Service Component Architecture gets slapped around a bit

Service component architecture (SCA) is a good thing, right? Isn't it supposed to elevate SOA-ish things above Java and all that other those other bothersome languages with their own protocols, complexities, and latency issues?

Well, some analysts out there have professed that SCA has, well, issues. David Chappell, for one, says SCA proponents link their approach to SOA, but SCA is not necessarily about SOA. "Talking about SCA and SOA in the same breath is at best confusing. At worst, it’s downright misleading," David says. (By the way, that's David Chappell the .NET guru, not David Chappell the ESB guru, formerly of Sonic now with Oracle.)

Jason Bloomberg of ZapThink also recently had some unkind words about SCA. He also uses the occasion to take a swipe a JBI (Java Business Integration), noting that both that SCA and JBI are mostly about vendor politics and hype and should be ignored by SOA architects and developers.

SCA is intended to provide a model for the assembly of composite application development, which forms the basis of most SOA deployments. These composite applications may be based on collections of individual services. SCA is designed to address the need for control over access and security, and simplify the development of business services and Service Data Objects (SDO) for accessing data residing in multiple locations and formats.

So what's wrong with SCA joining the SOA party? For starters, at least for now, SCA components "must currently run within a single vendor's SCA environment," David points out.

Reliance on one vendor's container. Strike one. That's a real bad when it comes to SOA, which is supposed to liberate us from vendors' clutches. Make that strike two as well.

Jason delivers strike three against SCA, noting that the SCA camp, which is IBM, BEA, SAP, and some other players like Rogue Wave Software, are pursuing a Java agenda, versus a purely SOA agenda. He notes that while other languages (except .NET-based ones) are supported, SCA is "clearly driven by the big Java vendors outside of Sun and Tibco."

Possibly, Jason speculates, SCA may be "a way for this group of Java vendors to diminish the role that Sun has with Java." True or not, "neither JBI nor SCA is particularly well suited for SOA," he says. That's because SCA focuses on building components that consume services, he continues. "But it's not about building services. It's a component architecture -- not a service architecture."

BEA's Paul Patrick, however, considers SCA to be something different from JBI. In a chat I had with Paul last year, he pointed out that unlike JBI, the SCA specification is not limited to Java environments. “JBI is very Java-centric, and we believed that SCA needed to be neutral of any programming language,” he said. In theory, SCA works with any and all languages, including scripting languages such as BPEL, XSLT, SQL, and xQuery. The code in the composite application would not change, even if the supported service were migrated from EJB to a Web service.

The SCA specification is even seen by some industry observers as an alternative to Java Enterprise Edition.

Indeed, while Jason Bloomberg considers SCA to only be "marginally helpful," David holds out some hope for the architecture. "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."