Opinari

Subscribe

Why Microsoft Should Not Support SCA  
# Saturday, September 29, 2007
 
Will Microsoft support Service Component Architecture (SCA)? It seems unlikely. After all, this new technology is controlled entirely by Microsoft's competitors. Still, even if Microsoft did decide to implement SCA, customers would see almost no benefit. Here's why.

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. This is an important point, but it's often lost (or misunderstood) in SCA discussions. Because some of SCA's supporters describe it as a standard for SOA, people assume it somehow enhances interoperability between products from different vendors. This just isn't true, and so Microsoft not supporting SCA will in no way affect anyone's ability to connect applications running on different vendor platforms.

But what about portability? Just as the various Java EE specs have allowed some portability of code and developer skills, SCA promises the same thing. Wouldn't Microsoft supporting SCA help here? The answer is yes, but only a little. To explain why, it's useful to look separately at the two main things SCA defines: programming models for creating components in various languages and an XML-based language for defining composites from groups of these components.

The current SCA specs define component programming models for Java, BPEL, C++, C, and COBOL. The only one of these languages that Microsoft fully supports is C++, a reality that significantly limits the value of SCA in the .NET world. Even if Microsoft chose to support the C++ SCA component model, not many people are likely to use it; C# and Visual Basic are far more popular choices for creating .NET applications. And while Microsoft could choose to define SCA programming models for C# and Visual Basic, what value would this bring? There'd be no portability outside the .NET world, since that's the only place these languages are really used. Besides, Microsoft already provides an analogous programming model for C#, VB, C++, and other languages in Windows Communication Foundation (WCF). Adding another one might well confuse its customers rather than make their lives better.

But what about implementing SCA's assembly model? Many SCA supporters argue that this is the most important aspect of the technology, so wouldn't Microsoft's endorsement benefit customers by allowing more cross-vendor portability? Once again, the answer is yes, but not much. The concrete expression of SCA's assembly model is the Service Component Definition Language (SCDL). SCDL provides a way to describe what components comprise a particular composite, specify bindings for those components, and more. Yet even in its full form, SCDL is a relatively simple language. Within a single vendor's SCA domain, much of SCDL can be optimized away, making it simpler still. (See my paper Introducing SCA for examples of this.) Vendors are also free to add their own extensions to SCDL, which they do. Even if Microsoft provided an assembly model, which they currently don't, using SCDL to describe it would offer at best minimal portability. 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.

There's a corollary here that's probably obvious by now. The big reason that Microsoft's support for SCA wouldn't much improve the portability of code is that SCA doesn't define much that truly allows that portability. (This is especially true for SCDL and the assembly model.) In fact, it's reasonable to wonder how much code portability will be possible across different vendor implementations of SCA. While some SCA skills portability will occur--at least everybody will be describing components and composites using the same terms--I'm doubtful that SCA will do much to help move applications from one vendor's SCA product to another. Put another way, don't look to SCA to play a big role in reducing vendor lock-in.

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.

10 comments :: Post a Comment