Brian O'Neill's Blog

Patterns Archives

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 .

Web Services & SLEE -- Whats the best fit?

The word "web" in "web services" is misleading. Web services do not in any way shape or form depend on the "web". They are not tied to any specific protocol or means of invocation. Very generally, a web service is simply a service made available to other loosely coupled systems via an interface that is usually described using the web services description language (WSDL).

In WSDL, the actual means of invocation (binding and port) are implementation details. Their could be multiple bindings because the service supports multiple means of invocation, RMI, EJB and SOAP for example. One can envision a day when HTTP is not the primary protocol via which a service receives and responds to invocations. This lead me to thinking about SLEE.

SLEE is the perfect platform on which to build generic event-driven applicaitons that provide services to external entities. Via the resource adapters, the application achieves the necessary abstraction layer away from the underlying protocols. In a SLEE container, I can develop my service without tying it to any particular protocol or invocation method.

Beautiful, but how does one do this? The question that is open for debate (and to which I don't have an aswer) is how does one develop a traditional web service in a SLEE container? Is it possible? Is it suggested? Do I have to first develop it in J2EE then tack on a SLEE mechanism to expose it via other means? That seems like the wrong solution.

So, I would like to propose an HTTP adaptor for the SLEE container. For some reason, I've "heard" this is frowned upon. In my opinion, this is the cleanest way of building services in the future.

Call me silly but I want to develop my service in a Service Logic Execution Environment (without thinking about J2EE), and whether or not it gets invoked via HTTP requests or someone tapping out morse code, is only an implementation detail.

How does one make this happen?

This work is licensed under a Creative Commons License.