在在SOA中实现业务规则和业务流程中实现业务规则和业务流程
使用面向服务的体系结架构（SOA）的其中一大动力在于提升企业的敏捷度，并将不可避免的改变所带来的影响减到最小。
这一般通过把经常改变和相当稳定的实现工件进行分离来完成。支持这种分离的常用方法是分解（decomposition）和封装
（encapsulation）。SOA的分解导致服务的定义代表更稳定的工件，而业务流程则代表更经常变化的工件1。在一个典型的
SOA实现中，服务不会经常改变，但是非常经常地被组合和重组来构建／修改企业的解决方案。
这种分解不会直接标明业务规则的位置——整体IT实现中另一个频繁改变组件。由于业务规则可能相当经常地改变的事实，其
中一种被广泛采用的实践是将它们与业务流程关联起来——更加频繁地变化的SOA组件。这种方法的普及又得到了“许多实践
者将业务规则当作更广义的业务流程管理（BMP）的一部分”这一事实的支持，往往把业务规则和业务流程捆绑在一起。结
果，许多人把业务规则引擎和业务流程引擎当作业务流程／业务规则实现的两种相互竞争的技术。这是由于下列几种普遍的误
解：
业务规则和业务流程有着相同的设计模型和实现模型
业务规则和业务流程提供相同的工件，并且能以同样的方式使用
在本文中，我们将概括业务规则和业务流程之间的相同点和不同点，并介绍关于在SOA实现中配置业务规则的一些指导方
针，以及每种技术的适当用法。
业务规则
“业务规则描述在实现一个组织的目标时所应用到的操作、定义和约束。这些规则用来帮助组织去更好地达成目标，在委托方
和代理方内部进行更好的沟通，以及在组织和有兴趣的第三方之间的更好沟通，更好地示范了法定义务的履行，操作更有效
率，操作更好地自动化，在当前的实践中更好地执行分析，等等”2。业务规则可以被看作是业务实践的一个集合，定义实际的
实现——业务逻辑。这种逻辑的实现经常可以通过使用专门的工具进行简化——业务规则语言和业务规则引擎。
规则语言是一种特定于领域的语言，包含定义业务规则的构造。这些构造可以根据业务需求而大相径庭。从文本描述（使用一
种特定于规则的语言或者简单英语），到决策表或者决策树的使用，都有可能。在有些情况下，也可能以图形的形式确定使用
规则流的那些业务规则的执行顺序。最后一种经常是导致业务流程和业务规则之间产生混淆的原因。虽然它们看起来类似，但
是业务流程流定义的是可以跨许多不同且异构系统的服务的执行顺序。另一方面，业务规则流则受限于规则执行顺序的编制
（orchestration）。
特定于领域的编程语言
“特定于领域的编程语言（DSL）是一种对特定的任务组特别有用的编程语言。这是相对于通用编程语言（GPL）如C、
Java、C#等等而言的3。DSL一般专门针对特定的问题领域进行量身定做。因而它能精确地捕捉领域的语义。为了进一步简化
它们的用法，DSL一般是高度声明式的，并描述需要发生什么，而不是如何完成（后者是语言实现者的责任）。由于这一
点，DSL经常被当作（可执行的）规范，而不是编程语言。
特定的DSL的主要优点在于特定于领域的抽象和符号，以及有限制（或者相当集中）的表达功能。对于应用程序的有些类而
言，使得DSL比GPL更具吸引力的原因有几个4：
更容易编程
因为它使用了一个更高级别的抽象，与问题领域密切结合，定义要实现的内容，而不是如何实现，相比于GPL实现，DSL程序
一般来说更加精确（由于它与领域的密切结合），并且更容易实现和理解（不仅对于开发人员，对于领域专家们也是如此）。
这一般会致使缩短开发时间，减少昂贵的维护成本。此外，DSL还有高级的数据处理（debagging）支持，允许直接在领域概
念级别上分析和调试代码。
系统的重用
重用始终是改善新应用程序的实现和缩短开发周期的方法之一。虽然GPL通过使用标准的和特定于领域的库来促进重用，但是
它们的实际用法还是取决于开发人员。另一方面，DSL强制重用被DSL实现使用的库。此外，由于DSL是为特别的问题领域而
定义的，因此它们捕捉且因此重用特定的领域知识。
更容易验证
随着软件工程的发展，正规的代码验证在成功的开发中正扮演着重要的角色。而对GPL而言，这种验证仅仅确保代码会执行，
对于DSL而言，由于它们的简洁和领域结盟，验证经常可以确保代码将生成正确的结果。
增进合作
跨组织使用相同的业务相关的语义，促进了信息的共享，降低了业务逻辑的实际实现与业务用户的预期之间不符的风险。
业务规则引擎支持用相应的规则语言表达的规则的评估。它们的主要功能是管理事实的集合，并评估由几个断言之一组成的规
则组。处理大量的事实，并且有效地评估断言，这是规则评估的主要挑战之一。根据业务规则定义，用业务规则语言表达，业
务规则引擎一般提供一些映射机制来生成更低级别的执行代码——一般是通用的语言类。那些类可以用作一个更大业务组件的
部分实现。这种方法的一种直接的后果是，业务规则的实现生命周期与它们所属的业务组件的生命周期紧密地结合在一起。
业务规则实现的灵活性和可修改性，通过激活动态变化的规则维护支持而实现（使用初始的规则语言）。这种能力提供了一种
资源评论
