Differences between jbi and SCA

Recently I am working on ESB development and found our product (Open Source celtix http://celtix.objectweb.org
)
Jbi and SCA standards must be supported. This left me confused for a long time. What is the difference between jbi and SCA?

A few days ago, I had a good time collecting information on the Internet. Now I want to share what I 've learned with you.
Enjoy:

Jbi definition http://www.theserverside.com/news/thread.tss? Thread_id = 35053

SCA
Difference with jbi http://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html

Upper
The link above has a detailed discussion. I have simply sorted it out.

The origin of jbi

Java One 2005 had a very heavy
Emphasis on JSR-208, Java business
Integration. However, he says,
"There seemed to be some folks
Confused looks on their faces in
Some jbi talks. "As a response, he's
Written a blog entry on what
Jbi actually is
Http://radio.weblogs.com/0112098/2005/07/07.html#a530
>.

Jbi
Is to provide some simple API definitions, including normalized
Message Service,
A Router component and a management model are used to manage services.
For example, routing engines, BPEL engines,
Rule systems, transformation Engines

Jbi provides a logical XML Message Network,
This network can be easily mapped
HTTP, email, and JMS/Mom, and can be easily adapted to legacy systems for binary transmission,
And RPC System
(EJB and CORBA ). Jbi can be seen as a high-level logic for JMS
Abstract, and provides different message exchange methods (single step, request response, etc)

What
Is it SCA? What problems does it try to solve?
WSDL makes a significant step in enhancing the connectivity and interoperability between applications.
However, WSDL only focuses on services.
Interface, which does not provide descriptions of other services that a service depends on,
And the dependency between the Configuration Policy and the service that this service requires.

Use the WSDL
It is difficult to implement combined calls between services.

SCA goes further than WSDL in terms of defining a service component model and a service assembly model. The service model provides more
Multiple features, which allow service developers not only to define service interfaces, but also to define dependencies between the service and other services, and these interactions (transactions, security, and reliable transmission) between policies
There are also configuration functions that may be provided by the Service.

An SCA model is equivalent to an SOA project. The model allows developers to assemble a set of service components to reference dependencies and use policies. This is
Great progress, because the current SOA platform requires developers to obtain private service deployment references, and sometimes write hard code in their service implementations.

SCA
Differences from jbi

The beauty of SCA lies in its focus only on SOA development.
SCA does not focus on how the runtime used to execute the SCA module is structured. This runtime can be implemented to compile all the SCA service components into Java
The ugly single service of classes, or a group of modular engines (one for each component), these engines can communicate through an enterprise service bus.

Jbi
On the other hand, it is a group of enterprise service bus that focuses on creating a development, expandable, and standard component.
In this way, its kernel is overlapped with SCA. At the same time, there is a complementary mechanism between the two.

If they are complementary, why not bind them together.
There are two reasons.
The first reason is that jbi focuses on assembling a set of engines and running them in a JVM.
On the contrary, SCA does not restrict a module to a single JVM.
An SCA module can be executed in a JVM, and it can also conveniently deploy these engines on different processes or even nodes.
The second reason is that
SCA not only supports Java but also C, and may support C # and PHP in the future. Jbi is only an implementation method of SCA, rather than the only choice.

 

Source: http://jnn.blogbus.com/logs/2010052.html