Friday, 19 October 2012

Extensible Web Service API

The only constant in life is change, and this is no different for Service-oriented Architecture (SOA). Services must be built with this in mind: that they will have to adapt to new or changing requirements. Extensibility is the ability for services to adapt whilst preserving existing consumer contracts.

We would expect the following types of changes to services to have no impact on other consumers:
- internal source code changes
- interface changes
- take on of new consumers
- environmental changes

Internal code changes

Insulating consumers from internal changes is achieved through another service characteristic: Abstraction, I.e. it is critical that that services do not “leak” implementation detail into the interface. A typical example of this is the use of underlying database identifiers in the interface instead of meaningful business keys.

Interface changes

In general interface changes will break existing code. The exceptions to this are the adding of new operations or certain types of service data types extension. Where breaking changes are introduced then a versioning scheme is required to separate the old and the new, whilst supporting both concurrently. Versioning for web services is typically done via the introduction of major and minor numbers to XML namespaces, such as proposed here, or alternatively via a service registry.

New consumers take-on
The take-on of new consumers will increase the load on a service. Services need to ensure that previously agreed consumer service level agreements (SLA) are not violated. Achieving this will involve a combination of automated performance regression test suites and runtime SLA monitoring.

Environmental changes

Services need to ensure that any planned maintenance that is performed on their underlying execution platform such as the application of critical patches does not affect consumers. Services need to run in a cluster with the ability for service instances to be transparently taken out of commission during maintenance periods whilst other service instances continue to support consumer requests. It is advisable to run automated regression test suites after such maintenance.

You may also like:

Service Characteristics - Contract
Service Characteristics - Abstract
Service Characteristics - Composable
Service Characteristics - Autonomous
Service Characteristics - Discoverable
Service Characteristics - Distributed
Service Characteristics - Reusable