An important characteristic of services is that they have simple, well-defined interfaces. This makes it easy to interact with them, and enables other elements to use them in a structured manner. A service interface defines the way in which other elements can interact and exchange information with a service. This concept is captured by the ServiceInterface OWL class:
The concept of an interface is in general well understood by practitioners, including the notion that interfaces define the parameters for information passing in and out of them when invoked. What differs from domain to domain is the specific nature of how an interface is invoked and how information is passed back and forth. Service interfaces are typically, but not necessarily, message-based (to support loose-coupling). Furthermore, service interfaces are always defined independently from any service implementing them (to support loose-coupling and service mediation).
From a design perspective interfaces may have more granular operations or may be composed of other interfaces. We have chosen to stay at the concept level and not include such design aspects in the ontology.
ServiceInterface is defined as disjoint with the Service, ServiceContract, and Effect classes. Instances of these classes are considered not to define (by themselves) the way in which other elements can interact and exchange information with a service. Note that there is a natural synergy between ServiceInterface and the interactionAspect datatype property on ServiceContract, as the latter defines any multi-interaction and/or sequencing constraints on how to use a service through interaction with its service interfaces.
Constraints Datatype Property
The Constraints datatype property on ServiceInterface captures the notion that there can be constraints on the allowed interaction such as only certain value ranges allowed on given parameters. Depending on the nature of the service and the service interface in question, these constraints may be defined either formally or informally (the informal case being relevant at a minimum for certain types of real-world services).
hasInterface and isInterfaceOf Properties
The hasInterface property, and its inverse isInterfaceOf, capture the abstract notion of a service having a particular service interface.
In one direction, any service must have at least one service interface; anything else would be contrary to the definition of a service as a representation of a repeatable activity that has a specified outcome and is a ‘black box’ to its consumers. In the other direction, there can be service interfaces that are not yet interfaces of any defined services. Also, the same service interface can be an interface of multiple services. The latter does not mean that these services are the same, nor even that they have the same effect; it only means that it is possible to interact with all these services in the manner defined by the service interface in question.
A service interface can enable another element to give information to or receive information from a service (when it uses that service); specifically the types of information given or received. The concept of information type is captured by the InformationType OWL class:
Figure 2. SOA-O InformationType Class
In any concrete interaction through a service interface the information types on that interface are instantiated by information items, yet for the service interface itself it is the types that are important. Note that the constraints datatype property on ServiceInterface, if necessary, can be used to express constraints on allowed values for certain information types.
hasInput and isInputAt Properties
The hasInput property, and its inverse isInputAt, capture the abstract notion of a particular type of information being given when interacting with a service through a service interface.
Note that there is a many-to-many relationship between service interfaces and input information types. A given information type may be input at many service interfaces or none at all. Similarly, a given service interface may have many information types as input or none at all. It is important to realize that some services may have only inputs (triggering an asynchronous action without a defined response) and other services may have only outputs (elements performing these services execute independently yet may provide output that is used by other elements).
hasOutput and isOutputAt Properties
The hasOutput property, and its inverse isOutputAt, capture the abstract notion of a particular type of information being received when interacting with a service through a service interface.
Note that there is a many-to-many relationship between service interfaces and output information types. A given information type may be output at many service interfaces or none at all. Similarly, a given service interface may have many information types as output or none at all. It is important to realize that some services may have only inputs (triggering an asynchronous action without a defined response) and other services may have only outputs (elements performing these services execute independently yet may provide output that is used by other elements).
A service contract on a service expresses that the services interfaces on that service must be used in a certain order:
- Service is an instance of Service.
- ServiceContract is an instance of ServiceContract.
- ServiceContract isContractFor Service.
- X is an instance of ServiceInterface.
- X isInterfaceOf Service.
- Y is an instance of ServiceInterface.
- Y isInterfaceOf Service.
The interactionAspect datatype property on ServiceContract describes that X must be used before Y may be used.