ServiceMix as an enterprise service bus
Use ServiceMix 2.0 as a service-oriented message routing framework
SummaryBy J. Jeffrey Hanson
Integrating old and new components and services using a service-oriented architecture requires an infrastructure that can connect any component or service, regardless of location, messaging protocol, and message format. To orchestrate existing services and components to meet the needs of today's dynamic business climate, this infrastructure must be highly customizable. The enterprise service bus (ESB) infrastructure fulfills these requirements. In this article, Jeff Hanson introduces the concepts behind an ESB and discusses the mechanisms it uses to facilitate cross-protocol messaging, message transformation, message security, service invocation, and other requirements of a service-oriented messaging infrastructure. (2,800 words; December 12, 2005)
Printer-friendly version | 
Mail this to a friend
n enterprise service bus (ESB) is a centralized, logical, architectural component that operates in a distributed, heterogeneous environment to facilitate the requirements of a highly scalable, fault-tolerant, service-messaging framework. An ESB acts as an open and implementation-independent service messaging and interfacing model that isolates application code from the specifics of routing services and transport protocols, and allows substitution of service implementations as needed.
An ESB acts as a shared messaging layer for connecting applications and other services throughout an enterprise computing infrastructure. It supplements its core asynchronous messaging backbone with intelligent transformation and routing to ensure messages are passed reliably. Services participate in the ESB using either Web services messaging standards or Java Message Service (JMS). Originally defined by analysts at Gartner, ESB is increasingly seen as a core component in a service-oriented infrastructure.
In this article, I discuss the open source ESB ServiceMix and its relationship to the Java Business Integration specification.
Minimum requirements of ESB message delivery
The minimum requirements of an ESB, as a message delivery system, are often referred to by the acronym TRANS, which defines an ESB as a software entity that does the following:
- Transforms messages from one format to another to accommodate the requirements of registered service providers.
- Routes messages to registered services while providing quality-of-service and service-level features.
- Augments message content with information, such as additional metadata, about the message requester. Augments the message protocol to meet service provider requirements.
- Notifies registered message listeners about specific message requests.
- Secures delivery of messages by enforcing authentication, authorization, nonrepudiation, confidentiality, etc.
Introducing Java Business Integration (JBI)
The Java Business Integration (JBI) specification and API defines a platform for building enterprise-class ESBs using a pluggable, service-based design. JBI builds on the TRANS foundation with normalized messages and component-based interactions.
JBI is a specification and an API for a normalized messaging service along with a component framework and management model for deploying integration services such as routing engines, rule engines, and transformation services. A JBI-based design specifies a standards-based pluggable architecture with a JVM-based runtime component called the normalized message router (NMR).
The high-level interactions of JBI can be seen in Figure 1 below.
Figure 1. High-level view of JBI. Click on thumbnail to view full-sized image. |
JBI embodies a messaging model based on Web Services Description Language (WSDL) for easy mapping to Web services, HTTP, email, and JMS. JBI integrates with legacy systems, binary transports, document-oriented transports, and RPC (remote procedure call) systems.
Figure 1's binding components deal with protocol-oriented relationships and components. And service-engine components in JBI support content-based routing, orchestration, rules, transformations, custom augmentation, etc.
Normalized messages
JBI uses a "normalized" message—consisting of a payload, optional attachments, and metadata—for interaction between consumers and providers. Message normalization is the process of mapping context-specific data to a context-neutral abstraction to transport data in a standard format. All messages handled by the NMR are normalized.
A normalized message consists of three main parts:
- Message content, also referred to as "payload," which is an XML document that conforms to an abstract WSDL message type with no protocol encoding or formatting.
- Message properties or metadata that hold extra data associated with the message. This metadata can include security information, transaction-context information, component-specific information, etc. Message properties form the first part of what is referred to as the message context.
- Message attachments referenced by the payload, contained within a data handler used to manipulate the attachment's contents. Attachments can be non-XML data. Attachments form the second part of the message context.
Normalized message router
The JBI message exchange depends on the NMR to route message exchange objects between service consumers and providers. The NMR performs such message delivery with varying qualities of service, depending on application needs and the nature of the messages being delivered.
An NMR is not embodied by any concrete object. It is abstracted as a set of APIs, SPIs (service provider interfaces), and components. The NMR APIs include:
- JBI Message API
- JBI Service API
- JBI Message Exchange Factory API
- Service Description SPI
- Message Exchange Patterns API
- Endpoint Reference API
Delivery channels
A JBI delivery channel represents a bidirectional communication pipe used by binding components and service engines to transport messages across the NMR. The javax.jbi.messaging.DeliveryChannel interface forms the API contract between service consumers, service providers, and the NMR.
A service consumer uses its delivery channel to initiate service invocations, while a service provider uses its delivery channel to receive invocations. A component that functions as both consumer and provider uses the same delivery channel for both roles. Therefore implementations of DeliveryChannel must support concurrent use of a given instance from multiple threads.
Components
The JBI component framework provides a pluggable interface that allows binding components and service engines to interact with the JBI environment. The framework provides the interface to all of the JBI services.
JBI supports two kinds of components, service engines and binding components. Components interact with JBI in two ways:
- SPIs: Interfaces implemented by a binding or engine
- APIs: Interfaces exposed to bindings or engines by the framework
Service engines
Service engines are the business-logic components in a JBI system and can serve as service providers/consumers. Service engines orchestrate service consumption and requirements. Service engines can also provide services such as data transformation, sophisticated routing, and message coordination facilities.
Binding components
Binding components are used to send and receive messages across specific protocols and transports. They uncouple the JBI environment from protocol specifics by marshalling and unmarshalling messages to and from protocol-specific data formats, allowing the JBI environment to process only normalized messages.
Normalized message exchange
JBI's principal purpose is to route normalized message exchanges from one component to another. Messages are delivered in a normalized form.
Binding components must convert protocol/transport-specific messages to a normalized form. Binding components and service engines interact with the NMR via a delivery channel, which provides a bidirectional delivery mechanism for messages.
An external service consumer sends a service request across a specific protocol and transport to a binding component. The binding component converts the request to a normalized message. The binding component then creates a message packet called a message exchange (ME) and sends it across the binding component's delivery channel to the NMR for delivery to a service provider.
After receiving a message, the consuming service engine or binding component creates a normalized message, putting it into a new MessageExchange instance, and sends it to the target ServiceEndpoint instance. After accepting the ME, the ServiceEndpoint component de-normalizes the message into protocol and transport format, and sends the message along to the external service provider.
Service units
Component-specific artifacts deployed to an installed engine or binding are referred to as service units. Service units are grouped into an aggregate deployment file called a service assembly. This file includes a deployment descriptor that indicates the component into which each service unit is to be deployed.
Service units contain:
- Metadata: JBI descriptor for services consumed/produced
- Artifacts: Generally XML (possibly binary, whatever the target binding component or service engine needs)
Page 1 ServiceMix as an enterprise service bus
Page 2 Introducing ServiceMix
See JavaWorld Talkback on the last page of this article to post your comments and see how fellow readers reacted.
