Process Abstraction

How can non-agnostic process logic be separated and governed independently?

Problem Grouping task-centric logic together with task-agnostic logic hinders the governance of the task-specific logic and the reuse of the agnostic logic.
Solution A dedicated parent business process service layer is established to support governance independence and the positioning of task services as potential enterprise resources.
Application Typically, business process logic is filtered out after utility and entity services have been defined, allowing for the definition of task services that comprise this layer.	Impacts In addition to the modeling and design considerations associated with creating task services, abstracting parent business process logic establishes an inherent dependency on carrying out that logic via the composition of other services.
Principles Service Loose Coupling, Service Abstraction, Service Composability	Architecture Inventory, Composition, Service

Table 5.9 – Profile summary for the Process Abstraction pattern.

Problem

Logic that is specific to a parent business process (a process that spans entity service boundaries) has limited or different reuse potential from logic that is specific to business entities.

Grouping these two types of logic together has several repercussions:

•       it reduces opportunities for applying the Service Reusability design principle on a broad scale

•       it imposes governance complexity when expertise associated with business entities and business processes lie with different analysts

•       it makes it difficult to apply the related Non-Agnostic Service Context pattern, thereby reducing the chances of successfully abstracting cross-entity logic into legitimate services

As illustrated in Figure 5.x, this grouping can further result in the fragmented implementation of task logic.

Figure 5.37 – Parent business process-specific logic is grouped with other logic that is likely agnostic, resulting in some dispersal. The primary negative effect is that by combining task-specific and task-agnostic logic, the opportunity to establish agnostic services in support of the Agnostic Context pattern (and other related patterns, such as Logic Centralization) is hindered.

Solution

Business logic that spans multiple entity service boundaries is abstracted into a distinct functional context associated with the task service model. This establishes a parent service layer responsible for containing workflow and service composition logic required to carry out the parent business process (Figure 5.x).

The application of this pattern allows for effective long-term governance, as the task service owner is only responsible for process-specific logic. It further supports the goals of the Non-Agnostic Service Context pattern in that task service logic is made separately available for potential future reuse.

Figure 5.38 – Solution logic limited to the fulfillment of business processes is abstracted into separate task services, each representing one business process definition. This establishes a parent task service layer that abstracts non-agnostic business process logic responsible for composing agnostic services.

Application

It may appear as though this pattern is applied out of necessity in support of the Utility Abstraction and Entity Abstraction patterns. Because these two patterns force the isolation of business process-agnostic logic, any logic that is specific to parent business processes must be located in its own layer.

However, logic residing in a business process layer may not need to be encapsulated by services. The formation of a task service layer is the result of repeatedly applying the Service Encapsulation and Non-Agnostic Service Context patterns to this logic so as to shape it into well defined services, as appropriate.

Services based on a task-centric context are very similar in concept to traditional applications, in that they are associated with the execution of a specific business process. Therefore, these types of services are more easily incorporated into established project delivery lifecycles and subsequent ownership arrangements.

The intentional abstraction of process logic into a separate service layer needs to be established alongside the definition of other service layers to ensure that subsequent modeling and design processes properly carry out the allocation of this logic. As with the inventory structure patterns, this pattern is realized via specialized analysis and design processes, examples of which are provided at SOAMethodology.com.

Impacts

The deliberate separation of business process logic into dedicated services generally positions these services as parent controllers of service compositions. Because essential agnostic logic will have been abstracted into other services, task services will almost always depend on multiple agnostic services to carry out their business process logic. An organization needs to be prepared to implement and support service compositions in order for this pattern to be effectively applied.

Relationships

Because the Process Abstraction pattern provides a service classification dedicated to encapsulating non-agnostic logic, its application filters out single-purpose logic in support of defining agnostic services, as per the Entity Abstraction and Utility Abstraction patterns.

When applied, this pattern tends to produce task services that are commonly responsible for encapsulating the composition logic required for the fundamental Capability Composition and Capability Recomposition patterns.

As shown in Figure 5.x, the key foundations of this pattern are the Non-Agnostic Context and Business-Driven Context patterns, which together establish the intentionally single-purpose, business process-specific scope that results in the creation of task services.

Figure 5.39 – The Process Abstraction pattern is vital to establishing a parent business task service layer wherein single purpose logic can be placed so that agnostic services can be comprised of pure, multi-purpose logic.

The concept of abstracting parent process logic into a logical layer forms the basis for modern orchestration platforms that are commonly based on Web service composition technologies, such as WS-BPEL. When associated with the Orchestration compound pattern (Figure 5.x), the application of the Process Abstraction pattern is assumed to result in a variation of the task service model called the orchestrated task service.

Figure 5.40 – The Process Abstraction patter is one of three core patterns that comprise the Orchestration compound pattern (described separately in Chapter 9).

Case Study Example

Case study content is not available on this Web site.