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.