• 
    

    
    

      99热精品在线国产_美女午夜性视频免费_国产精品国产高清国产av_av欧美777_自拍偷自拍亚洲精品老妇_亚洲熟女精品中文字幕_www日本黄色视频网_国产精品野战在线观看 ?

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

      2013-03-03 01:51:48詹云橋段隆振
      計算機(jī)工程與應(yīng)用 2013年7期
      關(guān)鍵詞:插件柔性框架

      詹云橋,段隆振

      南昌大學(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/.

      猜你喜歡
      插件柔性框架
      一種柔性拋光打磨頭設(shè)計
      框架
      灌注式半柔性路面研究進(jìn)展(1)——半柔性混合料組成設(shè)計
      石油瀝青(2021年5期)2021-12-02 03:21:18
      高校學(xué)生管理工作中柔性管理模式應(yīng)用探索
      廣義框架的不相交性
      自編插件完善App Inventor與樂高機(jī)器人通信
      電子制作(2019年22期)2020-01-14 03:16:34
      WTO框架下
      法大研究生(2017年1期)2017-04-10 08:55:06
      MapWindowGIS插件機(jī)制及應(yīng)用
      一種基于OpenStack的云應(yīng)用開發(fā)框架
      基于Revit MEP的插件制作探討
      广宗县| 永定县| 水城县| 阿坝县| 岳普湖县| 岚皋县| 报价| 镇沅| 玛沁县| 花莲市| 阜平县| 镶黄旗| 卢湾区| 苏州市| 宝应县| 韶关市| 明光市| 梅河口市| 怀来县| 耿马| 唐河县| 临海市| 乌兰察布市| 绥棱县| 潞城市| 镇巴县| 襄城县| 陵川县| 西藏| 嘉兴市| 阜新| 三亚市| 黑山县| 治多县| 彰武县| 临泽县| 婺源县| 内乡县| 阳春市| 出国| 九江县|