What about this SCA thing?

Ever heard of SCA? Service Component Architecture? (Leave it to the English-speaking people to glom together 3 nouns and expect people to understand what that jumble of words is supposed to mean. In the glass-houses dept: shades of "Windows Communication Foundation." But I digress!). I've certainly heard of it. From time to time, people ask me, or those around me, what about this SCA thing? People ask, what does Microsoft think about SCA? Will Microsoft support SCA? How?

Well, at this point, it's hard to say. Before I get into why, let me give my take on what SCA is. SCA is another multivendor integration spec to come out of the Java community, along the lines of OSGi, ebXML, JBI (JSR-208), and JCA (JSR-16, JSR-112). Yes, I understand that SCA is more heavily service oriented than JBI or JCA for example. But still, SCA is about integration in Javaland, and it falls in that line.

Why is it hard to say whether or how Microsoft would support SCA? There are a couple reasons.

• First, the jury is still out. No one - not Microsoft, and not even the spec authors - no one is sure of the real value here. The various prior efforts from the Java gang (ebXML, JBI, JCA, and others) have exhibited different degrees of success in delivering value for customers. It’s not clear at this time how SCA will turn out. Sure, the specs are finished, to the extent that they are v1.0. But we've not seen a huge wave of products supporting the specs. We haven't heard customers saying - yes, "SCA is making the business benefits of SOA so much more attainable." Will SCA follow the model of ebXML? JBI? JCA? If SCA duplicates the success of the most successful of those prior specs, it will at best be a niche thing. But it could also be significant. We don't know.

• Another thing: SCA is primarily about Java. Sure, sure, the OASIS page says "SCA is about SOA". That naturally leads me, and probably lots of other people, to think "Interop". But come on, have you read the specs? There are placeholder-y things for C++ and PHP, but really these specs are mostly about Java. (Yes, specs, plural. SCA is a family of specs. ) SCA looks and feels to me like EJB++, in the same way that J2EE was CORBA++. SCA specifies a model for a services composite, and most of the context around that composite smells strongly of a cup of Java.

  Before you all get all huffy on me on this point, just stop and consider it. The Java focus of the SCA family of specs should not be surprising. Just follow the money. These specs are primarily being designed and driven by vendors - IBM, BEA, Oracle, Iona, SAP, TIBCO - who make money selling server-side Java infrastructure – J2EE and extensions to it.

  A big part of SCA deals with current complexity in Java and J2EE, particularly around connecting distributed components. Today, Java has myriad programming models for communicating among disparate pieces of a distributed application: RMI and RMI/IIOP; web-services via JAX-RPC or JAX-WS; asynchronous invocation with JMS; JCA for packaged apps or for proprietary systems like IBM CICS, and so on. This is not a knock on Java. It's a consequence of evolution of the platform. SCA's Java annotations spec and Java component model spec attempt to unify those communications models in a single programming framework. And hey, that's a good goal. There's nothing wrong with doing this. In fact this is a page right out of Microsoft's book - we've already done this for .NET with WCF. But let's be clear, this part of SCA is all about JAVA. (Great question: why isn't this piece being specified in the JSR process? That would seem to be the natural home for it??? ) In addition to that subset of SCA, there is the SCA spec for the Java client for Spring, the EJB Binding, the JMS binding. Java Java Java Java. A large portion of SCA is about Java.

• Another reason it is hard to succintly answer the "will Microsoft support SCA, and if so how?" question - SCA freely mixes the language-specific (aka Java) stuff in with the language generic stuff. When I saw this, I could only wonder, Why? This makes it pretty clear that the spec authors aren't interested in specifying a clean interop standard - something that cleanly and succintly describes how to interconnect apps. Instead SCA amounts to a portability and migration spec. How to map Java logic to services, and how to bring existing Java/J2EE apps into the brave new world of Services.

When will we know more? When might I have a better answer to the question, "will Microsoft support SCA, and if so how?"

That's hard to say, too. I know that answer may sound evasive (maybe it is part of my DNA). But look: I'd expect delivery of commercial-ready implementations of the SCA specs, from vendors like IBM and BEA, in late 2007, possibly later. But those would be small scale roll-outs - small in terms of number of installations. And of course small is a relative term. Alfred Chuang of BEA used to talk on his earnings calls of growing his customer base from 13,000 customers to 14,000 customers. This is great, but Microsoft counts its .NET developers in millions. Given that, if a hundred customers begin using SCA to good effect, is that enough to incent Microsoft to action on SCA? Probably not! What numbers would reach the threshold of interesting? I don't know.

To wrap up, SCA is primarily NOT about Interop. SCA is primarily about Java, and describing a new service-oriented metaphor for Java-based application logic. Something to succeed J2EE, which offered a metaphor grounded in components - Enterprise JavaBeans(tm).

We think Interop is important. Customers get good value when obstacles to interconnections fall away. We started working on XML and Web services standards, along with other industry leaders, back in 1999. We're committed to supporting Interop over open standard protocols, to deliver that customer value (case in point: WCF). (**We also so our best to support non-standard protocols, via adapters that connect to proprietary systems like SAP ERP, or IBM transaction systems and MQSeries. ) We're pretty sure SCA doesn't raise the bar in the interop arena.