SOA has garnered widespread attention and adoption due to its promise to deliver agility and cost savings to IT. SOA “should be” seen as an architecture discipline designed to handle the heterogeneity of enterprise IT. SOA facilitates the interoperability of diverse applications and computing platforms by packaging or wrapping functionality as interoperable SOA Services.
One of the key tenets of SOA is the use of services. Lets cover of the high-level concepts of a service.
Definition of a Service
The term “service” is widely used in IT to mean many different things. To address this ambiguity use the term SOA Service to refer to a service that has been built as part of a SOA initiative i.e. it is published, discoverable, and was designed, implemented, can be versioned, deployed and managed using a service-oriented approach.
To illustrate this distinction, a web service may or may not be a SOA Service. A web service is a technology (i.e. SOAP over HTTP). This technology may be (and frequently is) used when creating and exposing a SOA Service. However, a web service may also be created when no service-oriented approach is employed i.e. the web service is simply a technical artifact of the implementation. Conversely, a SOA Service may be implemented using technologies other than web services (e.g. REST, JMS, JSON).
I like to think of a SOA service as a means to package usable software building blocks to provide functionality to users, applications, or other SOA services.
Facets of a SOA Service
To further differentiate the term service from SOA service I like to think of a SOA service as a whole of 3 facets. This might be controversial but it has helped me immensely when working with enterprises.
- Contract – A Service Contract describes the SOA Service in human-readable terms. It includes descriptions of both functional and non-functional capabilities. Contracts describe functional capabilities of the available operations of a SOA Service using business terms. Contracts also specify non-functional aspects of SOA Service, such as semantics, invocation style, security requirements, transaction requirements, quality of service, etc.
- Interface – A Service Interface provides a means for the consumers of a SOA Service to access its functionality according to the Service Contract. The interface separates the consumer from the Service Implementation and isolates the consumer from the details of the implementation. The consumer is only able to access functions and data offered through the interface.
- Implementation – The Service Implementation is the technical realization of the contract. It is responsible for fulfilling all functional and nonfunctional capabilities stated in the contract. The implementation may leverage functionality in existing systems, newly developed code, or a combination of both. Since infrastructure is often used to help satisfy certain capabilities of the SOA Service (either functional or non-functional), the infrastructure components act as part of the Service Implementation.
Usage Agreements
A common mistake is to assume that the Service Contract is between the service provider and the service consumer. However, this would create a point-to-point relationship between the service consumer and the service provider. Each time a new consumer wanted to use the SOA Service, a new Service Contract would need to be created. This is not a path to facilitating reuse.
The Service Contract defines what the SOA Service agrees to provide to the
environment. So, for example, if the Service Contract guarantees a throughput of ten transactions per second (TPS), that is the total for all service consumers.
The service consumer Usage Agreement defines what a particular service consumer is entitled to consume. Here is the relationship illustrated.
The illustration shows two SOA Services that share a backend system exposed via two interfaces, one synchronous and one asynchronous. There are three Usage Agreements illustrated for these two SOA Services. This is only an example and there could be different combinations of backend systems, Service Interfaces, Service Contracts, and Usage Agreements.
Having both a Usage Agreement and a Service Contract provides a decoupling between the service provider and service consumer. This not only facilitates reuse but also provides a separation of concerns. The Service Contract defines the totality of what the SOA Service guarantees to provide, and can be written and validated independent of any knowledge of specific service consumers. The Usage Agreement is service consumer specific and defines what capabilities of the SOA Service each consumer is allowed to consume.
An Enterprise Architect's Musings 