本系列文章將說明菜譜(recipes,本文中借用菜譜來喻意模板)、軟件模式和模型等可重用資產可以如何幫助加快 SOA 解決方案的開發。SOA Implementation and Optimization of Services Recipe 菜譜提供了規定性指南,用以確定如何使用模型驅動的開發方法來進行服務構造和利用其他可重用資產(如構造中的模式和模型)開發服務。我們將介紹通過一系列 IBM SOA 策略合作項目得到的四種新 SOA 應用程序模式。這些 SOA 模式代表了從這些 SOA 解決方案的開發過程獲得的重大經驗教訓。該菜譜還對參考示例應用程序進行了利用,該參考示例應用程序演示了如何將這些新 SOA 模式部署到 UML 模式,從而滿足服務的各個服務質量要求,如互操作性和可伸縮性。通過此菜譜可幫助產生符合代碼開發最佳實踐的體系結構一致的 SOA 應用程序。
引言
本文將對可重用資產、菜譜(recipes,本文中借用菜譜來喻意模板)和模式進行介紹。 資產是針對問題提供解決方案的構件集合??芍赜觅Y產規范(Reusable Asset Specification,RAS)(請參閱參考資料。)
軟件模式是特定上下文中的問題的可重復解決方案。Rational® Software Architect 采用了一種模型驅動的開發(model -driven development,MDD)方法來處理軟件模式。MDD 通常允許使用一組轉換從一個抽象級別轉換到另一個抽象級別。轉換的一個例子就是從分析模型轉換為設計模型,可能還隨后從設計模型轉換為代碼。
多個 Rational Software Architect 模式和其他資產(如模型或需求)可能交織在一起,以形成粒度更大的解決方案。菜譜提供了流程指南、上下文和組成元素(即模式和資產)的描述。
菜譜、Rational Software Architect 模式和轉換以及其他資產均使用 RAS 進行打包,存儲在資產或 RAS 存儲庫中。RAS 存儲庫是開發資產存儲庫,提供了發現可用于特定解決方案的資產和元素的機制。我們將重點討論 SOA 解決方案,但這個概念可以在很多地方使用。
模式菜譜提供了有關指定模式的使用、組織以及相互關系的文檔。菜譜提供了有關使用模式及其實現所必需的資產的指南。菜譜可幫助將一個模式的輸出與另一個模式的輸入緊密地聯系到一起。菜譜可以替代一個或多個模式。在上下文可能隨著時間而改變的情況下,這非常有用。
SOA Implementation and Optimization Recipe 是一個 Rational Software Architect 模式和轉換集合以及有關提供 SOA 解決方案的指南。在該菜譜中討論的模式將操作 UML 模型來生成和優化服務。Rational Software Architect 模式是使用 Rational Software Architect Pattern Engine 實現的。每個 Rational Software Architect 模式和轉換都作為 Eclipse 插件實現,均使用 Rational Software Architect 模式創作和轉換 API。
可重用資產簡介
幾年前,由軟件行業領先企業組成的聯盟——包括 IBM、Rational Software(當時尚未被 IBM 收購)和 Microsoft——開始討論如何幫助組織對軟件投資進行重新利用。當時,該聯盟將資產定義為:可提供給定上下文中的問題的解決方案的構件集合。
資產也可以具有其他特征。資產可以具有允許用戶通過設置各種參數對其進行自定義的可變點??梢圆捎眠@種方式處理的資產稱為模板。目前,IBM Rational 工具就是在考慮此定義的前提下實現的。
資產包括有關其使用的說明或規則,可盡可能減少開發人員發現、分析、使用和測試資產所需的時間。資產還要對開發和業務上下文進行描述,可以(也應該)在此上下文中使用此資產。
資產包含的構件類型取決于重用上下文。對于開發上下文,資產可以包含需求、模型、源代碼和測試。構建服務的人員應將此類構件包含進去,以便其他開發人員有效地重用服務。
請注意,資產的定義與模式的定義非常相似。設計就是如此,因為模式和資產背后的基礎概念都是上下文、問題和解決方案。不同之處在于細節不同。資產是比模式更為一般的概念。資產的可變點在構件級別,而模式則具有應用到整個模式(而不一定是特定構件)的參數和參與者(可變點類型)。
![]() ![]() |
![]()
|
RAS 簡介
如何組織和結構化資產?我們需要知道哪些有關它的信息?可重用資產規范 (RAS) 提供了一個結構,可以圓滿解決這些問題。此規范是一項 Object Management Group (OMG) 標準,于 2005 年開始采用。
存在很多類型的軟件開發構件,可能以任何形式存在,反映出設計風格的變化。這個多樣性可能增加發現、理解和重用其他作者的構件的成本。通過指定對這些構件進行組織、描述和打包的方法,RAS 可跨諸多資產提供一致性和可預測性,從而大幅度減少資產管理和使用的成本。
為了說明標準化資產打包的價值,讓我們了解一下標準化是如何為夜間運輸公司提供幫助的。通過向客戶提供標準信封和包裝箱,并要求在運輸標簽上填寫一致的信息,這些公司可籍此建立成熟的跟蹤系統。此外,這些策略還有助于在整個業務范圍內更好地進行各項規劃和決策工作,既包括確定傳輸帶寬度,也包含每個運輸工具能承載多少包裹以及需要多少運輸工具。
資產標準化可通過類似的方式提高效率,可在軟件開發工具中實現高效率和自動化并提高使用這些工具的團隊的工作效率。通過使用 RAS,開發人員可以將每個資產打包為元數據包裝,其中包含頂級屬性,例如資產的名稱、版本和描述(請參閱圖 1)。
如圖 1 中所示,RAS 資產具有一個有助于搜索和瀏覽的 classification 部分;此部分可以包含簡單的名稱/值對描述符和上下文聲明(如具體的領域、開發或部署上下文)。
圖 1 中所示的 solution 部分是資產的重要部分,描述提供解決方案的構件集合。
usage 部分提供有關使用可變點應用和自定義資產的指南??赡芸梢酝ㄟ^使用腳本和向導實現某些使用信息的自動化,這些腳本和向導與其他構件一起存儲在 solution 部分中。
related assets 部分定義資產與其他資產的關系,可幫助創建資產集合或系列,以形成粒度更大的解決方案。
為了支持組織中各種程度的重用、正式化和流程成熟度,很多 RAS 資產部分都是可選的。RAS 還可以通過配置文件 進行擴展和自定義。OMG 當前提供了三個配置文件:Default 配置文件、Default Component 配置文件和 Default Web Service 配置文件
Default 配置文件用于打包任意類型的軟件資產,而其他兩個配置文件分別用于與組件和 Web 服務一起使用。
![]() ![]() |
![]()
|
模式簡介
術語“模式”的定義非常多。如果不加留心,雖然的確應用了模式,也可能不會注意到使用了模式。這是模式一個好的特征,同時也是危險的特征。一方面,仍然可能不會注意到模式,而僅會看到所應用模式的好處。另一方面,沒有認識到應用模式的原因和目的,模式的基本原理本身、相關知識以及好處可能會被忽略,最終會被遺忘而不加利用??傊?,抽象既可能是我們的朋友,也可能成為敵人。
定義
但首先,什么是模式?此處,我們將借用一些思想先驅已在此領域獲得的工作成果:
James Coplien 將模式定義為“可解決在特定上下文中的問題的重復出現的結構配置,構成美學或文化價值的某個整體或系統的完整性。”(Organizational Patterns,第 4 頁,Pearson Prentice Hall)
Christopher Alexander 寫道:“每個模式描述在我們的環境中一再重復出現的問題,然后描述該問題的解決方案的核心內容。”(Alexander,1979)他還寫道:“每個模式都是一個三段式規則,表述特定上下文、問題以及解決方案之間的關系。”(Alexander,1979,第 274 頁)
Booch 寫道:“模式可提供某些上下文中的常見問題的良好解決方案。”(The Unified Modeling Language User Guide,第 370 頁,Addison Wesley)
盡管大多數人都認可這個定義,但在本文中,我們將選擇最常見的定義版本:
模式是對給定上下文中重復出現的問題的解決方案。
什么是模型驅動的開發?
模型驅動的開發基本上是用于指定和實現解決方案的軟件相關抽象??梢栽谡麄€軟件開發生命周期的各個地方使用模型。而且,在生命周期的任何位置,模型都是以特定的抽象級別加以表述的。
例如,業務流程模型描述任務、條件、資源、成本和時間安排。由于模型經過了優化,因此可能描述特定于 IT 系統或服務的資源的本性。這種類型的優化可能減少抽象級別。
另一個例子是用例模型,用于列出參與者。由于模型經過了優化,因此可能會描述用例實現的本性,對用于實現用例的組件和服務進行標識。同樣,這種類型的優化可能減少抽象級別。
抽象也可能向另一個方向發展,通過增加抽象級別,從而減少模型中的細節級別。
憑借著某種眼力,我有時候會問“有沒有別人發現模型的價值?”模型已經投入使用了相當長時間了。根據 Hermann Schichl 在《Modeling Languages in Mathematical Optimization》中的說法,“‘建模’一詞來自拉丁詞 modellus。它描述人類復制現實的一種典型方法。人類學家認為,構建抽象模型的能力是讓智人 (Homo sapiens) 具有競爭優勢的一個重要特征……”(History of modeling,第 25 頁)
隨著時間的推移,Schichl 進一步指出:“到公元前 2000 年,至少有三種文明(巴比倫、埃及、印度)具有一定的數學知識,并使用數學模型。”(History of modeling,第 25 頁)
Schichl 認為,早期使用的圖形模型之一是在天文學領域。在這個領域,托勒密于公元 150 年創建使用圓圈和中心點創建了太陽系的一個模型。顯然,此模型一直沿用到 1619 年,然后出現了一個更好的模型,該模型的基礎理論今天仍然在使用。(History of modeling,第 26 頁)
模型可提供進行溝通的手段,設計合理時,可提供能在相當長時間內使用的恰當抽象。有多少模型能夠使用近 1500 年,更不用說應用程序的一個或兩個版本了?
為特定上下文選擇恰當抽象非常關鍵。
模式規范和模式實現
考慮模式方面的工具提供情況,我們將模式規范和模式實現的概念分離開來。模式規范是描述模式的文本;您將在書中或網頁等上看到它。
模式可以采用多種形式之一實現;因此,對于每個模式規范,都可能會存在多個模式實現。模式可以實現為 UML 模型、組件或服務。
我們此處描述的模式是使用 UML 模型實現的,可使用一些轉換技術對這些模型進行優化。這要求使用模式引擎或機制來完成此任務。
![]() ![]() |
![]()
|
菜譜簡介
隨著存儲庫中資產數量的增加,我們面臨著嘗試找到那些將幫助解決問題的資產的艱巨任務。而且,我們還要承擔確定如何將一個或多個資產進行組合以創建粒度更大的解決方案的重任。
以更細粒度的方式重用資產具有模塊性和資產版本控制的好處。不過,將這些資產組合起來的工作可能引出有關使用資產的真正價值的問題。
同樣,有必要提供松散耦合方式,以對資產進行組合,更重要的是,規定在特定上下文中資產應如何進行組合。
為此,我使用了一個比喻“菜譜”。在烹飪法中,菜譜提供原料的列表,并就如何將這些原料混合到一起提供一些說明。廚師可以進行一定的靈活替換,以考慮當前的具體情況。就此來說,菜譜就是一個模板。
在軟件領域,我們可以借用菜譜的概念,將其用于創建模板解決方案,架構師和其他人員可以根據需要對其進行優化。此處的原料是細粒度資產,而菜譜可提供結合使用這些資產的流程指南。請注意,菜譜本身就是資產。
模式解決方案使用菜譜將很多模式組合到一起。菜譜描述各個元素——模式和其他資產——以及將這些元素一起使用來解決問題的方法。模式解決方案實現包含服務、組件和其他軟件構件,用于根據菜譜實現模式。
![]() ![]() |
![]()
|
設置 Rational Software Architect 環境
![]() |
|
現在已經給出了理論上的相關內容,下面讓我們了解一下在實踐中應如何操作。在本系列文章中,我們將使用 Rational Software Architect,因此,如果您尚未安裝該軟件,請現在進行安裝。(請參閱參考資料,以獲得相關鏈接。)還需要將 Rational Software Architect 更新到撰寫本文時已提供的 Fix Pack 6.0.1.1。Rational Software Architect 可方便地進行升級,方法為:選擇 Help > Software updates > IBM Rational Product Updater,并單擊 find updates 按鈕。
設置 RAS 客戶機
此處要進行的第一項工作是在 Rational Software Architect 中設置 RAS 客戶機。此 RAS 客戶機將用于訪問遠程 RAS 存儲庫。我們將使用的 RAS 存儲庫是 dW 所承載的一個 RAS 存儲庫。本系列文章中使用的可重用資產存儲在此存儲庫中,我們將在本系列文章中持續使用此存儲庫。
以下是設置 Rational Software Architect 客戶機所需的步驟:
./tools/ras
文件,并選擇“Solution Guide”資產。右鍵單擊該資產,并選擇 import。這將下載和安裝讓 Rational Software Architect 識別菜譜的 Eclipse 插件。安裝完成后,立即重新啟動 Rational Software Architect。 ./design_soa/recipes
文件夾,并選擇“SOA Implementation and Optimization of Services Recipe”資產。右鍵單擊該菜譜,在該上下文中有一個用于在解決方案指南中打開的選項。(注:由于當前解決方案指南插件中存在一個錯誤,您將需要首先將菜譜導入到工作區中。為此,請右鍵單擊該菜譜,并選擇 Import。接受了法律協議后,整個菜譜將導入到工作區中。接下來,切換到 Navigator 視圖,并右鍵單擊菜譜,并選擇 Solution Guide > Open Solution Guide View。這將打開菜譜,并允許您在工作區瀏覽菜譜的內容和結構。)之所以提供此功能,是因為需要使用 Solution Guide 來讓 Rational Software Architect 識別前面步驟中已經安裝的菜譜。 剛剛使用了從遠程 RAS 存儲庫下載的可重用資產對 Rational Software Architect 功能進行了擴展。同時也從遠程 RAS 存儲庫下載了用于構造 SOA 服務的菜譜,并可用于提供規定性指南、最佳實踐和模式,以幫助構建這些服務。
Requisite/Pro RSA/RSM 集成
要從這些文章最大地獲益,應該還進行相應設置,以將 Requisite Pro 與 Rational Software Architect 集成。要完成此任務,必須在您的系統上安裝 Rational Requisite Pro:(請參閱參考資料,以獲得相關鏈接。)提供 Rational Software Architect 時僅啟用了部分功能。要啟用更多的 Rational Software Architect 高級功能,請選擇 Windows > Preferences > Workbench >Capabilities 并啟用 Requirement Management 框。
./design_soa/requirements
來獲取。同樣,再次右鍵單擊資產,但這次在快捷菜單中選擇 download 選項。這是因為 Rational Software Architect 尚不知道如何處理 Requisite Pro 文件?,F在會將 zip 文件下載到磁盤上的位置。此測試 Requisite Profile 附加在本文的最后(請參閱下載,以下載代碼)。 Rational Software Architect 現在已配置為對此 Requisite Profile 進行讀寫。
![]() ![]() |
![]()
|
結束語
本文對菜譜、模式和可重用資產進行了逐一說明。我們對這些術語進行了介紹,并在它們之間建立了聯系。我們已將 Rational Software Architect 配置為瀏覽 dW 上的遠程資產存儲庫。使用了一個資產來讓 Rational Software Architect 識別菜譜。我們還訪問了此存儲庫中的 SOA Implementation and Optimization Recipe 資產。Rational Software Architect 還與 Requisite Pro 實現了集成,并下載了一個測試 Requisite Pro 文件作為資產在 Rational Software Architect 內打開,以便讀寫需求/用例。
現在已經準備好,可以在 SOA 應用程序參考示例上使用此 SOA Implementation and Optimization of a Service Recipe,此菜譜將提供規定性指南,指導如何在 MDD 環境中使用非功能需求來確定應該使用何種模式構建體系結構一致的應用程序。下一篇文章將介紹參考示例,并說明如何使用 Rational Unified Process,以及如何將 MDD 方法與可重用資產結合使用。
![]() ![]() |
![]()
|
下載
描述 | 名字 | 大小 | 下載方法 |
---|---|---|---|
Requisite Pro file for the recipe | IBMAutomotive.zip | 167KB | HTTP |
Flash movie for this article | Setup_RAS_and_ReqPro.zip | 2.9MB | HTTP |