SCA & JBI: Made for each other. (SOA Gone Wild)

I agree with Shaun Connolly's
observation that "While they [JBI and SCI] may share some similar patterns, those who pit SCA vs. JBI only demonstrate their inability to distinguish between the two perspectives".

In fact, we set out to prove the assertion that:
- JBI and SCA are entirely complementary.

And we've made quite a bit of progress by taking an example SCA composite application / contribution and figuring out how it translates into a JBI runtime environment. But translation is only one example of how JBI & SCA may fit together.

There are actually three different relationships that make sense. First, SCA run-times that already exist (e.g. Tuscany) could be deployed as containers within JBI by packaging them as Service Engines. JBI would leverage the SCA Service Engine as a means of integrating SCA contributions into a JBI runtime. In this respect, JBI provides an integration backbone that would improve the utility of SCA contributions by making them available to networks, capabilities and systems for which there is no SCA component implementation. (e.g. SIP and XMPP) Essentially, this would attach an SCA contribution to an bus architecture, with all of the benefits that comes with that.

Secondly, I don't see any reason why there wouldn't be a JBI Component Implementation added to SCA's list of implementations. This would allow an SCA contribution to declare a JBI service unit (or service assembly) as a component implementation within an SCA contribution.

Lastly and most interesting, JBI can be the run-time for SCA contributions. In this capacity, a translation layer would translate an SCA contribution into a set of service units deployed to binding components and service engines. In this example, each binding in the SCA composite application the would result in a service unit bound to a binding component. Likewise, for each service implementation in the SCA composite application, a service unit would be deployed to a service engine. (e.g. bpel, pojo, etc.)

The translation is a tremendously powerful construct. It lets JBI deliver all of the bus-like features, life-cycle management, and administrative controls, while allowing architects to define their composite applications in SCA.

We are working all of this through on jBIZint . If all goes well, we hope to deliver a Grand Unified Platform by the end of the year that when combined with Eclipse and/or NetBeans will directly interpret developers brainwaves into SOA. =)

JBI on your cell phone?

Despite the fact that many early JBI implementations are reusing enterprise infrastructure for their implementations (e.g. JMS messaging backbones and J2EE containers), my prediction is that JBI will start invading the mobile market.

Already, people are looking to leverage JBI implementations on small footprint platforms as a means of realizing the benefits of an "enterprise" service bus, but without the overhead of the "enterprise". In this capacity, JBI is a great means of achieving service re-use , while maintaining loosely coupled composition.

For example, JBI may be the best means to inject security into a mobile application. Since JBI focuses on data flow, , a developer can just "drop in" security components, rewire the messages to first pass through an authentication and authorization engines. Without changing the app at all, it would be capable of invoking services that require digital signatures. I go through this use case here.

It is a common misconception that OpenESB is wed to NetBeans and Glassfish. This isn't the case at all. In fact, you can follow these instructions to get OpenESB up and running in a J2SE environment, with XMPP capabilities and RSS feeds!

Lots of fun. =)

JBI as a Convergent Communication Platform

I have a hard enough time keeping my mind straight as it is, maintaining multiple internet persona's only makes my life more difficult: a skype account, IRC, AOL, XMPP, Yahoo, email, PSTN, mobile, etc. Some clients have been doing a better job of bridging the networks from a user perspective, but this does nothing for capabilities development on the server side -- and the disparity between the networks still causes user headache.

For example, even using one of the multi-protocol chat clients, to coordinate a chat-room I need to get everyone to agree on a common protocol, everyone needs accounts, and everyone needs to be on the same "type of network". (ie. firewalls need to permit traffic to the agreed upon network)

Why?

Because there isn't a server out there capable of maintaining presence, and location information across the multiple protocols. Sure, there are lots of gateways being built (e.g. XMPP -> SIP and back), but this results in the need for nxn gateways. Any architect will tell you that you need a common normalized schema to reduce the number of necessary conversions. Then you only need to develop n gateways, each converting from the protocol specific format into the normalized message format.

Hmmmm, interesting - this sounds awfully familiar. Enter JBI.

The devil is in the details, but if we ignore them for a moment, this is exactly the concept behind binding components (BCs) and the normalized message router (NMR). Over the past six month, we've developed binding components for XMPP , SIP , UDDI , and RSS . The purpose of each of these is to convert between normalized messages and their protocol specific equivalents.

Since the BCs expose those disparate communications networks over a single "bus", this appears to be the perfect environment for convergent applications development. Thus, you could implement a single presence service, a single locations repository, etc. Finally, I'll be able to join a chat-room over SIP, while friends join over XMPP, with the entire conversation broadcast over RSS.

Now, back to the devilish details. In a previous life, I spent long hours working on SIP (registrar, presence and proxy) servers. More specifically a commercial derivative of the NIST JAIN-SIP-Presence-Proxy server. Recently we've formed a new project, Marlin to attempt the very idea described in this blog, implementing the same capabilities as the JAIN-SIP-Presence-Proxy project, but independent of the protocol.

We're putting use cases together here , and meeting to determine how all of this relates to Sailfin .

Its an exciting time to be in communications infrastructure. =)

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 .

Better than Java.net?

I'm just wondering if blogspot is better than java.net. So, this is my test drive.
Ordinarily, I have a blog over on java.net, but I noticed some people had moved over here and wanted to see what all the hubbub was about.