Skip to main content

Understanding JBI and Open ESB

Posted by gsporar on February 19, 2007 at 7:50 PM PST

Okay, so I'm kind of behind the times. This seems to happen to me quite often - I
just recently upgraded from 8-track tapes to cassettes. :-) In the case of
the Java Business Integration (JBI) specification,
it was one of those
things I kept intending to investigate more closely but other things always
seemed to take up my time.

The other factor is that I have never been much of an integration kind of
a guy. I have worked on many different types of software during
my career, but enterprise integration is not something with which I
have much experience. In the applications I have worked on
that exchanged data with a central system it tended to be a silo approach:
pull out what you need and then in some cases write back a specific end result.

So there are a whole host of problems in enterprise environments that I have read
about, but have not had the responsibility for solving. But in preparation for a
workshop that I attended, I decided to learn a bit
more about JBI. I went out onto and looked around.

Surprisingly, there's
not much out there (but I later found some good stuff
There are some "take 10" presentations but I was looking for
a white paper type document that I could read on an airplane. I didn't see one, but
it turns out the specification
itself fits the bill pretty well. The first four chapters
are very user friendly. I also skimmed over chapter five. From what I can tell
the remainder of the document is only required reading if you plan to implement a
service engine or a binding component, so I did not print them out.

And that gets to the key point: the vast majority of folks will never implement a service
engine or a binding component. A fitting analogy comes from the world of Java EE: most developers
create servlets,
JSPs, EJBs, etc. not the web and application containers that provide a runtime environment for
those servlets, JSPs, EJBs, etc.

But I am getting ahead of the story. I like to approach these sorts of things from the perspective of:
What problem does this solve?
In other words, if JBI is the answer, what was the question? To me
the key to understanding all this is to focus on the 'I' in JBI: Integration. For many years
now our industry has come up with solutions for integrating applications and exchanging the data
that those applications process. Frequently those solutions involve custom-crafted internal code and/or
reliance on a single vendor's commercial solution. A better approach would be an industry standard
for integration services. The goal of JBI is to provide that industry standard for integration
providers and by extension, for their users.

That is a lofty goal and it leads to the question: What sorts of capabilities will these integration
providers be able to deliver? In other words: why should anyone care? It turns out there are many interesting possibilities.
To take just one example: the
Business Process Execution Language (BPEL)
provides a standard
for defining business processes, which can then be run by a BPEL engine.
There are a variety of BPEL engines out there - what JBI provides
is a standard way for organizations to use a BPEL engine (start/stop/discovery/deployment/etc.) and to make
other services available to their BPEL processes while running within a BPEL engine. For all of this
to work, the BPEL
engine providers have to conform to the JBI specification but from what the experts tell me, that is not too difficult
to achieve.

BPEL engines are just one example. There are many others: event processing, business rules engines,
extract/transform/load (ETL) engines,
etc. These and many other technologies are all perfect candidates to be implemented as JBI compliant service engines.
A service engine is a runtime process to which a developer deploys an artifact (BPEL code, business rules, etc.). That
artifact can interact with services provided by other JBI compliant service engines.
For example, a BPEL process could invoke a script over in an ETL engine in order to move some data around. Contracts
for these services are described using WSDL.

Naturally, interaction with the world beyond the JBI container is also necessary. This is where the binding components
fit in. They provide the bridge to external systems. A binding component could be written for just about any protocol:
FTP, etc.

Put it all together and you get the ability to integrate many different technologies. For example: a BPEL process
that uses a file system binding component to read a file that contains a credit application. It could then pass data to an
external credit-rating web service via a SOAP binding component and use the same approach to get a decision from a business rules
engine. When a decision has been reached, the BPEL process can use an SMTP binding component to send an email

Please note: that is just one example. The possibilities are pretty much unbounded. Note that in that example, the
developer who created the pieces (the BPEL process, the business rules, etc.) was not programming in Java. That point
is important because I think some critics of JBI have put too much stress on the 'J' in JBI. The "Java" in JBI is all
about the programming interfaces required in order to implement a service engine or a binding component. But as I wrote
a few paragraphs back, that affects only a small number of people. The people who actually use JBI compliant containers
to solve problems will use whichever languages are supported by the service engines they choose to use.

Now for the tricky part: finding a JBI compliant container and some useful service engines and binding components. Sun has made the decision
to seed the market with an open source project called
Open Enterprise Service Bus (ESB). Open ESB
provides both a JBI compliant container and
many useful service engines and binding components. Open ESB is being developed as
part of the GlassFish open source application server.
So Open ESB is a container-within-a-container - it
runs as a hosted application in GlassFish.

A great deal of the brain power behind Open ESB comes from the folks
who were part of SeeBeyond, an integration
software company that Sun bought back in 2005.
Last week I spent four days in a workshop that the Open ESB folks
hosted. I got an overview of the SeeBeyond
technology that is now being moved into Open ESB.

Naturally, to make use of all this cool runtime technology, you need tools. This is where the NetBeans IDE comes into
the picture. Back in October 2006 when
NetBeans IDE 5.5 was released there was an add-on
called the Enterprise
that also got released. To be frank, the name "Enterprise Pack" was not the best choice. It causes confusion
because people naturally assume that it includes tools for doing development for Java EE. That's understandable,
since "EE" does stand for "Enterprise Edition."

But the Java EE tools are in the standard NetBeans IDE distribution - the purpose of the Enterprise Pack is
to instead provide tools for developing what JBI calls composite applications. A composite application is simply
a collection of the artifacts that make use of the services and bindings provided by a JBI container. In other
words, it's the stuff that a developer writes and then deploys to a JBI container. So for that sample application
I described above, the composite application would include the BPEL script, business rules, and WSDL files
(and associated XML schema files).

The NetBeans Enterprise Pack 5.5 provided a relatively small number of tools, at least in comparison to
what's coming up. In
April 2007 NetBeans IDE 5.5.1
will ship and there will be a significant amount of
new functionality in NetBeans Enterprise Pack 5.5.1. This is in alignment with new features that are being
added to Open ESB. To give you an idea of the scope of the new features in Open ESB, take a look at the two screen snapshots
below. The first one is from NetBeans IDE 5.5. The second one is from a recent daily build of NetBeans IDE 5.5.1.



The list of Open ESB service engines and binding components is listed under "JBI" (which, by the way,
I am not in favor
of, it seems like the label should be "Open ESB"
). As you can see, there are quite a few new entries. Service
engines have been added for doing ETL, intelligent event processing, SQL queries, and
XSL transforms. Binding components have
been added for file system access, FTP, JDBC,
JMS, IBM's MQ Series, and SMTP.

All of which means there is still much more to learn and explore.