Service is another core concept of this ontology. It is a concept that is fundamental to SOA and always used in practice when describing or engineering SOA systems, yet it is not easy to define formally. The SOA-O is based on the following definition of service:
“A service is a logical representation of a repeatable activity that has a specified outcome. It is self-contained and is a ‘black box’ to its consumers.”
This corresponds to the existing official Open Group definition of the term.
The word “activity” in the definition above is here used in the general English language sense of the word, not in the process-specific sense of that same word (i.e., activities are not necessarily process activities). The SOA-O purposefully omits “business” as an intrinsic part of the definition of service. The reason for this is that the notion of business is relative to a person’s viewpoint – as an example, one person’s notion of IT is another person’s notion of business (the business of IT). Service as defined by the ontology is agnostic to whether the concept is applied to the classical notion of a business domain or the classical notion of an IT domain.
Other current SOA-specific definitions of the term service include:
- “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.” (Source: OASIS SOA Reference Model)
- “A capability offered by one entity or entities to others using well-defined ‘terms and conditions’ and interfaces.” (Source: OMG SoaML Specification)
Within the normal degree of precision of the English language, these definitions are not contradictory; they are stressing different aspects of the same concept. All three definitions are SOA-specific though, and represent a particular interpretation of the generic English language term service.
A service is a logical representation of a repeatable activity that has a specified outcome. It is self-contained and is a ‘black box’ to its consumers. The concept of service is captured by the Service OWL class:
Figure 1. SOA-O Service Class.
In the context of the SOA-O we consider only SOA-based services. Other domains, such as Integrated Service Management, can have services that are not SOA-based and hence are outside the intended scope of the SOA ontology.
Service is defined as disjoint with the System, Task, and HumanActor classes. Instances of these classes are considered not to be services themselves, even though they may provide capabilities that can be offered as services.
performs and performedBy Properties
As a service itself is only a logical representation, any service is performed by something. The something that performs a service must be opaque to anyone interacting with it, an opaqueness which is the exact nature of the Element class. This concept is captured by the performs and performedBy properties as illustrated in The Service Class (Figure 1). This also captures the fact that services can be performed by elements of other types than systems. This includes elements such as software components, human actors, and tasks.
Note that the same instance of Service can be performed by many different instances of Element. As long as the service performed is the same, an external observer cannot tell the difference (for contractual obligations, SLAs, etc. Conversely, any instance of Element may perform more than one service or none at all.
While a service can be performed by other elements, the service itself (as a purely logical representation) does not perform other services.
Service Consumers and Service Providers
Terminology used in an SOA environment often includes the notion of service providers and service consumers. There are two challenges with this terminology:
- It does not distinguish between the contractual obligation aspect of consume/provide and the interaction aspect of consume/provide. A contractual obligation does not necessarily translate to an interaction dependency, if for no other reason than because the realization of the contractual obligation may have been sourced to a third party.
- The above are the reasons why the ontology has chosen not to adopt consume and provide as core concepts, rather instead allows consume or provide terms used with contractual obligations and/or interaction rules described by service contracts. In its simplest form, outside the context of a formal service contract, the interaction aspect of consuming and providing services may even be expressed simply by saying that some element uses (consumes) a service or that some element performs (provides) a service.
- Consuming or providing a service is a statement that only makes sense in context – either a contractual context or an interaction context. These terms are consequently not well suited for making statements about elements and services in isolation.
uses and usedBy Properties Applied to Service
In one direction, it does not really make sense to talk about a service that uses another element. While the thing that performs the service might very well include the use of other elements (and certainly will in the case of service composition), the service itself (as a purely logical representation) does not use other elements.
In the other direction, we find the most common of all interactions in an SOA environment: the notion that some element uses a service by interacting with it. Note that from an operational perspective this interaction actually reaches somewhat beyond the service itself by involving the following typical steps:
- Picking the service to interact with (this statement is agnostic as to whether this is done dynamically at runtime or statically at design and/or construct time)
- Picking an element that performs that service (in a typical SOA environment, this is most often done “inside” an Enterprise Service Bus (ESB))
- Interacting with the chosen element (that performs the chosen) service (often also facilitated by an ESB)
represents and representedBy Properties Applied to Service
Concepts such as service mediations, service proxies, ESBs, etc. are natural to those practitioners that describe and implement the operational aspects of SOA systems. From an ontology perspective all of these can be captured by some other element representing the service – a level of indirection that is critical when we do not want to bind operationally to a particular service endpoint, rather we want to preserve loose-coupling and the ability to switch embodiments as needed. Note that by leveraging the represents and representedBy properties in this fashion we additionally encapsulate the relatively complex operational interaction pattern that was described in the section above (picking the service, picking an element that performs the service, and interacting with that chosen element).
While a service being represented by something else is quite natural, it is harder to imagine what the service itself might represent. To some degree we have already captured the fact that a service represents any embodiment of it, only we have chosen to use the performs and performedBy properties to describe this rather than the generic represents and representedBy properties. As a consequence, we do not expect practical applications of the ontology to have services represent anything.
Exemplifying the Difference between Doing a Task and Performing a Service
The distinction between a human actor doing a task and an element (technology, human actor, or other) performing a service is important. The human actor doing the task has the responsibility that it gets done, yet may in fact in many cases leverage some service to achieve that outcome:
- John is an instance of HumanActor.
- WashWindows is an instance of Task and is done by John.
- SoapWater is an instance of Service.
- WaterTap is an instance of Element.
- WaterTap performs SoapWater.
- John uses SoapWater (to do WashWindows).
Note how clearly SoapWater does not do WashWindows, nor does WaterTap do WashWindows.