Brian O'Neill's Blog

SOA, ESB, JBI & SCA: A caveman's perspective

Software development techniques and processes are changing at ever faster rates as open collaboration development spreads globally (thanks to the adoption and promotion of open source software). As the systems we architect and implement become increasingly complex, the mechanisms, infrastructure and patterns with which we build the complex systems constantly improve to keep the problems tractable.

The Java Business Integration (JBI) specification and Service Component Architecture (SCA) are the latest additions to our tool set. Now, I'm a simple man, a caveman really. And for the last three years, I've been working to construct a multi-channel service oriented architecture for the federal government, with pluggable enterprise services (pub/sub, security/encryption, messaging, VoIP, etc.)

As you can imagine, this is a hard problem for a caveman to solve, especially when you layer in a complicated political landscape filled with software infrastructure vendors, and their professional services divisions. We needed an industry standard on which to hang our hat.

Now, most people would hang their hats on "Web Services". Those same people would probably define web services as WSDL + SOAP + HTTP + (UDDI). They would then proceed to convert all RMI, RPC, and potentially database communication into web services: then call that a SOA. Unfortunately, that only results in a rat's nest of invocations and derived dependencies that can bring down an entire enterprise. (we have the battle scars to prove it)

So, we evolved.

We realized that we needed a common communications backbone to unravel the mess. Enter Enterprise Service Bus (ESB) concepts, but again we were disappointed. We looked around for one of these new fangled ESBs, but all we found were re-applied messaging systems that required proprietary extensions to achieve a services layer. (and we knew enough to stay away from those, and the vendor lock-in that came with them)

SO, we looked long and hard at the writing on the (cave) wall; and found a promising acronym: JBI. We set about downloading JBI implementations. Immediately, we were hooked. JBI provided a standard interface through which we could deliver our enterprise service "lollipops". Literally, we could drop our lollipops into existing JBI containers, rewire the connections and provide service consumers and producers with security, compression, discovery and other capabilities. Wow, nirvana.

In fact, as cavemen - we were more productive than ever. We could develop applications without writing a single line of code. Applications development became a matter of drawing pretty pictures. Using a palette of components, and drawing lines between them, in minutes we could create new convergent capabilities - e.g. take messages from XMPP, and post them to RSS feeds.

But alas, nothing gold can stay. The political landscape shifted, and SCA came down from the heavens like a meteor crashing into the earth. We ran for cover, trying to figure out how SCA fit into our new world view. What we had heard about SCA was promising, but we had trouble putting our fingers on it. SCA seemed like a great language with which to communicate with other cave people, a common way to describe what we were building, and compose larger services from smaller, recursively. This was much needed, and completely complimentary to our new found love - JBI. As cavemen, we couldn't see where SCA dictated a run-time, but we didn't need it to. We had JBI already.

Us cavemen proceeded forward with a new world understanding - determined to build a bridge demonstrating an SCA composite application, running in a JBI runtime.

You can follow along at jBIZint .

Comments

• Thanks for confirming my suspicions. I, too, am a caveman.

  The burning question for me, especially after reading Chappell's recent blog, is how we've returned to thinking in terms of app servers? Although I tend to agree with the composite application (because that's what I'm doing with JBI/ServiceMix) - I'm still having trouble seeing how they are complementary as everyone's preaching. I also would tend to agree that we need to be service-implementation-language agnostic - so I'm somewhat exited about SCA in this sense. But, unga oggg ohhga ooga bagooga & luba dob doog? (We do have JBI already & what is wrong with Java?)

  Nobody, to date, has been able to make the case where they are complimentary. Have we not learned that interfaces are the key? A SCA component/app must be able to talk to a JBI component/app - or any TLA-effin' component - regardless of where they are running.

  Politics, be what they be - take a look at who's voting down the JBI 2.0 spec. Again, haven't we learned that there is no "common" - only "standards" that must interface. Which leads me to think that I'm not really a caveman. Hmmn, maybe IBM and Oracle are still working on the fire thing - and I'm on to the wheel.

  Posted by: kitplummer on June 19, 2007 at 11:02 AM

This work is licensed under a Creative Commons License.