SCA vs. SOA?
Tuesday, May 22, 2007
Service Component Architecture (SCA) is commonly described as being a technology for SOA. The group that created it christened themselves the Open SOA Collaboration, a name that clearly indicates their stance. In fact, the first sentence of this group’s SCA web page
says that it describes “a model for building applications and systems using a Service-Oriented Architecture”.
I understand the need to link new technologies to SOA today—it’s a great way to get attention. The problem is that talking about SCA and SOA in the same breath is at best confusing. At worst, it’s downright misleading.
To see why, understand that SCA defines an abstract component model, then specifies how those components can be assembled into larger groups called composites. The components that make up a single composite might all run in the same process, they might be spread across different processes on the same machine, or they might run on different machines. In all of these cases, SCA’s assembly model defines how components in a composite relate to one another, specifying things like how those components should be wired together. In effect, it allows treating a group of possibly distributed components as a single unified application.
The applicability to SOA is obvious, isn’t it? As the notion of “application” increasingly refers to a group of services provided by software on various machines, having some way to define the relationships among this software is appealing. And because an SCA composite also defines a deployment unit, it can help make managing this new kind of application easier.
But there’s one problem: While the SCA specs don’t strictly mandate this, in practice all of the components in a composite must run within a single vendor’s SCA environment. This limitation isn’t obvious from reading the specs, so just to make sure, I asked this question of the participants on the SCA panel I moderated at this year’s JavaOne conference. All of them publicly agreed. While things could change in the future, at least for now, an SCA composite is a single-vendor construct.
A primary reason for this is that the SCA 1.0 specs
focus on portability, not interoperability, and so they don’t fully define the interactions between components necessary to create composites that cross vendor boundaries. This means that I’m free to create a distributed application that’s wrapped into an SCA composite, and even to allow the services that application provides to be accessed from other vendor platforms, as long as all of its components run on a single vendor’s SCA container.
What does this have to do with SOA? The answer is simple: not much. Multi-vendor services are the sine qua non of SOA . If an SCA composite can't be assembled from them, it’s not an SOA technology.
So does SCA improve the SOA picture in any way? I think the answer is yes, for a couple of reasons. First, even though its internals remain a vendor-specific black box, how a composite interacts with the outside world can be specified in a service-oriented way. And along with its assembly model, SCA also defines a new programming model for creating Java components. This component model allows building business logic in a modern, service-oriented style, similar to Microsoft’s Windows Communication Foundation (WCF)
. Just as WCF makes it easier to create service-oriented applications on the .NET Framework, SCA’s Java component model can make it easier to create service-oriented applications in the Java world. Although it might not be fully supported by all of SCA’s creators
, this approach nonetheless counts as a step forward.
SCA has the potential to be an important technology. By defining a modern, explicitly service-oriented approach to creating business logic, its Java component model can help Java developers build better applications for an SOA world. But as long as composites can contain only components running in a single-vendor environment, SCA’s value as a technology for SOA is limited.