基于柔性思想裝配云服務的研究

詹云橋，段隆振

南昌大學 信息工程學院，南昌 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/.