![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
The first five installments of this series covered several basic scenarios that showed how to take advantage of an Enterprise Service Bus (ESB) in a real life business environment, with a set of examples illustrating how those scenarios could be implemented using the IBM WebSphere ESB product. In this final article, we will summarize what we have accomplished with our fictitious Posts-R-Us company, and then point out areas in the ESB space that you might want to focus on next. Some of these areas are already covered in other articles, others will be addressed by articles yet to come, and all of them might influence where the product will go in the future.
The examples and scenarios we described in these articles were all based on the fictional Posts-R-Us company, which has a heterogeneous set of existing systems and solutions for the various parts of its business, and was looking to improve the accessibility, connectivity, and integration of these systems. The company decided to use the architectural pattern of an Enterprise Service Bus to achieve these goals, and thus take the first steps toward establishing a Service Oriented Architecture (SOA).
While Posts-R-Us is not a real company, we do see many cases in our real life projects that are quite similar. Existing business functions and business processes are increasingly represented by a service layer that is realized through an ESB so that the investment in these solutions can be preserved. At the very minimum, the ESB must offer support for a set of network protocols and be able to convert messages as they flow through the system. These are exactly the types of scenarios that we have included in our articles, and we have shown how they can easily be implemented by using WebSphere ESB.
Part 1 described the basic functionality of the ESB and positioned the functionality of the new WebSphere ESB product against its predecessor, the SIBus feature in IBM WebSphere Application Server. WebSphere ESB's additional features include better tooling (WebSphere Integration Developer) and a new service-oriented programming model (Service Component Architecture, or SCA).
Part 2 presented a basic, but powerful, scenario: inserting the ESB between a JMS-based service requester and a JMS-based service provider, represented by a message-driven bean (MDB). This decoupling of the requester and the provider creates a degree of independence between the two, from both a message format perspective and from a network protocol perspective. In other words, the message can be changed as it flows through the ESB, transparent to both requester and provider. Moreover, even though both requester and provider use JMS as the transport protocol in this case, one of them could switch to a different protocol without affecting the other. The interaction we built in this example was "one-way," meaning the request message was sent asynchronously without any response.
Part 3 introduced WebSphere ESB's support for Web services. Mediations in WebSphere ESB are service components following the SCA standard, and thus can be accessed as Web services. In turn, a mediation component can invoke external service providers through a Web services interface. As in Part 2, the service requester and the service provider used the same protocol, namely SOAP/HTTP. The ESB merely served as a level of indirection between the two to decouple them. Part 3 also showed how the endpoint address of the service provider could be changed at run time using the WebSphere ESB administrative console. However, with the advent of the IBM WebSphere Services Registry and Repository product, much more sophisticated and robust ways of performing dynamic routing became available. (We'll come back to this subject later.)
Finally, Part 3 showed a very important feature of WebSphere ESB that also enables making changes to how a mediation behaves at run time: promoted properties. Each mediation primitive within a mediation flow component has a set of properties that can be "promoted" so that they can be changed at run time, via the admin console, and thus add dynamic behavior to the mediation. The interaction in this case was synchronous; the service requester sends a request message and blocks all messages until the appropriate response message is received.
After using JMS and SOAP/HTTP as the underlying protocols in the first couple of sample scenarios, Part 4 took advantage of the native WebSphere ESB support for WebSphere MQ, which was introduced with Version 6.0.2. The example in the article highlighted a really powerful feature of SCA: the ability to add additional protocol support to an existing mediation component without affecting the component itself, and without affecting any already existing requesters or providers. The JMS example from Part 2 was reused in Part 4 and simply added a new service provider. The request message was now not only sent via JMS to the JMS-based service provider, it was also forwarded via WebSphere MQ to a queue controlled by a remote MQ queue manager. The service requester and the mediation flow component itself did not change at all, hence no programming was involved.
Part 5 investigated a scenario in which we switched between protocols supported by the service requester and the service provider. Instead of adding a new service provider to the scenario, which we had done in Part 4, we added an additional service requester. In fact, we did it twice: we reused both the JMS scenario and the SOAP/HTTP scenario from previous installments, thus creating a complete mix of protocols and interaction styles for requesters and providers. For the asynchronous JMS example, we added a (synchronous) SOAP/HTTP service requester. For the (synchronous) SOAP/HTTP example, we added an (asynchronous) MQ-based service requester. And again, all of this was done without ever touching the mediation flow component itself, and without changing any of the existing code. Instead, we used the import and export support offered by the SCA, which can be developed through the assembly editor in WebSphere Integration Developer.
The scenarios covered in these articles primarily showed WebSphere ESB support for different protocols and exchange patterns. They covered how to set up a fairly basic mediation flow component that would process messages, and then focused on how to connect various types of service requesters and providers to it. Again, this is what we see many of our customers start with: connecting applications that use different protocols, and replacing existing point-to-point connections with an ESB that decouples them.
Let's now take a look at how you might extend your ESB using additional WebSphere ESB features. One obvious area you might explore further is the processing capabilities within the mediation flow component itself. While we simply logged messages that came through the ESB in our examples, there is much more that can be done.
One of the core functions of an ESB is to support the concept of "virtual services;" that is, the ESB appears to be the real service provider to the requester, but in reality it only supports a virtual interface and routes messages to the actual service provider. In our example scenarios, the location of this real provider was basically hardcoded into the mediation by associating the SCA import with a WSDL definition containing a specific endpoint URL.
A much more elegant and robust solution is to store the location of a service provider in an external registry, where the ESB can look it up at run time. This way, endpoint information (among other things, of course) can be managed centrally, as part of an overall SOA governance model. The WebSphere Services Registry and Repository product offers support for this, and, in fact, there is a developerWorks article that describes in detail how to integrate WebSphere ESB and WebSphere Services Registry and Repository.
A special case of dynamic routing is content-based routing. The difference is that the lookup happens based on criteria that can be found inside the message itself. For example, assume that a mediation in WebSphere ESB supports multiple different service providers. Moreover, its interface is so generic that it can be used by multiple different service requesters. In this case, the mediation would parse the incoming message and perform a lookup of the right service provider based on differentiating content of the message. In WebSphere ESB, this would most likely be accomplished with a custom mediation primitive that contains the logic to extract the message differentiator and feed it into the lookup primitive that determines the right provider. A developerWorks article about content-based routing shows a complete example. (By the way, this article is the first of a series of articles about advanced WebSphere ESB topics, so watch for future articles in this series.)
A further, even more elegant extension to this scenario is offered by the dynamic assembler component that is included in the IBM WebSphere Business Services Fabric product. The dynamic assembler, which is implemented as an independent SCA component, can select service endpoints based on the content and the context of the message. The context information is in the message header and can include things like the channel that a request was sent over, or the identity of the requester, and so on. See Resources for an article that describes a complete sample scenario.
Message aggregation and distribution
In all the scenarios we introduced, one service requester was invoking one service provider. There are cases, though, where there is a one-to-many relationship between the two. For example, a requester might send a request message, resulting in multiple request messages being sent to multiple service providers. The response messages coming back from these providers then have to be aggregated back into one consolidated response message that goes back to the requester. WebSphere ESB currently does not offer out-of-the-box support for those types of mediations, so you would need to leverage custom mediation primitives to do this. An approach that requires no programming uses JMS as the protocol for multiple service providers, and one-way interaction. In this case, the message can be sent to a JMS topic by the mediation, from which it can be picked up by multiple subscribers. By the way, utilizing publish/subscribe capabilities in the context of an ESB probably deserves an article all by itself.
The messages in our examples were all XML-based. Not much (if any) transformation was required to adapt a specific requester message format to a specific provider message format. In real life, however, this will be common requirement. The simplest case of transformation is when one XML format must be transformed into another XML format. WebSphere ESB offers the XSLT mediation primitive that simply executes an XSLT transformation on a message flowing through the mediation. The XSLT transformation can be built using tooling available in WebSphere Integration Developer, or any other XSLT authoring environment.
Some complex transformations cannot easily be done in XSLT. As soon as you have things like extremely large messages, recursive and repeating structures, the need to callout into Java™ (or other logic) during a transformation, and so on, a more sophisticated transformation engine is required. WebSphere Transformation Extender provides support for very complex transformations and offers an API that can be invoked from within a WebSphere ESB mediation flow component. Look for improved support for this type of integration in future product releases.
When talking about message transformation, you also need to look at how data is sent into a mediation flow component to begin with. As you probably know by now, each message is represented as a Service Message Object (SMO) within the mediation flow component. This enables primitives (custom or pre-built) to access the message in a uniform way, regardless of the protocol that was used to send it. For messages that come into the mediation via SOAP/HTTP, this is done automatically, since the runtime knows the structure of the message, and can thus map it into an SMO. For JMS or WebSphere MQ, this is not necessarily the case. The message can contain an XML document that maps to a BO, it can contain a serialized Java object, or it can contain just plain text, to name a few examples. WebSphere ESB has built-in support for the most common data formats, and support is available to write your own custom data binding. You can see an example for this in an earlier developerWorks article series. (The example shown in the referenced article was built using WebSphere ESB Version 6.0.1. Version 6.0.2 supports the shown message formats out-of-the-box.)
Other protocols and formats are usually supported by utilizing adapters, preferably one of the WebSphere Adapter products. For example, reading data from a flat file into a mediation module is made possible via the IBM WebSphere Adapter for Flat Files. The adapter is imported and connected to the mediation module using the Enterprise Discovery Service tooling in WebSphere Integration Developer. A developerWorks tutorial takes you through a complete and detailed example.
The situations described above all implicitly assume that building a WebSphere ESB mediation is the right way to solve the problem. However, that is not always the case. One example for when it is better to step outside of the ESB altogether is: business logic. The ESB focuses on connectivity and integration issues that are usually independent of the business problem that the involved services try to solve. Hence, if certain logic touches on the business specific aspects of a solution, it should typically be located elsewhere. In cases where the implementation of a service interface consists of an orchestration of other services, this service should be implemented as a business process using the BPEL language. A BPEL-based business process can be executed in WebSphere Process Server, which includes WebSphere ESB, and since any service orchestration also has connectivity aspects, both products will often run together. Service interactions that are modeled in BPEL are often redirected via the ESB to support decoupling and virtualization of those services. For a thorough analysis of what runs in the ESB -- and what doesn't! -- see Greg Flurry's great article on developerWorks.
In this final article, we tried to show that this series of articles about building an Enterprise Service Bus is not the entire answer; it merely provides a basic introduction to a more complex and interesting technology area. In this series, we covered basic connectivity between service requesters and service providers across a selection of commonly used protocols and message formats. The examples shown are all meant to be easily reproducible and should serve as a good way of familiarizing yourself with the WebSphere ESB product and its tooling.
Learn
-
Dynamic routing improvements in WebSphere Enterprise Service Bus V6.0.2
-
WebSphere Integration Developer and WebSphere ESB advanced topics, Part 1: Content-based service invocation and routing
-
Make composite business services adaptable with points of variability, Part 2: Using dynamic service mediation in WebSphere Business Services Fabric
-
Building a powerful, reliable SOA with JMS and WebSphere ESB, Part 1
-
Tutorial: Building an ESB mediation to transform delimited files to service invocations
-
Exploring the Enterprise Service Bus, Part 1: Discover how an ESB can help you meet the requirements for your SOA solution
Discuss
Rachel Reinitz is an IBM Distinguished Engineer with IBM Software Services for WebSphere and a member of the IBM Academy of Technology. She has built much of IBM’s internal and external intellectual capital and education on SOA, Enterprise Service Bus, and Web services. Rachel focuses on how to get started with SOA and ESB best practices. She consults with clients and ISVs on how SOA and ESB can be used to achieve their business and technical objectives. She is a frequent conference presenter and written many developerWorks articles on ESB and Web services. Rachel lives in the Bay Area in California, and enjoys hiking, socializing, and international travel.
Andre Tost works as a Senior Technical Staff Member in the Software Group's Enterprise Integration Solutions organization, where he helps IBM's customers establishing Service-Oriented Architectures. His special focus is on Web services technology. Before his current assignment, he spent ten years in various partner enablement, development and architecture roles in IBM software development, most recently for the WebSphere Business Development group. Originally from Germany, he now lives and works in Rochester, Minnesota. In his spare time, he likes to spend time with his family and play and watch soccer whenever possible.
