詹云橋，段隆振

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

1 引言

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

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

2 相關(guān)工作

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

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

3 柔性服務(wù)

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

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

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

圖2 柔性SaaS模式

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

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

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

圖3 劃分步驟

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

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

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

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

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

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

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

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

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

圖4 核心類圖

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

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

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

圖6 Bundle狀態(tài)圖

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

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

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

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

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

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

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

4.1 項(xiàng)目描述

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

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

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

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

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

表2 總體對(duì)比

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

4.3 對(duì)比分析

柔性SaaS層將Hadoop中的MapReduce和HDFS分別作為分布式計(jì)算（編程模型）及分布式文件存儲(chǔ)的基礎(chǔ)平臺(tái)。因?yàn)镠adoop是由Java語(yǔ)言開發(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)境為L(zhǎng)inux+Eclipse+Hbase+Hadoop，支持框架 Equinox，每個(gè)服務(wù)必須實(shí)現(xiàn) BundleActivator接口中的 start（）和 stop（）方法，以便Equinox框架控制每個(gè)服務(wù)的啟動(dòng)、卸載、停止。插件管理程序主要由單例類PluginsManager來(lái)控制各個(gè)插件的注冊(cè)、嵌入、卸載等功能，其中注冊(cè)功能主要是告知有新開發(fā)的插件加入系統(tǒng)，以便將來(lái)查找或調(diào)用插件，嵌入功能將插件插入相應(yīng)服務(wù)，擴(kuò)展服務(wù)功能，卸載功能對(duì)應(yīng)于嵌入功能是解除服務(wù)相應(yīng)的功能。

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

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

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

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

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

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

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

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