Each service in the solution exists in exactly one of the following logical (architectural) "layers:"
-
Orchestration layer (sometimes called "orchestrated services" or "process services")
-
Entity services layer
-
Task services layer
-
Utility services layer
The definition of layers in this process is aligned with the work of Thomas Erl.
Each of these layers is described in more detail in the following paragraphs.
Orchestration Layer
Erl[2005] defines the orchestration layer as follows:
The orchestration service layer introduces a parent level of abstraction that alleviates the need for other
services to manage interaction details required to ensure that service operations are executed in a specific
sequence. Within the orchestration service layer, process services compose other services that provide specific
sets of functions, independent of the business rules and scenario-specific logic required to execute a process
instance.
Entity Services Layer
From Erl[2005]:
A service that encapsulates processing logic associated with a specific business entity... Entity-centric business
services are designed to provide a set of features that provide data management related only to their corresponding
entities. They are therefore business process-agnostic. The same entity-centric business services can (and should)
be reused by different process or task-centric business services.
Task Services Layer
From Erl[2005]:
A service that encapsulates business logic specific to a task. .
Utility Services Layer
From Erl[2005]:
The utility service layer intentionally abstracts non-business-related logic (logic that is not derived from an
organization's business models) into a set of services that can simply be referred to as ... utility services.
Their purpose is to provide reusable functions that address cross-cutting concerns by representing common
enterprise resources and capabilities.
|