Composite Materials

What's right with SCA?

My last posting expressed some of my misgivings about SCA, but also alluded to some features that I consider to be useful in SCA. In this posting, I'll expand on those.

SCA's design centre is a useful one. It is focussed on the design-time task of creating a model of a composite application. Unlike UML, the SCA model (plus a bunch of non-specified deployment information) is sufficient to generate an executable version of the model. SCA only touches on run-time aspects of executable version of the model; run-time is a secondary focus of SCA. Design-time is primary.

Why is this model-based approach useful? It helps developers. Whether I'm developing a service to used in this model, or am developing the composite, it reduces the number of functions the developer must provide to make the service (or composite) work. The model is an abstraction of the executable system. The details that make it deployable and executable are supplied later; meanwhile, the developer can stay focussed on his particular tasks & specialties.

I also find useful the concept of "smart wires" linking service consumers to providers. The wires provide more than a simple endpoint address; they provide a place to inject all those messy, non-functional policy items into the system. Things like security, auditing, and service-level agreements. These are not part of the service providers or consumers, but properties of the wires that associate them in the model.

Why is the "smart wires" model useful? Once again, it help developers. By separating out non-functional concerns from the core logic that provides (or consumes) services, the developers have less things to cope with. Getting business logic right is tough enough, and is core to why businesses have IT shops/vendors/consultants in the first place. Trying to also deal with non-function stuff (security, SLAs, QoS, regulatory compliance, etc.) just steals time and enery from the developer, keeping him from his core task. Also, security policies ought to be implemented by a security specialist, and it is hard to find good developers who happen to also have security expertise.

The smart wires model helps with the software development life cycle, as well. When policies change, it is very expensive (and risky) to have to touch the core service logic to accomplish this. Generally you need to go through a full development / test / validation cycle before you can redeploy the application. By putting the policies into the wires, core logic code is not touched, so risk is much reduced. It is also much easier to reason about the impact of the changes, enabling reduction of the test / validation phases of the SDLC. You change the model, not the code.

Finally, I like the "fractal" pattern of building componentry. This is a simple, easily understood pattern that allows successively more coarsely grained services to be composed from finer-grained ones. I have found this pattern to be very powerful in the hands of users in the past, particularly the programming language Function Block Diagram, known affectionately as FBD. It is an industrial automation programming language, defined in IEC-61131-3. For those of us who grew up using imperative languages, IA languages can be a real eye-opener.

As SOA begins to take its place in our ever-changing bag of tricks for containing complexity, the problem of how to best create composite applications from services will become our collective headache. Orchestration, choreography, collaboration, and general-purpose models will all have their places in defining certain types of composite applications. The SCA model-driven approach has some interesting ideas to contribute to this mix. Standard disclaimer: in this blog, I speak for myself, not Sun.

Posted at 10:37AM Jun 30, 2006 by rtenhove in Service Oriented Architecture  |