April 26, 2007

Service component architecture

I've been puzzling for some time what the point of the Service Component Architecture and Service Data Objects, standards from the Open SOA alliance are "really" for.

SDO I sort of understand: it's a cross-language data binding API for services, competing with Microsoft's ADO.NET.

SCA on the other hand, has been quiet for a long time, though 1.0 was released on March 22. For a while, I thought it was a way to wrest control of the deployment model for component software systems away from Java, to enable a truly cross-language containment and configuration of distributed systems. It still is this, to some degree: component implementations so far can be in (simple) Java, Spring, BPEL, C++, though Java remains a kind of unifier.

But it's clearer what else it is, from my first read of the 1.0 specifications. This is my first impression, not necessarily canon:

- It's a specification for how services & dependencies, with different kinds of transport or transfer bindings, can be assembled, wired together, and deployed when within the control of a single agency.

- It specifies how implementation technologies (not just Java) can implement service capabilities.

- Thus, SCA a framework that treats services logically - not just as web services. WSDL can serve as the cross-process interface definition, but a Java interface can serve as a service interface for "in-process" SOA.

This enables multiple implementations, whether C++, Java, or eventually PHP, Ruby, etc. to have bindings and in-process exposure to any other SCA component registered within a Java virtual machine itself, or out-of-process exposure via WSDL/SOAP or a custom interface type & binding.

In practice, this means no more futzing with JNI or JAX-WS when integrating disparate components, the SCA plumbing will take care of this wiring and type marshalling. Though you'll either have to wrap your implementation with the SCA API or conform to a particular interface binding.

- It's an attempt to show that Spring dependency injection and OSGI bundles can serve as the plumbing needed to make the JVM itself a bus between in-process services, so long as the interfaces are published and evolved independently from the implementations.

- It's another run at the Beehive fence, in an attempt to create a productive development and deployment model for services that competes with Microsoft.

Five years ago, BEA came up with a crazy idea to make Java web service & web development as productive as .NET 1.0 -- the result was WebLogic Workshop (WLW) and its notion of "Controls". While WLW was a modest success, Beehive spent ~2 years in proprietary incubation at BEA as the "Weblogic Workshop framework" before being spun out to Apache, which tainted its adoption, as it was largely tied to an IDE and had a set of newish code annotations (which Java didn't have support for back then).

This time, SCA seems to be much further ahead: with a broader mindset that includes multiple implementation technologies, lifecycle and deployment going beyond EJB, a richer competitor to compare with (Indigo / Windows Communication Foundation), and long list of partners at the table besides BEA, including some of its biggest competitors.

This is definitely the kind of innovation that the SOA community needs. It is open minded enough to enable many representations of service interfaces, implementations, and bindings. SCA unfortunately doesn't focus on network-scale service interoperability with RESTful interfaces, but I don't think it will necessarily prevent the adoption of it once the industry gains more understanding of how a programmatic RESTful interface, implementation & binding should look (beyond a Servlet ;).

Posted by stu at April 26, 2007 06:46 AM