Friday 8 June 2007

SCA: flexible, extensible, and useful for ordering a beer

This is my first ever blog post so I'd like to start by introducing myself. I'm a member of the Apache Tuscany developer community and I've been involved with Tuscany since the project started in 2005. I'm also an IBM Distinguished Engineer and I have worked on so many software development projects over my career that you really don't want the complete list (trust me). I'll just mention two of these into which I put an especially large dose of myself, with rather different results: RMI-IIOP, which brought together Java RMI and CORBA, became part of the Java platform, and is used by every JEE application server; and Object Rexx, which broke new ground technically for object-oriented scripting languages, but never achieved its full commercial potential for various reasons including the success of Java.

My passion these days is for Service Component Architecture (SCA) and I have started this blog to give my perspective on SCA and explain why it is an important step forward for building distributed applications in a service-oriented style. The views I'll express here are my personal opinions and don't necessarily represent IBM's positions.

Others (Dave Chappell here, Mike Rowley here, Sanjay Patil here, and Steve Kinder here) have expressed their views on whether SCA is a new programming model or not. For me the main value of SCA is not the programming model "in the small" (whether new or not new), but rather that SCA provides a common framework for bringing together assets from a wide range of technologies to create a solution that delivers business value. This isn't a new concept (remember CORBA?), but SCA puts a different spin on it with a framework that's designed for extensibility and isn't prescriptive about using any particular underlying technology. SCA strikes the delicate balance between defining a consistent set of common high-level SOA concepts and being flexible about how these concepts are rendered into different implementation environments that participate in the SCA ecosystem.

CORBA specified IDL for interface definitions and IIOP for the wire protocol. To come to the CORBA party, you needed to be able to define your interfaces using IDL and speak IIOP on the wire. RMI defined its interfaces using Java and spoke the JRMP protocol on the wire, so RMI-IIOP was created to allow RMI to become part of the CORBA ecosystem. With SCA, this uniformity of interface definitions and wire protocols isn't required. The architectural constructs that SCA defines (services, components, references, bindings, interfaces, implementations, composites, wires, policy intents) are designed to be flexible and extensible so that different SCA implementations can render them in different ways into the lower-level specifics of that implementation.

These renderings could differ significantly for different implementation technologies. The SCA 1.0 specs define renderings for Java, BPEL, Spring and C++ as implementation types, and Web services, JMS and EJB as protocol bindings. This set will grow in the future, but SCA usage doesn't need to be bounded by what the spec supports. There's a PHP implementation of SCA, providing a rendering that makes sense in a lightweight scripting environment. The scripting theme also surfaces in Apache Tuscany, which provides SCA renderings for various scripting languages including Ruby, Python, JavaScript and Groovy, as well as the more mainstream support for Java, Spring and C++ that's defined by the SCA specs. In the last week I've seen interest in implementing SCA support for OSGi, and having XSLT transformations as SCA implementations. You can think of SCA as a "lingua franca" for SOA that brings all these technologies together, not at a low level of interface definitions and wire protocols, but at a higher level of assembling, composing and customizing services.

What if some implementations only provide a partial rendering of SCA? Is this OK, or should SCA insist on a strictly defined minimum set of capabilities that everyone needs in order to come to SCA's party? The discussion on this will get going at OASIS soon (the SCA 1.0 specifications don't specify compliance points), so there's no official SCA position on this yet. I understand the value of uniformity and tight specifications, but I'm inclined to think that SCA shouldn't be too rigid and prescriptive about this. Imagine two people talking in a natural language such as English or French, who aren't native speakers and have an imperfect grasp of the language they are using, but can still communicate well enough to get by in their conversation. I was in Italy some years ago trying find a particular village, getting lost on back roads in deepest rural Tuscany, and trying to ask directions from an Italian man who spoke no English. My Italian is pretty bad too (I can manage "una birra, per favore"), and despite best efforts on both sides, it just wasn't going to work. My wife had a brainwave and started talking to the man in French. Success! The Italian man and my English wife both spoke enough French to ask for and receive the directions. Applying this to SCA, if different environments speak different dialects or subsets of SCA, there needs to be enough overlap and mutual understanding to "get by" for some business purpose, but how much shared vocabulary is needed will depend on the particular needs of the services involved. Some environments will provide a full implementation of SCA (fluent native speakers), and others will have just enough vocabulary and grammar to be able to order a beer. More fluency is always better, but let's also remember the greatest values that SCA has to offer: its flexibility, extensibility, and inclusivity.