Service-Oriented Architecture Ontology Version 2.0 – Service, ServiceContract, and ServiceInterface

 

Introduction

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 ontology 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; refer to the Open Group Definition of SOA.

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 ontology 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.

This chapter describes the following classes of the ontology:

  • Service
  • ServiceContract
  • ServiceInterface
  • InformationType

In addition, it defines the following properties:

  • performs and performedBy
  • hasContract and isContractFor
  • involvesParty and isPartyTo
  • specifies and isSpecifiedBy
  • hasInterface and isInterfaceOf
  • hasInput and isInputAt
  • hasOutput and isOutputAt

The Service Class

<owl:Class rdf:about="#Service">   <owl:disjointWith>     <owl:Class rdf:about="#System"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#Task"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#HumanActor"/>   </owl:disjointWith>   <rdfs:subClassOf>     <owl:Class rdf:about="#Element"/>   </rdfs:subClassOf> </owl:Class>

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, which is illustrated below.

The Service Class

In the context of the SOA ontology 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.

The performs and performedBy Properties

<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>

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. 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. see the definition of the ServiceContract class in Section 4.5.). 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. See the Simple Service Composition Example for an example of how to represent service compositions formally in the ontology.

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.
  • 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.

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; see the definition of the ServiceContract class in Section 4.5. 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; see also the examples below.

Service – Examples

The 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)

The 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.

Car Wash Example

Joe offers two different services to his customers: a basic wash and a gold wash. This can be instantiated in the ontology in the following way (subset to the part relevant for these two services):

  • GoldWash is an instance of Service.
  • BasicWash is an instance of Service.
  • CarWash performs both BasicWash and GoldWash.
  • WashManagerrepresents both BasicWash and GoldWash (i.e., is the interaction point where customers can order services as well as pay for  them).

Note the purposeful use of WashManager representing both services. This is due to Joe deciding that in his car wash customers are not to interact with the washing machinery directly, rather must instead interact with whomever (human actor) is fulfilling the role of wash manager.

The ServiceContract Class

<owl:Class rdf:about="#ServiceContract">   <owl:disjointWith>     <owl:Class rdf:about="#HumanActor"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#Task"/>   </owl:disjointWith> </owl:Class>

In many cases, specific agreements are needed in order to define how to use a service. This can either be because of a desire to regulate such use or can simply be because the service will not function properly unless interaction with it is done in a certain sequence. A service contract defines the terms, conditions, and interaction rules that interacting participants must agree to (directly or indirectly). A service contract is binding on all participants in the interaction, including the service itself and the element that provides it for the particular interaction in question. The concept of service contract is captured by the ServiceContract OWL class, which is illustrated below.

The ServiceContract Class

The interactionAspect and legalAspect Datatype Properties

<owl:DatatypeProperty rdf:about="#interactionAspect">   <rdfs:domain rdf:resource="#ServiceContract"/> </owl:DatatypeProperty>   <owl:DatatypeProperty rdf:about="#legalAspect">   <rdfs:domain rdf:resource="#ServiceContract"/> </owl:DatatypeProperty>   <owl:Class rdf:about="#ServiceContract">   <rdfs:subClassOf>     <owl:Restriction>       <owl:onProperty>         <owl:DatatypeProperty rdf:about="#legalAspect"/>       </owl:onProperty>       <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"       >1</owl:minCardinality>     </owl:Restriction>   </rdfs:subClassOf>   <rdfs:subClassOf>     <owl:Restriction>       <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"       >1</owl:maxCardinality>       <owl:onProperty>         <owl:DatatypeProperty rdf:about="#legalAspect"/>       </owl:onProperty>     </owl:Restriction>   </rdfs:subClassOf>   <rdfs:subClassOf>     <owl:Restriction>       <owl:onProperty>         <owl:DatatypeProperty rdf:about="#interactionAspect"/>       </owl:onProperty>       <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"       >1</owl:maxCardinality>     </owl:Restriction>   </rdfs:subClassOf>   <rdfs:subClassOf>     <owl:Restriction>       <owl:onProperty>         <owl:DatatypeProperty rdf:about="#interactionAspect"/>       </owl:onProperty>       <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"       >1</owl:minCardinality>     </owl:Restriction>   </rdfs:subClassOf> </owl:Class>

Service contracts explicitly regulate both the interaction aspects (see the hasContract and isContractFor properties) and the legal agreement aspects (see the involvedParty and isPartyTo properties) of using a service. The two types of aspects are formally captured by defining the interactionAspect and legalAspect datatype properties on the ServiceContract class. Note that the second of these attributes, the legal agreement aspects, includes concepts such as Service-Level Agreements (SLAs).

If desired, it is possible as an architectural convention to split the interaction and legal aspects into two different service contracts. Such choices will be up to any application using this ontology.

The hasContract and isContractFor Properties

<owl:ObjectProperty rdf:about="#isContractFor">   <rdfs:domain rdf:resource="#ServiceContract"/>   <rdfs:range rdf:resource="#Service"/> </owl:ObjectProperty>   <owl:ObjectProperty rdf:about="#hasContract">   <owl:inverseOf>     <owl:ObjectProperty rdf:about="#isContractFor"/>   </owl:inverseOf> </owl:ObjectProperty>   <owl:Class rdf:about="#ServiceContract">   <rdfs:subClassOf>     <owl:Restriction>       <owl:onProperty>         <owl:ObjectProperty rdf:about="#isContractFor"/>       </owl:onProperty>       <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"       >1</owl:minCardinality>     </owl:Restriction>   </rdfs:subClassOf> </owl:Class>

The hasContract property, and its inverse isContractFor, capture the abstract notion of a service having a service contract. Anyone wanting to use a service must obey the interaction aspects (as defined in the interactionAspect datatype property) of any service contract applying to that interaction. In that fashion, the interaction aspects of a service contract are context-independent; they capture the defined or intrinsic ways in which a service may be used.

By definition, any service contract must be a contract for at least one service. It is possible that the same service contract can be a contract for more than one service; for instance, in cases where a group of services share the same interaction pattern or where a service contract (legally – see the involvesParty and isPartyTo properties below) regulates the providing and consuming of multiple services.

The involvesParty and isPartyTo Properties

<owl:ObjectProperty rdf:about="#isPartyTo">   <rdfs:domain rdf:resource="#HumanActor"/>   <rdfs:range rdf:resource="#ServiceContract"/> </owl:ObjectProperty>   <owl:ObjectProperty rdf:about="#involvesParty">   <owl:inverseOf>     <owl:ObjectProperty rdf:about="#isPartyTo"/>   </owl:inverseOf> </owl:ObjectProperty/>

In addition to the rules and regulations that intrinsically apply to any interaction with a service (the interaction aspect of service contracts captured in the interactionAspect datatype property) there may be additional legal agreements that apply to certain human actors and their use of services. The involvesParty property, and its inverse isPartyTo, capture the abstract notion of a service contract specifying legal obligations between human actors in the context of using the one or more services for which the service contract is a contract.

While the involvesParty and isPartyTo properties define the relationships to human actors involved in the service contract, the actual legal obligations on each of these human actors is defined in the legalAspect datatype property on the service contract. This includes the ability to define who is the provider and who is the consumer from a legal obligation perspective.

There is a many-to-many relationship between service contracts and human actors. A given human actor may be party to none, one, or many service contracts. Similarly, a given service contract may involve none, one, or multiple human actors (none in the case where that particular service contract only specifies the interactionAspect datatype property). Note that it is important we allow for sourcing contracts where there is a legal agreement between human actor A and human actor B (both of which are party to a service contract), yet human actor B has sourced the performing of the service to human actor C (aka human actor C performs the service in question, not human actor B).

The involvesParty property together with the legalAspect datatype property on ServiceContract capture not just transient obligations. They include the ability to express “is obliged to at this instant”, “was obliged to”, and “may in future be obliged to”.

The Effect Class

<owl:Class rdf:about="#Effect">   <owl:disjointWith>     <owl:Class rdf:about="#ServiceInterface"/>   </owl:disjointWith> </owl:Class>

Interacting with something performing a service has effects. These comprise the outcome of that interaction, and are how a service (through the element that performs it) delivers value to its consumers. The concept of effect is captured by the Effect OWL class, which is illustrated below.

The Effect Class

Note that the Effect class purely represents how results or value is delivered to someone interacting with a service. Any possible internal side-effects are explicitly not covered by the Effect class.

Effect is defined as disjoint with the ServiceInterface class. (The ServiceInterface class is defined later in this document.) Interacting with a service through its service interface can have an outcome or provide a value (an instance of Effect), but the service interface itself does not constitute that outcome or value.

The specifies and isSpecifiedBy Properties

<owl:ObjectProperty rdf:about="#specifies">   <rdfs:domain rdf:resource="#ServiceContract"/>   <rdfs:range rdf:resource="#Effect"/> </owl:ObjectProperty>   <owl:ObjectProperty rdf:about="#isSpecifiedBy">   <owl:inverseOf>     <owl:ObjectProperty rdf:about="#specifies"/>   </owl:inverseOf> </owl:ObjectProperty>   <owl:Class rdf:about="#Effect">   <rdfs:subClassOf>     <owl:Restriction>       <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"       >1</owl:minCardinality>       <owl:onProperty>         <owl:ObjectProperty rdf:about="#isSpecifiedBy"/>       </owl:onProperty>     </owl:Restriction>   </rdfs:subClassOf> </owl:Class>   <owl:Class rdf:about="#ServiceContract">   <rdfs:subClassOf>     <owl:Restriction>       <owl:onProperty>         <owl:ObjectProperty rdf:about="#specifies"/>       </owl:onProperty>       <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"       >1</owl:minCardinality>     </owl:Restriction>   </rdfs:subClassOf> </owl:Class>

While a service intrinsically has an effect every time someone interacts with it, in order to trust the effect to be something in particular, the effect needs to be specified as part of a service contract. The specifies property, and its inverse isSpecifiedBy, capture the abstract notion of a service contract specifying a particular effect as part of the agreement for using a service. Note that the specified effect can apply to both the interactionAspect datatype property (simply specifying what will happen when interacting with the service according to the service contract) and the legalAspect datatype property (specifying a contractually promised effect).

Anyone wanting a guaranteed effect of the interaction with a given service must ensure that the desired effect is specified in a service contract applying to that interaction. By definition, any service contract must specify at least one effect. In the other direction, an effect must be an effect of at least one service contract; this represents that fact that we have chosen only to formalize those effects that are specified by service contracts (and not all intrinsic effects of all services).

ServiceContract – Examples

Service-Level Agreements

A Service-Level Agreement (SLA) on a service has been agreed by organizations A and B. It is important to realize that an SLA always has a context of the parties that have agreed to it, involving at a minimum one legal “consumer” and one legal “provider”. This can be represented in the ontology as follows:

  • A and B are instances of HumanActor.
  • Service is an instance of Service.
  • ServiceContract is an instance of ServiceContract.
  • ServiceContract isContractFor Service.
  • ServiceContract involvesParty A.
  • ServiceContract involvesParty B.

The legalAspect datatype property on ServiceContract describes the SLA.

Service Sourcing

Organizations A and B have agreed on B providing certain services for A, yet B wants to source the actual delivery of those services to third-party C. This can be represented in the ontology as follows:

  • A, B, and C are instances of HumanActor.
  • Service is an instance of Service.
  • C provides Service.
  • ServiceContract is an instance of ServiceContract.
  • ServiceContract isContractFor Service.
  • ServiceContract involvesParty A.
  • ServiceContract involvesParty B.

The legalAspect datatype property on ServiceContract describes the legal obligation of B to provide Service for A.

Car Wash Example

See Section 8.2 for the complete Service and ServiceContract aspects of the car wash example.

The ServiceInterface Class

<owl:Class rdf:about="#ServiceInterface">   <owl:disjointWith>     <owl:Class rdf:about="#Service"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#ServiceContract"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#Effect"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#HumanActor"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#Task"/>   </owl:disjointWith> </owl:Class>

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 which is illustrated below.

The ServiceInterface 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.

ServiceInterfaceis 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.

The Constraints Datatype Property

<owl:DatatypeProperty rdf:about="#constraints">   <rdfs:domain rdf:resource="#ServiceInterface"/> </owl:DatatypeProperty>   <owl:Class rdf:about="#ServiceInterface">   <rdfs:subClassOf>     <owl:Restriction>       <owl:onProperty>         <owl:DatatypeProperty rdf:about="#constraints"/>       </owl:onProperty>       <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"       >1</owl:minCardinality>     </owl:Restriction>   </rdfs:subClassOf>   <rdfs:subClassOf>     <owl:Restriction>       <owl:onProperty>         <owl:DatatypeProperty rdf:about="#constraints"/>       </owl:onProperty>       <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"       >1</owl:maxCardinality>     </owl:Restriction>   </rdfs:subClassOf> </owl:Class>

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).

The hasInterface and isInterfaceOf Properties

<owl:ObjectProperty rdf:about="#hasInterface">   <rdfs:domain rdf:resource="#Service"/>   <rdfs:range rdf:resource="#ServiceInterface"/> </owl:ObjectProperty>   <owl:ObjectProperty rdf:about="#isInterfaceOf"/>   <owl:inverseOf>     <owl:ObjectProperty rdf:about="#hasInterface"/>   </owl:inverseOf> </owl:ObjectProperty>   <owl:Class rdf:about="#Service">   <rdfs:subClassOf>     <owl:Restriction>       <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"       >1</owl:minCardinality>       <owl:onProperty>         <owl:ObjectProperty rdf:about="#hasInterface"/>       </owl:onProperty>     </owl:Restriction>   </rdfs:subClassOf> </owl:Class>

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.

The InformationType Class

<owl:Class rdf:about="#InformationType">   <owl:disjointWith>     <owl:Class rdf:about="#Effect"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#ServiceContract"/>   </owl:disjointWith> </owl:Class>

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, which is illustrated below.

The 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.

The hasInput and isInputAt Properties

<owl:ObjectProperty rdf:about="#hasInput">   <rdfs:domain rdf:resource="#ServiceInterface"/>   <rdfs:range rdf:resource="#InformationType"/> </owl:ObjectProperty>   <owl:ObjectProperty rdf:about="#isInputAt">   <owl:inverseOf>     <owl:ObjectProperty rdf:about="#hasInput"/>   </owl:inverseOf> </owl:ObjectProperty>

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).

The hasOutput and isOutputAt Properties

<owl:ObjectProperty rdf:about="#hasOutput">   <rdfs:domain rdf:resource="#ServiceInterface"/>   <rdfs:range rdf:resource="#InformationType"/> </owl:ObjectProperty>   <owl:ObjectProperty rdf:about="#isOutputAt">   <owl:inverseOf>     <owl:ObjectProperty rdf:about="#hasOutput"/>   </owl:inverseOf> </owl:ObjectProperty>

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).

Examples

Interaction Sequencing

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.

Car Wash Example

See Section 8.2 for the complete ServiceInterface aspect of the car wash example.