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:
Figure 1. SOA-O 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.
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:
Figure 2. SOA-O 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.
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.).
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.