基于柔性思想装配云服务的研究

詹云桥，段隆振

南昌大学 信息工程学院，南昌 330031

1 引言

软件即服务（SaaS）[1]是一种软件部署模型，通过它，服务提供者可按照客户需求将一种应用作为服务提供给客户使用，数据及程序从台式PC机和联合服务器中被移除，而被安装在云中的计算机中[2]，不再像以前，需要下载相应安装文件到本地系统，然后，进行安装、运行、维护等一系列过程。这无形中增加了用户的负担，更重要的是，用户时常被迫为他们所不需要的功能而付费。

但是，有许多制约因素限制企业大规模地应用SaaS化服务，如：由于多租户是SaaS的关键特性之一[3]，即只有唯一实例运行在SaaS应用中，所以，它必须满足所有个性化需要，如：异构数据、流程规则，以及业务规则，这样一来，SaaS应用模型将会非常复杂，并且，如果每个租户必须将他们的业务逻辑包含在这个模型中，将很难保证他们业务逻辑的私密性[4]。而导致这些制约因素产生的最根本原因是没有有效的方法去指引如何设计灵活且可伸缩的服务，以及如何高效地组装这些服务。有鉴于此，本文在柔性思想的基础上，提出一套有效的方法来介绍如何设计及实现服务，旨在帮助设计及开发人员搭建既经济又高效的弹性云服务平台。

2 相关工作

目前，许多研究工作倾向于探讨如何使服务提供者开发更柔性的服务以处理单实例与多租户之间的不平衡。例如，文献[5]认为一个应用应该被分为两部分：第一部分所包含的功能应该是固定的，并且能够被所有的用户所使用；第二部分应该被描述[6]为可配置的元数据，这些确切的租户数据应该被每一个新的用户所部署。因此，在服务组件架构（标准的多租户模型，SCA[7]）的基础上，引进了一种能够提供服务模板及解决思路的包格式。为了支持多租户服务，文献[8]介绍了一种双重验证，此双重验证的业务规则是从服务中抽取出来的；通过唯一的服务实现去处理来自不同租户的请求。因此，不需要为每个租户单独提供服务。在分析业务流程定制研究现状时，文献[9]认为，以版本为基础的主要策略是开发拥有完整功能，面向大众目标且高标准化的软件产品，并且，在特定的功能模块上预先定义一些参数，以便允许用户通过设定参数去描述软件[10]，而且，这些软件系统的流程定制方式仅通过一些选项、参数配置、可视化设计去完成，这是非常简单的，因为，以版本为基础的话，这些定制过程会被限定在预先定义的范围内。为了改变这一情况，文献[9]通过介绍服务模型（或模板）概念和特定域语言STML（服务模板标记语言），在SaaS平台上提出了一种以MDA为基础的SOA软件定制方法。STML工具的主要模块包含网页门户、服务定制和组装工具（SCIT）、服务执行平台（SEP）、服务模板注册（STR），尤其SCIT向用户提供工具，以支持用户用STML语言去编辑、核查、验证、恢复服务描述文件，并且，将这些文件转换为源码程序以适应多变性。

另一方面，为了灵活地产生业务流程，工作流语言被用来将单独的业务活动整合到完整业务流程中，其中每个单独的业务活动由不同的服务所实现[11]。而且，企业可以通过工作流语言所提供的平台去有效地编排新的“完整服务”[12]，例如，IBM公司的以XML为基础的网页服务流语言（WSFL[13]）、微软 XLANG[13]、工作流管理集合（WfMC）和XML流程定义语言（XPDL[14]），所有这些方法都提供了将服务编排到“端到端”的企业应用中去。再者，作为业务流程编排语言的BPEL被广泛认为对于应用的灵活性是非常有效的[15]，因为它允许改变编排逻辑（用BPEL描述）时独立于服务[16]。可以看出，目前的研究只关注于服务结构的外部，并没有过多地了解分析它的内部状态，唯有灵活动态的服务结构构造出的云服务系统才能适应未来多变的需求环境。

3 柔性服务

随着时间的推移，外界的环境及条件在不断地发生变化，唯有动态适应这种变化，才能继续生存及发展。柔性思想的核心理念是面对复杂多变的环境，本体拥有可灵活组合的结构，以形成不同的形态，去应对外界的环境。在SaaS模式中，外界的环境即用户需求，而本体结构即服务结构。传统的SaaS模式如图1所示。

图1 传统的SaaS模式

提供给客户的服务是运营商部署在云计算基础设施上的应用程序，并且，服务必须考虑各种类型的用户对它的特殊要求。用户可以在各种设备上通过瘦客户端界面访问，如浏览器。消费者不需要管理或控制任何云计算基础设施，包括网络、服务器、操作系统、存储等等。服务提供商开发相应的服务并在SaaS平台上进行注册，然后用户通过SaaS平台定制所需的服务以得到相应的业务功能。但在此模式下，当大量的用户使用云服务平台时，会带来诸多问题。首先，由于没有灵活且可组装的服务结构，随着用户大量增加，服务数量也会大量增加。所以，由此模式所搭建的系统对于外界的变化非常敏感，适应性差。第二，使用云服务系统的用户大部分来自各行各业，他们对于同一服务的需求层次是不尽相同的，即他们对某一服务所提供的大部分功能是趋同的，但他们对这项服务可能存在技术上或业务性上的需求差异。对此有两种解决方式：第一种，新增加若干个服务以满足不同用户的特殊需求，这无疑增加了系统的额外负担；第二种，将不同用户对于同一服务的不同需求功能点全部包含在一个服务内，大部分云服务系统采用了此方式。很明显，第二种方式增加了单个服务的复杂性，且可维护性差，再者，系统开发人员也不可能预测所有未来用户的服务差异。若考虑以柔性方式构建灵活且可组装的服务结构，则可提高系统的适应性，柔性SaaS模式如图2所示。

图2 柔性SaaS模式

在插件结构的应用系统中，程序并不是单一的执行文件，而是由主程序和若干外部模块组成。这些模块按照一定的规则编写，可以通过配置文件灵活地加入到系统中，也可以在程序运行时动态地加入到系统中。由于可以灵活机动地增加减少替换这些模块，通常把插入到系统中的模块称为插件。在柔性SaaS模式下，通过动态组装框架，云服务系统可以为不同用户装配不同的服务及插件。这样一来，不同用户对一个服务的细微差异可以通过组装不同的插件来消除，既降低了单个服务的复杂性也减少了服务的数量。另外一方面，对于大量不同用户的不同需求，可以先考虑通过现有服务及插件组装成符合用户新需求的服务，以减少新需求对系统的影响。以柔性SaaS模式构建云服务系统必须经过两个核心步骤：服务规划和构建服务扩展结构。以下详述这两个步骤。

3.1 服务规划

服务规划是构建柔性云服务平台的基础。在设计服务结构及数量时，必须在独立性和复用性中作一个权衡。如果只考虑服务间的独立性，则势必增加单个服务的复杂性，而且服务扩展性会变差，在云平台的分布式环境中，如果只考虑服务复用性，则势必增加服务间的调用次数，从而降低整个系统的运行性能。服务规划应从两个方面去考虑：服务定义和服务粒度。服务定义应从业务角度考虑，使服务功能更切合业务流程中的实际情况，而服务粒度则应更多的从技术方面出发，使得服务粒度的规模在不增加整个系统的复杂性的前提下，提高服务的复用性。综合以上两个方面，给出规划方法的具体步骤，如图3所示。

图3 划分步骤

（1）综合收集，将业务领域内的知识进行收集、归纳、总结。全面了解业务边界，掌握每个关键业务活动在业务领域中的逻辑依赖关系。

（2）单元切分，从用户的角度为出发点，以业务目的为界限将业务活动中包括的“最小”功能划分出来。以业务目的为界限来划分业务活动，旨在保证划分出来的最小业务功能在业务领域中具有完整的业务意义，否则划分结果会倚重技术层面，过多考虑独立性、系统性能等指标，偏离业务实际。以用户的角度作为划分的基点，主要是考虑将来用户使用SaaS系统平台的便利性及更多地以操作主体的视角来考察划分结果的合理性。强调将业务活动的“最小”功能切分出来，是为了尽可能地提高服务的复用性。

（3）独立合并，将在业务逻辑上具有较强依赖关系的核心功能划归为单个独立服务。依赖关系包括前向依赖即A-＞B，后向依赖A＜-B，双向依赖A＜-＞B，其中双向依赖的依赖关系最强。虽然，将具有较强依赖关系的功能划分为单个服务会导致服务“膨胀”，但在业务领域中的核心功能及其之间的依赖关系是相对稳定的，这样一来，在分布式环境中，可以有效地减少服务之间的调用，提高系统运行性能。

归根到底，服务规划的任务是将业务领域内的整个流程切分成具有相对独立性的基础服务，这些基础服务是构建服务扩展结构的起点。

3.2 构建服务扩展结构

一个应用模板是作为服务提供给用户的，这个应用的某些部分是不确定的或是需延迟定义的，并且，这部分应该能够被每一个租户所定制，以便满足它们特殊的需求[17]。再者，不同的用户对于一个用户有着不同的需求，这使得SaaS应用必须是可配置的以应对这些不同的需求，例如，不同的用户可能会使用服务来展示他们自己公司的标识[18]。因此，对于一个服务来说可以分为两个部分：第一部分是其基本功能，即所有定制此服务的用户都会使用的功能。第二部分为扩展功能，即不同用户使用同一服务的差异部分。基本功能通过“接口-实现类”的方式开发，为未来服务基本功能的升级和维护提供方便，而每一个扩展部分即为一个插件，扩展部分借鉴基于插件方式的软件开发，采用具有预见性及开放性的“接口”，提高插件的开发生产率。当系统运行时，插件借由动态组装框架灵活插入服务的基本功能中组装成“完整服务”提供给用户，插件的主要用途：（1）屏蔽用户使用同一服务的细微差异，从而使服务具有一定的通用性；（2）协调服务之间的调用关系，使得用户定制的服务之间可以柔性的调用，组成完整的业务流程；（3）动态插拔插件，使得服务具有一定的伸缩性。传统SaaS模式为“单实例多租赁”，在此基础上，通过引入“接口-实现类”方式、插件、动态组装框架，形成“单实例多扩展插件多租赁”的柔性SaaS模式。

为了使插件方便地插拔于服务，灵活地扩展或去除部分功能，并且降低插件与服务之间的耦合度，以便提高开发效率及扩展性，柔性SaaS模式的核心类图如图4所示。

服务类Service及插件Plugin类有各自的接口，分别可提供不同的实现方式，以产生多种实现类。AbstractServiceProxy是用户使用“完整服务”的一个接口，此“完整服务”的实现类Proxy是由构造类Constructor通过动态代理模式产生的。由此看来，每个服务可以通过动态代理模式和多个插件动态组合成“完整服务”供用户使用，且服务类与插件类的实现方式可相对独立，有利于提高系统的扩展性并降低耦合度。构造类Constructor动态产生服务代理类的方式，如图5所示。

由图5可以看出，构造类通过反射机制将服务类及插件类中的属性和方法映射出来，并构造出同时拥有服务类和插件类所有功能的新类Proxy。当用户定制好所需的功能或重新定制后，柔性SaaS平台将通过动态组装框架将用户目前所定制的“完整服务”进行动态编译直接使用户拥有新的功能，而不需重启系统。

图4 核心类图

图5 服务代理类产生过程图

动态组装框架基于OSGi体系架构，OSGi通过SOA为服务共享普通信息，这是最小的集合单元，并且，每个服务可以通过共享资源与其他服务进行交互[19]。在一个动态扩展的OSGi环境中，OSGi框架管理Bundle的安装和更新，同时也管理Bundle和服务之间的依赖关系，服务的更新是通过更新合作的Bundles实现的[20]。一个Bundle可能处于六种状态，如图6所示。

图6的各个状态说明：已安装。安装完成，本地资源成功加载。已解析。依赖关系满足，这个状态意味着该Bundle要么已经准备好运行，要么是被停止了。启动中。Bundle正在被启动，BundleActivator的start（）方法已经被调用但还没有返回。停止中。Bundle正在被停止，BundleActivator的stop（）方法已经被调用但还没有返回。运行。Bundle被成功地启动，并正在运行。已卸载。Bundle被卸载被无法进入其他状态。

图6 Bundle状态图

Equinox[21]框架是Eclipse组织基于OSGi Release 4的一个实现框架，它实现了OSGi规范的核心框架和许多标准框架服务的实现。柔性SaaS模式中的动态组装框架为Equinox。通过它，将插件动态插入特定服务中的基本功能部分形成具有特殊功能的“完整服务”。

通过Equinox框架及插件体系结构，柔性SaaS运行模式如图7所示。柔性SaaS框架主要由三大部件组成，即插件管理程序、Equinox、系统平台接口。插件管理程序的主要功能是向插件提供插入相应服务的接口，插件的开发只需符合接口规范，就可通过插件管理程序插入到相应服务中，扩展其功能。对于服务而言，插件管理程序如何通过插件扩展其功能是透明的。用户功能的更新只需要通过构造类Constructor将所涉及的插件及基础服务动态生成符合用户最终需求的服务代理类，最后由Equinox框架将经过重新编译的服务代理类代码嵌入运行的系统中。由此可见，一个用户更新其服务功能的整个过程对于运行中的系统以及其他用户而言，是无影响的。系统平台接口的功能涵盖展示系统服务及其扩展功能、响应用户定制需求、计费等。

新用户使用本系统的过程：首先，用户通过系统平台接口了解本系统平台所提供的服务及插件的功能和计费规格等信息；然后，选择所需的服务及插件并提交给系统，平台系统数据库中有一张记录所有用户所定制的服务和插件的编号、定制时间等信息的功能表；之后，插件管理程序根据用户定制的插件编号查找出相应位置，并提交给构造类Constructor；随后构造类通过动态代理模式将用户所定制的基础服务与相应插件组成“完整服务”；最后，Equniox将“完整服务”封装成Bundle并进行动态编译、加载、部署，系统平台接口随之动态更新当前用户所定制的服务。

4 实验分析

下面将某省物流公共信息平台在线交易系统作为实例，详细描述如何在柔性SaaS模式下建立云服务系统。

图7 柔性SaaS运行模式图

图8 在线交易系统主流程图

4.1 项目描述

某省物流公共信息平台在线交易系统旨在帮助货源方和车源方在线完成交易，通过该平台，货源方可以找到运价合适且信用较高的车源方，另一方面，车源方可以实时向平台提供车辆运行情况，以便货源方通过平台及时了解车辆状态，这样一来，车源方可以降低空载率。此物流公共信息平台在线交易系统的流程，如图8所示。

下一步即可按照“服务规划”及“构建服务扩展结构”步骤，分析设计某省物流公共信息平台在线交易系统云服务构建方式。

4.2 物流服务粒度设计

根据项目描述，结合柔性方法，某省物流公共信息平台的服务粒度设计，如表1所示。

表1 服务结构

表2 总体对比

以上每个服务的基本功能由服务提供者Bundle实现，作为插件的扩展功能由插件类实现，当用户登陆后，插件通过插件管理程序动态插入服务提供者Bundle中，最后动态组装框架Equinox向用户提供“完整服务”。

4.3 对比分析

柔性SaaS层将Hadoop中的MapReduce和HDFS分别作为分布式计算（编程模型）及分布式文件存储的基础平台。因为Hadoop是由Java语言开发的，所以，选用J2EE中的相关技术组件标准作为开发应用服务层的技术框架，表现层组件技术标准JSP、Web服务器Weblogic，开发环境为Linux+Eclipse+Hbase+Hadoop，支持框架 Equinox，每个服务必须实现 BundleActivator接口中的 start（）和 stop（）方法，以便Equinox框架控制每个服务的启动、卸载、停止。插件管理程序主要由单例类PluginsManager来控制各个插件的注册、嵌入、卸载等功能，其中注册功能主要是告知有新开发的插件加入系统，以便将来查找或调用插件，嵌入功能将插件插入相应服务，扩展服务功能，卸载功能对应于嵌入功能是解除服务相应的功能。

传统SaaS模式下构建的产品包括Salesforce.com、NetSuite等，它们的共同的特点是没有采用灵活的插件结构及动态框架Equinox的支持。在业务层面，传统SaaS模式中服务的功能必须包含所有使用此服务用户的业务要求，如表1所示。传统SaaS模式中的搜索车辆服务必须能够通过出发地、目的、载重、车高等条件搜索相应车辆，这样一来，将导致单个服务的粒度过大，可维护性差，更重要的是，某些用户根本用不到服务中所包含的所有功能，既增加了用户使用服务的无谓费用，又增加了使用服务的复杂性。在技术层面，与传统SaaS模式相比，柔性SaaS模式可以通过两种方式去应对用户需求变化：现有插件的组合去调整系统内部结构或将新开发的插件动态插入使得系统拥有新的扩展功能。两种模式的服务方式如图9所示。

图9 服务方式对比

从总体性能参数来看，两种模式的对比如表2所示。

由于采用了插件结构，柔性SaaS模式中的服务只须抽离出所有用户的共同要求，所以服务包含的内容少，粒度小，复杂性低，其他细微的需求差异或需求变化可以由插件来调整。另外一方面，因为在业务领域中所有用户的共同要求是相对稳定的，这将有利于对服务的维护。对于细微的需求差异或需求变化，系统可以将现有插件灵活组合或开发新的插件灵活插入服务，既扩展了现有服务的功能又减少了对现有系统的影响。

柔性SaaS模式的高扩展性、灵活结构都是建立在前期服务划分及插件管理程序的设计工作之上的，服务划分工作既要考虑业务领域内的实际情况，又要在技术层面上考虑插件通过插件管理程序插入服务的可操作性及便利性，所以，相对于传统SaaS模式，柔性SaaS模式的系统设计工作较困难。

由于Equinox框架的加入，柔性SaaS模式具备了运行连续性及更新动态性的特点，具体表现在：当系统需要升级时，可以将需要已升级的代码部分交给Equinox框架，这些代码将被动态编译，并直接被部署到运行中的系统，这个过程并不会影响到不需升级的部分。当用户需要修改定制的服务功能时，构造类Constructor根据定制信息动态产生服务代理类Proxy并提交给Equinox框架，然后直接被嵌入用户的功能列表中。

从图9及表2中可以看出，柔性SaaS模式在适应性及可扩展性方面有较好的改进，但这都是以稳定的服务结构及灵活的插件体系结构为前提的。

5 总结语

以目前云计算为基础，通过对SaaS层上有关服务的问题分析，提出一种柔性SaaS模式。首先查阅并了解目前关于如何解决在SaaS层上灵活提供服务，方便有效地让用户形成自己独立的业务流程等问题的现状，然后针对这些解决方法或思路存在的问题，提出了服务规划并构建服务等级结构，最后，通过一个具体案例进行研究分析。实验证明，在保证不提高系统复杂性的前提下，经过该柔性方法装配后的服务在业务独立性方面更强，在适应性方面，具备满足来自不同部门或不同行业人员的功能要求。

本文提出的柔性思想中的服务划分部分着重研究业务领域内的理论逻辑部分，需要大量人工分析及干预，技术辅助不足。另一方面，构建服务扩展结构中的插件管理程序部分需要编程人员定义带有预见性的接口，以方便后期插件的插入，但接口总有不适用的时候。因此，下一阶段的工作是根据服务划分理论开发出一套适合某一业务领域的服务分析框架，减少开发人员花费在分析某领域内的业务时间，将更多的精力放在考虑系统平台运行效率及扩展性等问题上；同时，提出一种比基于插件开发方式更具扩展性的软件开发方式，让已经在系统上运行的服务具备永远可以获取新功能的能力。

[1]Monfort V，Khemaja M，Ammari N，et al.Using SaaS and cloud computing for“on demand”e learning services application to navigation and fishing simulator[C]//Proceedings oftheIEEE 10th InternationalConferenceon Advanced Learning Technologies（ICALT），Sousse，Tunisia，2010：663-665.

[2]Wang H.Privacy-preserving data sharing in cloud computing[J].Journal of Computer Science and Technology，2010，25（3）：401-414.

[3]Wu S，Zhang S，Lan J.A dynamic data storage architecture for SaaS[C]//Proceedings of the InternationalConference on Multimedia Information Networking and Security，Nanjing，China，2010：292-296.

[4]Liu Y，ZhangB，Liu G，etal.Personalized modeling for SaaS based on extended WSCL[C]//Proceedings ofthe IEEE Asia-Pacific on Services Computing Conference（APSCC），Hangzhou，China，2010：355-362.

[5]Mietzner R，Leymann F，Papazoglou M P.Defining composite configurable saas application packages using SCA，variability descriptors and multi-tenancy patterns[C]//Proceedings of the 3rd International Conference on Internet and Web Applications and Services，Athens，Greece，2008：156-161.

[6]Chong F，Carraro G.Building distributed applications architecture strategies for catching the long tail[EB/OL].MSDN architecture center（2006）[2011-06].http：//msdn2.microsoft.com/enus/library/aa479069.aspx.

[7]Open SOA Collaboration（OSOA）.SCA service component architecture，assembly model specification version 1.00[EB/OL].（2007）[2011-06].http：//www.osoa.org/download/attachments/35/SCA Assembly Model V100.pdf.

[8]Pervez Z，Khattak A M，Lee S，et al.Dual validation framework for multi-tenant SaaS architecture[C]//Proceedings of the5th InternationalConferenceon Future Information Technology（FutureTech），Busan，Korea（South），2010：1-5.

[9]Zhu X，Wang S.Software customization based on model-driven architecture over SaaS platforms[C]//Proceedings of InternationalConference on Managementand Service Science（MASS’09），Beijing，China，2009：1-4.

[10]Xue H，Du R，Huang H.Research on version-based customizableERP systems[M].Hefei：HefeiIndustrialUniversity Press，2003：875-878.

[11]Candan K S，Li W，Phan T，et al.Frontiers in information and software as services[C]//Proceedings of IEEE 25th InternationalConferenceon DataEngineering，Shanghai，China，2009：1761-1768.

[12]Georgakopoulos D，Hornick M.An overview of workflow management：from process modeling to workflow automation infrastructure[J].Distributed and Parallel Databases，1995，3（2）：119-153.

[13]IBM.Web services flow language（WSFL）[EB/OL].（2009）[2011-06].http：//www.ibm.com/software/solutions/webservices/pdf/WSFL.pdf.

[14]WfMC.Workflow processdefinition interface-xmlprocess definition language，Document Number WFMC-TC-1025.2001.

[15]Leymann F，RollerD.Production workflow-conceptsand techniques[M].[S.l.]：Prentice Hall PTR，2000.

[16]Anstett T，Leymann F，Mietzner R，et al.Towards BPEL in the cloud：exploiting different delivery models for the execution of business processes[C]//Proceedings of the World ConferenceonServices-I，Los Angeles，CA，USA，2009：670-677.

[17]Mietzner R，Leymann F.Generation of BPEL customization processes for SaaS applications from variability descriptors[C]//Proceedingsofthe InternationalConference on Services Computing（SCC 2008），Honolulu，Hawaii，USA，2008：359-366.

[18]Mietzner R，Metzger A，Leymann F，et al.Variability modeling to support customization and deployment of multi-tenantaware software asa Service applications[C]//Proceedings of the ICSE Workshop on Principles of Engineering Service Oriented Systems（PESOS 2009），Vancouver，Canada，2009：18-25.

[19]Wang Y，Song M，Song J.An extended distributed OSGi architecture for implementation of SOA[C]//Proceedings of the International Conference on Advanced Intelligence and Awarenss Internet（AIAI），Beijing，China，2010：416-419.

[20]Chen J，Huang L.Dynamic service update based on OSGi[C]//Proceedings of WRI World Congress on Software Engineering（WCSE’09），Xiamen，China，2009：493-497.

[21]Eclipse，EclipseSource[EB/OL].（2010）[2011-06].http：//eclipsesource.com/en/eclipse/equinox-osgi-overview/.