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

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