JBI and SCA Are Complimentary!

JBI and SCA Are Complimentary!

from http://www.jroller.com/bsnyder/entry/jbi_and_sca_are_complimentary

JBI and SCA Are Complimentary!

For the past 16 months I've been saying that JBI and SCA are complimentary technologies and finally someone has been quoted as saying the same thing! It was announced this week that SCA/SDO are being donated to the Oasis standards body and Jeff Mischkinsky, director of Fusion middleware and web services standards for Oracle, stated:

This [SCA] is a higher level than JBI," he said, stating that this covers development time, whereas JBI covers run-time.

This is exactly correct. The fact that JBI and SCA have been developed in separate camps needs to change. I like the fact that SCA is finally leaving IBM's closed doors. However, I think that a formal effort should be started to make sure that the two are developed in a way that they continue to compliment one another and interoperate well.

In December of 2005 Hiram and I met with people from IBM and other companies in Boston who all supported SCA. We explained to everyone that we saw JBI and SCA as being complimentary and that they should be treated as such. But it seemed that our explanations went in one ear and out the other. It's great to see someone quoted as stating this very thing in these announcements. Hopefully this will begin to get the message out there.

JBI vs. SCA? Not From My Perspective

The real reason that JBI and SCA are perceived to be in opposition to one another is largely due to the target audience of each technology. JBI is focused on container developers - folks whose goal is to implement an integration platform providing a vendor independent API for binding components and service engines (JBI components) that plug in to the JBI integration platform. The JBI APIs are geared toward implementing the runtime container and the JBI components. SCA is focused on application developers - folks who are developing applications that are deployed to a JavaEE platform, but I question that type of deployment because it begets David Chappell's (the Sonic David Chappell) concept of J2EE everywhere.

J2EE everywhere is the concept of requiring the installation of a J2EE (or JavaEE now) container on every application deployment node your network. This idea has many downsides, the two most common being that chances are you won't be using all components that make up the JavaEE container so why are you deploying the whole thing? (You'd be better to use Apache Geronimo in this case anyway because it's so modular and allows deployment of only the components you need, but that's another discussion.) It's never a good idea to try to use the one-size-fits-all approach in software. By deploying a full JavaEE container on every application node you are doing exactly this. In addition, being required to deploy an entire JavaEE container on every application node is bound to drive up your production costs in terms of services and support, especially if license costs are involved.

First let's take a look at some of the areas where JBI and SCA are in harmony, then we'll circle back and look at some areas where JBI and SCA are unique.

• Both JBI and SCA are focused squarely on Service Oriented Architecture but each is attacking it from opposite ends of the problem. JBI is concerned with an integration runtime and deployment packaging whereas SCA is concerned with a component model for development and deployment.
• Both JBI and SCA promote the concept of separating the business logic from the infrastructure logic. Business logic should not be concerned with what implementations need to be used for, say, persistence or transactionality because this is infrastructure logic.
• Both JBI and SCA promote a concept of component building blocks for development. These building blocks are then wired together using metadata understood by each container and bundled together with each component.
• Both JBI and SCA provide an XML dialect for component metadata. Each type of metadata contains references to components bundled into an artifact bundle, interface and endpoint descriptions and references to other components used by the components in the artifact bundle. See below why SCA wins out in the metadata area.
• Both JBI and SCA allow for synchronous and asynchronous invocation of components.

Now let's look at some of the areas where JBI and SCA are unique. These unique qualities offer many complementary items to the other technology and create definite possibilities when considering the integration of JBI and SCA.

• SCA provides a client programming model for locating and accessing service components. JBI offers no such model because it is not focused on the application development side of integration. This model supports both dynamic invocation and typed invocation and it contains a richer response model than JBI.
• JBI provides a runtime container for the deployment of SCA bundles instead of just relying on a JavaEE container.
• JBI provides APIs for vendor independent component interoperability in the runtime container. E.g, deploying BPEL processes is certainly appealing, but augmenting that with all the capabilities of JBI and SCA is much more attractive that just using a BPEL container alone. A rising tide raises all boats.
• SCA wins out in the metadata are because it's metadata model is richer than JBI because it provides the ability to define reference multiplicity, binding types over which a component is exposed and accessed, explicit imports and exports and much more.
• JBI is extremely focused on WSDL whereas SCA supports both WSDL and Java. JBI uses the WSDL mediated messaging model but doesn't require WSDL for every component.
• SCA provides explicit qualifiers for asynchronous requests, transactions, security, etc. for explicit Quality of Service (QoS) whereas JBI only mentions QoS and some intended uses, no mandates.
• JBI offers the support of the four most common Message Exchange Patterns (MEPs) for JBI components.

I'm sure there are many more things, but I'll stop here. I'm simply trying to point out some of the items that are obvious to me.

If JBI and SCA worked together, the result would be a specification for both development time and runtime that is much more nimble and modular than the integration servers of old. And this synergy is only logical - why continue to work in different camps only to eventually meet in the middle and produce two specs that overlap more and more as development of each continues. Besides, some users are already confused by the separation and don't understand how much each spec compliments the other. Instead of causing yet another EJB fiasco because companies can't agree, let's solve this issue now for the good of the users.