David Chappell

Opinari

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

Comments:

"Put another way, don't look to SCA to play a big role in reducing vendor lock-in"

I completly agree with the above quote in your article. I just think these vendors just made each one of thier lives easier by inventing a composition model which they are in desparate need for in wholly new and complex services world. They came together on the pretext of portability and they don't care much about it anyway. However at leaset they got some simple assembly model now which can be used in/for thier products. Thanks.

# posted by Anonymous : September 30, 2007 9:15 PM

If you look at it from an IT management perspective, SCA provides value in addition to whatever code portability it brings. It provides a model of the composite application that is at a level of granularity appropriate for automation of management tasks. The full story is too long for a comment, so read it here: http://stage.vambenepe.com/archives/125.

# posted by Anonymous : October 01, 2007 5:21 PM

William Vambenepe, a management architect at Oracle, raises an interesting point. If I understand his blog entry correctly, he's arguing that if Microsoft provides a SCDL definition of composite applications, management software would be able to learn about the structure of future Microsoft composites in the same way it might learn about composites running on SCA systems from Oracle, IBM, BEA, or anybody else.

Yet SCDL files aren't designed to allow this. Vendors can optimize away parts of SCDL within their domain and add extensions, for example, and there's no standard way to access SCDL files from other systems. To rely on SCDL for this kind of information seems dangerous to me.

SML, by contrast, was designed for problems like this. Creating a standard way to describe composite applications in SML would seem to be a much safer path. In fact, Microsoft does something much like this today with service monitoring in System Center Operations Manager (which you can read about here if you'd like).

# posted by David Chappell : October 01, 2007 9:10 PM

David, I am very aware that, unlike SML, the SCA artifacts were not designed for the purpose of helping the management infrastructure. But that won't stop me from using them if they are useful for management. Sure, it would be great if developers bought into the need to "develop for management" and remembered to include all kinds of useful metadata for the consumption of management tools when they design or write their code. But in real life, that doesn't happen very often. But developers who use SCA don't do it to help the operations folks. They do it for the extra help and flexibility that they get from the platform (and maybe for portability, but I doubt that's the main reason). And since there is something in it that directly benefits them, they are a lot more likely to generate these artifacts than if it's just to help the operations crew.

Now I am sure Microsoft is well aware of this and maybe they'll figure out a way to convince Visual Studio developers to generate a nice SML model of their app by providing extra development-time features or extra help with generating an installer if there is such a model. I'd love it if they did and I'd be very happy to feed that SML model into my management tools.

But I won't wait for that to happen in order to get all the usable metadata I can for app management. And SCA is a good source, among others. And sure some companies will have their own SCA extensions that I may or may not understand. Why is that a problem? If SML takes off, you'll also see plenty of platform-specific SML extensions.

If I need a rope and all I have is electric wire, I'll use it even if it wasn't meant for that purpose.

# posted by Anonymous : October 02, 2007 10:09 PM

I admire your resourcefulness, William. I know that you management guys are used to heavy lifting, something that perhaps SML and good tooling will some day change. In any case, I hope you're able to derive some value from SCA's SCDL definitions.

# posted by David Chappell : October 04, 2007 8:43 PM

David,
I posted a reply to your latest comment on the infoq. Also, a minor quibble - as far as I could tell SCDL is perhaps no longer the official term of the composite configuration as per the 1.0 specs - a composite configuaration is now described in, surprise, surprise, a .composite file.

# posted by Unknown : October 05, 2007 10:51 AM

For anybody who's interested, the InfoQ article and discussion that Satadru refers to is here. I've posted a response there, too.

And the SCA specs say that a file containing SCDL should have a .composite extension. SCA's creators don't all promote the term "SCDL", which I think is a shame: It's very useful to have a name for the language. The later specs use this term more; see the Policy spec, for example.

# posted by David Chappell : October 05, 2007 1:07 PM

"After all, this new technology is controlled entirely by Microsoft's competitors."

Seeing as Microsoft tends to view pretty much everyone else in the industry as a competitor, this statement is going to be true of everything new that Microsoft doesn't invent itself.

# posted by Anonymous : October 07, 2007 2:33 AM

Whether Microsoft or any other vendor chooses to support a particular standard isn't a moral issue--it's a business decision (a point I've made before). And Microsoft does sometimes work with others on standards, such as with the WS-* specs. Still, would any vendor who had a choice tie its commercial fate to a standard over which it had no influence? It's a safe bet that Microsoft, like every other vendor, will embrace only those standards that it feels are in its interest.

# posted by David Chappell : October 07, 2007 4:59 PM

The other question WRT to SML, however, is if its specific enough to talk about being consumed in a general way by management tools. You can argue the validity of using SCA in the management context, but at least it is reasonably specific in terms of the structures it defines. SML is a modeling language, but the semantics that can be inferred from the language as it stands are very general. Specific semantics such as are implied by SCA are not present and would likely be very different in each different vendor's models described using SML. The answer (as is often the case) is probably somewhere in between.

# posted by Anonymous : October 08, 2007 5:02 PM