![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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.
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
TargetFunctionNameto 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
getQuoteoperation 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
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.
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.
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.
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.
Learn
- Learn more about
IBM WebSphere Enterprise Service Bus.
- Get more information about
IBM WebSphere
Integration Developer.
- Learn more about
IBM WebSphere
Transformation Extender.
- The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services
applications.
- Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- Stay current with developerWorks technical events and webcasts.
- Browse for books on these and other technical topics at the
Safari bookstore.
- Check out a quick Web services on demand demo.
Get products and technologies
- Innovate your next development project with
IBM trial software, available for download or on DVD.
Discuss
- Get involved in the developerWorks community
by participating in developerWorks blogs.
Table of contents
Next steps from IBM
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
