Tip:
Highlight text to annotate it
X
This presentation describes support for service mapping that is included
in IBM WebSphere Application Server V8.5.5 full profile.
Service mapping is not included in the Liberty profile.
Service mapping provides a way of insulating an application that
consumes a service from the details of that service provider's interface or location.
This is achieved by providing a simple way of performing
content-based routing and message transformation.
This helps in many scenarios, such as 'service versions
' and 'meet in the middle', as a couple of examples.
There are many more.
A service versions scenario is when a service is modified
to cope with additional requirements, its interface and location
are likely to go through modifications that, although small,
are likely to break existing service consumers.
The 'Meet in the middle' scenario is when a
business unit defines the service interface that it expects to perform a task.
The defined service does not match the details of an
existing 'enterprise service' owned and offered by the IT organization.
When restructuring a message from one structure to another,
it is common for graphical tools to exploit the idea of a graphical message map.
It allows you to decide how a field in the input message maps to a field in the output message.
Provided here are a few factors you need to consider when mapping services.
When a service consumer interacts with a service provider that
can change its location, or can have a different
interface, there are three considerations: One, which
service location should you route a message to?
Two, which operation on the service provider should be
invoked when dealing with a request from a service consumer?
And three, for any particular operation, how must
each input and output or fault message be transformed?
In WebSphere Application Server V8.5.5, service mapping applies to
configured web service clients, or service consumers, that
make outgoing calls from a WebSphere Application Server 8.5.5 instance.
The web service message is intercepted and a specified mapping
can be applied to that intercepted message.
The web service client code itself does not need to
be changed in any way – the service mapping is
essentially invisible to both the consumer and the provider.
The application developer creates a service map in a service
map library in Rational Application Developer.
After creating the service map, the application developer can
export the service map library that contains the service map.
A service map library can contain one or more service maps.
After the service map library has been exported, it
can be passed to a WebSphere Application Server administrator so that it can be installed.
After the service map is installed in WebSphere Application Server,
it can be attached to a mapping service.
Once the service map is attached and the mapping service
is started, requests can be intercepted by the mapping
service and the requests and responses can be transformed or
re-routed using rules in the service map.
You can develop service maps with Rational Application Developer V9.
The service mapping tools package must be enabled when you
install or update Rational Application Developer.
By default, they are not enabled.
There are some prerequisites for developing service maps in Rational Application Developer V9.
When you install Rational Application Developer, select the service mapping tools option.
The option can be selected in a panel during the
setup process when you use Installation Manager to install Rational Application Developer V9.
You also need the wsdl files and xml schema files
used by the original source service and the new target
services so that you can define when and how requests,
responses, and faults are transformed or routed.
When a new service map is created in Rational Application
Developer 9.0, the first step is to define the
source and target services that the service map will connect.
These are defined in .WSDL files that describe the services.
When source and target services have been added, the
canvas in IBM Rational application developer shows the interfaces of each service.
Extra target services can be added.
The endpoint addresses of those target services can be set
at development time, when the service map is installed
into WebSphere Application Server, or when the service map
artifacts are administered when running in the application server.
The source and target services can be wired together.
By adding a wire, you are defining a route
that can be selected by the service mapping runtime so
that when a message for the source service is intercepted,
it is routed to the wired target service.
You can also add a condition to the wire,
so that it is only followed when the condition and the contents of the intercepted message matches.
Wires can be created at the interface level, where
the routing applies to all operations in that service interface,
or at the operation level, where only that specific
operation is routed and other operations are not affected.
The slide shows a fully wired up source service connected to three different target services.
The conditions are used at runtime to decide which of
the target service is called, dependent on the contents of the message.
If the first two conditions are not met, the
third 'Else' clause is used instead, meaning that
a message that reaches this service map will always be
rerouted to one of these three target services.
When an operation on the source interface is wired to
an operation on the target interface, you know that
a message intercepted for the source operation should be sent
on to the wired operation on the target interface.
When you select the wire on the canvas, you
are shown the operation mapping in the lower part of the canvas.
Here you can wire the returned messages from the target
service, such as the response message and any architected
fault messages as defined in the service WSDL.
Where the source and target operations have different interfaces,
each request, response, or fault message can have
a data mapping applied to it, allowing the message to be transformed to match the target interface.
The data mapping uses a standard data mapping editor that
is used in various IBM products, and .map
files are created in the Rational Application Developer project for these data mappings.
If the source and target operation interfaces match, you
can still apply a data mapping, allowing transformation of data.
This slide is a completed data mapping showing how structures can be mapped to each other.
Extra information can be included in the output message.
When service maps are exported from Rational Application Developer, a .slibzip file is created.
This contains all the artifacts used by the service maps.
These artifacts are: WSDL and XSD files that define
the interfaces used by the services, a service map
file that is an XML file with the extension .
srvcmap that contains the rules for transformation and routing, and message map files.
These are XML files with the extension .msl.
MSL is a dedicated XML syntax for expressing data maps.
The MSL files express how a message should be restructured from one data structure to another.
The MSL files are supported by Rational Application Developer before V9.
They are generated when the graphical data mapper is used.
A WebSphere Application Server administrator can configure service mapping using
the Integration Solutions Console or using the wsadmin commands in jython or jacl scripts.
An interception point is defined by creating a mapping service.
After the mapping service has been created and started,
it will intercept request and response messages sent and received by service clients.
The slide shows a simple case where an application running
in WebSphere Application Server is making web service calls to some web service provider.
Service mapping introduces the concept of the "mapping service
" - also known as a "local mapping service
" because it exists locally to the web service client application.
Mapping services are created administratively either in the administrative console
or with wsadmin commands.
These services are configured to intercept messages that are destined
for a specific service provider, meaning that messages from
multiple service clients running in the same WebSphere Application Server
cluster or server can be intercepted by a single mapping service.
Mapping services can be attached to service maps that have
been developed in Rational Application Developer, but do not need to be.
When a mapping service is not attached to a service
map, no re-routing or message transformation occurs, and
the message continues to its original target service.
An unattached mapping service can be used to control the
calls to the web service provider by starting or stopping
the mapping service, and can be used to emit events about the intercepted messages to a JMS topic.
When a web service request or response is intercepted by
the mapping service, an event message can be emitted.
The event messages can be recorded and used for audit purposes.
The mapping service must be configured in order for it to emit event messages.
Events can be useful for audit and monitoring purposes.
The events are published to a JMS topic.
You can publish the event message to any standard JMS
provider, like IBM MQ or the Service Integration Bus
that is included in WebSphere Application Server.
The events can be consumed by any JMS application that subscribes to that topic.
The administrator can define the scope of the content of
the event message - for example, whether it should
contain only the header, body, the whole of the message, or none of the message data.
A structured topic space is used, but that can be overridden by a JNDI reference name.
In WebSphere Application Server 8.5.5, the only way to
add an event point to a mapping service is with
the wsadmin administrative commands, not with the administrative console.
The four different administrative commands are shown in this slide.
To configure a local mapping service to emit events,
create an event point on that local mapping service.
An event point describes when the events are emitted,
the event contents, and event emission location details.
You can configure the event point to publish to a specified JMS topic.
If a JMS topic is not specified, events are
published to a topic by using the default topic string shown here.
The event point is created on a local mapping service, which is a cell-wide configuration.
This means that service client requests from any application in
the cell can be intercepted by the local mapping service and can cause an event to be published.
Local mapping services do not need to be attached to a service map to emit events.
If the local mapping service is stopped, events are not published.
To include message data in events, you must create
the WebSphere variable shown here and set its value to true.
If this variable is not defined or is set to
false, then the event will not contain the message
data that was intercepted in the request or response.
For a Network Deployment environment, the scope of the
WebSphere variable definition determines whether the policy is applied to
all nodes in the cell, or to individual clusters or servers.
The general use of event emission from a mapping service
is to publish events to a standard JMS topic space.
Any standard JMS topic subscriber can pick up the events.
The schema for events is published in the WebSphere Application Server 8.5.5 information center.
A specific scenario that can be enabled with event emission
from a mapping service is publishing to the IBM Integration Bus data capture store.
IBM Integration Bus (previously known as WebSphere Message Broker
) includes details of how to configure the data capture
store to allow subscription of events from WebSphere Application Server.
Once the IBM Integration Bus data capture store is configured,
an event point that publishes to the topic space can
be enabled on the mapping service in WebSphere Application Server.
Any web service messages that the mapping service intercepts will
cause an event to be published that can then be
acted upon using the IBM Integration Bus data capture, record, and replay functionality.
A service map that has been developed in Rational Application
Developer can be installed into WebSphere Application Server.
Once installed, it can be attached to the mapping service that has been administratively created.
Once attached, the mapping - as defined in the
service map - is applied to any web service messages intercepted by the mapping service.
When a service map is installed into WebSphere Application Server,
a set of standard artifacts is generated.
These artifacts are: a business-level application that contains links
to the other two artifacts, an enterprise application with
a service client for each target service defined in the
service map, and an enterprise bundle archive - or
EBA - that contains the service map file and any
related data maps, WSDL, and XSD artifacts from
the *.slibzip file that was exported from Rational Application Developer.
The enterprise application allows for standard WebSphere Application Server administration
of the service client – for example, adding policy or overriding the endpoint address.
If you create a service map that does not transform
or route a particular intercepted message, then that message
will continue on to the original service provider that it was destined for.
This slide shows the first step of using the WebSphere Application Server administrative console.
New panels have been added for service mapping under the "Service integration" section.
Here you see using the administrative console to install a
service map that has been developed in Rational Application Developer
and exported as a *.slibzip file.
This slide shows the second step of using the WebSphere Application Server administrative console.
The slide shows the creation of a local mapping service
that is defined to intercept messages that are destined for a specific web service provider.
When the local mapping service is created, it can be attached to the installed service map.
There are no debugging tools in Rational Application Developer 9.0
for service maps, so developers will need to test
service maps on a WebSphere Application Server V8.5.5 instance.
By switching on fine-level service mapping trace, some useful
and translated information messages are shown in the trace logs.
This level of tracing is also useful for general problem
determination in a running service mapping system.
This trace shows the messages that are seen in a trace.log file for a service mapping invocation.
You can see the interception of a message, the
matching of the intercepted message with a local mapping service,
the fact that the local mapping service is attached to
a service map, and the contents of the intercepted message.
You can also see the selected target service that is
routed to, the fact that the message is transformed
by a specific data map, the output from the
transformation, and the fact that the message has been sent to the selected target service.
You will also see similar messages for the return path,
whether that is a normal response message or a fault message.
Service mapping provides a way of insulating an application that
consumes a service from the details of that service provider's interface or location.
This is achieved by providing a simple way of performing
content-based routing and message transformation.
It is supported in WebSphere Application Server 8.5.5 base profile
and in tools in Rational Application Developer 9.0.
Service mapping extends data mapping so that you can define
service maps, interface maps, and operation maps.
Additionally, it allows you to configure event points so
that you can audit the web service requests and responses
that are intercepted by the mapping services.
See these references for additional information about service mapping
You can help improve the quality of IBM Education Assistant content by providing feedback.