OSGi, Eclipse Equinox, ECF, Virgo, Gemini, Apache Felix, Karaf, Aires, Camel, Eclipse RCP

HBase, Hadoop, ZooKeeper, Cassandra

Flex4, AS3, Swiz framework, GraniteDS, BlazeDS etc.

There is nothing that software can't fix. Unfortunately, there is also nothing that software can't completely fuck up. That gap is called talent.

About Me


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:
Distributing JBI ESBs

posted on 2010-03-08 14:15 gembin 阅读(333) 评论(0)  编辑  收藏 所属分类: SOA


















Design Pattern


Favorite Links


Game Dev


Identity Management

IT resources






Version Control







free counters