Service-Oriented Architecture Ontology Version 2.0 – Composition and its Subclasses



The notion of composition is a core concept of SOA. Services can be composed of other services. Processes are composed of human actors, tasks, and possibly services. Experienced SOA practitioners intuitively apply composition as an integral part of architecting, designing, and realizing SOA systems; in fact, any well structured SOA environment is intrinsically composite in the way services and processes support business capabilities. What differs from practitioner to practitioner is the exact nature of the composition – the composition pattern being applied.

This chapter describes the following classes of the ontology:

  • Composition (as a subclass of System)
  • ServiceComposition (as a subclass of Composition)
  • Process (as a subclass of Composition)

In addition, it defines the following datatype property:

  • compositionPattern

The Composition Class

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

A composition is the result of assembling a collection of things for a particular purpose. Note in particular that we have purposefully distinguished between the act of composing and the resulting composition as a thing, and that it is in the latter sense we are using the concept of composition here. The concept of composition is captured by the Composition OWL class, which is illustrated below.

The Composition Class

Being intrinsically (also) an organized collection of other, simpler things, the Composition class is a subclass of the System class. While a composition is always also a system, a system is not necessarily a composition in that it is not necessarily a result of anything – note here the difference between a system producing a result and the system itself being a result. A perhaps more tangible difference between a system and a composition is that the latter must have associated with it a specific composition pattern that renders the composition (as a whole) as the result when that composition pattern is applied to the elements used in the composition. One implication of this is that there is not a single member of a composition that represents (as an element) that composition as a whole; in other words, the composition itself is not one of the things being assembled. On the other hand, composition is in fact a recursive concept (as are all subclasses of System) – being a system, a composition is also an element which means that it can be used by a higher-level composition.

In the context of the SOA ontology we consider in detail only functional compositions that belong to the SOA domain. Note that a fully described instance of Composition must have by its nature a uses relationship to at least one instance of Element. (It need not necessarily have more than one as the composition pattern applied may be, for instance, simply a transformation.) Again (as for System) it is important to realize that a composition can use elements outside its own boundary.

Since Composition is a subclass of Element, all compositions have a boundary and are opaque to an external observer (black box view). The composition pattern in turn is the internal viewpoint (white box view) of a composition. As an example, for the notion of a service composition this would correspond to the difference between seeing the service composition as an element providing a (higher-level) service or seeing the service composition as a composite structure of (lower-level) services.

The compositionPattern Datatype Property

<owl:DatatypeProperty rdf:about="#compositionPattern">     <rdfs:domain rdf:resource="#Composition"/> </owl:DatatypeProperty>   <owl:Class rdf:about="#Composition">   <rdfs:subClassOf>     <owl:Restriction>       <owl:maxCardinality rdf:datatype=""       >1</owl:maxCardinality>       <owl:onProperty>         <owl:DatatypeProperty rdf:about="#compositionPattern"/>       </owl:onProperty>     </owl:Restriction>   </rdfs:subClassOf>   <rdfs:subClassOf>     <owl:Restriction>       <owl:onProperty>         <owl:DatatypeProperty rdf:about="#compositionPattern"/>       </owl:onProperty>       <owl:minCardinality rdf:datatype=""       >1</owl:minCardinality>     </owl:Restriction>   </rdfs:subClassOf> </owl:Class>

As discussed above, any composition must have associated with it a specific composition pattern, that pattern describing the way in which a collection of elements is assembled to a result. The concept of a composition pattern is captured by the compositionPattern datatype property. Note that even though certain kinds of composition patterns are of special interest within SOA (see below), the compositionPattern datatype property may take any value as long as that value describes how to assemble the elements used by the composition with which it is associated.

The Orchestration Composition Pattern

One kind of composition pattern that has special interest within SOA is an orchestration. In an orchestration (a composition whose composition pattern is an orchestration), there is one particular element used by the composition that oversees and directs the other elements. Note that the element that directs an orchestration by definition is different than the orchestration (Composition instance) itself.

Think of an orchestrated executable workflow as an example of an orchestration. The workflow construct itself is one of the elements being used in the composition, yet it is different from the composition itself – the composition itself is the result of applying (executing) the workflow on the processes, human actors, services, etc. that are orchestrated by the workflow construct.

A non-IT example is the foreman of a road repair crew. If the foreman chooses to exert direct control over the tasks done by his crew, than the resulting composition becomes an orchestration (with the foreman as the director and provider of the composition pattern). Note that under other circumstances, with a different team composition model, a road repair crew can also act as a collaboration or a choreography. (See below for definitions of collaboration and choreography.)

As the last example clearly shows, using an orchestration composition pattern is not a guarantee that “nothing can go wrong”. That would, in fact, depend on the orchestration director’s ability to handle exceptions.

The Choreography Composition Pattern

Another kind of composition pattern that has special interest within SOA is a choreography. In a choreography (a composition whose composition pattern is a choreography) the elements used by the composition interact in a non-directed fashion, yet with each autonomous member knowing and following a predefined pattern of behavior for the entire composition.

Think of a process model as an example of a choreography. The process model does not direct the elements within it, yet does provide a predefined pattern of behavior that each such element is expected to conform to when “executing”.

The Collaboration Composition Pattern

A third kind of composition pattern that has special interest within SOA is a collaboration. In a collaboration (a composition whose composition pattern is a collaboration) the elements used by the composition interact in a non-directed fashion, each according to their own plans and purposes without a predefined pattern of behavior. Each element simply knows what it has to do and does it independently, initiating interaction with the other members of the composition as applicable on its own initiative. This means that there is no overall predefined “flow” of the collaboration, though there may be a run-time “observed flow of interactions”.

A good example of a collaboration is a work meeting. There is no script for how the meeting will unfold and only after the meeting has concluded can we describe the sequence of interactions that actually occurred.

The orchestrates and orchestratedBy Properties

<owl:ObjectProperty rdf:about="#orchestratedBy">   <rdfs:domain rdf:resource="#Composition"/>   <rdfs:range rdf:resource="#Element"/> </owl:ObjectProperty>   <owl:ObjectProperty rdf:about="#orchestrates">   <owl:inverseOf>     <owl:ObjectProperty rdf:about="#orchestratedBy"/>   </owl:inverseOf> </owl:ObjectProperty>   <owl:Class rdf:about="#Composition">   <rdfs:subClassOf>     <owl:Restriction>       <owl:maxCardinality rdf:datatype=""       >1</owl:maxCardinality>       <owl:onProperty>         <owl:ObjectProperty rdf:about="#orchestratedBy"/>       </owl:onProperty>     </owl:Restriction>   </rdfs:subClassOf>   <rdfs:subClassOf>     <owl:Restriction>       <owl:minCardinality rdf:datatype=""       >0</owl:minCardinality>       <owl:onProperty>         <owl:ObjectProperty rdf:about="#orchestratedBy"/>       </owl:onProperty>     </owl:Restriction>   </rdfs:subClassOf> </owl:Class>   <owl:Class rdf:about="#Element">   <rdfs:subClassOf>     <owl:Restriction>       <owl:minCardinality rdf:datatype=""       >0</owl:minCardinality>       <owl:onProperty>         <owl:ObjectProperty rdf:about="#orchestrates"/>       </owl:onProperty>     </owl:Restriction>   </rdfs:subClassOf>   <rdfs:subClassOf>     <owl:Restriction>       <owl:maxCardinality rdf:datatype=""       >1</owl:maxCardinality>       <owl:onProperty>         <owl:ObjectProperty rdf:about="#orchestrates"/>       </owl:onProperty>     </owl:Restriction>   </rdfs:subClassOf> </owl:Class>

As defined above, an orchestration has one particular element that oversees and directs the other elements used by the composition. This type of relationship is important enough that we have chosen to capture the abstract notion in the orchestrates property and its inverse orchestratedBy.

In one direction, a composition has at most one element that orchestrates it, and the cardinality can only be one (1) if in fact the composition pattern of that composition is an orchestration. In the other direction, an element can orchestrate at most one composition which then must have an orchestration as its composition pattern.

Note that in practical applications of the ontology, even though Service is a subclass of Element, a service (as a purely logical representation) is not expected to orchestrate a composition.

The ServiceComposition Class

<owl:Class rdf:about="#ServiceComposition">   <rdfs:subClassOf>     <owl: rdf:about="#Composition"/>   </rdfs:subClassOf>   <owl:disjointWith>     <owl:Class rdf:about="#ServiceContract"/>   </owl:disjointWith>   <owl:disjointWith>     <owl: rdf:about="#ServiceInterface"/>   </owl:disjointWith> </owl:Class>

A key SOA concept is the notion of service composition, the result of assembling a collection of services in order to perform a new higher-level service. The concept of service composition is captured by the ServiceComposition OWL class, which is illustrated below.

The ServiceComposition Class

As a service composition is the result of assembling a collection of services, ServiceComposition is naturally a subclass of Composition.

A service composition may, and typically will, add logic (or even “code”) via the composition pattern. Note that a service composition is not the new higher-level service itself (due to the System and Service classes being disjoint); rather it performs (as an element) that higher-level service.

The Process Class

<owl:Class rdf:about="#Process">   <rdfs:subClassOf>     <owl:Class rdf:about="#Composition"/>   </rdfs:subClassOf>   <owl:disjointWith>     <owl:Class rdf:about="#ServiceContract"/>   </owl:disjointWith>   <owl:disjointWith>     <owl:Class rdf:about="#ServiceInterface"/>   </owl:disjointWith> </owl:Class>

Another key SOA concept is the notion of process. A process is a composition whose elements are composed into a sequence or flow of activities and interactions with the objective of carrying out certain work. This definition is consistent with, for instance, the Business Process Modeling Notation (BPMN) 2.0 definition of a process. The concept of process is captured by the Process OWL class, which is illustrated below.

The Process Class

Elements in process compositions can be things like human actors, tasks, services, other processes, etc. A process always adds logic via the composition pattern; the result is more than the parts. According to their collaboration pattern, processes can be:

  • Orchestrated: When a process is orchestrated in a business process management system, then the resulting IT artifact is in fact an orchestration; i.e., it has an orchestration collaboration pattern. This type of process is often called a process orchestration.
  • Choreographed: For example, a process model representing a defined pattern of behavior. This type of process is often called a process choreography.
  • Collaborative: No (pre)defined pattern of behavior (model); the process represents observed (executed) behavior.

Service Composition and Process Examples

Simple Service Composition Example

Using a service composition example, services A and B are instances of Service and the composition of A and B is an instance of ServiceComposition (that uses A and B):

  • A and B are instances of Service.
  • X is an instance of ServiceComposition.
  • X uses both A and B (composes them according to its service composition pattern).

Note that there are various ways in which the service composition pattern can compose A and B, all of which are relevant in one situation or another. For example, interfaces of X may or may not include some subset of the interfaces of A and B. Furthermore, the interfaces of A and B may or may not also be (directly) invocable without going through X – that is a matter of the service contracts and/or access policies that apply to A and B. Finally, X may also use other elements that are not services at all (examples are composition code, adaptors, etc.).

Process Example

Using a process example, tasks T1 and T2 are instances of Task, roles R1 and R2 are instances of Element, and the composition of T1, T2, R1, and R2 is an instance of Process (that uses T1, T2, R1, and R2):

  • T1 and T2 are instances of Task.
  • R1 and R2 are instances of Element.
  • Y is an instance of Process.
  • Y uses all of T1, T2, R1, and R2 (composes them according to its process composition pattern).

Process and Service Composition Example

Elaborating on the process example above, if T1 is done using service S then:

  • S is an instance of Service.
  • T1 uses S.

Note that depending on the particular design approach chosen (and the resulting composition pattern), Y may or may not use S directly. This depends on whether Y carries the binding between T1 and S or whether that binding is encapsulated in T1.

Car Wash Example

See Section 8.3 for the Process aspect of the car wash example.