An introduction to web applications architecture

SOA principles

SOA is governed by a number of design principles (adapted from Erl, 2007):
Start of Quote
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.