Adapters for an ESB

One of the joys of software development is the ease with which you can create complex stuff out of thin air–or your own imagination. Creating new software may fulfill a need that could not otherwise be met. However, you can take advantage of a standardized way of doing things, so that you don’t have to start from scratch every single time. In the case of infrastructure software, using an established standard enables you to concentrate on your specific business needs, and not the supporting systems.

The seed of this article is actually a comment on the first article^[1] in this series. In that first article, I described middleware as though it were plumbing. I chose to use this analogy as the term “middleware” is often misunderstood. My rationale for the plumbing analogy was that plumbing and middleware share these characteristics:

First, it’s mostly invisible. Second, it provides a standard way of doing things. Third, it ties together parts of complex systems. Fourth, and finally, it lets you worry about other things.

What I was getting at with the fourth characteristic is this: With middleware, application developers don’t have to re-invent the software infrastructure needed to support their applications. Instead, they can concentrate on the business logic of the application. In the article, I said, “When you put an addition onto a house, what do you worry about? Bathroom fixtures, kitchen appliances, flooring, colors, and how to pay for it all. It’s a very stressful process. The last thing you want to worry about is whether you want 3/4-inch or half-inch pipe, copper or PVC connectors, #9 or #17 solder, etc. With middleware taking care of all the invisible functions, you (as a software developer or a business owner) can concentrate on building software to solve your business problems and fulfill your customers’ needs.”

That article has received several responses from readers. One response included this comment:

“…Except that when you do build your addition, you will need to worry about those exact issues. You’ll need adapters for attaching new metric pipes to old Imperial sizes; you’ll probably have couplers that are designed to connect plastic to copper; and you’ll also need to know the current regulations about when to use copper, plastic, or (heaven forbid) steel. In this sense, your analogy that middleware is like plumbing is surprisingly accurate. Just when you aquire all the materials and expertise in working with one standard, a new standard replaces it, and you start all over again, with the added headache of making the two work together during the transition period…At least that has been my experience over the past twenty years as a developer.”

Now, I hadn’t planned on writing a series of articles on middleware, but that reader’s comment got me thinking about adapters. Not the kind of adapter that you use to tie together different generations of water pipes in your house, but the kind of connections that the adapters in an ESB make possible.

JBoss ESB

Just like “middleware,” the term “ESB” can cause confusion.

An Enterprise Service Bus (ESB) is not a single program or technology. It’s really a matter of software architecture or design. Let’s take a step back from all the jargon and keep it simple. In hardware terms, a “bus” is a physical connector that ties together multiple systems or subsystems. Instead of having a large number of point-to-point connectors between pairs of systems, you connect each system to the bus once.

An ESB does the same thing, logically, in software. Instead of passing electric current or data over the bus to and from the connections (or “endpoints”) on the ESB, the ESB logically sits in the architectural layer above a messaging system. The messaging system allows for asynchronous communications between services over the ESB. In fact, when you are working with an ESB, everything is either a service (which in this context is your application software) or a message being sent between services. It’s important to note that a “service” is not automatically a web service. Other types of applications, using transports such as FTP or JMS, can also be services.

Is an ESB the same thing as SOA? (Service Oriented Architecture)

Not exactly. An ESB does not provide a Service Oriented Architecture, but it does provide the tools than can be used to build one–especially loose-coupling and asynchronous message passing. SOA is a series of principles, patterns, and best practices. The key initial “A” is for “architecture.” In this article, we’ll discuss JBossESB^[2].

Raising Your (ESB) Awareness

We just talked about considering everything in an ESB as either a message or a service. That’s fine for inside the ESB. How does a client or service–especially legacy applications–connect to an ESB?

To answer that question, we have to think about awareness.

No, I’m not talking about getting in touch with your inner child. I’m talking about whether or not your application clients and services are “ESB-aware” or, in other words, whether they can understand the message formats and transport protocols used by the ESB. If you (as a programmer) are ESB-aware, then you can simply code any new clients and services that you write to also be ESB-aware. ESB-aware clients and services communicate with each other using messages. ESB-aware services are identified using Endpoint References (EPRs). The messages take the form defined by the org.jboss.soa.esb.message interface. As the javadocs^[4] for message says:

A message consists of the following components:

• Header: the header information contains information such as the destination EPR, the sender EPR, and where the reply goes–general message-level functional information.
• Context: additional information that further explains the message; for example, transaction or security data, the identity of the ultimate receiver, or HTTP-cookie-like information.
• Body: the actual payload of the message.
• Fault: any error information associated with the message.
• Attachment: any attachments (additional files) associated with the message.
• Properties: any message-specific properties (for example the jbossesb.message.id property is a unique value for each message.

What about cases where legacy clients and services that are not ESB-aware need to be able to communicate over the ESB? What about cases where legacy clients and services need to be able to communicate with newer ESB-aware clients and services? Oh, and how about ESB-aware clients that we need to be able to use with ESB-unaware services?

This is suddenly getting complicated. It sounds like you will have to build lots of custom plumbing adapters to get all these combinations of clients and services to talk to each other. But don’t panic and don’t start building home-grown infrastructure. Supporting interoperability between different clients and services is one of the goals of JbossESB.

Interoperability through ESB adapters

One of the ways that JBossESB makes this interoperability possible is though gateway adapters.

Remember how I said that in an ESB, everything is either a message or a service? Well, a gateway (org.jboss.soa.esb.listeners.gateway) is a service that acts as a bridge between an ESB-aware and an ESB-unaware client and service. Gateways translate information between ESB and non-ESB message formats and EPRs. (And EPR stands for endpoint reference.) Gateways are listener processes in that they “listen” for incoming communications. They are different from ESB-aware listeners in that they accept data in different formats such as objects in files or SQL tables. ESB-aware listeners can only accept messages in the org.jboss.soa.esb.message format.

JBossESB supports these gateways:

• file gateways: local filesystem, ftp, sftp and ftps
• JMS
• HTTP/HTTPS
• email (POP3)
• SQL table
• Hibernate

When a gateway listener hears something, it converts the non-JBossESB messages that it receives to the org.jboss.soa.esb.message format. How this conversion happens depends on the gateway type. For example, the file gateway takes the contents of the file and puts it into the location named BytesBody.BYTES_LOCATION within the message body.

Let’s look at an example.

A quick start (with a quickstart)

One of the helpful features included in JBossESB is the set of “quickstart” sample applications. The quickstarts demonstrate JBossESB functions and integrations. The goals of the quickstarts are to serve as learning tools and as a starting point for your own application coding. We’ll examine one of these quickstarts to view the operation of a gateway.

Let’s assume that you have a legacy application that stores data in text files. What you want to do is to create an ESB-aware service to read these files and process them as they are created. You could write infrastructure code that periodically polls a target directory to determine when a new file is deposited there. With JBossESB, however, you can simply use a file gateway.

First, let’s install and start up a JBossESB server. Before you start, you will need to install Java (1.4 or 1.5) and ant (1.6.5 or later).

Next, download the JBossESB server from
http://www.jboss.org/jbossesb/downloads/
. For this illustration, download the JBossESB 4.2.1 GA Binary and unzip it:

unzip jbossesb-server-4.2.1GA.zip

Then, configure the quickstarts to know about the install directory for the JBossESb server by editing jbossesb-server-4.2.1GA/samples/quickstarts/conf, and setting org.jboss.esb.server.home to the directory into which you installed the JBossESB server

Now start the server:

sh jbossesb-server-4.2.1GA/bin/run.sh -c default

The quickstarts are distributed under the samples/quickstarts directory. Let’s take a look at helloworld_file_action.

cd jbossesb-server-4.2.1GA/samples/quickstartshelloworld_file_action

Deploy the test to the server and run it with these simple commands:

ant deploy
ant runtest

The server output should look something like this:

16:42:22,744 INFO [STDOUT] Message structure:
16:42:22,744 INFO [STDOUT] [Hello World In A File].
16:42:22,746 INFO [STDOUT]
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
16:42:22,746 INFO [STDOUT] Body: Hello World In A File
16:42:22,746 INFO [STDOUT] &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
16:42:22,747 INFO [STDOUT] Message structure:
16:42:22,747 INFO [STDOUT] [ message: [ JBOSS_XML ]

What just happened here? Let’s take a look. The “runtest” and target invokes CreateTestFile.java program. As its name implies, this program creates a test file. The file contains this text: Hello World In A File

For what happens next, we need to look at how the test application is configured in the ESB. A JBossESB application’s primary configuration file is named jboss-esb.xml. In the case of this quickstart, that file is generated at run time so that the JBossESB install directory can be determined. So, we need to look at the source of the generated file, jboss-esb-unfiltered.xml.

The first part of the file that we’re interested in looks like this:

This is the definition of the file gateway that we’ll use. Note the directory names. In this example, they are filled in at run time from values determined by the directory in which you installed JBossESB.

Now, remember how we said that everything in the ESB is either a message or a service? Scroll down in the file and we’ll see our service.

Let’s look at this service description.

First, the listeners. Note the definition of the file system (fs) listener. This is our gateway. The “busidref” field references the “fs-provider” that we discussed a minute ago. Did you notice a second listener? This is an ESB-aware JMS listener. It is there because JBossESB requires that each gateway have a corresponding ESB listener defined.

Let’s look at the actions. The “mep” definition of “OneWay” refers to the action pipeline (the sequence of actions) explicitly not sending a response. (You can find more detail about these definitions in the ESB Programmers’ Guide ^[7].)

The actions named “testAction” and “dump” write the message to the server log. The action that we’re most interested in is “action1.” The methods (displayMessage, playWithMessage) in the class referred to by this action (org.jboss.soa.esb.samples.quickstart.helloworldfileaction.MyAction) receive the data in the input file as an ESB-Aware message, extract that information, and process it. In the case of your application, you would replace “MyAction” with your own business logic code.

So, in summary, what happens when this quickstart is run?

1. The file system gateway is initialized.
2. A file is created in the input directory defined in its fs-provider definition.
3. The gateway reads the file, transforms it into an ESB-aware message, and passes the message to the methods in the action class defined in the action definition.
4. These methods process the message (in the case of the quickstart, they write the message contents to the server log).5. The gateway moves the file to the output directory defined in its fs-provider definition.

It’s important to note that the only new code that had to be written is the action class. The infrastructure code to listen for and transform the file into a message in the format that the ESB can process is all part of the gateway.

From the perspective of an application developer, this is a plus as you can concentrate on writing code to fulfill the business process requirements of your application.

From the perspective of a QE engineer, this is a real plus as it means that less code has to be written. And, the less code, the fewer opportunities for bugs!

What’s next?

In the next article in this series, we’ll take a look at the counterpart to listeners: the notifiers. The listeners enable you to get information into the ESB. Notifiers provide one way to get information out.

Resources

^[1] Read the first article in this series – What is middleware? (In plain english, please.)
^[2] JBossESB –
http://labs.jboss.com/jbossesb/

^[3] JBossESB Connectors and Adapters Guide
^[4] JBossESB javadoc: jboss/soa/esb/message/Message.html
^[5] JBossESB quick start
^[6] JBossESB getting started guide (4.2.1GA)
^[7] JBossESB Programmers Guide

Acknowledgments

The author would like to thank the members of the JBossESB project and community (especially Burr Sutter and Mark Little) and the SOA Platform project for their help and timely review comments. This article relies heavily on the excellent JBossESB user documents and the quickstarts.

About the author

Len DiMaggio is a senior QE engineer for JBoss middleware at Red Hat. When he’s not building tests and generally breaking things, he likes writing, photography, and chauffeuring the kids to their many sports activities. Len is a frequent contributor to Red Hat Magazine (this is Len’s 10th article in the magazine), and has also written for Dr. Dobbs’ Journal, STQE, Software Development, IBM DeveloperWorks, and other publications. Len also recently launched a blog dedicated to software testing.

This entry was posted by Len DiMaggio on Thursday, May 22nd, 2008 at 4:53 pm and is filed under JBoss, technical. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.