许多组织正从面向对象的业务流程管理范例转移到面向服务的方法；实际上，服务正在成为应用程序开发的基本元素。同时，业务流程执行语言(BPEL)已经成为编排这些服务和管理业务流程的无缺陷执行的事实标准。这些趋势所产生的结果是，为更灵活、更经济高效地管理业务流程提供了一些良机。

　　大多数业务流程（贷款审批就是一个典型示例）包含多个决策点。在这些决策点处，将对某个条件进行评估。业务流程根据这些标准或业务规则更改它们的行为。(一个是BPEL流程编排的分支可能存在规则，一个是BPEL中的活动节点本身可能存在数据处理规则。)实际上，这些业务规则对业务流程起到了推动作用。这些规则通常嵌入到业务流程本身或自定义Java代码的内部，这将导致在将来的某个时候出现若干问题：

• 业务规则比业务本身更改得更频繁，而更改和管理嵌入的业务规则是一个复杂问题，并超出了大多数分析员的能力范围。因此，随着业务规则的更改，程序员通常要消耗大量时间来执行该任务。
• 大多数组织都缺少中央规则信息库。策略中任何涉及到组织范围的更改都无法运用到所有业务流程中。
• 业务流程无法重用规则。因此，IT人员最终要为每个流程设计规则，这通常导致不一致性或冗余。

　　避免这些问题的最佳方法是使用规则引擎将业务流程与业务规则分离。在该方法中，规则公开为服务，而BPEL流程在到达决策点时通过查询该引擎来利用这些服务。该方法更为灵活-可以通过图形方式操作规则，而不是在编程语言中或在流程内部对规则进行编码。业务用户可以使用工具自行编写规则，并且无需IT人员的协助即可进行部署后的规则更改。由于大多数更新和功能增强是由业务用户执行的，因此可以显著减少维护成本。（分离的本质一方面是解耦，一方面是SOA平台本身不负责业务规则，业务规则由业务系统或业务人员自己维护，减少对SOA平台本身服务的变更。）

　　规则引擎和BPEL是两种互补技术。Oracle BPEL流程管理器提供了高级工具来显示、设计和管理BPEL流程，而第三方规则引擎使复杂的业务逻辑可以用类似英语的语法表示，并由非程序员领域专家对其进行编辑。

　　分离规则与流程

　　将规则引擎集成到流程管理框架中要求事先进行一定量的投资。在尝试进行此集成之前，将规则与流程分开是很重要的。因此，系统体系结构方面的一个主要决策是如何实现业务策略、业务流程和支持业务逻辑。实际上，架构师必须交流或设计最佳实践，以便设计人员在设计系统功能时知道应在何处应用每个相关技术-BPEL、业务规则、Java/Web服务。

　　如图 1 所示，业务逻辑被分布到三个不同的 IT 基础架构层中：业务流程、Web 服务和规则。我们将对它们进行依次介绍。

　　业务流程层。该层负责管理业务流程的总体执行。这些使用 BPEL 实现的业务流程可以是长期运行的业务流程、事务业务流程以及持久业务流程。流程逻辑支持分布到Web服务/EJB调用中的高级事务（“sagas”）以及嵌套的子流程事务。BPEL引擎支持对工作流进行审计和检测，因此比较适合于

• 　　将不易变化的工作流步骤与易变的业务规则分开
• 　　实现行业流程
• 　　实现需要补偿的流程（事务完整性考虑）
• 　　支持流程的大型实例化
• 　　设计需要审计的流程
• 　　协调异构技术，如连接器、Web服务和支持Web服务调用框架(WSIF)的逻辑

　　Web服务层。Web服务层将现有的应用程序层功能公开为服务。这样，多个业务流程便可以重用这些服务，从而实现面向服务体系结构(SOA)的承诺。

　　Web服务实现功能逻辑和域逻辑。功能方法通常是无状态和中等粒度的。例如，Web服务可能包含系统数据的实用程序方法、实体操作和查询方法。可以使用多种技术实现Web服务并隐藏实现平台之间的差别。因此，该层比较适合于：

• 　　为特定实体/域领域实现中等粒度的方法
• 　　集成原有的代码/第三方工具
• 　　封装应用程序层中的逻辑、自定义代码和实现

　　规则层。规则引擎通常是复杂逻辑（涉及实体之间的一些相互依赖性以及与顺序相关的逻辑计算）的发源地。从业务流程中以单独实体的形式提取业务规则可更好地对系统进行分离，从而提高可维护性。(对于规则层，是否应该访问数据库，按道理规则层的数据应该是外面送过来的，规则层拿到数据去匹配规则进行运算，不应该再和数据层打交道。)

　　规则引擎可以对规则集进行并行和按顺序的评估(注意规则集本身是可以编排的，即规则链，可以并行也可以按顺序执行)。此外，规则能够对输入数据和中间数据的值进行评估并确定是否应引发规则。与传统的Java过程代码相比，该模块设计提供了一个更简单、可维护性更高的解决方案。

　　此外，正如我在前面指出的，规则具备声明特性，并使业务分析员能够进行高级GUI编辑。现代规则引擎的执行速度非常快，并提供了内置的审计记录。规则层的典型特性包括:

• 　　包含耦合和复杂的逻辑
• 　　支持使用并行执行进行高效的业务逻辑评估
• 　　包含基于多个业务规则评估构建的复杂返回结构
• 　　允许将域逻辑转换为简单规则
• 　　实现高度易变的业务策略

　　由于规则在Web服务层中公开为服务，因此可以在所有企业间应用程序中重用，从而简化了新应用程序和集成的开发。

　　开发和维护

　　1. 在规则集中创建规则。在开发的最初阶段，规则开发人员在集成的图形开发环境（如ILOG的JRules业务规则管理系统）中创建初始规则。使用Oracle BPEL Designer 中的 Decision Service 向导，用户可以将业务规则集成到BPEL项目中。该向导将能够浏览Oracle Business Rules（Oracle 业务规则）以及第三方规则引擎的信息库。此外，用户能够将BPEL变量映射为规则信息库中的事实、插入新的事实并执行规则。然后，BPEL引擎将针对规则引擎事实自动执行从基于XML的变量到基于Java的数据类型的任何格式转换。

　　部署后，业务用户将能够访问与业务流程相关的规则并进行更改，而不必重新部署流程。该方法将显著简化BPEL流程与规则引擎的集成，并增强体系结构的灵活性。

　　创建规则前，应设置规则信息库和对象模型。通过规则信息库可以在业务规则的生命周期内维护和管理业务规则。业务规则操作的问题域通过ILOG JRules以业务对象模型(BOM)的格式表示。BOM通过表示模型的可执行版本的Java类或XML模式表示。XML模式可以帮助确保数据的灵活性。详细地实现对象模型通常是开发人员的任务。（定义规则前，必须有对象定义的schema信息，可以类结构，也可以是XSD,XML等）

　　开发人员创建对象模型和规则信息库后，您需要决定哪些规则可以由分析员维护，以及哪些规则要用低级语言(IRL)开发。创建开发人员级规则后，开发人员与分析员协作标识剩余规则并在规则模板（可以由多个非技术方重用）中捕获它们。该方法简化并加快了规则的生成，同时减少了可能出现的人为错误。

　　为启动基于模板的规则创建流程，分析员需连接到规则信息库。当分析员从信息库中打开规则程序包时，他们将能够访问该程序包的BOM。ILOG支持通过它的业务应用程序语言(BAL)定义高级规则。分析员可以在此时编辑现有规则，也可以创建新规则。可以在维护期间通过模板（用于限制可以对规则进行的修改）修改规则。

　　开发一个新规则后，可以使用ILOG Rule Builder工具内部的示例数据对其进行测试。Rule Builder中的该调试器支持断点，使用户可以检查有效的内存数据并显示规则执行顺序。完成规则编辑和测试后，分析员将规则程序包导入到规则集中并部署回信息库。

　　2. 将规则集公开为Web服务。JRules等规则引擎提供了相应的工具来生成包装程序Web服务或会话Bean，以包装新开发的规则集。Web服务开发人员将创建一个包装程序，以将规则集公开为Web服务。

　　XML是一个用于集成规则、EJB、BPEL流程和Web服务的关键标准。BPEL使用本机XML访问数据，而Web服务使用它来序列化数据（并将在Doc/Literal调用中原封不动地使用它）。XML可以在规则中直接使用。通过编组，可以将XML直接转换为JAXB对象树。可以使用本机Java对象执行规则。

　　Web服务应在它们相应的WSDL定义中导入XML模式。从XML模式中生成的DTO对象（如JAXB）还可以帮助确保数据顺利转换，而不会出现转换错误。

　　（注BPEL调用业务规则，调用的方式仍然是业务规则首先要封装为Web服务并在ESB上注册，BPEL调用Web Service送入的数据用于业务规则的计算，送入数据的WSDL和XML文件应该和规则定义时候使用的Schem一致）

　　3. 从BPEL调用规则集Web服务。开发所有自定义系统组件后，开发人员应将系统与BPEL引擎集成。原有系统和新的自定义组件由BPEL流程编排。可以在此时解决兼容性、数据类型转换和 Web 服务协议方面的问题。流程开发人员和/或系统集成商将在Oracle BPEL Process Designer内部实现编排流。

　　使用Oracle BPEL流程管理器执行JRule

　　显然，规则、Web服务和BPEL流程的设计和开发涉及多种不同的技术。在本部分中，我将介绍这些技术如何在运行时协同工作以执行 Eligibility Process。尽管该示例专门基于Oracle BPEL流程管理器和ILOG JRule，但它可应用于许多其他环境。

　　规则引擎调用将出现在三个层中：BPEL 调用规 Web服务、规则Web服务调用规则引擎、规则引擎应用程序代码接收输入并返回结果。

　　结论

　　在这篇BPEL“指南”中，我介绍了用于在三个不同层（业务流程层、Web服务层和规则层）中分布业务逻辑的策略。可以使用这些辅助技术最大限度地降低数据和逻辑之间的相关性。但是，为了获得充分的好处，设计师必须执行严格的分析以分解系统组件，并使用相应的技术来设计它们。开发过程涉及多种技术和各种角色。在参与开发过程之前，必须标识相应的资源。最终的体系结构是一个灵活的平台，业务用户可在该平台上处理多数业务更改，而无需IT人员的参与。