Like any other religion, sorry architecture, SOA has its own language and meanings for the terms it uses. Unfortunately, some of these words can be very confusing, none more than the term "service". So here is a bluffer's guide to understanding and conversing in SOA-speak.
Lexicon of confusing SOA terms:
Service:
The trickiest of the lot. Here is my preferred SOA usage:
"A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data; consolidate drilling reports). It is self-contained, may be composed of other services, and is a "black box" to its consumers."
Two more definitions in increasing order of opaqueness:
"...;a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description." OASIS
"...;a discretely defined set of contiguous and autonomous business or technical functionality" Wikipedia(!)
However, in IT the term service can also apply to a very low level data or logic routine, and in business discussions, service is a description what your business provides to its customers, and in operations, service describes the quality of delivery (i.e. Service Level, Service Management). The newer definitions above are peculiar to SOA, but those with the misfortune to have been exposed to Object Oriented (OO) methods in the nineties will recognised the constructs (and obscure language).
Sub-categories of Service:
Composite Service/Atomic Service:
"A composite service is a service whose implementation calls other services. This is as opposed to an atomic service, whose implementation is self-contained and does not invoke any other services. A composite service acts as both a service provider of the (composite) service and as a service consumer of its child services. The composite can be considered to be aggregating together the child services into a bigger service."
This building block approach, where you can create larger re-usable service blocks from the smallest services is a fundamental characteristic of SOA and provides significant potential maintenance benefits.
Service Consumer:
"A consumer of a service is an agent (user, process, composite service) which seeks to satisfy a particular need through the use of capabilities offered by means of a service. A service can have one or more consumers."
There are many consumer/provider models in IT, including Pub/Sub (Publish/Subscribe), that de-couple the systems required to support the overall business process. The ultimate consumer is the customer for the business process, but they can be several layers of service consumer each of which is loosely connected to the layer below.
Service Provider:
"A provider of a service is an agent that takes responsibility for it being carried out. Every service has a provider."
The key point about a service provider in the SOA context is that the service provider is not the service itself, but is effectively a management layer than ensures that all the non-functional characteristics for the service (accessibility, availability, quality, security, etc.) are agreed with and delivered to the Service Consumer.
Service Registry:
"To make a service available for use by consumers, the service providers register their service in a public registry. A registry is nothing but a collection of services, their description and their addresses. The registry is used by consumers to find services that match their requirements. If the registry has a service with matching criteria, it provides the consumer with the address for that service. The consumer accesses the service, binds to the service by calling its visible interfaces and invokes the methods provided by the service."
A more recent addition to the SOA terminology and tools list is the concept of making information about existing services easier to discover, so that effort is not duplicated in developing new services when existing services have been developed for another project that can be re-used to meet the requirements of the current project. More sophisticated Registries and Repositories for services are emerging that support real-time service choice and usage at run-time as well as during development. A key advantage for BAs here is that you have much better visibility of the building blocks you could use to build the solution required.
Web Service:
"A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards"
In effect, a web service is a specific software implementation of service architecture that have specific physical definitions and characteristics - enabling real code to be cut and executed to deliver some service functionality. Fortunately, or unfortunately depending on your view, web services have come to dominate the whole service discussion. It is certainly the most popular implementation of the SOA service concept, and has a large set of agreed policies ensuring that interoperability is easy to achieve (all called WS-something). The downside is that it allows programmers to jump straight into coding with little architectural context for the overall business service they are delivering. So if you ask your IT department about SOA, and all they come up with is web services, don't expect to get a process-driven, service-oriented solution to meet your business requirements.
So these are most of the definitions of Service terms you will need to know to be able to make sense of SOA. In the next article I will cover some of the other arcane and, at times, baffling SOA terms you may come across.
Author: John Moe is Head of Business Consulting at Alphacourt, and writes and presents widely on SOA and BPM. With over 25 years experience delivering application development and business transformation programmes, John has made most of the mistakes you will ever make and is keen to pass on this knowledge to help you avoid them yourself. In return he just expects undying gratitude and free drinks wherever he goes.