Coexistence: Preserve or migrate a v5.1 gateway

Coexistence: Preserve or migrate a v5.1 gateway

Web services gateways running on WebSphere Application Server v5.1 can, subject to certain restrictions, coexist with gateway instances running on v7.0 or later application servers. Alternatively, we can migrate the v5.1 gateways and application servers to WAS v7.0 or later. To help us choose whether to preserve or migrate our v5.1 gateways, this topic explains the restrictions to gateway coexistence and the approach taken to gateway migration.

WAS v5.0 is no longer supported, so we should migrate any existing gateways running in v5.0 application servers to run on application servers at the current level of the product.

Coexistence with v5.1 gateways

v5.1 web services gateways can coexist with v7.0 or later gateways, subject to the following restrictions:

The v5.1 web services gateway application is not supported on v7.0 or later application servers.
The service integration technologies endpoint listener applications are not supported if installed on v5.1 application servers.
To change the configuration of a gateway running on a v5.1 application server, we use a web browser rather than the administrative console to access the v5.1 gateway user interface.

If our deployment is not affected by these restrictions, and our v5.1 gateways are running on stand-alone v5.1 application servers, then we need take no further action.

If our deployment is not affected by these restrictions, and our v5.1 gateways are running on v5.1 application servers that are part of WAS Network Deployment cells, we can continue to use the v5.1 gateways and application servers even if we migrate the cells from v5.1 or v6 to v7.0 or later. However, when we migrate a cell any previously-configured v5.1 gateway on an application server in the cell is replaced with an empty gateway. To preserve and restore our v5.1 gateway configurations, first follow the steps given in Preserving a v5.1 gateway when migrating a cell.

Migration of v5.1 gateways

We can migrate a v5.1 gateway running in a v5.1 application server to a v7.0 or later gateway running in a v7.0 or later application server. To do this you export the v5.1 gateway configuration, then run a script to migrate the exported configuration into a new gateway instance in an existing v7.0 or later application server. The detailed steps for this task are given in Migrate a v5.1 web services gateway configuration. The key rules underlying the migration process are as follows:

The migration can happen in parallel with the original gateway continuing to run, and without disrupting the existing configuration.
Each execution of the migration command acts on a single gateway configuration.
A gateway configuration is migrated into a gateway instance, within a service integration bus. More than one gateway can be migrated into the same bus, but in that case the gateway namespace URIs must be different.
The endpoint listeners for the gateway instance are all located on the same application server or cluster; localizations of port destinations for outbound invocation are all in the same application server or cluster.
All created objects and destinations have the gateway namespace URI as a prefix to their name, concatenated with a colon (":"). For example with the default namespace URI, a gateway service reply destination would be called: urn:ibmgateway:gatewayservicenameReply. This prefix can be overridden by a parameter on the migration command.
All target services are migrated into new OutboundService objects. Existing OutboundService objects cannot be automatically reused by the migrated configuration.
A JAX-RPC handler list is created for every gateway service/channel and gateway service/target service/port combination. These are not shared even if they contain the same handlers in the same order.
WS-Security (Draft 13) configuration and binding objects are created for every gateway service/gateway service and target service combination. These are not shared even if they have all the same attribute values. All created objects have names based upon the name given to the inbound or outbound service created by the migration tool:

The WS-Security configurations created for each service are given the same name as the service itself, suffixed by either _Inbound or _Outbound.
The WS-Security configuration objects created as children are given the same name as the type of object, followed by _x, where x is the number of objects the migration tool has created of the type for the service. For example the first Required Integrity object created for a given service is called RequiredIntegrity_1.
The WS-Security bindings created are given a name consisting of the port name, suffixed by the type of binding, one of _Req_Rec, _Req_Snd, _Res_Rec and _Res_Snd.