面向服务的体系架构（Service-oriented architecture ，SOA）已经成为软件工程中一个最重要的主题。无疑，随着Web服务的推广和广泛接受，以及支持基于SOA解决方案开发的case风格的IDE这一新浪潮的兴起，SOA已经成为构建企业级分布式应用程序的首选蓝图。与此同时，业务流程管理（business process management ，BPM）作为操作灵活的新企业并为其建模的主要支持者，正在强力反弹。基础结构厂商已经使BPM成为他们出售的系列产品的主要组件，瞄准机会的厂商使用专用的BPM系统提供垂直的业务解决方案，纯使用BPM的厂商正在得到更加广泛的接受。

　　尽管两种趋势均显露出了征兆，它们的趋同现象仍不明显，而且关于这种现象没有统一的看法。它们是互补的表示法吗？它们会重叠吗？我该如何一起使用它们？这样做有没有另外的优点？此外，为什么80年代末期的企业流程重构（BP reengineering）失败了，而第三次BPM浪潮却将要取得成功呢？

　　在这一系列三篇文章中，我将解决这些问题。首先，我将讨论一个体系架构蓝图的最佳实践如何将面向服务体系架构与BPM框架合并，从而为构建健壮的企业级集成解决方案并对其建模提供可重复的方案。我描述了为什么在当今，任何使用技术支持其任务陈述需要的企业比以往更能拥有合适的体系架构蓝图。最后，我讨论了什么是实时交易的挑战，以及BPM方法如何能够实现企业灵活性、智能企业建模、系统开发和以客户为中心的运作优点。

　　在第二篇文章中，我将应用BPM技术来为一个支持“用于汽车保险”业务场景的软件解决方案建模和设计体系架构。我将讲述两种设计：一种纯BPM设计和一种混合型设计。我还将讲述一些新兴的建模工具和标准，并讨论一些建模和各种体系架构选择和策略方面的难题。

　　在第三篇（也是最后一篇）文章中，我将使用BEA的WebLogic Platform 8.1 构建一个POC。我将讨论BEA的IDE新引入的可视化编程范型及其优缺点，和构建完全分布式的企业级应用程序所需的一些技术。我还将解释，为什么流行的请求/响应模式的WEB协议与基于事件的流程建模，以及它在进行架构决策时的意义不一致的原因。

　　体系架构模式 —— 谁需要它们?

　　软件工程是艺术还是科学？在科学中，我们有明确的定义、定理和证据。在艺术中，我们有工具和技术、趋势以及最佳实践。科学中提出了一些假设，其中一些变成定理，另外一些在经过数个世纪的研究之后得到验证，还有一些永远没有答案。在艺术中，新技术带来新的趋势，比如新闻和数字摄影。如果软件工程是一门科学，定义我们在日常业务语言中使用的所有术语不应该是一件困难的事情，像服务、Web服务、面向服务的体系架构、BPM和BPM系统（BPMS）。的确，我可以利用数学精度来证明一个数据库查询算法的正确性。但是，我能够以一种干脆、简洁且通常会被接受的方式来回答，J2EE中的B2B集成是与纯.NET Web服务解决方案相对的正确答案吗？据我了解，对于我们中间的一些人来说，这不是问题。最后，任一种常见的贸易出版物的随机调查指出，每个人都可以给出自己的定义，而有些人甚至质疑IT存在的本质。我不得不得出结论，软件工程仍然是艺术多于科学。这正好是我们需要合适的最佳实践、框架和可重复过程的原因。

　　模式封装了最佳实践，简练地定义了域问题，描述了使问题值得关注的原因，并提出了解决方案。模式并没有解决独特的问题。专业人员结合各种模式来解决更为复杂而且有时更为独特的问题。Christopher Alexander说：“模式同时也是发生在世界上的事件和告诉我们如何创建该事件的规则，以及我们必须创建它的时刻。它既是过程，也是事件。”我回想起我一直以来最喜欢的定义：对象是带有状态或数据及行为的数据结构。就目前来说，可以把Web服务看作带有一个方法的对象。就像BEA WebLogic Platform 8.1所实现的那样，会话式Web服务看起来更像是真正的对象：对它进行一次初始化，然后一直执行方法。万一您仍然不能肯定Web服务是粗粒度的对象，考虑：(1) IBM、BEA和 Microsoft宣布了WS-Eventing规范。它就像是优秀但老式的对象观察者模式。(2) 开放式网格服务体系架构（Open Grid Services Architecture）实现了网格服务协议的Web服务接口继承。因此，Web服务提供数据和行为（Alexander的定义中的事件和规则），而BPMS 实现模式的流程组件。SOA是一个用于解决企业集成和系统开发问题的体系架构模式。

　　我们已经看到，SOA不是体系架构趋势的革命，而是它经过一段时间发展的演变成果。它围绕为企业构建分布式系统而发展。诚然，Web服务以一种普遍接受且无二义性的方式提供底层技术，以解决系统连接性问题。也许是头一次，Web服务成功地解决了互操作性的问题，而这是 CORBA、COM、 DCOM和 RPC 做梦也从未想过的事情。我肯定，作为中立语言，XML对此也准备一展身手。然而，SOA中包括进来的BPMS框架是一个新的、革命性的元素。Howard Smith 和Peter Fingar 描述的第三次浪潮是指一组全新的概念、框架和主流产品。它正在显著改变企业转化的方式，从而灵活地管理和运行全局的和协作的电子商务实体。

　　业务流程管理的出现已经有一段时间，它更多地用于工业中，而与IT无关。并发工程和六西格玛被开发用来解决生产和流程改进中的及时协作问题，并且确实取得了相当的成功。然而，在80年代晚期，出于多方面的原因，业务流程重构管理获得的成功非常有限。但是最根本的原因是，重构是纸上谈兵。没有软件来支持这样一个复杂的任务。BPM在没有考虑IT系统的情况下设计了自适应的企业。正如David Taylor 所写：

　　“对连续性流程优化的需要要求从根本上重新考虑如何设计和构建信息系统。提出解决固定问题的固定解决方案已经不再够用。”

　　信息系统，像它们支持的业务模型一样，必须在本质上就是自适应的。

　　Taylor提出一种基于OO的开发技术，作为开发自适应IT的一种方法，这种技术称为聚合工程（convergent engineering）。然而，OOP无法成功解决分布式计算和企业集成的问题。另外，负责对企业建模的业务分析人员也没有采用OO。

　　BPMS将流程建立为用于建模、软件设计和运行时执行的统一结构。过去，开发趋势一直在影响我们对企业建模的方式。功能式编程使功能需求技术流行起来。关系数据库带来了RDBS分析和设计的流行。面向对象的编程则为OO分析和用例开发铺平了道路。但是在大多数情况下，业务分析人员不会使用开发专门术语，因此产生了对需求可跟踪性中通常影响的另一种翻译的需要。

　　BPM规范正在快速演变为标准。市场中已经出现了支持业务建模、优化和运行时执行的产品。正如BEA的WebLogic Platform 8.1和其他BPMS产品所实现的那样，以流程为中心的BPMS 方法用于系统开发生命周期，它消除了对运行时阻抗不匹配的业务需求。

　　灵活的企业拥有自适应的业务和自适应的IT系统。如果构建企业解决方案的过程中出现一个新的问题，那么它一定是需求变化的速度。它的速度之快是前所未有的。BPMS引擎添加了一个新的层到传统的开发堆栈（参见图1）中，并引入服务质量来解决企业集成中的根本问题。BPMS引擎使编程最易变的部分——集成点——的软布线变得容易。软布线是以正式语言显式描述的，并由BPMS引擎（又名有限状态机引擎）执行。正如BEA WebLogic Integrator和其他BPMS产品所实现的那样，业务与IT资源可以同时在一个可视化的只能IDE中查看和修改流程。只需轻击鼠标，便可部署到运行时BPMS执行引擎。业务模拟可以运行，而性能工程可以在系统完成之前完成；这种方式听起来就像CASE工具。SOA和BPMS工具将灵活企业的实时执行仪表板带向主流。

　　在本文余下的部分中，我将描述一个典型的金融服务企业的开发，并提出一条通向基于BPMS的SOA的迁移路径。该路径是增量的，但是它需要战略思考和对未来远景的承诺。作为回报，它将允许投资的早期回报，并将遗留企业转化为完全自适应的灵活企业。

　　从企业远景到组织筒仓（Silo）

　　企业从远景开始。CEO和董事会采用远景和行业使命陈述。C级管理人员定义策略，并适当地安排流程来管理执行（参见图1）。定义功能角色和责任，然后创建企业界线。业务分类（Line of business，LOB）在本质上可以是水平或垂直的（参见图2）。垂直LOB具有以下特征：

　　独立的操作域。

　　特有的管理和策略。

　　开发和维护自己的IT—自动化孤岛。

　　足够大以至于可以创建多种业务分类；例如，抵押贷款证券、市政公债、货币市场，等等

　　水平LOB具有不同的特征集合：

　　提供业务控制。

　　管理的支配和一致。

　　需要访问由垂直LOB管理的数据。
　
　　合适的手动流程和书面报告。

　　在第二个信息纪元（不要与第二次浪潮混淆）中，我们使用了各种编程技术来链接自动化孤岛，从FTP、数据库复制、EAI和消息收发开始。此方法产生了一整套新问题：

　　·  接口的多重性: 一份Morgan Stanley Dean Witter报告表明，通常的金融服务客户需要维护6000个接口，为此每年花费2500万美元，而且每年还需构建900个新的点到点接口，为此需另外花费2500万美元进行构建，并且还要花费400万美元进行维护。

　　· 调停流程: 必须在每一个仓库上实现，需要消耗有价值的时间和昂贵的资源。这是一项常用技术，用于检验由多个实体修改的引用数据。

　　·  流程: 在中间件中进行硬布线。在分析过程中捕捉流程所花费的时间和金钱属于浪费。企业最重要的资产——流程——隐藏在n(n-1)个意大利面式接口的迷宫中。

　　·  开发新的水平流程：需要多个LOB 的协调。

　　·  实现特定和专用的接口：需要专门化和一次性编程。重用消失，维护方面的投入显著增加。

　　·  异常难于跟踪： 错误解析通常需要访问多个系统。人工干预和解释是不可避免的。找寻答案需要花费大量宝贵时间，并对客户满意程度和收益性方面的大致情况有着直接影响。

　　流程无处不在。您能发现它们吗？

　　对于企业来说，流程可以是客户层面上的，也可以是内部的，或者可以是更大流程的组成部分。我们在同样的企业中可以找到内部流程。流程通常涉及到人与系统的交互，或者只是系统之间的交互（参见图3）。交易流程是大规模流程的一个很好的例子。行政管理部门的交易人员在他的销售订单系统中接收一个来自对冲基金管理人员的交易执行命令，或者他接到一份传真或一个电话。交易人员检查库存系统的安全性或资金，并借助他的交易对手执行交易。可以制造纸质入场券，而交易助手可能必须在下行系统中进入它。

　　当因为下行系统之一错误地再进入，而帮助台分析人员收到一份异常报告时，另一个内部流程启动了。然后，他在内部记事薄之一中查找数据（原始进入记录），请求来自事务部门的传真（我们假定讨论的交易超过了结算日期），而且因为他在两天内没有收到回复，也许他会再次重复同样的行为。这个流程最终当分析人员解决了问题时终止，当然，除非他调到另一个部门或者调出公司。然后，顾问们必须参与进来，跟踪问题和流程，这通常需要一大笔钱。

　　每月的客户声明是定期性企业范围内流程的一个传统例子，通常为水平LOB所特有。在大多数情况下，客户在被不同LOB支持的产品中拥有帐号，例如，股票、U.S.证券和外汇。在月末发送多个声明将会十分混乱。法律和一致性问题还需要交叉引用多个仓库的数据。Patriot和 Sarbanes-Oxley Acts (一个新的业务流程，但是不赚钱)的一个主要问题是要访问由大量LOB所拥有的数据，有时还要环绕半个世界。EAI技术和消息收发试图借助早先阐明的限制解决这些问题。

　　通向灵活性的道路：以BPM为中心的SOA

　　让我们考虑带有Web服务的、以BPM为中心的SOA如何将现有的遗留企业转换为自适应性的企业。水平流程和异常管理是用于SOA启用的理想候选者，可以演示可调整的和速度快的ROI。没有经历业务流程再造的严谨，我们必须定义良好的流程图。流程图也是实行业务流程重新设计的第一步。如果使用BPMS 设计工具(Proactivity, Intalio, Interfacing Technologies)，您可以把度量关联到流程和行为，例如，性能、开销、IT资源、FTE、逝去的时间、容量，等等。许多BPMS设计工具允许您运行模拟，并继续进行流程优化（运行what-if场景），但是这并非本文的重点。对于我们的重点来说，以下列出的是良好流程图的一些特征：

　　·  考虑流程而不是功能 : 流程告诉您完成什么工作以及如何完成。功能描述谁在哪里来完成它。

　　·  从客户的观点出发： 考虑从外部业务事件开始的流程，例如，一次交易、一份订单、一个主张、一个报价请求。

　　·  在更宽泛的意义上并基于不同的服务质量来划分客户类别： 您生态系统中的性能、供应商、业务伙伴。

　　·  流程反映状态变化：交易订单、现金支付。从可管理的流程数量6－10开始。记住，大多数人最多只能保留一个页面上的七样东西。

　　·  定义核心流程和子流程：这里没有科学理论，只有最佳实践。然而，要当心P-calculus2 和Petri-nets；它们将在接下来的10年内带给BPM科学的严密性。

　　·  将流程分解为行为

　　下一个目标是通过分解行为来定义小单元。我们将这项工作称为Elementary Business Services (EBS)。如果您从多维矢量代数开始回想，空间中的任意一点都可以被定义为单元矢量的线形组合。在我们的例子中，我们以可以通过编排EBS子集来构造任何流程的方式定义了所有EBS。正如您可能猜想的那样，我们将EBS实现为Web服务。识别EBS的正确集合和粒度水平很重要。这与设计对象的重要程度相同。相同的规则和技术——封装、状态相关性、内聚性、松散耦合和重构——同样适用，这并不使人惊奇。

　　EBS的业务量体现出了大量实际优点：

　　1. 它是要重用的最终指南。可以通过任何想像得到的方式编排EBS，以形成新的LOB。

　　2. 连续性流程改进不必等到IT适应新的业务模型。

　　3. EBS对企业生态系统中的企业和业务伙伴可用。

　　4. 放弃使用一个系统并不是一个一蹴而就的过程，而是一个循序渐进的过程。

　　5. 可以以一种易于管理且性价比高的方式合并和获得IT。

　　6. 可以几乎实时地设计和执行一个新的业务流程。

　　从图4中可以看出，我们可以使EBS在BEA WebLogic Platform 8.1（集成组件）的一个实例中可用。从技术上说，在BEA WebLogic Integration中，Web服务被称为业务流程资源。我们使用IDE编排新流程，使用门户添加UI，然后将它部署为一组EJB来执行。就是这么简单！现在流程是一项IT资产了，就像数据库表、存储过程、遗留COBOL书籍和专用的计算c库。

　　许多金融服务机构的业务分类是水平的，管理高净值的私有客户。在启用了BPMS SOA的企业中，开发IT基础结构来支持这样的新LOB完全可以与正确放置业务模型并行完成（参见图5）

　　考虑Amazon.com 现象，它们并没有创造任何新的EBS。所有EBS位于任何其他邮件订单一览表书店中的恰当位置：定购书籍，检查库存，信用卡付帐，打印声明，准备装运，给客户发送电子邮件。但是它没有创建新流程，没有质疑已经建立好的流程，甚至不用花费什么力气。

　　正如Howard Smith 和 Peter Fingar所说的那样：“在BPM的第三次浪潮中，筒仓式思考和点到点的技术集成被灵活的、基于业务流程的体系架构所代替。”此外，Gartner Group 现在声明，继续将业务逻辑硬布线到软件或中间件中或者坚持人工步骤的公司将输给部署流程管理体系架构的竞争对手。

　　实时处理业务

　　退一步说，预测将来是很困难的事情，但是我们用非常科学的态度对待它，而且始终试着这么做，不管对还是错。统计和预测是关于预测将来的两门科学。投资组合评估和保险统计研究是有关预测的科学。实际上，我们的预测仅仅基于我们已经经历过的、过去的性能和趋势。实时处理业务需要预测未来的业务情况。然而，基本的业务协议和框架必须合适。今天，技术革新、BPMS和SOA是将业务目标与IT相结合的基础。流程提供一个封装了变化的新层。90年代早期，PowerBuilder和VB风格的工具使客户端/服务器和关系数据库系统的开发流行开来，通过与此相同的方式，BPMS引擎将在未来建立流程驱动的企业。事实上我预测，在我们的一生中，我们将看到对运行时流程的需求，该类流程用于实时变化或对自修改流程的需要。无疑，人类希望能够掌管该类变化，但是通过使用UDDI-? (? 代表流程)找出最可能的服务契约和使用描述域专业知识和市场情况的规则进行决策，BMPS能够使这项工作更加容易。随着BPMS的普及，灵活性将被极端自适应所代替。

　　结束语

　　在本文中，我描绘了合并SOA和BPM的蓝图。从一幅企业的自顶向下流程图开始，我们定义了基本业务服务的组合选择。垂直LOB拥有并部署EBS。Web服务实现它们，并使它们对企业可用。通过使用BPMS引擎的一个实例，可以设计、开发、测试新的流程，并通过结合现有的EBS，在数日内添加业务值。

　　在我的下一篇文章中，我将：(1) 讲述用于给现实世界业务保险流程建模的BPM技术，并提出一个纯BPM解决方案和一个混合解决方案；(2) 使用Web服务和JMS连接设计EBS并实现它们；(3) 提出一个使用WebLogic Platform 8.1的物理基础结构；并 (4)讨论面向服务体系架构中的BPMS难题和新出现的模式。

　　直到：流程无处不在。您能发现它们吗？