SaaS系列介紹之十四: SaaS軟件開發分析

1 引言

　　真正的問題，不是電腦是否具有思考能力，而是人類是否具有這種能力

　　                    ________B.F.Skinner《計算機科學》

　　SaaS模式不一樣於傳統軟件不只僅體如今運營的服務上，同時在軟件開發的方式和技術上也有很大的不一樣。

　　如何開發SaaS軟件，開發SaaS軟件將用到哪些技術這都是咱們要研究的主要內容。

　　2 實現SaaS軟件的關鍵技術

　　l SOA技術

　　SOA與SaaS被被稱做攣生姐妹確實並不爲過，SOA與SaaS是現代軟件服務領域的二架馬車，它們奔蹄狂奔、並駕齊驅。

　　面向服務架構(SOA)最先是由Garnter公司在上世紀90年代末提出的概念，強調服務的重要性。國內大多數消費者是經過SOA領域的老大IBM的宣傳逐步對其認識和理解的。

　　隨着時間的推移，應用軟件開發廠商向SOA領域涉及的程度愈來愈深，如今能夠絕不誇張地說，SOA已經無處不在。隨着SaaS的愈發火熱，SOA的繼續深刻，2007年12月微軟率先在業界提出了「軟件+服務」(S+S)戰略，旨在打通「內部業務整合(SOA)+外部業務拓展(SaaS)+豐富用戶體驗」等多重資源，將「軟件」和「服務」有機地結合在一塊兒，達到IT價值的最大化，實現SaaS和SOA「魚和熊掌兼得」。

　　根據微軟在一份技術白皮書中作出的定義，「軟件+服務」是一把「IT大傘」，它綜合了不少IT現有的技術和理論，包括SaaS、SOA和Web2.0。隨着不一樣廠商從不一樣的切入點切入，整個IT業正在托起」軟件+服務」這把大傘，走向IT將來之路。

　　「IT環境的日益複雜，使得人們對科技產品的需求不斷增長，將來10年的科技發展趨勢已經昭示，單1、模式化的技術產品或服務將不能知足社會經濟的發展需求，全球科技生態系統將向多元、動態、服務性等方向健康發展」。微軟院士、微軟CTO辦公室成員DonaldFerguson認爲，在服務領域，用戶能夠買前試用，按需支付;在軟件領域，用戶有徹底的掌控權--自行定製、一次性支付，想用多久就用多久。用戶若是選擇了純軟件或純服務的途徑，實際上就等於放棄了另一方面的優點。「S+S」能夠很好地解決這一問題。「S+S」的理念針對用戶的多種需求，既可選擇得到服務，也可選擇繼續擁有軟件，或兩者兼得。

　　「SOA對那些開展SaaS的軟件廠商而言也至關重要」。Interarbor Solutions有限公司首席分析師Dana Gardner指出，緣由在於SOA能幫助其更有效地進行應用程序軟件的傳遞。並且，與傳統的打包應用軟件廠商相比，他們從價格方面得到了競爭優點。

　　微軟中國首席技術官李志霄博士表示，軟件與服務在「S+S」中扮演了互補的角色，2008年將是微軟對「S+S」戰略加緊佈局的重要一年。另據SAP Business ByDesign總監劉欽中透露，SAP也將在2008年大變臉，以SOA架構產品拓展SaaS新渠道，從而得到SaaS和SOA的雙重收穫。

　　l 雲計算技術

　　SaaS做爲應用軟件的一種全新的銷售方式已經開始蓬勃發展起來，可是隨着SaaS軟件客戶的增加，網絡存儲和帶寬等基礎資源就會逐步成爲發展的瓶頸，對衆多企業來講，自身計算機設備的性能也許永遠沒法知足需求，一個簡單的辦法是採購更多、更先進的設備，隨之而來就是設備成本急劇增加，利潤隨之下降，有沒有更加經濟有效的解決途徑呢?「雲計算」的出現也許爲這個問題的解決推開了大門的一個縫隙。

　　雲計算(Cloud Computing)是基於互聯網的一種新興的共享基礎架構的方法，一般爲一些大型服務器集羣，包括計算服務器、存儲服務器、寬帶資源等等。它利用高速互聯網的傳輸能力，將數據的處理過程從我的計算機或服務器移到互聯網上的服務器集羣中，這些服務器集羣由一個大型的數據處理中心管理着，數據中心按客戶的須要分配計算資源，將巨大的系統池鏈接在一塊兒以提供各類IT服務。以達到與超級計算機一樣的效果。雲計算將全部的計算資源集中起來，並由軟件實現自動管理，無需人爲參與。這使得企業無需爲繁瑣的細節而煩惱，可以更加專一於本身的業務，有利於創新。

　　一般狀況下，SaaS供應商更專一於軟件的開發，而對網絡資源管理能力較弱，每每會浪費大量資金購買服務器和帶寬等基礎設施，但提供的用戶負載依然有限，而云計算提供了一種管理網絡資源的簡單而高效的機制，其分配計算任務、工做負載從新平衡、動態分配資源等等，能夠幫助SaaS廠商提供不可想象的巨大資源給海量的用戶，SaaS供應商能夠再也不服務器和帶寬等基礎設施上浪費本身的資源，而專一於具體的軟件開發和應用，從而達到最終用戶、SaaS、雲計算三方的雙贏。

　　因而可知，雲計算在企業軟件市場上具備至關大的潛力，對於SaaS供應商來講也是一大機遇，他們能夠選擇雲計算平臺，使用雲計算的基礎架構，使用及其低廉的價格爲海量的用戶羣提供更爲穩定、快速、安全的應用和服務。

　　要快速掌握雲計算的概念的話，咱們能夠用網絡架構圖上的那朵雲的概念來類推。在網絡架構圖上，一般以雲來把因特網聯機架構給隱藏起來，就不需理解聯機的複雜性，而能以簡化的概念來溝通;雲計算的概念，則是要把運算系統的複雜性給隱藏起來，讓開發者能夠沒必要了解提供運算資源的系統架構爲什麼，只要把運算的數據丟進系統，最後系統就會傳回結果。

　　雲技術能夠算是網格技術的一個子集合，二者目的相同，都是要把系統的複雜性隱藏起來，讓使用者只要使用而不須要了解系統內部如何運做。

　　l Ajax技術

　　Ajax(Asynchronous javascript and XML)是一組開發Web應用程序的技術，它結合了JavaScript、XML、DHTML和DOM等編程技術，可讓開發人員構建基於Ajax技術的Web應用，並打破了使用頁面重載的慣例。它使瀏覽器能夠爲用戶提供更爲天然的瀏覽體驗。每當須要更新時，客戶端Web頁面的修改是異步的和逐步增長的。這樣，AJAX在提交Web頁面內容時大大提升了用戶界面的速度。在基於AJAX的應用程序中沒有必要長時間等待整個頁面的刷新。頁面中須要更新的那部分才進行更改，若是可能的話，更新是在本地完成的，而且是異步的。讓用戶享受SaaS應用服務的同時能夠實現頁面的局部刷新，使用基於瀏覽器的B/S軟件像象使用傳統的C/S軟件同樣習慣、流暢。像Ajax這樣的應用正不斷透過SaaS使用到軟件行業中來。

　　l WebService技術

　　Web Service是一種以SOAP爲輕量型傳輸協議、以XML爲數據封裝標準、基於HTTP的組件集成技術。

　　Web Service主要是爲了使原來各孤立的站點之間的信息可以相互通訊、共享而提出的一種接口。Web Service所使用的是Internet上統1、開放的標準，因此Web Service能夠在任何支持這些標準的環境(Windows，Linux)中使用。它的設計目標就是簡單性和擴展性，這有助於大量異構程序和平臺之間的互操做性，從而使存在的應用程序可以被普遍的用戶訪問。

　　Soap技術是Web Service的核心，它以XML的標準格式封裝數據包，其中封裝的溝通訊息是以文本方式來表達的，而且遵循標準的封裝規則。這意味着任何組件模型、開發工具、程序語言和應用系統只要支持XML和文本格式的數據，就能夠順利的使用該技術。而如今全部組件模型、開發工具、程序語言、應用系統和操做系統都支持XML和文本格式，固然就能夠徹底支持Soap了。

　　在SaaS軟件中，Web Service提供組件之間相互溝通的機制。Web Service技術將極大提升系統的擴展性，使各類不一樣平臺、不一樣開發工具的應用系統無縫集成起來。同時，做爲Web Service技術核心的Soap是一個開放的標準協議;它不只突破了應用壁壘，並且可以結合企業防火牆和內部信息系統，同時提供安全和集成的應用環境;容許企業封裝任何自定義信息，而不須要修改應用系統的源代碼，提供了強大的系統彈性。

　　l 單點登陸技術

　　對現代網絡應用易用性的基本要求之一，至少在咱們系統內部，咱們要作到用戶一次登陸，便可訪問全部他有權訪問的全部子系統。

　　Single Sing On(單點登陸)就是要實現經過一次登陸自動訪問的全部受權的應用軟件系統，從而提升總體安全性，並且無需記憶多種登陸過程、ID或口令。

　　在WebService 環境中，單點登陸扮演着很是重要的角色。在WebService環境中，各式各樣的系統間須要相互通信，但要求每一個系統都維護彼此之間的訪問控制列表是不實際的。用戶也須要更好的體驗以不須要繁瑣的屢次登陸和身份驗證來使用一個業務過程當中涉及到的不一樣系統。在WebService的單點登陸環境下，還包含這樣一些系統，它們有着本身的認證和受權實現，所以須要解決用戶的信任狀在不一樣系統間進行映射的問題，而且須要保證一旦一個用戶被刪除，則該用戶將不能訪問全部參與的系統。

　　SAML是一個將認證和受權信息以XML格式編碼的標準。一個Web Service所以可以從一個SAML兼容的認證和受權服務中請求並收到SAML斷言，並據此驗證和受權一個服務請求者。SAML能夠用來在多個系統間傳遞信任狀，並所以被用於單點登陸的方案中。

　　3 軟件工廠的產品線生產

　　經過應用重要的新方法可以克服阻礙從技術到生產轉變的經濟和技術問題，這些方法在對付複雜性和變化方面採起了新的方式。這些新的方法目前也存在，同時在商業產品方面表現出了明顯的潛力，儘管它們大多數還不成熟。主要在四個方面：系統重複利用、組裝開發、模型驅動開發、過程框架。讓咱們逐一進行考慮。

　　l 系統重複利用

　　軟件開發中一種最重要的新方法是定義軟件產品族，它們的成員在變化，可是卻共享着許多共性的特徵。像Parnas，這樣一個族提供了一種環境使成員中共性的問題可以集體解決。經過識別和區別特性，這些特性或多或少的存在於多產品和那些變化中，咱們可以採用一種系統的方法去重複利用。一個軟件產品族由組件或整個產品組成。好比，一個族應當包含不一樣的應用程序投資管理，包含不一樣用戶管理框架，用戶管理框架是由應用程序投資管理和用戶關係管理應用程序使用的。

　　軟件產品族是由系統整合業者(SIs)開發的，從一個用戶到一個用戶移植應用程序，或者改進已存在的應用程序來建立新的應用程序。他們也經過獨立的軟件供應商開發軟件產品族，開發區域多應用程序像CRM，或者多版本應用程序經過維護和改進。他們也經過IT組織來開發軟件產品族，改進已存在的應用程序，開發多關係的應用程序，或者多版本應用程序經過維護和改進。

　　l 軟件生產線的實踐

　　軟件生產線開發軟件產品族，經過標識共同特性和填寫特殊領域變化的表格，使軟件產品族中成員的開發變得更快、更便宜、更少的風險。而不是寄但願於暫時的重複利用，他們系統的捕獲如何開發家族成員的知識，使重複利用資產變得可能，在家族成員開發過程利用那些資產。做爲一個家族的產品開發，能夠重複利用需求、構架、框架、組件、測試和其餘資產。

　　固然，開發一個生產線須要成本。換句話說，生產線體現了經典的成本-利益權衡。等式一邊的利益不可以經過在支持有限發佈的市場上生產許多備份來增長收益時，可是能夠經過生產許多相關的、惟一性的產品來增長收益，如許多案例研究所述[CN01]。利用軟件生產線是通向軟件工業化的第一步。使它們的建立和運行變得更加便宜是第二步。圖1在一條生產線上描述了主要任務的執行、工件生產和利用。

　　

　　圖1 軟件生產線

　　生產線開發者應用開發資產去開發軟件族成員的方式正如平臺開發者建立設備驅動和操做系統以供應用程序開發商使用同樣。開發產品資產的一個重要的步驟是開發一個或者更多的區域模型，這些模型描述了由生產線提供的共同問題特性和描述不一樣的表格。這些模型共同定義生產線的範圍，被用來限定預期的軟件族成員。軟件族成員的需求就是源自於這些模型，提供了一種方式使需求的變化和構架的、實現的、執行的、開發過程的、項目環境的、和軟件生命週期的其餘部分的變化相互聯繫。

　　l 模型驅動的開發

　　提升抽象水平是一個重要的過程，它減小了抽象的範圍，所以實現的時候也減小了開發者的控制。失去控制的損失是權力相應的增長。大多數商業應用程序開發者，好比寧願使用更高水平的像這些用C#和.NET框架的抽象，而不是組裝語言和系統調用。更高水平的抽象產生許多好處，包括更高的生產率，更少的缺陷，更易維護和改進。

　　不幸的是，咱們看到了提升抽象水平和工具很是昂貴。假如咱們可以找一些方法使它變得更快、更便宜、更容易，不過咱們可以爲小的問題域提供更高水平的自動化。這就是模型驅動開發(MDD)的目標。模型驅動開發利用模型驅捕獲高層次的信息，一般是非正式的表述，自動實現，或者經過編譯模型來執行，或者經過它們令人工開發執行變得容易。這是重要的，由於信息目前在低層的工件裏還找不到，好比源代碼文件、很難進行跟蹤，維護和持續改進。

　　一些開發活動，好比構建、配置和調試目前都是經過利用從源代碼文件和其餘實現工件中捕獲的信息來實現部分或者徹底的自動化的。利用經過模型捕獲的信息，MDD也可以提供更多可擴展的自動化活動，和更多自動化優化表格，好比模型調試和自動化配置工具。如下是一些例子：

　　² 平常的任務，好比從一種東西生產另一種東西，一般可以充分的自動化。好比，測試用具一般可以從用戶界面模型自動生產，使頁面之間進行轉換以模擬用戶的活動。

　　² 其餘任務，好比解決工件之間的差異，可以部分實現自動化。好比，表中的列和表單的域中多是滿滿的問題待用戶去解決，而後由用戶決定自動進行校訂。

　　² 適配器，好比Web service wrappers在實現技術裏可以從模型到橋的差異自動生成。模型也可以用來表示，協議配置，和其餘適應的集成機制。

　　² 模型能夠用來定義工件配置，這些工件由配置單元組成，使配置過程自動化。模型的配置環境可以用來約束設計，以便可以正確的實現設計。

　　² 模型可以用來描述配置部件的配置，捕獲操做特徵的信息，好比下載平衡，失敗恢復，資源分配策略，自動化管理活動，數據收集和報告。

　　l 特有領域語言

　　爲了MDD，咱們再也不對一些末端語言如4GLs感興趣，也不對用一種高水平的語言以實現全部方面的開發感興趣。這些戰略的弱點已經被充分證實。咱們也再也不對會議上提交的模型感興趣，還有筆記。不幸的是，模型一般用來編成文件供人來用而不是計算機。這些形成了一種印象，模型不是第一類用源代碼的開發工件。咱們對用工具來處理模型感興趣，咱們也計劃用一樣的源代碼方式去用它們。用這種方式，文檔設計的模型不能用語言來表達。模型必須是準確的不含糊的。同時，爲了提升抽象水平，建模語言必須着眼於小的區域而不是一種通用的編程語言。有以下要求：

　　² 語言設計的目標必須明確規定，以便熟悉領域的評審人員可以評價語言和決定它是否實現了目標。

　　² 這種語言必需要能使工做在該領域的人員可以捕獲業務概念。用於開發和裝配Web服務的語言必須包含一些概念如Web服務、Web方法、協議和基於協議的鏈接。一樣的，一種語言用來可視化和編輯C#源代碼必須包含一些概念(像C#那樣)，好比類、成員、域、方法、屬性、事件和代理。

　　² 這種語言必須讓其用戶熟悉其概念的名稱。好比，一個C#開發人員發現一個擁有域和方法的類的模型比發現個擁有屬性和操做的類的模型更天然。

　　² 語言的符號，是圖片或者文字，必需要容易用來解決問題。人們平常做的事情必須容易用概念來表達。好比，它必需要容易用一種可視化和C#源代碼編輯的語言來操做一個繼承。

　　² 這種語言必需要有一套定義好的規則，叫作語法，管理組成概念的表達式。這樣使得用工具檢測表達式是否正確變得可能，同時幫助用戶寫概念。

　　² 每個表達式的語義都必須定義無缺，以便用戶能建立其餘人也理解的模型，工具可以從模型中產生合法的實現，從模型中捕獲的元數據當用來處理任務時可以作其所指望的事情，像配置服務器。

　　知足這些標準的語言稱爲領域專用語言(DSL)，應爲它爲那些特殊領域概念進行建模。DSL比通常的建模語言更加嚴格。像一種編程語言，它也有文字或者圖片符號。SQ和HTML就是DSL的兩個例子，分別爲關係數據定義和Web頁面定義服務。

　　圖2是兩個說明DSL的圖示的例子，是Microsoft Visual Studio 2005 Team System的一個屏幕截圖。左邊的DSL描述了組件，像Web服務。它被用來實現組件開發和配置自動化。右邊的DSL描述了數據中心的邏輯服務類型。它被用來設計和實現數據中心配置。Web服務開發是經過把服務部件拖到邏輯服務器上。邏輯服務器上資源需求和可用之間的不一樣，充滿了確認錯誤和圖示。

　　

　　圖2 領域專用語言

　　l 增量代碼生成

　　高效代碼生成的關鍵是少生成概念上差異小的代碼。這樣就能夠容許工具利用平臺特色，生產集中的、高效的、平臺特性的實現。一種使代碼生成增長更多的方式是讓模型更切近平臺，如圖3所示。好比，用編程語言類型系統定義的專用編程語言比使用類型系統定義的建模語言能實現更加真實的建模。這個模型如今變成了一個代碼視圖，開發者圖形化操做程序結構像操做類和方法定義同樣。這個工具體現了在代碼中難以看到的關係和依賴，節省了爲程序結構生成代碼的時間和努力。它使得實現了像基於關係收集的編程風格，或者提供高級的特性像重現和模式構造、應用和評估。

　　

　　圖3 SaaS運營人體關係羣

　　固然，經過限制在可用的平臺上進行抽象，這減弱了建模的做用，或者做用不大像編程風格。那咱們如何工做在較高的抽象層呢?咱們使用了更加抽象的模型，經過框架或者轉換使平臺和模型更緊密，如圖4所示。讓咱們逐一看看這些。

　　

　　圖4 編程語言建模

　　使用高層抽象

　　² 咱們能夠用框架去實現模塊中的高層抽象，用這些模塊在框架擴展點去生成小段代碼。相反，模型幫助用戶完成框架經過可視化框架概念和用直覺的方式體現擴展。當開始用微軟的操做系統時，好比構建圖形應用是困難的。隨後，Microsoft Visual Basic經過表單和控制概念使得圖形應用變得更加容易。

　　² 咱們能夠建立更低層次的DSL描述語言，代替構架或模型語言。爲了領導這種革命性的變革，咱們還能夠利用兩個以上的DSL描述語言跨越更寬的跨度，用最高層次的DSL語言描述的模型能夠經過提煉轉換成可執行的軟，如圖4所示。這說明了編譯器如何工做，如何將高級語言像c#和java轉換成中間代碼像字節或IL，經過JIT編譯成目標平臺的二進制格式。

　　l 組成機制

　　固然，手寫的代碼必須一般和框架代碼結合產生一個完整可執行程序。一些不一樣的機制能夠用來作這些東西。它們之間重要的區別是幫定時間。

　　

　　圖5 設計時間的組成

　　運行時綁定的兩個優勢是，經過接口使手寫代碼和框架代碼結合起來，容許經過對象置換來實現動態配置。同時，委派類容許手寫代碼經過再生來進行保護。一個比較小的缺點是運行時間常常是方法調用。在組件編程模型中，一些基於運行時綁定的機制很是流行，如圖6所示。它們在大規模的商業產品中都很是成功。

　　² 在編譯以前，在同一個工件中的設計時間主要是手寫代碼時間和框架代碼二者的時間，如圖5所示。這包括爲了不用戶修改框架代碼的編輯經驗的約束(好比，用只讀區域的編輯器)。在其餘工具中，用戶在一個特別的窗口中添加手寫代碼。經過異步回調，運行時綁定合併手寫代碼和框架代碼。一種基於代理的運行時綁定機制經過設計模型來描述，好比、如下從Gamma，et.al.：events(Observer)，adapters(Adapter)，policy objects(Strategy)，factories (Abstract Factory)，orchestration(Mediator)，wrappers(Decorator)，proxies(Proxy)，commands (Command)?and?filters(Chain of Responsibility)[GHJV95].運行時綁定的兩個優勢是，經過接口使手寫代碼和框架代碼結合起來，容許經過對象置換來實現動態配置。同時，委派類容許手寫代碼經過再生來進行保護。一個比較小的缺點是運行時間常常是方法調用。在組件編程模型中，一些基於運行時綁定的機制很是流行，如圖6所示。它們在大規模的商業產品中都很是成功。

　　² 手寫SUB類。用戶提供手寫代碼在框架裏的SUB類中。在框架代碼中的抽象方法定義了顯示覆蓋點。好比，用戶寫了一個框架實體子集，域內經過模板方法模式引用了手寫代碼，和突出函數調用。

　　² 框架SUB類。用戶在框架代碼的父類中提供了手寫代碼。手寫代碼的一個抽象方法在框架代碼中被重寫。好比，一個框架實體域引入了關於手寫代碼的父類函數調用，和突出函數調用。

　　² 手寫委託類。用戶在委託類中提補充寫代碼。好比，一個框架實體在制定處調用一個手寫實體，在設置屬性值的以前或以後。實際上是一種代理服務器模式。

　　² 框架委託類。用戶補充手寫代碼去得到框架服務。好比，一個手寫代碼實體調用框架實體去設置或者獲得屬性值。

　　

　　圖6 運行時構成

　　² 在編譯期間綁定合併手寫代碼和框架代碼，如圖9所示。在編譯期間利用部分規格和編譯時合併是一種很好的方式。在Visual Studio 2005中的Visual Basic和C#語言就是編譯期間構成。

　　

　　圖7 SaaS運營人體關係羣

　　l 組裝開發

　　平臺無關協議領域的重要革新有，自描述，變量的封裝，經過流程的組裝和構架驅動的開發。

　　l 平臺無關協議

　　Web服務技術成功了，早期的組件組裝技術從實現技術中分離出用於特定和組裝的組件卻失敗了。因爲XML是一種管理信息的技術，不是一種構建組件的技術，Web服務利用封裝去映射Web方法調用到本地方法調用，基於下面的組件實現技術。雖然CORBA試圖用一種類似的策略，它的複雜性須要平臺供應商的大量投資，爲此也限制了它的使用範圍。基於XML的簡單協議明顯下降了實現困難，確保它們的廣泛性。經過編碼遠程方法調用請求像XML，它們避免了由平臺特殊遠程調用編碼和參數集結所引發的協同工做問題。同時，經過得到普遍的工業標準承認，它們從一開始就設計了平臺的協同工做能力。

　　l 自描述

　　經過改進組件包裝來使推斷，依賴，行爲，資源消耗，性能和證實明顯，自描述減小了構架不匹配的狀況。它提供的元數據能夠用來自動進行組件發現，選擇，許可，得到，安裝，調整，組裝，測試，配置，部署，控制和管理。

　　自描述最重要的表格是用來描述組件推斷，依賴和行爲，所以開發者能夠推出組件之間的交互，工具纔可以驗證組裝。在面向對象中用途對普遍的規格表是類和接口聲明。它們定義了類提供的行爲，可是經過在方法簽名中命名其餘類和接口，僅僅說明了重要的推斷和依賴。合約是一種豐富的規格說明。一個合約管理着組件之間的交互。它不知道什麼時候去調用一個組件。一個合約描述了交互順序，和響應協議非法和其餘不可預知的條件。

　　固然，合約除非是強迫的不然也沒有什麼用。這有兩種方法強制合約。

　　² 不用不匹配的合約來組裝組件

　　² 用合約提供的信息去提供適配器，這種適配器使的組件之間直接交互，或者協調它們之間的交互。

　　Garlan建議使用標準適配技術菜譜和提供封裝與數據轉換的工具[Gar96]。一種最有但願的適配策略是發佈部分組件，這些組件可以在組裝期間經過封裝各個方面來完成，這些方面提供了組裝須要的代碼。這種策略，稱之爲變量封裝，描述以下。

　　關於自描述的另一個重要方面是證實。假如組件可以證實僅僅有指定的依賴，消耗了指定的資源，在必定的條件下具備特定的功能特性，或者有一些公開的弱點，那麼它可以推斷由這些組件組裝成的軟件所具備的功能特性和操做特性。這已經在卡內基梅隆大學軟件工程學院裏進行研究，它被認爲是可保證組件的可預見組裝(PACC)。

　　l 變量封裝

　　咱們已經看到，靜態封裝減小了這種可能性--一個的組件經過靜態綁定其功能方面或者沒有功能或上下關聯的內在方面可以用於特定裝配。變量封裝減小了構架之間的不匹配經過發佈部分封裝的組件，這些組件經過利用其功能性方面來選擇和編制適當的非功能性方面，使得可以適應新的上下文關係，如圖8所示。在特定組裝中的組件形式可以經過它位置上的上下文來決定。經過使得組件邊界更有彈性，和減小構架之間的不匹配能夠改進靈活性。經過移除非功能性假設，可以容許功能性部分在組件邊界上進行重製。有效的調整能夠預先標識，在一些例子中甚至能夠經過工具來自動完成。

　　

　　圖8 變量封裝

　　變量封裝是面向切面編程的改寫(AOP)。AOP是系統的不一樣方面各自進行先分離後組合的方法[KLM97]。變量封裝在三個方面和AOP不一樣。

　　² 變量封裝編入了封裝的方面，然而AOP，做爲普通的實踐，編入了非封裝的代碼行。編入非封裝方面，當組裝很差的組件包時產生了一樣的問題，叫作構架不匹配和不可預見。的確，基於方面編入源代碼更傾向於這些問題而不是組件組裝，由於組件至少有描述行爲和一些防止無依賴的包裝。AOP缺少包裝使得開發者難於推斷個方面的兼容性和編入的功能特性，或者執行結果特性，幾乎使得利用工具檢查方面編入都不可能。

　　² 在組件開發期間AOP編入方面，可是變量封裝編入卻比他們晚，好比在組件組裝或者配置期間。這很是重要，由於組件可能置入的上下文直到組件發佈時才知道。事實上，爲了支持組裝開發，如文章所述，第三部分必須可以預知組裝和部署無依賴的開發組件。這須要一種正式的方式去分割方面，封裝方面，說明方面和包裝方面。變量封裝也能夠是累進的，它能夠在不一樣的階段發生。好比，咱們能夠綁定一些方面在組裝期間，一些方面在開發期間，一些方面在運行期間。

　　² 變量封裝是構架驅動的，然而AOP卻不是。這些從功能內核分離出來的方面必須經過接口、抽象類、WSDL文件或其餘形式的合約來明顯定義。

　　l 流程管理組裝

　　若是有充足的合約機制，服務能夠經過流程管理引擎，好比Microsoft BizTalk Server，去管理它們之間交流的信息順序，如圖9所示。流程管理組裝使得組裝開發更加容易，由於服務之間的依賴遠比二進制組件少。不像類，它們沒有必要駐留在同一個執行中。不像組件，須要平臺特定的協議，它們可以經過平臺邊界來組裝。若是它們之間的合約是兼容的，兩種服務之間能夠相互做用。它們能夠分別開發和部署，而後經過流程管理來進行組裝。假如適當的攔截重道服務可用，它們甚至可以駐留在不一樣的管理和組織區域。換句話說，流程管理組裝消除了不一樣組件之間的設計、編譯、部署時間依賴。

　　

　　圖9 流程管理組裝

　　流程管理組裝實質上是一種仲裁，像Gamma的仲裁模式描述的那樣。一個仲裁管理組件之間的交互流程。一個仲裁有強大的屬性。其中一個功能是過濾或者翻譯組件交互時的信息。另一個功能是控制交互，若有必要能夠經過多路調用來維持狀態。這容許仲裁去推斷交互，若有必要能夠經過條件邏輯改變它們。仲裁同時可以執行一些有用的功能，好比日誌，增強安全策略，不一樣技術或者同一種技術的不一樣版本之間的聯繫。一個仲裁一樣可以成爲組裝的功能部分，增強商業規則或者執行商業功能，好比達成商業交易。

　　l 架構驅動的開發

　　當防止組裝不匹配組件好過於構建非法的組裝時，那麼就沒有必要提高匹配好的組件的可用性。這就是架構的目標。依照Shaw和Garlan，一個軟件構架描述了組件的組裝，它們之間的交互和可接受的構成模式，減小了良好設計的構架不匹配和約束設計決定的風險。

　　固然，開發軟件架構是具備挑戰性的。這使得不少架構師花費了許多年纔可以精通有限的構架風格或者應用領域。若是沒有在架構實踐方面明顯的進步和軟件構架方面更多的信任，組裝開發不可以在工業規模上實現。

　　這些是架構驅動的軟件開發(ADD)的目標，包括：

　　² 用於描述、複述和使用架構的標準。

　　² 用於預知設計決定效用的方法。

　　² 模式或者架構風格，它用來整理設計專家意見，幫助設計者開發組件分割再現模式。

　　一個架構風格是一個粗糙的模型，它給抽象框架提供了一組家族系統。它定義了一套指定不一樣種類組件的規則，這些組件可以用來組裝一個系統，不一樣種類組件的關係能夠用在組裝中、組裝時的約束中和組裝的設想中。好比，一個Web服務成分風格可用來指定組件提供端口。這些成分是Web服務定義好的，經過鏈接端口來創建聯繫，只有兩個端口兼容才能夠鏈接，經過HTTP用SOAP來進行通訊。其餘的架構風格包括：數據流、分層和MVC風格。一個架構風格經過提供頻繁出現問題的解決方案，促進了劃分和提升了設計重用，同時也有以下促進。

　　² 經過標識普通的架構元素來實現再使用，這些構架元素是基於這種風格的、被系統共享的。

　　² 經過定義標準構架來表示明白。

　　² 經過定義標準的通訊機制來提升協同工做能力。

　　² 經過定義標準的表示法來提升可視化。

　　² 經過定義強制的約束來提升工具開發。

　　² 經過標識基於這種風格的系統突出特性來分析。

　　一個構架描述就是一個定義了軟件構架的文檔。IEEE標準1471，被推薦用來描述密集型軟件構架，提供了描述構架的指導方針[IEEE1471]。根據這些指導方針，一個系統有一個或者更多的股東。一個股東有特殊的關注和關於系統某些方面的利益。爲了對股東們有用，一個架構描述必需要求有能使股東們明白的形式和結構。ADS就是一個用來描述一個系統家族架構的模板。一個正式的場景定義了一個視圖，這個視圖能夠描述軟件產品的一部分;它也提供了一種模式，這種模式用來進行描述，定義範圍，目標和聽衆，習俗語言和用來開發它的方法。

　　這些突出的元素用來詳細說明一個場景包括：

　　² 一個標識符和其餘介紹性的信息(好比，做者，日期，參考文件，等等)。

　　² 與場景的利害關係。

　　² 習俗、語言和基於場景用來產生視圖的方法。

　　² 確認視圖的一致性和完成測試。

　　一個視圖從一個給定的場景描述了一個軟件產品。一個視圖是語義上接近的，意味着它從那個場景描述了一個軟件產品。一個視圖包含一個或者多個工件，每個都根據場景需求來開發。一個視圖是一個場景的實例，爲了更好的成形視圖必須和場景是一致的。一個視圖遵循網頁設計場景，好比，應該描述特殊軟件產品的網頁佈局，應該用場景定義好的符號來描述網頁佈局。這些突出的元素用來詳細說明一個視圖包括：

　　² 一個標識符和其餘介紹性的信息(好比，做者，日期，參考文件，等等)。

　　² 視圖遵循的場景標識符。

　　² 用習俗、語言和場景定義的方法構建的軟件產品描述。

　　爲了明白視圖和它的場景差異，考慮爲商業應用程序進行邏輯數據庫設計。邏輯數據

　　庫設計是應用程序的一個視圖，更確切一點，是一個構成組件的視圖。應用程序方面和用來描述它的語言都在邏輯數據庫設計場景中規定好了。許多不一樣的商業應用程序可以規定下來，經過用相同的場景，產生了不一樣的視圖，每一個視圖描述了一個爲一些商業應用程序的邏輯數據庫。這些視圖可以描述一樣的方面，用同一種語言，可是它們會有不一樣的內容，所以每一個內容都描述了一個不一樣的應用程序。一個組裝視圖能夠從相同的場景中分解出各個組件的視圖。

　　根據IEEE1471，一個架構描述必須標識所用的場景和用這些場景的原理。做爲特殊目標的ADS，能夠經過列舉其所用的一套場景來定義。好比，一個消費者對商業的Web應用程序的ADS可能須要一個對網頁佈局的場景和一個對商業數據佈局的場景。每個在架構描述中的視圖，都必須遵循一個由ADS定義的場景。

　　l 過程框架

　　隨着項目規模、地理分佈或者時間而複雜度提升時，過程成熟的關鍵是保持靈活性。經驗告訴咱們不多有結構經過減小必須的工做量增長了靈活性。這原理可以在軟件產品家族中應用，經過運用過程框架去管理複雜的產品同時不減小靈活性。

　　正式過程的一些困難是它們太抽象了。它們提供的指導對於老程序員是明顯的，可是對於初學者就不怎麼具體充分了。爲了增長使用價值，它必須下降目前項目的細節，由於每個項目在許多方面都是獨特的，咱們不可能產生一種能知足全部項目的過程。咱們知道如何解決此類問題，咱們能夠爲一個特殊產品家族定製和裁剪出一個正式的過程。若是沒有專業供應商，以上的東西是不能在市場上成功的。一些供應商爲了給特殊用戶定製過程，一般從其餘過程如XP添加一些有用的東西。其餘的，尤爲是系統集成者和ISVs，裁剪過程以適應特殊的產品或者諮詢性的實踐。每個方式，高效使用任何過程的關鍵是使其對於一個給定的項目高度特殊化，以便它僅僅包含直接可用的資源。由這種定製產生的改變是很是複雜的，產生了和原來過程不多類似的結果。

　　一個高度集中的過程包括詳細的項目信息，如工具配置、網絡共享路徑、開發者根據指導來工做、API文檔、關鍵過程的重要聯繫人物的名字像CM，缺陷跟蹤和處理，關於check-in的小組策略，編程風格和同等檢查，還有其餘的關於項目和項目小組的細節特徵。和其餘形式的系統重用一塊兒，僅當咱們可以不止一次用它，這種定製纔會有用。一樣，重用高集中的過程資源經過消除工做增長了其靈活性，就如同其餘的重用資源同樣。如同Jacobson常說的，構建東西最快的方式是重用一些已經存在的東西，尤爲可重用的資源可以定製和擴展。不少東西均可以系統地重用，開發過程也同樣。

　　一個過程框架分解成一些更小的過程，這些過程附上了ADS的場景。每個小的過程描述了產生視圖的需求。它可以列舉出關鍵的決策點，標識了每一個決策點的轉換聯繫，描述了必須和可選的活動，描述了每一個活動所需的資源和產生的產品。每一個工件處理以前都有一些約束，和一些後置條件，工件穩定時所需的不變環境。好比，咱們須要在循環開始以前獲得循環條件，在退出時獲得結束條件。咱們須要全部的代碼都構建和測試正確。咱們稱這種架構爲過程框架，由於它定義了可能合併過程的空間，依賴於給定項目的需求和環境，而沒有必要爲全部的項目都描述一個過程。當一個過程框架定義好了，小的過程可以組合成項目所需的任一工做流，包括自頂而下，自下而上，由裏到外，測試編碼和編碼測試，任何組合或者混合流。

　　這些工做流能夠由資源來驅動，容許經過PERT和CPM來進行優化，當資源可用時啓動工做流。許多種類資源能夠驅動計劃，包括需求和源代碼，開發人員和程序管理人員，配置管理產品或者缺陷跟蹤系統，像在服務器上打開一個端口或者分配存儲器的設備。這稱爲基於約束的計劃。基於約束的計劃利用少許的架構需求，平衡了靈活性的需求。基於約束的計劃提供了指導，在開發工件上添加了約束，而不是規定過程。靈活性的產生，能夠經過一個工做流在約束中動態產生來獲得，適應大量環境變量，同時總結學習經驗，減小知識再發現的費用和時間。

　　一個過程框架沒有必要太大或者過細，可能包含或多或少的須要的細節。這提供了一種衡量過程大小的方式，依賴於環境。好比，一個小而靈活的小組可使用小的框架，這種框架僅提供了一些主要的關鍵實踐，如XP。一個大的組織，能夠添加許多構建過程的細節，檢查過程，測試過程或者組件共享規則。

　　4 小結

　　本文介紹了SaaS的開發模式。經過對實現SaaS軟件的關鍵技術的介紹讓咱們有目的性的去了解有關這方面的知識。軟件工廠的產品線生產源於傳統的製造業，製造業中流水線的做業是否可在軟件業上應用還面臨着一些問題，但真正實現軟件的工廠化也不是不可能。談到開發確定少不了系統的體系架構，軟件的體系架構是主要是軟件的分層問題。本節就.net與J2ee都經過實例來講明軟件的架構問題。產品的研發不只僅是技術路並且是企業的決策問題。不一樣公司可根據公司實際狀況採用有效並最佳的研發模式。創建並積累本身的開發體系有助於您複用代碼並極大地下降開發成本。