在SOA中实现业务规则和业务流程

业务规则实现的灵活性和可修改性，通过激活动态变化的规则维护支持而实现（使用初始的规则语言）。这种能力提供了一种动态地修改业务规则的方法，并且不用重新构建和重新部署实现来快速地适应改变了的业务环境。

声明式的编程（例如规定什么）代表规则的选择模型：根据规则取值为true还是false，有些东西得以触发（例如动作）。控制流（例如这些调用的顺序）是隐式的，并在规则触发时显现出来。

业务流程

“业务流程是通过将一个输入转换成一个更有价值的输出来创造价值的一组相互关联的活动。输入和输出都可以是工件和/或者信息，并且该转换可以由人类的操作员、机器或者两者来执行”5。包含一个业务流程的活动不包括任何过程级别的决策，不值得进一步的分解。业务流程定义可以被看作是实现一个特定目标的诀窍。类似于业务规则的情况，利用业务流程DSL和专门的业务流程引擎，业务流程的实现可以被明显地简化。

业务流程编程要求指定执行流程活动（控制流）和活动（数据流）之间数据交互的顺序和条件。典型的语言构造允许以扩展流程图或者限定状态机器的形式定义流程。

业务流程定义，以业务流程语言表达，一般直接由业务流程引擎执行。（引擎在内部可以编译或者解释业务流程语言。业务流程引擎支持流程活动执行的协调和它们之间数据传播。在资源约束之下，管理多个异步处实例的同步执行，是业务流程引擎的主要挑战之一。

因此，业务流程实现与活动的实现分离，由业务流程编制。这样提供了将变化引入到业务流程的能力，不影响或者最小限度地影响底层的活动，从而给整个系统提供一种更高级别的可修改性。

必要的编程（例如规定如何）表示业务流程实现的选择模型：因为业务流程定义规定了它们的顺序，因此某些东西在其他某些东西之后被调用。控制流是显式的。

为了保持竞争力，公司必需不断地变革，并改善它的业务流程。从应用程序中将业务流程分解出来，并给它们允许简化实现和修改企业业务流程的实现，使用一种业务流程语言和引擎。

决策考量

说到最好地支持业务需求，并实现最佳的架构品质，确定正确的技术就变得很重要了。一天下来，假如使用了适当的DSL和引擎，那么业务规则和业务流程模型之间的实现选择则取决于两大因素：

适当引擎的能力

整体系统的分解

说到规则与业务流程引擎的能力对比，应该考虑到以下几点：

同步性。规则评估是同步的，并且规则引擎（rulesengines）被设计成尽可能迅速地评估业务规则。另一方面，流程一般来说本质上就是长运行且异步的。流程引擎（process engines）的长处在于支持长运行流程的能力，在这里，动作可以花很长的时间来完成。因此，它们提供流程异步调用所需要的机制，例如请求/响应的关联、补偿，等等。

状态性。规则引擎是无状态的，当规则触发引擎时，一般会从输入参数或者知识库中拖出它的输入，对它进行评估，然后更新知识库或者将结果传播到输出。业务流程引擎专门设计用来保存每一个活动的流程实例的状态，在活动调用之间对它进行转换（hydrate）和保存，并为下一个活动的执行将它再次转换（re-hydrate）。

决定性。规则引擎触发其条件同时评估的业务。然而，它们的顺序是不确定的。业务流程大部分是确定的3，人们一般增加制约与平衡（checks and balances）来确保确定性。

粒度。虽然业务规则本身可以在公司级别使用，但是它们一般被当作组件。它们本身提供一种更小的粒度，并从维护和部署角度来提供一种更高级别的灵活性。另一方面，业务流程更可以被看作是固定资产，它更不可能经历超时的巨大改变。

如前所述[1]，SOA设计是基于企业业务模型从上到下的分解，如顶级的业务流程集合所定义的。在这种方法（图1）中，顶级的业务流程定义了一组活动，它们组成高级的业务服务。这些服务经常依次被当作流程，这导致递归的分解。最后，服务被实现为一组组件的协调，它展现这个分解的叶元素。

图1分等级的分解

在这种情况下，业务组件的不同实现可以包括现有企业功能的“包装”4，新的实现使用通用的编程语言，业务规则基于一个组件，编制则基于多个组件。