基于MDA的SOA服务协作模型
MDA与云计算_SOA的比较研究

具有垄断地位的软件服务商为主导的信息技术。 云计算的“云”就是存在于互联网的服务器集群上的服 务
器资源,包括硬件资源(如服务器、存储器和处理器等)和 软 件 资源(如应用软件、集 成 开 发 环 境 等)。 每 个 提 供 云 计 算 服 务 的公司,其服务器资源分布在世界上相对集中的、少量的几 个 地方,对资源基本采 用 集 中 式 的 存 放 管 理。 云 计 算 给 需 要 各 种服务的终端提供 支 持,如 同 用 电、用 水 一 样,可 以 随 时 随 地 获取计算、存储等信息服务[1]。而从经济而言,云计算效 用 明 显:“云”可 以 帮 助 企 业 IT 中 心 节 约 大 至 80% 的 使 用 面 积、 60%的电源和制冷消耗,达至原有设施的3倍利用率,使 得 现 有的资源更 加 经 济 高 效[2]。 云 计 算 不 仅 有 以 上 所 列 举 的 好 处,因为在“云”的另一端,有全世界最专业的团队来帮你 管 理
· 207 ·
用[3]。即使有人担心存在风 险,美 国 公 司 Gartner于 2008 年 发布的关于“云”计算安全风险分析也指出云计算中存在的 安 全风险包括特权管理、数据位置、数据隔离、数据恢复、审 计 与 法律调查、服务延续性等[4],即云计算的安全风险仅存在于 使 用中的数据安全上,也就意味着云计算机是可以使用的,只 要 采取措施规避以上风险即可。
SOA应用系统总体框架及相关概念

SOA应用系统总体框架及相关概念■ 庞引明看到SOA的一堆名词,读者可能会感到迷惑,有必要结合实际的应用环境进一步阐释SOA的相关概念。
总体框架图1所示的就是一个SOA应用系统的大体框架结构。
它大体上可以分为五个部分:● 展现层(presentation):图1中5区,通过portal等技术建立展现平台,方便用户在这个界面上提出服务请求。
● 业务处理建模(business process modeling):图1中的4区,SOA元模型从MDA中继承了平台无关模型来对业务处理过程建模。
这一部分独立于服务设计和部署层。
模型驱动架构MDA(Model Driven Architecture)的主要缺陷是在模型设计阶段就对需求有完整的描述,而且没有需求变更的反馈机制。
SOA通过添加敏捷方法AM来应对需求变更的情况。
● 服务层(Services): 图1中的3区,整个SOA的核心层,它承上启下,对上响应业务模型,对下调用相关组件群完成业务需求,形成“业务驱动服务、服务驱动技术”的SOA事务处理格局。
服务可以根据粒度分层。
虽然细粒度提供了更多的灵活性,但同时也意味着交互的模式可能更为复杂。
粗粒度降低了交互复杂性,但敏捷性却下降。
● 企业组件层(enterprise components):图1中的2区,这里是相关组件发挥作用的场所。
这些组件是平台相关的。
因为到了这一层,许多底层软硬件平台的特性已经不再透明了。
● 系统软件层(Operational System):图1中的1区,这一层包括操作系统、数据库管理系统、CRM、ERP、商业智能(BI)等异构系统,是一个集成的平台。
除此之外,诸如QoS、安全性等(图1中7区)也是SOA架构的组成部分。
在上面的介绍中,自上而下有一条线,如图2所示,由业务建模开始,通过定义业务过程,得到服务模型,它是平台无关的,实现了模型与实现的分离。
再通过设计组件群,得到平台相关的组件模型。
基于SOA的数据协同模型

—261—基于SOA 的数据协同模型易峥荣,卜 炜,葛序风,刘颖娜(华东计算技术研究所,上海 200233)摘 要:传统的企业信息集成采用的是功能驱动的方法,主要用于解决企业数据的分布性与异构等问题,它们通常都忽略了业务逻辑而直接进入到企业业务集成的层次。
然而不在数据集成的层次中响应企业业务流程的处理要求,就会直接限制系统的数据处理能力。
该文基于用户的业务逻辑,通过事件驱动数据在不同组织或系统间流动来实现数据的集成。
这是一种松耦合的数据集成模式,用户通过协同不同系统提供的能力来控制系统的集成行为及数据转换规则,适用于数据共享需求变更频繁的应用集成系统。
关键词:Web 服务;ECA 规则;计算机支持的协同工作Data Cooperative Model Based on Service-oriented-architectureYI Zheng-rong, BU Wei, GE Xu-feng, LIU Ying-na(East China Institute of Computer Technology, Shanghai 200233)【Abstract 】The traditional enterprise information integration is driven by function, which mainly solves the distributed and heterogeneous data integration problems, but without the consideration of the business logic, stepping strictly into the business integration level. If no actions are taken at the data integration level to response the enterprise business work flow, it restricts the system ability of sharing data. This paper provides a data cooperative model which is based on business logic of enterprise. It invokes the event which drives data flowing between different organizations. It is a loose coupling model and gives customer the ability to change functions and data transform rules. The system which changes a lot will benefit from the model.【Key words 】Web service; ECA role; computer supported cooperative work计 算 机 工 程 Computer Engineering 第35卷 第4期Vol.35 No.4 2009年2月February 2009·开发研究与设计技术· 文章编号:1000—3428(2009)04—0261—04文献标识码:A中图分类号:TP3151 概述近年来,随着企业逐步实现职能优化,企业的资金流、物流和生产效率都得到提高。
面向服务架构中的服务交互模型研究

面向服务架构中的服务交互模型研究一、前言面向服务架构(SOA)已经成为现代企业应用的架构模式之一。
SOA可以将企业内的各种业务功能和信息资源通过服务的方式进行组装,从而形成为合理的业务化的服务体系。
因此,SOA中借助服务组合的方式进行信息交互和业务处理变得至关重要。
而服务交互模型是SOA中最核心的研究内容之一。
二、服务交互模型介绍服务交互模型是SOA中服务实现的一种方式。
从机理上看,它是基于远程调用或者消息传输的。
SOA中,服务交互模型是指业务提供方和调用方之间以消息为媒介,通过一些特定的交互协议来完成交互操作的过程。
因此,服务交互模型的研究重点就是业务提供方和调用方之间的消息交互过程。
三、服务交互模型的分类基于服务交互模型的实现方式不同,可以将服务交互模型分为两种:一种是同步模型,即客户端发送请求后一直等待服务端的响应,此时客户端的线程会被锁定,无法进行其他操作;另一种是异步模型,即发送请求后,客户端可以继续执行其他的任务,同时服务端发送完成响应后通知客户端进行后续处理。
这两种服务交互模型的基本实现机制如下:1.同步模型同步模型通过线程锁定机制保证调用者和服务提供者的消息同步。
在同步模型中,调用者发送消息后一直等待响应,将服务提供者的响应结果返回后,调用者才能结束其发送请求的操作。
同步模型的缺点在于不能高效地利用系统的资源,因为在等待结果时,客户端的进程会长时间被锁定,视线未来引起其他服务请求的阻塞等问题。
2.异步模型异步模型通过消息发送与回调机制实现消息传递。
在异步模型中,调用者向服务提供者发送请求,然后可以继续处理其他任务,服务提供者完成任务后通过回调机制通知调用者。
该模型能够高效运用系统的资源,因为在等待结果时,客户端得以继续执行其他的任务,比同步模型提供了更好的性能和灵活性。
四、服务交互模型的技术实现1.同步模型的技术实现在同步模型中,调用者向服务提供者作请求,发送请求后会暂停执行,等待服务提供者响应结果后继续执行调度服务。
基于MDA的工作流建模框架

层 的功 能 更 见 清 晰 ,它 描 述 了这 些 类 的实
基于
基于
的工作流建模 实现
的工作流的建模框架是一个包括了模 型的 个
业在这一实现上为我们提供了有益的尝试 ,值得我们进行进一 步的研究和完善 。
参 考文献 川 记
,
不 同层 次 间 映射 以及模 型 与模 型 不 同层 次 之 间 的映射 技 术所 构成的模型到模型转换的体系结构 。 型的 模 射。 模型的 个不同层次间映 射是指 模 型 的元一 模 型层 到元模 型层 , 再 到模 型层 之 间的 映 元 个不同层次间的映射技术 ,构成模型的上层模型 由映射 的变动可以转换成多个不同的下层模型 。 模 型到 模 型 的转 换 即 由 到 、 从 到代码等 个 阶段 的模 型转换 。 以 ,又 把模 型转 换分 为模 型到 模 型的 转 所 换和模型到代码的转换 。 不过可以为 目标编程语言提供一个元 模型 ,这样模型到代码的转换可以看作是模型到模 型的转换的 特例 。 的工作流的建模的实现 ,要解决的问题 中 ,最重要 的部分就是各个步骤对应的模型与模 型之间转换的不同层次 模 型 的映 射 图 。
软 件 导 刊
冷年
的模型元素相一致 。 元素构成的基础 。 其次 ,基于
元素也是定义
元模型
象语法表示转换规则 ,这样所描述的转换规则就具有语义上的 约束 ,含义也很清楚 ,更容易达到模型 自动转换 的目标 ,从而使 得这 些模 型转 换得 到保 证 。 是由 提 出的由平台无关模型到平台相关模 型 的 自动化 的架构 。 若存在一些构建 良好的建模平台模型就比较 理想 ,但是 目前尚无成熟的基础来指定这些模型间的转换 。在 这样 的环境 下 ,基于 工作 要 做 。 的工 作流 建模 的模 型转 换有 更 多 的
MDA模型驱动架构

MDA模型驱动架构MDA(Model-Driven Architecture)是一种软件开发的方法或者框架,它将系统开发的焦点从代码编写转移到了模型的创建和转换上。
MDA的核心思想是将系统的抽象描述转换为具体实现代码的过程自动化,并且强调在不同开发阶段中的模型转换和模型分析。
在MDA中,开发者首先创建CIM,它是对问题域进行抽象,以便更好地理解和定义系统需求。
这个模型与具体实现无关,它只关注问题域的概念和规则。
接下来,开发者使用模型转换器将CIM转换为PIM。
PIM是CIM的具体实现,通常用于描述系统的功能、业务流程等。
PIM与实际的技术和平台无关,因此可以用于多个平台上的开发。
最后,开发者使用另一个模型转换器将PIM转换为PSM,PSM是与特定平台相关的模型,它描述了如何将PIM映射到实际的技术平台上。
PSM通常是使用特定的编程语言、框架或技术进行描述的,因此它是与特定平台的实现相关的。
使用MDA的好处在于解耦开发过程和具体实现。
通过将系统开发分为不同的模型层次,可以实现问题域和技术实现之间的分离,从而降低了系统的复杂性和维护成本。
此外,MDA还提供了模型转换和重用的机制,可以减少重复劳动,并促进在不同平台上的代码重用。
然而,MDA也存在一些挑战和限制。
首先,建立和维护模型需要额外的开发成本和时间。
其次,模型转换可能会引入错误和缺陷,因为在转换过程中可能会丢失一些信息或者忽略一些细节。
此外,MDA一般用于大型系统的开发,对于小规模项目来说,可能过于复杂和冗余。
总的来说,MDA是一种具有潜力的软件开发方法,它通过模型的创建和转换来实现系统的开发。
它可以提高系统的可维护性和复用性,并促进在不同平台上的代码重用。
然而,MDA也面临着一些挑战和限制,需要开发者在实践中权衡其利弊,并根据具体项目的需求来决定是否使用MDA。
基于SOA和MDA的构件技术应用研究

中图分 类号 : P3 3 T 9
文献 标识 码 : A
近 年来 , 向构件 技 术 的应 用研 究 在 国 内外 I 得 到 了重 视 , 多 大 工程 、 项 目都 纷 纷 采 用 此 技 面 T业 许 大 术 。在 商业 软件 中应 用此 技术 的关 键 是 如何 找 到 一 个 切人 点 , 以使 成 本 、 度 、 量 处 于 一 个平 稳线 J 进 质 。 近来 将 构 件 技术 与 面 向服 务 的体 系结 构 ( e i Src v e—O etdAcicueS A) i r ne rht tr,O 相结 合 是 一个 新 的研 究 方 e 向 。模 型 驱动 架构 ( dl r e r ic r, A) 会 成 为对 未 来 I 技术 产 生重 大影 响 的开 发 方 法 , Moe i nAc t t eMD 将 Dv h eu 1 1
硬件平 台 、 操作 系 统 和编程语 言 。这 使得 构建 在各 种 系统 中的服 务 可 以 以一种 统 一 和通 用 的方 式 进 行 交
互。要应用 S A思想来指导应用软件开发, O 首先要花时间考虑系统 ( 或企业) 业务 、 与合作伙伴 系统 的交 互、 希望 用户 怎样 与服 务进 行交 互 以及系 统 ( 企 业 ) 望利 用 服务实 现 什 么。这 种 思考 将 反 映 到体 系结 或 希 构设计和应用程序如何进行 内部和外部传送上来 。
1 框 架的原理 与方 法
( )面 向服务 的体 系结 构 。S A是 一个 组件 模 型 , 将应 用程 序 的不 同功 能单 元 ( 为服 务 ) 1 O 它 称 通过 这
些服 务之 间定 义 良好 的接 口和契 约联 系起 来 。接 口是 采用 中立 的方 式 进行 定 义 的 , 独 立 于实 现 服 务 的 它
基于MDA统一配置的SaaS元模型

2017年8月第38卷第8期湖北文理学院学报Journal of Hubei University of Arts and ScienceAug. ,2017Vol. 38 No. 8基于MDA统一配置的SaaS元模型潘虎\熊伟〃(1.湖北文理学院数学与计算机科学学院,湖北襄阳441053;2.武汉大学软件工程国家重点实验室,湖北武汉430072)摘要:为了适应用户个性化与多元化的定制需求,基于Sa a S的多租户特性建立了 一种由 M D A统一配置的SaaS元模型,内容包括各种场景下的SaaS配置元模型和统一的用户配置接口.模型将各种配置场景参数转化为元数据及其关系,让SaaS模型进一步地抽象并统一起来.设计了相应的原型系统进行规模实验验证.结果表明:该方法能够对系统进行有效的多租户定制,可以满足用户对SaaS服务的特殊定制需求,降低了服务定制复杂度,适宜应用到大型S a a S系统中.关键词:SaaS;多租户;个性化定制;M D A中图分类号:TP311.5 文献标志码:A文章编号=2095 -4476(2017)08 -0010 -05要在竞争中获胜,企业必须保证业务的敏捷性,尽可能降低系统的服务代价[1_3].随着云计算技术的发 展和面向服务架构(S0A)技术的日渐成熟,SaaS模式使用外包方法降低了租户费用(冷启动具有较低代价,对市场反应具有敏捷性),赢得了多数企业的支持.SaaS模式的一个典型特征是“单实例多租赁”,对于每个 租户来说,实例像是只为自己工作.通过给大量租户供应服务能够实现规模化定制.这种统一的软件服务 方式通过按需定制,可以让具有不同服务要求的租户基于单实例构建定制流程和服务.其中流程逻辑可以 虚拟化并可以重用.另外现存的大批不同性质的服务也应使用统一架构整合起来.SaaS模式的服务定制过程在界面、流程、服务、数据等层次上比以往的服务定制模式都复杂,租户的服 务定制行为必须遵从这些层次间的大量依附和约束关系.本文的第1节回顾了与本文相关的研究工作;第2节提出了各种场景下SaaS配置元模型;第3节提出 了支持统一的用户配置接口架构,通过实验对本文提出的方法进行了评估;最后展示了未来的研究方向.1相关研究及本文贡献传统模式的业务流程定制是针对服务组合、形式化验证与流程演进等进行研究.SaaS模式下的服务定 制研究刚起步,很多问题(包括安全策略、构造方法、定制方法、可扩展性等)才开始研究[4_7].文献[8]中的 复杂业务流定制框架将业务流程执行语言(B P E L)规范引入了 SaaS业务流程定制,它独立于B P E L引擎与 W e b服务,支持流程逻辑验证,依照租户提出的规则实现自适应.文献[9]提出了一种基于T L A的模型定制 方法,主要关注对象是如何实现验证.文献[10]中先设计了层次化定制框架(能够描述流程、服务、数据等 层次的定制活动及其之间的依赖关系并进行相应验证,为提高定制效率,该框架还提供了推荐机制).上述 方法都将流程定制作为目标,并且对流程间的依赖规则进行验证,确保了流程定制的正确性.但是,流程定 制仅仅是SaaS服务定制中的一种,在动态多变的网络环境中,需要满足更多用户个性化的定制需求.目前SaaS模型在“多租户”特征下已支持功能、流程和界面的可配置,但缺乏将上述配置数据统一起来 的办法.本文设计了一个M D A(Model Driven Architecture)驱动的统一配置SaaS元模型与相应体系结构.将 各种配置场景的参数转化为元数据及其关系,使SaaS模型更进一步地抽象并统一起来.然后使用了 4个支 持SaaS的开源项目进行实验,验证了本文方法的有效性.收稿日期:2016 -07 -04;修订日期:2016-11-20基金项目:国家自然科学基金项目(61172〇84)作者简介:潘虎(1975 —),男,湖北襄阳人,湖北文理学院数学与计算机科学学院讲师.潘虎,等:基于MDA 统一配置的SaaS 元模型2各种场景下的SaaS 配置元模型2.1研究场景本文假定某项目组开发一个在线客户管理系统(C R M )平台.考虑以下几个场景:场景A :根据项目时间需求的紧迫性和现有技术储备,采用面向对象方法,利用“Struts + Spring + Hibernate ”开源框架进行开发,项 目顺利上线,由于采用了成熟技术,系统稳定可靠.场景B :经过一段时间的业务发展,公司接手了若干类似项 目,在原有系统的基础上为这些项目定制开发多个系统,系统版本分支逐渐增多,公司需要响应多个项目的需 求变更,版本管理越来越复杂.公司通过抽象提取现有项目的共性需求,将原有项目转型为支持功能可配置的产品.场景C :又经历了一些时日,公司需要支持的可配置能力变得更多起来,除了功能可配置,还希望支持流 程、界面和数据的可配置.为了维护方便,引入了 SaaS 的多租户思想,以实现用户深度定制.另外,对于原有功 能模块进行重构并服务化,便于系统的复用、X #卜开放OpenAPI 以及支持第三方开发.2.2配置扩展数据为了适应实际业务个性化定制对于自定义扩展字段的需求,关系模式表可以用key /value 方式转化来实 现可扩展性.如图1如示,可以为SaaS 系统提供灵活的数据扩展.扩展数据元模型图2功能包元模型图12.3配置功能为提供规模化定制服务,SaaS 需要支持功能的可配置性.l )SaaS 服务的碎片化.是功能配置实现的基础,可以从两个方面入手:第一是原子功能的划分.资源分解遵循原则是每个功能自有价值,并具有原子性(功能不重叠且不能形成依赖环).功能的并集要完整覆盖 系统功能,功能划分最好由价值驱动.第二是功能描述和功能关系.功能描述包括对功能名称、关键字、内 容、以及所依赖的功能列表的描述.每个原子功能在系统内要求具有唯一关键字,实现功能引用和校验.2)针对租户的特殊要求设计功能包.实时构建满足需求的服务组合需要很高代价,可以在线下根据用户类 型和场景聚类原子功能并打包,用户可根据需要在功能包中选择.但是,由于原子功能具有依赖性,必须遵 循高内聚、低耦合的原则.3)功能验证.包括功能验证和互操作验证,系统根据租户定制的配置,递归查找其 包含的功能包,并据此进行相关验证.功能包元模型如图2所示.2.4配置界面SaaS 服务需要规模化自定制界面,用于配置系统菜单和页面内容.1)系统菜单配置.出于个性化需要,不同租户对于相同功能的 菜单可能使用不同标示,对于菜单结构和分布可能会有不同要求.租 户可以定制唯一菜单,其中各个菜单项关联一项原子功能.菜单采 用树状结构,同级菜单项为顺序排列.2)页面内容配置.租户对界面 都会提出特殊需求,包括页面上元素的数量、顺序、位置、含义,还需 要支持数据可扩展性.页面内容的实现一般比较复杂,多采用标签 语言来描述.界面元模型如图3所示.图3界面元模型11第38卷第8期 湖北文理学院学报 2017年第8期2.5配置流程通过改造工作流系统可以在支持多租户的基础上实现流程的可配置.为方便性考虑,系统通过提供公 用流程模板,租户可以复制该模板并根据自身需要修改,设计出符合要求的工作流程.另外,由于租户流程 是私有的,其他租户应该不可见,因此要确保租户间的数据隔离.流程元模型如图4所示.图4流程元模型ConfigTypeId Name ProcessClassRemark 1 ,Table com. abc. config. TableMeta 表2 1Function 功能3 j FunctionPack 功能包4 j Menu 菜单5 j Page 页面6 j PageContent 页面元素7 1workflow 流程ConfigMeta Id TvDeld!NameKev Content2001客户表T. Custom 客户表20021订单表T. Order 订单表120032新建客户 F. NewCustom 新建客户]20042修改客户 F. UpdateCustom 修改客户120053客户管理FP. CustomMgt 客户管理丨20064客户新建M. CustomNew 客户新建'20075客户新建页面P. NewCustom 客户新建页面丨2008|6客户姓名PC. custoName 客户姓名!2009!7客户审批流程WF. CustomSubmit客户审批流程MetaRelation MetaPropertyId Mainld Relaid]Relation 120042003 1Depend 220052003 +Include 320052004Include 420062003Association 520072008IncludeId Metaldi Name Key ContentDataTvoe CheckRule Order 100012008 +宽度Size 控件宽度int >01100022008左边位置X 控件左边位置int>021********上边位置Y控件上边位置int >03图5配置数据元模型图6 配置数据元模型用例2.6配置数据管理一个完整的SaaS 应用有很多配置需要.如果配置达到原子功能,系统业务逻辑的实现会过于复杂,用 户体验也差,实现系统可配置的成本较高.根据M D A 核心思想,基于模型所在领域提取一个相对核心的领 域模型.经过抽象发现在系统的各种配置场景下(数据扩展、功能、界面、流程可配置等),表面上配置参数各不相同,实际上仍然存在很多共性.如果采用Key /valne 方案,各种配置场景的实现完全一样.因此,可以实 现统一的接口,简化实现系统可配置性的复杂度,同时保证统一的配置规划和管理风格.配置数据元模型如 图5所示.图5中配置元数据间的关系为包含关系、依赖关系和关联关系.ConfigType 表示类别.类别包括表、原 子功能、功能包、菜单、页面、页面元素、流程等,每个类别对应一个处理类,负责处理相应配置元数据.Con figMeta 表示可共享属性 • MetaProperty 表示私有属性 •以 C R M 为例 ,如图 6 所示 ,其中箭头表示关联 •酉己置元数据与系统设计紧密关联,必须根据系统的规划设计确定可配置点,才能定义出配置元数据内容.2.7租户配置数据租户配置数据即租户定制配置信息,包括自定义菜单、自定义界面元素、自定义流程、数据表扩展字段、 租户购买包等.由系统管理员设置租户购买包,其他信息均由租户管理员配置.租户元模型如图7所示.3可配置系统架构及实验验证在一套统一的租户配置接口下,管理员可以轻松设置和修改相应配置以适应各种场景,为用户提供更12潘虎,等:基于MDA 统一配置的SaaS 元模型好的服务.运行结构如图8所示.可以通过界面元模型实现系统菜单定制与页面定制,通过扩展数据元模 型实现扩展数据引擎并提供对于扩展数据的查询、使用、提交和检查等支持,通过功能包元模型实现功能引 擎(根据租户定制的功能包找到所有原子功能集合),更进一步通过结合租约与流程实现配置数据和工作流 引擎的融合.图7租户元模型 图8 可配置系统的运行结构基于统一配置的SaaS 元模型开发出了相应的原型系统.为评估此方法,实验采用如下配置环境:1)该 集群包括8个节点,每个节点有64位8核C P U 和16G B R A M ;2)所有节点都用CentOS 6. 2和Java 1.6. 022;3)开发工具包括Java 5,工作流引擎Yaw l 版本为2. 3,数据库采用M y S Q L 5. 1,使用Mule ESB 2. 2. 1作为服 务总线,有效地串联起各个模块.为了比较本方法的用户满意度,使用了 4个支持Sa a S 的开源项目(3%-a r C R M 、Gl a d C R M 、vTigerCRM 、CloudCRM )进行验证,编号为 C R M 1、C R M 2、C R M 3、C R M 4.课题组中的 4 个成员(编号为111、112、113、114)对4个开源项目都很熟悉,阅读过它们的源码,熟悉项目架构,规定运用“优、 良、中、差”四级评断标准对4个开源项目的用户满意度分别给出贡献等级,未使用本方法的情况为M l ,使 用了为M 2.最后汇总如表1所示.通过比较在租户数量不同时,使用与未使用以上方法的平均响应时间,进一步检验以上方法在租户规模化定制下的性能.结果如图9所示.表1用户满意度比较用户指标方法项目CRM 1CRM 2CRM 3CRM 4U 1功能性Ml 良良良良U 1功能性M 2优良良优U 2可靠性Ml 良中良中U 2可靠性M 2良优良优U 3可维护性Ml 中中差中U 3可维护性M 2优优良优U 4易用性Ml 良中良中U 4易用性M 2优优优优从图9中可以看出,使用统一配置方法优于未使用统一配置方法.并且随着定制规模的扩大,定制所需 要的响应时间会逐渐增加,但变化幅度较小,便于将其运用到大型系统中.此项研究提出了一种基于M D A 统一配置的SaaS 元模型及其系统架构,包括配置扩展数据,功能配置过 程,系统菜单和页面内容配置,配置工作流程,配置数据管理和租户配置数据.经过实验验证了基于以上元 模型构建的原型系统,满足用户对于SaaS 服务的特殊定制需求.通过采用统一配置方法,能有效降低服务13第38卷第8期湖北文理学院学报2017年第8期定制复杂度,验证了它适用于大型系统中.下一步研究将继续深入探讨SaaS服务的交互行为特性,从多层 次分析交互行为产生的涌现行为及其调控机理.参考文献:[1 ] KANG S,MYUNG J, YEON J,et a l. A general maturity model and reference architecture for SaaS service [ J]. Lecture Notes in Computer Science,2010,5982(2) :337 -346.[2] JACOBS D. Enterprise software as service [ J]. ACM Queue. 2005 ,3(6) :36 -42.[3] JACOBS D, AULBACH S. Ruminations on multi - tenant databases [ J]. BTW,2007(103) :514 -521.[4] FREDERICK C, GIANPAOLO C ,ROGER W. Multi - Tenant Data Architecture[ R]. Microsoft Corporation,2006 :36 -45.[5] AULBACH S,GRUST T, JACOBS D,et a l. Multi - Tenant Databases for Software as a Service:Proceedings of SIGMOD'08 [ C]. ACM,2008 ,25(7) :1195 -1206.[6] AULBACH S, JACOBS D, KEMPER A, et a l. A Comparison of Flexible Schemas for Software as a Service : Proceedings of SIGMOD '09 [ C ].ACM,2009:881 -888.[7] FRANCLIN S F,IOANNIS M. D, JOHN F S I. A New Hybrid Schema - Sharing Technique for Multitenant Applications: Proceedings of ICDIM2009[C], IEEE,2009:1 -6.[8] YULIANG S,SHUAI L,QINGZHONG L,et al. A flexible business process customization framework for SaaS: Proceedings of ICIE 2009 [C].IEEE,2009,2(6) :350 -353.[9] LUAN S,SHI Y,WANG H. A mechanism of modeling and verification for SaaS customization based on TLA[ J]. Lecture Notes in Computer Science, 2009 (5854) :337 -344.[10 ] SHI Y L, LUAN S, LI Q Z, et a l. TLA based customization and verification mechanism of business process for SaaS[ J]. Chinese Journal of Computers ,2010 ,33 (11) :2055 -2067.A SaaS Meta Model of Unified Configuration Based on MDAPAN Hu1, XIONG Wei1'2(1. College of Mathematical and Computer Sciences,Hubei University of Arts and Science,Xiangyang441053, China; 2.State Key Lab of Software Engineering,Wuhan University,Wuhan430072, China)Abstract ;This paper establishs a SaaS meta model of unified configuration based on M D A (Model Driven Architecture)according t o multi- tenancy features,in order t o meet the requirements of personalized customization for SaaS tenants.The content includes SaaS configuration meta model and unified user configuration interface in various scenarios.The model translates parameters of various deployment scenarios into metadata and i t s relationship,making the SaaS model more abstract and unified.To validate our approach,large- scale experiments are conducted based on a developed prototype system.The results show that the architecture can customize service effectively in a multi -tenant environment,meeting the user,s special customization demand for SaaS services,reducing the complexity of service customization,suitable for application t o large scale systems.Keywords:SaaS;multi- tenant;personalized customization;M D A(责任编辑:陈丹)14。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Vo . NO 4 1 31 . Aug . 2 0 01
文 章 编 号 :6 2— 8 1 2 1 )4— 0 1— 4 17 67 (00 0 03 0
基 于 MD 的 S A OA服 务 协 作 模 型
张 春 阳 韩 建 松 张 惠 军 任 铭 亮 刘 勇 , , , ,
( . 南 科 技 大 学 电 子 信 息 工 程 学 院 , 南 洛 阳 4 10 ; . 阳 卷 烟 厂 企 管 部 , 南 安 阳 4 50 ) 1河 河 7 0 32 安 河 5 10
摘 要 : P L是 业 务 流 程 执 行 语 言用 来 描 述 S A 的服 务 协 作 模 型 , 现 对 已有 系 统 业 务 流 程 的 编 排 。但 其 随 BE O 实 着 整 合 已有 系统 的增 多 和 业 务 流 程 复 杂 性 的 增 加 , P L建 模 也 变 得 异 常 复 杂 。本 文 给 出 了一 种 基 于 MD BE A
两种模 型之 间通过 相应 的转换 规则 联 系起 来 。PM 是 一 个 不考 虑 具体 实 现 技 术 的纯 分 析模 型 , 这 个 I 在
层 次上 PM 是 可重用 的 , 过 PM进 一 步提 高 了软 件 系 统 的抽 象 层次 , 时也 屏蔽 了 由于 底层 平 台技 I 通 I 同 术 的变 化所带来 的影 响 ; S 是 与 特 定 的 平 台系 统相 关 的模 型 , 基 于某 一 个 特 定 的实 现 技 术 , PM 它 比如
0 前 言
We b服务 是 目前 S A 中服务 的最 主要 实 现技术 , 以说 S A 的兴 起 在很 大 程 度上 得 益 于 We O 可 O b服 务相关标 准 和技术 的成熟 与进 步 。We b服 务协 作 的 目标 正 是研 究 如何 在 已有 服 务 的基 础 上 , 建 复 杂 创 的服务来 满足 S A业务 流程 的需 求 O 。尽管 We b服务 为应 用 程序 通 过跨 平 台 间传递 消息 和调 用 方 式提供 了一种 方法 , 但是 它们 仍然 不能 利用 自身 的力量 满足业 务 流程 的操作 需求 , 别是对 于 大型 的分 特 布式企业 应用 系统 , 需要 在大量 的 We b服务 之 间进 行信 息 的交 互 以及 业务 流程 的 编制 , 因此 随 着 S A O 中业务流 程模 型 的增 加 , 带来 服务 协作 模型 的复 杂性 与 日俱 增 的问题 会 。 模型 驱动构 架 ( A, o e D i nA ci cue 的核心 思想 是抽 象 出与实 现技 术无 关 , 整描 述业 MD M d l r e rht tr) v e 完 务功能 的核心平 台无 关 的模 型 , 然后 针对 不 同实 现 技术 制 定 多 个转 换 规则 , PM 转 换 成 与具 体 实现 将 I 技术相关 的 P M, S 最后 将经 过精化 的 P M 转 换成 代码 -] S 6。MD A的 目的是通 过 P M 和 P M将 业 务 建 I S 模 和底层 平 台技 术分 离开 , 以保 护建 模 的成果 不受 技 术 变迁 的影 响 “ 。因 此 , 中采 用 MD 文 A的 开发 方法, 通过 在 PM层 建立 服务 协作模 型 , I 解决 了直 接建立 S A服 务协作 模 型 的复杂性 问题 。 O
台相 关 层 B E P L模 型 , 验 表 明 : 方 法 能 较 好 地 简 化 S A 服 务 协作 模 型 的 建 立 过 程 。 试 该 O 关 键 词 : 型驱 动构 架 ; 向服 务 的 体 系 构 架 ; b服 务 ; 务 流程 执 行 语 言 模 面 We 业
中 图分 类 号 : P 1 . T 3 15 文 献 标 识 码 : A
第 3 卷 第 4期 1
21 0 0年 8月
河 南 科 技 大 学 学 报 :自 然 科 学 版
J ur lo n n Unv r i fS inc n c oo y: t r lSce c o na fHe a ie st o ce e a d Te hn lg Na u a in e y
模 型驱 动 转 换 的方 法 来 建 立 S A 服 务 协作 模 型 。 针 对 建 立 S A 服 务 协 作 模 型 的 复 杂 性 , 平 台 无 关 层 建 立 O O 在
U ML活 动 图描 述 服 务 协 作 模 型 的 交 互 过 程 , 过建 立模 型之 间 的 映 射 规则 , 平 台 无 关 层 模 型 自动 转 换 到 平 通 将
.
N T、 E E J E平 台等 2
。 Leabharlann 1 2 We . b服 务 协 作
We b服务 就是 一个应 用 程序 , 向外界 暴 露 出一 个 能 够 通 过 We 它 b进 行 调 用 的 A I其 目的 是使 分 P,
布在 网络上不 同地 理位 置和 不 同平 台 的客 户 可 以获 得 服 务 。We b服 务 本 身是 独 立 的模 块化 的应 用 程
序, 它们 常常 不能利 用 自身 的力量 满足业 务 流程 的操作 需求 。为满 足 日益 复杂 多变 的业 务 需求 , 需要将 这 些 We b服 务连 接在 一起 成 为一 个业 务 流程 来 实 现 更 复杂 的功 能 , 因此 出 现 了 We b服 务 协作 。服务
1 相 关 理 论
1 1 模 型 驱 动 体 系 构 架 .
M A是 由对象管 理组 织 ( bet n gm n G op O D O jc Maae e t ru , MG) 2 0 于 0 1年提 出来 的 , 它将 软 件 系统 的模 型分 为平 台无 关模 型 ( l f m Id p n e t o e, I 和平 台相关模 型 ( lt r p cf d lP M) Pa o n ee d n M dlPM) tr Pa om S eicMoe, S , f i