Relationship of SCA and JBI
from http://www.osoa.org/display/Main/Relationship%20of%20SCA%20and%20JBIThe 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++.