from http://blogs.sun.com/tombarrett/entry/sca_raining_on_the_jbi
good article for reference!
SCA Raining on the JBI Parade?
Java Business
Integration (JBI)
is Java's standard for providing an open integration platform.
From the
outset in 2004, the main goal has been to provide an open alternative
to closed, proprietary approaches that vendors like IBM, webMethods and
yes, Sun/SeeBeyond, have been offering. Without JBI, there is no
easy way to rip out a BPEL engine, for example, from an Enterprise
Service Bus (ESB) and replace it with a better one from a different
vendor. Sun and the Java
Community Process (JCP) wanted “to
do for integration what J2EE did for
application development.” The hope has been to encourage
an ecosystem
that supports plug-and-play for integration components in a SOA
world. This would, in turn, offer customers freedom of choice and
combat vendor lock-in.
IBM
and BEA Abstain
Right
before
Java One 2005, the JBI Java Specification Request (JSR
208) came up for final vote. IBM and BEA, key expert group
members, abstained. IBM commented:
- “IBM abstains because the JBI specification
doesn't represent a sufficient
step forward in terms of what we believe
our customers need, and above what they can already do. Many
technologies and open specifications are available to the Java
programmer today with more
compelling interoperability and better
mechanisms for component composition.”
Wow. That
let some big air out of the JBI balloon set for
launch at Java One 2005. Some suspected the beginning of major schism in the
JCP that moves the Java platform
forward. Can you imagine what J2EE (now Java EE) would have been
like if IBM and BEA had not supported it from the outset?
Two years have
passed and the JCP is still intact. JBI is moving along nicely
without
IBM and BEA. Sun is developing the
next major release of Java CAPS (6) atop the JBI specification as
implemented in the Open ESB
project. However, enthusiasm for JBI
has not ramped up like we saw for J2EE in its early days.
It
seems that attention is diverted elsewhere. That elsewhere is a
movement called Service Component
Architecture (SCA)
spearheaded by IBM and BEA.
What's
the SCA Movement?
As JBI is
developed and promoted through the JCP, SCA is nurtured through a
relatively new group called Open Service Oriented Architecture (OSOA)
collaboration. Their goal is "defining
a language-neutral application
model that meets the needs of enterprise developers who are
developing
software that exploits Service Oriented Architecture characteristics
and benefits." Sun joined the
group in July of 2006. OSOA is not a standards body, but
coordinates projects like
SCA to the point where they can be submitted to a standards group for
ratification. The standards body chosen for SCA
is Organization for the
Advancement of Structured Information Standards (OASIS ) through its new Open
Composite Services Architecture (Open
CSA) group. SCA specifications have begun to be
submitted to OASIS.
So, IBM and BEA
rained
on the JBI parade in 2005 and have been working on something called
SCA. How important is this? Is it really a competitor to
JBI? I've asked lots of
JBI vs. SCA
questions and I have heard:
- JBI wants
to build a standards-based ecosystem around integration and folks like
IBM want to protect their proprietary ESB infrastructure.
- IBM and
BEA are tired of Sun controlling the Java community and are seizing SCA
to exercise some independence.
- IBM and
BEA both enjoy sizable market share in integration based upon
proprietary technology and an open ecosystem might erode their
installed base.
- JBI and
SCA are something quite different and really aren't competing
technologies. Comparing the two is like considering apples vs. oranges.
- JBI is a
container model for an Enterprise Service Bus (ESB) while SCA is a
model on how to assemble composite applications.
- JBI speaks
to infrastructure vendors who will build ESBs and containers like BPEL
engines that plug into them while SCA speaks to programmers and
architects who want to wire components together to field an application.
- JBI (as
the "J" implies) is targeted solely on the Java platform while SCA is
language-independent.
- JBI is
starting at plumbing and taking a bottom-up approach while SCA is
starting at the programmer and taking a top-down journey. Hopefully,
the two initiatives will meet in the middle without creating too much
overlap that will need to be resolved.
- Eventually
the SCA community will see that they need the runtime environment
provided by JBI and Sun will embrace the component modeling and
assembly work from
SCA. As a result, the JCP rift will be patched up.
All these made
sense to me. Certainly the motivations and general approaches
of JBI and SCA are quite different, but I kept wondering if there was
something
fundamentally different in the architectural principles that drive JBI
and SCA. So, I did what I usually do ... I pondered. I
poked around on the Web and landed on something that feeds my curiosity
about architectural underpinnings. The insight came from an SAP
employee's
blog
post on the SAP Community Network. The title of Jean-Jacques
Dubray's post is "Comparing SCA, Java
EE and JBI."
He points out
that there are three popular approaches to integration: invocation, mediation and activation and illustrates them
like this:
Invocation is
the most
well-travelled road. JCA (Java Connector Architecture) and JAX-WS
(Java API for
XML Web Services) serve us well here by
providing a request/response message exchange model in
particular. JCA became well-known as the
standard technique to extend a Java EE application server via
resource adapters to communicate with external systems. JAX-WS is
the follow-on to the popular JAX-RPC which provides a solid solution to
generating web services and clients based upon Web Service Description
Language (WSDL) or Java interfaces.
Mediation is
all about having a
message middleman acting as an intermediary between the consumer sending a message and
a provider responding to it. This is where JBI
fits. JBI's Normalized Message Router (NMR) is the mediator and
acts as a backplane into which service engines (SE) (like a BPEL
engine) and binding components (BC) (like SOAP/HTTP ) plug in.
JBI is a centralized architecture.
The JBI 1.0 specification was focused on providing a container
definition for an integration server where the container was assumed to
be running in a single JVM.
Activation is
the newest
approach. It seeks to provide an architecture where components
hosted on different middleware can interact as first-class
citizens. No centralized mediator is required. Components
in a SOA based upon activation can't rely on any specific middleware
features. SCA is apparently becoming a poster child for the
activation approach.
I was
particularly interested in Jean-Jacque's comments on
disadvantages he sees in the mediation approach. He says that
centralized approaches,
like JBI, often lead to the "who is to
manage the mediator?" question that has plagued B2B
implementations.
In
many traditional B2B scenarios, users are loath to pay for
mediation
unless substantial value-add services are provided.
Perhaps because Jean-Jacque is from
SAP, a SCA supporter, he
fires a shot
across the JBI bow as he notes that JBI doesn't address mediation
beyond JBI container boundaries. Hence, there's no distributed
ESB story. In his mind, JBI can solve only "small and local"
integration challenges. Zing, ouch.
In contrast, SCA
is a shining star for Jean-Jacque. Because of its
activation
roots, he touts SCA as more powerful than JCA, JAX-WS or JBI
because an SCA application:
- Has no
preconceived notions of system or company boundaries.
- Requires
no centrally managed mediator.
- Enjoys the
benefits of a mediation approach, but it's a decentralized mediation
that can happen at either the consumer or provider end with no
intermediary in between.
- Can handle
the complex integration challenges that JBI can't because of its
mediation architecture.
Well,
Jean-Jacques, where does this leave JBI? He answers:
- "We can
expect that Java EE and SCA will coexist offering a complementary
application model while JBI will be used in traditional Enterprise
Application Integration scenario."
In other words,
if all you want to do is plain old, boring, traditional
integration work in a Java-focused infrastructure, JBI will serve you
well. However, if you want to tackle more complex, decentralized
challenges, SCA provides a superior basis. Wow.
That's something more to ponder.
Bottom Line
I think that JCA, JAX-WS, JBI and SCA are all very powerful
approaches.
They
need to be in every architect's toolkit. In deciding the right
tool for the job, be aware of the appropriate integration
approach:
- The
invocation style can server particularly well with
request/response. If the interaction can be handled by the client
invoking web service endpoints,
JAX-WS can serve well. If the focus is really about extending the
Java EE application server to access an external system and web
services aren't necessary, JCA is great.
- Mediation
works well if you are building a composite application where an
intermediary needs to be involved in order to bring the appropriate
engines together to provide containers for services to execute.
JBI provides an excellent container specification for a framework
propulated with service engines and binding components like J2EE did
for the web container (servlets and JSPs) and EJB container (stateless,
stateful, entity and message-driven EJBs).
- Activation
focuses on enabling composite applications where an intermediary is
unnecessary. SCA is a very visible implementation of the
activation
approach for SOA.
Of course, the
JBI folks and SCA folks may be slow to come together. Rifts take
time to heal.
However, perhaps Jean-Jacques is on to something in his discussion of
the
three fundamental integration approaches. As I continue to watch
the SCA / JBI discussions, I'll ponder their relative contributions
to invocation, mediation
and activation.
The better we can make these three work
together, the better it is for developers and for the JCP. JBI
enthusiasts and SCA evangelists need to start talking
more. It's OK to say good things about the other guy's
technology! Neither effort will go away.