SOA principles

Interoperability: services implemented in different systems, locations or even business domains, and using diverse technologies – ranging from programming languages to platforms – need to work together to allow diverse consumers and providers to communicate. For this to happen effectively, services must rely on internationally agreed communication standards. Many of the current standards were developed for communication over the web – although SOA is in fact technology-agnostic, so that its principles apply regardless of which communication standard is actually used.

Location transparency: consumers should be able to make use of a service without necessarily knowing where the service is located, that is, on which machine or even in which business organisation. Service consumer and provider are only loosely bound together, with the consumer having no knowledge of the service implementation or its platform, and consumer and provider communicating solely through messages.

Discoverability: the consumer must be able to find out about relevant services, which usually involves access to appropriate metadata about services. Discovery is often done through registries: a service registry will contain metadata and references to services. The actual services are often contained in inventories: a service inventory is collection of complementary services within a boundary of the provider, an enterprise or even a meaningful segment of an enterprise. We distinguish between run-time and design-time discovery. In run-time (or dynamic) discovery, the consumer first queries the registry for a service that matches the consumer’s criteria; if such a service exists, the registry provides the consumer with the location of the service provider; the consumer can then bind dynamically with the service provider and invoke the service. This model of service collaboration is known as the ‘find, bind and invoke’ cycle. While this model is of historical and theoretical significance, it has yet to become mainstream in practice despite much research and development effort in both academia and industry. This is due to the intrinsic difficulty of specifying semantic information which may allow one to reliably predict the interaction of a potentially unlimited number of diverse services. Instead, current discovery mechanisms support primarily design-time discovery – that is, they’re aimed at developers who are trying to find out about relevant services in the planning stage of a SOA application development.

Loose coupling and encapsulation: coupling between service providers and consumers should be low, and confined to reliance to service public interfaces, with an understanding that such interfaces should disclose as little as possible of the underlying implementation details, which is known as encapsulation. The interfaces should be based on standard communication protocols, rather than proprietary ones, with open standards recommended to foster the highest degree of interoperability.

Abstraction: both the encapsulated implementation, the implementation technology and the physical location of services should be fully transparent to consumers, which should be reliant solely on public interfaces, service contract descriptions and SOA infrastructures to locate and invoke required services.

Autonomy: the more autonomous a service is, the more control it will have over its own implementation and run-time environment, and so the greater will be its flexibility and potential for evolution. Both implementation and run-time environment can be modified without affecting consumers.

Statelessness: excessive state information can compromise the availability of a service and limit its scalability; hence, services should remain stateless as far as is realistic to allow them to do their work.

Standardised interfaces and contracts: to support the service collaboration model and automate service interaction, services need to be described in a similar way using commonly understood standards. In particular, a service description may include descriptions of the service technical interface (that is, the operations which can be invoked and their parameters), the quality of service provided, and a service-level agreement which details both service characteristics (e.g. response time or availability) and cost to the consumer of invocation. Additional metadata may cover a range of information, for instance including user satisfaction rating or future development plans.

Reusability: services must be designed with reuse in mind, so generality of the service in terms of potential reuse across projects and systems is an important design principle. This impacts on both the granularity of the service (the service should strive to support generic business processes and tasks and close alignment with the business) and on the choice of standards and implementation technology, which should foster the highest possible degree of interoperability.

Dynamic reconfiguration: service-based systems should be configurable and reconfigurable dynamically by discovering and incorporating existing services, but while maintaining coherence and integrity. This should be supported by metadata, which underlie the discovery of existing services, coupled with contract agreement descriptors.