如同我们前几期中所讨论的那样，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年中，能够解决这些问题的新技术和技术革新将催生出下一代的分布式系统，它将有更加成熟的、动态的和适应性强的架构范式。