本文发表于《中国计算机用户》杂志2009年第3、4期

http://media.ccidnet.com/art/2655/20090106/1652443_1.html

http://media.ccidnet.com/art/2655/20090223/1686267_1.html

大型企业信息化中的BPM和SOA实战

万星[1]

JPort Group

北京交通大学

1       概览

对于BPM和SOA的理解一直是非常困难的，我认为如果没有企业信息系统的丰富开发背景，以及对于软件工程历史的充分了解，想要从纷繁的概念中理清一条思路，进一步为己所用更是让人难以下手。SOA和BPM概念的提出都具有悠久的历史，在学术界的研究也在向语义SOA和语用SOA等方向发展（这也是我们另一个实验室正在探索的方向）。而厂商的驱动使得SOA和BPM逐渐落地，从早期的大量文献在解释SOA≠Web Service，到后来ESB的出现，以及最近的SCA/SDO规范的完善（特别是具体产品的落地），直至今年兴起的BPM和SOA热潮，我们可以看到SOA离我们的工业实践越来越近了，它不再是一个时髦的大词。工作流抑或业务流程的辨析同样也使用户为难，简单而言，业务流程∈工作流。业务流程管理，或BPM，强调的概念是企业应用集成（EAI）。而Workflow领域的研究则显得单纯一些。许多开发者都是从技术的角度来考虑SOA，因此相信SOA只是一种新的分布式架构或者是一种新的EAI方式。起初，我也兴奋的认为将BPM和SOA结合起来是伟大的想法（两种以EAI为目标的技术整合在一起），以流程的方式整合服务，这是比ESB的想法更加先进的主意。然而，随着研究和实践的深入，我越发觉得SOA和BPM结合带来的好处远不止于此。

1.1   我们做了什么？

我们JPort团队主要研究了IBM的BPM和SOA方法论，并结合了企业管理中的一些方法，又融合了软件开发领域几十年的模式和最佳实践，对于我国南方某大型港口企业的业务流程进行了优化，并基于优化的流程设计了SOA风格的IT系统。

我们的主要工作包括：

1 找到了从企业战略到业务操作具有完整映射的组件模型方法论——IBM创造的CBM（组件化商业模型），设计业务组件模型；

2 引入了企业价值树模型从企业战略出发推导出业务流程的KPI（关键绩效指标）；

3 结合既有的业务流程优化模式，CBM方法论，企业价值树模型，创建了一套业务流程重构方法论，包括业务流程Bad Smell，重构名录，以及评估测试模型体系；

4 利用用例对企业的既有业务流程和业务规则（包括国家法规和企业内部的规章制度以及其他更为细节的业务规则）进行了详尽的调研；

5 通过使用IBM Websphere Business Modeler（WBM）对那些画在纸上或Visio，甚至是Rational Rose中的现有业务流程模型（AS-IS Model）进行了重绘，并利用其按照我们提出的业务流程重构方法论进行业务流程优化，得到未来的业务流程模型（TO-BE Model）。在WBM中，我们可以为组件（在WBM中每个流程任务都是一个组件）的一些特别的事件属性赋值，并将那些由企业价值树模型推导出的KPI设置在相应的组件上；

6 利用IBM的SOMA（面向服务建模和架构）方法论识别，规约和实现服务；

7 使用IBM Websphere Integration Developer（WID）来设计和开发SOA系统。其中除了包含一般服务，业务流程服务，人员任务服务，状态机服务和业务规则服务，还包括与第三方服务（无线通讯服务，消息服务以及金蝶财务系统，AIS等）的交互，与远程RCP（Rich Client Platform）客户端的交互，以及遗留系统集成；

8 将系统部署在IBM Websphere Process Server和IBM Websphere ESB之上，并通过企业Dashboard监控之前在WBM中设置的KPI；

9 提供了一份完整的投资回报分析报告。

1.2   本文提供什么？

在针对该大型港口企业信息化项目中，我们遇到了一系列的问题，在理清了SOA和BPM、企业信息系统这几个大的主题纷繁复杂的知识结构，以及IBM在这些领域的众多概念之后，对关于这些主题的如下问题进行了重新的审视：

两个首先被提出来的大问题是：

n  从企业角度看SOA和BPM，SOA有何不同？

n  SOA如何帮助企业进行业务流程管理？

大量的文献都在讲解什么是SOA，然而关于它究竟有何不同的讨论却难以具有说服力。本文试图结合理论和实践，规范与实现来说明实战中的SOA和BPM是如何相互作用帮助企业提升企业绩效，满足企业核心战略，以及实现ROI（投资回报率）。

2       从企业角度看SOA和BPM

2.1   SOA有何不同？

正如前文所说，理解SOA一定要站在企业的高度，与其他方法学和技术相比，SOA具有以下特点：

n  SOA是一种架构模式（现在来看，其应该是一整套方法论），而非一个产品。

n  SOA比过去的任何IT技术都要更关注企业，其中的服务应该是指业务服务，或者说企业服务，而非具体技术提供的服务，注意这是一个识别和设计服务时选取视角的问题。与领域建模中所提到的服务区分比较困难，因为对于这两个概念的理解因人而异。

n  SOA比过去的任何IT技术更加强调抽象、关注点分离，也更加强调基于标准和规范，平台中立，技术无关，这与计算机科学的发展是密不可分的。

SOA绝不仅仅意味着企业应用集成（EAI），也绝不仅仅就是一种分布式架构，与JEE，.Net，以及更早的CORBA（公用对象请求代理（调度）程序体系结构Common Object Request Broker Architecture ）等技术相提并论。

SOA的革命性之处在于其把企业定义为提供服务的组织，服务提供的单元作为组件，就像OO（面向对象）是革命性的一样（也不仅仅只是一个编程模型）。在从面向过程、结构化方法论向OO迈进过程中（其间还经历过很多的开发范型），我们需要改变过去以机器指令看待业务执行的思维，而应以对象来建模业务。而SOA中，则需要我们从更加宏观的企业关注点出发，其最高纲领当然就是企业战略了。

在1.1节中我所提到的那些方法论，相辅相成，浑然一体，完成了一个从企业战略逐步推向IT实现，又以IT实现帮助企业监控企业绩效，从而调整企业战略的过程。在环环相扣的BPM和SOA解决方案中，可以更好的体会，SOA中的服务，是如何从企业的高度得来的。  

2.2   Component Business Model

CBM是IBM提出的以组件方式重新理解企业的方法论，在这个方法论中，包括三个主要步骤：洞察，架构和投资。其中最为重要的就是设计业务组件模型。

业务组件模型就是将企业中那些使用了相似的资源（人员，技术等）的类似活动聚合起来，其实这一概念和好处是非常容易理解的。快速理解这一概念的好方法是（我们就是这样做的），把企业的流程搜集起来，然后使用Excel将每个流程作为一列，然后行表示业务活动，你可以将那些相同的活动（不同的流程总是会共享一些共同的流程活动，比如付款，计费，查询订单号）放在同一行，给他们起一个名字，这个名字就是服务名，然后在将一些看上去属于同一类的活动用一个彩色的方块围起来，这就是一个业务组件了。企业的组织结构将帮助你设计业务组件，然而对于大型企业进行分析，你就会发现其中存在很多冗余、重复甚至是莫名奇妙的组织单元或职能部门，因此需要注意的是，不要让糟糕的组织模型限制了设计业务组件的思维。

CBM将组件放在一个二维矩阵中，横轴是责任等级，纵轴是业务能力，交点是业务组件。责任等级与我们在信息管理专业课本上看到的那个信息系统分级是一致的，CBM中定为Direct（引导），Control（控制），Execute（执行），对应的信息系统分级实际上就是战略层，战术层和操作层。其中Control主要完成的是业务的监管，包括一些分析，报告等内容。

按照IBM的官方说法⁷：业务组件包含五个方面，分别是业务用途，活动，资源，治理模式和业务服务。如果你使用过WBM，那么看到活动，资源和业务服务一定会感到兴奋，如果这些直接转成IT设计，那么我们就完成了一次从业务直接映射到IT的过程！而其中的业务服务，就是我们在SOA中的服务的一部分（因为还包括其他两类来源的服务，见2.3节）。

2.3   Service-Oriented Modeling Architecture

IBM的SOMA方法论主要就是用来识别、规约和实现服务的。识别服务主要有三种方式，第一种就是分解业务领域，其实这种方法可以借助CBM来完成，还记得前面所说的业务组件包含的业务服务吗？那个业务服务实际上就是这么推导出来的。第二种就是基于对既有系统的分析（这也是SOMA方法论中包含的一个活动），在已有的系统中（这些系统不久就变成遗留系统了），提供了哪些功能，完成了业务，这就是服务了，第一种方法叫自顶向下，第二种方法叫自底向上，而第三种方法当然就是从中间向两边了（没有创意的IT理论界）。这种方法就是从其他方面考虑一下，有没有落下的服务。

第二个步骤是制定服务规约，包括接口签名，数据对象，组件设计等。列举出的就是最重要的。其实这些设计的原则以及模式，大都可以来自于过去分布式系统的经验，而对于服务识别，我们亦可参考分析模式，我主要参考的是Martin Fowler的《分析模式》。在实际项目中，我主要需要研究计费模式。服务是通过接口暴露的，而由组件来提供相应的服务实现。这没什么特别的。而数据对象设计，这里的数据对象并非单指持久化对象，也非表现层数据对象或者数据传输对象（DTO）¹、值对象（VO）²，而是指贯穿于各层之间的数据对象。这些数据对象就是Pure Data Object，只有属性没有方法。

第三个步骤就是决策服务的实现。每种服务究竟该如何实现，是自己实现还是封装遗留系统提供的服务/第三方服务（映射已有/外部服务），自己实现是新建Java服务，还是流程服务（包括状态机），或是人员任务，抑或是业务规则。

从这套思想的步骤我们就可以看到，从来自于业务域（其来自于更高层的企业战略分析）识别出来的服务，到规约上的设计，以及最终的实现决策，充分的体现了，SOA方法论中更加注重从企业出发和关注点分离这两个特点。换个角度，由于当前IT技术以及计算机科学的发展，才使得我们可以如此轻松的实现从业务到IT的映射。下面就来讲一下技术标准，以及它在现实世界中是什么样子的。同时，也可以体会一下思想，理论，技术与实现是如何很好的结合起来的。

2.4   SCA/SDO规范与实现

就在我搁置对于SOA的研究有半年之久的时候，忽然打开互联网，发现SOA已经有标准了，那就是刚露头角的SCA（Service Component Architecture）和SDO（Service Data Object）。因此，在SOA有何不同的论述中，我尤其强调了SOA注重标准和规范这一事实。

SCA

SCA是一个SOA的编程模型，就好比JSP是Web开发的一个编程模型一样，Web是一种架构模式，而SOA亦然。SCA有很多部分组成，核心理念是1）将业务功能作为一系列的服务而提供，2）将这一系列的服务组装起来。SCA致力于创建服务组件，以及解决各服务组件间的多技术互访问题。SCA的核心工件是组件（Component）。⁵

如果想要问SCA与其他诸如JMS、CORBA这样的编程模型有何不同，我觉得IBM的Barcia 和Brent给了我们最好的答案：SCA 向您提供一个以与技术无关的方式定义接口、实现和引用的模型，从而使您能够将这些元素绑定到所选择的某一技术的特定实现。³

OK，当我们谈及组件或对象时，无非要涉及这么几个抽象关注点（如果你认同每个实组件或对象都要将接口与实现分离的话）：其接口是什么，实现是什么，以及其依赖了什么（依赖的组件或对象当然又包含接口和实现）。SCA则把关注点分离发挥到了极致，接口，实现，以及引用都是可选的。如图2.4-1所示。

图2.4-1 SCA组件模型

于是在SCA规范中⁵，SCA当前支持接口类型系统包括：Java interfaces和WSDL（WSDL 1.1 portTypes和 WSDL 2.0 interfaces）

而对于实现，则可以包括Java，C++，BPEL流程，Web Service以及SCA Composite。在IBM WID中可以选择实现（generating implements）为Java，Web Service，Process，State Machine，Rule，Human Task等。Process，State Machine（特定的Process）由BPEL技术支持。

当SCA模块（在SCA规范中即Composite，在IBM的产品中被称为Module）被导出（作为服务），或者需要导入其他服务时，SCA中还可以指定要访问服务使用的机制是什么。这是通过Binding实现的。由于导入、导出都是抽象概念，因此需要绑定通讯机制。

通过Binding，来指出想要调用服务和服务被调用时的访问机制，包括SCA，JCA，Web Service，JMS，无状态会话bean等。

OK，接口，实现，Binding，引用，全是独立变化，自由组合的，全面的灵活，与技术无关。前所未有，这就是SCA。

在IBM的实现版本中，可以借助WID，很方便的开发SCA程序，并且提供了很多便利的扩展。比如谈及实现问题时，IBM提供的诸如Process，State Machine之类的实现类型。

SDO

SDO是一个数据应用系统开发框架，它包括架构和API。它在SOA系统中充当抽象数据。⁶

SCA规定了怎样编写SOA程序，组件、服务、引用等都是如何定义的，以及它们之间如何通讯，而且还规定了如何传递数据，数据的类型可以有很多种，但是首选SDO。

那么SDO又是如何超越以往任何技术或规范实现技术中立、平台无关的呢？没什么令人惊奇的，做到这些无非就是增加中介和中间层次，将不同的关注点隔离。SDO客户端通过SDO框架工作在SDO数据图（Data Graph）之上。数据图中包含多个数据对象和改变摘要（Change Summary）。DMS（数据中介服务）访问数据源，即DMS负责从数据源创建数据图，并且基于对数据图的改变更新数据源。

如果想要更新SDO数据，将如何做呢？首先SDO客户端（即SDO应用）遍历数据图，修改其中的数据对象，然后将修改的数据图传回DMS，然后DMS根据修改的数据图更新数据源。

可以看出，正是由于有了数据图和数据中介服务这两个隔离，才将具体的数据源与SDO应用分离开，而由SDO框架来做出相应的转换。

IBM对SDO进行了扩展，就是所谓的BO（Business Object）。

阅读和理解规范，并且与具体的实现产品联系起来，可以更好的理解SOA思想。

BPEL

BPEL是用来编排流程服务的规范，这里的服务技术是WS*-堆栈的Web Service。BPEL规范中详细的定义了如何引入Web Service，其中包含的各种活动（诸如Invoke，IF，Scope等）以及如何建立引用。在规范中，对于引用的其他服务称为Partner，可以看出，这样的说法更贴近于业务层次。⁴

正是由于SCA、SDO这样的将抽象发挥到极致的规范，使得我们可以按照CBM、SOMA方法来设计SOA系统。我想使用一下WID来进行SOA系统的开发，将使你更容易体会我想说的内容。可见，SCA和SDO中规定的组件，服务，接口，数据对象，以及BPEL中提到的活动，与之前CBM、SOMA方法中提到的组件，业务服务，接口，数据对象，和活动，是非常吻合的，而且这是一个前后照应，完整的方法体系。

小结

写到这，似乎可以将理论和实践、规范和实现联系起来了，再强调一次，SOA的思维是从企业业务出发，甚至是企业战略出发，来考虑服务和组件，而不是从远程方法调用（RPC），消息服务，或者是分布式对象（EJB等）的角度去考虑服务。

SOA不只是EAI，这句话的另一个意思是，SOA包含EAI的部分。前文我提到了，通过BPEL和SCA Composite这样的技术，我们可以实现系统的集成，企业是流程驱动的，流程是由业务组件组成的，那么我们就可以通过BPEL将服务组合起来，或者通过SCA将服务组装起来（SCA的基本理念之一）。那么，还要ESB干嘛？ESB在哪？

2.5   ESB在哪？

ESB（Enterprise Service Bus，企业服务总线）继承了EAI的思想。我不必重复讲解Hub/Spoke和Bus这两种拓扑结构。因此，ESB的出现是为了解决集成问题。

ESB是SOA的一种实现模式，任何接入ESB的应用都将封装为服务的形式，其核心是个中介流（在IBM Websphere ESB（WESB）中是通过策略SCA/SDO实现的中介流组件），可以在其中设计消息路由，然后由其来完成消息的路由，格式、协议的转换/翻译，以及消息的分发。消息路由当然是要按照业务逻辑来设计。两个系统（包括但不限于异构系统）需要进行通讯难道不是因为业务逻辑的需要？这其中的业务逻辑就包括了业务规则和业务流程，不过也有可能就是某个业务需求，需要对两个系统进行消息转换。

可以简单的说，SCA+BPEL就可以代替ESB的存在了，BPEL可以充当中介流，只不过它更为强大（尤其是IBM将SCA作为WESB的编程模型之后，这进一步模糊了直接使用SCA和使用ESB的界限，如果说状态机是Process的一个特定实现，那么WESB就是SCA的一个特定实现了）。但是如果仅仅是想做EAI，或者尝试用SOA的方式做EAI，而不是如我前文所讲，采用一套完整的、从业务到IT的水到渠成式的SOA解决方案，则采用SCA+BPEL会面临更加复杂的学习曲线，虽然我认为它是更好的实现。

3       BPM与SOA互动

    BPM是从BPR（业务流程重组）发展而来，在大型的企业中，想要实施ERP（企业资源计划）往往都要经历一个BPR的过程，然而想要一蹴而就的BPR很难在大型企业中实现。预先看不到一点好处的改革将会受到巨大的阻挠，因此，一个更好的方式，先将企业的流程监管起来，发现流程运转中的问题，或者那些大幅度创造价值的热区，然后在对业务活动扬长避短，以提高企业的效率。那么，如果才能有效的监管流程呢？答案当然是数字化业务流程，还记得CBM方法论吗？我们需要一套从执行到控制再到战略的、互相沟通的组件。然后在组件之上设定KPI和特别事件（执行时间和成本，资源，等待时间和成本，角色/人员等）的属性。当企业正常运转时，我们就可以从现场直接搜集到第一手资料，进行企业的监控了。然后根据监控结果进行流程优化。优化后再监控，再根据新的结果优化，如此反复。

    这里就存在两个问题，一个问题是KPI如何得来；第二个问题，当发现了问题，并且找到了优化方案后，IT如何能够快速的随需而变。以下两节将解决这两个问题。

3.1   企业价值树模型

企业价值树可以帮助我们从企业战略到业务流程KPI的推导，当然，这不是数学，严谨的推导是不可能的。我们可以先从企业战略主题出发，然后由主题发现企业关键绩效指标，然后在寻找影响这些企业关键绩效指标的核心驱动流程，最终推导出流程的关键绩效指标（KPI）。

不得不说，详细完整的CBM方法论应该包括这个部分，但是这一方面大概是IBM内部的机密，因此我们只能通过引入其他的模型来解决问题。

3.2   SOA帮助企业数字化BPM

从CBM方法论我们可以看到（你可以回顾本文的相应章节），其核心的业务组件模型包括了活动、资源等，我们也提到过，业务组件是从业务流程中归纳出来的，它们是一个互动的关系。

从概览部分你可以了解到JPort团队做了哪些工作，这些工作连起来就是为了利用SOA帮助企业数字化BPM。

SOA的方法论支持BPM中需要监控业务组件的需求，因为SOA的服务是由业务组件来实现的。另外，SOA也可以满足随需应变的业务要求，就像领域驱动建模一样，基于业务建立的模型，神奇的可以随业务更好的变化。SOA的方法论可以完整的更好的以这种方式建模，就像本文始终所演示的那样。

4       结论

    采用SOA方法论一定要站在企业的角度去思考问题，具体的、可操作的方法就是CBM，更重要的是其中蕴含的思想。首先要了解企业的战略是什么，根据战略再来了解企业的业务，可以通过业务流程建模软件模拟企业流程，分析企业问题。然后俯视整个企业，设计出业务组件模型，并暴露服务。接下来在通过SOMA方法识别出所有的服务，之后再考虑服务规约，数据对象模型的设计。最后，才是决策实现的方式，复用遗留系统的功能，引入第三方服务，还是自行开发。当然并非所有的企业应用都有必要采用这样的步骤，比如只是一个新的功能，可以不妨以SOA的思想来开发这个新功能，关键是要为企业提供合理的ROI。

新的SOA编程模型SCA，与过去的众多用于SOA实现技术相结合，使得SOA的思想可以更好的实现，比如复用遗留系统，Web Service不再是不二法门，诸如无状态会话Bean，JMS之类的应用，亦可无缝的连接到SOA系统之中。SDO也增加了更多的抽象层次，其目标也更为宏大，这与JDO等目标不同。

SOA和BPM结合起来，使得SOA找到了新的务实方向，对于企业信息系统而言是大有裨益的。

当然，本文主要是从IBM，BEA，Oracle，SAP，JBoss，Sun等这些Java世界的领导者的视角来看待SOA，以它们的产品和理论为基础，然而不得不说Microsoft有其自己的一套产品和理念，但是，其根本的SOA理论是一致的：以企业为圆点，高度抽象，关注点分离，技术中立，平台无关；另外，就是其亦看中与业务流程管理的整合。毕竟，微软是BPEL的缔造者之一。

    一种务实的精神是，开发那些真正为企业创造价值的系统，如果某个业务单元本身就是低效和没有价值的，我们是不是可以考虑一下改变它的运作模式？

参考文献

1.         Deepak Alur , John Crupi , Dan Malks ，Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition)，Prentice Hall PTR

2.         Martin Fowler，Patterns of Enterprise Application Architecture，Addison-Wesley Professional

3.         Roland Barcia，Jeff Brent，使用服务组件体系结构构建 SOA 解决方案——第 1 部分http://www.ibm.com/developerworks/cn/websphere/techjournal/0510_brent/0510_brent.html

4.         Tony Andrews, Francisco Curbera,.etc,2003，Business Process Execution Language for Web Services，Version 1.1

5.         Michael Beisiegel,Henning Blohm,.etc,2007,SCA Service Component Architecture：Assembly Model Specification

6.         Bertrand Portier, Frank Budinsky,2004, Introduction to Service Data Objects:Next-generation data programming in the Java environment,http://www.ibm.com/developerworks/java/library/j-sdo/

7.         IBM商业研究院，2006，组件化业务模型：企业实现专业化的有效工具

8.         IBM Business Consulting Services, New competitive weapons in the insurance business: Insurance component business modeling, http://www-935.ibm.com/services/us/imc/pdf/g510-4033-new-competitive-weapons.pdf

9.         Anurag Goel, Enterprise Integration:EAI vs. SOA vs. ESB, http://hosteddocs.ittoolbox.com/Enterprise%20Integration%20-%20SOA%20vs%20EAI%20vs%20ESB.pdf