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

转载 2006年06月01日 15:24:00

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 likely 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

Business analysis and SOA part 1 of 6: The benefits of business services [by Thomas Erl]

 This is the first article in a six-part series dedicated to exploring how SOA and service-orientati...
  • Xalloy
  • Xalloy
  • 2006年06月01日 15:20
  • 1239

Business analysis and SOA part 2 of 6: Business service models and the entity-centric business service [by Thomas Erl]

 As part of the design of service-oriented solutions it is common to label individual services accor...
  • Xalloy
  • Xalloy
  • 2006年06月01日 15:23
  • 1262

BABOK(Business Analysis Body of Knowledge)阅读笔记(二) Introduction

在这一章节的介绍中,BABOK对"What is Business Analysis"做了一个权威的定义:"Business analysis is the set of tasks and tech...
  • bruesz
  • bruesz
  • 2009年07月20日 17:29
  • 2247

Business analysis and SOA part 4 of 6: SOA delivery lifecycle and the top-down approach [by Thomas Erl]

 Development projects for service-oriented solutions are, on the surface, much like any other custom...
  • Xalloy
  • Xalloy
  • 2006年06月01日 15:27
  • 1752


业务分析BA逐渐成为当前一个热门领域,未来10年,多数公司对于BA人才和技能有持续旺盛的需求。目前有两个常见的考试认证CBAP和PMI-PBA, 下面对比介绍CBAP和PBA,供广大学友和考生参考。可...
  • crimosn7
  • crimosn7
  • 2016年08月09日 13:35
  • 1018

我们分析了全美Top Business Analyst 和 Data Science专业,最后给你总结了这几点

  • zw0Pi8G5C1x
  • zw0Pi8G5C1x
  • 2018年01月06日 00:00
  • 2477

BABOK(Business Analysis Body of Knowledge)阅读笔记(一) 前言

BABOK (Business Analysis Body of Knowledge), 可以称为是BA界的圣经(Bible)。目前流传比较广泛的是BABOK1.6(正式版),但是目前其实已经出了BA...
  • bruesz
  • bruesz
  • 2009年07月15日 14:55
  • 2029

创建SharePoint Business Data Connectivity Service Application

SharePoint中的Business Data ConnectivityService是一个非常有用的功能,使用这个service,可以很容易的和外部的系统(database,web servic...
  • SPFarm
  • SPFarm
  • 2015年03月02日 11:05
  • 941

Business Analysis note part 1

The data that we might be tracking :such as : marketing activities,competitive information,macro eco...
  • qq_32424029
  • qq_32424029
  • 2016年07月01日 19:03
  • 146

SQL Server 2005 Integration Services (SSIS) (3) - Business Intelligence Development Studio

 三,SQL Server Integration Services 开发环境– Business Intelligence Development Studio (BIDS)           在...
  • Me_online
  • Me_online
  • 2007年03月30日 11:00
  • 6932
您举报文章:Business analysis and SOA part 3 of 6: Process-centric business services [by Thomas Erl]