融合軟件商店和Web聚合的SaaS軟件開發模型*

馮 翔 ，殷月明 ，吳永和

（1.華東師范大學網絡教育學院 上海 200062；2.上海數字化教育裝備工程技術研究中心 上海 200062；3.上海貝爾股份有限公司 上海201206）

1 引言

當前的SaaS主要由服務商開發成套的軟件，這些軟件由低耦合、可組裝的軟件實體構成，因此可提供基于模板和規則的定制功能來滿足多租戶應用需求，其最大優勢在于提供多租戶服務，用規模效應來降低成本。多租戶相關的技術是SaaS中的核心關鍵技術，如可配置的多租戶SaaS應用、單實例支持多租戶的SaaS應用架構、可伸縮的多租戶SaaS應用架構等，這些技術從服務的角度保障多租戶系統的彈性、擴展性和性能，確保SaaS軟件交付模式的成功，但還不能解決需求交集小、多領域、多變的租戶個性化需求問題，而這個問題需要從軟件開發模型的角度來解決。從SaaS發展歷史來看，其典型應用演化自CRM(customer relationship management)、ERP（enterprise resource planning）、MIS(management information system)、HRM(human resource management)等，面向的是中型以上具有明確上述系統需求的企業，它們的需求集合存在較大的交集，一旦需求集合交集過小，SaaS將難以適應。據埃森哲2009年11月發布的《中國云計算調研報告》數據，我國的中小企業數量超過千萬。由于行業千差萬別，數量巨大，這些中小企業的SaaS應用需求集合交集較小，傳統SaaS軟件交付模式難以滿足這樣的需求。

近幾年發展起來的軟件商店模式，可滿足大量人群的個性化需求，而Web Mashup為快速情境應用[1，2]提供技術和模式支撐。在SaaS上整合軟件商店模式有利于提高應用豐富度，從而滿足個性化需求，基于此，本文基于Web2.0、Web聚合、網構軟件思想，設計一種融合SaaS和軟件商店的新型SaaS軟件開發架構，該架構源自電信2.0領域的研究，其目的是以輕量級方式整合電信和IT能力，從而為中小企業提供靈活、敏捷的信息化平臺支撐。

2 相關研究

Web的第一階段是基于超鏈接的靜態信息存儲網絡，隨著Web的發展，應用越來越多，各種結構之間的交互需求也越來越迫切；第二階段的Web2.0隨之也發展起來了，并由此催生了新一代的Web軟件開發技術和模式，一些公司和機構都已相繼展開研究[3，4]。

互聯網作為平臺是Web2.0中的核心原則之一[5]。隨著Web的平臺化，IT界的商業模式也在發生改變，新型應用模式誕生了，如聚合（mashup）對軟件行業產生了深遠影響，相對于傳統 I T應用有眾多優點[6]，因此越來越多的企業和學者對此展開研究，各種面向用戶的聚合系統[7]開始出現 ， 如 Y ahoo Pipe[8]、Intel Mash Maker[9]、SAP 的Enterprise2.0聚合平臺[10]、IBM 情境應用平臺[6]等。

Web聚合有兩種形式：一種是對于不同來源的數據和服務進行聚合，另一種是作為完整Web應用的包含UI、邏輯在內的一整套網頁功能被聚合，這種聚合下的典型代表是Widget/Gadget等。然而，Widget/Gadget僅表現簡單邏輯功能，現階段多數Widget平臺只負責將不同來源的Widget組織在一起展示，而沒有深度地將其進行業務聚合。開放聚合聯盟 (open mashup alliance,OMA)制定的EMML(enterprise mashup markup language)聚焦在后臺的數據聚合邏輯流程上[11]。

IBM的 Mashup Center[6]是基于聚合思想的企業級情景應用支撐系統，是Mashup應用企業的成功案例。Mashup Center不支持將互聯網上的普通網頁聚合到應用中，任何現有網頁和Web應用必須以IBM提供的Widget規范方式重新包裝之后打包為jar格式或war等格式發布,或通過聚合 H ub發布。

總之，將聚合應用于企業成為趨勢，但應用的深度和廣度還不夠，對于具有較強邏輯性的企業應用方面還需要深入研究：不依賴于特定廠商Widget/Gadget規范的Web應用聚合技術；在Web前端的業務邏輯構造；任意來源的Web應用組裝。網構軟件理論與技術在Web上的應用為解決這些問題提供了支撐。網構軟件是指在面向對象、軟件構件等技術支持下的軟件實體以主體化的軟件服務形式存在于Internet的各個節點上,各個軟件實體相互間通過協同機制進行跨網絡的互連、互通、協作和聯盟,從而形成一種與WWW 相類似的軟件Web(software Web)形態[12]。參考文獻[13]指出網構軟件可適應開放、動態、難控的網絡環境需求，它呈現出一種可演化、連續反應式、多目標適應的新系統形態。網構軟件系統強調的是以網絡為“土壤”，以可復用構件為“營養”來實現豐富多彩的新型應用程序，這是個性化軟件的重要基礎。

軟件商店模式充分體現了“長尾”效應，為軟件滿足個性化需求提供了較好的模式。雖然軟件商店取得了成功，但是商店應用的同質化逐漸暴露。這種問題在長尾坐標圖上反映為：橫軸過度，縱軸過低。即長尾在橫軸上非常之長，而對應的縱坐標指標，如單個軟件關注度、下載量、付費量則極度偏低。從短期看，這樣的態勢對運營商非常有利，而對多數開發者極其不利。從長遠看，對運營商也將逐漸變得不利，因為大量處于“長尾”上的開發者將不再愿意投入過多。

3 設計思想與方法

本文提出將軟件商店模式、SaaS和Web聚合模式進行整合，使得SaaS可向第三方軟件提供商開放，并具有可聚合任意開發商所接入的Web應用功能。這種模式的核心在于：讓軟件商店的開發者之間也開展軟件的共享和聚合，這種共享與聚合可以采用免費共享方式也可以采用付費方式。其宗旨就是，降低單體應用同質化，提高單體應用流通量，從而在提高平臺應用豐度的同時也關注了質量和收益。而要采用這樣的模式，則需要構建一種滿足軟件商店中軟件聚合需求的平臺。這里講的聚合著力點在于Web應用軟件的聚合，不是簡單的Widget/Gadget或者數據聚合，這些軟件可獨立運行，也可被組裝起來完成更大的需求目標，它不同于傳統意義上的組件復用。將這種軟件聚合的模式稱為Executable Web軟件模式。

為了將Web上的各種應用從更高層次進行聚合，就需要一種關于Web應用的發布、發現和集成機制。圖 1所示為 Web2.0及之前的示意，圖 2為Executable Web的示意，這兩個圖顯示了這兩種機制的不同[14]。Executable Web最初是Boothby[14]提到的一種想法，本文的思想與其相似，且字面含義明確,故沿用Executable Web這一概念，并借助軟件商店、SaaS等進行了拓展和完善，以此為核心設計服務于電信行業、中小企業以及開發者的SaaS生態環境。

Executable Web類似于W3C中的Web服務的架構[15]，不同的是，這種架構最終返回給調用程序或者用戶的是一個可直接使用的、具有UI交互能力的、完整意義上的應用程序，而不是需要繼續加工的面向機器的服務。就其本質來看，傳統 Web服務是 M2M（machine to machine），而這種服務既可以是M2M也可以是M2P（machine to person）。

圖3所示的Executable Web Ecosystem描述了基于Executable Web的SaaS生態環境。其主要組成為服務提供商、集成商、網頁提供商以及Executable Web支撐運營商（即SaaS運營商）。

服務提供商提供各種各樣的服務，包括SOAP Web服務、RESTful服務、RPC服務以及以腳本語言 (如 Google map JavaScript API)提供的Open API等。這些服務可以是免費的，也可以是收費的。

網頁提供商編寫各種各樣的Widget/Gadget，甚至較之更復雜的完備意義上的網頁，并將這些網頁提交到Executable Web支撐運營商。在提交網頁時，根據需要和特性，公布該網頁的目的、傳值方式、URL等。支撐運營商根據提交時的參數進行后臺索引、發布、管理。

集成商可在服務提供商、網頁提供商的服務及網頁基礎上編寫更多、更復雜的服務、網頁甚至大型應用。

支撐運營商負責管理底層服務，網頁服務的注冊、發布、管理，還負責提供用戶管理、平臺管理、開發者管理、計費管理、應用管理等功能支撐。

依據上述方法，設計了BellMashup Platform系統架構。

4 BellMash Platform系統架構

BellMash Platform系統架構如圖4所示，其主要部分功能如下。

BellMash Widget/Webpage、構件 Workbench作為軟件開發的SDE提供給開發者以提高開發速度、效率及支持軟件質量保證；Workbench可基于Eclipse開發，其中配置Web頁面開發向導，開發模板。

BellMash運營管理負責對開發者、構件、應用、運行平臺等進行管理。

BellMash Web服務器用于暴露各種服務，包括Web服務、RESTful服務等。

BellMash構件服務器是符合SCA規范的構建服務器，可采用Apache Tuscany搭建。SCA規范能夠采用依賴注入的技術將任意的服務進行組裝集成，比如可以將傳統的POJO形式的Java類進行封裝，可以將Web服務進行封裝，可以將RESTful服務進行封裝，可以將上述各類服務進行組裝。

5 客戶端聚合引擎

在BellMash平臺中，實現基于Web聚合、用戶驅動、網構軟件理念的關鍵除了后臺服務構件之外，還在于瀏覽器端的聚合框架。這種框架應該能夠自動發現、加載服務型的Web頁面，能夠聚合Web頁面形成更大的應用，還需要具備網構軟件所強調的動態性、開放性、演化性等。

在聚合框架中，開發者和用戶都可以通過非常簡單的語句聚合新的Web應用。新的應用是位置透明的，由框架自動搜尋、加載和呈現。框架還可負責在同類Web應用中加載使用體驗更好、可信度更高、響應更快的應用；框架還可在無法尋址用戶既定Web應用的情況下搜尋并加載替代應用。

要將Web應用共享起來，必須有一個機制，該機制能夠在Web上標示這個Web應用，這包括Intent Based軟件共享方法和聚合引擎。

5.1 Intent Based軟件共享方法

賦予Web應用特定的功能描述，這種描述類似Android application Framework中的Intent機制[16]。每個Web應用的公開頁面將向Web暴露二元組。將這樣的二元組通過數據庫進行注冊登記，當其他應用需要調用該功能時，網頁代碼中只需要通過簡單的數條Java Script語句調用。對于開發者來講，在面對一個具體需求時，其首先在粗粒度層次進行需求分析，并向服務器端的application目錄進行Intent關鍵字模糊查詢。如果能夠查詢到類似的Web應用服務，則可復用之，如果不能搜索到，則自主開發，并可提交到服務器端的application目錄，以被他人復用。一個典型的例子是：開發者A開發了一個聯系人應用，開發者B開發了一個發短消息的應用，A現在需要擴展聯系人應用，以使其能夠在用戶點擊聯系人的手機號碼時啟動一個發送短消息的應用。由于A沒有開發短消息的能力和經驗，A在系統中檢索類似Intent：Intent_SMS形式的Web應用聲明。當獲得這樣的應用之后，在其代碼(客戶端代碼)中的clickEvent中調用類似如下代碼 Intent(Intent_SMS，arg_msg)即可調出Web上無論在哪里的由B開發的發送短消息的應用。arg_msg包含目的移動電話號碼以及可選的消息，該參數有開發者B定義。arg_msg通常以JSON/XML格式編碼，默認的開發者B的應用接受JSON格式傳送的arg_msg。

5.2 聚合引擎

在聚合框架中，開發者在一定的規則下開發Web應用，這些Web應用中的網頁在傳統Web網頁基礎上嵌入了一種基于HTML5標準提出的新事件機制——PostMessage[17]。通過該機制繞開瀏覽器同源策略（same origin policy，SOP）限制，該Web頁面可以同其他不同來源的頁面在同一網頁進行通信，從而達到聚合的目的。

圖5和圖6顯示了整體聚合機制以及聚合引擎所在的位置。一個開發者通過BellMash平臺搜索已注冊的Web應用數據,搜索到applicationService1和applicationService2滿足其需求。開發者通過Intent機制，將二者結合起來。需要強調的是，在這個過程中，開發者并不是將這兩個應用的代碼融合到一個Web頁面中，開發者僅僅使用Intent聲明了要使用那個applicationService，在隨后的聚合過程中，聚合引擎將可以把不同來源的應用聚合在用戶界面中。

開發者將applicationService1和applicationService2在開發階段聚合成新的應用application1；開發者也可以直接用applicationService2開發新的應用application2，隨后他將把application1和application2發布到服務器上，并且可將其注冊到BellMash的application目錄上以供其他開發者共享使用。

圖6表示的是在用戶使用階段，聚合引擎的工作機制。一個認證用戶可以從application目錄中挑選滿足需求的應用，這些應用條目將被自動記錄到用戶的application目錄中，并且在適當的時候保持同瀏覽器端用戶離線application目錄的同步。依然以contact和sendsms為例，把contact作 為 applicationService1， 把 sendsms作 為applicationService2。當用戶啟動application服務1時，啟動過程從離線數據庫獲取了applicationService1的URL，隨即聚合引擎依據該URL從第三方服務器上調出contact應用頁面。此時聚合引擎沒有進行任何關于sendsms機applicationService2的操作。當用戶點擊contact中的Mobile電話號碼時，該過程通過代碼Intent(Intent_SMS，arg_msg)在Intent analyzer協助下對sendsms及applicationService2進行定位、加載、賦值等一系列操作，最終顯示給用戶一個新的界面，該界面即為發送短信的界面，并且其上依據自動填充arg_msg的相關數據，此外，用戶還可以根據需要修改該數據，最后將短信發送出去。

6 原型系統

根據上述架構，研究團隊開發了一個可以實際運行的原型系統。該系統主要實現聚合引擎部分，并整合電信行業的Parlay X能力，將其封裝為Restful API，提供通信支持。BellMash原型平臺的用戶界面參考開源Web desktop[18]。開始菜單中顯示所有的應用，包括用戶從application目錄中選擇的，也包括系統級默認功能，如application目錄、應用注冊模塊以及同步服務器等。

6.1 個性化企業應用實例

為了測試Web 上任何位置的應用之間的聚合運行，研究團隊在不同的域上分別開發了聯系人應用、基于電信位置服務的定位應用、發送短消息應用、第三方呼叫應用。這些應用都是相互獨立的應用，都可以獨立使用，但是在某些情況下，可以將應用聚合起來滿足特定需求場景，比如物流跟蹤。

場景如下：假如原始的聯系人應用中顯示的是所有配送員的個人信息，包括手機號碼信息。現在物流公司希望隨時了解配送員的當前位置，他們也希望其客戶能夠隨時了解配送員的當前位置，以提高服務滿意度。同時，物流公司后臺管理員還希望隨時快速地通過短信或者撥打電話聯系配送員。物流公司希望開發上述功能的Web應用，開發周期要求在兩周之內。

面對這樣的場景，開發者首先在BellMash中搜索Intent滿足sendsms、location、call等關鍵字的應用。開發者搜索到了相關的應用，并且也獲得了調用規范，即上文所述的Intent二元組，開發者只需要調用Intent(Intent_SMS，arg_msg)這樣的代碼即可。在這樣的情況下，開發者對原有聯系人應用進行了適當修改，在contact中每個配送員條目下添加了：發送短信的圖標及對應的功能；根據手機定位的圖標及功能；第三方呼叫的圖標及功能。至此，該聚合應用完成。經過測試，滿足了物流公司的需求。開發時間：3天。

6.2 Bellmash Platform上的應用開發流程

典型的開發流程包括開發者搜索Intent的過程，開發者定制應用以及開發者發布自己的應用的過稱，圖 7所示為開發流程。

7 下一步研究

本文所設計的BellMash Platform原型平臺的主體是聚合引擎以及后臺電信能力服務，融合SaaS和軟件商店實踐Executable Web理念。BellMash是平臺原型，它支持在其上進行不斷的演化、擴展。因此，從理論上來看，在這樣的平臺上所演化的具體應用是因需求而變的，應用沒有數目限制，應用的類型也沒有預期性,而這樣的特征能夠為應用的個性化提供支撐。原型系統設計以及典型案例測試表明本方案為SaaS提供了一種滿足多領域、需求集合交集較小的中小企業個性化、頻繁變化的應用需求的可行技術路線。

為了提供安全可靠的SaaS服務，還有關鍵問題需要進一步研究，這些問題包括：由于應用不再由SaaS運營商獨立提供，因而應用的可靠性、安全性技術將有別于傳統SaaS模式；由于應用聚合可能在不同的應用提供商之間發生，數據的安全性也將有別于傳統SaaS技術。這些問題是構建新型SaaS生態環境的必要保障。下一步研究將重點集中在以下兩方面。

（1）數據的保護機制

通過構建應用安全沙箱，使得SaaS應用軟件的運行限制在安全框架之內，對于大多數應用，數據只在瀏覽器本地駐留，不允許不同提供商的應用將數據通過網絡發送到其他域；對于必須同服務器進行交互的數據，通過制定技術和機制兩個層面的安全協議，確保數據被限定在特定的域中。

（2）應用的多實例機制

對于任意應用，采用類似云存儲中數據備份機制確保應用高可靠性。應用提供商可以提供任意套實例，但必須在SaaS運營商域部署至少一套實例，從而保證用戶總是能訪問應用。對于同類型應用，SaaS運營商將首先查找用戶配置的應用的實例，如果所有實例不可訪問，則查找其他等價應用實例以提供應急服務。

1 Maximil ien E M,Ajith Ranabahu,Stefan Tai.Swashup:situational web applications mashups.Companion to the 22nd ACM SIGPLAN Conference on Object-Oriented Programming Systems and Applications Companion,ACM,2007

2 Mehmet Altinel,Brown.Damia:a data mashup fabric for intranet applications.Proceedings of the 33rd International Conference on Very Large Data Bases,VLDB Endowment,2007

3 Katsuhisa Maruyama,Makoto Matsushita,Shinichiro Yamamoto.Japanese workshop on leveraging web2.0 technologies in software development environments (WebSDE).Proceedings of the 21st IEEE International Conference on Automated Software Engineering(ASE'06),Tokyo,Japan,2006

4 QEDWiki.Ibm.http://services.alphaworks.ibm.com/qedwiki/

5 Tim O'reilly.What is Web 2.0:design patterns and business models for the next generation of software.Communications&Strategies,2007,1(17)

6 IBM Mashup Center初探:第一部分.http://www.ibm.com/develo perworks/cn/data/library/techarticles/dm-0808wumd/index.html

7 Hoyer V,Fischer M.Market overview of enterprise mashup tools.Proceedings of the 6th International Conference on Service-Oriented Computing,Springer-Verlag,2008

8 Yahoo.Pipes:rewire the web.http://pipes.yahoo.com/pipes/

9 Intel.Intel Mash Maker.http://mashmaker.intel.com/web/

10 Rama Gurram M.A web based mashup platform for enterprise 2.0 web information systems engineering-WISE 2008 Workshops.http://dx.doi.org/10.1007/978-3-540-85200-1_17

11 Open Mashup Alliance.The open mashup alliance for enterprise mashups.http://www.openmashup.org/

12 楊芙清,呂建,梅宏.網構軟件技術體系:一種以體系結構為中心的途徑.中國科學E輯:信息科學,2008,38(6):818～828

13 楊芙清,梅宏.網構軟件:未來的新型軟件形態.中國教育網絡,2005(7)

14 Rod Boothby.The executable web.http://innovationcreators.com/wp/p=300

15 W3c.Web services Architecture.http://www.w3.org/TR/ws-arch/

16 Speckmann Benjamin.The Android mobile platform.http://www.w3.org/TR/html5/comms.html

17 Ext Js Inc.ExtTop-Desktop Sample App.http://www.extjs.com/deploy/dev/examples/desktop/desktop.html