Overview

This article provides additional information to section 5.3 of IBM Redbook, Patterns: Implementing an SOA using an Enterprise Service Bus, SG24-6346 where the capabilities of an Enterprise Service Bus (ESB) are mapped against current IBM products. Specifically it describes the ESB capabilities in WebSphere Business Integration Server Foundation V5.1.

Back to top

Current IBM technology and the ESB

In IBM's Business Integration Reference Architecture shown in Figure 1, we can use the following products for implementing an ESB as part of a service-oriented architecture:

• WebSphere MQ
• Web Services Gateway (part of WebSphere Application Server Network Deployment)
• WebSphere Business Integration Event Broker
• WebSphere Business Integration Message Broker

In this reference architecture, WebSphere Business Integration Server Foundation can be used to implement Process Services, choreographing services provided on the ESB. We should recognize that this technology itself contains ESB capabilities. Indeed base ESB capabilities, such as protocol management, are required, and others such as transformation may also be provided. Therefore any Process Services technology should by definition provide some level of ESB capability coupled with process integration capability. WebSphere Business Integration Server Foundation implements both Process Services and ESB functionality. For example, in WebSphere Business Integration Server Foundation there is the inclusion of WebSphere MQ, WebSphere Business Integration Event Broker, and the Web Services Gateway.

The Redbook provides a detailed analysis of WebSphere MQ, WebSphere Business Integration Message Broker and Web Services Gateway against the ESB capabilities, and gives guidance on their use to implement an ESB. IBM recommends the use of these components for implementing an ESB today. However, as part of defining a solution architecture, organizations should consider the ESB capabilities of other IBM components.

It is worth bearing in mind that for certain solutions the ESB capabilities embedded in WebSphere Business Integration Server Foundation will prove sufficient for required purposes. These capabilities will be coupled with process integration functionality in an SOA. The reasons for this approach include the following:

1. An organization has limited resources and cannot afford to acquire the skills for both a process integration engine and a technology for an ESB. This includes the on going maintenance and support of the environment.
2. An organization's requirements can be met by a simpler infrastructure which may be achieved using a single technology. This would reduce operational resource requirements.
3. The ESB is being implemented in a small organization or division of an organization where a large software inventory is disproportionate to the number of services.
4. The ESB can contain flow logic as part of its mediations, though it does not typically contain business process logic or manage business state. Both of these are characteristics of the Process Services component. However WebSphere Business Integration Server Foundation can execute flow logic without managing business state.

It should be noted that the primary focus of WebSphere Business Integration Server Foundation is to provide solutions for the Process Services requirements. This article is not advocating the use of this product as an ESB implementation without very careful consideration. It simply provides the analysis of the product's capabilities against those of an ESB.

There is important architectural principle which must be applied when using a common technology for multiple architectural components, in this case the ESB and Process Services components. There must be a clean interface between the ESB mediations and the process flows defined, for example a WSDL definition. Therefore both process flows and mediation flows for the ESB will exist. Each will be independent of the other, accessed only through defined interfaces. If a clean interface is not architected and implemented between the components, then the benefits of using an ESB in an SOA will not be achieved, maintenance costs will soar and flexibility will be lost.

Adopting this principle in WebSphere Business Integration Server Foundation requires careful business process design. Business processes built for WebSphere Business Integration Server Foundation will use the Business Process Execution Language for Web Services (BPEL4WS) open standard. From its name alone, it is obvious that BPEL4WS can be used to model business process flow logic. BPEL4WS, and the IBM extensions of this standard, can also be applied to implement mediation logic. The business process flow and mediation logic should be carefully separated into distinct BPEL4WS processes. Each BPEL4WS process is described with a WSDL interface, and can be deployed with a Web service, EJB, or JMS binding. This allows loose coupling between the business flow logic and mediation logic. This loose coupling approach allows the deployment of multiple WebSphere Business Integration Server Foundation instances. One instance may execute business process flows while another executes mediation logic.

Back to top

Enterprise Service Bus capabilities

The following table from section 4.3 of IBM Redbook, Patterns: Implementing an SOA using An Enterprise Service Bus, SG24-6346 categorises the capabilities of the Enterprise Service Bus.

Table 1. Catagorization of ESB capabilities

Back to top

Summary of capability mapping

The following table summarizes the support for ESB capabilities in WebSphere Business Integration Server Foundation V5.1.

Table 2. Capability mapping summary

Back to top

Assessment of ESB capabilities for WebSphere Business Integration Server Foundation V5.1

Here are the capabilities of WebSphere Business Integration Server Foundation V5.1 as they relate to an ESB.

Communication

• Incoming requests can be routed to outgoing partner links.
• Support for communication using Web services SOAP over HTTP and SOAP over JMS, RMI over IIOP, Java, JMS.
• Support for event-based calls.
• Synchronous and asynchronous support for process and activity interfaces.

Service interaction

• A WSDL interface is defined for each BPEL4WS process, and each activity within a BPEL4WS process.
• Partner links are bound at deployment time, therefore service providers can be substituted without changing the process structure.
• Support provided for UDDI registries.

Integration

• Support for J2EE Connector Architecture resource adapters to connect to enterprise information systems such as CICS Transaction Server and IMS.
• Support for multiple transports, as defined by binding settings in WSDL definitions.
• Service aggregation can be achieved using parallel process paths and data mapping.

Service level

• Processes can contain multi-threaded, parallel execution paths.
• Multiple server instances can be scaled using standard WebSphere clustering techniques.

Quality of service

• Business process instances are persisted and can survive a server restart or failure.
• Business processes can leverage J2EE transaction support.
• Compensation can be used to compensate transactions that have already committed, or to compensate activities that cannot be rolled back due to their non-transactional nature.
• Support of JMS implemented with WebSphere MQ allows assured message delivery.

Security

• Standard WebSphere J2EE security support.
• Process-level authorization can be set, with roles resolved by a pluggable user registry.

Message processing

• XML message structures can be transformed using XSLT.
• Message and data structures can be transformed, aggregated, correlated and validated using Java code snippets.
• Elements in a data structure can be populated using an assign activity, if no data transformation is required.

Management and autonomic

• Business Process Web Client provides full administration of business process templates and instances.
• Process instances can be monitored in the Business Process Web Client, or using the Business Process Engine API.
• Server-related administration provided in the Administrative Console.
• Process interfaces can be registered in a directory, such a UDDI.
• Logging and tracing facilities provided.

Modelling

• Broad support for data formats, including SOAP.
• Development and deployment tooling is provided with WebSphere Studio Application Developer Integration Edition.

Infrastructure intelligence

• Business Rules Beans support allow business rules to be dynamically changed at runtime without modifying or redeploying a process.

Back to top

Conclusion

This article has provided an understanding of the Enterprise Service Bus capabilities of WebSphere Business Integration Server Foundation. It can be used by IT architects to help them construct solutions to business requirements in the context of a service-oriented architecture using current IBM WebSphere software.

Back to top

Acknowledgments

This article would not exist without the discussions the author has been involved in with the following people, all of whom contributed to the ideas and thinking behind it: Chris Nott, Jonathan Adams, Amit Acharya, Susan Bishop, Alan Hopkins, Sven Milinski, Rick Robinson, Mark Tomlinson, Kareem Yusuf, and Richard Johnson.

Resources

• See WebSphere Business Integration Server Foundation on the IBM Internet for product description and documentation.
  
  
• IBM Redbook Patterns: Implementing an SOA using an Enterprise Service Bus, SG24-6346 by Martin Keen, Amit Acharya, Susan Bishop, Alan Hopkins, Sven Milinski, Chris Nott, Rick Robinson, Jonathan Adams, Paul Verschueren defines the capabilities of an Enterprise Service Bus and describes implementation using Web Services Gateway V5.1 and WebSphere Business Integration Message Broker V5.
  
  
• See Enterprise Service Bus Capabilities of WebSphere InterChange Server V4.2 for similar information about Enterprise Service Bus Capabilities of WebSphere InterChange Server V4.2.
  
  

About the author

Martin Keen is an Advisory IT Specialist at the International Technical Support Organization, Raleigh Center. He writes extensively about WebSphere products, Patterns for e-business, and the Enterprise Service Bus. He also teaches IBM classes worldwide about WebSphere and business process management. Before joining the ITSO, Martin worked in the EMEA WebSphere Lab Services team in Hursley, UK. Martin holds a bachelor's degree in Computer Studies from Southampton Institute of Higher Education.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Overview
• Current IBM technology and the ESB
• Enterprise Service Bus capabilities
• Summary of capability mapping
• Assessment of ESB capabilities for WebSphere Business Integration Server Foundation V5.1
• Conclusion
• Acknowledgments
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers