These days, "Enterprise Service Bus" (ESB) is a widely discussed and frequently explained term, representing a crucial piece of infrastructure used by enterprises when building solutions based on a Service Oriented Architecture (SOA). In short, an ESB offers capabilities to connect new and existing software applications within and across enterprises, with a rich set of features enabling management and monitoring of interactions between applications.
IBM WebSphere Application Server V6 introduces a new messaging engine that includes many of the functional features needed to construct an Enterprise Service Bus. The architectural aspects of ESB and SOA are covered in a variety of resources (see Resources). Instead, we will focus on the practical application of this new technology, how to use the Messaging Resources feature to build a particular instance of an ESB.
There are additional features beyond Messaging Resources in WebSphere Application Server V6 (such as EJB clients or JMX MBeans) that can contribute to building an ESB. We will not cover these in this series of articles. There are also other IBM software products, including WebSphere products, which are frequently used to construct ESBs with some of the same features -- and with functionality beyond that provided by WebSphere V6 Messaging Resources.
This being the first article in the series, we will begin with an introduction of the new messaging engine and briefly cover the main functional features it offers. In subsequent articles, we will dive deeper into each feature and demonstrate how that feature contributes to a complete ESB scenario.
What is WebSphere V6 Messaging Resources?
WebSphere Application Server V6 has a completely new messaging engine written in Java™. From a J2EE™ perspective, this engine serves as the default JMS provider for the application server. This means that any application component taking advantage of J2EE messaging (for example, message-driven beans) can take advantage of this engine. Other JMS providers continue to be supported including WebSphere MQ. In our ESB scenario, we will use WebSphere MQ and WebSphere V6 Messaging Resources together to provide the ESB functionality.
WebSphere V6 Messaging Resources also provides a consolidation of support for queuing, pub/sub, and Web services, and in so doing provides a platform for several key messaging and interaction patterns. For example, both synchronous request/response messaging and asynchronous one-way messaging are supported. This establishes the notion of an "integration bus"; message producers and consumers communicate by interacting with the bus, not directly with each other. This level of indirection enabls centralization of management and monitoring functions in one local entity without affecting application components. We will get into this aspect in more detail below.
A key feature of the new platform is the ability to use a variety of protocols to send and receive messages to and from the bus. For example, a message can be sent into the bus as a Web services request message based on the SOAP protocol over HTTP. The bus can then forward this message to a JMS consumer, such as a message-driven bean. As another example, you can send a message to the bus via WebSphere MQ and forward it to an EJB as a regular EJB method invocation. Consumers and producers of messages are hence completely decoupled, including the message and transport protocols. This decoupling is a core benefit of an ESB.
Support for various protocols is provided and format conversion for those protocols is supported through use of a common message representation, into which messages are converted as they flow through the bus. However, additional transformation is frequently needed both at the protocol and application levels. For example, the consumer may call the order number PO_NUM and the provider may call it PurchaseOrderNumber and so a custom transform must be written to provide that conversion. Messaging Resources provides support for you to write your own transforms and other custom bus functions.
Three core components: bus, destination, and mediation
At its core, the messaging engine consists of three main components:
- The bus serves as the main transport mechanism for messages. As described earlier, message consumers and producers do not exchange messages directly; they send and receive messages from the bus. Applications act as if they are interacting with a single bus entity when, in fact, the bus may be distributed on many processors and machines, which provides scalability (more on that later). Administrators can also configure several bus instances for separate applications.
- Each bus contains a list of destinations. A destination is the logical target for each message that is sent to the bus. You can think of destinations as a generalization of a queue and topic. This is how the sender and receiver(s) of messages are separated: a message is sent to a destination, from where a receiver (consumer) will pick it up. Of course, a message can be consumed by multiple receivers in a pub/sub scenario.
WebSphere V6 Messaging Resources provides robust, flexible messaging support which includes the ability to set different qualities of service on different destinations, such as setting a persistence policy on a message.
Importantly, a message can also be routed from one destination to another before being consumed by a receiver. This enables encapsulating any message routing logic into the bus without affecting the sender or receiver. This functionality enables you to implement one of the key characteristics of an SOA-based ESB: separation of concerns. The handling (or routing) of a message is managed by the bus and does not clutter any business logic.
- The third component, mediations, contributes to the separation of concerns. A mediation is a piece of code which is always associated with a destination. Mediation code operates on a message as it traverses that destination. A programming model based on a common Java representation of the message is provided for writing mediations; Java objects represent the message and its properties.
When talking about a common Java representation of a message, this commonality lies in the format of the message, not a transformation to a common data model for the message content itself; that is, a common way to get the length of the message, but not, for example, the PO_Number tag. This common model is explained in further detail below.
The two most common functions in a mediation are:
- Transforming the message data from one message content format to another. This is especially important if the sender and the receiver of a message do not support exactly the same message format. A mediation can be written to perform the necessary transformation using, for example, an XSLT stylesheet.
- Making routing decisions. A mediation could read the content of a message and, based on this content, route the message to different destinations.
Mediations can be developed from scratch simply by writing Java code, or they can be assembled from existing mediations into handler lists. In upcoming articles in this series, we will show how you can develop your own mediations, provide example mediations, and show how to compose handler lists. The combination of destinations and mediations let you manage a message as it travels across the integration bus, thereby providing key functionality for building an ESB.
Figure 1 shows the basic concept of destination and mediation.
Figure 1. Destination and mediation
Much of the literature on Enterprise Service Bus and Service Oriented Architecture focuses on Web services. Web services are a widely adopted, key technology for SOA, largely due to their platform and programming language independence. Web services have already become a first class citizen in the J2EE world, particularly with the advent of Java APIs for Web services in J2EE Version 1.4 (supported by WebSphere Application Server V6).
At its core, Web services technology is all about exchanging messages between applications, so it makes sense for WebSphere V6 Messaging Resources to have first class support for Web services. A message sender can simply be a Web services client/requester, and a message consumer can be a Web service provider.
The WebSphere V6 Messaging Resources support in the WebSphere Application Server administration console has wizards to consume a Web Services Description Language (WSDL) file for a service and generate artifacts (specialized listeners and destinations) in the bus. These wizards can receive Web service messages from Web services requesters and/or send Web service messages to Web service providers.
SOAP over HTTP and SOAP over JMS Web services are supported. Destinations are used to represent the Web service client and provider in the bus. Mediations can operate on Web services messages. Therefore, WebSphere V6 Messaging Resources enables Web services messages to be managed and monitored, including dynamic routing and transformation, in the bus as just another message type.
Again, the goal here is to decouple the requester and the provider of a service, so that additional quality of services and management can be applied in the bus. Importantly, none of this has any impact on the programming model for Web services. The Web service in the bus may be invoked just like any other Web service from a variety of platforms. For example, you can still invoke a Web service via JAX-RPC. The change is that the SOAP request message will be sent to a destination on the bus, rather than directly to the service.
From a development perspective, the client does not know the difference. The only change required from the client is to change the URL address from the real service to the service destination in the bus. No changes are required by the service provider, and the service may be invoked via the bus or directly by a Web services client. The business logic in the service is not affected. Web services deployed to the bus through WSDL are not limited to J2EE services, and can be any WS-I compliant Web service on any platform.
If all this sounds rather abstract to you, don't worry. We will cover this topic in detail in a future article that will take you through all the necessary steps to make this work. Let it suffice to say that Web services are prime resources to be connected to the bus.
Multiple protocols, multiple APIs
Above, we explained that bus destinations serve as the main means to virtualize resources that are connected to the bus. This includes the ability to access those resources using multiple protocols and APIs; a message can be sent into the bus over one protocol and be available to its consumer via another protocol.
The process is all about decoupling and the separation of concerns. A client should not have to know where a resource is located, what protocol it responds to, and what API should be used to send a message to it. All these are handled by the bus. Configuring resources as (virtual) destinations on the bus makes this goal possible. Messages can be sent to a destination using SOAP over HTTP, or MQ or RMI over IIOP, just to name some of the possibilities. The same message can also be received by its consumer over any of those protocols, regardless of how it arrived in the bus. This value will be an important topic of discussion in future articles.
A common message format
Managing messages in a protocol-independent fashion in the bus requires a data representation format that is also protocol independent. For the WebSphere messaging engine, Service Data Objects (SDO) was chosen as such a format. (Describing SDO in detail is beyond the scope of this article, so please refer to the papers and articles that discuss the subject in the Resources section.)
Simply put, SDO describes a way to represent data in a way that is independent of its data source; for example, whether the data came from a Web service call or a JMS client. A set of Java APIs exist for accessing SDOs and an SDO model of a message is used to represent data about messages, such as length, format, header information, and so on. Each message that arrives in the bus is converted into a graph of SDO objects. Mediations in the bus use the SDO programming model to manipulate the data in the message.
This use of SDO is all about being protocol independent. The bus does not convert the message content (for example, XML tags) into a canonical data model; if canonicalization is needed, custom mediations can be written.
Application server + messaging = ESB?
The messaging functionality described in this article is shipped as part of WebSphere Application Server V6. Having this technology available in the application server results in a powerful combination of capabilities: you can build, compose, and host robust and scalable applications and services, as provided by the leading J2EE application server, and at the same time have access to advanced messaging technology that forms the core of any service-oriented architecture.
The new messaging engine takes full advantage of the clustering and load-balancing features of the application server. The integration bus is instantiated in "messaging engines" that can exist across multiple processes on the same machine, or be spread out over separate physical boxes. In other words, bus instances and message destinations are completely virtual, and can be scaled to serve extremely high transaction loads.
The installation and administration of the application server and messaging engine happen seamlessly in the same fashion. For example, you define and configure message destinations on a bus in the regular application server admin console. Furthermore, the message bus can take advantage of the underlying runtime for some of its internal components. For example, mediation is deployed into the engine in the form of a stateless session EJB. This automatically makes mediations transactional, scalable, and secure.
Finally, all of the tooling for both the messaging engine and the application server is commonly available. The Application Server Toolkit comes with the application server and delivers all of the tooling required to build, deploy, and debug J2EE and messaging solutions. Rational® Application Developer V6 also offers a large set of tools for application development, including tools for Web services, J2EE, XML development, database, UML visualization, and many more.
This article provided a high level description of the new messaging engine in WebSphere Application Server V6 and the Enterprise Service Bus. WebSphere V6 Messaging Resources is based on three core components: the integration bus, destinations as a means to virtualize resources connected to the bus, and mediations that can route and manipulate messages flowing across the bus. In Part 2 of this series, we will show you how to get started with a simple scenario, setting up a bus and a destination, and using JMS to connect to the bus. Stay tuned.
- IBM Web site for Enterprise Service Bus
- IBM Web site for SOA and Web Services
- Article: Service-oriented modeling and architecture
- Article: Web Services Architectures and Best Practices
- Reference collection for Service Data Objects
- Article: Introduction to Service Data Objects
- Redbook: Patterns: Service-Oriented Architecture and Web Services
- Redbook: Patterns: Implementing an SOA using an Enterprise Service Bus
- Redpaper: Patterns: Using Business Service Choreography In Conjunction With An Enterprise Service Bus
- Resource: The WebSphere Application Server Version 6.0 Information Center
- Redpaper: WebSphere Application Server V6 Technical Overview
- Get involved in the developerWorks community by participating in developerWorks blogs.
- Browse for books on these and other technical topics.
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.