X
Business

Why doesn't Microsoft get in on the Service Component Architecture action?

Microsoft supporting SCA is about as likely as an embrace of Enterprise Java Beans would have been a decade ago. There's not much there for Microsoft to embrace
Written by Joe McKendrick, Contributing Writer

Microsoft is pretty well known for creating its own bandwagons, not jumping on someone else's. But if Microsoft is really serious about SOA, shouldn't it at least get in on the Service Component Architecture action? After all, SCA is about moving the SOA service code base away from specific languages, such as Java.

'Microsoft supporting SCA is about as likely as an embrace of EJB. There's not much there for Microsoft to embrace.'

David Chappell, the .NET guru, says this would be a bad idea at least for Microsoft and its customers. In a recent post, Dave points out that first of all, SCA is supported by Big Red's competitors. Strike one. The second is that Microsoft customers would see no benefit from such a move, he says. At least those customers who rely mainly on Microsoft environments.

"Microsoft supporting SCA today is about as likely as an embrace of [Enterprise Java Beans] would have been a decade ago," David says. "Yet even if the company wanted to, there's not much there for Microsoft to embrace."

First of all, SCA has nothing to do with interoperability, which is key to Microsoft's SOA and Web services strategies. "SCA is purely about portability," relying solely on Web services standards to connect applications across vendor boundaries, he says.

There wouldn't be a whole lot of value for Microsoft customers if the vendor supported SCA's programming model, nor its assembly model, David adds. Current SCA specifications do define a component programming model for C++, but's that it as far as Microsoft languages go. The other languages supported include Java, BPEL, C, and COBOL. Most .NET applications are built with C# and Visual Basic.

Why couldn't Microsoft simply define SCA programming models for C# and Visual Basic, then? This would be a fairly empty move, David continues. "There'd be no portability outside the .NET world, since that's the only place these languages are really used."

Maybe other unforeseen forces could bring -- or force -- Microsoft into closer alliance with the Java and SCA world. There are many sites that need to support both Java Platform and .NET Frameworks, and they may begin pushing vendors harder to bring the two worlds closer together.

Then there's the strange bedfellows that industry consolidation makes. The other day, ZDNet blogging colleague Dana Gardner urged Microsoft to consider buying BEA Systems, a move that could bring together the Java and .NET camps, and bring about a sort of neutrality into the platforms that underpin SOA efforts. Of course, since BEA is the greatest promoter of SCA, this would pose an interesting dilemma to such a vendor combo early in the marriage.

Editorial standards