BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News JBI Spec Lead Criticizes Competing SCA Initiative

JBI Spec Lead Criticizes Competing SCA Initiative

In a blog entry titled "What's wrong with SCA?", JBI spec lead Ron Ten-Hove criticizes the Service Component Architecture (SCA). Some choice quotes:
The more I look at it, the less I like it. I have a couple of major reasons: it is too complicated, and it is a very poor approach to creating a service-oriented architecture.
SCA isn't a way to define a SOA: it is just another software component model. Give enough time, money, and consultants you could probably use SCA to realize a SOA, but SCA itself would be of little assistance along the way.
SCA is a poor choice if you are vested in Java, especially Java EE. SCA collides rather badly with technologies like JSR-181 JAX-WS, and EJB 3. At best SCA creates a more confusing story for Java developers; at worst it mandates a certain amount of rip-and-replace to fit into the SCA model & metadata requirements. This really forces the question: is this necessary? Unless someone can demonstrate why such pain would be worth enduring (and paying for!), I'd say the answer is a resounding NO.
In Ten-Hove's opinion, the key problem of SCA is its multi-language/multi-interface support. The Java Business Integration (JBI) specification, standardized in the JCP as JSR-208, originally had support from many vendors. IBM and BEA later withdrew and abstained in the Approval Ballot, both citing doubts about JBI's value contribution for their customers as the reason. The SCA initiative was started by IBM and BEA, with support from IONA, Oracle, SAP, and others. The latter three support both JBI and SCA. In the view of Oracle's Edwin Khodabakchian, described in a blog entry written at SCA's release, the two technologies are supposed to coexist:
One of the beauty of SCA is that it is focusing only on things that a SOA developer sees and touches. SCA does not care about how the runtime that is going to execute a SCA module is architected. The runtime could be implemented as an ugly monolithic server which would compile all the SCA service components into Java classes or it could be implement as a modular set of engines (one for each component type) communicating between each other using an enterprise service bus.

JBI on the other side is a set of APIs focus on building an open, extensible and modular Enterprise Service Bus. So at the core there is very little overlap between SCA and JBI. I would say in the contrary that they are very complementary.

Rate this Article

Adoption
Style

BT