jboss教程_教程：JBoss企业BRMS最佳实践

jboss教程

红帽的Eric Sc​​habell和Edson Tirelli提供了一些方便的提示，帮助您充分利用红帽的JBoss Enterprise BRMS。

免责声明–本文仅代表Schabell和Tirelli的个人观点，而非Red Hat的观点 。

介绍

任何规模的组织中的业务专家和应用程序开发人员都需要能够建模，自动化，衡量和改进其关键流程和策略。 红帽的JBoss企业BRMS使完全集成的业务规则管理，业务流程管理（BPM）和复杂事件处理（CEP）成为可能。

本文将为您提供有关我们使用JBoss业务规则管理系统（BRMS）创建基于流程和规则的应用程序的见解的概述，该应用程序可以扩展以满足您当前和将来的企业项目需求。 我们将涵盖基于流程的应用程序和基于规则的应用程序，为您提供一些基本见解，以使您能够开发大型应用程序。

本文假定您具有JBoss BRMS产品的工作知识，并且不涉及基础知识。 扎实的软件架构背景很有用，因为本文讨论了正在做出的设计决策以及您需要执行的操作，以便您的项目可以在企业架构中不断扩展。

最后，我们不会在本文中研究CEP组件。

Craft.io流程

首先，我们需要仔细研究典型的企业环境，然后像洋葱一样剥离各个层，以仔细研究如何提供可扩展的BPM项目。 下面的图1显示了几个组件层，我们将需要集中精力：

• 初始化层
• 实施层
• 互动层

首先将介绍流程初始化层，我们在此向您，您的客户和如何启动流程介绍最佳实践。 在流程存储层，工具，业务用户和设计流程的开发人员的帮助下，流程实现层是维护流程的地方。 在这里，您还将找到各种实现的详细信息，例如特定于域的扩展，以涵盖我们项目中的特定节点类型。 最后，流程交互层是您的流程将连接到各种旧系统，后台系统，服务层，规则系统甚至第三方系统和服务的地方。

图1 – JBoss BRMS流程架构 

初始化层

看一下如何初始化流程，我们希望为您提供一些大型企业多年来使用的最佳实践。 似乎有一个主要主题是收集启动流程所需的客户，用户或系统数据，然后通过调用将其注入。 可以通过BRMS jBPM API调用，使用RESTful服务或通过标准Java Web服务调用将其嵌入到您的应用程序中。 无论您如何收集数据以初始化流程实例，都可能要考虑从一开始就如何扩展初始化设置。 通常，最初的项目设置时对未来没有太多考虑，因此某些问题没有被考虑在内。

顾客

  此处定义的客户可以是提供初始流程开始数据的人员，系统或用户。 在图2中，我们提供了一个高层次的视图，即客户如何提供过程数据，然后将其打包到请求中以放入一个过程队列中。 然后，我们可以从队列中确定优先级，并让不同的机制获取这些流程请求，并使用提供的请求数据启动流程实例。 我们在这里显示了EJB，MDB和云，它们表示可以用来清空进程队列的任何调度方式。

图2：队列和更多

Queue列

这些队列可以像数据库表一样简单，也可以像消息队列一样完善。 可以按照项目所需的任何方式进行设置，例如后进先出（LIFO）或先进先出（FIFO） 。 使用消息队列的好处是可以从轮询机制中确定它们的优先级。

此设置的原因有两个。 首先，您确保不通过从客户界面直接启动流程实例来保持客户请求。 它永远不会在到流程引擎的途中丢失。 其次，您可以对可能无法满足项目要求的未来流程进行优先级排序，例如必须在客户提交后10秒钟内开始的新流程请求。 如果将它放在队列的底部，需要花费一个小时来处理它，那么您就遇到了问题。 通过对队列进行优先级排序，您可以调整轮询机制以每次以正确的顺序检查适当的队列。

Java /云

图2中显示的Java图标代表您可能想用来处理流程队列的任何JEE机制。 它可以是EJB，MDB，您自己编写的调度程序，也可以是您想拿起处理请求的任何内容。

云图标旨在表示服务，您的软件可以使用这些服务来实际调用最终的startProcess方法，以初始化所请求的流程实例并将其传递给初始数据。 将与jBPM API的交互集中在单个服务中非常重要，以确保API更改时可以进行最少的工作，以便将来进行可能的版本迁移，并且您是否希望在以后的项目中进行扩展以扩展与jBPM的服务交互。

实施层

该层重点在于您的业务流程设计，流程中自定义操作的实现以及流程使用方式的扩展。 在流程设计和执行中采用标准BPMN2消除了BPM体系结构这一层的许多麻烦。 流程引擎被迫遵守并支持BPMN2标准，这意味着您在流程设计过程中只能做些限制。

在JBoss BRMS BPM组件中，有一个有趣的事情是构建高度可扩展的流程体系结构。 这是有状态知识会话 （SKS）的概念。 创建它是为了保存您的过程信息-数据和过程规范的一个实例。 当运行基于规则的应用程序时，通常的过程是运行单个KS（注意，不是有状态的！），并且所有规则和数据都将利用该单个KS。 对于一个SKS和流程，我们希望每个流程实例都使用一个SKS。 我们可以将此功能捆绑到单个服务中，以允许并发并促进我们的流程实例生命周期管理。 在此服务中，您还可以根据需要嵌入最终的同步或异步业务活动监视（BAM）事件生成器。

交互层

访问业务逻辑，后端系统，后台系统，用户界面，其他应用程序，第三方服务或您的业务流程完成工作所需的任何东西，一个好的策略可以带来很多好处。 许多企业正在将这些交互与面向服务的体系结构（SOA）中的服务层隔离，该体系结构提供了灵活性，并且可以很好地扩展可能遇到的所有各种工作负载。 在这里查看BPM层时，我们只想提及其中的一些后端系统，作为如何在企业中优化流程项目的示例。

JBoss BRMS BPM体系结构包括一个单独的人工任务（HT）服务器，该服务器作为服务运行并实现WS-HT规范。 可插拔，没有什么可以阻止您通过在服务中公开WS-HT任务生命周期来避免在企业中托管另一台服务器。 然后，应使用同步调用模型，该模型可以大大简化默认情况下利用HornetQ消息传递系统的标准产品实现。

您可以实施以提供出色的报告可伸缩性的第二项服务，我们称为BAM服务 。 您将使用此服务来集中BAM事件，并使用它来将这些事件推送到可靠且快速的JMS队列中。 然后，可以使用一台单独的机器来托管这些JMS BAM队列，在不增加BPM引擎本身负载的情况下处理消息，写入单独的BAM数据库，通过批处理进行优化，并且使用BAM信息的任何客户端都不会再次放入BPM引擎本身的任何负载。

规则

BPM专注于使用定义明确的流程对一系列操作进行建模，而业务规则管理（BRM）技术则用于对松散耦合并由场景触发的操作进行建模。 考虑这个概念的一种更简单的方法是记住规则实现的最常见用例：决策管理。

一般而言，决策管理是对给定域及其管理中涉及的所有规则和变量（数据）的外部化和合并。 然后，可以通过决策服务将这些合并的规则提供给应用程序，并且可以对其进行集中管理，审计和维护。 它们将具有独立于用户应用程序的生命周期，并提供其他好处。

目标

通常，对应用程序采用业务规则管理有哪些目标？

决策自动化：第一个好处是业务应用程序中决策的自动化。 在这里，我们谈论的是日常运营决策，这些决策在任何业务环境中都花费大量时间。 我们并不是指需要人为干预的长期战略决策。 现实情况是，企业中的绝大多数运营决策都可以自动化，从而缩短了响应时间并提高了业务绩效。 它还可以提高质量，一致性，并具有随时间推移审核决策过程的能力。

表现力和可见性：业务规则引擎（BRE）通常提供更高级别的隐喻和更高级别的语言来编写规则。 通过使用这些更高级别的表示，规则变得更加简洁，使业务用户更易于理解和验证。 它还使业务用户可以自己编写规则。

性能和可伸缩性： BRE具有用于规则编译和执行的专门算法，这些算法通过自动优化规则，优于手动编码规则。 JBoss BRMS可以有效地执行并扩展到成千上万的规则。

知识的集中化：通过外部化和合并规则，企业可以确认规则已正确实施并且在使用它们的所有应用程序中保持一致。 这种体系结构还促进了逻辑，数据和任务之间的明确分离，从而使企业能够提高敏捷性和上市时间。 最后，通过集中业务知识，可以对其进行审核以进行合规性和优化。

启用BRE的应用程序

开发支持BRE的应用程序与开发传统应用程序没有太大不同，但是可以遵循一些最佳实践，以最大程度地利用BRMS工具提供的好处。 下一部分按特定的顺序列出了这些最佳实践中的一些最佳实践，这些最佳实践归类于架构和创作实践中。

建筑的

知识库分区

知识库通常将包含与一个主题，业务实体或工作单元相关的资产，例如规则，流程和领域模型。 了解如何在知识库中划分这些资产可以对整个解决方案产生巨大影响。 BRMS工具在优化规则集方面比在优化单个规则方面更好。 与在多个规则集中划分的同一组规则相比，规则集越大，结果越好。 另一方面，通过包含不相关的规则来增加规则集具有相反的效果，因为引擎将无法优化不相关的规则。 该应用程序仍将支付附加逻辑的开销。 作为最佳实践，用户应通过仅将相关规则部署到单个知识库中来对知识库进行分区。 用户还应避免使用单一的知识库以及过于精细的知识库。

知识会议分区

知识会议的创建旨在降低性能。 BRMS系统通常在增加规则数量时伸缩性更好，而在增加数据量（事实）时伸缩性更差。 因此，我们可以推断出，知识会议越小，系统的整体性能就越好。 单个会话也很容易并行化，因此具有多个会话的系统将在具有多个处理器的硬件上更好地扩展。 同时，我们应尽量减少数据或事实的碎片，因此我们只想在同一会话中将相关事实与相关规则包括在内。 这通常包括与交易，服务或工作单元有关的事实。 创建会话时，与将单个事实添加并为每个事实触发规则相比，更希望将所有事实批量添加到会话中，然后触发规则。

领域模型设计

从基础关系算法到诸如数据索引之类的优化，BRE在许多方面都类似于数据库。 因此，为数据库使用而记录的许多最佳实践也适用于BRE，这不足为奇。 最重要的一项是仔细设计域模型。 领域模型的质量与规则的性能和可维护性成正比。 设计不当的域模型不仅会影响引擎的运行时间，还会增加时间和成本，因为规则的编写将更加复杂，并且随着时间的推移将难以维护。 好的领域模型是一种以最简单的方式表示多个实体之间的关系的模型。 较扁平的模型通常有助于使约束更易于编写，而小的实体（属性很少的实体）则有助于防止循环。

规则创作

不要试图进行微控制

规则应根据场景执行操作，这些是规则的条件。 通过遵循这个简单的原则，规则可以保持松散耦合，从而允许规则作者单独管理它们。 规则引擎进一步优化了分离的规则。 仅使用诸如显着性，议程组或规则流之类的冲突解决策略来编排规则集，而不要使用单个规则。

不要重载规则

每条规则应描述一个方案和一个动作列表之间的映射。 不要尝试在多种情况下使规则过载，因为这会使长期维护变得更加困难。 这也增加了测试的复杂性，并使场景之间不必要地联系在一起。 通过将引擎分解为多个规则，利用引擎的推理和链接功能为复杂的场景建模。 引擎将在场景之间共享任何通用条件，因此这样做不会对性能造成任何影响。 例如：

规则“ 1 –青少年和长者获得折扣”

什么时候

年龄在16至18岁之间，或年龄在65岁以上

然后

分配25％的门票折扣

结束

规则“ 2 –长者可以在A区购买门票”

什么时候

年龄大于或等于65岁

然后

允许销售A区门票

结束

以上规则已超载。 他们在相同的规则中定义了青少年或长者的政策，以及针对这些人群的实际行动。 假设公司有1000条适用于长者的规则，并且在每条规则中，它将重复条件“人员年龄大于或等于65岁”以检查长者。 想象一下，公司针对长者的政策或有关此事的政府法律发生了变化，现在60岁以上的人被视为长者。 这种简单的策略更改将更改所有1000条现有规则，更不用说测试方案，报告等了。编写相同规则的一种更好的方法是让一个规则定义什么是长者，另一条规则定义什么。一个少年，然后所有1000条规则都只使用推断的数据。 例如：

规则“ 0.a –青少年为16-18岁”规则“ 0.b –年龄大于65岁”

什么时候

年龄在16至18岁之间

然后

断言：这个人是少年

结束

规则“ 0.b –老年人年龄超过65岁”

什么时候

人大于65岁

然后

断言：此人是长者

结束

规则“ 1 –青少年和长者获得折扣”

什么时候

青少年或长者

然后

分配25％的门票折扣

结束

当这样编写时，用户将利用引擎的推理功能，同时使规则更易于理解和维护。 同样，针对长者的相同政策更改只会影响我们示例中的1000条规则中的一条规则，从而降低了成本和复杂性。

控制事实是代码异味

控制事实是在域中引入的事实，并在规则中使用，其唯一目的是显式控制规则的执行。 它们是任意的，不代表域中的任何实体，通常用作规则中的第一个条件。 控制事实在没有JBoss BRMS具有表达力和强大的冲突解决策略的引擎中大量使用，并且具有许多缺点：它们导致对规则执行的微控制，导致不必要的规则激活和取消引起的大量工作突发。 它们降低了规则的可见性和表达性，使其他用户更难以理解以及在规则之间建立依赖关系。 控制事实是一种代码气味，应作为一般最佳实践避免使用。 话虽如此，只有一种使用情况可以接受控制事实，这是为了防止昂贵的联接操作，除非满足给定条件，否则该联接操作不会发生。

适用于正确工作的正确工具

JBoss BRMS具有许多高级功能，可帮助用户和规则作者对业务进行建模。 例如，如果需要查询会话中的数据以做出决定或将数据返回给应用程序，则用户应使用查询而不是规则。 查询就像规则一样，但是它们总是按名称调用，从不执行动作并且始终返回数据。 另一方面，规则始终由引擎执行（无法调用），规则应始终在它们匹配时执行操作，并且永不返回数据。 JBoss BRMS提供的另一个功能是声明性模型，即声明和定义为知识库一部分的事实类型。 例如：

申报人

名称：字串

年龄：整数

结束

声明性模型是开发快速原型和建模仅由规则而非应用程序使用的辅助事实类型的好方法。 JBoss BRMS与POJO中开发的域模型本地集成，并且POJO的使用简化了应用程序集成，测试，并且当规则和应用程序使用相同的域实体时应优先使用。

作者简介

Eric D. Schabell是Red Hat的JBoss集成和BPM产品的技术推广者。 他负责推广JBoss企业中间件集成产品和服务（BRMS / BPM，SOA和数据集成）的各种出站技术方面。 自1998年以来，他一直为许多不同的企业从事软件开发工作。 在http://www.schabell.org上关注此博客。

Edson Tirelli是Red Hat的首席软件工程师，在中间件和电信解决方案方面拥有10多年的经验。 自2006年以来，他一直从事Drools项目和JBoss Enterprise BRMS产品的设计和开发，并且是Drools Fusion CEP模块的首席工程师。 他的兴趣是一般的AI，特别是推理引擎，语言设计以及开发和编译器。

翻译自: https://jaxenter.com/tutorial-jboss-enterprise-brms-best-practices-105333.html

jboss教程