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

IOS App上传App Store 由于使用第三方支付而被拒绝的解决方案

最近在做项目时,涉及用户付费。于是就找来了支付宝和微信支付的集成教程,按照要求分别开通各自开发平台的开发者账号和商户号。在后台加入了支付的支持,一步步的集成和测试,通过后打包上传到App Store ...
  • txinhuacdn
  • txinhuacdn
  • 2016年09月29日 09:51
  • 21416

UML建模之业务处理模型(Business Process Model,BPM)

一、业务处理模型简介(Brief introduction) 二、业务处理模型元素(Elements) 1、目标(Goal) 2、消息(Information) 3、资源(Re...
  • heshengfen123
  • heshengfen123
  • 2013年07月18日 00:12
  • 1316


拒绝理由Notes from App ReviewWe have begun the review of your In-App Purchase(s) but aren’t able to cont...
  • imanapple
  • imanapple
  • 2015年08月21日 10:40
  • 1410

How to balance the business benefits and IT costs of SOA by Gartner

  • 2016年02月15日 05:51
  • 1.68MB
  • 下载

Business Process Management Enabled by SOA.pdf

  • 2009年07月29日 16:46
  • 905KB
  • 下载

  • 2008年05月09日 17:00
  • 2.38MB
  • 下载

IBM Press - The New Language of Business SOA and Web 2.0

  • 2007年08月11日 14:27
  • 2.38MB
  • 下载

Thomas Erl: SOA Principles of Service Design SOA:服务设计原则(英文版)

  • 2010年05月01日 23:01
  • 27.58MB
  • 下载

(CBAP - Babok V3) A Guide to the Business Analysis Body of Knowledge

  • 2017年08月20日 06:48
  • 3.14MB
  • 下载

(BABOK Guide v3) IIBA-A Guide to the Business Analysis Body of Knowledge

  • 2017年11月02日 17:40
  • 2.13MB
  • 下载
您举报文章:Business analysis and SOA part 3 of 6: Process-centric business services [by Thomas Erl]