构建业务流程

1、构建业务流程，第2部分-WebLogic Integration 开发最佳实践文章工具推荐给朋友-打印文章时间：2004-12-22作者：Vijay Mandava, Anbarasu Krishnaswamy浏览次数：酸本文关键字：本文是在BEA WebLogic Integration 8.1上构建业务流程的最佳实践中的第二篇。第一部分 (WLDJ，第3卷，第6期)关注于团队开发和维护的最佳实践。在本文中，我们着重于创建具 有可伸缩性、可恢复性、异常处理、有保证的传送以及高性能的业务流程的最佳实践。本文适用于 WLI应用程序的开发人员和设计人员。阅读本文的第一部分流程的版本控制最佳实践指定

2、流程文件的版本。原因很容易忽视版本控制，原因是流程无需任何版本就可以工作。但是对流程进行版本控制确实很 重要的，特别是对于那些长期运行的流程而言。升级一个流程时，如果流程没有指定版本，那么未 决(in-flight)实例要么终止，要么部署失败，这依赖于服务器的运行模式。如果服务器运行在迭代 (iterative)模式，则流程中止，如果服务器运行在生产(production)模式，则部署失败。细节利用WebLogic Workshop的版本控制功能，您可以对业务流程进行更改，而无需中断任何当 前正在运行的流程实例。当您指定一个业务流程的版本时，您就创建了一个业务流程的子版本，该 流程共享相同的公

3、共URI (接口)作为其父流程。在运行时，被标记为活动的流程版本是那些被外 部客户端通过公共URI所访问的流程。您可以为业务流程指定版本，但不能为与该流程相关联的单独控件或者其他与业务流程相关的 组件(例如schema和转换)指定版本。当您指定一个业务流程的版本时，您也必须指定该流程 的子流程的版本，指定父流程的版本后，子流程的版本并不能被自动指定。所调用子流程的版本取 决于它所采用的版本策略。两个可用的策略分别是松散藕合（调用时确定版本）和紧密藕合（调用 父流程时设置版本）。这里要重点指出的是，版本之间的不同并不是彻头彻尾的，原因是所有的版本都是同一个接口 的不同实现。这也就意味着，不同版本

4、可以有相同的请求、回调方法（callback methods）以及静 态消息代理订阅（static message broker subscriptions）。异常处理最佳实践为流程创建相应的异常处理。为所有流程创建全局异常处理。原因在业务流程的任何阶段出现已检查的或者未经检查的异常是很自然的事情。应当在业务流程中 对异常进行适当的处理。如果异常没有被显式地处理，那么该流程就可能中止且永远不会重试。这 也可能导致消息未被处理或者消息丢失。细节可以在三个级别上创建异常处理：全局异常处理针对一组节点针对单个节点一般来说，异常会向上传播，从节点异常路径到组异常路径，再到全局异常路径，直到它被处 理为

5、止。换句话说，与节点相关的异常路径会首先执行，然后是与组相关的路径，再后是与起始节 点相关的路径（全局路径）。异常只会被处理一次，除非您的异常处理路径抛出一个异常；然后异 常会再次按照相同的顺序向上传播。对您的业务流程，您可以利用这种特性并创建满足特定异常处 理需要的异常路径逻辑。对于非事务性资源而言，可以在异常处理中进行补偿事务处理。恢复最佳实践在流程级和/或JMS队列级设置适当的redelivery属性。原因在流程中出现异常的地方，事务会回滚，同时流程可能会中止。如果没有设置合适的redelivery 属性，那么用来启动流程的消息将被移到错误队列。移入错误队列的消息将不会被业务流程再次进

6、行处理。相反，一个内部消息驱动bean将会读取该消息并调用该业务流程的全局异常处理。避免发生这种情况的一个推荐的方法是为retry count和retry delay都设置较高的值。细节流程级的属性是：Retry count:指定在第一次尝试执行业务流程失败后流程引擎应该试图执行该业务流程的次 数。Retry delay:指定两次重试之间的时间间隔(以秒为单位)。确保重试次数和重试间隔合适。重试次数和重试间隔的乘积应该超过运行JTA恢复的时间。如果需要调整重试次数和重试间隔，您可有以下的选择：在您的 JPD 中认真设置 retry count 和 retry interval为每个 JPD 工

7、程(WebApp)的 async 和错误队列(error queues)设置 retry count 和 retryinterval o注意这将会中断JPD上显式retry设置，但它是最容易的，也是推荐使用的方法。消息代理通道最佳实践最好使用JMS header值，而不是使用文档号。原因使用header值的速度远远快于使用一个文档元素，因为前者无需进行解析。细节消息代理通道和Java Message Service (JMS)主题有相似的属性，但它经过了优化，以便和 WebLogic Integration流程、控件和事件生成器(event generator)一起使用。我们推荐创建多个 通道

8、(channel)，而不是让多个JPD用订阅筛选器(subscribtion filter)来监听单个通道。最佳实践创建业务流程来使用失效通道(dead letter channel)中的消息。原因如果该通道没有订阅者，或者由于筛选条件不满足而导致已注册的订阅者不匹配，那么该消息 被置入失效通道。如果该失效通道没有订阅者，置于该通道上的消息就会因被丢弃而丢失。细节当一个消息被发布到一个通道，同时未找到匹配的订阅者，则该消息会被重新发布到一个和该 通道类型相对应的失效通道。WebLogic Integration提供了如下的失效通道：/deadletter/xml/deadletter/stri

9、ng/deadletter/rawData例如，一条发布到一个XML通道(即消息类型Type = xml的通道)的非匹配消息被发送 到/ deadletter/xml通道。在设计时，当您创建MB Publish和MB Subscription控件时失效通道 是可用的。您的业务流程可以发布和订阅该失效通道。例如，当设计错误处理时您可以使用失效通 道一您可以创建这样一个业务流程，它包含对失效通道的静态订阅和处理已发布到这些通道上的非 匹配消息的设计错误处理代码。WebLogic Integration Administration Console 中的 Message Broker 模块可让您对应

10、用程序中的 所有Message Broker通道，包括失效通道进行监管。BP事务边界最佳实践在进行流程设计的同时要记住事务边界(transaction boundaries)。原因流程中存在隐式的事务边界，它们将影响业务的行为。如果对其视而不见，它将导致无法预期 的结果。添加事务性边界将会为流程定义引入一个抑止点(quiescent point)。细节在WebLogic Integration中，流程在本质上是面向事务的。流程每步的执行都是在JTA事务 的环境中进行的。事务确保了一个或者更多的操作将作为一个工作的最小单位来执行。如果事务处 理中的某个操作失败的话，那么所有的操作都将回滚，于是应

11、用程序返回到其先前的状态。对业务 流程逻辑的设计决定了该流程是有状态的还是无状态的，于是也决定了给定流程环境中存在一个或 者多个事务处理。当您创建一个流程的时候，根据流程中放置基本构成元素(例如，control receive或者client receive)的位置而形成了隐式事务边界。在您添加流程节点的同时，流程中的事务边界会随着更改。 您也可以创建显式的事务边界，方法是选取相邻的节点并在一个与那些应用程序隐式创建的事务所 分开的事务中进行声明。流程所访问的资源也可以是事务处理的一部分，这取决于资源的本质和提 供该访问的控件。可引入隐式事务边界的一些节点是：Event choiceParal

12、lel nodesControl receives无状态流程最佳实践最好用无状态流程，而不是有状态流程。原因有状态流程是作为实体bean而实现的，当存在抑止点时它们将被持久存储在数据库中。细节无状态流程是只在内存中执行的流程，并且不会在数据库中永久存储其状态。从技术上讲，它 被编译成一个无状态会话beano无状态流程所支持的业务情况涉及到短期运行的逻辑且有较高的性能需求。由于它不在数据库 中持久存储其状态，所以它对较低的延迟时间、较高的性能执行进行了优化。这里举一个示例，一 个无状态流程异步接收来自客户端的消息，对消息进行转换，然后利用一个控件按照异步或者同步 模式将其发送给一个资源。另外一个

13、示例是，一个无状态流程以一个消息代理订阅(message broker subscription)开始，对消息进行转换，并将其发布到另一个消息代理通道。现实中较为常用的情 形是对一个长期运行的业务事务进行建模。这可通过向通道发布消息将其构建为松散藕合的一组无 状态业务流程。由于无状态流程被编译成无状态会话bean，这就确保了数据成员只包含非特定实例(non-instance-specific)数据。您不能显式地将一个流程配置为无状态的。在默认情况下，一个业务流程是无状态的，直到您 向数据流中添加了任何的基本构成结构，譬如等待一个回复或者一条消息。这反过来强迫事务边界 和流程变为有状态的。因此，

14、如果流程只运行在一个事务中的话，该流程就是无状态的。有状态流程有状态流程指的是运行在一个以上事务中的流程。这样的流程在数据库中有持久存储的状态， 并被编译成一个实体beano有状态流程所支持的业务情况涉及到复杂的、长期运行的逻辑，并且因此有特定的可靠性和恢 复需求。通过添加有状态节点或者强加事务边界逻辑的方式就能使一个流程变成有状态的流程(参 见事务边界)。例如，一个流程接收消息，进行转换，将其发送给一个业务伙伴，然后等待一个异 步响应，这样一个流程就是有状态流程，因为“等待”的动作强加了一个事务边界。可引起抑止点的节点列表是：Control receiveEvent choice (起始节点

15、除外)Parallel branching有些控件通常需要一个control receive并因此将会强制一个流程变成有状态的。这些控件的 一个部分列表包括：WorklistTimer异步双向流程JMS订阅消息代理订阅有状态流程由于其在数据库中有状态，所以其性能不及仅使用内存的(memory-only)无状态 流程。然而，状态的持久存储往往是必要的，因为它可以确保：在系统停机的等待期间内，流程可以恢复并继续执行而不会丢失数据。在此等待期间内，系统资源会被有效的利用。在此期间，该实体bean可能会被钝化(passivated)，这将释放服务器上的内存。您不可以显示地将一个流程配置为有状态的。当位

16、于流程顶部的流程起始节点有一个绿环时， 您就知道该流程何时是有状态的。并行节点最佳实践在使用并行节点之前，先要了解它们。原因使用并行节点可以隐式地改变流程的行为。并行节点可改变流程的事务处理行为和状态行为。并行节点所谓的并行也仅仅是逻辑概念上的并行。细节业务流程中的并行执行分支是逻辑上的并行；物理上它们是由业务流程引擎顺序执行的。业务 流程在和外部系统进行通信时，如果涉及到等待外部系统的响应的话，那么业务流程就会从这种逻 辑上的并行机制受益。在一个执行分支等待响应的同时，并行流中的另外一个执行分支可以继续执 行。并行分支只是在它们的终止点上被同步。在多个分支的终端定义了一个结合条件（join

17、condition） 来确定分支的终端是如何终止总体并行活动的（parallel activity）。有效的结合条件是AND和OR。WebLogic Integration 数据库最佳实践为WLI数据库和应用程序数据库使用分开的schema （而不是物理数据库）。原因这将WebLogic Integration表与应用程序表分开，所以可应用不同的策略。细节即便在您只有一个共享数据库的情况下，为WebLogic Integration和应用程序使用分开的 schema （分开的用户）是一个好方法。有时WebLogic Integration可能会在开发模式中迅速地 创建表，这说明WebLogic

18、 Integration用户ID需要创建许可，但是应用程序数据库用户通常没 有被赋予这种特权。这也将WebLogic Integration表与应用程序表分了开来，从而有助于数据归 档和维护。配置超时最佳实践关联超时路径以确保业务流程最终会结束。原因这个事件可能永远不会发生，该业务流程可能会永远阻断（blocked）o细节您可在一个节点上、一组节点上或者整个流程上设置超时。当流程开始时，起始节点上的定时 器启动。当业务流程到达该执行点时，节点或者节点组上的定时器启动。结束语软件开发的艺术在过去的几年中发生了显著的变化，现实中所有的软件工程都要使用实现特定 模块的框架。正在建设中的项目利用不同服务级别的协议与分散的系统进行集成，同时业务领导者 们期望着在宏观业务流程级别上实现可视化和管理。在与这种趋势保持协调一致的同时，我们期望 在今后的5年中业务流程管理系统会和数据库一样普及。在本文中，我们讨论了在BEA WebLogic I