Introduction

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® InterChange Server V4.2.

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 InterChange Server 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 incorporate some level of ESB capability coupled with process integration capability. WebSphere InterChange Server implements both Process Services and ESB functionality. For example, inherent in WebSphere InterChange Server is MQ or HTTP protocol support (using the WebSphere Business Integration Adapter for Web Services).

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 InterChange Server 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 is required to manage the interactions with backend packaged applications, such as Siebel and SAP. These interactions are complex and form part of the service implementations. The implementation may include the use of IBM pre-built collaborations for WebSphere InterChange Server, which are provided as services on the bus. However, the IBM Business Integration Reference Architecture places such logic in the Process Services component, a view supported by the advice given in the Redbook. It is a decision which must be made when defining the architecture as to what business logic, if any, should be implemented in the ESB.
5. 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 InterChange Server can execute flow logic without managing business state.

It should be noted that the primary focus of WebSphere InterChange Server 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. If you decide to adopt WebSphere InterChange Server for ESB implementation then you should ensure that the approach taken is in line with IBM's product strategy.

There is an 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 InterChange Server requires careful collaboration design. Collaborations which implement process flow logic must be separated from mediation logic. Mediation logic is implemented using a combination of collaborations and maps. Typically the collaboration templates for process flow logic and mediation logic will be tightly bound together at design time to form collaboration groups using the native interface provided by WebSphere InterChange Server, represented by a business object. However, it is also possible to provide the logic of each through standards-based interfaces so that use by or access to other technology components is possible. For example, the WebSphere Business Integration Adapter for Web Services can be used. This loose-coupling approach allows the deployment of multiple WebSphere InterChange Server instances. One instance may execute 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 categorizes 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 InterChange Server v4.2.

Table 2. Capability mapping summary

Back to top

Assessment of ESB capabilities for WebSphere InterChange Server v4.2

Here are the capabilities of WebSphere InterChange Server V4.2 with the WebSphere Business Integration Adapter for Web Services (which includes the SOAP Data Handler) as they relate to an ESB.

Communication

• Event-driven processing (using WebSphere Business Integration Adapters).
• Messages can be routed using collaboration object subscriptions to events on business objects, collaboration logic, and mapping logic.
• Support for document and RPC styles.
• JMS (including JNDI support), HTTP and HTTPS protocol support.
• Synchronous and asynchronous delivery support.

Service interaction

• WebSphere InterChange Server does not inherently force a single interface for services it provides. There must be a policy decision to define service interfaces as SOAP over HTTP, for example.
• Using application-specific business objects at the service interface and mapping them to generic business objects allows the interface to be changed -- WebSphere Business Integration Adapters and maps -- without affecting the collaboration logic.
• Collaboration and mapping logic can be changed without affecting service requesters.
• Changes to service provider implementations do not affect the collaboration logic or service calls.
• WSDL can be used to generate business objects.
• SOAP messages, including faults, are supported using the SOAP Data Handler.

Integration

• All of the WebSphere Business Integration Adapters can be used to provide bi-directional connectivity to many applications and technologies, including databases.
• There is protocol support for JMS and HTTP using the WebSphere Business Integration Adapters, and therefore protocol conversion.
• Data enrichment using mapping and collaboration logic.
• Service aggregation can be implemented using collaboration logic.

Service level

• WebSphere InterChange Server and Java-based WebSphere Business Integration Adapters are multi-threaded.
• Multiple instances of WebSphere InterChange Server can be deployed and a high availability model is provided.

Quality of service

• Events are persisted while being processed by the WebSphere InterChange Server. WebSphere MQ can be used as the "internal" transport mechanism.
• The collaboration engine provides a compensation model.
• Support of JMS implemented with WebSphere MQ and WebSphere MQ access using a WebSphere Business Integration Adapter allows assured delivery.
• WebSphere Business Integration Adapters can be configured in store-and-forward mode. In this case, the Connector Controller component blocks requests to the agent component if it is unavailable. Once the agent becomes operational the controller will forward the requests.

Security

• A collaboration can make a service call to an LDAP directory for authentication and authorization using an LDAP Adapter available as a WebSphere Business Integration Accelerator SupportPac.
• HTTPS for transport security using JSSE in the Adapter.
• Username and password access to HTTP proxy server when making service requests.

Message processing

• The SOAP Data Handler supports encoding for parts defined using types, although the message parts must be in the order defined in the WSDL when using document style.
• Content-based logic can be defined in maps and collaborations. This can include identifying appropriate service provider(s) based on incoming message content.
• Message and data transformations are performed in maps. Validation can be performed in maps and collaborations.

Management and autonomic

• Services implemented in a collaboration can be registered in a directory, such a UDDI.
• Logging can be performed in a collaboration using either a probe or a service call (to a database, for example).
• Administration, management, and monitoring facilities are available.
• An Object Activation Daemon is available with WebSphere Business Adapters and can be configured to automatically attempt to restart an adapter agent following abnormal shutdown.

Modelling

• WebSphere InterChange Server provides a common business object model for business entities.
• Business objects (including data formats) can be generated from WSDL using the Object Discovery Agent which is provided with the WebSphere Business Integration Adapter for Web Services. This supports rpc literal, rpc encoded, and document literal styles.
• Relationships can be configured for cross-referencing primary keys between endpoints.
• Development and deployment tooling is provided.

Infrastructure intelligence

• Collaboration and map processing can be adapted according to business rules using Activity Diagrams. Java may also be used.

Back to top

Conclusion

This article has provided an understanding of the Enterprise Service Bus capabilities of WebSphere InterChange Server. 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 Martin Keen, Amit Acharya, Susan Bishop, Alan Hopkins, Sven Milinski, Rick Robinson, Mark Tomlinson, Andy Garratt, Kareem Yusuf and Jonathan Adams.

Resources

• See WebSphere InterChange Server on the IBM Internet for product description and documentation.
  
  
• See WebSphere Business Integration Adapter for Web Services 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.
  
  

About the author

Chris Nott is a Consulting IT Specialist with IBM Software Group in the UK. He has fourteen years of IT experience in software development, technical pre-sales consulting and solution architecture. His current area of expertise is business integration and he has a strong background in relational systems design and database technology. He has written extensively on business integration and the Enterprise Service Bus. He holds a BSc degree in Mathematics from the University of Durham and is registered in the UK as a Chartered Engineer.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Current IBM Technology and the ESB
• Enterprise Service Bus capabilities
• Summary of capability mapping
• Assessment of ESB capabilities for WebSphere InterChange Server v4.2
• 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