一种基于SOMA的服务建模方法研究*

汪　鹏　赵　恒　黄　伟

(武汉数字工程研究所　武汉　430205)



一种基于SOMA的服务建模方法研究*

汪鹏赵恒黄伟

(武汉数字工程研究所武汉430205)

摘要在分析SOMA思想的基础上，研究了一种基于SOMA的服务建模方法，通过形式化理论分析了服务建模过程中服务发现和设计建模的过程，结合模型驱动理论提出具体的方法实现服务从抽象模型到运行实体的转换，并根据方法实现服务设计建模工具，最后通过在海战场领域的一个建模实例验证方法的可行性。

关键词SOMA; 服务建模; 模型驱动理论

Class NumberTP391.9

1引言

面向服务的建模(Service Oriented Modeling，SOM)是SOA软件系统实现的重要手段。研究服务建模技术旨在通过建立一种可行的服务建模方法为SOA软件系统提供良好的解决方案[1]。

目前，IBM的SOMA[2]思想为业界面向服务的建模提供了方法论的指导[3]，文献[4]提出了一种全过程复用的服务建模方法，研究了服务本体系统等相关概念，提出了全过程复用过程中的具体算法，该方法着重于服务建模全过程中模型资产复用的研究。文献[5]研究了知识服务的建模方法，通过对知识服务的分析，从多个角度定义了知识服务的描述模型。该方法的重点在于服务的发现和规约上，并未对服务实现做具体的研究。而在文献[6,8～9]中，研究者将服务建模的模型与模型驱动体系(Model Driven Architecture，MDA)相结合，采用标准UML建模语言实现特定平台服务模型的创建与转换。

以上的研究从不同的方面研究了面向服务的建模方法，这些方法或是基于模型定义研究模型的复用，未体现服务实现过程；或是研究单个服务模型的规约，而缺少对建模过程中多个模型间关系的描述；又或是研究了特定平台下的服务建模方法，其依赖的软件环境在其他平台下无法完全满足，导致其可用性存在一定的不足。因而，在实际的SOA软件系统开发过程中，缺乏一种规范的、可遵循的服务建模方法来指导服务的建模开发过程。

针对以上问题，本文在SOMA方法论的指导下，通过形式化的理论对建模过程中模型的定义、模型之间的关系以及服务实现进行了研究，提出了一种基于SOMA的服务建模方法，以期为SOA软件系统的开发提供方法指导。

2基于SOMA的服务建模方法

SOMA方法论提出服务建模的三个过程：服务发现、服务规约以及服务实现。服务发现是通过一定手段获取服务候选目录的过程；服务规约过程定义了服务的细节，包括数据、约束、消息、事件定义等；服务实现过程则是根据服务规约的结果并结合实际环境进行服务的开发。

基于SOMA方法论，本文提出的服务建模方法，其过程如图1所示。

图1　服务建模过程

业务分析是服务发现的过程，通过对实际业务进行分析，提取业务中的参与人员(创建人员、过程执行人员)和具体事务节点。为了得到人员和具体事务节点的关系，对业务进行业务流程建模，产生的业务分析模型在整体上为业务流程化运行提供基础，而细化到具体的流程实现上，事务节点的细节分析则是服务设计建模的必要条件。

服务设计是服务规约的过程，通过对事务节点的细节进行分析提取，将具体事务抽象成对应的服务描述模型，并从数据模型和约束条件上满足具体事务的要求。

服务的构建与开发是服务实现的过程，抽象的服务描述模型经过构建和开发，形成可运行部署的服务运行实体，这样的过程涉及到描述模型中的数据模型到代码框架模型的转换以及基于框架模型的开发。

上述过程是SOMA方法论的具体化，用以指导从实际的业务到服务描述模型再到服务运行实体的转换实现。

2.1业务分析

业务分析作为建模的初始阶段，其核心是业务流程建模。经过业务分析节点，实际业务被转换成用一定的标准或语言符号描述的业务流程模型。业务分析阶段需要将一些业务所处的实际环境特性(如网络环境，安全因素等)考虑其中，具体到流程建模当中，则需要分析事物节点处理的时间要求、处理人员的身份认证，这就为进一步的服务分析阶段提供了一定的约束条件。

业务分析的结果就是事务节点的集合。事务节点包括了参与人员、事务、以及约束要求，可以用这样的三元组来表示：

其中，ProN表示事务节点，P表示参与人员People，E表示具体事件Event，R表示约束条件集，R=R′∪R″∪…∪R(n)。由于业务是多个事务节点的集合，用Task表示业务，其表达方式如下：

Task=RroN1∪ProN2∪…∪ProNm

由于业务是由事务节点按照一定的顺序构成，假设业务Task1是按照图2顺序执行。

图2　Task1事务节点流程图

箭头表示一个事务节点转到另一个事务节点。将业务Task1按照参与人员P进行划分，得到过程如图3。

图3　Task1业务泳道图

业务Task1的划分结果是多个独立的、顺序执行的二元组〈E,R〉，这个二元组是服务的实现基础。分析事件E提取事件的内容、所需的数据输入以及事件输出，抽象成包含这些信息的数据模型D，从而将服务定义成数据和约束的二元组：

通过业务分析阶段，一个具体的业务被分解成多个事务节点，进而可以分析提取出对应的服务模型，这样的过程为下一阶段的服务设计提供了输入。

2.2服务设计

根据2.1分析，服务定义为一个数据模型D和约束R的二元组，即服务是满足环境定义的数据模型和约束条件共同关系的结果。假设Dm是数据模型集，req是约束条件集，ref表示满足实际环境的要求，因此，服务是满足ref的Dm与req的笛卡尔积，其形式化描述为

service=σref(Dm×req)

对于一个数据模型D，2.1节分析了数据模型是方法Methods、输入输出Input/Output以及属性描述desc的三元组，Methods是方法的集合，表示为

Methods={mi|i∈(1,n),n∈Z}

Input是输入数据的集合，由于方法的输入量有多个，因此Input定义如下：

Input={it|t∈(0,k),k∈Z}

Output是输出数据，服务方法的输出只能是一个，所以定义Output如下：

Output={Os|s=1}

对于任意的一个方法mi，可以用如下的三元组来定义：

其中，Operation表示方法操作名，I是输入数据集合，I⊆Input，O是输出数据，O⊆Output。

约束条件是根据服务在实际环境中可能存在的限制和要求在模型层面定义的服务需求。按约束的属性来划分，包括了服务QoS约束和安全性约束等，QoS约束根据实际的环境分析(如限制的传输条件)，定义服务的延时约束，即在接收请求的一定时间内，服务需要做出应答的最长时间；安全性约束是考虑服务在安全性上的要求，限制未经安全认证的请求访问。

由此可得到服务模型的XML描述文件，如下：

〈service〉

〈properties〉

〈name value="Test "/〉

〈id value="ID_Test"/〉

……

〈nodeIP value="127.0.0.1"/〉

〈serviceURL value="http://127.0.0.1:10000"/〉

……

〈bundleList〉……〈/bundleList〉

〈description value="description of service"/〉

……

〈/properties〉

〈interfaces〉

〈inter interDescription="interface description"

interName="send"〉

〈returnValue description="method description"

type="int"

unit="NULL"/〉

〈qos delay="1"

description="timedelay"

unit="ms"/〉

……

〈args〉

〈arg description="arg0" ioflag="input"

name="arg0" type="String"

…/〉

……

〈/args〉

〈/inter〉

……

〈/interfaces〉

〈/service〉

2.3服务构建与开发

服务构建与开发是在服务描述模型的基础上，将描述定义结构通过技术手段转变成实际服务运行实体的过程，本质上是系统无关模型PIM到平台相关模型PSM再到实现模型ISM的转换[10]，这是一个“灰盒”过程[11]，如图4所示。

图4　服务模型转换过程

图中，模型转换的核心是转换规则和相应的代码生成工具，服务描述模型作为PIM，经过转换过程proc1，转换成PSM，PSM经过代码生成引擎转换成ISM，其中proc1的状态过程如图5所示。

图5proc1状态过程

其中，状态0→1的转换条件是读取服务的描述desc，desc包括服务名称等信息；

状态1→2的转换条件是读取服务的方法m0；

由于服务的方法有多个，因此：

状态2→2的转换条件读取服务的方法mi；

状态2→3的转换条件是方法读取完毕。

对于状态2，细化其状态过程如图6所示。

图6　过程2的状态细节

2-0→2-1，读取方法的输出O；

2-1→2-2，读取方法的操作名Operation；

2-2→2-3，读取方法的输入I1；

由于一个方法的输入有多个，因此：

2-3→2-3，读取方法的输入Ii；

2-3→2-4，输入读取完毕。

根据以上的状态过程，本文设计的模型代码转换流程如图7所示。

图7　模型代码转换流程图

在实际的研究过程中，对图7的模型转换过程进行了完整的封装，并结合服务设计过程，实现一个服务设计建模工具，工具隐藏了中间的细节，使用者无需知道中间的转换规则以及转换过程，这在很大程度上提高了实际服务建模过程的便捷性。

在得到的服务代码框架的基础上，进行服务具体方法接口的开发是得到服务运行实体的重要步骤。根据设定的平台属性和定义的输入输出，将输入数据进行适当的数据处理，使之满足接口方法的功能需求，并将结果传递给输出载体。

服务的构建与开发对服务设计阶段的输出模型进行细节上的分解与分析，经过模型代码转换过程以及服务方法接口开发，得到实际可运行的服务实体。

3实验验证

本文以海战场领域的护航方案创建业务作为应用实例来验证本文研究的建模方法。通过业务分析过程，得到护航方案创建业务中参与的人员People、对应的事务节点Event以及相互之间联系，其中参与人员包括：岸基指挥官P1、编队指挥官P2、编队对海指挥官P3以及舰长P4，对应的事务节点有护航业务下达，护航方案制定，护航方案审核，护航方案修改等。通过业务分析阶段，得到护航方案筹建业务的业务流程模型如图8所示。

图8　业务流程分析模型

编队对海指挥官P3的事务“制定护航方案并提交”进行分析设计，得到数据模型Dm如表1所示。

表1　服务数据模型

该服务的约束req主要是QoS约束，即每个方法的最大处理时间，该约束主要考虑在服务开发过程中。

当服务的数据模型和约束条件确定后，可利用服务设计建模工具进行服务的构建和开发，将服务信息输入到服务设计建模工具中，得到服务模型，如图9所示。

图9　服务设计建模工具构建服务

利用服务设计建模工具可得到2.2节描述的服务XML描述模型，利用工具提供的模型转换功能输出服务的代码框架，经过服务具体功能开发阶段，得到服务运行实体，实现服务的开发运行，得到如下所示服务WSDL描述：

〈definitions name=”ConvoyServer” targetNamespace=”urn:ConvoyServer”……〉〈types〉〈/types〉

〈message name="AddConvoyInfoRequest"〉

〈part name="arg0" type="xsd:base64Binary"/〉〈/message〉

〈message name="AddConvoyInfoResponse"〉

〈part name="response" type="xsd:int"/〉〈/message〉

……

〈portType name="ConvoyServerPortType"〉

〈operation name="AddConvoyInfo"〉

〈documentation〉Service definition of function

ns_AddConvoyInfo〈/documentation〉

〈input message="tns:AddConvoyInfoRequest"/〉

〈output message="tns:AddConvoyInfoResponse"/〉

〈/operation〉

……

〈/definitions〉

上述描述仅显示了AddConvoyInfo方法，包含了该方法的operation，input，output等信息，并定义了输入输出的数据格式。

将本文研究的方法与其他文献中提出的建模方法进行比较，可得到如表2比较结果。

表2　服务建模方法比较

根据以上的表格分析，本文研究的建模方法在形式化分析(Formal Analysis)、模型间关系(Model Relation)、模型转换(Model Transformation)以及通用性(Commonality)均作了相应的分析和考虑，但是在模型的复用上(Model Reuse)需要做进一步研究。

4结语

本文提出一种基于SOMA的服务建模方法，从业务出发，采用模型驱动的理论系统地阐述了服务建模的各个阶段，完整地分析各个阶段之间相互的联系。根据形式化的理论推导结合实际的模型开发了服务设计建模工具，最后通过实例验证了方法的有效性与可行性。

本文研究的是从业务分析到服务实现的过程，下一步的研究则是如何从服务回到业务，这部分内容包含基于业务的服务编排以及服务的集成与运维，并将本文的研究内容与下一步的工作结合起来，从而形成一个完整的服务化建模方法。

参 考 文 献

[1] 毛新生.SOA:原理.方法.实践[M].北京:电子工业出版社,2007:53-62.

MAO Xinsheng. SOA: Principle. Method. Practice[M]. Beijing: Publishing House of Electronics Industry,2007:53-62.

[2] Ali Arsanjani. Service-Oriented Modeling and Architecture[C]//IEEE International Conference on Service Computing,2004:521.

[3] 金戈,姚辉,赵勇.SOA快速指南123[EB/OL].(200612-26).http://www.ibm.com/developerworks/cn/webservices/06-10_jinge/index1.html.

JIN Ge, YAO Hui, ZHAO Yong. SOA Quick Guide 123 [EB/OL]. (2006-12-26).

[4] 吴布丹,金芝,赵彬.面向服务的建模:一种全过程复用的方法[J].计算机学报,2008,31(8):1294-1308.

WU Budan, JIN Zhi, ZHAO Bin. Service-Oriented Modeling Based on Whole Process Asset Reuse[J]. Chinese Journal of Computers,2008,31(8):1294-1308.

[5] 任彦，柏小莉，郭得科，等.面向任务的知识服务描述模型及体系结构[J].计算机科学,2006,33(10):291-294.

REN Yan, BAI Xiaoli, GUO Deke, et al. Task Oriented Knowledge Service Model and Architecture[J]. Computer Science,2006,33(10):291-294.

[6] OMG. Model Driven Architecture (MDA): The MDA Guide Rev2.0[EB/OL]. [2014-06]. www.omg.org/cgi-bin/doc?ormsc/14-06-01.pdf

[7] OMG. Unified Modeling LanguageTM(UML)[EB/OL]. [2005-07]. http://www.omg.org/spec/UML/2.0

[8] José Luis Herrero Agustin, Pablo Carmona del Barco: A model-driven approach to develop high performance web applications[J]. The Journal of Systems and Software,2013,86:3013-3023.

[9] Kwanghoon Kim. A model-driven workflow fragmentation framework for collaborative workflow architectures and systems[J]. Journal of Network and Computer Applications,2012,35:97-110.

[10] IBM. An introduction to Model-Driven Architecture(MDA)[EB/OL]. [2005].http://www.ibm.com/developerworks/rational/library/apr05/brown/.

[11] 宋莉莉,王维平,李群.基于SOA和MDA的模型重用和组合技术研究[J].系统仿真学报,2009,21(13):3969-3974.

SONG Lili, WANG Weipin, LI Qun. Model Reuse and Composition based on SOA and MDA[J]. Journal of System Simulation,2009,21(13):3969-3974.

收稿日期:2016年1月9日,修回日期:2016年2月20日

作者简介:汪鹏，男，硕士研究生，研究方向：服务化，软件构件。赵恒，女，博士，研究员，研究方向：分布式计算、软件工程。黄伟，男，高级工程师，研究方向：服务化，软件工程。

中图分类号TP391.9

DOI:10.3969/j.issn.1672-9722.2016.07.027

Service Modeling Method Based on SOMA

WANG PengZHAO HengHUANG Wei

(Wuhan Digital Engineering Institute, Wuhan430205)

AbstractBased on the analysis of SOMA theory, the paper studies a service modeling based on SOMA, which analyses the procedure of service discovery and service design-modeling through the formal theory, also presents a specific method to implement the transformation from service abstract model to service instance with combining the Model Driven Architecture, additionally develops a service tool with the method. The paper also demonstrates the correctness of the modeling method with a case on naval battle field.

Key WordsSOMA, service modeling, model driven architecture