<cr:conditions>
  <greater-than-or-equal-to>
    <instance-method>
      <variable>
        <type-alias>Beans.Trade</type-alias>
      </variable>
      <name>getQuantity</name>
      <!-- getQuantity (and any other bean property) takes
           no arguments.  If it did, they
           would go here
        <arguments>...</arguments>
      -->
    </instance-method>
    <literal:integer>
      5000
    </literal:integer>
  </greater-than-or-equal-to>
</cr:conditions>

　　在这个示例中，如果在我们的事实中有一个Trade对象，那么规则引擎就会调用它的getQuantity()方法并且将结果与整型5000进行比较。如果它大于或等于5000，则该条件为真。

　　规则的第二部分是条件满足时执行的动作的列表。最常见的动作是：创建一个新对象，把它添加到规则引擎用来评估条件的事实集中。规则引擎继续对规则进行迭代，直到无法从事实中得出更多的推理；向动作添加新对象会导致另一轮的条件评估循环。正如我们将要看到的那样，可以创建任意类型的对象，并定义对应用程序具有特定意义的各种类型。这里的技巧是，应用程序设计者可以定义一组足够丰富的动作，以包含那些可由规则编写者调用以满足各种业务需求的任务。

　　在我们的交易应用程序示例中，所有动作都会创建将添加到由规则引擎使用的工作集中的新对象。有些规则向该集合中添加简单的String对象。这些对象表示了从原始事实中演绎出来的中间事实，它们可以在规则引擎中得到进一步的推理，但流程JPD不会以任何形式解释它们。其他的规则将创建Beans.Action类的对象。这些对象包括当规则条件满足时流程将执行的实际命令。流程JPD和支持类将实施已知的动作命令来聚集交易并执行块交易。在这个简单的示例中，实际上只有两个已知的命令：创建（并执行）订单、使用指定的属性聚集一项交易。前面规则2的动作是使用属性symbol和manager来进行聚集，该动作如下：

<cr:actions>
  <new-instance>
    <type-alias>Beans.Action</type-alias>
    <arguments>
      <literal:string>symbol, manager</literal:string>
    </arguments>
  </new-instance>
</cr:actions>

(编辑:aniston)