基于柔性思想裝配云服務(wù)的研究

詹云橋，段隆振

南昌大學(xué) 信息工程學(xué)院，南昌 330031

1 引言

軟件即服務(wù)（SaaS）[1]是一種軟件部署模型，通過它，服務(wù)提供者可按照客戶需求將一種應(yīng)用作為服務(wù)提供給客戶使用，數(shù)據(jù)及程序從臺式PC機(jī)和聯(lián)合服務(wù)器中被移除，而被安裝在云中的計算機(jī)中[2]，不再像以前，需要下載相應(yīng)安裝文件到本地系統(tǒng)，然后，進(jìn)行安裝、運(yùn)行、維護(hù)等一系列過程。這無形中增加了用戶的負(fù)擔(dān)，更重要的是，用戶時常被迫為他們所不需要的功能而付費(fèi)。

但是，有許多制約因素限制企業(yè)大規(guī)模地應(yīng)用SaaS化服務(wù)，如：由于多租戶是SaaS的關(guān)鍵特性之一[3]，即只有唯一實(shí)例運(yùn)行在SaaS應(yīng)用中，所以，它必須滿足所有個性化需要，如：異構(gòu)數(shù)據(jù)、流程規(guī)則，以及業(yè)務(wù)規(guī)則，這樣一來，SaaS應(yīng)用模型將會非常復(fù)雜，并且，如果每個租戶必須將他們的業(yè)務(wù)邏輯包含在這個模型中，將很難保證他們業(yè)務(wù)邏輯的私密性[4]。而導(dǎo)致這些制約因素產(chǎn)生的最根本原因是沒有有效的方法去指引如何設(shè)計靈活且可伸縮的服務(wù)，以及如何高效地組裝這些服務(wù)。有鑒于此，本文在柔性思想的基礎(chǔ)上，提出一套有效的方法來介紹如何設(shè)計及實(shí)現(xiàn)服務(wù)，旨在幫助設(shè)計及開發(fā)人員搭建既經(jīng)濟(jì)又高效的彈性云服務(wù)平臺。

2 相關(guān)工作

目前，許多研究工作傾向于探討如何使服務(wù)提供者開發(fā)更柔性的服務(wù)以處理單實(shí)例與多租戶之間的不平衡。例如，文獻(xiàn)[5]認(rèn)為一個應(yīng)用應(yīng)該被分為兩部分：第一部分所包含的功能應(yīng)該是固定的，并且能夠被所有的用戶所使用；第二部分應(yīng)該被描述[6]為可配置的元數(shù)據(jù)，這些確切的租戶數(shù)據(jù)應(yīng)該被每一個新的用戶所部署。因此，在服務(wù)組件架構(gòu)（標(biāo)準(zhǔn)的多租戶模型，SCA[7]）的基礎(chǔ)上，引進(jìn)了一種能夠提供服務(wù)模板及解決思路的包格式。為了支持多租戶服務(wù)，文獻(xiàn)[8]介紹了一種雙重驗(yàn)證，此雙重驗(yàn)證的業(yè)務(wù)規(guī)則是從服務(wù)中抽取出來的；通過唯一的服務(wù)實(shí)現(xiàn)去處理來自不同租戶的請求。因此，不需要為每個租戶單獨(dú)提供服務(wù)。在分析業(yè)務(wù)流程定制研究現(xiàn)狀時，文獻(xiàn)[9]認(rèn)為，以版本為基礎(chǔ)的主要策略是開發(fā)擁有完整功能，面向大眾目標(biāo)且高標(biāo)準(zhǔn)化的軟件產(chǎn)品，并且，在特定的功能模塊上預(yù)先定義一些參數(shù)，以便允許用戶通過設(shè)定參數(shù)去描述軟件[10]，而且，這些軟件系統(tǒng)的流程定制方式僅通過一些選項(xiàng)、參數(shù)配置、可視化設(shè)計去完成，這是非常簡單的，因?yàn)?，以版本為基礎(chǔ)的話，這些定制過程會被限定在預(yù)先定義的范圍內(nèi)。為了改變這一情況，文獻(xiàn)[9]通過介紹服務(wù)模型（或模板）概念和特定域語言STML（服務(wù)模板標(biāo)記語言），在SaaS平臺上提出了一種以MDA為基礎(chǔ)的SOA軟件定制方法。STML工具的主要模塊包含網(wǎng)頁門戶、服務(wù)定制和組裝工具（SCIT）、服務(wù)執(zhí)行平臺（SEP）、服務(wù)模板注冊（STR），尤其SCIT向用戶提供工具，以支持用戶用STML語言去編輯、核查、驗(yàn)證、恢復(fù)服務(wù)描述文件，并且，將這些文件轉(zhuǎn)換為源碼程序以適應(yīng)多變性。

另一方面，為了靈活地產(chǎn)生業(yè)務(wù)流程，工作流語言被用來將單獨(dú)的業(yè)務(wù)活動整合到完整業(yè)務(wù)流程中，其中每個單獨(dú)的業(yè)務(wù)活動由不同的服務(wù)所實(shí)現(xiàn)[11]。而且，企業(yè)可以通過工作流語言所提供的平臺去有效地編排新的“完整服務(wù)”[12]，例如，IBM公司的以XML為基礎(chǔ)的網(wǎng)頁服務(wù)流語言（WSFL[13]）、微軟 XLANG[13]、工作流管理集合（WfMC）和XML流程定義語言（XPDL[14]），所有這些方法都提供了將服務(wù)編排到“端到端”的企業(yè)應(yīng)用中去。再者，作為業(yè)務(wù)流程編排語言的BPEL被廣泛認(rèn)為對于應(yīng)用的靈活性是非常有效的[15]，因?yàn)樗试S改變編排邏輯（用BPEL描述）時獨(dú)立于服務(wù)[16]?？梢钥闯觯壳暗难芯恐魂P(guān)注于服務(wù)結(jié)構(gòu)的外部，并沒有過多地了解分析它的內(nèi)部狀態(tài)，唯有靈活動態(tài)的服務(wù)結(jié)構(gòu)構(gòu)造出的云服務(wù)系統(tǒng)才能適應(yīng)未來多變的需求環(huán)境。

3 柔性服務(wù)

隨著時間的推移，外界的環(huán)境及條件在不斷地發(fā)生變化，唯有動態(tài)適應(yīng)這種變化，才能繼續(xù)生存及發(fā)展。柔性思想的核心理念是面對復(fù)雜多變的環(huán)境，本體擁有可靈活組合的結(jié)構(gòu)，以形成不同的形態(tài)，去應(yīng)對外界的環(huán)境。在SaaS模式中，外界的環(huán)境即用戶需求，而本體結(jié)構(gòu)即服務(wù)結(jié)構(gòu)。傳統(tǒng)的SaaS模式如圖1所示。

圖1 傳統(tǒng)的SaaS模式

提供給客戶的服務(wù)是運(yùn)營商部署在云計算基礎(chǔ)設(shè)施上的應(yīng)用程序，并且，服務(wù)必須考慮各種類型的用戶對它的特殊要求。用戶可以在各種設(shè)備上通過瘦客戶端界面訪問，如瀏覽器。消費(fèi)者不需要管理或控制任何云計算基礎(chǔ)設(shè)施，包括網(wǎng)絡(luò)、服務(wù)器、操作系統(tǒng)、存儲等等。服務(wù)提供商開發(fā)相應(yīng)的服務(wù)并在SaaS平臺上進(jìn)行注冊，然后用戶通過SaaS平臺定制所需的服務(wù)以得到相應(yīng)的業(yè)務(wù)功能。但在此模式下，當(dāng)大量的用戶使用云服務(wù)平臺時，會帶來諸多問題。首先，由于沒有靈活且可組裝的服務(wù)結(jié)構(gòu)，隨著用戶大量增加，服務(wù)數(shù)量也會大量增加。所以，由此模式所搭建的系統(tǒng)對于外界的變化非常敏感，適應(yīng)性差。第二，使用云服務(wù)系統(tǒng)的用戶大部分來自各行各業(yè)，他們對于同一服務(wù)的需求層次是不盡相同的，即他們對某一服務(wù)所提供的大部分功能是趨同的，但他們對這項(xiàng)服務(wù)可能存在技術(shù)上或業(yè)務(wù)性上的需求差異。對此有兩種解決方式：第一種，新增加若干個服務(wù)以滿足不同用戶的特殊需求，這無疑增加了系統(tǒng)的額外負(fù)擔(dān)；第二種，將不同用戶對于同一服務(wù)的不同需求功能點(diǎn)全部包含在一個服務(wù)內(nèi)，大部分云服務(wù)系統(tǒng)采用了此方式。很明顯，第二種方式增加了單個服務(wù)的復(fù)雜性，且可維護(hù)性差，再者，系統(tǒng)開發(fā)人員也不可能預(yù)測所有未來用戶的服務(wù)差異。若考慮以柔性方式構(gòu)建靈活且可組裝的服務(wù)結(jié)構(gòu)，則可提高系統(tǒng)的適應(yīng)性，柔性SaaS模式如圖2所示。

圖2 柔性SaaS模式

在插件結(jié)構(gòu)的應(yīng)用系統(tǒng)中，程序并不是單一的執(zhí)行文件，而是由主程序和若干外部模塊組成。這些模塊按照一定的規(guī)則編寫，可以通過配置文件靈活地加入到系統(tǒng)中，也可以在程序運(yùn)行時動態(tài)地加入到系統(tǒng)中。由于可以靈活機(jī)動地增加減少替換這些模塊，通常把插入到系統(tǒng)中的模塊稱為插件。在柔性SaaS模式下，通過動態(tài)組裝框架，云服務(wù)系統(tǒng)可以為不同用戶裝配不同的服務(wù)及插件。這樣一來，不同用戶對一個服務(wù)的細(xì)微差異可以通過組裝不同的插件來消除，既降低了單個服務(wù)的復(fù)雜性也減少了服務(wù)的數(shù)量。另外一方面，對于大量不同用戶的不同需求，可以先考慮通過現(xiàn)有服務(wù)及插件組裝成符合用戶新需求的服務(wù)，以減少新需求對系統(tǒng)的影響。以柔性SaaS模式構(gòu)建云服務(wù)系統(tǒng)必須經(jīng)過兩個核心步驟：服務(wù)規(guī)劃和構(gòu)建服務(wù)擴(kuò)展結(jié)構(gòu)。以下詳述這兩個步驟。

3.1 服務(wù)規(guī)劃

服務(wù)規(guī)劃是構(gòu)建柔性云服務(wù)平臺的基礎(chǔ)。在設(shè)計服務(wù)結(jié)構(gòu)及數(shù)量時，必須在獨(dú)立性和復(fù)用性中作一個權(quán)衡。如果只考慮服務(wù)間的獨(dú)立性，則勢必增加單個服務(wù)的復(fù)雜性，而且服務(wù)擴(kuò)展性會變差，在云平臺的分布式環(huán)境中，如果只考慮服務(wù)復(fù)用性，則勢必增加服務(wù)間的調(diào)用次數(shù)，從而降低整個系統(tǒng)的運(yùn)行性能。服務(wù)規(guī)劃應(yīng)從兩個方面去考慮：服務(wù)定義和服務(wù)粒度。服務(wù)定義應(yīng)從業(yè)務(wù)角度考慮，使服務(wù)功能更切合業(yè)務(wù)流程中的實(shí)際情況，而服務(wù)粒度則應(yīng)更多的從技術(shù)方面出發(fā)，使得服務(wù)粒度的規(guī)模在不增加整個系統(tǒng)的復(fù)雜性的前提下，提高服務(wù)的復(fù)用性。綜合以上兩個方面，給出規(guī)劃方法的具體步驟，如圖3所示。

圖3 劃分步驟

（1）綜合收集，將業(yè)務(wù)領(lǐng)域內(nèi)的知識進(jìn)行收集、歸納、總結(jié)。全面了解業(yè)務(wù)邊界，掌握每個關(guān)鍵業(yè)務(wù)活動在業(yè)務(wù)領(lǐng)域中的邏輯依賴關(guān)系。

（2）單元切分，從用戶的角度為出發(fā)點(diǎn)，以業(yè)務(wù)目的為界限將業(yè)務(wù)活動中包括的“最小”功能劃分出來。以業(yè)務(wù)目的為界限來劃分業(yè)務(wù)活動，旨在保證劃分出來的最小業(yè)務(wù)功能在業(yè)務(wù)領(lǐng)域中具有完整的業(yè)務(wù)意義，否則劃分結(jié)果會倚重技術(shù)層面，過多考慮獨(dú)立性、系統(tǒng)性能等指標(biāo)，偏離業(yè)務(wù)實(shí)際。以用戶的角度作為劃分的基點(diǎn)，主要是考慮將來用戶使用SaaS系統(tǒng)平臺的便利性及更多地以操作主體的視角來考察劃分結(jié)果的合理性。強(qiáng)調(diào)將業(yè)務(wù)活動的“最小”功能切分出來，是為了盡可能地提高服務(wù)的復(fù)用性。

（3）獨(dú)立合并，將在業(yè)務(wù)邏輯上具有較強(qiáng)依賴關(guān)系的核心功能劃歸為單個獨(dú)立服務(wù)。依賴關(guān)系包括前向依賴即A-＞B，后向依賴A＜-B，雙向依賴A＜-＞B，其中雙向依賴的依賴關(guān)系最強(qiáng)。雖然，將具有較強(qiáng)依賴關(guān)系的功能劃分為單個服務(wù)會導(dǎo)致服務(wù)“膨脹”，但在業(yè)務(wù)領(lǐng)域中的核心功能及其之間的依賴關(guān)系是相對穩(wěn)定的，這樣一來，在分布式環(huán)境中，可以有效地減少服務(wù)之間的調(diào)用，提高系統(tǒng)運(yùn)行性能。

歸根到底，服務(wù)規(guī)劃的任務(wù)是將業(yè)務(wù)領(lǐng)域內(nèi)的整個流程切分成具有相對獨(dú)立性的基礎(chǔ)服務(wù)，這些基礎(chǔ)服務(wù)是構(gòu)建服務(wù)擴(kuò)展結(jié)構(gòu)的起點(diǎn)。

3.2 構(gòu)建服務(wù)擴(kuò)展結(jié)構(gòu)

一個應(yīng)用模板是作為服務(wù)提供給用戶的，這個應(yīng)用的某些部分是不確定的或是需延遲定義的，并且，這部分應(yīng)該能夠被每一個租戶所定制，以便滿足它們特殊的需求[17]。再者，不同的用戶對于一個用戶有著不同的需求，這使得SaaS應(yīng)用必須是可配置的以應(yīng)對這些不同的需求，例如，不同的用戶可能會使用服務(wù)來展示他們自己公司的標(biāo)識[18]。因此，對于一個服務(wù)來說可以分為兩個部分：第一部分是其基本功能，即所有定制此服務(wù)的用戶都會使用的功能。第二部分為擴(kuò)展功能，即不同用戶使用同一服務(wù)的差異部分?；竟δ芡ㄟ^“接口-實(shí)現(xiàn)類”的方式開發(fā)，為未來服務(wù)基本功能的升級和維護(hù)提供方便，而每一個擴(kuò)展部分即為一個插件，擴(kuò)展部分借鑒基于插件方式的軟件開發(fā)，采用具有預(yù)見性及開放性的“接口”，提高插件的開發(fā)生產(chǎn)率。當(dāng)系統(tǒng)運(yùn)行時，插件借由動態(tài)組裝框架靈活插入服務(wù)的基本功能中組裝成“完整服務(wù)”提供給用戶，插件的主要用途：（1）屏蔽用戶使用同一服務(wù)的細(xì)微差異，從而使服務(wù)具有一定的通用性；（2）協(xié)調(diào)服務(wù)之間的調(diào)用關(guān)系，使得用戶定制的服務(wù)之間可以柔性的調(diào)用，組成完整的業(yè)務(wù)流程；（3）動態(tài)插拔插件，使得服務(wù)具有一定的伸縮性。傳統(tǒng)SaaS模式為“單實(shí)例多租賃”，在此基礎(chǔ)上，通過引入“接口-實(shí)現(xiàn)類”方式、插件、動態(tài)組裝框架，形成“單實(shí)例多擴(kuò)展插件多租賃”的柔性SaaS模式。

為了使插件方便地插拔于服務(wù)，靈活地擴(kuò)展或去除部分功能，并且降低插件與服務(wù)之間的耦合度，以便提高開發(fā)效率及擴(kuò)展性，柔性SaaS模式的核心類圖如圖4所示。

服務(wù)類Service及插件Plugin類有各自的接口，分別可提供不同的實(shí)現(xiàn)方式，以產(chǎn)生多種實(shí)現(xiàn)類。AbstractServiceProxy是用戶使用“完整服務(wù)”的一個接口，此“完整服務(wù)”的實(shí)現(xiàn)類Proxy是由構(gòu)造類Constructor通過動態(tài)代理模式產(chǎn)生的。由此看來，每個服務(wù)可以通過動態(tài)代理模式和多個插件動態(tài)組合成“完整服務(wù)”供用戶使用，且服務(wù)類與插件類的實(shí)現(xiàn)方式可相對獨(dú)立，有利于提高系統(tǒng)的擴(kuò)展性并降低耦合度。構(gòu)造類Constructor動態(tài)產(chǎn)生服務(wù)代理類的方式，如圖5所示。

由圖5可以看出，構(gòu)造類通過反射機(jī)制將服務(wù)類及插件類中的屬性和方法映射出來，并構(gòu)造出同時擁有服務(wù)類和插件類所有功能的新類Proxy。當(dāng)用戶定制好所需的功能或重新定制后，柔性SaaS平臺將通過動態(tài)組裝框架將用戶目前所定制的“完整服務(wù)”進(jìn)行動態(tài)編譯直接使用戶擁有新的功能，而不需重啟系統(tǒng)。

圖4 核心類圖

圖5 服務(wù)代理類產(chǎn)生過程圖

動態(tài)組裝框架基于OSGi體系架構(gòu)，OSGi通過SOA為服務(wù)共享普通信息，這是最小的集合單元，并且，每個服務(wù)可以通過共享資源與其他服務(wù)進(jìn)行交互[19]。在一個動態(tài)擴(kuò)展的OSGi環(huán)境中，OSGi框架管理Bundle的安裝和更新，同時也管理Bundle和服務(wù)之間的依賴關(guān)系，服務(wù)的更新是通過更新合作的Bundles實(shí)現(xiàn)的[20]。一個Bundle可能處于六種狀態(tài)，如圖6所示。

圖6的各個狀態(tài)說明：已安裝。安裝完成，本地資源成功加載。已解析。依賴關(guān)系滿足，這個狀態(tài)意味著該Bundle要么已經(jīng)準(zhǔn)備好運(yùn)行，要么是被停止了。啟動中。Bundle正在被啟動，BundleActivator的start（）方法已經(jīng)被調(diào)用但還沒有返回。停止中。Bundle正在被停止，BundleActivator的stop（）方法已經(jīng)被調(diào)用但還沒有返回。運(yùn)行。Bundle被成功地啟動，并正在運(yùn)行。已卸載。Bundle被卸載被無法進(jìn)入其他狀態(tài)。

圖6 Bundle狀態(tài)圖

Equinox[21]框架是Eclipse組織基于OSGi Release 4的一個實(shí)現(xiàn)框架，它實(shí)現(xiàn)了OSGi規(guī)范的核心框架和許多標(biāo)準(zhǔn)框架服務(wù)的實(shí)現(xiàn)。柔性SaaS模式中的動態(tài)組裝框架為Equinox。通過它，將插件動態(tài)插入特定服務(wù)中的基本功能部分形成具有特殊功能的“完整服務(wù)”。

通過Equinox框架及插件體系結(jié)構(gòu)，柔性SaaS運(yùn)行模式如圖7所示。柔性SaaS框架主要由三大部件組成，即插件管理程序、Equinox、系統(tǒng)平臺接口。插件管理程序的主要功能是向插件提供插入相應(yīng)服務(wù)的接口，插件的開發(fā)只需符合接口規(guī)范，就可通過插件管理程序插入到相應(yīng)服務(wù)中，擴(kuò)展其功能。對于服務(wù)而言，插件管理程序如何通過插件擴(kuò)展其功能是透明的。用戶功能的更新只需要通過構(gòu)造類Constructor將所涉及的插件及基礎(chǔ)服務(wù)動態(tài)生成符合用戶最終需求的服務(wù)代理類，最后由Equinox框架將經(jīng)過重新編譯的服務(wù)代理類代碼嵌入運(yùn)行的系統(tǒng)中。由此可見，一個用戶更新其服務(wù)功能的整個過程對于運(yùn)行中的系統(tǒng)以及其他用戶而言，是無影響的。系統(tǒng)平臺接口的功能涵蓋展示系統(tǒng)服務(wù)及其擴(kuò)展功能、響應(yīng)用戶定制需求、計費(fèi)等。

新用戶使用本系統(tǒng)的過程：首先，用戶通過系統(tǒng)平臺接口了解本系統(tǒng)平臺所提供的服務(wù)及插件的功能和計費(fèi)規(guī)格等信息；然后，選擇所需的服務(wù)及插件并提交給系統(tǒng)，平臺系統(tǒng)數(shù)據(jù)庫中有一張記錄所有用戶所定制的服務(wù)和插件的編號、定制時間等信息的功能表；之后，插件管理程序根據(jù)用戶定制的插件編號查找出相應(yīng)位置，并提交給構(gòu)造類Constructor；隨后構(gòu)造類通過動態(tài)代理模式將用戶所定制的基礎(chǔ)服務(wù)與相應(yīng)插件組成“完整服務(wù)”；最后，Equniox將“完整服務(wù)”封裝成Bundle并進(jìn)行動態(tài)編譯、加載、部署，系統(tǒng)平臺接口隨之動態(tài)更新當(dāng)前用戶所定制的服務(wù)。

4 實(shí)驗(yàn)分析

下面將某省物流公共信息平臺在線交易系統(tǒng)作為實(shí)例，詳細(xì)描述如何在柔性SaaS模式下建立云服務(wù)系統(tǒng)。

圖7 柔性SaaS運(yùn)行模式圖

圖8 在線交易系統(tǒng)主流程圖

4.1 項(xiàng)目描述

某省物流公共信息平臺在線交易系統(tǒng)旨在幫助貨源方和車源方在線完成交易，通過該平臺，貨源方可以找到運(yùn)價合適且信用較高的車源方，另一方面，車源方可以實(shí)時向平臺提供車輛運(yùn)行情況，以便貨源方通過平臺及時了解車輛狀態(tài)，這樣一來，車源方可以降低空載率。此物流公共信息平臺在線交易系統(tǒng)的流程，如圖8所示。

下一步即可按照“服務(wù)規(guī)劃”及“構(gòu)建服務(wù)擴(kuò)展結(jié)構(gòu)”步驟，分析設(shè)計某省物流公共信息平臺在線交易系統(tǒng)云服務(wù)構(gòu)建方式。

4.2 物流服務(wù)粒度設(shè)計

根據(jù)項(xiàng)目描述，結(jié)合柔性方法，某省物流公共信息平臺的服務(wù)粒度設(shè)計，如表1所示。

表1 服務(wù)結(jié)構(gòu)

表2 總體對比

以上每個服務(wù)的基本功能由服務(wù)提供者Bundle實(shí)現(xiàn)，作為插件的擴(kuò)展功能由插件類實(shí)現(xiàn)，當(dāng)用戶登陸后，插件通過插件管理程序動態(tài)插入服務(wù)提供者Bundle中，最后動態(tài)組裝框架Equinox向用戶提供“完整服務(wù)”。

4.3 對比分析

柔性SaaS層將Hadoop中的MapReduce和HDFS分別作為分布式計算（編程模型）及分布式文件存儲的基礎(chǔ)平臺。因?yàn)镠adoop是由Java語言開發(fā)的，所以，選用J2EE中的相關(guān)技術(shù)組件標(biāo)準(zhǔn)作為開發(fā)應(yīng)用服務(wù)層的技術(shù)框架，表現(xiàn)層組件技術(shù)標(biāo)準(zhǔn)JSP、Web服務(wù)器Weblogic，開發(fā)環(huán)境為Linux+Eclipse+Hbase+Hadoop，支持框架 Equinox，每個服務(wù)必須實(shí)現(xiàn) BundleActivator接口中的 start（）和 stop（）方法，以便Equinox框架控制每個服務(wù)的啟動、卸載、停止。插件管理程序主要由單例類PluginsManager來控制各個插件的注冊、嵌入、卸載等功能，其中注冊功能主要是告知有新開發(fā)的插件加入系統(tǒng)，以便將來查找或調(diào)用插件，嵌入功能將插件插入相應(yīng)服務(wù)，擴(kuò)展服務(wù)功能，卸載功能對應(yīng)于嵌入功能是解除服務(wù)相應(yīng)的功能。

傳統(tǒng)SaaS模式下構(gòu)建的產(chǎn)品包括Salesforce.com、NetSuite等，它們的共同的特點(diǎn)是沒有采用靈活的插件結(jié)構(gòu)及動態(tài)框架Equinox的支持。在業(yè)務(wù)層面，傳統(tǒng)SaaS模式中服務(wù)的功能必須包含所有使用此服務(wù)用戶的業(yè)務(wù)要求，如表1所示。傳統(tǒng)SaaS模式中的搜索車輛服務(wù)必須能夠通過出發(fā)地、目的、載重、車高等條件搜索相應(yīng)車輛，這樣一來，將導(dǎo)致單個服務(wù)的粒度過大，可維護(hù)性差，更重要的是，某些用戶根本用不到服務(wù)中所包含的所有功能，既增加了用戶使用服務(wù)的無謂費(fèi)用，又增加了使用服務(wù)的復(fù)雜性。在技術(shù)層面，與傳統(tǒng)SaaS模式相比，柔性SaaS模式可以通過兩種方式去應(yīng)對用戶需求變化：現(xiàn)有插件的組合去調(diào)整系統(tǒng)內(nèi)部結(jié)構(gòu)或?qū)⑿麻_發(fā)的插件動態(tài)插入使得系統(tǒng)擁有新的擴(kuò)展功能。兩種模式的服務(wù)方式如圖9所示。

圖9 服務(wù)方式對比

從總體性能參數(shù)來看，兩種模式的對比如表2所示。

由于采用了插件結(jié)構(gòu)，柔性SaaS模式中的服務(wù)只須抽離出所有用戶的共同要求，所以服務(wù)包含的內(nèi)容少，粒度小，復(fù)雜性低，其他細(xì)微的需求差異或需求變化可以由插件來調(diào)整。另外一方面，因?yàn)樵跇I(yè)務(wù)領(lǐng)域中所有用戶的共同要求是相對穩(wěn)定的，這將有利于對服務(wù)的維護(hù)。對于細(xì)微的需求差異或需求變化，系統(tǒng)可以將現(xiàn)有插件靈活組合或開發(fā)新的插件靈活插入服務(wù)，既擴(kuò)展了現(xiàn)有服務(wù)的功能又減少了對現(xiàn)有系統(tǒng)的影響。

柔性SaaS模式的高擴(kuò)展性、靈活結(jié)構(gòu)都是建立在前期服務(wù)劃分及插件管理程序的設(shè)計工作之上的，服務(wù)劃分工作既要考慮業(yè)務(wù)領(lǐng)域內(nèi)的實(shí)際情況，又要在技術(shù)層面上考慮插件通過插件管理程序插入服務(wù)的可操作性及便利性，所以，相對于傳統(tǒng)SaaS模式，柔性SaaS模式的系統(tǒng)設(shè)計工作較困難。

由于Equinox框架的加入，柔性SaaS模式具備了運(yùn)行連續(xù)性及更新動態(tài)性的特點(diǎn)，具體表現(xiàn)在：當(dāng)系統(tǒng)需要升級時，可以將需要已升級的代碼部分交給Equinox框架，這些代碼將被動態(tài)編譯，并直接被部署到運(yùn)行中的系統(tǒng)，這個過程并不會影響到不需升級的部分。當(dāng)用戶需要修改定制的服務(wù)功能時，構(gòu)造類Constructor根據(jù)定制信息動態(tài)產(chǎn)生服務(wù)代理類Proxy并提交給Equinox框架，然后直接被嵌入用戶的功能列表中。

從圖9及表2中可以看出，柔性SaaS模式在適應(yīng)性及可擴(kuò)展性方面有較好的改進(jìn)，但這都是以穩(wěn)定的服務(wù)結(jié)構(gòu)及靈活的插件體系結(jié)構(gòu)為前提的。

5 總結(jié)語

以目前云計算為基礎(chǔ)，通過對SaaS層上有關(guān)服務(wù)的問題分析，提出一種柔性SaaS模式。首先查閱并了解目前關(guān)于如何解決在SaaS層上靈活提供服務(wù)，方便有效地讓用戶形成自己獨(dú)立的業(yè)務(wù)流程等問題的現(xiàn)狀，然后針對這些解決方法或思路存在的問題，提出了服務(wù)規(guī)劃并構(gòu)建服務(wù)等級結(jié)構(gòu)，最后，通過一個具體案例進(jìn)行研究分析。實(shí)驗(yàn)證明，在保證不提高系統(tǒng)復(fù)雜性的前提下，經(jīng)過該柔性方法裝配后的服務(wù)在業(yè)務(wù)獨(dú)立性方面更強(qiáng)，在適應(yīng)性方面，具備滿足來自不同部門或不同行業(yè)人員的功能要求。

本文提出的柔性思想中的服務(wù)劃分部分著重研究業(yè)務(wù)領(lǐng)域內(nèi)的理論邏輯部分，需要大量人工分析及干預(yù)，技術(shù)輔助不足。另一方面，構(gòu)建服務(wù)擴(kuò)展結(jié)構(gòu)中的插件管理程序部分需要編程人員定義帶有預(yù)見性的接口，以方便后期插件的插入，但接口總有不適用的時候。因此，下一階段的工作是根據(jù)服務(wù)劃分理論開發(fā)出一套適合某一業(yè)務(wù)領(lǐng)域的服務(wù)分析框架，減少開發(fā)人員花費(fèi)在分析某領(lǐng)域內(nèi)的業(yè)務(wù)時間，將更多的精力放在考慮系統(tǒng)平臺運(yùn)行效率及擴(kuò)展性等問題上；同時，提出一種比基于插件開發(fā)方式更具擴(kuò)展性的軟件開發(fā)方式，讓已經(jīng)在系統(tǒng)上運(yùn)行的服務(wù)具備永遠(yuǎn)可以獲取新功能的能力。

[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/.