Business analysis and SOA part 3 of 6: Process-centric business services [by Thomas Erl]

 
In the previous article we described the role of service models and explored the design standards for an entity-centric business service. This model establishes a highly process-agnostic encapsulation context in that the logic placed into these types of services is not directly related to any one business process. So, where does the process logic go? There are two common options we'll explore shortly, each of which represents another distinct type of service model. But first, let's discuss agnostic services some more and explain how they can be realized through the abstraction of business process logic.

Agnostic services and business process logic abstraction

Agnostic business services are considered valuable members of growing enterprise service portfolios -- valuable in that they provide a high level of reuse potential and are therefore positioned (and measured) as actual IT assets. Abstraction, one of the most fundamental service-orientation principles, fully supports the creation of agnostic business services by allowing us to cleanly separate and even isolate business process logic into its own domain. This introduces a number of advantages that tie into some of the more strategic benefits of SOA.

For example, one such benefit is more efficient maintenance. When business process logic is deeply entrenched within our systems, changes to this logic often require significant redevelopment. By creating a partition or domain for these process details we can more easily maintain and extend them because less of the overall automation logic is directly tied to the process.

By furthermore representing the bulk of our systems through agnostic services, our business process domain establishes a parent service composition layer. When changes to a business process are required, this layer will be affected, but our agnostic services are more like
4000
ly to be shielded. They may need to be recomposed or perhaps extended (or even created), but the key benefit here is that they usually do not require fundamental redevelopment, thus lessening the overall impact of the changes. Their status as reusable IT assets is preserved and they are simply reutilized as required.

How business process logic is implemented within SOA comes down to how the physical architecture is designed. Many options exist, depending on the technology platform being utilized and the existence of service-based middleware. Let's take a look at two common options as we introduce the next set of service models.

The task-centric business service model

Task-centric business services exist as independently implemented services that each embed a body of business process logic. Each service is generally tied to a specific task, which may represent a business process in its entirety or perhaps a well-defined sub-process. Because the service context is defined by the scope of a task, operations (and often there is just one) are grouped accordingly.

Typical sources for deriving task-centric business services include use-case models and BPM process definitions. While they tend to require less analysis effort than entity-centric business services, they also have less reusability potential. To seriously model a reusable task-centric business service will generally require the analysis of multiple use-cases and business process models prior to defining the actual service.

Orchestration and the process service model

Organizations that already have employed enterprise application integration (EAI) middleware products to automate business processes or to integrate various legacy environments will likely already be familiar with the concept of orchestration. In these systems, a centrally controlled set of workflow logic facilitates interoperability between two or more different applications. A common implementation of orchestration is the hub-and-spoke model that allows multiple external participants to interface with a central orchestration engine.

One of the driving requirements behind the creation of these solutions was to accommodate the merging of large business processes. With orchestration, different processes can be connected without having to redevelop the solutions that originally automated the processes individually. Orchestration bridges this gap by introducing new workflow logic.

The role of orchestration broadens in service-oriented environments. Through the use of extensions that allow for business process logic to be expressed via services, orchestration can represent and express business logic in a standardized, services-based venue. When building service-oriented solutions, this provides an extremely attractive means of housing and controlling this logic in one central physical location (the orchestration platform).

The orchestration service layer establishes a parent business process layer that can be expressed through service composition technologies, such as Business Process Execution Language (BPEL). A business process definition created using BPEL can be represented in its entirety by a Web service, introducing a new service model that can simply be called the process service.

Comparing process-centric service models

From a service composition perspective, a process service is a lot like a task-centric business service. Each encapsulates business process logic that can be composed as part of a greater parent business process. It is by studying how these models relate to physical architecture where their primary differences come to light. The task-centric model is decentralized in that it distributes process logic across numerous physical services. These services often exist as Web services that encapsulate components or environments wherein individual pieces of process logic are embedded. Process services represent a centralized process architecture, where middleware providing an orchestration engine (and related system services) acts as the primary hosting environment.

Process services are functionally dependent on their underlying orchestration platform. Although they are typically always suitable for managing long-running activities, they may be challenged to adequately fulfill real-time processing requirements. Task-centric services, on the other hand, simply represent standalone services. Real-time performance is more easily achieved, but is ultimately dependent on the collective performance of the underlying service composition. Using task-centric services to manage long-running service activities is less common.

Another consideration when contrasting these service models is their respective cost and complexity. Imposing an orchestration layer introduces technology that can significantly impact an environment right from the infrastructure layer all the way to how an IT department governs its systems. Task-centric services are often utilized out of necessity when orchestration technology is not an option.

Either way, it is also important to note that the use of one process-centric service model does not exclude the use of another. Each model simply establishes a service that will likely compose others, but that is also itself a composable service.

What's next

In our next installment we'll introduce some of the common SOA project delivery strategies. Top-down and bottom-up approaches will be compared and common deliverables of top-down analysis stages will also be discussed.

This article contains excerpts from "Service-Oriented Architecture: Concepts, Technology, and Design" by Thomas Erl (792 pages, Hardcover, ISBN: 0131858580, Prentice Hall/Pearson PTR, Copyright 2006). For more information, visit www.soabooks.com.