SOA-3 – Service

Definitions of Service

Service Oriented Architecture (SOA) is, above all, an approach that specifies how entities can best work together to meet a set of objectives. SOA separates what needs to get done from how it gets done, where it gets done, and what or who gets it done.

Current SOA-related standards stress different aspects of the meaning of “service”:

  • “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 SOA Reference Model – SOA-RM)
  • “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 Open Group: Service Oriented Architecture Ontology – SOA-O)
  • “A service is value delivered to another through a well-defined interface and available to a community (which may be the general public). A service results in work provided to one by another.” (Object Management Group: Service Oriented Architecture Modeling Lanaguage – SoaML)

A consumer accesses a service by means of a service interface, comprising the specific of how to access an underlying capability offered by the .

A consumer may be unknown to the provider.

A service is opaque, that is, its implementation is typically hidden from the service consumer (“black box”) except for the information required by service consumers to determine whether a given service is appropriate to their needs, and for the behavior model exposed through the service interface (“white box”).

The consequence of invoking a service is a realization of some real world effect that may include:

  1. information returned in response to a request for that information,
  2. a change to the shared state of defined entities, or
  3. some combination of (1) and (2).

Typically the consumer does not know how the information in (1) is generated, or how the state change in (2) is effected.

A consumer may demonstrate uses of a service beyond the scope originally conceived by the provider (“co-creation of value”).

Representations of Service

In addition to these discussions of “service” in (more or less) plain English, we have two formal means of representing “service” – an OWL ontology (SOA-O) and a UML2 Profile (SoaML):

[code language=”xml”]</span>
<owl:Class rdf:about="#Element">
</owl:Class>
<owl:Class rdf:about="#Service">
<rdfs:subClassOf>
<owl:Class rdf:about="#Element"/>
</rdfs:subClassOf>
</owl:Class>
<owl:ObjectProperty rdf:about="#performs">
<rdfs:domain rdf:resource="#Element"/>
<rdfs:range rdf:resource="#Service"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:about="#performedBy">
<owl:inverseOf>
<owl:ObjectProperty rdf:about="#performs"/>
</owl:inverseOf>
</owl:ObjectProperty>
<span style="color: #ffffff;">[/code]

and
SOA-O Service Class

Domains of Service

A service may apply (1) to a “real” world (e.g. social or business) domain or (2) to an IT domain. There is also a third (hybrid) sense of service:

A service [IT domain] may be provided in the service of another service [business domain].

Our concern is primarily in “real” world services – though, undoubtedly, software services will play an increasing role in service requests and service provisions.

At this point, we need to incorporate more “real” world thinking and technologies into our (so far deliberately abstract) description and model of service.

Previous: SOA-3 Overview

Next: SOA-3 XXX or SOA-3 Service + Supplementary Ontologies