资源描述
简介业务应用的需求总是随着业务环境的变化趋势而不断地改变。决策非常少是原封不动的，同时竞争压力要求业务逻辑的设计和实现具有灵敏性，以快速地习惯不断变化的需求。通常，对业务逻辑的更改必须由开发人员来完成，然后进展屡次完全的测试，而这将是一个非常耗时的过程。在应用程序的修正工作完成后，需要将其重新部署到效劳器，需要留出预定的停机时间，以防应用程序对用户不可用。关于这个咨询题，更好的处理方案是通过应用程序之外的一组规则来实现某些业务决策。这些规则并没有被编译到应用程序中，而是在运转时读取并应用。通过这种方式，无需更改代码或者停顿正在运转的应用程序就能够改变这些规则。WebLogic Portal包括一个根本的规则引擎，用于使WebLogic Platform应用程序从规则获益。尽管该引擎不是功能完备的产品，但我们将展示如何将其与WebLogic Integration Business Processes (JPDs)一起使用来为业务逻辑提供一种灵敏且动态的实现机制，从而无需只为了修正规则而重新部署应用程序。首先我们来看一下将在全文中使用的例如应用程序，然后介绍如何将规则引擎注入到WLI流程中以实现业务逻辑。然后，我们将更细心地研究这些规则本身以及如何为业务逻辑定义这些规则，最后将描绘在运转中的系统中更改业务规则所使用的机制。例如应用程序我们将开发一个例如买卖应用程序作为在业务流程中使用规则的例子。该买卖应用程序是一个金融买卖流程的简化版本，该流程使用调用规则引擎的JPD业务流程而构建。该例如应用程序采纳了不同的有价证券买卖集合，并依照一组由业务定义的规则将其分组成买卖块以便执行，或许是为了减少佣金。所以，这里给出的应用程序并不完好，但它已经足以展示如何在现实世界应用程序中使用规则引擎。有完好的源代码可供下载，其中的readme文件提供了构建和运转该应用程序的说明。在解释如何开发如此的应用程序之前，我们先通过对门户规则引擎的一些特性的简要概括来理解其工作方式。这里假定读者熟悉一般的规则技术。规则引擎及其工作方式图1说明了规则引擎的根本情况。该引擎依照一组规则来处理初始的事实集，而这些规则由引擎从外部库中获得。初始事有用于为该引擎填充工作内存。由规则来对工作内存中的事实进展评估，假如满足某条规则的条件，则将执行对应的动作。通常，一个规则动作将向工作内存中添加一条新的事实，并重复该流程直到应用完所有的规则。然后通过可选的过滤器来选择特定类的对象以返回给调用方。能够通过Controls界面访咨询规则引擎，还能够用它来设置属性（比方规则集文件的位置）。 图1：该规则引擎是一个由控件包装的EJB。储存库中的规则反复地应用于工作内存中的事实，以获得新的事实。在无法进展接着推理的情况下，对工作内存进展过滤以返回感兴趣的工程。从WLI流程调用规则引擎让我们从被实现为JPD的买卖业务流程开场，来看看如何添加对规则引擎的调用。要在WLI流程中添加规则，能够使用作为WebLogic Portal的一部分而提供的Rules Executor Control（规则执行器控件）。关于本例，我们只使用该控件中所提供的方法和特性的一个子集。关于规则控件的附加说明文档能够在参考材料部分找到。此处假定开发人员使用WebLogic Workshop集成开发环境来创立新的流程应用程序。然后可在该应用程序中创立一个流程工程。由于默认情况下门户控件在流程工程中不可用，因而需要将这些控件和规则引擎的EJB导入到应用程序。然后，将控件输入和输出插入到JPD中。在WLI流程中使用门户规则引擎的根本步骤如下： 导入规则引擎到应用程序： 在应用程序中包含规则引擎。 将p13n_controls库添加到应用程序。 处理输入和输出： 为输入和结果添加变量。 创立一个Rules Executor控件。 在WLI流程中添加一个Control Send With Return节点。 为创立初始数据编写Java代码。 添加一个流程节点以对结果进展迭代。 创立规则集。 后面我们将更详细地讨论其中的每一个步骤。在应用程序中包含规则引擎规则引擎包含在下面的文件中：/weblogic81/p13n/lib/p13n_ejb.jar要在应用程序中包含该引擎，请右击Workshop集成开发环境中的Modules文件夹，并选择Add Module。导航到该jar文件，并选择Open。将p13n_controls库添加到应用程序要使得门户规则控件在应用程序中可用，请右击Workshop集成开发环境中的Libraries文件夹，并选择Add Library。该控件位于： Rules Executor。为控件键入名称，并按下Create按钮。在WLI流程中添加一个Control Send With Return节点将刚刚创立的控件拖放到流程中以创立一个控件节点来实际调用规则引擎。在例如中，我们将使用控件的evaluateRuleSet()方法。从Send Data面板中，选择前面为方法的输入参数而创立的输入变量。使用Receive Data面板选择返回变量来获取规则执行的结果。在Property Editor窗口中为控件属性键入相应的值。为创立初始数据编写Java代码在创立了输入变量后，我们还没有对它赋值，因而需要编写代码来完成该任务。这个变量是一个Java对象数组，它提供了输入到规则条件中的初始事实。能够创立一个新的Perform节点来初始化该数组，或者通过使用Source View在Control Send节点中添加代码来设置该变量的值。添加一个流程节点以对结果进展迭代Rules Executor控件的每一个计算方法都将返回一个结果的迭代器。编写代码，使用该值实现对规则执行结果的迭代。假如没有指定过滤器类，这个迭代器将返回规则引擎工作内存中的所有值。其中包括原始输入以及任何在执行满足条件的规则的动作时添加到工作内存中的值。关于添加的对象，迭代器返回一个Result类的对象，该类的getObject()方法能够返回在规则动作中所添加的实际对象。创立规则集使用XML编辑器，在/META-INF/data目录中创立一个扩展名为.rls的文件。规则通常添加到子目录rulesets中。业务逻辑规则我们刚刚展示了如何在业务流程中插入规则引擎。如今让我们来看看如何利用该规则引擎以及如何编写映射到业务规则的规则。规则包括两个部分：应用该规则时必须为确实条件，以及当条件满足时将执行的动作。因而，要在应用程序中使用规则，设计人员必须首先定义哪些对象和属性在测试规则条件时对规则编写者是可见的。规则引擎同意在一个条件中调用任意多个方法。这种构造方式便于定义JavaBean作为组成初始事实集合的对象，规则引擎使用这些初始事实来进展推理。能够使用bean的 get方法来获得条件测试的值。规则所援用的Java对象需要从创立它的WLI流程以及从规则引擎本身中都可见。这就防止了这些对象与流程JPD位于同一包中，更确切地说，它们应该被创立于作为同一应用程序的一部分的Java工程中。然后，这些对象能够通过package.class标记在规则文件(.rls)和流程JPD中援用。在我们的买卖例如中，将把不同的买卖分组以便能够成块执行。为实现该目的，我们定义两个bean来表示相关的对象。第一个是Trade bean，它表示单个的买卖订单。这个bean的属性表示买卖的份额、股份数目以及所期望的价格等。任何关于决定买卖所属的块来说可能有用的值，都应该作为这个具有公有get方法的bean的属性，以便能够在规则中使用它。第二个bean是Block bean，通过它能够存储所有依照某个属性集聚合在一起的不同买卖。这个bean的属性包括规则中任何可用于断定块大得足以执行订单的的信息。这些属性能够是平均价格、买卖的总美元数或总的份额数等等。为了在我们的应用程序中实现块功能，首先使用规则来定义某项买卖是否只需要执行其本身就足够了（也确实是说，它是仅包含单个买卖的块），或者假如不是如此的话，那么应该使用什么属性将其与其他买卖聚拢以构成一个块。在一项买卖聚拢到适当的块中后，就会第二次调用规则引擎来推断该块是否完成。例如，假设我们想要得到如此的规则： 规则1：任何5,000股及以上的单项买卖应该作为一个块并予以执行。 规则2：由同一个投资治理者定购的具有一样标记的买卖应该聚拢在一起。 规则3：总价值超过,000的块应该予以执行。 调用与规则条件中的对象相关联的方法非常容易，如下面的例如所示，这是规则1的条件： Beans.Trade getQuantity !- getQuantity (and any other bean property) takes no arguments. If it did, they would go here . - 5000 在这个例如中，假如在我们的事实中有一个Trade对象，那么规则引擎就会调用它的getQuantity()方法同时将结果与整型5000进展比拟。假如它大于或等于5000，则该条件为真。规则的第二部分是条件满足时执行的动作的列表。最常见的动作是：创立一个新对象，把它添加到规则引擎用来评估条件的事实集中。规则引擎接着对规则进展迭代，直到无法从事实中得出更多的推理；向动作添加新对象会导致另一轮的条件评估循环。正如我们将要看到的那样，能够创立任意类型的对象，并定义对应用程序具有特定意义的各品种型。这里的技巧是，应用程序设计者能够定义一组足够丰富的动作，以包含那些可由规则编写者调用以满足各种业务需求的任务。在我们的买卖应用程序例如中，所有动作都会创立将添加到由规则引擎使用的工作集中的新对象。有些规则向该集合中添加简单的String对象。这些对象表示了从原始事实中演绎出来的中间事实，它们能够在规则引擎中得到进一步的推理，但流程JPD不会以任何方式解释它们。其他的规则将创立Beans.Action类的对象。这些对象包括当规则条件满足时流程将执行的实际命令。流程JPD和支持类将施行已经知道的动作命令来聚拢买卖并执行块买卖。在这个简单的例如中，实际上只有两个已经知道的命令：创立（并执行）订单、使用指定的属性聚拢一项买卖。前面规则2的动作是使用属性symbol和manager来进展聚拢，该动作如下： Beans.Action symbol, manager 响应该动作，流程JPD及其支持类为当前买卖查询symbol和投资manager，找出具有一样的symbol和投资manager的未执行买卖，并将这些买卖聚拢到一样的块。在完成一项买卖的聚拢后，将从第二个Rules Executor控件再次调用规则引擎，以评估规则，决定是否应该执行产生的块买卖。依照业务规则3，该规则如下： Beans.Block getAmount 50000.00 Beans.Action create 这一次，我们分析Beans.Block对象，获取amount属性并与阈值进展比拟。假如该条件满足，则使用create命令向工作集中添加一个Beans.Action对象，这是通知流程执行该块订单的信号。让我们细心分析一下流程JPD。下面有用于调用规则引擎的Control Send节点的代码。正如我们能够看到的，该节点使用一个Rules Executor控件来评估规则集，该控件返回一个迭代器。通过其属性（没有给出），控件将过滤结果，仅返回Beans.Action类的对象。通过这些对象，代码将提取动作命令并执行所恳求的动作。正如前面所提到的，假如动作是聚拢该买卖，则流程将使用更新后的块作为输入，对规则引擎开场第二次调用。通过执行适当的动作，对结果进展第二次迭代循环。public void rulesExecutorControlEvaluateRuleSet() throws Exception / Execute the Rules using facts as the input /#START: CODE GENERATED - PROTECTED SECTION - you can safely / Add code above this comment in this method. #/ / Input transform / Return method call this.results = rulesExecutorControl.evaluateRuleSet(this.facts); / Output transform / Output assignments /#END : CODE GENERATED - PROTECTED SECTION - you can safely / Add code below this comment in this method. #/ /* Iterate over the results of rules execution. This assumes that results are filtered to return only items of the Beans.Action class. The command property from the Action is expected to be either the string create, in which case a Block trade can be executed from the single discrete Trade, or it is expected to be a list of attributes describing the Block that this Trade should be incorporated into. */ while (results.hasNext() String action = (Action)results.next().getCommand(); if (action.equals(create) (new Block(trade).execute(); / single-trade else / Aggregate trade into an intermediate Block trade.aggregate(blockStorage, action); /* Call the rules engine a second time, this time using the resulting Block as the only input. This is to determine if the resulting Block now meets the criteria to execute the order. Again, results are assumed to be filtered by the control to return only the Actions. */ Block block = trade.getBlock(); Object blockFacts = new Object1; blockFacts0 = block; Iterator blockResults = blockRulesCntl.evaluateRuleSet(blockFacts); while (blockResults.hasNext() action = (Action)blockResults.next().getCommand(); if (action.equals(create) block.execute(); 动态规则WebLogic Portal的特性之一是Datasync功能，通过它能够将修正后的数据重新部署到集群中的门户应用程序中。由于门户规则引擎从Datasync存储区中获得其规则文件，因而应用程序的业务规则能够在运转的系统中进展更改，而无需停顿应用程序。关于Datasync以及用于更新数据的Datasync Web应用程序的其他信息，请参阅WebLogic Portal文档。默认情况下，Datasync Web应用程序将部署在常规门户应用程序中。然而，我们的例如应用程序是一个WLI流程应用程序，因而必须在其中手动地包含Datasync。要在Workshop集成开发环境中完成这些工作，请右击Modules文件夹，并选择Add Module。然后，选择下面的文件：/weblogic81/p13n/lib/datasync.war在集群中，Datasync应用程序应该仅部署到治理效劳器。为了说明如何在运转中的应用程序中更改规则，例如应用程序中包括了两个不同的规则文件，这两个文件中包括了用于将买卖聚拢成块的可选规则。前面已经描绘了默认规则（定义于traderules.rls文件中），第二个集合（在altrules.rls中）定义如下规则： 按照标记将所有的买卖聚拢成块。 执行包含3,000或更多股的块。 要看到动态规则的执行，首先使用所提供的测试数据运转例如应用程序。无需停顿效劳器或者重新部署应用程序，直截了当将原始规则保存到一个新文件中，并将替代的规则文件从： /META-INF/data/rulesets/altrules.rls 拷贝到：/META-INF/data/rulesets/traderules.rls再次运转例如数据，这时会发觉产生了不同的订单。留意，在例如域中不需要重新运转Datasync Web应用程序来更新规则。这是由于例如平台域以开发方式运转。在这种方式下，Datasync自动轮询 /META-INF/data目录及其子目录以搜索更改，更改正的文件能够自动地重新部署到应用程序。在消费域中，需要使用Web应用程序来实现数据的重新部署。推荐的步骤是，首先为所有更新过的文件创立一个jar文件，jar文件的根目录应该是data。然后，使用Datasync Web应用程序的Bootstrap Data功能来重新部署包含了新规则的jar文件。下载您能够下载本文中使用的例如程序的源代码：SampleApp.zip (2MB)完毕语在与WLI流程应用程序一起使用时，Portal Rules Engine是实现业务逻辑的强大工具。它非常容易合并到WLI流程中，同时能够使用JavaBean来评估规则条件，或者扩展作为规则评估结果而执行的动作。最后，Datasync特性所提供的动态更新才能使得业务逻辑更灵敏，并能够在不改变Java代码的前提下习惯不断变化的需求，因而不需要重新部署应用程序。
展开阅读全文