Level: Intermediate Amanda Watkinson (amanda.watkinson@uk.ibm.com), Software Engineer, IBM
20 Mar 2008 Check out the latest features introduced into IBM® WebSphere® Enterprise
Service Bus V6.1 and its associated tooling, IBM WebSphere Integration Developer.
This article describes the transport protocol binding, data
bindings, and administrative and mediation support. You should have basic
knowledge of the features and functions of previous versions of WebSphere Enterprise
Service Bus to follow along with this article.
WebSphere Enterprise
Service Bus overview
WebSphere Enterprise Service Bus enables the integration of disparate systems
through the deployment of mediation modules. You author mediation modules using
WebSphere Integration Developer. Mediation modules provide access to a message's payload and
transport headers using a Service Message Object (SMO), which is the logical
representation of the message data as it passes through the mediation flow. Within
the mediation module, the message may be logged, augmented, transformed, or routed
to integrate services across the bus. (For more information about the basic concepts
of WebSphere Enterprise Service Bus, see Resources at the
end of this article.)
The next few sections introduce the new features and functions in WebSphere Enterprise
Service Bus V6.1, starting with the enhancements to the installation and
configuration wizards.
Then you explore the new bindings function and, finally, the new
mediation primitive support. Note: This article doesn't cover every addition, nor does it
attempt to describe each section in great depth. Instead it focuses on the
important features, highlighting the capabilities of each new function.
Improved installation
and configuration support
WebSphere Enterprise Service Bus is built on top of IBM WebSphere Application Server Network Deployment
and, thus, exploits the application server's workload balancing and high-availability capabilities. This version of WebSphere Enterprise Service Bus introduces a set of
wizards to help the system administrator, with improved support for configuring
different messaging engines and clustered server topologies. The following
diagrams illustrate some of the configuration options available from the profile
management tool.
Figure 1 illustrates some of the options in the profile creation wizard. You
can choose the configuration option that suits your needs, ranging from
a typical configuration to more advanced options. The advanced options
give you fine-grained control over settings, such as port
values, installation of the administrative console, and database configuration.
Figure 1. Choosing different
WebSphere Enterprise Service Bus profile configurations
Figure 2 illustrates some of the advanced options, such as letting you
specify a different messaging engine, common event infrastructure, and cluster
configurations.
Figure 2. Messaging and server
cluster configuration options
You can also specify security settings and database configuration options within
the installation and configuration wizards. The advantage of the enhanced
administrative support lies in the ready-to-use experience that lets you get commonly used clustering configurations up and running
in less time.
New and enhanced
transport protocol support
This section describes the newly added data bindings and the new HTTP
transport protocol binding.
In WebSphere Enterprise Service Bus, imports define the connection to
existing services, whereas
exports define how a newly constructed service is exposed to external
applications. Both imports and exports are associated with transport-specific
protocol bindings, such as Web services, IBM WebSphere MQ, Java™ Message
Service (JMS), WebSphere MQ for Java Message Service, or
Service Component Architecture (SCA).
Specific protocol binding types, such as WebSphere MQ, JMS, and
WebSphere MQ for Java Message Service, also enable the configuration of function selectors and data
bindings. A function selector specifies the particular operation to invoke within
the mediation modules interface. A data binding converts the transport's native
message into the Service Data Objects (SDOs) expected by the components, and vice versa.
In WebSphere Enterprise Service Bus, data is represented as an SMO, which is a
specialised SDO and provides a common way to access the data
regardless of which transport is used.
In this article, a binding describes the protocol
binding associated with an export or import, and data
binding describes the data binding you can specify within the export
and import binding, which converts the native data to a data object, and vice versa.
For example, the JMS binding is the transport protocol
associated with an export, whereas the JMS Object data binding converts the
object message into the associated data object.
New HTTP transport
binding
In version 6.1, the HTTP binding is introduced to complement the current list of
transport protocols for export and import bindings, providing access to the raw
HTTP headers and content within the SMO.
The diagram in Figure 3 illustrates the HTTP export and import icons within the
tooling.
Figure 3. HTTP export and import
bindings
You can configure the HTTP binding with a predefined or custom function selector
and data binding. The binding comes with the following two predefined function
selectors:
-
HTTP header function selector: Uses the message header named
TargetFunctionName to specify the interface operation to invoke
-
HTTP URL function selector: Uses the URL address to determine the
interface operation to invoke (for example, http://myHost/myService/getQuote
would invoke the
getQuote operation on the target
service)
You can create custom function selectors should you want to use information in
other parts of the message to determine which operation to invoke.
Although you can write your own data binding, the HTTP binding comes with three
predefined data binding implementations:
-
HTTP bytes data binding: Used to receive bytes
-
HTTP XML data binding: Used to receive XML, which represents the data
object defined in the service interface
-
HTTP SOAP data binding: Used to receive SOAP messages whose bodies are
converted into the data object representation defined in the service
interface
You can also select a fourth data binding, called the IBM WebSphere Transformation Extender data
binding, which is discussed in the New data bindings
section.
The code samples below show how an XML message sent to the HTTP binding is
represented in the SMO when using the XML data binding. In Listing 2, the known
HTTP headers are contained in the HTTPHeader element in the SMO, with additional
transport headers, such as cookies, contained in the properties elements.
Listing 1.
Incoming XML message
<?xml version="1.0" encoding="UTF-8"?>
<ns1:getCustomerDetails xmlns:ns1="http://BusinessLibrary/getCustomerDetails">
<customerID>12345</customerID>
</ns1:getCustomerDetails>
|
Listing 2. XML
representation of the SMO
<?xml version="1.0" encoding="UTF-8"?>
<smo:smo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:smo="http://www.ibm.com/websphere/sibx/smo/v6.0.1"
xmlns:customer="wsdl.http://BusinessLibrary/getCustomerDetails"
xmlns:customerDetails="http://BusinessLibrary/getCustomerDetails"
xmlns:http="http://www.ibm.com/xmlns/prod/websphere/http/sca/6.1.0">
<context/>
<headers>
<SMOHeader>
<MessageUUID>E3E1664D-0116-4000-E000-12600914F31C</MessageUUID>
<Version>
<Version>6</Version>
<Release>1</Release>
<Modification>0</Modification>
</Version>
<MessageType>Request</MessageType>
</SMOHeader>
<properties>
<name>Cookie</name>
<value>ABCDE12345</value>
</properties>
<HTTPHeader>
<control>
<http:URL>
http://localhost:9080/CustomerWeb/Export1/getCustomerDetails
</http:URL>
<http:Version>1.1</http:Version>
<http:Method>POST</http:Method>
</control>
<header>
<http:name>Host</http:name>
<http:value>localhost:9080</http:value>
</header>
</HTTPHeader>
</headers>
<body xsi:type="customer:getCustomerDetailsRequestMsg">
<customerDetails:getCustomerDetails>
<customerID>12345</customerID>
</customerDetails:getCustomerDetails>
</body>
</smo:smo>
|
 |
New generic JMS provider
bindings
Figure 4 shows how to select the new generic JMS provider protocol binding for
export and imports within the tooling. This binding type integrates with
third-party JMS 1.1 providers (that have already been configured in WebSphere) and
works in much the same way as the current JMS protocol binding. The key difference
is that you should use the existing JMS binding to interact with the default
messaging provider found in WebSphere Application Server; for other JMS 1.1
providers that support the optional Application Server Facility (ASF), you should
use the new generic JMS binding.
Figure 4. Selecting the generic
JMS binding
New data bindings
You can configure custom and predefined data bindings for some of the messaging
import and export transport protocol bindings. IBM has increased the number of
predefined data bindings in WebSphere Enterprise Service Bus
V6.1, providing more capabilities that are ready to use as they are. In addition,
you can now create data binding configurations, which can
be shared across a number of different export and import binding instances.
One important addition to the collection of predefined data bindings is the new
WebSphere Transformation Extender data binding, which allows integration of
WebSphere Enterprise Service Bus with WebSphere Transformation Extender V8.2 (see Figure
5). WebSphere Transformation Extender is a powerful transformation and
validation engine (see Resources for more information
about this product).
Figure 5. Selecting the WebSphere Transformation Extender data
binding
The WebSphere Transformation Extender data binding delegates the transformation logic to WebSphere
Transformation Extender. The data binding is configured with the appropriate map
names, which are invoked at run time to convert the native data to the data object
format, and vice versa.
Mediation primitives
WebSphere Enterprise Service Bus V6.1 introduces several new mediation primitives
as well as
enhancements to the current collection.
Enhanced custom
mediation support
To use a custom mediation, you add the icon shown in
Figure 6 to the mediation flow.
Figure 6. Custom mediation
primitive
Custom mediation primitive support has been enhanced to provide more
flexibility for writing custom code within the mediation flow. In previous
versions of WebSphere Enterprise Service Bus, only one input and output terminal was allowed on the
custom primitive; now this has been relaxed to allow multiple terminals. Figure 7
shows a custom mediation containing two input terminals and three output
terminals. This allows complex routing conditions where you can specify which
output terminals to fire based on some logic contained within the mediation
primitive.
Figure 7. Enhanced custom
mediation showing multiple input and output terminals
The tooling still allows you to choose either the graphical snippet or Java
editor, but now in both you can fire different output terminals depending on the
logic within the mediation primitive, or throw an exception to trigger the fail
terminal. You can also define user properties on the mediation primitive, which
can be promoted, enabling the system administrator to modify the values at run time,
just as properties on other mediation primitives may be promoted.
XSLT editor
To
use an XSLT mediation, you add the icon shown in Figure 8 to the mediation flow.
Figure 8. XSLT mediation primitive
The XSLT mapping editor has been updated, bringing many usability enhancements
and, in particular, improved custom scripting support. The editor is similar to
the previous version in that it shows the input and target message mappings. But
now it lets users define submaps, which can be reused across a number of
different primitives and, as Figure 9 illustrates, additional custom logic within
the editor.
Figure 9. New XSLT editor
With complex transformations, it's useful to be able to test the mapping output
prior to deployment. In version 6.1, this facility is now provided as part of the XSLT
mediation primitive. A sample XML input file is created if the check box Create a
sample xml input file for testing the XML Map is selected when the XSLT mapping is
generated (see Figure 10). This creates an input XML file that can be
located in the physical resources view within the tooling business integration
perspective.
Figure 10. Creating a sample XML
file for XSLT testing
Within the XSLT mapping editor, you can also select the associate XML files icon
to associate new input XML files. When you select the generate XSL script
icon, the defined input XML files are transformed based on the map definition with the
output XML files placed in the physical resources business integration
perspective.
New Business Object Map
mediation primitive
To use a Business Object Map mediation, add the
icon shown in Figure 11 to the mediation flow.
Figure 11. Business Object Map
primitive
The Business Object Map primitive provides an additional mapping tool within the
mediation flow. Whether you choose to use the XSLT primitive or the Business
Object Map primitive is dependent on the function required. If you're familiar
with XSLT and want to use existing XSLT function, then you might want to choose
the XSLT primitive. However, if you're familiar with the Business
Object Map technology within WebSphere Process Server or have business object
relationships already defined, you might want to use the Business Object Map primitive instead.
Figure 12 shows a mapping using the Business Object Map editor. You can
perform several functions, such as add custom code or invoke relationship
mapping. Relationship mapping is a powerful function of the Business Object Map
primitive that associates data in different contexts. For example, a particular
service might generate the customer ID as integer values, but the target service
expects the ID in a different format using a combination of characters and integers.
You can create a relationship map that defines the relationship between these two
logical fields and then invoke this from the mapping editor.
Figure 12. Business Object Map
editor
New Set Message Type
mediation primitive
To use a Set Message Type mediation, add the icon
shown in Figure 13 to the mediation flow.
Figure 13. Set Message Type
primitive
This primitive provides enhanced support for the XML schema any,
anySimpleType, or anyType definitions. For message definitions that contain
such elements, this primitive enables the concrete runtime types or elements to be
specified within the tooling. The following scenario illustrates the use of the
Set Message Type primitive. A business object called Car contains an xsd:anyType
within its message definition, but at run time this element may contain either the
business object type FordCar or the type HondaCar. All three business objects
are shown in Figure 14.
Figure 14. Sample business objects
Figure 15 shows a mediation flow that uses a Message Filter primitive to route
the message based on the Car id element. If the id element starts with x, then
the Car message contains the FordCar type; otherwise it contains the HondaCar type.
The Set Message Type primitive, called SetFordType within the mediation,
associates the details xsd:anyType in the Car business object with the FordCar
business object.
Figure 15. Mediation flow
containing the Set Message Type primitive
Subsequent mediation primitives, downstream of the Set Message Type primitive,
use this concrete information to display the expanded information to the user to specify appropriate XPath expressions. Notice how the details element
now contains the FordCar type in the XSLT mapping
editor shown in Figure 16.
Figure 16. Downstream XSLT
primitive uses the Set Message Type information
New Service Invoke
mediation primitive
To use a Service Invoke mediation you add the icon
shown in Figure 17 to the mediation flow.
Figure 17. Service Invoke
primitive
In previous releases of WebSphere Enterprise Service Bus, users invoked a service from within the
mediation module either by wiring the flow to a callout node or by providing
custom code. The new Service Invoke mediation primitive enables users to additionally invoke
services from anywhere within a mediation flow.
Along with out and fail output terminals, this primitive has a timeout
terminal that propagates the original message if an asynchronous invocation with
deferred response fails to return a message within a specified time period.
Further output terminals are generated in the tooling for each fault message
specified on the target service interface. This lets you handle all the
defined responses, both output and fault, that can be returned from the target
service. As with callout nodes, the Service Invoke primitive can be configured to
retry invocations of the target service or to perform dynamic invocation using
endpoint address URLs specified in the SMO header or in the primitive properties.
You can place any number of Service Invoke primitives within the request or
response mediation flow. This feature becomes powerful when used in
conjunction with the new Fan Out and Fan In mediation primitives.
New Fan Out and Fan In
mediation primitives
To use a Fan Out and Fan In mediation you add the
icons shown in Figure 18 to the mediation flow.
Figure 18. Fan Out and Fan In
mediation primitives
The new Fan Out primitive lets a user fire one or more messages for a
repeated message element within the mediation flow and, when coupled with the Fan
In primitive, defines a scope in which aggregation of data from multiple sources
can be defined.
You can configure the Fan Out mediation primitive to fire its output terminal
just once or once for each element obtained using a specified XPath expression.
This
enables the creation of different messages for repeated elements. For example,
using the XML representation in Listing 3, you can configure
the Fan Out primitive to fire its output terminal for each element returned from
the XPath expression /body/myMessage/values.
Listing 3. XML representation message contents
<body>
<myMessage>
<values>A</values>
<values>B</values>
<values>C</values>
</myMessage>
</body>
|
At runtime, the primitive fires the output terminal three times. The first
time, the message contains value A in the FanOut context along with the
original message. The second time it contains B in the FanOut context. And
the third time it contains the value C. The FanOut context is a
specialized area in the SMO for storing such values.
You can also combine the Fan Out primitive with a Fan In primitive to perform
aggregation of messages. There's a new context area, called the Shared Context, within the SMO
specifically for the Fan Out and Fan In primitives.
You can configure this Shared Context area with user-defined business object
definitions. This context area is important when you consider the following
scenario, which
illustrates a particular aggregation scenario using a combination of Fan Out, Fan
In, and Service Invoke primitives.
Scenario: An order application mediation module needs to enrich an order document with
additional information before propagating it onto the order processing service.
Figure 19 illustrates a mediation module that calls out to two services to get
the additional customer and part information required by the target service.
Figure 19. Aggregation scenario
using the Fan Out, Fan In, and Service Invoke primitives
The Fan Out mediation is configured in this instance to fire its output terminal
only once. The out terminal is wired to three flow paths: Two contain an
XSLT used to create the request message for the target service, a Service Invoke
that invokes the target service, and another XSLT that maps the target service
response message into the shared context. The third code path contains only one
XSLT primitive, called SaveOrderDoc, which places the incoming order message into
the Shared Context for later retrieval. The Fan In primitive is configured to fire
the out terminal when all three messages are received on its in terminal. When
all the messages have been received by the Fan In primitive, an XSLT uses the data
in Shared Context information to augment the order document with additional
customer and part information required by the final order processing service. You
can also configure the
Fan In primitive to fire its incomplete terminal if all
three messages aren't received within a specified time.
|
Summary
This article provided a technical introduction to some of the new features in
WebSphere Enterprise Service Bus V6.1. You should be familiar with enhancements to the installation and
configuration wizards, additional protocol transport binding for exports and
imports, additional data bindings, and several new and enhanced
mediation primitives.
Resources Learn
Get products and technologies
- Innovate your next development project with
IBM trial software, available for download or on DVD.
Discuss
About the author  | 
| | Amanda Watkinson is a software engineer and has worked on a number of WebSphere
products with expertise in WebSphere Application Server, WebSphere Enterprise
Service Bus, and WebSphere Integration Developer. |
Rate this page
| 
