Web services gateways running on WebSphere® Application Server Version 5.1 can, subject to certain restrictions, coexist with gateway instances running on Version 7.0 or later application servers. Alternatively, you can migrate the Version 5.1 gateways and application servers to WebSphere Application Server Version 7.0 or later. To help you choose
whether to preserve or migrate your Version 5.1 gateways, this topic
explains the restrictions to gateway coexistence and the approach
taken to gateway migration.
Note: WebSphere Application Server Version 5.0 is no longer supported, so you should migrate any existing gateways that are running in Version 5.0 application servers to run on application servers at the current level of the product.
Coexistence with Version 5.1 gateways
Version 5.1 web services gateways
can coexist with
Version 7.0 or later gateways,
subject to the following restrictions:
- The Version 5.1 web services
gateway application is not supported on Version 7.0 or later application servers.
- The service integration technologies endpoint listener applications
are not supported if installed on Version 5.1 application servers.
- To change the configuration of a gateway running on a Version 5.1 application server, you
use a web browser rather than the administrative console to access
the Version 5.1 gateway user
interface.
If your deployment is not affected by these restrictions,
and your Version 5.1 gateways
are running on stand-alone Version 5.1 application
servers, then you need take no further action.
If your deployment
is not affected by these restrictions, and your Version 5.1 gateways are running
on Version 5.1 application servers
that are part of WebSphere Application Server Network Deployment cells,
you can continue to use the Version 5.1 gateways
and application servers even if you migrate the cells from Version 5.1 or Version 6 to Version 7.0 or later. However, when you
migrate a cell any previously-configured Version 5.1 gateway on an application
server in the cell is replaced with an empty gateway. To preserve
and restore your Version 5.1 gateway
configurations, you must first follow the steps given in Preserving a Version 5.1 gateway when migrating a cell.
Migration of Version 5.1 gateways
You
can migrate a
Version 5.1 gateway
running in a
Version 5.1 application
server to a
Version 7.0 or later gateway
running in a
Version 7.0 or later application
server. To do this you export the
Version 5.1 gateway configuration,
then run a script to migrate the exported configuration into a new
gateway instance in an existing
Version 7.0 or later application server.
The detailed steps for this task are given in
Migrating a Version 5.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.