from http://www.osoa.org/display/Main/Relationship%20of%20SCA%20and%20JBI
The objective of this note is to provide background on SCA's
relationship to the JBI standard defined by the Java Community Process
JSR 208 - Java Business Integration. This relationship can be summed
up in two statements:
1. Supporters of SCA view JBI as a Java Platform standard that can be helpful in implementing SCA on the Java platform.
2. Supporters of JBI view SCA as providing additional service
metadata that can help simplify and standardize service composition
within the Java Platform and between the Java Platform and other
platforms.
Both SCA and JBI are focused on helping developers construct and
compose services so it is natural to assume that they are competitors;
however, this is not the case. While both can be used separately, they
are also effective to use together because they focus on different
aspects of the larger service composition problem.
The reason this is possible is that SCA and JBI target different
audiences. The SCA specifications target end users. They describe how
to implement, assemble and deploy applications composed from
services. As such, the target audience for these specifications is
people working in the roles of developer, assembler and deployer
respectively.
SCA allows multiple technologies to be used to implement services
(e.g. Java, BPEL, C++) and multiple bindings for communicating with
services (e.g. Web services or JMS). However, SCA does not describe
how you would introduce a new implementation type or new binding into a
runtime. This is exactly where JBI is targeted.
JBI is a Java Platform integration 'micro kernel' standard that
provides an open architecture in support of multi-vendor Java Composite
Application Platform tools and infrastructure. It defines a set of
service provider interfaces for middleware providers to implement if
they want to install new service engines (which correspond to SCA's implementation types) or binding components (which correspond to SCA's bindings) into a JBI-compliant runtime.
How SCA and JBI can work together
As SCA asserts, its service component metadata is platform
independent so it is possible to use it with any service implemented on
the Java Platform.
The focus of JBI is to provide an extensible Java Platform server
facility that simplifies how multiple server-side programming
facilities such as Servlets, EJBs, JavaScript, BPEL, business rules,
data transformation, etc. can work together within a Java Server
environment. This allows a Java server-side application to mix-and-
match the facilities it needs to effectively implement its function.
JBI is a set of Java SPIs used by the implementors of a Java Server
and its constituent technologies and is not designed to be exposed
directly to developers.
The result is that JBI is Java run-time server infrastructure that,
like other platforms, has the potential to support SCA service
composition metadata. There is nothing in JBI's run-time architecture
that conflicts with SCA.
Those who have looked closely at JBI will know that it does define a
basic form of metadata used to describe the packaging of a service
application. This metadata is used by tools to describe applications
that require a JBI run-time. This is a very basic set of metadata
described in a few pages of the JBI spec and was limited to minimum
needed to support JBI application deployment. In the few cases where
SCA and JBI metadata overlap it would be practical for JBI to treat SCA
metadata as an additional source of this information.
The bottom line is that JBI should be considered a Java technology
that potentially helps middleware vendors implement SCA. JBI and SCA do
not compete with or conflict with each other.
Do I need both JBI and SCA?
In a word - "no". SCA runtimes can be implemented without utilising
JBI. Equally, JBI runtimes can be constructed that don't implement
SCA. However, using them together in a runtime for the Java platform
can be an effective approach, suiting the needs of both application
developers and platform builders.
There are some clear cases where an SCA runtime would not utilise
JBI. SCA supports implementation types that do not naturally run
within a Java Virtual Machine. C++ is an example of such an
implementation type. Such an implementation type would typically
execute within a runtime implemented using C++ or C technology. JBI
addresses runtimes that must be capable of running on a Java Virtual
Machine. SCA can support a system which potentially does not use a Java
Virtual Machine at all. This might be the case for a business where all
the service components are written in C++.