David Chappell

  • September 2020
  • November 2017
  • April 2017
  • October 2016
  • March 2016
  • February 2016
  • August 2015
  • April 2015
  • December 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • January 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • January 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012
  • July 2012
  • June 2012
  • May 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • December 2011
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011
  • April 2011
  • March 2011
  • February 2011
  • January 2011
  • December 2010
  • November 2010
  • October 2010
  • September 2010
  • August 2010
  • July 2010
  • June 2010
  • May 2010
  • April 2010
  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • January 2007
  • December 2006
  • November 2006
  • October 2006
  • September 2006
  • August 2006
  • July 2006
  • June 2006
  • May 2006
  • April 2006
  • March 2006
  • February 2006
  • January 2006
  • December 2005
  • November 2005
  • October 2005
  • September 2005
  • August 2005
  • July 2005
  • June 2005
  • May 2005
  • April 2005
  • March 2005
  • February 2005
  • January 2005
  • December 2004
  • November 2004
  • October 2004
  • September 2004
  • August 2004
  • July 2004
  • June 2004
  • May 2004
  • April 2004
  • March 2004
  • February 2004
  • January 2004
  • December 2003

Opinari

Get the Feed! 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

 


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.
 

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.
 

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).
 

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.
 

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.
 

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.
 

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.
 

"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.
 

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.
 

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.
 

Post a Comment


<< Home