Service mapping for WebSphere Application Server

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.

Static routing

In a WebSphere® Application Server environment, applications can act as service clients or as service providers. Such service clients and service providers are configured to interact with a static endpoint address, as shown in Figure 1. In this situation, a service client can connect to a service provider only when the endpoint address of the service provider is known and the interface that is expected by the service client is the same as the interface provided by the service provider.
Note: In this diagram and subsequent diagrams, interfaces and services are indicated by shapes: circle, squares, triangles, and hexagons. Open shapes indicate interfaces. Filled-in shapes indicate services. An identical open shape on both the service client and the service provider means that their interface types are the same.
Figure 1. Static routing. An example of static routing, in which a specific service client hosted on one application is configured to interact with a specific service provider.
A service client is configured to interact with a service provider. A line indicates a direct connection between the service client interface and the service provider interface.
In the previous example, a specific service client is configured to interact with a specific service provider. When a new service provider is introduced, as in Figure 2, the service client must be configured manually to route requests to the new service provider (Service Provider 2), and to ignore the previous service provider (Service Provider 1).
Figure 2. Static routing with more than one service provider. A new service provider is introduced and you must manually configure the service client to route to the new service provider.
The service client previously routed to Service Provider 1. A new service provider, Service Provider 2, is introduced, and the service client now routes to the new service provider. A line shows the connection between the service client interface and the interface of Service Provider 2.

Service mapping

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.

For example, service mapping can be useful in the following scenarios:
  • When you want a service client to be able to dynamically select from several service providers, based on data in the service request. For example, when different services are required based on which department within an enterprise a service request originated from (dynamic routing).
  • When a service client requires a service with a particular interface, and a service provider that provides the function exists, service mapping can be used to transform the service request and response messages so that any interface mismatches are resolved (transformation).
  • When the interface and implementation for a service provider are updated to provide a new version (dynamic routing and transformation).

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.

Routing and transformation by using service mapping

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.

Figure 3. Routing by using service mapping. The service interaction is intercepted by the local mapping service, which routes it to the service provider specified in the service map.
The diagram shows a service client that is connected to a service provider through a local mapping service, which has a service map attached. A line shows the connection between the interface of the service map and the interface of the service provider. The service client and the local mapping service are shown in the same rectangle, indicating they are hosted on the same application.

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.

Figure 4. A service mapping between a service client and a service provider that use different interfaces. The service request is intercepted by the local mapping service, which routes it to the appropriate service provider, and carries out any specified transformations.
In this diagram, the different interfaces are shown by using a circle, a triangle, and a square. The circle represents the interface that is used by the service client, and the triangle and square are the interfaces that are used by the service providers, showing that some transformation is needed before the request can be routed.

Clustered environments

In a clustered or network deployment environment, deploy service maps to all the clusters that contain service clients whose requests you want to intercept.

As an example, consider an environment with three clusters or managed servers that are defined in a WebSphere Application Server Network Deployment environment. A local mapping service has a service map attached. All local mapping services apply to all nodes in the network deployment environment. In this scenario the local mapping service has an attached service map that is deployed to two servers: a server in Cluster 1 and a server in Cluster 2. When you install a service map, you must choose to which deployment targets you want to deploy that service map. The service map must be deployed to all the deployment targets that contain clients whose requests are to be intercepted by the local mapping service. You can specify the deployment targets by either of the following methods:
  • By using the -deploymentTargets parameter on the installServiceMap command.
  • By using the administrative console to install your service map.
Figure 5. Service mapping in a clustered environment

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.

Monitoring services

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.


Icon that indicates the type of topic Concept topic

Terms and conditions for information centers | Feedback


Timestamp icon Last updated: Tuesday, 22 April 2014
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-iseries&topic=csmwas_servicemappingintro
File name: csmwas_servicemappingintro.html