Defining the ESB

Enterprise Service Bus helps you create, deploy, and orchestrate service components in distributed systems


July 27, 2007
URL:http://drdobbs.com/jvm/defining-the-esb/201200303


Eric is a DDJ contributing editor and consultant in New York. He has worked extensively in Java and C++ developing real-time trading and financial applications and is the author of Java Messaging. He can be contacted at [email protected].


The combination of low-cost computing, fast networks, and, of course, the Internet, has driven software beyond the boundaries of a single computer. Almost all of today's enterprise software applications are built and deployed as distributed components, which can be spread across computers, networks, and entire corporations. A single user request may interact with a global set of computers and networks, each owned by different companies around the globe, before a response is assembled and delivered back to the user.

This may be obvious. However, what is less obvious are the solutions to the challenges that distributed software development create. In this article, I guide you through a solution-set to these challenges, using a relatively new piece of software, called the "Enterprise Service Bus" (ESB).

The Distributed Software Challenges

When you design enterprise software with an architecture that includes decoupled components, you enable an iterative software development and deployment process which results in systems that grow efficiently, and scale economically. The cost of developing and maintaining the software is spread across time, and shared across organizations. As usage of the software grows, parts of the software deployment can grow with it. Figure 1 shows an enterprise software application that is deployed across a varied number of servers within separate organizations. Servers can be added, on demand, as usage grows, and can be limited to the areas of greater usage.

Figure 1: An enterprise application with distributed components is better positioned for growth, and enables resource sharing within and across organizations.

However, these advantages -- scalability, shared resources, and shared costs -- come with their own challenges, especially when the software is developed without a unified architecture. Some of these challenges are:

These challenges are amplified when some of the components are built by different development groups, or different organizations. Such disparate, and hence disjointed, systems usually require more effort, time, and money to deploy and maintain. Before examining possible solutions, let's look at these challenges a little more closely.

The Complexity Challenge

Complexity in distributed software systems comes in the form of touch-points, or lines of communication, between different pieces of the software. As components are spread out across computers and networks, dependencies are built between those components, computers, and networks. If a software component is moved to reside on a different computer, or if a computer is moved onto a different network, or if the network architecture is modified in any way, there may be a rippling affect across the associated distributed applications.

When these changes do occur, the result may be as subtle as unexplained application behavior, or as bad as a completely broken application. Care must be taken to reduce these types of dependencies, and to minimize the effects when changes are made.

The Security Challenge

When distributed components communicate over a network, there is a potential for that communication to be tapped into, or otherwise spoofed. The potential for trouble increases when this communication spans networks, organizations, and the Internet. Malicious software, or people, may snoop network activity to retrieve sensitive data, especially those involving financial transactions.

Standards and measures for security must be implemented at every leg of the distributed application, and it must be done consistently across all of the organizations that the application spans. This level of coordination can be a huge challenge within one organization, never mind other (possibly competitive) organizations.

The Reliability Challenge

Simply put, the more computers involved in processing a user request, the greater the chance a failure will occur. Redundancy and failover strategies must be put in place in all areas of the application, but this may be implemented differently depending on the part of the application in question. For example, each network component may be paired with a redundant component; web servers may be deployed in farms of hundreds or even thousands of servers; application servers may be clustered in smaller numbers of servers; and database systems may be replicated across datacenters.

By far the most challenging of the reliability issues will be those that involve software communication. It's vital that when a component makes a request to another component, the response should arrive accurately and in a timely manner. The proper mechanisms must be in place to ensure that messages are re-sent when they are lost, and that they arrive in the same form as when they were sent, even if they are sent over foreign or unreliable networks.

The ESB Solution

Fortunately, there are patterns and tools that can be used to manage, and even eliminate, the three challenges just discussed. Implementing patterns of reliable communication is the first step towards a robust distributed software system. Arguably, the most important part of a distributed software system is its communication infrastructure. It's therefore no coincidence that many of the advances in modern software architecture and development have centered on service-oriented architecture (SOA), enterprise messaging systems, and platform-neutral data structures and protocols. Examples of technologies in these areas are web services, the Java Message System (JMS), eXtensible Markup Language (XML), and the Simple Object Access Protocol (SOAP), respectively.

Smart people know that breaking a large problem into smaller pieces helps to solve the associated problem; the same principal applies to software. Therefore, the decomposition of software functionality into XML or SOAP-based web services is the second step towards a robust distributed software system. The resulting services can then be used together, in varying combinations, to solve even more problems than just the ones that inspired their creation.

Finally, the integration and proper orchestration of these services is the third step towards a robust distributed software system. Possessing, or having unlimited access to, any number of software services is useless if there is no reasonable way to aggregate them into a cohesive application. Patterns and standards for service integration and orchestration are a must.

So far I've identified three high-level patterns, or principals, that provide for robust distributed software: reliable communication; a service-oriented architecture; and service orchestration. Additionally, a tool is needed to enable these principals -- one that helps to reduce the complexity and costs associated with distributed software systems by implementing the three patterns just discussed. This tool is the Enterprise Service Bus. The ESB is both a tool and a software framework that helps you to create, deploy, and orchestrate (and communicate between) service components in a distributed system.

An enterprise service bus is a framework that consists of many capabilities from which you can pick and choose. You may decide to use only portions of the ESB feature-set (and to ignore others) perhaps out of necessity, or as a way of migrating existing software to it. The ESB can best be described as having these characteristics. It:

Serving as a visual summary, Figure 2 illustrates the issues and challenges I've discussed related to distributed-software development. Writing code to communicate over varying communication protocols directly with systems of differing architectures, and dealing with data in different formats, is costly and non-reusable.

Figure 2: Legacy distributed applications might contain custom code to communicate over various protocols, such as FTP, TCP/IP, UDP. EDI, and so on. With no standard data form, structure, or protocol, security and reliability needs to be built into each integration solution.

The cost of integrating new partner organizations may outweigh the benefits the partner may otherwise bring to the application, and more importantly, end-users.

Figure 3 is a revised version of Figure 2, but now with the ESB added along with the services it manages. With the ESB in the picture, you can begin to envision distributed application development and deployment differently. No longer are the communication lines between disparate systems hard-coded; you can orchestrate and aggregate services and applications in various ways, and change them, without modifying your code. This is a true paradigm shift compared to the classic client-server architecture in the previous diagram.

Figure 3: The enterprise service bus helps to eliminate the often duplicated work that goes into building reliable, secure, and expandable SOA-based distributed applications. It also helps you and your partners to cost-effectively integrate applications and services.

With the ESB, adapters connect disparate software, enterprise messaging systems can be leveraged, and services can be integrated without writing a single line of associated code. This lets you focus on the construction of services and their associated business logic and not on the costly chores that go into building a robust distributed system -- the ESB eliminates them. That solves the complexity issue.

The ESB provides authentication and authorization services, as well as secure channels for component communication, thus solving most security issues. It has the added benefit of ensuring that security is implemented consistently across all services and components that use the ESB.

Furthermore, the ESB performs these services flawlessly, end to end, through its built-in reliable messaging backbone. Because of this, reliability is virtually guaranteed to components built on the ESB. Additionally, the messages themselves, and the act of sending those messages, are normalized. This means that regardless of the initial form of the data you are sending between systems, and the form of communication a particular system is designed to use, the ESB transforms those messages and adapt various protocols to work together.

Build on the ESB Foundation

The ESB can be used from within an application server, a lightweight framework, and even a standalone application. However, in practice, the ESB itself is not an application server, a messaging server, or a single piece of software that is installed and run on a piece of hardware. Instead, it's a framework and a set of tools that you can choose from to achieve distributed application development, integration, and deployment.

Of course, you get the most value from an ESB when you take advantage of all of its capabilities, but it's not necessary. You can migrate an existing system, or set of systems, to the ESB slowly over time using a phased approach if circumstances require. In fact, this is exactly how many corporations begin with the ESB, as illustrated in the case studies explored later in this article. The most benefit you will see from an ESB will be from the SOA standards and software design patterns that it enables you to follow when building distributed software.

Overall, the foundation of the ESB includes enterprise messaging, SOA standards, message transformation, and message routing services, upon which you can efficiently build robust, distributed applications. Let's begin by looking at how enterprise messaging is a critical piece of the ESB.

Build a Communications Infrastructure

The enterprise service bus evolved from the growing need for enterprise messaging systems and the integration of SOA-based software components. With distributed software, computer-to-computer communication is a top issue; the quality of communication quickly becomes a key differentiator, and can determine the software system's success or failure. In the past 10 years or so, as companies rushed to make their applications and services available over the Internet, much of this infrastructure was custom developed. Over time, as organizations deployed different messaging infrastructures and different platforms and protocols for their SOA-based systems, it became clear that standards would be needed to drive down the cost of integration.

Moreover, these standards need to account for platform and language independence. The adoption of standards further eliminates costs by enabling organizations to leverage their existing software systems and developer knowledge. It also lets developers focus on building software functionality, and not infrastructure, thereby easing the pain of distributed software development.

Communication Standards. There are many choices for application component communication, from the simple method call, to the robust, yet heavy and complicated, Common Object Request Broker (CORBA) infrastructure. In between, developers can use low-level network sockets, older communication protocols such as the FTP, modern protocols such as HTTP, hub-and-spoke architectures, email systems, and other platform-specific, proprietary, communication protocols (see Figure 4).

Figure 4: Simple method calls, network socket communication, and CORBA are examples of the different types of intra and inter application component communication.

Thanks in part to the growth of the Internet, and Web standards, three forms of messaging have become popular and standardized, at least in definition:

Topic-based messaging (shown in the top portion of Figure 5) is often referred to as "publish-and-subscribe" because components send messages to abstract topics, which other components subscribe to and receive.

Figure 5: Topic-based and queue-based messaging appear similar, yet they differ in message delivery semantics. Topic-based messages are received by all subscribers, while queue-based messages are each received by only one listener.

Each subscriber to a topic receives every message published to that topic (a multicast), without regard to the software that publishes the messages, or the other components that have also subscribed. In this sense, communication is anonymous -- publishers and subscribers don't need to know of one another's existence. It's important to note that messages published to a topic for which no subscribers exist are generally discarded.

Queue-based messaging (see the lower portion of Figure 5), sometimes called store-and-forward, is quite different than topic-based messaging, and more closely mirrors that of an email system. Messages are placed on a queue and delivered to only one receiver (not multicast). If there are no queue listeners when a message is sent, that message is stored and delivered when a listener becomes available.

Request-and-reply messaging (see Figure 6) is best described as the dialog that occurs between a web browser and a web server.

Figure 6: Request-reply messaging is the communication paradigm used on the World Wide Web

A request message is directed to a specific server, and a message is sent to that client in response, with the data to satisfy the request. This form of messaging is straightforward and obvious, but has some shortcomings. First, senders and receivers need to know of each other's existence, which builds hard-coded dependencies between them. Second, scalability and reliability become an issue, especially if one component in the request/reply sequence fails. In practice, request-reply messaging is usually implemented through either topic-based or queue-based messaging, where the message itself supplies a means to reply to the message sender.

Reliable Messaging Explained. Regardless of the communication paradigm you choose (topic or queue), it's important that it be reliable. When a message is sent, you must be guaranteed that it is received in the same form it was sent, or the integrity of your distributed software system is at risk. Enterprise messaging systems provide message delivery guarantees, as well as transactional support, most often with two-phase commit. This provides the ESB, along with the applications built on top of them, a level of built-in reliability required for mission-critical application. For software components developed for an ESB, there is generally nothing special that needs to be done to tap into this service. It's provided transparently by the ESB and the enterprise messaging backbone it itself is built upon.

Asynchronous Event Processing. Enterprise messaging systems, and the ESB, provide the capability for software components to send, listen for, and process messages asynchronously. This helps to decouple components in a distributed software system, further enabling system reliability and scalability. For instance, with asynchronous message processing, a component that sends messages to a queue does not need to wait for each message to be processed before sending the next one (see Figure 7). In contrast, the sequential (synchronous) processing of messages can lead to a semi-unresponsive system that would appear to behave "choppy" to users. Asynchronous messaging lets the sender component continue processing in parallel as its sent messages are received by other components, or stored for future retrieval.

Figure 7: Asynchronous messaging decouples the processing of the sender from that of the receiver(s), making for a more responsive, parallel-processing, system in general.

Of course there are also valid reasons to use synchronous message processing, such as with certain types of financial transactions, and with systems that require messages to be processed in a well-defined order. Because of this, the ESB provides both synchronous and asynchronous messaging support.

However, most distributed software systems benefit from the event-driven behavior asynchronous messaging provides. The obvious example is an email system: when you send an email message, you are free to send more email messages, even if the recipient has not yet read the first email you sent.

More importantly, the ESB brings the benefits of event-driven processing to the world of batch-processing systems, such as the many legacy applications used in banks and financial institutions across the globe. SOA alone may allow you to integrate a legacy system with a newer, web-based, application. However, with the features of an ESB, there are strategies you can employ to migrate a legacy system from batch processing, to semi real-time processing behavior, over time. In the modern world, where up-to-the-minute information is available on demand not only to institutional traders, but also to a bank's checking account customers, this feature has become a requirement. The ability to change a batch system to an event-driven system incrementally is another benefit of the ESB.

The Java Message System (JMS). Entire books have been written about JMS, message-oriented middleware (MOM) software, enterprise messaging, and enterprise application integration. Since the ESB helps to eliminate or at least hide many of the issues around messaging and integration, you really don't need to have more than a basic knowledge of JMS. However, it does help to have some exposure to JMS and its concepts, so let's go over it quickly now.

The Java Message Service (JMS) specification describes an enterprise messaging system for Java that supports both topic-based and queue-based messaging paradigms. JMS also specifies many types of message objects with the goal of interoperating with other, non-Java/JMS, messaging systems. With enterprise messaging -- and in particular, JMS -- you can build distributed software systems that are truly platform and language-independent.

In a nutshell, JMS is a specification [Hapner02] that describes the properties and behavior of an information pipe for Java software. It also describes how Java client applications interact with the information pipe. These are two very important distinctions that must be understood before implementing JMS software. They are named a JMS provider, and a JMS application, respectively:

The ESB is built directly on top of the JMS information pipe, and leverages everything that JMS has to offer. The remainder of the ESB functionality is layered on top of JMS in a way that its messaging features are abstracted nicely, but are still available for components to plug into directly, if there is a need to do so.

Integrate Service-Oriented Architectures

Reliable communication over JMS is important, but it's not the only communication protocol in use today. The global reach of the Web and HTTP, along with the data and platform-independent nature of XML, has given rise to a new paradigm for software development: the service-oriented architecture. This includes, more specifically, XML/SOAP-based web services that are becoming increasingly available over the Internet.

The proliferation of the Web and its related technologies, the adoption of broadband networks by both businesses and individuals, and the ever-decreasing cost of computer hardware, has helped to usher in the age of integration. Corporations partner with other corporations to share data and provide complimentary services; we send and receive email through a corporate server from handheld devices; and we stay connected to the systems and data we rely on even as we travel. The age of integration defines the interconnectivity of computers, and whole networks, which enable these solutions.

It has become increasingly useful to integrate available web services into existing applications, and to generate new applications from existing web services. After all, this is what SOA advocates have been promising all along. Organizations have discovered the benefits of using both internal web services (those developed and deployed within the organization) as well as external ones (those built and deployed by other organizations). Google is, perhaps, the most famous of those offering use of its intellectual property (web search, photo archives, mapping, and so on) through web services to be integrated into other organizations' applications.

Google's web services, along with Google's usage of advanced web technologies such as Ajax, have spawned an entire genre of web-based applications called Web 2.0. Part of the movement of Web 2.0 is the concept of mashups, which are web applications that use content from multiple sources (usually web services) to form a new application or service. The excitement of Web 2.0, the development and usage of web services, and the ever-increasing deployment of mashups, all prove that there is a lot to be gained through web service integration.

Though there are standards for web service development, discovery, and usage (such as SOAP, UDDI, and WSDL), there is still a lot of work to be performed in actually integrating the web service APIs and their content into a unified application. Web service orchestration, or the integration of web services and other components through rules-driven processes, is one way to solve this problem. The ESB supports web services through a SOAP adapter, and the use of Business Process Execution Language (BPEL) for orchestration.

Integrate Legacy Applications

Although the number of systems that support a SOAP interface is increasing, there are many more that don't. You're more than likely to come across other applications, ranging from standard Java, enterprise Java, .NET, and even IBM CICS applications, which you will need to integrate into a newer distributed application. For this reason, you may need to use the data transformation functionality provided by the ESB, a built-in adapter, a custom adapter, or a combination.

The ESB Adapter. An adapter is a relatively simple piece of software that wraps a component's interface, or transforms data, to interface with a different system. You can write this software yourself to, in effect, convert the software's interface into a web service or to be JMS-compliant. If the application uses enterprise Java or .NET, the tools used to build the system will more than likely be able to automate this process. This is assuming you have access to the component's source code or development tools. Even if you don't, you will more than likely be able to use the ESB's built-in adapters for these cases (see Figure 8)

IBM CICS now supports adding enterprise Java and web services interfaces to components built upon it. The adapter software will need to be run somewhere, and be interfaced to the ESB in some way. If the application supports a Java interface, the calling Java component can be developed and deployed as an enterprise Java application and integrated with the ESB's built-in JCA adapter, as in Figure 9.

Figure 9:

More often than not, data transformation adapters will be the way to go. In fact, this problem is so common that most ESB vendors provide tools to support various data transformations. Even if the ESB you choose does not support all of the transformations you require, the chances are high that you will be able to find other tools, often open-source, that can automate this process. Figure 10 is an example of how the ESB XML adapter can be used to accept transformed XML.

Figure 10: Data transformation may be the easiest way to adapt a legacy system, such as one that supports EDI, into the ESB architecture.

For other cases where a data transformation or a built-in solution is not possible, you may need to build a more complex, custom adapter. The custom code you write may need to interface with older applications such as COBOL (see Figure 11) or to transform older, proprietary, data formats, to XML.

Figure 11: A more involved custom adapter may need to be written to interface older applications, such is this one written in COBOL, with modern SOA-based applications that use an ESB.

The adapter pattern is straightforward in most cases, and will solve many of your ESB integration problems. There will be cases, however, where more subtle differences between integrated systems require something other than an adapter. For systems that comply with the ESB interface, yet whose messages do not match the standards for the rest of the system, the ESB message transformation capabilities may be used.

Message Transformation

As mentioned in the previous section, merely sending a message is not always enough. The components that need to receive that data will require it to be in a form that they can process. Many services will accept messages in the form of XML, but they may need that XML to conform to a particular XML schema. As more receiver components are plugged into an ESB-based deployment, the more potential data transformations will need to take place. Developing custom code to transform the same message to conform to a different XML schema for each client is inefficient and costly. Worse, there will be many components that send their data in JMS messages. In these cases, the data in the message will need to be converted to XML in general-never mind subsequent XML transformations that will need to occur-for XML-based receivers to process them.

Fortunately, the ESB provides built-in message transformation services to take care of this for you. In many cases, the ESB will normalize all message flow within its boundaries to be XML-compliant, regardless of the form the message data started in. This allows each listener component plugged into the ESB to specify a format for which it requires the data. In most cases, this format will be described with an XML Schema. In other cases, a component may request all message data be delivered as a JMS message. Either way, the ESB will perform the transformation for the listening component, without any specialized code required on the part of the sender or the receiver.

The net effect is that the receiver's view of the data is decoupled from the sender's view, the overall system's view, or that of any other receiver in the system. This message normalization and decoupling is the feature that begins to set the ESB apart from just another message-oriented middleware (MOM) product. Whereas typical MOM software, such as a JMS provider, will treat most messages as opaque, and not get involved in what they contain, the ESB gets intimate with the data.

Message normalization and transformation is a feature that will also save you a lot of development, testing, and maintenance effort. Because the ESB decouples both the message sender and receiver from the message format (and hence one another), the development of either component will not impact the other. Normalizing message formats doesn't just benefit message sender and receiver component developers; it enables the ESB to work with the messages; such as to route then effectively across the network and to the systems that require them. Message routing is the next part of the ESB foundation that we need to look at.

Message Routing

With the ESB, applications, services, and components do not interact directly. The ESB serves as an intermediary for communication and the routing of messages between components. This is an important advance, especially compared to how message exchanges work in the classic cases of web services or JMS. In both of those cases, message senders and receivers would have to find one another, and invoke each others services. (Perhaps this applies more to message receivers, but since many components are both senders and receivers, we'll look at it from both perspectives.)

The problem with this approach is that every component has some sense of awareness of the other. In most cases, this awareness is hard-coded within the component in a way that makes it difficult and expensive to change and redeploy. The system-wide dependencies that this model creates can quickly bring a system to a halt and put system administrators into a frenzy when parts of the distributed application are changed, even in minor ways. This is an obvious waste of time and money for system maintenance, as well as development, as developers must spend time implementing service lookups instead of implementing customer features.

The ESB separates service lookups from the components that require the services. Hence, developers spend less time implementing this code for every component in the system. This ESB feature is called message routing, and it has some additional benefits aside from the obvious savings of time and money. It allows you to define how messages and events can be chained together, resulting in abstract message flows (also know as workflows) that components can plug into at runtime dynamically -- no hard-coding required. We'll take a quick look at what a message flow is below.

Abstract Service Endpoints. The first part of message routing and workflow definition is to define an abstract service endpoint. A service endpoint is defined as a discrete operation [Chappell04] devoid of its implementation. A software architect or ESB administrator can choose a component to fulfill the role of the service endpoint. This component may be a web service, a Java EE application, or an adapter to a third-party application of unknown implementation. So long as it conforms to the service endpoint definition, the servicing component can be selected at runtime.

Service endpoints are abstract in the sense that you do not need to worry about how they're implemented, where they reside, or how they're plugged into the ESB. You simply know they exist based on their service definition, usually in the form of Web-Service Definition Language (WSDL), which is an XML-based standard for defining business logic operations in a SOA.

The definition of a message flow begins by chaining together various service endpoints (and hence the components that implement those services), applying any required message transformations, along with any rules for the overall workflow. The rules of the workflow can be defined in terms of the content within the messages, or they can be tied to a generalized workflow, also known as itinerary-based routing.

Content-based Routing. The act of routing messages based on content is generally implemented as script components deployed within the ESB. The script can be code in the form of JavaScript, or it can be in the form of Business Process Execution Language (BPEL) rules. The routing can be based on message validation to ensure that applicable messages contain the data they're supposed to, or that they conform to an expected message format.

The routing can also be based on more complex rules, such as decision points that are made based on the presence of certain fields or field values within a message. For instance, the presence of favorable data within a credit field of a message may lead to a trade between two counterparties in a trading system. In many cases, content-based routing may be all you need to properly define a workflow.

In reality, this may not be enough. The contents of a single message may not be complete enough to make all of the decisions required within a business process. There may be a chain of events that need to occur, and applied to one another, to complete a workflow. This is where itinerary-based routing comes into play.

Itinerary-based Routing. Itinerary-based message routing is based on pre-defined workflows, or step-by-step processing. This type of routing is similar to a Java Servlet filter chain, where the response from one Servlet becomes the input to the next Servlet in the chain, and so on. Whereas the Servlet chain is defined in a Java EE configuration file, the itinerary-based routing workflow is defined with routing rules in the ESB. The sequence diagram in Figure 12 illustrates an involved, but realistic, business process that occurs during a foreign exchange trade.

Figure 12: This itinerary-bases message routing example describes a workflow by which a foreign exchange trade may occur. Buy and Sell order messages are routed to the market manager component; trade notification messages are routed to all counterparties involved, and the ticket generator component is notified to distribute final trade tickets for auditing purposes.

First, a trader places a sell order for a particular currency pair (the two currencies to be traded). Some time later, another trader places a buy order for the same currency pair. According to the workflow, the Market Manager component is notified of all order entry requests. When it gets notified of both the buy and sell orders for the same currency pair, it checks for a potential trade. In this case, a trade does occur, and the Market Manager sends a trade notification message which is routed to the counterparties involved, including the Ticket Generator component. Finally, the Ticket Generator component generates a trade ticket message, which is also routed to the counterparties involved in the trade.

It's precisely the set of events, and the proper event ordering, that is described through message routing rules in an itinerary-based message workflow. Without hard-coding the workflow within the components themselves, the process can be modified by redefining the rules on-the-fly, without the need to change any code. For example, let's say we need to change this workflow to include the content-based routing rules for a credit check, as discussed in the previous section. A credit manager component can be deployed in the system, and the routing rules modified to include a credit check before a trade notification is sent. If the credit checks out, based on the data within the existing messages, the workflow will continue and a trade will occur. If the credit check does not pass, the workflow will stop and the trade will not occur.

This type of routing, and rules that describe it, is the beginning of a service orchestration model that the ESB enables. With service orchestration, seemingly unrelated sets of services and even entire applications can be choreographed to work together to define new business processes, and solve new problems.

Orchestration and Business Process Management

BPEL is an XML-based language specifically designed to describe and orchestrate asynchronous business processes. A business process is really nothing more than a piece of business logic (code) that performs some data-related task, but which is meant to be part of a larger set of processing. In other words, a business process is a relatively small data-crunching task that is meant to be chained with other business processes to perform an overall larger task. These tasks (their methods, inputs, and outputs) can be combined in meaningful ways with BPEL. Plugging SOAP-driven business process components into the ESB and controlling them with BPEL allows you to build reliable, distributed, systems with central orchestration and monitoring capabilities, as in Figure 13. Further, the ESB lets you dynamically change the orchestration of these business processes dynamically, while the system is running, without changing code or deploying new software.

Figure 13: Web services, deployed on the ESB, are integrated and orchestrated using BPEL, which can be managed and changed centrally

The distributed, asynchronous, nature of the ESB, combined with its support for SOAP and BPEL, provides a standard method for web service integration that is consistent and straightforward to implement and deploy. This powerful ESB feature allows you to create virtual edge servers, which are those that combine the data and operations from other services in order to make the resulting combination available to other applications. Best of all, the ESB lets you do this in a standard way.

Do I Need an ESB?

Hopefully, at this point, you've built a basic understanding of what an ESB is, and how it can be used. The next step is learning when (and how) to use an ESB. If you're building an application that consumes web services, communicates with remote software systems or components, requires reliable messaging and transaction services, or integrates with legacy applications, you will benefit greatly from the ESB. If you work with software that relies on particular communication protocols, interfacing techniques, or instrumentation, the ESB helps to abstract your application from these details. This adaptability ensures that as protocols and interfaces change, your application will be insulated from those changes.

Beginning with the material covered in this article, you should see how the ESB can help you, especially if you're developing software that uses any of the following:

The case studies discussed below intend to show you how other organizations have solved real-world problems with an ESB. You will see not only the problems that were solved, but also the added benefits that an ESB provided, and the factors that led to the decision to use an ESB in the first place. After that, I look at various commercial and open-source ESB offerings, and then explore a "Hello, world!" application that demonstrates how easy it is to get up and running with an ESB.

ESB Case Studies

To add proof to the claims of benefit, let's look at some companies (and their products) that achieved proven success from using an ESB. Below, you will see examples of how an ESB has helped companies large and small, across a wide range of applications, including financial services, partner service integration, order processing, enterprise resource management, and content-based information services.

Travel System Integration. To integrate with its partners, and to provide secure, reliable, transactions to its customers, LibGo Travel turned to the ESB. LibGo's system ties together outside systems and services from airlines, hotels, other travel agencies, with its own internal systems using an ESB and a built-in rules engine for workflow management. Instead of building a specialized interface for each of its partner's systems -- a development process that doesn't scale well -- LibGo decided to use an ESB and standardize on SOA-based technologies such as XML and SOAP. The result is a system that is less costly to integrate with partners and other third-party systems (Figure 14).

Figure 14: The LibGo composite application uses an ESB to integrate with its partners' systems, as well as other third-party software, using SOA-based standards such as XML, WSDL, and SOAP.

The application typically handles over 1 million transactions per day, and can easily scale upward as needed. With the ESB and the standards it implements, it's straightforward for new systems to be integrated, and more servers to be rolled out as needed. Furthermore, not all of the systems that LibGo interfaces with use HTTP web services. Some use FTP, email, even FAX reports. The ESB and its adapter layer normalize all message traffic as XML, and allow the disparate system to communicate in a reliable, secure, manner.

With the ESB, all of the integrated systems interface via XML standards, messages are guaranteed, distributed transactions are centrally coordinated, business processes are managed via a configurable rules engine, and security is implemented end-to-end. LibGo achieved all of this without requiring third-party providers to rewrite their software, or make any large-scale or costly changes.

Bank Account Management. Rabobank, faced with regulatory demands and increasing competition, turned to the ESB to expand its banking infrastructure, and to meet the growing needs of its customers. The ESB solved these problems by providing an infrastructure for a straight-through processing (STP) system that integrated into an existing network with existing software systems. The ESB enabled Rabobank to meet its number one requirement -- use open-standards to avoid vendor lock-in.

The use of standards meant that Rabobank could support diverse platforms and technologies, such as .NET, Java EE, and the various web servers and application servers that its partners and customers may already have rolled out in production. After the initial development effort to rollout the ESB framework, Rabobank and its partners are now able to integrate new applications and services with its core services in a matter of days.

The ESB has allowed Rabobank to focus on its core functionality, and not the technology required to build reliable, globally distributed systems. The needs of both the end users and partners are now the primary focus, and where most of the time and money are spent. Best of all, the ESB allows the core business processes to be easily modified to adapt to changing market conditions and customer needs.

Straight-through Processing/Order Processing. Stratus Technologies provides software, hardware, and services for ATM and credit card vendors, as well as securities and brokerage firms. In the past, Stratus would need develop new software and roll out new servers to integrate with a new partner's software. This process proved costly and troublesome; and with very little similarity between each implementation, there was not much chance for re-use.

Noticing the growing numbers of SOA implementations in the financial industry, Stratus used an ESB to redesign its antiquated order processing system. The ESB provides much needed integration points to systems from its vendors, customers, and shippers, and allows them to orchestrate all of the distributed business processes. Business processes are encoded as XML-based rules, and the ESB provides message transformation services to seamlessly integrate XML and non-XML data into the message flow, as in Figure 15.

Figure 15: Stratus broke its system down into eight core business processes that customers interface with using XML/WSDL. The ESB provides message transformation and business process management services to easily integrate third-party systems via standards.

The ESB helps to enforce interface standards and rules, providing error checking and notification when problems occur. It's estimated that the ESB has cut Status' costs by 60 percent when integrating new customers. Additionally, administrative staff can monitor and manage the system from anywhere on the network using only browser, providing a further savings of 70 percent in overall system maintenance costs.

Business Process Management. Xerox achieved cost savings in its core business processes, as well as time-to-market reduction in new system rollout, because they adopted an ESB. The strengths of the ESB allowed disparate databases across the organization to be integrated with new front-end systems repeatedly, without duplicating effort or costly custom coding.

The ESB implementation replaced a CORBA-based system of ever-increasing complexity and cost. The reliability provided by the ESB, along with its support for SOA standards, allowed Xerox to build and deploy its growing number of business applications efficiently, without sacrificing quality. The use of standards and ESB-provided adapters has decreased the amount of custom coding required for new application integration, and has saved an estimated $720,000 annually in development and maintenance costs.

Commercial and Open-source ESB

The main purpose of this article is to define what an ESB is, what it can do, and how you can use it to solve your real-world, distributed application problems in a less-costly, more time-efficient manner. Although the examples are presented through the use of open-source ESB implementations, there are commercial ESB solutions available that may better suit your software needs. I won't attempt to sway you to one side or the other here, but instead equip you with the knowledge you require to make this decision on your own. As you read along, your understanding of what an ESB is, along with your exposure to the various ESB software packages available as of this writing, will increase to give you a complete picture of the ESB industry.

I examine the various commercial and open-source ESB offerings currently available and, where necessary, contrast the differences between them.

Commercial Solutions

There are a growing number of ESB offerings available to companies that feel more comfortable purchasing commercial software and support agreements from a commercial software vendor. This section will provide a brief overview of some of the more popular commercial ESB offerings available, along with link to web sites to provide more information and trial downloads. This list is by no means comprehensive, and is subject to change as ESB vendors and their products come and go.

IBM WebSphere ESB. IBM has built the ESB concept into the heart of its middleware product, WebSphere, and offers two individual products to meet the different business needs for an ESB:

Sonic ESB. Sonic Software is a pioneer in the world of ESB software in helping to define it, and being one of the first vendors to sell one. Sonic ESB is a direct descendant of the SonicMQ JMS provider, which includes built-in dynamic message routing and advanced clustering for robust enterprise messaging applications.

SonicESB is part of an integrated product family that includes an orchestration server, a collaboration server, a specialized XML server, a database service, various built-in adapters, and an Eclipse IDE-based development toolset to build, test, and deploy components within SonicESB.

TIBCO BusinessWorks. Although TIBCO does not directly call its TIBCO BusinessWorks product an ESB, it does state that it has all of the features and characteristics of an ESB, such as XML and web service support. BusinessWorks contains a set of advanced tools that allow developers and administrators alike to visually configure services, data transformations, security, management, and perform real-time monitoring.

These features, combined with its Enterprise Message Service product, and its flagship Rendezvous JMS provider, amount to a solid, reliable, ESB product with flexibility so that you can more easily choose which features to purchase, use, and deploy with your application.

CapeClear. CapeClear offers a standalone version of its ESB, along with a version that integrates with WebSphere. This allows existing enterprise Java applications to migrate to an ESB within an application server environment; thereby reducing the amount of re-work that otherwise might need to be done.

Regardless of which version you use, the CapeClear ESB comes with an ESB server, a service orchestrator, an ESB manager for advanced management and configuration, an Eclipse IDE-based development toolset, and a service enablement tool that helps you quickly add a service interface onto existing applications.

iWay SoftwareiWay Software’s ESB specializes in integrating with applications written and deployed with other frameworks, such as .NET, IBM CICS, and BEA Tuxedo. iWay stresses interoperability, and provides tools to easily integrate your existing Java, non-Java, and mainframe-based applications as services into newer SOA-based applications. There’s even a tool that integrates the iWay ESB with the Google search appliance to search-enable your ESB-based applications.

BEA WebLogic / AquaLogic. The AquaLogic Service Bus is BEA’s ESB that integrates well with its enterprise Java application server, WebLogic, providing an easy migration path for existing enterprise Java applications. AquaLogic builds on BEA’s reputation for quality, robustness, management services, and developer s upport, as proven through its successful WebLogic application server offering. AquaLogic supports specialized tools to support legacy applications’ custom protocols, allowing them to seamlessly integrate into an ESB-based system.

Open Source Solutions

The number of open-source software packages has been growing consistently over the years. Just as importantly, the acceptance of open-source software within corporations has grown also. Organizations have become comfortable building their applications, and in some cases, their entire product strategies, on top of open-source software packages. The quintessential example of this phenomenon is the Linux OS.

It should come as no surprise that there is an abundance of open-source ESB packages available, each of which compare well in terms of features and quality to the commercial ESB offerings we’ve just discussed. In many cases, open-source ESB packages (as well as in other categories open-source software) evolve quicker than the commercial offerings as they have entire communities of developers and testers dedicated to improving them. Let’s explore some of the open-source ESB packages available today.

JBoss ESB. The JBoss ESB is an evolving ESB offering from a leader in open-source Java frameworks, application servers, and enterprise messaging systems. Although at the time of this writing the JBoss ESB is undergoing some changes, including the absorption of Rosetta ESB (which was another open-source ESB package), look for JBoss ESB to be a major player in the open-source ESB arena, especially as it is integrated as part of RedHat Linux.

Sun Microsystems Open-ESB. Sun Microsystem’s Open-ESB project is part of the overall Java Business Integration (JBI) effort that Sun put together to ensure that all ESBs conform to a set of standards, thereby eliminating vendor lock-in issues for ESB adopters. Open-ESB integrates with Sun’s open-source application server, named Glassfish, as well as its open-source NetBeans development environment.

Codehaus Mule. Codehaus Mule is a complete open-source ESB framework that supports all of the features of an ESB that this article has discussed so far. It integrates with existing application servers, lightweight frameworks, mainframe-based applications, web services, BPEL engines, and enterprise messaging software.

LogicBlaze ServiceMix. The ServiceMix ESB, supported by LogicBlaze, is an Apache incubator open-source ESB framework. ServiceMix is a lightweight ESB that works either as a standalone or embeddable server. It integrates with existing applications servers (it’s packaged with the Apache Geronimo open-source Java application server), lightweight frameworks such as Spring, and enterprise messaging packages such as the LogicBlaze open-source ActiveMQ JMS provider.

An ESB "Hello, world!" Application

Let's examine what it takes to get similar functionality from an application built on top of an ESB. Here's overview of the steps you take to build and run this sample ESB-based application:

  1. Download and install an ESB (in this case, ServiceMix)
  2. Build the individual message sender and message receiver components
  3. Write the "Hello, World!" ESB application configuration file
  4. Start the ESB
  5. Run the ESB-based "Hello, World!" application (which entails running the sender and receiver components)

Download and Install ServiceMix. The first step is to download and install an ESB, such as ServiceMix, which is an open-source ESB made available from LogicBlaze. As mentioned in the previous section, ServiceMix offers a great deal of flexibility in terms of its deployment and integration options and, as a result, will be used extensively throughout this book. At the time of this writing, ServiceMix is at version 2.0.2, and is part of the Apache Inubator project, which is the entry path into the Apache Software Foundation (ASF) for software projects wishing to become part of the Foundation's efforts. All code donations from external organizations and existing external projects wishing to join Apache enter through the Incubator.

Go ahead and download the latest ServiceMix binary and source. The software is available in multiple compressed formats, such as .ZIP for Windows and .GZ for Unix variants (such as Linux and Solaris), so be sure to download the proper file for your system. Additionally, you can choose to download ServiceMix with or without the source; the file with the text "src" in its name (such as servicemix-3.1-src.tar.gz) contains the binaries and full source code, along with the maven and ant scripts to build it. It's recommended that you download ServiceMix with full source code. You don't need to touch the source if you don't want to, but it's there if you want to explore it at some point.

Next, you can to uncompress the SeviceMix files to your computer's hard drive in a location of your choice. When the file is uncompressed, a subdirectory will be created with the name "servicemix" along with the version number (i.e. "servicemix-3.1"). Where you choose to uncompress the file, and hence create the ServiceMix subdirectory, is entirely up to you. However, on a Unix-based system, a good location is the /usr/local directory or your home directory. On Windows it's a good idea to simply uncompress the file at the root of your hard drive, which will result in a c:\servicemix-3.1 subdirectory, for example. Regardless of where you choose to place it, the ServiceMix subdirectory will contain all the ServiceMix source, binary, and configuration files needed to develop and run an ESB-based application.

Writing the Application Code. The sample application we're exploring here consists of a class that both sends, and waits to receive, a message that contains the text "Hello, world!" The ESB will be configured to route this message from the sender to the receiver, based simply on messaging topic names.

Listing One is the code to send and listen for the message for the JMS Client. No code needs to be written for the message routing; proper configuration is all that is required.

import javax.jms.*;
import org.activemq.ActiveMQConnectionFactory;
import org.activemq.message.ActiveMQTopic;

public class JMSClient 
{
    public static void main(String[] args) throws JMSException 
    {
        // ActiveMQ JMS Provider code
        ActiveMQConnectionFactory factory =                         
            new ActiveMQConnectionFactory("tcp://localhost:61616"); 
                                                                    
        ActiveMQTopic pubTopic =                                    
            new ActiveMQTopic("demo.esb.source");          
        ActiveMQTopic subTopic =                                    
            new ActiveMQTopic("demo.esb.result");          

        System.out.println("Connecting to JMS server.");            
        Connection connection = factory.createConnection();         
        Session session =                                           
            connection.createSession(                               
                false, Session.AUTO_ACKNOWLEDGE);                   

        // Create the message producer and consumer
        MessageProducer producer =                                  
            session.createProducer(pubTopic);                       
        MessageConsumer consumer =                                  
            session.createConsumer(subTopic);                       
        connection.start();                                         

        System.out.println("Sending request.");                     
        producer.send(                                              
            session.createTextMessage(                              
                <message>Hello, world!</message>"));
        // Wait up to 10 seconds to receive the message
        TextMessage m = (TextMessage)consumer.receive(1000*10);     
        if( m == null ) 
            System.out.println("Response timed out.");
        else
            System.out.println("Response was: "+m.getText());
        
        connection.close();
        System.out.println("Done.");
    }
}
Listing One: The "Hello, world!" JMS application that will run in the ESB

Listing One is a straightforward JMS client. For simplicity, both the sender and receiver components have been placed in the same class. In reality, these components would most likely be separate entities; developed and deployed individually without any dependencies on one another. Although it's true that this code needs nothing more than a JMS provider, the point is that this application will run in an ESB without the need for any ESB-specific code. All that is needed now is some configuration on the ESB side to make this application work, and to route the "Hello, world!" message properly from the sender to the receiver.

The ServiceMix ESB needs a configuration file, named servicemix.xml, to operate properly and in the manner you expect. Listing Two contains a portion of the servicemix.xml file for the "Hello, world!" sample application. The listing sets up a JMS consumer within the ESB to subscribe to a JMS destination.

...
<!-- Subscribe to a JMS destination -->
<sm:activationSpec componentName="inputReceiver"
                   service="my:inputReceiver"
                   destinationService="my:outputSender">
  <sm:component>
    <bean 
        xmlns="http://xbean.org/schemas/spring/1.0"
        class="org.servicemix.components.jms.JmsInUsingJCABinding">
      <property name="jcaContainer" ref="jencks"/>
      <property name="activationSpec">
        <bean class="org.activemq.ra.ActiveMQActivationSpec">
          <property 
            name="destination" 
            value="demo.esb.source"/>
          <property 
            name="destinationType" 
            value="javax.jms.Topic"/>
        </bean>
      </property>
    </bean>
  </sm:component>
</sm:activationSpec>
 ...
Listing Two: This portion of the configuration file sets up a JMS consumer within the ESB.

The first XML tag in the XML contains an attribute, componentName, which provides a name for the component ("inputReceiver" in this case). The other <property> tags specify features of the component, such as that it uses ActiveMQ for activation and message deliver, and that a JMS topic is to be used as the destination. Therefore, in this portion of the file, the ESB is instructed to internally create a consumer to subscribe to the topic, demo.esb.source, which is the topic to which the producer from Listing One sends a message.

Receiving the message from the client's producer component is only half of the story. To complete the picture, and the "Hello, world!" message's journey, a message producer must be created within the ESB to route the message to the client's consumer component.

Listing Three contains another portion of the servicemix.xml configuration file; this time with the piece that creates the internal JMS message producer. This producer is configured to send the messages received by the internal message consumer, from Listing Two, to the topic, demo.esb.result, which is the topic that the client's consumer is listening to.

<!-- Publish the result to a JMS destination -->
<sm:activationSpec componentName="outputSender" 	
                   service="my:outputSender">
  <sm:component>
    <bean 
        xmlns="http://xbean.org/schemas/spring/1.0"
        class="org.servicemix.components.jms.JmsSenderComponent">
      <property name="template">
        <bean class="org.springframework.jms.core.JmsTemplate">
          <property name="connectionFactory">
            <ref local="jmsFactory"/>
          </property>
          <property 
            name="defaultDestinationName" 
            value="demo.esb.result"/>
          <property 
            name="pubSubDomain" 
            value="true"/>
        </bean>
      </property>
    </bean>
  </sm:component>
</sm:activationSpec>
Listing Three.

You can see that this portion of the XML configuration file is similar to Listing Two, with some important differences. The big difference is that the component is specified to be a JMS sender, as shown in the <bean> tag's class attribute. The destination, in the case of this component, is also a topic. The ESB will take on the responsibility of delivering all messages reliable via its built-in JMS provider.

Understanding the ESB Internals

Let's look at what happens inside the ESB when the "Hello, World!" application is executed. When you run the JMS client code in Listing One with the ESB, it appears that the message sent by the producer is simply received by the consumer component, as in Figure 16.

Figure 16: The JMS message is sent by the producer and then received by the consumer. The ESB internal message system reliable transports and routes the message to the proper message consumer(s).

In reality, the ESB is itself listening with its own consumer, thereby intercepting and then routing the message back to the client application's consumer via its own internal message producer. This involved, but transparent, message interaction is shown more clearly in Figure 17.

Figure 17: With the ESB, the JMS message is consumed internally, routed, and then sent again by the ESB to the client. This message routing is performed without adding any code within the components.

It's precisely this sort of automated messaging capability, along with the associated message routing, that is the foundation for the ESB's power and ease of use. The internal interception and routing of messages allows the ESB to distribute processing across process and machine boundaries in order to improve overall system scalability, and to transparently provide failover and redundancy across various parts of the network deployment.

It's time to prove that the ESB and its internal message routing works, and that the "Hello, world!" message will truly be received and displayed. Follow along as we run the application and see the message delivered first-hand.

Running the Application

Let's recap what we're trying to accomplish with this sample application. So far, we've downloaded and installed the ServiceMix ESB, written the Java code for the message sender and receiver components, and wrote the ESB configuration file which specifies some simple message routing guidelines. Now let's prepare to execute the application and watch the ESB in action. The first step in running any ESB application is to ensure that the ESB itself is running.

Start the ServiceMix ESBFor this example, you will need to download the complete sample code for this article. While the listings above contained the full Java source code, there is an ant script (not shown) and more to the configuration file in Listing Three. The "Hello, world!" application should be placed in a directory called hello-world, which is the directory you should change to when you run it.

Note: Remember to ensure that execute permission is set on the servicemix shell script within the servicemix-3.1/bin directory.

When the ESB has completely started, you should see output similar to that in Figure 18.

Figure 18: The output displayed when ServiceMix is started for the "Hello, world!" sample application

Once startup is complete, you can run the sample client application that will send, receive, and display the "Hello, world!" message.

Run the Client ApplicationYou can run the sample client application on either Windows or Unix via the supplied ant script with the following simple command from within a second command prompt or terminal window:

> ant

With this one command, the sample client application will be compiled, if needed, and run. If successful, the output you receive should appear similar to that in Figure 19.

Figure 19: When the ESB sample "Hello, world!" application is run, the response output will be in the form of XML. Of course, using an ESB to send the message, "Hello, world!" is overkill, but it serves as an example that's easy to understand and get running.

The proper response is the "Hello, world!" message within the XML that was actually routed through the ESB. This text is seen just before "Done" message, at the bottom of Figure 19. Looking back at the first command prompt or terminal window, where the ESB is running and its output displayed, you should see some messages pertaining to a transaction that is started and then committed as the message is delivered. By default, with ServiceMix and this sample application, a transaction is started as each message is transported.

So there you have it -- your first ESB-based application. Reliable messaging, message routing, message normalization, and transaction support, all provided transparently and with very little code.

Conclusion

This article set out to define what an ESB is, what it consists of, and what problems it is designed to solve. As a result you, should have and understanding of when to use an ESB, and what parts best apply to your own problem sets. An important lesson to learn is that the ESB should be thought of as a toolkit, or a framework, from which you can choose the pieces to use or ignore as you design and build distributed software systems.

For existing systems, the ESB can be easily migrated to, or it can be used to integrate existing systems and services, even when those systems were not originally designed to work in a service-oriented architecture. Although the ESB is built around XML and SOA technology, through adapters and message normalization, legacy systems of all types can be brought into the modern age of integration and Web 2.0 architectures.

Furthermore, the case studies and the sample application presented here should begin to give you a feel for how an ESB is put to use, how it can benefit your organization, and how it can save time and money from a design, development, and administrative point of view

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.