dev2dev 首页 > 资源中心 > 技术文章
为WebLogic Integration 8.1对流程模式的支持评分
--WLI和BPEL在支持流程模式方面表现出色
每架飞机都可以起飞、直飞和降落，但是只有极少数可以在航展中表演侧翻和回旋。所以如果以飞行特技来判断的话，某些飞机要优于其它的。 每种BPM流程语言都可以实现基本的顺序控制流，但是大多数语言都努力支持更先进的拆分、联结、循环和同步。这些流程操作被称为模式，就像飞机在稀薄的空气中作航空表演一样，流程模式是业务流程中的一种动作，它被建模为活动的特定排列。 由擅长BPM的计算机科学家所创建的Web站点www.workflowpatterns.com是关于流程模式的资料的最初来源。该站点最杰出的两个特征就是一个包括20种模式的目录，以及对大量标准和特定于供应商的流程语言对该目录的支持的评分。最流行的流程语言，业务流程执行语言(Business Process Execution Language，BPEL)，获得了非常高的分数。根据该站点的分析，它支持20种模式中的14种。（如果您看了其他语言的得分，您就会知道，70%已经是一个比较高的等级了！）
BPEL的出色得分对WebLogic Integration (WLI)来说是一个好的兆头，后者从版本8.5开始就将采用BPEL作为它的流程语言。那么，部署在WLI 8.1上的、得到广泛安装的流程库又如何呢？它的流程语言，Java流程定义(Process Definition for Java，PD4J)，并没有在该站点上进行评分。本文就将比较BPEL与WLI 8.1的模式能力。我们将详细讨论四种模式：
- Cancel Case（取消实例），二者都支持
- Milestone（里程碑），二者都不支持
- Discriminator（鉴别器），只有WLI 8.1支持
- Interleaved Parallel Routing（交替并行路由），只有BPEL支持
本文还将给出WLI 8.1的完整得分。
Cancel Case：二者都支持
Cancel Case模式旨在停止一个运行中的流程，不管它执行到哪一步，只要取消事件发生，马上就停止（例如，取消对正在进行审查的保险索赔的处理）。大多数BPM供应商实现都提供了一个系统管理功能，以便允许管理员终止错误流程，但是该模式要求取消逻辑（可能具有重要的业务意义）必须内嵌在流程模型本身中。
对于支持Cancel Case模式的流程语言来说，它必须具有在一个有别于主线路径的路径中监听事件的能力。WLI 8.1通过允许将一个消息路径关联到流程或活动来支持该功能。例如，图1中的流程就随时准备对取消事件（Cancel Event）做出响应，而不管它的主逻辑进行到哪一步（Step 1、Step 2或Step 3）。当它收到取消事件，流程就清除（Cleanup）并退出（Finish）。
图1 WLI 8.1中的Cancel Case实现
BPEL中的实现与此类似，它允许将一个事件处理程序关联到流程或子活动上。
在清单1中，流程注册了一个事件处理程序（第2-6行），使得一收到cancelEvent就会终止流程。该处理程序可以在任一时刻中断主逻辑（第7-9行）。 清单1：BPEL中的Cancel Case实现
01 <process>
02 <eventHandlers>
03 <eventHandler name="cancelEvent" . . .>
04 <terminate/>
05 </eventHandler>
06 </eventHandlers>
07 <sequence>
08 . . . <!-- main flow -->
09 </sequence>
10 </process>
（注意：在本文中，BPEL示例是以基于XML的源代码形式给出的，而WLI 8.1是以WebLogic Workshop所采用的图形表示法给出的。BPEL没有标准的图形表示法。WLI 8.1的PD4J虽然具有XML编码功能，但是对大部分读者来说，还是Workshop的图形视图更为熟悉，看起来也更舒服。） Milestone：二者都不支持
在Milestone模式中，只有在达到一个里程碑时才可以执行一个活动，而且在里程碑过期后就不能再执行了。在不同的场景中，一个活动可以在激活事件到禁止事件之间运行任意次。例如，在拍卖中，出价人可以在从拍卖开始到拍卖结束这段时间内多次出价。很少有流程语言直接支持这种与众不同的模式。WLI 8.1中的精心设计是通过图2所示的出价流程来说明的。该流程从激活事件Open Bidding开始，之后它将一个布尔值标志设为true（在Perform节点Set Bidding Open中），表明出价过程被激活。流程的中心是一个复杂的while循环，它的条件检查布尔值标志以确定是否要继续；只要标志为true，循环就一直执行。While循环包含了一个有两条路径的事件选择（Event Choice）：一条表示出价（Bid），另一条表示禁止事件Close Bidding。如果执行Close Bidding，流程就调用Perform节点（Set Bidding Closed）来清除标志，这将在下一次迭代前中断循环。
图2 WLI 8.1中的Milestone实现
该逻辑成功地满足了要求：Bid事件可以发生任意次，直到Close Bidding事件发生。但是，该实现太过复杂，我们无法给它一个合格的等级，而它的语言又缺乏使实现更容易的特性。
BPEL对该例的实现几乎是相同的，该实现在论文“Pattern Based Analysis of BPEL4WS”（参考资料中的第五项）中有所描述，它使用了一个布尔值标志、一个while循环，以及一个“pick”（Event Choice在BPEL中的等效）来建模里程碑逻辑。
Discriminator：只有WLI 8.1支持
在Discriminator模式中，当多个并行分支汇聚于一个给定的结合点时，根据运行时估算的条件，流程中只有一个分支被允许继续；其余分支将被阻塞。Discriminator是N-of-M Join模式的特例，对于后者，M个并行分支汇聚于一个结合点，而只有前N个被放行；在Discriminator模式中，N=1。
当只需要所分派工作的一个子集时，就需要使用这种模式。例如：
- 要获得安全通关证（security clearance），申请人必须证明符合以下三个条件中的两条：有良好的信用，没有犯罪记录，自然国籍（2-of-3）。
- 一个复杂的Web搜索被提交给两个搜索引擎；只要一个搜索引擎完成搜索，其结果就会被收集起来，而另一个搜索就被忽略了（1-of-2，即Discriminator）。
有意思的是，WLI 8.1开箱即用地支持Discriminator，但是要使用更一般化的N-of-M却非常复杂。图3显示了搜索引擎的Discriminator例子。在一个并行结构的两个独立分支中，搜索被提交给两个搜索引擎（Search Engine 1和Search Engine 2）。并行结构被设置为OR联结条件（见并行结构底部循环中的并行条），以便只要有一个引擎完成，并行结构本身也就完成，控制权就被转交给下一个活动，Present Search Results。
图3 WLI 8.1中的Discriminator实现
WLI 8.1无法轻松地建模2-of-3的安全通关证例子，或其他任何的N-of-M，只要N>1。它的语言是有局限性的：并行联结条件还没有完善到可以选择两个以上的分支。BPEL也好不到哪去，它甚至缺乏可以满足Discriminator的基本OR联结功能。（BPEL有一个OR联结，但是它要等待每一个入站路径完成，而WLI 8.1联结则接受第一个入站路径并放弃其他的。）在BPEL中，实现搜索引擎例子的最容易的方法是在不同的流程中分别运行搜索（清单3），这些流程执行工作（第3行），并在完成后发布一个事件来宣告（第4行）。主流程（清单2）不同时地分出两个子流程（第2行和第3行的invoke语句），并等待第一个完成事件到达（第4行的receive）。
清单2：BPEL中的Discriminator实现
01 <process>
02 <invoke name="Submit Search Engine 1" . . . />
03 <invoke name="Submit Search Engine 2" . . . />
04 <receive name="Search Complete" . . ./>
05 <!-- got one, proceed -->
清单3：BPEL中的Discriminator子流程
01 <process>
02 <receive name="Get Search Request" . . . />
03 <!-- perform the search -->
04 <invoke name="Search Complete" . . ./>
05 </process>
安全通关证例子的BPEL实现与此类似（见清单4）：分出三个检查作为子流程（第2-5行），并等待任两个完成（第5-6行）。WLI 8.1也可以使用这种方法，或许是使用Message Broker订阅来捕捉事件。
清单4：BPEL中的N-of-M Join实现
01 <process>
02 <invoke name="Check credit" . . . />
03 <invoke name="Check criminal record" . . . />
04 <invoke name="Check natural citizen" . . . />
05 <receive name="Clearance Event" . . ./>
06 <receive name="Clearance Event" . . ./>
07 <!-- got two of three, proceed with the clearance -->
nterleaved Parallel Routing：只有BPEL支持
Interleaved Parallel Routing是一种特殊的模式，其中的多个活动以一种设计时不确定的顺序执行。活动是顺序执行的（而不是如它的名称所说的是“并行”），但是执行的顺序是任意的。Interleaved Parallel Routing是一种临时的处理，但是临时包括各种各样的特殊情况，其中并行与顺序之间没有明确的区别，而执行是由执行者决定的（例如，一个典型项目中的软件开发人员的工作，可能是开发三个组件，编写架构文档中的两段，以及为开发团队设置一个独立的测试环境）。
至于Interleaved Parallel Routing的例子，可以考虑参军申请者要进行的三项测试：牙科、内科、视力——必须一项接一项的来，但是没有固定的顺序；当申请者完成一项测试，接着要进行哪项测试要看哪个医生有空（例子见参考资料中的第6项的第10页）。
WLI 8.1实现的整体流程如图4所示，从一个具有三条独立路径的Event Choice开始：Dental、Optical和Medical。Dental事件意味着申请者被叫入进行牙科检查；申请者通过参加检查来响应（Attend Dental），然后进入内部Event Choice（如图4所示），内部Event Choice建模其他的两项检查。内科和视力的路径与牙科类似。图5显示了三个顶级选择的Event Choice扩展结构。如果第一个选择是牙科，那么接下来就在内科和视力中间选择。如果被内科叫入，申请者就参加内科检查，然后等待被视力叫入；而如果被视力叫入，申请者就参加视力检查，然后等待被内科叫入。
图4 WLI 8.1中的Interleaved Parallel Routing实现
图5 WLI 8.1中Interleaved Parallel Routing实现的扩展视图
总的来说，建模牙科、内科和视力的安排需要六条路径。如果有四项活动，那么就需要24条路径；如果是五项，就需要120条路径！替代实现应该视具体情况而定。
对比之下，BPEL有一个优良的线性解决方案（也许是碰巧得到而不是有意设计的）。其思想是，将活动置于并行结构中（清单5的第5-27行中的“flow”活动），但是强制每个活动在运行之前带一个互斥的共享变量（定义在第3行）。其结果是活动将顺序执行，但是次序不确定。该策略的关键是第6、13和20行的variableAccessSerializable标志，它实际上保证了一旦有一个局部活动（第6-12行的optical、第13-19行的dental、第20-26行的medical）访问该变量，其他的活动就被封锁直到该活动完成。
清单5：BPEL中的Interleaved Parallel Routing实现
01 <process>
02 <variables>
03 <variable name="C" . . . />
04 </variable>
05 <flow>
06 <scope name="optical" variableAccessSerializable="yes">
07 <sequence>
08 write to variable C
09 run optical activity
10 write to variable C
11 </sequence>
12 </scope>
13 <scope name="dental" variableAccessSerializable="yes">
14 <sequence>
15 write to variable C
16 run dental activity
17 write to variable C
18 </sequence>
19 </scope>
20 <scope name="medical" variableAccessSerializable="yes">
21 <sequence>
22 write to variable C
23 run medical activity
24 write to variable C
25 </sequence>
26 </scope>
27 </flow>
28 </process>
在BPEL方法中，活动的次序实际上是随机的，由BPEL引擎所专有的底层逻辑决定。该方法不适合用于次序由应用程序逻辑或外部因素决定的场景。
WLI 8.1的得分 表1提供了WLI 8.1在20种模式上的得分。沿用workflowpatterns.com上的风格，该表使用符号“+”表示语言从根本上支持给定的模式，“+-”表示语言支持使用简洁的编码应用模式，而“-”表示模式在该语言中很难实现，或者根本就无法实现。将+和+-都算上，WLI 8.1和BPEL的得分都是14。
表1 WLI 8.1的模式得分
结束语 在对著名的www.workflowpatterns.com站点所列出的20种模式的支持方面，BPEL和WLI 8.1的得分是有区别的。有一些模式是二者都支持的，有一些是都不支持的，有一些只有BPEL支持而WLI 8.1不支持，还有一些是WLI 8.1支持而BPEL不支持的。
参考资料
原文出处:Rating WebLogic Integration 8.1 on Process Patterns
http://wldj.sys-con.com/read/138267.htm
作者其它文章
|
