Connection and difference between SCA and jbi

See: http://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html

1. What is SCA?

Weakness of WSDL:

WSDL improves the connectivity and interoperability between applications. however, WSDL only focuses on one service interface, excluding any information about the service dependency on other services and the Policy Configuration between the service and its dependencies.

SCA, on the one hand, goes beyond the WSDL and defines the service component model and Service combination model. service Components go beyond the WSDL, allowing service developers to define service interfaces and their dependencies on other services, you can also define policies (transactions, secure, reliable transmission, etc.) between interactions, as well as potential configuration interfaces that the service can display.
SCA does not interfere with Service implementation. SCA components can be implemented in any language

Figure 1

SCA defines the standard-sca module for service assembly. In the past, component development obtained references between services and dependencies in a proprietary deployment descriptor or hardcoded manner to assemble services.

Figure 2

On the other hand, SCA defines a framework that allows developers to easily develop components in pojo mode: SCA provides a set of annotations, such as converting pojo into services, session management, and asynchronous communication.

For SCA, the implementation of components and Assembly metadata is unlimited and scalable.

Note 1: the implementation of components and Assembly metadata is unknown and scalable, so it is very convenient to extend the support for C # or other languages/models you want to use to implement services.

NOTE 2: SCA includes the concept of a binding: it allows multiple services to be assembled and does not require soap (SCA can provide special functions such as rest binding and Java binding, JMS binding .) These are further improvements to wsif.

2. Differences between jbi and SCA

One highlight of SCA is that it only focuses on what SOA developers see and what they come into contact. SCA does not focus on how the module of SCA is executed after being assembled. Execution can be performed on a single server. The server compiles the SCA service component into a Java class, or the execution can be implemented into a Modular Engine set (each component type is an engine) use ESB to make interactions between them.

In another aspect, jbi focuses on creating an open, scalable, and modular esb api set. Therefore, SCA and jbi seldom overlap at the core. On the contrary, I think they complement each other.

If they are complementary, why not integrate them? There are two reasons: 1) jbi focuses on assembling the engines running in the same JVM. On the other hand, SCA is not limited to one JVM, it enables the engine set to run well across different processes, or even on different nodes. 2) JCA not only supports Java, but also supports the implementation of other languages of the service, such as C. It will also support C # and PHP in the future. Therefore, jbi is not the only way to implement the SCA system.

Why do I like SCA?

WSDL is hidden under the conceptual Interface

Extends the concept of traditional interfaces to support Asynchronous interaction.

Loose coupling of modular, contains multi-language support

Developer-centered

Future development:

The SCA specification will be further developed. (Of course, keep it simple)

Jbi 2.0 recognizes SCA and serves as its service components and integration model.

SCA recognizes jbi and uses jbi as a new component and binding class in the Java-based SCA system.