You use a wsadmin command script to migrate from a previous gateway version. The migration procedure takes an existing working gateway application whose configuration has been exported to an XML file and uses the exported XML file to configure the same gateway functionality on a Version 6 application server or cluster. Requester applications can then switch over to using the new gateway configuration while the existing Version 5 gateway continues to run. For more information, see Migrating a complete gateway configuration.
As in previous versions, you use a Web services gateway to map an existing target service to a new Web service that seems to be provided by the gateway. The gateway acts as a proxy. It provides you with a single point of control, access and validation of Web service requests, and allows you to control which Web services are available to different groups of Web service users. It also allows you to map multiple target services to a single gateway service, and to configure proxy services.
In this version, you map a service that is provided at a service integration bus destination as a gateway service. The service provided at the destination can be either an internal service (hosted so as to be directly available at the destination) or an externally-provided Web service.
For a high-level task view of how you configure the Web services gateway as part of an overall bus-enabled Web services configuration, see Enabling Web services through service integration technologies.
In this version of the gateway, channels are replaced by endpoint listeners and ports. The endpoint listeners that are supplied with this version support SOAP over HTTP and SOAP over JMS bindings. For more information, see Endpoint listeners and inbound ports - entry points to the service integration bus. WS-Security settings and JAX-RPC handler lists are now applied at ports.
Within each service integration bus you can create multiple gateway instances, and within each gateway instance you can configure gateway and proxy services to use endpoint listeners. This allows you to finely control the groups of users that can access each Web service.
Selective SOAP parsing is a technique whereby the service integration technologies parse only the headers of incoming messages for a Web service, and the message body is passed through unchecked. This technique optimizes the speed at which messages pass through the service integration bus.
In WebSphere Application Server Version 5, selective SOAP parsing is an optimization that you could select for any gateway-deployed Web service that used a SOAP over HTTP binding. In this version, selective SOAP parsing is automatically applied to all Web services that are configured for a service integration bus, and is supported for both SOAP over HTTP and SOAP over JMS bindings.
Existing filters are not migrated, but are supported in this version through a co-existence mediation. The role formerly played by filters is now undertaken by a combination of JAX-RPC handlers and service integration bus mediations.
In this version of the gateway you define one or more WS-Security configurations and bindings, each of which can then be applied to many Web services. For more information, see Service integration technologies and WS-Security.
For core administrative tasks (for example creating a new gateway service configuration) you can either use a set of configuration wizards accessed from within the administrative console, or access equivalent functionality through the gateway administrative commands.
This version of the gateway uses a Service Data Objects (SDO) repository, backed by your preferred database, for storing and serving WSDL definitions. For more information, see Installing and configuring the SDO repository.