For users of version 7.0 of the Telecom Web Services Server (TWSS)
product, there are several points to consider when migrating your
existing configuration to version 7.1.
A version 7.1 Access Gateway can
coexist with a version 7.0 Access Gateway within
the same cluster. Because the TWSS Access Gateway component
is stateless, no migration is needed.
The TWSS Service Platform
is a stateless component, and as such it does not require migration.
Each service maintains a state that is related to current session
activity; as a result, when the service is stopped, there are no remaining
states that need to be migrated.
No automatic migration is provided
for Access Gateway flows
that you have customized. You must import any existing custom flows
into WebSphere® Integration Developer and
export them for the new target runtime.
Coexistence among components
Different
versions of the TWSS components can coexist as follows.
- Access Gateway:
- The Access Gateway in
version 7.1 can
interoperate with the Service Platform components in
version 7.0. However, if you want to use the Access Gateway in
version 7.1 with
the Service Policy Manager in
version 7.0, new policies corresponding to the OneAPI notification
need to be added.
- Access Gateway version 7.1 can
interoperate with all versions of Service Policy Manager.
- Access Gateway version 7.1 can
interoperate with all versions of Address List Management.
- TWSS Administration Console:
The console can integrate with the other TWSS components at either
the version 7.1 or
version 7.0 level. The version 7.1 console
can integrate with any supported version of WebSphere Application Server.
- Web service implementations:
Version 7.1 instances
of the Web service implementations can
operate together with version 7.0 instances.
Considerations for upgrading the TWSS base
components
As you plan to upgrade the TWSS base components,
consider the following.
- It is not necessary to retrieve and preserve runtime data when
you are upgrading the Access Gateway and Service Policy Manager components
to version 7.1.
As a result, the upgrade steps for these components primarily involve
stopping the server, replacing the program code, and restarting the
server.
- If you use customized message processing flows for the Access Gateway,
some modifications might be required. Changes for TWSS version 7.1 include:
- There are two Service Level Agreement (SLA) mediation primitives:
SLA Local Enforcement and SLA Cluster Enforcement. With SLA Cluster
Enforcement, the hierarchical limits in the SLA mediation primitive
are enforced using a sliding window, rate limiting bucket algorithm.
With SLA Local Enforcement, the hierarchical limits in the SLA mediation
primitive are enforced using a fixed window algorithm. For details,
see the SLA Enforcement mediation primitives topic in
the Mediation Primitives section of this information center.
- System configuration data for the Service Policy Manager is
maintained in the form of policies. Take the following things into
account as you migrate to TWSS version 7.1:
- If any of the policy names change, or if your deployment assumptions
(configuration options) change, you must migrate the policy data manually
to a new database.
- Some deployment options in the WebSphere Integrated Solutions Console are
tied to specific software versions, which necessitates manual migration
steps.
- New default policies are introduced in version 7.1 for
some of the Web service implementations.
For a complete list see Considerations for upgrading the Web service implementations,
elsewhere in this topic.
- There are no special considerations for upgrading the Service Platform components.
- There are no special considerations for upgrading the TWSS Administration Console for
TWSS version 7.1.
The upgraded console can integrate with any supported version of WebSphere Application Server.
Considerations for upgrading the Web service implementations
The
following sequence of steps is recommended for upgrading a Web Service
implementation in a clustered environment without disruption:
- Defederate one of the active nodes.
- Upgrade the node to the new Web service implementation, either
by updating it or by uninstalling the old version and installing the
new one. During this time, the other active nodes can continue to
process requests.
Note: If you use a distributed database configuration,
refer to the topic Migrating data in a distributed database
configuration when you perform the updates.
- Federate the node on which you upgraded the Web
service implementation.
- Repeat steps 1 through 3 for each remaining node.
(For details on how to perform these steps, refer to the
instructions in Migrating from the previous version of Telecom
Web Services Server.)
Some of the
Web service implementations entail
special considerations when you upgrade them to run in a version
7.1 environment.
Those considerations are listed here.
- For Parlay X SMS over SMPP,
in TWSS version 7.0, the Enable Synchronous SMS and Enable StatusLess
SMS controls were used to specify the message type for configuring
network elements to prepare them to receive messages from Parlay X SMS over SMPP.
When you migrate from version 7.0 to version 7.1,
you need to reset this value using the new Type of Message setting.
See the topic Administering Parlay X SMS over SMPP for
more information.
- The following new default policies are introduced in version 7.1 for
some of the Web service implementations.
(All default policies used in TWSS version 7.1 are
listed in the TWSS Reference section of this information center.)
- notification.Endpoint.Type - Parlay X Payment (PostPaid), Parlay X Terminal Location over MLP, Parlay X Terminal Location over
Parlay, Parlay X SMS over Parlay,
and Parlay X SMS over SMPP
- service.Endpoint - Parlay X Call Handling over SIP/IMS