RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Implementing an Enterprise Service Bus in Java

Using the open source Mule project, you can build a highly customized Enterprise Service Bus (ESB) that meets your specific needs.


ntegrating old and new components and services using a service-oriented architecture (SOA) requires an infrastructure that can connect any component or service, regardless of location, messaging protocol, and message format. To orchestrate existing services and components via this infrastructure, you must be able to customize it extensively. An SOA infrastructure that fulfills these requirements is called an "enterprise service bus (ESB)."

This article discusses the mechanisms used by an ESB to facilitate cross-protocol messaging, message transformation, message security, service invocation, and other necessary requirements of a service-oriented messaging infrastructure.

The Enterprise Service Bus
An enterprise service bus (ESB) is a centralized, scalable, fault-tolerant, service-messaging framework that:

  • Provides a transparent means for communicating with heterogeneous services over a diverse set of message protocols.
  • Provides a shared messaging layer by which enterprise applications, services, and components can connect and communicate.
  • Can transmit messages synchronously or asynchronously to service endpoints and intelligently transform and secure the message content to meet the requirements of each service endpoint.
  • Should provide sophisticated error recovery, allowing for failed message delivery, scalability problems, duplicate messages, network failure, etc.
Minimum Requirements of ESB Message Delivery
The minimum capability requirements of an ESB as a message delivery system can be remembered using the acronym "TRANS," which defines an ESB as a software entity that:

  • Transforms messages from one format to another to accommodate the requirements of registered service providers
  • Routes messages to registered services while providing defined Quality-of-Service (QoS) 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 of specific message requests
  • Secures delivery of messages by enforcing authentication, authorization, non-repudiation, confidentiality, etc.
Transforming ESB Messages
An ESB must be able to transform data into a common data format to enable effective communication between disparate applications, components, and services. Data-format transformation can be simple or very complex; therefore the transformation facilities offered by an ESB should be both pluggable and configurable. An example of ESB transformation is applying an XSLT document defined by the receiving service's schema against the requester's XML message content.

Routing ESB Messages
An ESB should be able to determine the destination of a given message based on a number of factors—including the content of the message. This provides the flexibility to route messages to heterogeneous services without coupling the routing logic with the message structure.

Some of the mechanisms used for ESB message routing are:

  • XML-based content routing.
  • Proprietary object-based routing, such as that used by JMS.
  • External routing, where message routing is configured externally, and is therefore disconnected from the message content.
Notifying Message Listeners
An ESB should provide message-based listening capabilities to enable secured management of the message traffic and content.

Securing Message Delivery
An ESB should provide security for each message-request, including authentication, authorization, non-repudiation, confidentiality, and enforcement of security standards such as Kerberos and WS-Security.

The Decentralized Nature of an ESB
An ESB should be designed modularly, around a decentralized model to be able to scale effectively to meet any messaging demands placed on it. The decentralized nature of an ESB is realized in multiple interconnected runtime engines. Each runtime engine is responsible for handling the minimum capabilities defined by TRANS.

Interconnected runtime engines allow applications to interact with the ESB as if it were a single entity, even though it may be distributed across many networks and machines

Each runtime engine consists of:

  • An administrator.
  • A destination-based list of mediators.
  • A namespace directory.
Figure 1. ESB Components: The figure shows a high-level view of the relationships and interactions between the components of an ESB.
ESB Administration
Each runtime engine retains an administrator that handles management functionality such as service provisioning, service registration, service discovery, message logging, metering, and monitoring.

Mediation of ESB Messages
Each runtime engine also retains a list of mediators; each mediator is always associated on a one-to-one basis with a destination. A mediator is responsible for acting upon (transforming, augmenting, and securing) a message before it reaches its destination. After transforming, augmenting, and securing each message, the mediator routes the message to the destination.

Figure 1 illustrates a high-level view of the relationships and interactions between components of an ESB.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date