让我们也趟一趟建模这潭混水吧，描述建模的一些挑战，并提供一个业务流程建模状态概述。在本系列中的第一篇文章（WLDJ，第3卷，第4期）中，我论述了架构蓝图的重要性，同时也详述了为构建健壮的、企业级集成解决方案而创建可重复方法的最佳实践，目的是服务于那些能够适应和灵活的企业。

　　在本系列中的第一篇文章（WLDJ，第3卷，第4期）中，我论述了架构蓝图的重要性，同时也详述了为构建健壮的、企业级集成解决方案而创建可复用方法的最佳实践，目的是服务于那些能够适应和灵活的企业。在高度分布和时刻变化的业务生态系统中，作为连接性的支柱，我认为该服务是将SOA和BPMS与Web服务合并起来的统一结构。在业务流程和BPMS是一个进化性的新技术革新（计算中的头等公民）的分布式计算中，SOA是一个进化性的步骤。最后我用基本业务服务（EBS）的概念结束，EBS是通过企业信息总线（另外一个时代错误的和重载的术语）可用于企业的小的工作单元。EBS组合提供企业级重用的最终指南。通过将现有的EBS、新业务事件以及人力资源与自适应公司目标相结合，新的业务流程正在接近实时的情况下出现。

　　在本文中，我介绍了新出现的业务流程设计模式，这些模式提供可应对长期的、企业级业务挑战的以BPM为中心的架构解决方案。在描述了模型的外观之后，我们将业务流程分解成已知组件并试图理解伴随而来的设计挑战。最后，我将提供一个业务－流程设计模式的建议分类法。

　　与此同时，虚构的汽车保险代理机构（其业务流程是获取汽车保险报价，这正是我要建模的）的董事会要求我在提出解决方案之前等待一段时间。他们正在经历业务流程的重新设计阶段并准备通过一项新的政策。该政策规定所有的报价都要由外部保险商提供。保险商通过虚拟的协作式B2B交易获利。此外，作为流程的一部分，他们通过安全的Web服务进行信誉报告检查的谈判。因此，不管我在第一篇文章中许诺了什么，且为了完整性，我将不得不推迟到下一篇文章中进行本讨论。

　　建模的问题

　　Booch et al告诉我们“模型是现实的简化”和“最好的模型是和现实相联系的”；但是我们要对谁的现实进行建模呢？而且，我们使用哪种建模范例或者说框架来对建模框架进行建模呢？以及为什么我们需要模型？模型可能会比较恐怖，因为它会使您忘掉现实。考虑以下类比：业务领域（business domains）好比是梦，而模型就是您对梦的阐释。不久您会只记住了梦的阐释而忘却了梦。为此，我的目标不是去详尽的解释所有这些问题，即使我有这个能力。这里只是阐明基本的概念，并简要描述涉及以下几个方面的且为人们所普遍接受的观念和挑战，（1）用流程－业务流程对业务生态系统进行建模；（2）使用对业务流程进行建模的建模框架；（3）选择一种语言/语法来表示建模框架；和（4）选择一个图形符号来可视化呈现业务流程。

　　业务流程可很好地对协作式业务生态系统进行建模，且BPMS框架可成功的消除业务和IT之间的阻抗失配问题。但是我们应该使用谁的建模标准呢？BPML的出现和使用已有一段时间了，但看上去BPEL4WS是赢家。很明显，两个标准都使用XML作为实现之选择。另一方面，UML阵营也没有停滞不前。UML序列图表用于建模已经足够好了吗？关于OMG的模型驱动架构，而不和特征驱动架构或域驱动设计相混淆的乱哄哄的是什么？当然，更不用提众多的其他标准了，如XPDL、ebXML、XLANG、WSCL、WSFL和许多其他正在研制过程中的标准，如YAWL（yet another workflow language）。现在是打破公共谬误的好时间了：与流行的看法相反，工作流和流程确实有非常相似的方面。在工作流软件公司劫用了术语“工作流”来表示文档流和工作分配之前更是如此，BPM技术推广人，包括我自己，不希望和过去的事情如AＩ和工作流引擎有什么关系。（这里我使用而不是传统的E来表示防火墙之外和整个业务生态系统的AI。）很明显，图形化、控制流表示和图形理论是工作流和类似流程的公共方面。所以从现在开始，我将交替使用工作流和流程这两个术语。

　　业务－流程模型并不封装特定业务领域的知识，但却有定义业务内容的表达力。另一方面，业务内容的不透明对业务协议有着不确定性的影响，使得异常处理和补偿交易（compensating transactions）更具挑战性。

　　流程建模所采用的两个主要的数学/建模理论是：（1）Petri网，和（2）π-微积分（π-calculus）或差分和补充概念分别是状态图表、时间随机网络和环境微积分。

　　Petri网是由C.A.Petri在20世纪60年代早期提出来的，作为对分布式系统进行建模的数学工具，特别用于并发、不确定论、通信和同步的概念。π－微积分（π－calculus）是由Milner、Parrow和Walker所定义，作为“移动流程的微积分（Calculus of Mobile Processes）”。基于Petri 网语言的性能优于基于状态的工作流，但是在对多个并发流程和复杂同步需求进行建模时，它却有一定的困难并可能提高复杂程度。

　　
　　图１

　　简单来说，曲线图含有与边缘线相连的节点。Petri网是一种带有节点的曲线图，节点是位置（圆形）或转换（矩形）和令牌。不同类型的节点通过弧线连接在一起。弧线有两种：输入和输出。一个位置可拥有一个或多个令牌。流程的状态是由位置和令牌建模的，而状态转换是由转换建模的。图1图示了作为Petri网的B2C和B2B的交互，一客户分别从一个代理和保险商流程请求保险报价。私有流程从本质上说独立运行，但是必须通过共享点进行同步。Wil van der Aalst教授的论文用了若干个很好的示例对Petri网进行了简单的介绍，并提供了一个applet来设计您自己的Petri网。

　　π－微积分对通过网络拓扑可动态改变的通道所进行并发流程通信进行建模。节点是流程，边缘线是命名通道。流程可以通过通道交换名称，且除了通道名称外没有其他值。例如，符号x(y).P 表示流程P通过通道x接收一个值y。P1|P2表明P1和P2是两个并发流程。最后，（y）表示通过一个通道a发送一个名称y。例如，某用户通过一个保险Web站点请求报价的情况可能是这样的：

　　webChannel(sendData).RequestQuote | webChannel (getData).ProcessQuote,

　　其中RequestQuote和PeocessQuote是两个并行运行的流程。

　　您可能会问，为什么要用这些形式主义使事情更加复杂化呢？因为不这样的话，它等于不用双帐簿入帐技术和普通的分类总帐进行账目管理，并希望最后的总和为0。基本的流程几何帮助我们（BPM引擎和下一代业务活动监视器）来找到死锁和竞态条件、将流程简化为更简单的，并找到最佳路径、更好的机遇（基于业务规则）和回答其他感兴趣的问题。BPMS的视野远远超过了流程的简单执行。正是由于BPMS的形式主义，才使我们现在有一个该运行时企业的直接实时API并实现执行的天堂。

　　至于图形符号，业务流程建模符号（BPMN）是学术界之外所不得不使用的惟一符号。当有人在谈论着要在BPEL4WS顶部实现BPMN时，一些提供商已经宣布了愿意遵从，包括Popkin Software（一个软件分析工具提供商）和Intalio（一个专业BPM工具）。基于WebLogic Server（事实上的应用服务器行业标准）的WebLogic Platform 8.1自带的集成开发环境（IDE）用于设计和部署分布式应用程序。该IDE使用了一些强大的和直观的结构来推动业务－流程的设计和开发。可视化范例成功地隐藏了面向对象编程、J2EE、J2EE CA、JMS和WS-WSDL的苛刻要求。而其他大多数供应商使用典型的类似Visio的工作流或者面向对象的UML符号。

　　分解业务流程

　　图2

　　业务流程管理方法实际上是一个自上而下的方法。起始于顶端，流程的宽度整合了灵活企业内部的所有知识领域：业务情报、主题专业知识交互（UI和其他）、位置和组织边界、遗留应用程序、集成点以及数据需求。随着我们增加流程的深度，我们要识别子流程（一些位于一组业务边界的内部的流程），直到单个业务规则的微观级别。这个分层的自上而下的方法使BPMS成为正在消失的遗留产品的理想工具。企业级流程可以触发并执行子流程，依此类推。很明显这个自上而下的方法推动着递增式改变而不是“宇宙大爆炸式”。

　　Gregor Hohpe 和 Bobby Woolf（见 Enterprise Integration Patterns）的结论是：

　　业务流程组件将一系列的服务结合到一个逻辑单元，该单元和其他这样单元通过消息传送以实现高度的可伸缩、高弹性的逻辑和数据流。流程、对象和交互模式到业务流程组件的合并是将来的事情。

　　图2提供了一个业务流程的分层视图以及每层所涉及的相关设计模式。启动一个业务流程始于参与者、真人（该组织的内部或外部的人员）或者一个系统所触发的业务事件。一个业务流程含有动态和静态部分。

　　动态部分设计使用一个IDE内的拖放机制，并通过控制流语言和消息传送/连接点（包括AL、遗留适配器和Web服务）来封装。该控制流软件具有发散性，这使领域专家和设计建模人员只需单击一个按钮，就可以对其进行更改和部署。消息是使用抽象和具体类实现的。具体类将依赖于协议的实现细节从控制流中隐藏了起来。

　　静态层含有通常的几个方面：业务服务、业务逻辑和数据。业务流程中的数据有两个位置：在协议消息和业务内容的交换中，和持久存储堆栈和其他业务－流程元数据存储库的底部。为限制任何的RDBMS建模观念，我想起了Graham的来自面向对象方法（Object-Oriented Methods）: 原理和实践（Principles and Practice）的数据视图：“我坚信在受过传统关系型数据库系统教育的或者有这方面经验的一些人员的手中，数据驱动方法是危险的”。

　　BPEL4WS只是根据Web服务论述了消息传送。与之相反，BEA的WebLogic Platform 8.1巧妙地使任何可想像的实体作为一个控件进行封装，并暴露出可用作连接点的方法调用。通过自省，它甚至可以暴露出内部方法作为“直接”连接点。在下一篇文章中我将讨论控件的更多功能。

　　业务流程设计模式

　　很明显，业务流程的动态层创建了业务流程模式的基础：将工作流和Web服务/消息传送模式的结合。此外，作为OEM的一个新的品种，特定业务垂直的主题专业知识和技术的合并，启动了高度可配置可执行业务流程的组合和库的延伸，我们将见证政策模式或最佳实践业务流程的出现。

　　它们也将解决立法问题，如爱国法案（Patriot Act）和Sarbanes-Oxley、解释最佳实践、复杂的和充满政治色彩的组织间引用数据问题、风险管理、数据缓冲策略和网格计算的SLA。

　　考虑一下引用数据问题：一份Tower引用数据报告告诉我们（1）组织每年花费320万美元于数据引用；（2）有48%的受访组织透露引用数据包含在超过10个系统中，8%的受访组织说引用数据包含在令人惊讶的150个或更多的系统中；（3）劣质引用数据导致30%的业务失败；和（4）同样的Tower报告透露人工输入和有错误倾向的人工维护仍然是一个普遍的实践。我还需要继续说吗？您已经明白是什么意思了。传统的EAI技术、数据复制以及企业级数据标准化的幼稚观念不仅限制了成功，而且实际上将问题放大了，因为它会在整个企业范围内复制坏了的、不可靠的和冲突的数据。

　　但是基于BPMS的解决方案是如何可以解决这么大的一个问题呢？完整的答案和策略方法可以占满BPM实践指南的一章或两章，或者是一个额度为百万级的项目。不用给出大多的细节，这里给出该方法的一些描述：对一块具有与之相关联的许多属性引用数据进行可视化，比如一个大约为600的数量级。暗含的假定是企业内部的不同组织对不同的属性段或簇具有第一写作权；因此，按照主要的LOB用户所有者将属性分为主要的簇，比如6个域，每一个含有大约100个属性。最后，对每一个域而言，设计和实现流程可管理每个属性子集的生命周期，并包含该簇的生命周期和批准的政策（见图３）。

　　图３

　　换句话说，拿部门所有权、过程以及策略并在BPMS中实现之。这就是所有的BPM，对吗？可执行进程。该问题的核心现在是一个成功解决方案的关键。最后但并非最不重要的，您已经解决了另一个和企业集成有关的具有挑战性的问题：公司治理和技术解决方案的所有权。

　　学术团体已经开发出了一组20个基本模式来准确定义所有主要的工作流模式。然后工作流可以依据已建立的模式进行测定。这些被分为6个主要种类：（1）基本控制流模式，（2）结构化模式，（3）基于状态的模式，（4）高级分支和同步模式，（5）取消模式，和（6）多实例模式。

　　1. 基本控制流模式是（a）顺序，（b）并行分支，（c）同步，（d）互斥选择，和（e）简单合并。

　　2. 结构化模式是（a）任意循环和（b）隐式中止。

　　3. 基于状态的模式是（a）延期选择（b）交叉存取并行路由选择，和（c）里程碑。

　　4. 高级分支模式是（a）多重选择，（b）同步合并，（c）多重合并，和（d）识别器。

　　5. 取消模式是（a）取消活动和（b）取消案例。

　　6. 多实例模式是（a）不带同步的多实例，（b）具有先验设计时知识的多实例，（c）具有先验运行时知识的多实例，（e）不带先验设计时知识的多实例。

　　Eiendhoven 大学的Wil van der Aalst通过一个示例流程详细描述了以上的一些模式。

　　模式3的（b）、模式5的（a）和（b）以及所有的模式6都需要消息传送和Web服务模式。这些模式可以分为以下类别：服务访问和配置模式包括包装器外观、组件配置器以及截取器。事件处理模式，包括反应器、前摄器和接受器－连接器以及并发模式，包括活动对象、监控对象以及领导者/追随者架构模式。Douglas Schmidt等在Pattern-oriented Software Architecture (第2卷): Patterns for Concurrent and Networked Objects 一文中对以上模式进行了很好的描述。Martin Fowler等的Addison Wesley Signature Series 也是连接性模式的另外一个好的来源。

　　BEA WebLogic Platform 8.1 去除了低级实现的需求。然而，必须认识到由于BPM实际上是凭借自身的实力成为一个编程范例的，制作意大利面条流程的前景和充满GoTo的基本意大利面条一样真实。合适的设计是我们强烈推荐的。

　　结束语

　　在本文中，我描述了建模背后的推理、对模型进行建模的必要性以及BPM标准前沿的当前状态。我描述了BPMS如何提供一个自上而下的递增式的方法以统一企业内部所有的知识领域，并介绍了用于解决企业引用数据难题的一个高级最佳实践方法。最后，我对工作流和连接模式进行了总结。

　　在本系列的最后一篇文章中，我将描述获取保险报价业务案例并介绍BMP建模选项。然后我将使用本文介绍的一些工作流和连接性模式用BEA的WebLogic Platform 8.1实现一个解决方案，然后讨论一些仍旧存在的限制和可能的解决方案。

　　届时：流程无处不在。您能看到它们吗？