Process Centralization

How can abstracted business process logic be centrally governed?

Problem When business process logic is distributed across independent service implementations, it can be problematic to extend and evolve.
Solution By leveraging orchestration technology, logic representing numerous business processes can be deployed and governed from a central location.
Application Middleware platforms generally provide the necessary orchestration technologies to apply this pattern.	Impacts Significant infrastructure and architectural changes are imposed when the required middleware is introduced.
Principles Service Autonomy, Service Statelessness, Service Composability	Architecture Inventory, Composition

Table 6.17 – Profile summary for the Process Centralization pattern.

Problem

Within environments containing larger service inventories, the requirement to concurrently to support the automation of multiple business processes is common. Business process logic that spans multiple business entities (process logic that cannot be represented by any one entity service) can be placed into individual task services.

While these services exist as peer members of a service inventory, the fact that they are independently implemented results in an enterpriseÕs business process logic being physically distributed across multiple locations. When changes come along, the ability to efficiently extend, streamline, or even combine business process logic is inhibited because the underlying service logic of each affected task service needs to be revisited, opened up, and changed, as required.

Furthermore, due to the nature of the underlying workflow logic, some business processes cannot be carried out in real-time. Instead, they may impose long-running service activities that can span minutes, hours, and even days. Independent task service implementations need to be equipped with state deferral extensions to facilitate these requirements. While this is technically feasible, it can become somewhat tedious to repeat these implementation extensions across numerous individual service environments, especially when the task services are highly distributed across different physical servers (and perhaps even across different vendor runtime platforms).

Figure 6.76 – Task services are commonly implemented as individual Web services. Because each program contains embedded business process logic, it results in a physically decentralized business process architecture.

Solution

Parent business process logic (representing some or all of the business processes within a given domain) is centralized into one location. An orchestration platform hosts and executes this logic while allowing for its on-going centralized maintenance.

Figure 6.77 – Task services can continue to be implemented as separate Web services, but as part of an orchestration platform their collective business process logic can be centrally governed. (This results in orchestrated task services.)

Note: The result of applying this pattern is still a collection of new task services. Only, because they are hosted and executed within a very specific (and an intentionally more stateful) environment, they can be further qualified as ÒorchestratedÓ (as per the orchestrated task service model).

Application

Orchestration platforms that emerged during the EAI era provide a fundamental medium for process logic centralization. When combined with support for open business process definition languages (such as WS-BPEL), these platforms become suitable for establishing a primary parent composition layer within SOA.

To realize this design pattern, a modern orchestration platform is required. Such a platform is typically comprised of the following:

•     A graphical front-end tool allowing users to express and maintain business process logic.

•     A back-end middleware runtime environment capable of hosting orchestrated task services and the corresponding collection of business process definitions created with the front-end tool.

•     Features that comply with industry standards related to business process logic expression and execution, such as WS-BPEL.

In a nutshell, the composition logic for a specific business process is defined using the front-end tool and then encapsulated by a specific orchestrated task service. The back-end platform hosts the service in the same environment as others, allowing these services to carry out their composition logic with a range of supporting features, including state management, and various service agents.

Impacts

The overall impact of this design pattern depends on the extent to which service-related middleware already exists as part of the enterprise. If no middle tier exists, its introduction will affect the surrounding infrastructure and the complexion of the overall technology architecture as well as affected service inventories.

Furthermore, the front and back-end products required to support orchestration are rarely implemented in isolation. When creating an orchestration environment, the middleware platform is typically expanded to encompass a range of centralized service governance functions.

Introducing orchestration technology into an enterprise can be expensive and disruptive. The infrastructure requirements to host and run the necessary middleware can increase the size and overall operational costs of the IT environment as a whole. It is therefore best to decide whether an orchestration layer will be established as early in the technology architecture planning process as possible.

Relationships

The centralized environment established via the application of this pattern affects a variety of architectural considerations. Because Process Centralization represents a core part of the Orchestration compound pattern (shown subsequently in Figure 5.x), Canonical Resources comes into play, especially when more than one orchestration engine is a possibility.

The use of an industry-standard business process definition language (such as WS-BPEL) fully supports the Vendor-Agnostic Context pattern, and process centralized environments naturally require state management extensions (as per State Repository and Partial State Deferral) due to the tendency of orchestrated task services to be more stateful.

Finally, this pattern is simply focused on the physical location of process logic and therefore equally supports both Capability Composition and Capability Recomposition patterns.

Figure 6.78 – The Process Centralization pattern establishes a physical process hub within an architecture, and therefore can affect the application of several other patterns.

Figure 6.79 – Process Centralization is most commonly associated with its role as part of the core patterns that represent the Orchestration compound pattern.

Case Study Example

Case study content is not available on this Web site.