SOA fundamentals and characteristics

In my last Industry Insight I explored at a high level what the service-oriented architecture (SOA) proposition is and provided simplistic definitions and descriptions. This Industry Insight explores the underlying principles and characteristics of SOA in more detail, providing architects and system integrators with a deeper understanding of the SOA design approach and architectural style.

So we agree that at a high level, there are three fundamental roles in an SOA, namely: service providers, service consumers and service brokers. What we have failed to discuss is the message that is exchanged between the services, as well as implementation technologies.

A service in SOA is a piece of functionality exposed to and callable by other applications. Services essentially have two parts: the interface and the implementation.

The interface defines the programatic access contract between the consumer and the provider. It should contain:

1. The identity of the service
2. Input and output data details of the service
3. Metadata on the service`s functionality and purpose

The implementation contains the functional or business logic of the service. It should essentially be a `black-box` to the service consumer, where the consumer has no understanding of the service`s functional implementation or the technology in which it is physically written. It is the role of the interface to provide this level of abstraction and encapsulation.

Services should further exhibit and comply with the following:

1. The interface contract to the service must be platform-independent. As such, the service can be consumed and called from any client running in any environment, written in any language. The interface contract defines the behaviour of the service and the messages they accept and return.

2. The service must be dynamically located and invoked. This allows the service to be published to a directory from where it may be `looked-up` adlib.

Services can also be categorised into different types.

Just as the interface contract is platform independent, so the messages exchanged via these contracts must also be platform and language agnostic.

The beauty of Web services is that today they provide an almost perfect implementation technology for SOA.

Edward Lane, technical manager, BEA Solutions Africa

Messages should be descriptive and constrained by an extensible schema which limits the vocabulary and structure of messages. Prescribing system behaviour in the messages should be avoided. Limiting the vocabulary and structure of messages is a necessity for any efficient communication. The more restricted a message is, the easier it is to understand the message, although it comes at the expense of reduced extensibility. Extensible schemas, however, will allow new versions of services to be introduced without breaking existing services.

As you may already have guessed, XML provides the perfect implementation technology for loosely coupled inter-application data sharing. It is self-describing, independent of hardware and programming language, and it accommodates independent change/versioning (is less fragile to extension or application changes).

SOA clients need to locate and consume services as do SOA producers need to advertise their services for consumption. The service broker is the agent that brings these two parties together. Also known as a directory service, the broker is essentially an intermediary between consumers and providers. The directory service catalogues all services advertised inside it, making them available for consumption. Consumers can then use the directory service`s search capabilities to find providers.

While Web services and SOA are usually thought to be synonymous, they are not. It should be made clear that Web services are an important tool and one implementation method for SOA, but there are other patterns that may be more appropriate for any given use-case. The beauty of Web services, however, is that today they provide an almost perfect implementation technology for SOA. Web services are built on top of industry-standard, platform agnostic technologies and protocols such as HTTP, XML, UDDI, WSDL and SOAP. These protocols also fulfil the key requirements of a SOA.

* Dynamically discovery and invocation: fulfilled by UDDI, WSDL and SOAP.
* Platform-independent interface contract: fulfilled by XML.
* Interoperability: fulfilled by HTTP.

So Web services continues to be the best-fit implementation we have for SOA architectures to date. I expect that we will see Web services develop and mature into the sole implementation technology for SOA-based systems.