让 SOA 更快速适应用户需求变化

绪论

面向服务的架构（Service Oriented Architecture, SOA）为软件复用提供了良好的基础环境，平台无关的规约和松耦合的交互方式使服务成为良好的复用单元，而服务的编排组装机制更为软件构造和应对需求变化提供了强大的支持。

在软件企业为其客户分析其需求时，往往采用一种类似于树状结构的形式对其需求进行自上而下的分解，这种自顶而下、逐步划分的需求组织形式非常符合人的直观，能较好的提高客户在需求建模时的参与度。

然而，这种以树状结构组织的需求形式上与最终的运行态系统——服务流程在形式上具有很大的不同，而这种展现形式上的不同可能造成客户对最终系统实现的理解上产生偏差；同时，在客户需求发生变化时，如果将需求的变化很好反映到流程的变化上，也是一个较为棘手的问题。

Diva 项目的初衷就在于能够帮助 SOA 系统在需求描述与实现上建立其映射关系——在需求发生变化时，这种变化能立即反应到流程上。Diva 使用特征模型（一种以树状结构的需求组织形式）描述需求，并建立了特征模型和 SOA 设计模型之间的关联关系，从而需求的定制能直接转化具体的设计模型。

我们在 Diva 项目中提出的方法和工具，应用于一个虚拟企业——凤凰公司的整合项目中。通过根据系统需求对特征模型进行建模，并且建立特征模型与服务模型和 BPEL 规约之间的关联，对系统的流程变化性进行管理。

文档的其它部分按如下组织：第 2 节介绍一个展示性的例子，用于展示使用 Diva 能够对流程进行按需定制；第 3 节介绍 Diva 方法，并围绕第二节的例子介绍 Diva 是对变化性支持的原理；第 4 节介绍了使用 Diva 方法和工具在凤凰公司整合项目中应用；第 5 节是总结全文。

例子

这一节将以一个例子来介绍 Diva 对于需求模型和流程之间映射的支持。在本文中的后续章节中，将围绕这个例子具体介绍开发人员如何利用 Diva 定制需求模型和流程之间的映射关系，以及 Diva 具体实现的核心技术。

假设的一个需求是需要对企业种存在的两个系统，例如 ERP 系统和 CRM 种的产品和订单数据进行同步。图 1 左边是根据业务人员定义出来的需求模型，它使用特征模型进行描述。

业务人员经过研究，认为需要为产品和订单两类信息提供两种不同的同步方式：反映到图中，就是“同步产品信息”和“同步订单信息”这两个可选的子特征。同时，从时间角度，系统又需要多个触发数据同步的特征。因此，根节点还包括一个“同步触发”的子特征，这个子特征又包括两个可选的子特征，分别是“固定时间间隔更新”和“请求触发”。与此同时，根据业务人员总结出来的特征模型，可以相应的设计出可运行的服务流程模版，如下图右部所示。

图 1：特征模型与 BPEl 模版

Diva 可以帮助开发人员定义特征模型与流程模型之间的映射规则——这些规则可以被 Diva 工具进行解释。然后，用户就可以根据其实际的需求来定制所需要的服务流程。如果用户选择了数据同步中的使用固定间隔触发来更新产品信息，那么根据模版中定义的特征模型与 BPEL 模型之间的映射关系，将为其定制得到下图右部的 BPEL 流程。

图 2：定制结果
 

Diva 方法

Diva 方法概述

Diva 方法立足于建立需求模型与运行模型之间的映射关系，支持根据不同需求来定制服务的流程。Diva 方法的概览如图 3 所示。其中需求使用特征模型进行描述；流程则使用 BPEL 描述的服务流程作为目标模型，是可执行的。在此基础上，为了使用户更好地理解需求与流程之间的对应关系，增加描述业务流程的 BPM 作为辅助视图，使得定制更直观。

从图中可以看到，特征模型与 BPEL 和 BPM 都有着导出关系，也就是通过特征模型的裁剪，可以将其变化反映到 BPEL 和 BPM 两者上。在这里我们使用模板的方法，定义领域的特征模型，以及对应的 BPEL 和 BPM 的模板。通过建立特征模型与 BPEL、BPM 模板之间的映射关系，建立需求模型与运行模型之间的关联关系。这样，对于业务需求的变化，用户只需要修改对应的特征模型，而相应地，通过特征模型与 BPEL 模版之间的关联，将变化传递到服务流程层，得到变化之后的可运行的 BPEL 文件；通过特征模型与 BPM 模版之间的关联，将变化传递到业务层，提供可视化的流程视图。

图 3：Diva 概览

在这个过程中，BPEL 和 BPM 之间，BPEL 和 BPM 对特征模型也存在着反馈作用。在 BPEL 和 BPM 的定义过程中，可能会也对需求模型进行精化。这使得特征模型、BPEL 和 BPM 模版以及它们之间的映射关系的定义过程是一个迭代的过程。

以下我们分别介绍如何按照 Diva 方建立特征模型与 BPM/BPEL 模型之间映射的过程。对于 Diva 而言，建立特征模型与 BPM 或 BPEL 之间的映射的过程完全相同，因此下文将以 BPEL 为例，描述 Diva 的核心思想和方法。

BPEL 中变化性描述

Diva 方法的基础，就是需要建立特征模型与目标模型（Diva 工具针对的目标模型是 BPEL 文件）之间的映射。建立这样的映射，需要在 BPEL 文件中定义其可变化的地方（比如活动的增加 / 减少等），本节主要阐述 Diva 方法中如何描述 BPEL 文件中的可变之处。

BPEL 使用 XML 来存储，所以其变化性实际体现为 XML 文件的变化性，我们引入 XVCL（XML-based Variant Configuration Language）语言 [WONG01] 来管理这种变化性，一个用 XVCL 命令组织的文档称为一个 X-Frame，可以用来定义一段流程。表 1 列出了一些重要的 XVCL 命令，Diva 中也只使用到了这些命令。

表 1：主要的 XVCL 命令

XVCL 命令	描述
	标记一个 X-Frame.
	声明全局变量及其赋值
	标记 XVCL 配置命令发挥作用的区域
Customization commands	将一个 X-Frame. 用配置命令配置后拷贝到这里
INSERT-AFTER >	允许在断点（breakpoint）处加入内容，可以加在断点前或断点后，也可以取代断点处的内容
	定义 X-Fram 中的一个断点
	声明一个 XVCL 变量及其值
	标记一个 XVCL 变量
	基于变量的值选择配置项

图 4 是一个将 BPEL 模板表示为用 XVCL 包装的 XML 文件的例子（考虑篇幅原因，这里给出的 BPEL 文件是经过简化处理的），它包括 3 个 X-Frame. 文件，这个 BPEL 模板其实就是上一小节图 1 中右部 BPEL 模板的 XML 规约，图中蓝色加粗字体为 XVCL 标记。

图 4：用 XVCL 包装的 BPEL 模板示例

建立特征模型与 BPEL 模板之间的关联

要建立特征模型与 BPLE 模板之间的关联，需要建立两者之间变化相互影响的规则。对于特征模型的变化记录比较简单：每一个节点对应一个特定的 ID，当用户对特征模型进行定制时，只需记录特征模型中所有的节点在定制后是否还存在于模型中。

对 BPEL 模板中的变化性的描述相对复杂。我们需要对上节中的 XVCL 的描述机制进行扩展以更好的支持变化性映射。上节中 BPEL 模版的概念借鉴了 C++ 等编程语言中“template”的概念，可通过给定不同的参数生成不同的模型实例。那么变化性的描述，也就是模型模版中的参数。由于模版中已经对所有可能的变化性进行了描述，所以在实例化时，只需要判别这些变化点是否要在实例中存在。在其变化性描述中，我们支持以下两个属性：

• PC（presence condition）：标识一个模型元素是否应该存在；
• ME（meta-expressing）：用来计算模型元素的属性，包括名和值。

简单的 PC 和 ME 用特征来表达就可以了，复杂的 PC 和 ME 可以采用 X-Path 来表示。

由于 PC/ME 的定义与标准 XVCL 的标签上有一定冗余，因此在 Diva 中规定，容器和流程本身的 PC 使用 XVCL 中的 SELECT 与 OPTION tag 来标记，而其它元素的 PC 用 BREAK 和 COPY&INSERT tag 来标记；而 ME 则通过定义变量和规定变量的赋值来实现。

按照前文所述，PC 定义被分成两类。第一类定义了模板中的 SELECT 标签与 PC 的对应关系：即，当特征模型中一个节点被选中时，它会为变量以怎样的赋值。表 2 给出了一个例子。根据这样的赋值，SELECT 标签可以选定下面哪一个分支将会被选中。

表 2：流程本身和容器类元素的 PC 定义

SELECT 名	PC 为 true 时的赋值	Presence Condition (PC)
DATASYN	NEED_DATASYN	数据同步
LONGRUN	REALTIME_REPETCHECK	固定时间间隔更新

第二类定义了当模板中的断点标签与 PC 的对应关系：即，当特征模型中一个节点被选中时，它会为 BPEL 文件导入哪一个 X-Frame. 文件。表 3 给出了一个例子。

表 3：其它结构元素的 PC 定义

断点	Presence Condition (PC)	应导入的 X-Frame. 文件
WAIT_POINT	固定时间间隔更新	waitPoint.xml
REQUEST_REPLY	请求触发	synReply.xml

同理，ME 表示例子如表 4.

表 4：ME 表示

序号	变量名	Meta-Expression (ME)
1	processName	dataType+”_”+”SynProcess”
2	watiTime	“H”+ 固定时间间隔更新 . interval_time
备注	为了方便这里的表达，定义一个临时字符串变量：dataType 当特征“同步订单信息”被绑定时，dataType=”order”； 当特征“同步产品信息”被绑定时，dataType=”product”； ME 栏表达式按照 Java 中的字符串操作规则

通过定义 PC 和 ME，就建立了特征模型和 BPEL 模板的关联，当特征模型被剪裁后，便可以根据相应的 PC 和 ME，生成一个配置脚本。图 5 是仅选择了“同步产品信息”和“请求触发”两个可选特征后的配置脚本。

图 5：XVCL 配置脚本示例

根据配置脚本生成 BPEL

根据配置脚本中的定制要求，可以自动解析去对相应的 X-Frame. 文件进行操作，来得到实例化的 BPEL。图 6 是根据前面图 5 所给配置脚本得到的实例 BPEL。在 Diva 工具中，已有自动化支持。

图 6：BPEL 实例化示例

案例分析

本章将使用一个案例，讲述 Diva 方法以及支持工具在一个虚拟企业——凤凰公司的业务整合项目中如何帮助其建立需求模型与流程模型之间的定制关系。本章先对 Diva 方法的支持工具进行简要的介绍，之后介绍项目需求，根据项目需求的领域知识，建立特征模型、BPM 模版和 BPEL 模版，之后使用 Diva 工具对其进行定制而获得整合所需要的业务流程。

工具介绍

Diva 的支持工具已经被实现为一个 Eclipse 插件，其界面如下图所示。

图 7：Diva 工具界面

在 Diva 工具中，有两个最主要的视图：

特征模型视图 (Feature Model View)：用于对描述需求的特征模型进行建模和编辑，以及通过对特征模型的定制，来获得目标的 BPEL。这个视图将特征模型组织成树状模型，使用如下的元模型进行建模。

图 8：特征模型元模型

业务流程视图 (BPM View)：这个视图展示根据需求定制得到业务流程，是通过扩展 JBoss 的业务流程建模工具 jBPM 的流程节点的显示方式得到的。

另外还有一些辅助性视图，包括用于展示项目中已有的业务流程视图（BPM 列表视图），用于展示特征模型属性的视图（属性视图），以及 BPM 定制结果的价格显示（价格视图）。除此之外，在支持流程定制的过程中，用户还可以使用 BPEL 的编辑工具和 BPM 建模的可视化工具 jBPM 来辅助设计。这些工具都有基于 Eclipse 插件的实现，可以很好地与 Diva 工具一起使用。

系统需求

凤凰医疗设备有限公司是一家专门制造和营销专业医疗器械和实验仪器仪表等仪器的民营企业，其购销客户和网络遍布全国各地。在企业内部管理，凤凰公司使用 ERP 系统进行产品库存及订单管理，而外部销售人员使用 CRM 系统进行客户管理。

但是由于 ERP 系统和 CRM 系统中分别维护着产品和客户信息，以 ERP 系统中的数据作为主数据源，而 CRM 系统中的商业机会（Lead）等，和订单数据的有着密切的关系。所以需要这两个系统进行整合，以使得两个系统之间能够实现数据的同步，以及在两个系统之间通过流程的集成，完成订单信息提交和审批流程的集成。

特征模型，BPM 和 BPEL 模版的定义

根据凤凰公司 CRM 和 ERP 的整合的需求以及相关的领域知识，领域专家首先对这个项目定义其相关的特征模型。下图是领域模型的图形化实例。

图 9：凤凰公司整合项目的特征模型

根据定义出来的特征模型，接下来需要定义实现这些需求所需的业务流程模型 BPM 和 BPEL 语言描述的流程。最后，建立这些流程与特征模型之间的对应关系，获得可用于定制的 BPM 和 BPEL 模版。建立对应关系的例子可以参见第三节。

其中，特征模型使用 Diva 工具支持的元模型描述，BPM 模版和 BPEL 模版分别使用 jBPM 和 BPEL 语言描述。

流程定制

获得上一步的特征模型和两种模版之后，就可以使用 Diva 工具来进行流程定制。

在工具中打开特征模型，可以看到如图 10 所示。在左边的特征模型中，特征的状态包括两种，一种是默认已选的，使用图标标识，这些特征不可缺少的；另外一种还未决定是否选择的，使用图标标识，这些特征可以由用户决定是否选择。在此基础上，还包括特征模型中的约束，使用图标标识。约束中包含一个或者多个属性，属性使用图标描述。

右边展示的业务流程视图，是在用户还没进行定制的情况下，默认生成的业务流程。业务流程与左边的特征模型对应，其通过将特征模型中状态未定的特征，默认为不选择，来生成 BPM。

图 10：定制界面

用户根据需求，对于特征模型中的特征，可以进行三种操作：包括绑定（Bind），删除（Delete）以及待定（Undecide）。用户可以通过右键点击对应的特征，来对其进行操作，如图 11 所示。其中，绑定与删除决定对应的特征是否是所需的。而待定则是表示对应的特征还没有决定是否会包含在用户需求中。

图 11：特征的操作

在定制的过程中，特征模型和对应的 BPM 视图都会根据定制结果的不同显示相应的模型。如图 12 所示，在对特征进行绑定（Bind）和删除（Delete）操作之后，对应的特征模型有了不同。绑定了的特征，使用图标进行标示，而删除掉的特征，使用图标进行标示。同时，在 BPM 视图中也实时生成相应的流程，包括状态和流程图两种，用户可以在这些可视化而易于理解的流程的基础上进行讨论，决定最后所需要的流程。

图 12：定制中的界面

Diva 根据特征之间的关系，为用户在定制过程中提供一些自动化的帮助。例如：如果特征 A 依赖于特征 B，那么当用户绑定特征 A 时，相应地特征 B 也应该被绑定。Diva 对特征之间的这些规则提供了自动化的支持。在例子中，由于系统中的监控只能通过记录日志来实现，因此特征“order monitor”的实现依赖于特征“log service”。对应地，当用户在 Diva 中绑定了特征“order monitor”，其结果如图 13 所示，其依赖的特征也同时被绑定，并且对这两个特征都使用焦点加颜色提醒用户注意。

图 13：根据特征之间的关系协助用户的定制

用户定制的过程中，工具也根据特征之间的关系，来检查可能存在的冲突。当监测到冲突时，Diva 工具会弹出对话框列出冲突列表来提示用户，如图 14 所示，并且提供默认的自动冲突解决方案。

图 14：冲突检查

而在此基础上，用户也可以根据其定义的约束来对系统进行检查。如图 15 所示，用户首先单击右键选择“Validate”。

图 15：模型约束检查

经过检查之后，工具反馈检查的结果。如图 16 所示，当发现约束没有满足，则提示用户进行解决。由于这些约束是用户定义的，并且通常是特定应用的，所以可以看到，工具无法对其提供自动解决的方案，只能提示出错的地方，由用户自行更正。

图 16：约束检查

生成流程

用户完成定制之后，通过 BPM 视图确认对应的流程是否是自己所需要的。如果确认之后，就可以生成对应的 BPEL 流程了。如图，在完成定制的同时，将在 PROJECT_DIR\BPEL 目录下生成的 BPEL 实例。

图 17：生成定制后的 BPEL 实例
 

总结

Diva 方法在 SOA 系统的需求描述与实现上建立其映射关系，使得需求发生变化时，这种变化能很快的反映到流程上。Diva 使用特征模型（一种以树状结构的需求组织形式）描述需求，并建立了特征模型和 SOA 设计模型之间的关联关系，从而需求的定制能直接转化具体的设计模型。

Diva 工具对 Diva 方法提供了有力的支持。在需求以及需求变化的描述上，为用户提供了易于理解的层次化特征模型，并利用特征模型中元素和元素之间的（依赖、精化、约束等）关系来增强对变化性描述的能力。用户可以使用 Diva 工具进行建模和定制，工具也提供了部分自动化的验证能力。在此基础上，Diva 工具还提供了可视化的定制模式，在进行定制时能够直接看到相应的业务流程模型（BPM），使用户对需求所对应的实际系统有一个直观的了解。Diva 工具还提供了模型映射与自动实例化的能力，使得根据需求模型中的变化可以得到对应的可执行服务流程。

在凤凰公司的整合案例中，我们可以看到，根据系统需求建立其对应的特征模型、BPM 和 BPEL 模版之后，Diva 工具就可以很好支持用户在需求变化时自动生成对应的的流程。这种自动化同步映射的机制，对于需求快速变化的现代企业，能很好的缩短开发所需的时间。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780828/viewspace-584494/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14780828/viewspace-584494/