Composite Materials

Why SOA?

Why bother with SOA? What benefits can it possibly generate for users? Isn't it just another instance of vendors hyping the latest acronym du jour?

At its core, SOA is a good, sensible idea. It has existed in one form or another since the 1960's. The technical "perfect storm" of the Internet, TCP/IP, HTTP and XML have created the conditions for yet another incarnation of SOA to emerge. Due to the almost universal support for those technologies, this version of SOA has the potential to have a wider, longer lasting impact than any previous one.

SOA is a software system structuring principle, based on the concept of services, which are offered (and described) by service providers. Service consumers read service descriptions, and using ONLY those descriptions, can interact with service provider, getting access to whatever functions it provides.

That's a very general definition. Interaction between a consumer and provider requires some common computational infrastructure. In our shiny, new 21st century version of SOA, this means XML message exchange using web protocols, usually HTTP over TCP/IP. Service description is accomplished using WSDL. (This is my definition of SOA; others have much different (and usually more complex) ideas about modern SOA.)

That's a very brief description of what SOA is. But why bother? In a word: decoupling. In the history of software engineering, coupling between "pieces" of a software system are like nails through pieces of wood: they make modification of the system design difficult, expensive, and time-consuming.

Sofware systems are normally decomposed into some sort of modules (I'd use the term 'components', but that has become a loaded word!). Good decomposition leads to modules that have just a few, well-understood associations with other modules. Software architects talk about "connections" between such modules. Obviously the more connections there are, the more difficult it is to modify one of the modules without disturbing the others. Too much coupling between modules manifests itself in several ways:

• Need for co-ordinated software updates across two or more (sometimes many more! modules. This can be a serious problem in distributed system.
• Unexpected side effects. We've all seen this one. Make a change to one module, and something apparently completely unrelated breaks. Why? Complex (sometimes invisible) coupling. What you don't know can hurt you!
• High costs for software maintenance. Changes are difficult, and thus expensive.
• Difficulty in "evolving" a system over time. Reuse, changing, refactoring are all difficult when changes of any sort are difficult.

These are all consequences of "nails", often hidden ones, confining your system to its current design. Consider the following snippet of code:

    z = foo.getW().getX().getY().getZ();

This is a long nail, hard-coding the association between five separate classes. (Karl Lieberherr has lot to say about this, by the way. Check of the Method of Demeter.) This is an example from O-O, but larger scale systems often exhibit the same close-coupling, but in ways that are not so obvious.

How to avoid those "nails"? Decoupling is the first step. You must minimize how much each module "knows" about the other modules in the system. At a very fine-grained scale, this is what OOP introduced: type abstraction helped hide class implementation details from "users" of a class. Similarly, SOA introduces mechanisms to help maximize decoupling at a course-grained scale.

The service consumer (in SOA) bases all of its "knowledge" about a provider on the WSDL the provider has made available (typically through publication). This represents everything the consumer needs to know, so we have a small, well-defined interface between the two entities. Normally services a very coarse-grained (think "submit purchase order"); fine-grained services (like "find square root") don't make a lot of sense when I've got a perfectly good run-time library.

The consumer, dealing with only XML messages, has no knowledge of how the provider implements the service. That's good: this avoids sneaky sorts of technical coupling. It also makes changes, such as switching to a different service provider, very easy: the declared interface to the provider is either compatible with the old one, or not.

The provider is similarly decoupled from the consumer. In fact, the provider can make very few assumptions about the nature of the consumer, especially why the consumer is asking for a particular service. (There of course, can be higher-level application context information concerning this (a BPEL process instance, for example).) All of this adds up to a very good set of circumstances for reuse of the service in many different use cases. Indeed, when we talk about service composition, we are relying on this ability to reuse services in new ways without affecting the service implementation. Decoupling is the ticket to providing this capability.

So what do I get from using a SOA?

• Reuse and composition. This is particularly powerful for creating new business processes quickly and reliably.
• Recomposition. The ability to alter existing business processes or other applications based on service aggregation.
• The ability to incrementally change the system. Switching service providers, extending services, modifying service providers and consumers. All of these can be done safely, due to well-controlled coupling.
• The ability to incrementally build the system. This is especially true of SOA-based integration.

As my colleague Mike Wright is fond of saying, SOA gives you the ability to refactor your enterprise incrementally. That certainly makes SOA worthwhile, don't you think?

Posted at 11:33AM Apr 11, 2006 by rtenhove in Service Oriented Architecture  |