David Chappell, from Chappell & Associates, started a debate on SCA by reasoning that "Microsoft Should Not Support SCA".
The Service Component Architecture (SCA) was originally created by a group of vendors, including IBM, Oracle, BEA, and SAP, and has been handed over to OASIS in March 2007. SCA defines a programming and assembly model for developing and composing services within a Service-oriented Architecture. Services, or Components, may be developed in Java or any other programming language that supports the SCA programming model, i.e. any language whose binding has been specified by the SCA specs.
The SCA programming model has been defined by Microsoft's competitors, who control the specifications, and whose main focus is on portability of code rather than interoperablity according to Chappell. The only .NET language supported by SCA is C++, which does not play an important role in the .NET world. Even if Microsoft would design a C# or VB.NET binding, nothing will be gained in regard of portability, because both languages are bound to the homogenous Microsoft platform. In addition Microsoft already provides an analogous programming model: Windows Communication Foundation.
First, it's important to understand that SCA is purely about portability--it has nothing to do with interoperability. To connect applications across vendor boundaries, SCA relies on standard Web services, adding nothing extra. [...] and so Microsoft not supporting SCA will in no way affect anyone's ability to connect applications running on different vendor platforms.
The assembly model, which is defined by the Service Component Definition Language (SCDL), does not add to interoperability either:
The language just doesn't define much. And since all of the components in a single SCDL-defined composite must run on the same vendor's infrastructure, Microsoft's lack of support doesn't affect anyone's ability to define SCA composites that include both, say, Java and .NET components. This wouldn't be possible even if Microsoft did support SCDL.
SCA's focus on portability is the main reason, why neither Microsoft nor any customer would benefit from Microsoft embracing SCA:
Given the competitive realities, Microsoft supporting SCA today is about as likely as an embrace of EJB would have been a decade ago. Yet even if the company wanted to, there's not much there for Microsoft to embrace. Given SCA's complete focus on portability rather than interoperability, the set of programming languages it supports, and the minimalist nature of SCDL, Microsoft's support of this emerging technology would provide almost no benefit to customers.
Stefan Tilkov agrees and even poses the question "whether the whole thing is worth the effort after considering his [David Chappell] arguments". In his follow up Stefan states that "Interoperability clearly tops portability" and he is doubtful about the success of SCA:
To me, a portable, cross-platform assembly model and programming model has no chance to succeed — there’s just too much agreement requirement for our industry. [...] it seems there was no clear vendor advantage to CORBA, either … which somehow did not make MSFT ever join it, either.
William Vambenepe responds that although SCA is not for interoperability, it "is not just for code portability". He sees an advantage to SCA from an IT management point of view:
it’s a machine readable description of the logic of the composite application, at a useful level of granularity for application and service management. This is something I can use in my application infrastructure to better understand relationships and dependencies. It brings the concepts of the application world to a higher level of abstraction (than servlets, beans, rows etc), one in which I can more realistically automate tasks such as policy propagation, fail-over automation, impact analysis, etc.
In this regard Microsoft might very well benefit from supporting SCA according to Vambenepe. He thinks that a Microsoft effort to support SCA would make it a lot easier for him ", and all the management vendors, to efficiently manage composite applications that have components running on both Microsoft and Oracle, for example". Don Box is asking for arguments in favour of SCA and is not convinced by Vambenepe arguments.
It will be very interesting to see how SCA will influence the SOA market and how Microsoft will finally respond to the debate. The SCA Interview with SCA standards members and users, published on InfoQ today, addresses some of the issues of the SCA debate and gives further insight and understanding of SCA's role and future.