ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button O'Reilly Book Excerpts: Enterprise Service Bus

Using the ESB Service Container

by David A. Chappell

Author's note: I am pleased to share with you an excerpt from Chapter 6 of my latest book, Enterprise Service Bus. If you build, integrate, or architect enterprise applications, and are looking for the skills and expertise to become a next-generation enterprise integration architect, this is the book for you!

Related Reading

Enterprise Service Bus
By David A. Chappell

An Enterprise Service Bus (ESB) is a standards-based integration platform that combines messaging, web services, data transformation, and intelligent routing in a highly distributed, event-driven Service Oriented Architecture (SOA). ESBs are rapidly being adopted within IT organizations across a wide variety of industries, to solve real-world integration challenges in a unique and efficient manner.

This book is the first of a new Enterprise Series of books from O'Reilly Media, and is targeted to integration architects, project managers, CIOs, and CTOs who need manage integration issues across their extended enterprises. The architectural concepts are presented in the form of integration patterns that show how an ESB can help solve a diverse range of application integration challenges using standard components and interfaces.

This excerpt comes from one of the core chapters discussing a key architectural concept of the ESB -- the service container. The concepts discussed here are the principal enablers of service reuse through the ESB mantra of "configuration rather than coding." The level of technical depth, architectural discussion, and diagramming notation are indicative of what you will find throughout the rest of the book. I hope you enjoy reading it as much as I enjoyed writing it! (And by the way, while many ESB implementations to date are built using Java components, the ESB is a platform-independent architectural concept that is equally relevant to other languages, such as C++ and C#, for example.) -- Dave

The ESB Service Container

The highly distributed nature of the integration capabilities of the ESB is largely due to traits of the ESB service container. A service container is the physical manifestation of the abstract endpoint, and provides the implementation of the service interface. A service container is a remote process that can host software components. In that respect, it has some similarities to an application server container, but with the specific goal of hosting integration services.

A service container is simple and lightweight, but it can have many discrete functions.

As illustrated in Figure 6-10, service containers take on different roles as they are deployed across an ESB.

Figure 6-10
Figure 6-10. ESB service containers are specialized for integration services such as transformation, routing, and application adapters

Unlike its distant cousins, the J2EE application server container and the EAI broker, the ESB service container allows the selective deployment of integration broker functionality exactly when and where you need it, and nothing more than what you need. In its simplest state, a service container is an operating system process that can be managed by the ESB's invocation and management framework.

A service container can host a single service, or can combine multiple services in a single container environment, as illustrated in Figure 6-11.

Figure 6-11
Figure 6-11. The ESB service container allows selective deployment of a single service, or can be combined with other services

An ESB service is also scalable in a fashion that is independent of all other ESB services. A service container may manage multiple instances of a service within a container. Several containers may also be distributed across multiple machines for the purposes of scaling up to handle increased message volume (Figure 6-12).

Figure 6-12
Figure 6-12. Services may be scaled within a container, and several containers may be scaled across multiple machines

The Management Interface of the Service Container

An ESB service container should handle the inflow and outflow of management data such as configuration, auditing, and fault handling. Management interfaces should be implemented using the Java Management eXtensions (JMX) if the ESB implementation supports Java. A more detailed discussion on the use of JMX in an ESB can be found in Chapter 10.

As illustrated in Figure 6-13, an ESB service container supports the retrieval of configuration data from a directory service, and can also have a local cache of configuration data. This means that even if other parts of the ESB, including the directory service, become temporarily unavailable, the service container can continue to operate with its current set of configuration data.

Figure 6-13
Figure 6-13. Service containers support inputs and outputs for management data such as configuration, auditing, and fault handling

Management input data can originate from a remote management console issuing commands such as start, stop, shut down, and refresh the cache. Management output data can consist of event tracking, such as notification that a message has successfully exited the service or that a failure has occurred. These inputs and outputs can be managed by a JMX management console or redirected to some other management tool using standard protocols such as SNMP.

The ESB Service Interface

The ESB container provides the message flow in and out of a service. It also handles a number of facilities, such as service lifecycle and itinerary management, which we will explore in a later section. As illustrated in Figure 6-14, the container manages an entry endpoint and an exit endpoint, which are used by the container to dispatch a message to and from the service.

Figure 6-14
Figure 6-14. Message dispatch to a service uses the service's configured entry and exit endpoints

XML messages are received by the service from a configurable entry endpoint. Upon completion of its task, the service implementation simply places its output message in the exit endpoint to be carried to its next destination using the "request/reply" or "replyforward" pattern discussed in Chapter 5. The output message may be the same message that it received. The service may modify the message before sending it to the exit endpoint. Or, the service may create a completely new message to serve as a "response" to the incoming message and send the new message in the exit endpoint. The following code example shows what a service implementation looks like:

public void service(ESBServiceContext ctx) throws ESBServiceException {
    // Get any runtime process parameters.
    Parameters params = ctx.getParameters();
    // Get the message.
    ESBEnvelope env = null;
    env = ctx.getNextIncoming();
    if (env != null) {
        ESBMessage msg = env.getMessage();
        ... // Operate on the message
    // Put the message to the Exit Endpoint

What is placed in the exit endpoint depends on the context of the situation and the message being processed. In the case of a CBR service, the message content will be unchanged, with new forwarding addresses set in the message header.

In more sophisticated cases, one input message can transform into many outputs, each with its own routing information. For example, a custom service can receive a purchase order document, split it up into multiple output messages, and send out the PO and its individual line items as separate messages to an inventory or order fulfillment service. The service implementation in this case does not have to be written using traditional coding practices; it can be implemented as a specialized transformation service that applies an XSLT stylesheet to the purchase order document to produce the multiple outputs (if the ESB has an XSLT extension to support multiple outputs).

Auditing, Logging, and Error Handling

Auditing and logging play an important business function within an integration strategy. Part of the reason you want to integrate across a common backbone is to gain real-time access to the business data that is flowing between departments in an organization. A reliable communications backbone will ensure that the data gets to its intended destinations. An auditing framework will allow you to track the data at a business level.

As part of its management capabilities, an ESB container provides an auditing and logging facility. This facility can have multiple sources for tracking data. System-level information about the health of the service itself and the flow of messages can be tracked and monitored. Application-level auditing, logging, and fault handling are accomplished through additional endpoints that are available to each service. As illustrated in Figure 6-15 the service implementation has three additional endpoints at its disposal: a tracking endpoint, a fault endpoint, and a rejected-message endpoint. A service can be created such that a message can be placed in the tracking endpoint in addition to its normal exit destination. A rejected-message endpoint can be used for system-level errors, such as a malformed XML document, or any case in which the service itself throws an exception. The fault endpoint can be used for any application-level errors, or faults, that can occur.

Editor's note: See sidebar, "Is XML Too Slow", at the end of this excerpt for a brief look at an XML document's potential for consuming computing resources, as well as a suggestion for "spreading out the load".

Figure 6-15
Figure 6-15. Additional tracking and fault handling endpoints are handled by the service container

There is an underlying philosophy behind the way that tracking, system errors, and application faults are handled. In addition to a normal exit endpoint to handle the outgoing flow of a message, additional destinations are available to the service for auditing the message and for reporting errors. The service implementation has these endpoints available for its own use. From the service implementation's point of view, it simply places data into the tracking endpoint or fault endpoint, and the surrounding ESB framework takes care of managing the auditing, logging, and error reporting. A tracking endpoint can be configured to point to anything - a topic or queue destination, or even a call to an external web service. This approach provides a separation between the implementation of the service and the details the surrounding fault handling. The implementer of a service need only be concerned that it has a place to put such information, whether it is information concerning the successful processing of good data, or the reporting of errors and bad data.

Tracking can be handled at both the individual service level and the business process level. A business process may make use of different implementations of individual services over time. The tracking of a fault occurrence or the auditing of an individual message can be tied to the context of the greater business process that is utilizing the service at the time.

Is XML Too Slow?

One of the most common observations regarding XML is its potential to consume computing resources due to its verbosity. An XML business document that represents an EDI document can range from 110 KB to over 100 MB in size (often five times larger than the original EDI message), and can consume a great deal of CPU and memory while being parsed and translated. Deploying multiple instances of a particular XSLT transformation service across many machines can provide a very powerful and flexible scaling capability.

If the implementation of the service containers is portable across multiple platforms, you can also take advantage of existing hardware assets. Imagine having the flexibility to commandeer a set of Linux, AIX, and Win2K servers for the purpose of spreading out the load of a particular XML transformation. In addition, because the service containers are relatively lightweight, you can take advantage of less powerful machines that may be underutilized within your organization.

David A. Chappell is vice president and chief technology evangelist for is vice president and chief technologist for SOA at Oracle Corporation.

Return to ONJava.com.