Composition Roles
With the potential for Capability Recomposition
to be applied frequently, a given service can find itself participating
in different ways within a given service composition. Therefore, in
order to better identify and describe the interaction between services
within a service composition architecture, a set of runtime roles exist:
composition controller–
The service with a capability that is executing the parent composition
logic required to compose capabilities within other services.
composition member– A service that participates in a service composition by being composed by another service.
composition initiator–
The program that initiates a service composition by invoking the
composition controller. This program may or may not exist as a service.
composition sub-controller–
A variation of the composition controller role that is assumed by a
service carrying out nested composition logic (within a capability that
is composing one or more other service capabilities while itself also
being composed).
Services assume composition
roles within the context of different service compositions, depending on
the logic executed by service capabilities. In other words, a service’s
capabilities will automatically enlist the service in one or more
composition roles.
Service Layers
These service models represent the two most
common agnostic functional contexts for services (in other words, they
represent the two popular means of further applying the Agnostic Context pattern).
When we abstract common
types of logic into collections of services based on the same underlying
service model, we end up establishing service layers. These logical
layers are the result of the application of the Service Layers pattern, which provides us with an opportunity to organize and classify all services within a given service inventory.
Service Layers
requires that at least two layers exist, and these layers are generally
based on a fundamental separation of agnostic and non-agnostic service
logic. Therefore, we typically end up with a task service layer,
followed by a service layer based on one or more agnostic service
models, as shown in Figure 6.
The Three-Layer Inventory compound pattern essentially indicates that the most common application of Service Layers is via the combined application of Entity Abstraction , Utility Abstraction, and Process Abstraction.
This establishes a logical layered architecture that tends to encompass
the natural hierarchy formed by most service compositions (Figure 7).
Note
The top layer shown in Figure 7 is defined via the application of the Process Abstraction pattern, which is explained shortly.
Non-Agnostic Context
When decomposing business process logic as part of a service-oriented
analysis, what remains after multi-purpose logic is separated logic that
is specific to the business process. Because this logic is considered
single-purpose in nature, it is classified as non-agnostic. The
encapsulation of non-agnostic logic within a service is the basis of the
Non-Agnostic Context pattern (Figure 8).
Process Abstraction and Task Services
The
types of agnostic services are
generally (but not always) dependent on the existence of abstracted,
non-agnostic business process logic that is encapsulated in task
services (Figure 9).
This is the result of the combined application of Non-Agnostic Context and Process Abstraction.
Note
The runtime role that is most
commonly associated with the task service model is the composition
controller because the functional scope of these services is typically
focused on a parent business process. A variation of the task service
model, called the orchestrated task service.
