In a blog posting, David Chappell (the David Chappell from Chappell & Associates, not to be mistaken for the Sonic/Oracle David Chappell) has posted his impressions from a panel on the Service Component Architecture (SCA) he moderated at JavaOne. David highlights the fact that SCA is composed of two things, namely
[...] a new programming model for creating service-oriented components in Java (and C++), and a way to describe how components are assembled into groups called composites. Composites can contain components built using SCA’s new programming models, but they can also contain components built using other technologies, such as Spring and BPEL. SCA doesn’t define a new programming model for these other technologies, however; it just describes how components built using them can be made part of a composite.
The relative value of SCA and JBI, the Java Business Integration, has been debated here on InfoQ before -- there is now an official statement as to their relation. In previous postings, Chappell has argued that SCA is a threat to Java EE. Both IBM and BEA, whose J2EE/Java EE investment is not being seriously questioned, are big SCA supporters -- but as David points out, this can mean different things:
One more point to take away from this is that when a vendor says they support SCA, you can’t know what they mean until you ask them. When Oracle says it, they seem to mean the technology’s assembly aspects. When BEA says it, they seem to mean the assembly aspects and the Java component model, but not necessarily the C++ component model. When IBM says it, they seem to mean pretty much everything in the current 1.0 specs. When Sun says it--well, I’m afraid I can’t tell what they really mean.
Google's Gregor Hohpe shared his impressions:
The programming model, much like Microsoft's WCF, provides a unified API for all kinds of distributed systems communication. In the Microsoft world this is a big deal, and rightly so. So it was a little surprising that the vendor support for SCA's programming model is at best luke warm. Even a lot of the "official" documents seem to downplay this aspect of the spec. Only IBM and BEA are really supporting both aspects while the others openly stated that the programming model is not their focus.
Hohpe also questions whether SCA really has something do with SOA:
When I looked at SCA before it totally escaped me that the spec assumes that a composite has to run in a single vendor environment. This limitation means to me that SCA has relatively little to do with SOA, which has to deal with an environment that is heterogeneous and not controlled by a single vendor.
Indeed it seems that SCA addresses a topic different from the typical "high-level" SOA aspects. While that doesn't mean it's not a viable technology, it begs the question whether the common-place association with the standards around SOA is really applicable.