ESB vendors’s response to SCA

Most of the key ESB vendors are already participating in finalizing SCA 1.0 specifications. The list contains on Oracle, IBM, BEA, Tibco, Sun, Iona, Progress (Sonic), Jboss (Redhat), CapeClear, and more. (You may find a latest list at http://www.osoa.org/display/Main/Service+Component+Architecture+Partners)

Most of them see a value in SCA as a promise to have standard for a simplified and powerful Component model to assemble SOA based applications/integrations. They understand a need of a common framework to connecte and assemble SOA components together so as to deploy on various middleware including their ESBs.

(http://www.osoa.org/display/Main/Partner+Motivations)

The commitments from different participants may vary significantly. Some may participate to provide inputs and be part of standardizations with two fold focus: one to influence the direction and another to align their products. Some of them may start implementations based on SCA specifications. The early participants like IBM, BEA and Oracle would offer solutions based on SCA earlier than others. Apache open source’s Servicemix allows deploying SCA composite in its container. Other vendors may work on aligning their products to support SCA. However, some vendors may play wait and watch to see a market adaption and provide a choice when customers demand.

Irrespective to their commitment, they may support SCA differently.

There are three broader possibilities.

1. Build a platform based of SCA foundation: A compatible to SCA in a way SCA as a first class citizen. Such platform can be a monolithic or a modular with different engines for different component types like BPEL, Java, etc. Such implementation would directly use SCA assembly metadata.
   
2. Deploy SCA on their container: support deployment of SCA composite in their container. In this model, as a part of deployment, a container would consume SCA composite but may transform to its own runtime metadata.
3. Integrate: Integrate with SCA based container but the SCA based container is outside the core platform.

Many of ESB vendors took one of these approaches (or a last one “do nothing”) for JBI. For example, ServiceMix is based on JBI while Oracle ESB 10.1.3 provides a JBI container to integrate with ESB.

Here, I am giving a reference to JBI as an example of ESB world’s response to a standard specification. JBI and SCA have some overlapping and some complementary functionality. JBI and SCA is another subject to discuss in detail. Since we are on the subject, I would make a passing note that JBI provides a framework and runtime specifications mainly for integration architects and middleware runtime platform (SPIs) so that runtime containers can be interconnected. SCA specification does not dictate a runtime implementation. One may enhance a JBI based runtime for SCA. There is a little overlap but a very good value addition.

In Summary, SCA is a very good specifications for ESBs to provide SOA platform. We may see some innovation from ESB vendors while implementing it.

SCA

ESB