业务规则管理系统的设计与实现推荐.pptVIP

* 规则引擎和 BPEL 是两种互补技术。Oracle BPEL 流程管理器提供了高级工具来显示、设计和管理 BPEL 流程，而第三方规则引擎使复杂的业务逻辑可以用类似英语的语法表示，并由非程序员领域专家对其进行编辑。 业务逻辑被分布到三个不同的 IT 基础架构层中：业务流程、Web 服务和规则。 业务流程层。该层负责管理业务流程的总体执行。这些使用 BPEL 实现的业务流程可以是长期运行的业务流程、事务业务流程以及持久业务流程。流程逻辑支持分布到 Web 服务/EJB 调用中的高级事务（“sagas”）以及嵌套的子流程事务。BPEL 引擎支持对工作流进行审计和检测，因此比较适合于 将不易变化的工作流步骤与易变的业务规则分开 实现行业流程 实现需要补偿的流程 支持流程的大型实例化 设计需要审计的流程 协调异构技术，如连接器、Web 服务和支持 Web 服务调用框架 (WSIF) 的逻辑 Web 服务层。Web 服务层将现有的应用程序层功能公开为服务。这样，多个业务流程便可以重用这些服务，从而实现面向服务体系结构 (SOA) 的承诺。 　Web 服务实现功能逻辑和域逻辑。功能方法通常是无状态和中等粒度的。例如，Web 服务可能包含系统数据的实用程序方法、实体操作和查询方法。可以使用多种技术实现 Web 服务并隐藏实现平台之间的差别。因此，该层比较适合于： 为特定实体/域领域实现中等粒度的方法 集成原有的代码/第三方工具 封装应用程序层中的逻辑、自定义代码和实现 规则层。规则引擎通常是复杂逻辑（涉及实体之间的一些相互依赖性以及与顺序相关的逻辑计算）的发源地。从业务流程中以单独实体的形式提取业务规则可更好地对系统进行分离，从而提高可维护性。 规则引擎可以对规则集进行并行和按顺序的评估。此外，规则能够对输入数据和中间数据的值进行评估并确定是否应引发规则。与传统的 Java 过程代码相比，该模块设计提供了一个更简单、可维护性更高的解决方案。 此外，正如我在前面指出的，规则具备声明特性，并使业务分析员能够进行高级 GUI 编辑。现代规则引擎的执行速度非常快，并提供了内置的审计记录。规则层的典型特性包括 包含耦合和复杂的逻辑 支持使用并行执行进行高效的业务逻辑评估 包含基于多个业务规则评估构建的复杂返回结构 允许将域逻辑转换为简单规则 实现高度易变的业务策略 由于规则在 Web 服务层中公开为服务，因此可以在所有企业间应用程序中重用，从而简化了新应用程序和集成的开发。 * 典型的开发流程包含三个步骤： 在规则集中创建规则 将规则集公开为 Web 服务 从 BPEL 中调用规则集 Web 服务 开发阶段需要专门的角色（如规则开发人员、流程开发人员、业务分析员和 Web 服务开发人员）才能完成这些任务。 维护阶段。 对于维护阶段（项目中的最长阶段）而言，将业务规则移出 Java 代码并移入规则引擎中将增强维护的可管理性。业务管理者可以在运行时使用图形界面修改规则，业务规则和 BPEL 流程可以相互独立地进行更改。 * 规则引擎调用将出现在三个层中（请参阅图 4）：BPEL 调用规则 Web 服务、规则 Web 服务调用规则引擎、规则引擎应用程序代码接收输入并返回结果。 在示例业务流程的上下文中，应用程序使用 XML 有效载荷调用 Eligibility process。该有效载荷包含有关帐户的信息（如家庭属性）。Eligibility process 反过来调用 Eligibility Web service。Eligibility Web service 提供从 XML 到 JAXB 的转换，然后调用 Eligibility Rules Delegate Session Bean。后者使用 RMI 与会话 session fa?ade 交互。Session fa?ade 激活规则引擎，后者随后计算 eligibility 结果并将这些结果返回给该流程。Eligibility Process 将评估返回的结果并将 Program 1 或 Program 2 指定给该帐户。在该示例中，我们提供了一个远程服务器来运行 eligibility 规则，也可以在本地托管该规则。（注意，最佳实践是不要将非流程服务与 BPEL 流程管理器放在同一位置，这样可以实现更好的可伸缩性。） 该示例有效演示了如何将业务逻辑划分为规则、BPEL 和 Web 服务： Eligibility BPEL Process 显式定义了必须根据接收的 Eligibility Results 数据执行的步骤。Eligibility BPEL Process 将基于 Eligibility Results 调用不同的分支