I just read this interesting rant from ZapThink on the importance of loose-coupling between service providers and consumers. It highlights the difference between a Service Oriented Architecture and SOA’s evil twin the “bunch of web services” (JBOWS).

“Lots of things change in an IT or business environment: location and availability of services, versioning of Service implementations and contracts, changes to business processes and policies, new or changing requirements for reporting, visibility, and control, and of course the need for new capabilities to solve emerging business problems or capitalize on new business opportunities. However, if you think that a Service is just an API, then all hell breaks loose when you try to connect a Service Consumer directly to a Service Provider.”

I wrote about this in a previous post…the need to Design for Change is a critical requirement for any organization and is one of the prime reasons behind adopting an SOA approach. Architectural approaches such as “loose coupling” are an important part of design for change. But that is only one dimension of the problem. Design for change also needs to be built into the IT culture. Change processes must be a natural part of your Services development and management lifecycle.

I find a common mistake is that Services are designed for a point purpose at a point in time without regard for how they will change over time. The result is brittle solutions that are expensive and risky to evolve.

The ZapThink article goes on to talk about late binding and the use of a services proxy and WS-Addressing to route service invocations to the appropriate provider. This is somewhat simplistic and I find that the pointed comments about “integration-centric techies” is a bit hyperbolic, especially since the ZapThink SOA Roadmap clearly shows an evolutionary progression starting from “static binding to static services” as the first phase along the ZapThink road to SOA. But everyone is entitled to change their mind, and leaving that aside I agree that strong decoupling of consumers and providers is important for a mature SOA. Some of these concepts have been discussed by others in terms of “Service Virtualization.”

Change is a continuing and important challenge for an SOA and the solution is “in your architecture” rather than something that can be bought off the shelf. Consider these sources of change that we must deal with every day:

• Hardware failure in either our service implementation, or network connectivity – the need to support fault-tolerance or high availability.
• The need to load-balance service invocations across a number of different but redundant providers
• Changes in the underlying applications supporting the service provider – e.g. package version upgrades
• Changes in the location of a service provider – e.g. in a disaster recovery situation, or planned migration from one facility to another.
• Migration of service implementations – e.g. migration from a legacy application to a new platform.
• Functional changes to service provider to support new business requirements
• The need to support multiple service versions to allow phased migration of consumers from one service version to another.
• The need to phase out old services which do not provide sufficient ROI.

The challenge is that all of these changes happen on different timescales. Some changes occur on sub-second timescales (fail-over and load-balancing) while other changes can occur over months (system migrations). There is no single indirection technique that will span all these requirements.