Use service mapping to route and transform requests and responses between service clients and service providers, so that you remove the dependence of the service client on the service provider location and on the service provider interface.
By using service mapping, requests and responses can be intercepted and rerouted or transformed, without the need to change the endpoint details each time. Use service mapping to avoid having to reconfigure an application that uses a service provider each time you change either the location of a service, or its interface.
In WebSphere Application Server, a service mapping consists of a local mapping service and an attached service map. The local mapping service intercepts requests and responses between service clients and service providers. The service map defines the conditions for routing and transformation of the requests and responses that are intercepted by the local mapping service. The service client and the local mapping service must be hosted on the same WebSphere Application Server cell.
To reroute and transform service interactions by using service mapping, you must have a service map attached to your local mapping service. A service map is defined by a .slibzip file that contains rules for routing requests, and for transforming requests and responses. You can create a service map by using the Service Mapping editor in Rational® Application Developer, then deploying the map to the WebSphere Application Server runtime. The WebSphere Application Server administrator uses the service map by installing it and attaching it to a local mapping service. When the local mapping service intercepts requests sent from a service client and has a service map attached, that local mapping service uses conditions that are set in the service map to route or transform those requests.
When using service mapping, service clients do not need details of the location and interface format of the new service providers that they need to interact with. Figure 4 shows how a local mapping service can route to a service provider, even if that service provider has a different interface to the interface used by the service client.
In a clustered or network deployment environment, deploy service maps to all the clusters that contain service clients whose requests you want to intercept.
In Figure 5, the service map is installed, attached to the local mapping service, and deployed to Cluster 1 and Cluster 2. The service map is not deployed to Cluster 3 because Cluster 3 was not specified as a deployment target when the service map was installed. Therefore, the local mapping service intercepts only requests from service clients in Cluster 1 and Cluster 2. The routing conditions and transformations in the service map are applied to these requests, which are transformed and routed to Service Provider 2, instead of to Service Provider 1. If the service client in Cluster 3 sends a request to Service Provider 1, the local mapping service intercepts the request, but does not reroute the request to Service Provider 2, because the service map was not deployed to Cluster 3. The local mapping service therefore sends a SOAP Fault back to the service client in Cluster 3 with a message that contains the reason for the fault.
You can view information about the requests and responses that are intercepted by the local mapping service. The local mapping service can be configured to emit events before a request is intercepted, and after the response is intercepted. You can configure the contents of the emitted events when you create an event point by using administrative commands. The emitted events are published to a JMS topic. To view these events, you can use the built-in data capture functions in IBM® Integration Bus, or you can use any JMS provider that is configured in WebSphere Application Server. For more information, see Event emissions when using service mapping.