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年的科技發展趨勢已經昭示，單一、模式化的技術產品或服務將不能滿足社會經濟的發展需求，全球科技生態系統將向多元、動態、服務性等方向健康發展”。微軟院士、微軟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上統一、開放的標準，所以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類。使用者在架構代碼的父類中提供了手寫代碼。手寫代碼的一個抽象方法在架構代碼中被重寫。比如，一個架構實體域引入了關於手寫代碼的父類函數調用，和突出函數調用。

　　² 手寫委託類。使用者在委託類中提補充寫代碼。比如，一個架構實體在制定處調用一個手寫實體，在設定屬性值的之前或之後。其實是一種Proxy 伺服器模式。

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

　　

　　圖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都通過執行個體來說明軟體的架構問題。產品的研發不僅僅是技術路而且是企業的決策問題。不同公司可根據公司實際情況採用有效並最佳的研發模式。建立並積累自己的開發體系有助於您複用代碼並極大地降低開發成本。

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