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. =)