Composite Materials

What's wrong with SCA?

I've been examining the Service Component Architecture (SCA) Specification version 0.9 for a while now. 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 is trying to fill an important hole: how do we create service-based composite applications? At first glance, SCA's model-based approach looks promising. Closer examination reveals something less appealing. Most of SCA's problems lie in its muddied definition of what a service is. In SCA a service is anything with an interface of some sort. That can be annotated POJOs, C++ code with metadata, WSDL, even COBOL (theoretically). The idea is to support multi-language composition. What SCA delivers is not the ability to MIX languages, but the ability to use separate languages within the same model. There is no support for, say, having my Java code call my C++ code. SCA provides no ability to cross language boundaries; you have to manage that yourself. Interoperability isn't supported, except within a single language/interface type. The title Service Component Architecture is quite misleading: this isn't about services at all. This is just yet another software component model, whose claim to fame is an attempt to define a similar component model for disimilar lanaguages.

SCA does start to approach some level of service-orientation with its support for the WSDL interface type, but there is no bridge between WSDL and the other languages, leaving a huge disconnect (Recent drafts of the SCA specifications have included a recommendation (not a requirement) that interfaces that are remotable include an equivalent WSDL interface). (SDO is advocated by SCA to address the data representation issues involved in interoperation, but this is a) only part of the solution, and b) optional, so of limited utility.)

Looking at this from an architectural perspective, the SCA model restricts reuse of what it terms services, increases overall cost of ownership, and represents an extremely poor integration strategy:

• Limits reuse. Making a service a language-specific construct couples consumers and providers at a fundamental level: the implementation language. Reuse is limited to consumers written in that language, and usually running in the same address space. Close-coupled components lead to limited reuse.
• Raises TCO. Every time you need to bridge the gap between incompatible languages/interface types (the so-called services), you incur a cost. Support multiple languages guarantees you'll waste a lot of time & money building new bridges between them.
• Poor Integration Strategy.With every added language/interface type in an SCA environment, you need to start building bridges between each of them to achieve interoperability. This is okay if you have only two or three language types, but scales badly as you add more: adding an (N+1)th language type potentially requires up to N bridges for the existing language/interface types. Worse yet, the consumers may be forced to provide such bridges, substantially raising the number of such bridges & client cost. The best strategy for scalable, manageable integration is to standardize on a single, implementation neutral interoperation technology, such as web services. Consumers and providers are decoupled from each other; their implementation languages are irrelevant. Adding a new provider (or adapting a legacy app) simply involves adapting it to web services. You build one bridge, not N. Consumers are ready to use the service.

This really comes down to how you structure your SOA. The SCA approach doesn't lead to SOA, for it doesn't even know what services are, its name not withstanding. SCA defines a jumble of tightly-coupled components (but multi-language!), and alarming gaps between components because interoperability isn't at the core of the model. 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.

Finally, 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.

Enough complaining. How do we fix SCA? For starters, throw out the multi-language/interface support. Cute idea, but very bad in practice. Instead, embrace only WSDL interfaces. This should get rid of about 80-90% of the junk in the spec. This leaves us with a much cleaner model for creating composite applications. What we are left with, beyond the simple compositional model, is the concept of "smart wires", the links between consumers and providers than have non-functional policies such as security, and some functional ones such as session-based affinities, to play with. Those "smart wires" are probably more interesting as operational features than design features, for the most part. If we leave them out, we have something that looks like a simple services composition model that features a kind of fractal aggragation pattern. That could be quite useful at design time. (Update: see more about SCA in part 2, "What's right with SCA".)

Standard disclaimer: I speak only for myself in this blog, not SMI.

Posted at 02:01PM Jun 29, 2006 by rtenhove in Service Oriented Architecture  |  Comments[5]