from http://blogs.sun.com/tombarrett/entry/role_of_the_esb
I have been laser-focused for well over a year on the role of the
Enterprise Service Bus (ESB). That's the part of Java CAPS that
interests me most and I am infatuated with the work going on under the
Java Business Integration(JBI) specification in the Open ESB community.
It has seemed to me that the ESB encompassed everything, that it was
the umbrella under which everything else interesting was going on.
JBI's normalized message router, service engines and binding components
are exciting. Building composite applications with NetBeans to deploy
to Open ESB as service assemblies composed of service units is just
plain fun.
However, it occurred to me a couple weeks ago that there is an
architectural perspective well outside and above this ESB world and
that I ought to be studying and appreciating it more. The awakening was
provided by Mark Hapner, a Sun Distinguished Engineer. We are on the
agenda at a developer conference this month and he will give the
keynote right ahead of me on the agenda. My topic, of course, is ESB. I
needed to understand where Mark will leave the audience when he sits
down and I stand up. So, through several phone and email dialogs, Mark
educated me a bit on the world outside my ESB.
Covering that education in full is the stuff of multiple blog postings.
However, one key epiphany I had was that in contrast to what I read
about ESBs as massively distributed, uber information buses, I should
remember that my JBI-based ESB has a relatively small, well-scoped
role. In fact, it may be far more plausible to view ESBs, in general,
as localized middleware that just make it easier for developers to
field composite applications. Perhaps all this "ESB as distributed,
uber information bus" is just pho0ey?
The JBI 1.0 (JSR 208) spec is clear that JBI is a meta container
specification for integration. JBI is to do for integration what J2EE
(now Java EE) did for application development. Java EE gave us
containers (web and EJB) and an assembly model (JSPs, servlets and EJBs
configured declaratively via deployment descriptors and packaged into
wars, ejb jars, and ears). JBI gives us containers (service engines,
binding components) and an assembly model (service units and service
assemblies). Both Java EE and JBI establish a standard that combat
vendor lock-in by fostering open ecosystems.
So, instead of seeing the ESB vista as huge, distributed information
buses spanning many hosts on many subnets, I am scaling back to realize
that an ESB is just to be a local meta container (like Java EE app
servers are) where programmers can more easily bring technologies
together (BPEL, XSLT, rules engines, Java EE, SOAP/HTTP, JMS, AS2, ...)
and field composite applications. These applications run atop a
particular host housing supporting middleware. For Java EE, the
supporting middleware is a Java EE-compliant application server. For
JBI, the supporting middleware is a JBI-compliant infrastructure like
Open ESB (and soon ... Java CAPS 5.2).
So, I'll be more realistic about ESBs in general and truer to the JBI
spec and realize that my Open ESB runtime is for my composite apps what
my application server is for my Java EE apps.
In the spirit of "a picture is worth a thousand words," I'll close with
one that has helped me. You want a distributed JBI ESB? You know each
JBI ESB runs in its own JVM, right? Just link them up somehow. How
about good old message-oriented middleware? No problem, here you go:
