一个架构蓝图，第 2 部分----构建模型的理由

日期：2004年5月17日

摘要

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

作者：Labro Dimitriou

让我们也趟一趟建模这潭混水吧，描述建模的一些挑战，并提供一个业务流程建模状态概述。

在本系列中的第一篇文章（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技术推广人，包括我自己，不希望和过去的事情如<e>AＩ和工作流引擎有什么关系。（这里我使用<e>而不是传统的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内的拖放机制，并通过控制流语言和消息传送/连接点（包括<e>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实现一个解决方案，然后讨论一些仍旧存在的限制和可能的解决方案。

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

参考文献

l         Engberg, U. and Nielsen, M. (1986). "A calculus of communicating systems with label-passing." Report DAIMI PB-208, Computer Science Department, University of Aarhus, Denmark.

l         Milner, R.; Parrow, J.; and Walker, D. (1992). "A calculus of mobile processes, Parts I and II". Information and Computation, 100, 1, pp 1-77.

l         van der Aalst, W. "Classical Petri nets: The basic model." http://tmitwww.tm./staff/wvdaalst/Courses/pm/pm2classicalpn.pdf

l         ter Hofstede, A. (QUT); Kiepuszewski, B. (QUT); Barros, A. (UQ); Ommert, O.(EUT); Pijpers, T. (ATOS); et al. Workflow patterns. www.tm./it/research/patterns/

l         Booch, G.; Rumbaugh, J.; and Jacobson, I. (1999). The Unified Modeling Language User Guide. Addison-Wesley.

l         Hohpe, G. and Woolf, B. (2004). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley.

l         BPEL4WS, Business Process Execution Language for Web Services. BEA, IBM, Microsoft.

l         BPML, (2002). Business Process Modeling Language. Bpmi.org.

l         Reference Data, (2001) "The Key to Quality STP and T+1." A Tower Reuters CAPCO report.

l         Graham, I. (2000). Object-Oriented Methods: Principles and Practice. Addison-Wesley.

关于作者

Labro Dimitriou是BPMS主题专家和网格计算顾问。他在分布式计算、应用数学和运筹学研究领域已经工作超过20年了，并开发了用于贸易、工程和地球科学的商业软件。在过去的5年中，Labro一直致力于基于BPM业务解决方案的设计。(更多)

 

架构蓝图（第 3 部分）--流程带来统一

作者： Labro Dimitriou∣来源：BEA dev2dev∣原文地址∣2004-8-31

如同我们前几期中所讨论的那样，JTA样式的事务处理提供了一种将多个数据更新捆绑到一起的方法，这样一来，不管它成功与否，应用逻辑都将安全运行，即便中途存在技术性问题也是如此。

本文是系列文章中的最后一篇，文中我将把最初两篇（WLDJ，第三卷，第 4－5期）中所讨论的一些BPM技术应用到一个业务案例中去，目的是设计一个基于SOA的健壮的解决方案。特别地，我要（1）将该业务案例定义为一组高级策略，以及（2）运用业务流程优化技术获得一个高效的业务流程模型，并利用它封装实际问题。该业务模型将包括启动流程的业务事件、高级的处理线程以及这些处理线程如何分解为低级的企业级业务服务。然后，我还会讨论针对建立概念验证（POC）的各种结构化的设计选项。但是首先，我要介绍一下BEA WebLogic Workshop 8.1的新的IDE编程范式，尤其是流程集成框架如何为建立SOA Web 服务集成应用程序提供可靠的编程环境。

从数据库客户端/服务器工具到分布式应用程序集成平台

BEA新的IDE（集成开发环境)）将为设计和部署J2EE应用程序提供一个功能强大、无缝且完善的工具。如同MS Acess和PowerBuilder早在20世纪90年代用客户端/服务器模型普及了任务关键型应用程序的开发，而无需深入了解RDBMS或TCP-IP通信的专业知识一样，Workshop通过使用简单的概念如控件、事件、方法和属性来隐藏了面向对象（OO）和J2EE的复杂性，而不会牺牲应用程序的表达力和质量。可视化控件是开发人员和应用程序基础结构之间的接口层。Workshop将可视化控件转换成J2EE组件，并且，开发人员总是可以在需要时编写JAVA代码。

开发人员可以用Java Page Flow (JPF)创建复杂的基于Web的用户接口。Workshop使用Struts，它是一个用接口工具绑定数据项的Model-View-Controller结构的开放源代码实现。这就是现在所谓的MVC1结构化模式，与MVC2相反，它更类似于最初的Smalltalk模式，Smalltalk模式从业务模型中分离数据表示和用户控制。在这里值得一提的是Barracuda是MVC1的模式的另一种开放源代码实现（不是标准实现），它在简单性方面接近Visual Studio .NET IDE提供的基于事件的UI。但本文不过多涉及它们之间的比较，我会在别的时机给予对比。Web 服务连接是作为Java Web 服务（JWS）文件而建立起来的，该文件是带有简单Javadoc注解的用于访问Web服务功能的标准Java文件。开发人员只有在他希望的情况下才去关注SOAP协议、WSDL 以及XML绑定。

Java Control是WebLogic Workshop 8.1中惟一最为重要的概念。相当大部分的编程资源可以作为一个可视化的Java Control来处理。诸如一个遗流系统或是一个Web服务，一个自定义Java对象或一个EJB，一个外部的资源或者一个实现一段专有商业逻辑的工作流，一个异步或双向的消息有状态或无状态会话，都能表示为控件。开发人员通过处理事件和设置属性来和控件进行交互，也可通过编写自定义控件来扩展内置控件。

业务案例

我们虚构的但实际又很真实的汽车保险公司（Car Insurance Company ，CIC）面临着竞争压力、较低的利润以及较高的遗留系统的运行和维护成本。存在的一些问题包括：客户要求更短的决策时间；客户的保险申请表在从前台（front office）到中台（middle office）的转移过程中会出现错误放置；从遗留系统和庞大的数据仓库中获取信息仍具有一定难度；请求信用信息以及机动车辆记录也是耗费时间且难以跟踪的；最后，保险商来去匆匆使得通信需求不断变化。

考虑到这些挑战，董事会投票通过了一些新的策略：（1）允许潜在客户通过Web获得时间为60秒的响应，以此建立电子商务；（2）简化信用核查过程，充分利用机动车部（DMV）刚刚部署完毕的新的安全Web服务接口；而且（3）通过建立一个B2B合作社区，成为保险业界的领头羊。如果项目预期目标得以实现，董事会然后会决定淘汰使用一些过时的遗留系统。但是在这一阶段，董事会强烈建议最充分利用所有的遗留系统和现有的数据。

业务规则

用户访问网站，输入汽车类型、购买日期、每年行驶的里程（英里）、姓名、性别以及社会保险号。为了简单起见，汽车类型分类紧凑型（compact）、家用型（sedan）和运动型多功能车（SUV），所对应的基本保费分别是200、250和400。每年行驶的里程数产生一个里程因数（MF）：每年行驶里程如果不到8,000英里，则MF值为1；如果是在8,000 到 20,000之间，MF值就是2；如果超过了20,000，那么MF值就是3。性别和年龄也产生一个性别年龄因数（SAF）：对于二十四岁以下的男性，SAF值是4，二十五岁以下的女性，SAF值是3，二十四岁以上的男性和二十四岁到三十四岁之间的女性，SAF的值是2，三十四岁以上的女性，SAF值是1。保险公司使用DMV最新级别的安全Web服务来抽取驾驶员的记录，使用基于多年收集的数据的专有方法，一个遗留的后台应用程序对DMV进行评分并产生驾驶员历史因数（driver profile factor， DPF），DPF是一个介于1和4的数字。最后的保费的计算方法是，基础保费＋加权因数*50，其中加权因数（WF）＝(3*MF+4*SAF+4*DPF)/10。

如果加权因数WF小于20，代理商可以生成一个报价并返回给用户，否则，需要发送用户对报价的请求以承保。如果可能，保险商希望使用相同的方法来计算保费。然后用户可以决定是否要申请该保险项目，在这种情况下用户只需提交支付信息等。其余的过程就不在POC的范围之内了。

很明显所有的这些规则都是不稳定的而且会经常变化和调整。它们中的大部分在不同复杂程度的多种系统中都得到了实现，从电子表格到COBOL工作簿。报价请求的完成也需要人为的干预和协调。

开发业务模型

这时应考虑流程而不是功能。一个流程以一个预定义业务事件开始，并且是一个企业所做（而不是如何来做）的一系列工作，目标是产生与管理层和企业宗旨中设定的企业策略和企业远景规划相一致的结果。一个事件可以触发一个或多个处理线程，并且可以位于企业的内部或外部。赚钱事件通常是外部的，且在某些方式上与供应链相关联。事件可以是实际的或暂时的。结果可在防火墙的内部或外部感觉到，而防火墙是虚构的企业保护屏障。一个好的一致的命名规则始终很重要：一个动词加上一个业务流程对象，即Get DMV records 和 Calculate Premiums；一个行动者加上一个动词再加上一个实际事件的对象，即Customer Requests Quote；和一个临时事件的“时间快照”定义，即Sixty Second Response 或 9:00 AM Consolidation。

很明显，BPM设计和开发方法的优点之一在于可视化工作流方面。然而，WebLogic Workshop 没有开发“泳道”类型图表的工具。处理设计阶段不得不在纸上进行，或者使用类似Visio的绘图工具或带有设计功能的BPM工具。后一种方法会带来两个大的问题：

1.         导入/导出流程的负担。

2.         更改时的可跟踪性问题。Workshop 在其IDE的设计区内甚至不允许同时查看两个或更多个流程。这样一个简单的解决方案使得交互式设计会话更容易。

在本文中，对于两级流程分解的第一级，我使用了OpenOffice 绘图包。随着流程的逐步深入并接近企业业务服务（Enterprise Business Services， EBS），我将开始在Workshop Studio中进行设计。我能够在一个方框中将活动集合起来，并用描述性的名称对其进行命名，也可随意折叠。第一步是开发一个高级流程图（见图1），其中含有启动业务事件的行动者或参与者，以及对子流程和活动的粗粒度分解。本图表很有用。它是一个基线通信，并用作“稻草人”； 然而，它也有一个弱点。它遗漏了这么一个事实，即双方之间的流程有两个视图。流程正如含有内部和私有实现以及一个外部公共接口的对象。当然，这是全部相关并取决于您位于流程的哪一端。在本例下，是按照CIC的观点分类的。图2含有分布在“泳道”中的流程。从左至右共有5个流程： 请求报价公共流程、请求报价私有流程、处理报价私有流程、承保私有流程以及承保公共流程。

图1

设计决策和架构选择

现在，您可能会认为已经很好地理解了UI的构建并认为这只是一个简单的问题。不妨再想一下。选项之多就如同问题的类型一样，而且每个选项都有其自己所面临的挑战。目前，我将讨论两个问题：事件通信和建立widget。

图2

事件通信
 

用户事件要么需要启动一个进程并与之交互，要么附加到一个长时间运行的监控进程。作为响应，该进程产生一个专为某特定的客户提供服务的进程线程的实例，有点像一个TCP/IP服务器在监听一个端口，当有客户发出请求时生成一个新的进程线程，并通过一个专用套接字简化与新客户的交互。但是用一个请求和应答协议如何做到这一点呢？答案是不能，至少是不能用普通的和有效的方式实现。

作为受业务流程驱动的企业核心的业务事件和Web是不一致的。在这里不足为奇，http从来不被认为是一个成熟编程范式的替代品，而只是一个用于信息、图片、文本等交换的纯粹的协议。那么现在如何呢？在无状态交互情况下不存在实际的问题。Web 服务可以封装和简化同步通信。在本质上是异步的有状态交互会话式Web服务情况下，它们可以在多用户呼入过程中保持状态。编程人员为会话式的Web 服务增加了回调功能。Web服务完成其服务后，客户端代码中的回调信号被激活。这是一个很棒的决不拖泥带水的解决方案；然而，有些客户端并不能含有回调。例如，使用http的Web页面交互不能安装回调。所以我们回到了起点，这就是大约30年前的轮询。是的，轮询。Web服务必须实现如areYouDoneYet ()的一个方法，返一个布尔值true或false。当服务完成后，将一个状态变量从false更新为true。客户代码将一直轮询或执行areYouDoneYet ()方法，直到返回值为true。然后客户可以调用Web服务的getResults ()方法得到结果。

构建Widget

乍一看，JPF类似于流程流，但除了文字处理外二者没有任何的共同之处。JPF管理http页面之间的导航。Workshop 提供建立复杂UI的widget丰富的环境。特别强大的是Form Beans的使用，它管理表单数据的绑定、存储和有效性验证。JPF 通过会话式的Web服务与系统其他部分进行通信。Web服务使用了一个流程控件来执行报价流程这一私有流程。由于 JPF 不能含有回调机制，所以Web 服务采用了上述的轮询技术。此外，Web服务嵌入了60秒的计时器来监控来自系统其他部分的响应信号（见图3）。

图3

Worklist 客户端 API

BEA WebLogic Integrator 提供了一个供应用程序和流程容器交互的编程接口。作为流程的一部分，一个活动可能需要人为交互。Worklist 是一个简单的基于HTTP的测试工具，它支持人为交互。它是一个工作队列。很明显，更好的设计是定义您自己的客户端接口并使用Worklist Client API链接到流程引擎，但是建立这样一个接口的细节超出了本文所讨论的范围。Worklist 提供了一个测试保险流程有效性的简单方案。Gregor Hohpe 和 Bobby Woolf 在Enterprise Integration Patterns 中用了一章的篇幅描述了一个Loan Broker例子，非常类似于Underwriters B2B 生态系统的概念。它们特别描述了三种不同的模型：Fixed addressing、Distribution和Auction。使用Web服务、一组URL和消息通道的组合，可以建立一个完全可扩展的解决方案。

BPM 作为编程工具

在我以前的文章中，我曾经说过，大多数的流程引擎都是作为一种状态机（state machine）来实现的，同时Petri网已走向Turing完善。然后您可以证明用任何语言编写的任何程序也都可以在BPM中实现。很明显，某些语言在解决某些特定问题方面会优于另外一些语言。在实现集成层或问题的不稳定和快速变化方面，BPM语言是自然的选择。

业务规则成为BPM实现的一个理想的候选。为了在此处说明清楚，我并不是指具有推理机（inference engine）等的人工智能专家系统意义上的业务规则。我指的是上述有关因数计算和保费意义上的业务规则。然而，我必须承认使用BPM工作流创建一个泛化的专家shell将是一个十分有趣的练习。为了说明这一点，我已经将我们的商业规则实现为一个流程： computeFactors。我为三个不同的因数实现了一个平行的拆分。实际上，平行分支在逻辑上是并行的。WebLogic Server对分支的执行进行了串行化。当网格计算和高性能计算普及时，真正的并行化可能只是附加的选项。目前，只有通过如Powerllel等专业公司的支持网格计算（grid-enabling）的软件或Platform和Sun的Distributed Resource Manager (DRM)系统来使用这样的选项。第三分支执行可返回DMV因数的DMV Web服务。过程是：假设该Web服务已在Internet上提供，我将浏览器指向它并将WSDL文件下载我的本地磁盘上。然后，在 Workshop 中我浏览到该WSDL位置，右键单击，并选择Generate JCX from WSDL。得到的JCX 文件是一个Web服务控件，现在可以将该控件绑定到一个流程项。

结束语

WebLogic Platform 为基于SOA方案的部署提供了健壮的产品架构。它提供了一个可实现企业级分布式方案的开发、部署和操作的高效环境。可视化范式很好地隐藏了J2EE和面向对象的复杂性。我发现，将几乎所有的可用资源变成一个控件（一个带有一致接口的计算组件），就是其最强大的功能。控件以一种非常一致且可重复的方式利用了对象重用的功能，并使解决方案可根据不断变化着的灵活企业进行轻松扩展。

流程是统一的构造，可用于所有的开发阶段。流程为通往建模的“巴别塔”驾起了一座桥梁。业务和技术现在可以用相同的语言。在宏观层面上，流程是实现集成任务的自然之选。在微观层面上，流程是实现解决方案的易变方面（如业务规则）的理想之地。实际上，BPM是头等“计算公民”。

WebLogic Platform实现了一个综合的BPM环境。然而，BEA并没有提供BPM方案的一个关键组件：一个纯粹的业务流程设计和建模环境。同样地，很少业务分析师是对象建模人员，很少业务分析师会熟悉BEA的业务集成环境。但是鉴于建模领域内部所发生的一系列大的事件如Rational Rose 和 TogetherSoft 的收购、Microsoft 对UML建模再次感兴趣以及专注 BPM竞争对手不断的成功，BEA正在致力于BPM for Business Analysts 的无所不包的下一个版本，它将可能和UML兼容！

最后，面向服务的架构已经成为现代分布式系统的通用结构。普遍采用Web 服务作为连接技术极大地促进了协作。很明显本领域还将有更大的发展。毕竟，问题积累的速度快于我们解答问题的速度。一些问题涉及到关键领域如安全和连网。Paul A. Watson 在其最近的一篇文章“Slipping In The Window: TCP Reset Attacks”中对作为我们技术基础的TCP/IP 提出了置疑。如果有任何的疑问，我们对垃圾邮件的战争就宣告失败，至少现在是这样。我们可以静止不动；我们从来没有那样过。IT商品化的时代还没有到来。我预言在未来的2到3年中，能够解决这些问题的新技术和技术革新将催生出下一代的分布式系统，它将有更加成熟的、动态的和适应性强的架构范式。

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