Web services gateways running on WebSphere® Application Server Version 5
application servers can, subject to certain restrictions, coexist
with Version 6 gateways and be part of Version 6 cells. Alternatively
you can migrate the gateways, and the application servers on which
they are running, to WebSphere Application
Server Version 6. To help you choose whether to preserve or migrate
your Version 5 gateways, this topic explains the restrictions to gateway
coexistence and the approach taken to gateway migration.
Coexistence with Version 5 gateways
Coexistence,
as it applies to WebSphere Application
Server products, is the ability of multiple installations of WebSphere Application Server
to run on the same machine at the same time. Multiple installations
include multiple versions and multiple instances of one version. Coexistence
also implies various combinations of Web server interaction.
Version 5
Web services gateways can coexist with Version 6 gateways, subject
to the following restrictions:
- The Version 5 Web services gateway application is not supported
on Version 6.0 or later application servers.
- The service integration technologies endpoint listener applications
are not supported if installed on Version 5 application servers.
- The Version 6 administrative console and the service integration
technologies administrative commands can only be used to change the
configuration of gateways running on Version 6 application servers.
To change the configuration of a gateway running on a Version 5 application
server, you use a Web browser to access the Version 5 gateway user
interface.
Version 6 Network Deployment cells can contain both Version
5 and Version 6 application servers, so you can continue to use gateways
that are running in a cell even if you migrate the cell from Version
5 to Version 6. However when you migrate a cell, any previously configured
gateway on any Version 5 application server in the cell is replaced
with an empty gateway. To preserve your gateway configuration, you
must follow the steps given in Preserving a Version 5 gateway when migrating a Version 5 cell.
Migration of Version 5 gateways
You can
migrate a Version 5 gateway running in a Version 5 application server
to a Version 6 gateway running in a Version 6 application server.
To do this you export the Version 5 gateway configuration, then run
a script to migrate the exported configuration into a new gateway
instance in an existing Version 6 application server. The detailed
steps for this task are given in
Migrating
a complete 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.
You cannot migrate a gateway directly
to a Version 6 application server that is part of a cluster. To achieve
a clustered configuration, you should use the topic Migrating
a complete gateway configuration to migrate your gateway to
a single server that is part of a managed cell, then manually convert
the Version 6 single server to a cluster.