The Deployment Descriptor on Steroids...

Well.... the thing that I had been hoping to see for some time now happened yesterday... Oracle, IBM, Sybase, Siebel, BEA, SAP and IONA announced support for the Service Component Architecture (SCA). SCA is at the heart of WebSphere Process Server and so I've been exposed to this technology for some time now.

Why do we need SCA? What problem does it solve? What's wrong with WS-*? JAX-RPC? J2EE? etc, etc, etc.

The links above are worth looking at for the "official answer" - and the reasons are good. However, the motivation for SCA that I give is usually as follows. I'm not claiming this is the real reason it was invented or that this is necessarily the most important aspect but I've found it useful for my own internal thinking.

So here goes....

Let's imagine we're starting a new development project. We've heard all about SOA... perhaps there is even an existing SOA initiative in our organisation. Perhaps several key services have already been exposed (and advertised) as reusable services. Perhaps there is even some governance in place around them. Excellent.

We start to design our system and we realise we can use these services in our application. That is: we will be building a composite application that contains both new code and invocations of existing code... we will orchestrate the execution of services hosted elsewhere if you like.

Two immediate technical questions arise. 1) How do we invoke these services? 2) How do we build our own application such that it isn't monolithic but can, in turn, provide services to other users in the enterprise?

Today, the answer to the first question will vary based on who you speak to. But the answer usually comes down to some API (JAX-RPC? JMS? EJB calls? whatever...) and some meta-language for describing the service (WSDL?). This is just fine... as long as you're happy to treat these services as end-points.

But what happens when we look at our own piece of development work? It is likely that we will be trying to build a modular solution which consists of various "chunks" of functionality and we may even wish to regard these pieces of functionality as services in themselves. That is: we will use this new functionality but it's sufficiently coarse-grained to make parts of it suitable for exposing to other users in time.

The big problem, however, is that these components are not just end-points.... they are components that provide both a service and which have dependencies. This is a problem since we're writing this application! It's up to us to satisfy these dependencies.

What SCA does is allow us to write our applications as we always have done if we choose (Session Beans, chunks of java, whatever makes sense for each component) and attach a descriptor to each component in the application which contains several pieces of information: the interface provided by this component and the interfaces it needs to call in order to perform its work. This descriptor contains other information but these two aspects (the interfaces and references) are the key.

They are key because it means we now have a consistent way to build and package components that provide and consume services. Even better, since we now have a useful descriptor for each component, we can create tooling to facilitate the building of such applications - the descriptor (the ".component file") tells the tooling all it needs to know to allow users to "wire" components together.

Now, a secondary benefit of this is that we now have a unified API for invoking services (a component merely says to the runtime "give me the service which implements this interface that I am dependent on - and wired to" and the runtime is responsible for taking care of the invocation, regardless of the actual technology in use). However, this benefit really is secondary.

So, to my mind, the big step forward with SCA is not the "extra layer" or the "unified API". Rather, it's the fact that we now have way of describing components and for wiring them together to build composite applications that is consistent whether we're programming "in the large" or "in the small" - and which extends service-orientation from the end-points into the heart of an application in a unified manner.

Of course, not everybody seems to think this is a good idea :-)