使用可重用資產構建 SOA 應用程序，第 2 部分: SOA 菜譜參考示例

本系列探索可重用資產、菜譜（recipes，本文中借用菜譜來喻意模板）和軟件模式可以如何促進 SOA 解決方案的開發。本文是本系列的第二篇文章，將描述可以在其中應用菜譜的參考示例。以后的文章將說明如何將 SOA 模式應用于此類示例，以滿足非功能需求。

引言

本系列的第一篇文章“可重用資產、菜譜和模式”介紹了菜譜是一種提供規定性指南的方法，以便使用模式和分層體系結構創建 SOA 實現。其中介紹的菜譜稱為 SOA Implementation and Optimization of Services Recipe。在本文中，我們將對此菜譜進行詳細的分析，并討論其引用的其他可重用資產。應該注意，此菜譜并不完整；我們僅使用其來進行演示。

在前一篇文章中，我們建立了 IBM® Rational® Software Architect 客戶機來連接到 IBM Rational developerWorks RAS 存儲庫，并導入了 SOA Implementation and Optimization of Services Recipe。這個特殊的模式菜譜使用 SOA 模式實現和優化服務。其主要受眾是致力于提供 SOA 應用程序開發方面的規定性指南的架構師和開發人員。

我們將結合一個參考示例來說明可以如何使此菜譜。此菜譜使用模型驅動的開發環境（Rational Software Architect 就提供了此類環境）。菜譜還將使用 Rational Unified Process 作為使用的方法，該方法是以用例為中心的方法，包含迭代開發和和可視模型。

我們首先對 SOA Implementation and Optimization of Services Recipe 和參考示例進行一下介紹，以便說明可以如何將菜譜應用到參考示例。該參考使用模型驅動的開發方法，并利用 Rational Software Architect 建模功能來開發用例模型、分析模型、設計模型和服務模型。

Implementation and Optimization of Services Recipe

在前一篇文章中，我們將 SOA Implementation and Optimization of Services Recipe 導入到了 Rational Software Architect 中。這個特殊的菜譜處理如何應用和使用一系列 SOA 模式。系統的非功能需求（如性能可伸縮性、互操作性）可以用于確定要使用哪個模式。這些非功能需求提供了恰當使用的指南。此菜譜主要針對要在 SOA 應用程序的開發中提供規定性指南的架構師和開發人員。

此菜譜有兩個主要的指南：

1. 選擇實現選項
2. 將模式應用到服務實現

在本文中，我們將詳細分析如何選擇實現選項。這將為本系列的后續文章奠定基礎，以便將各個模式應用到服務實現中。

選擇實現選項

顧名思義，該菜譜處理兩種類型的服務：

1. 全新服務：服務定義通常為已知（或許是通過某種業務服務分析活動得到的）。該菜譜還鼓勵架構師或開發人員查找以前具有相似非功能需求的服務的實現。這樣可確保當前實現將與以前實現的最佳實踐保持體系結構一致性。
2. 與已經存在的遺留應用程序或服務相關的服務。通常，這是遺留服務或應用程序，不受開發人員或架構師的看法影響。這代表了當前存在的大量遺留應用程序和服務，需要將其作為較大的 SOA 工作中的一部分加以利用?，F在必須滿足服務的非功能需求，而這通常會涉及可伸縮性和性能問題。

圖 1 是 SOA Implementation and Optimization of Services Recipe 的關系圖，說明了架構師所要遵循的步驟，以評估用例的用戶需求和實現與優化服務方面的功能與非功能需求。

圖 1. SOA Implementation and Optimization of Services Recipe 略圖
soa-reuse2/Recipe4.gif" width="545" twffan="done"/>

此菜譜使用模型驅動的開發 (MDD) 方法，并允許建模人員或架構師將重點放在抽象層，以更好地設計解決方案的體系結構。

從其本質而言，菜譜將盡可能調用更為豐富的信息源，由于我們在使用 MDD 方法開發 SOA 解決方案，因此菜譜的第一個調用是鏈接到 Rational Unified Process，以便使用 SOA。Rational Unified Process 提供軟件開發流程指南，這些指南是通過對大量開發活動中使用的最佳實踐進行提煉得到的。

菜譜表明，將首先分析用例，以確定需要構建哪些用例以及哪些可以利用現有的遺留服務或應用程序。

• 對于現有應用程序，將分析非功能需求 (NFR)，并基于這些 NFR 應用響應的模式。
• 對于需要構建的服務，將分析以前的服務實現，以實現體系結構一致性。

在這兩種情況下，如果可用，將對服務模型和實體模型進行分析。在 Rational Software Architect 之類的 MDD 環境中，這些模型將是作為基本安裝的一部分提供的 Rational Software Architect 模型，其用戶體驗方面將遵循 RUP 的風格。菜譜使用了與圖 2 中所示類似的 n 層體系結構，可在其中將 SOA IF 模式應用到相應的層。

 

SOA 模式

在討論 SOA 模式的概況前，將 n 層體系結構視為以下所給出的情況。簡單的三層體系結構將包括表示層、業務層和持久層。在 SOA 環境中，我們可以將業務層進一步劃分為服務層、控制器層和實體/對象管理層。此分層情況如圖 2 中所示。會話 Fa&clearcase/" target="_blank" >ccedil;ade、消息 Façade 和業務委托等核心 Enterprise JavaBean™ 模式屬于控制器層。

菜譜所使用的 SOA 模式與業務層相關。所有這些模式都源自戰略性 IBM SOA 工作。其中的每種模式都使用 Rational Software Architect 模式引擎作為模式規范和模式實現開發。有關更多信息，請參閱參考資料部分。

討論模式時——以 Gang of Four 的《Design Patterns》為例——會涉及到人們感興趣的兩個不同元素。一個是描述模式的實際文本。這就是將在書上看到的內容，如有關適配器模式的章節。

另外，還有實現該模式的設計工具元素。例如，Rational Software Architect 中就有實現 Gang of Four 書中的不同設計模式的 UML 構件。因此，如果希望將適配器應用到設計中，將從選擇面板選擇對應的元素，并在工具中進行一些操作，以對設計進行轉換，從而實使用該模式。

第一個我們稱為“模式規范”。第二個我們稱為“模式實現”。本系列的后續文章將更為詳細地討論這些模式。

將考慮以下四種模式；將會在本系列的后續文章中更為詳細地對這些模式進行分析：

• WS 響應模板模式（有關模式規范，請參閱參考資料）提供了對粗粒度服務的細粒度訪問，并提供了服務定義的靈活性。
• 請求端緩存模式（有關模式規范，請參閱參考資料）提供了請求端緩存功能。
• 首選數據源模式是用于進行服務聚合的一種微流模式。
• 面向方面的模式將結合使用方面、AJDT 和模型驅動的開發。

圖 2：n 層體系結構

這種業務層細化方式具有很多好處：

1. 將服務定義同業務邏輯（控制器）以及數據（實體）訪問分離，可確保實體中不會透露任何業務邏輯。
2. 在 Web 服務實現中，服務可以委托給控制器，以對有關方面進行恰當的分離。僅在進行消息攔截時會考慮服務，但將委托給控制器，以確定業務已完成。
3. 控制器將訪問其他服務或通過其創建、讀取、更新和刪除 (CRUD) 操作訪問后端實體，從而實現服務業務邏輯。
4. 現在可以在每個層實現相應的模式，從而滿足服務功能需求和系統要求，并產生體系結構一致的應用程序和服務。

為了幫助架構師或開發人員更好地理解此菜譜，還將提供一個示例。

回頁首

SOA 參考示例

在 SOA Implementation and Optimization of Services Recipe 中集成了一個示例，以便進行演示。在此部分，我們將逐步了解該菜譜如何訪問用于構造參考示例的資產。為此，我們首先需要在 Rational Software Architect 中建立一個項目，以便承載這些資產。通常，這些資產將為用例、服務、分析和設計模型。要在 Rational Software Architect 中創建簡單的項目，可以使用以下命令序列：File > Project > Simple > project call the project "Retail"。

該示例演示各個 SOA 模式如何以可組合的方式一起工作，并說明這些模式如何與其他模式進行交互。此示例基于零售鏈進行松散耦合，重點是一個名為“Lookup Item”的業務服務。Lookup Item 通常將用于需要在銷售前在庫存系統中查詢商品的零售方案中。通?？蓪?ldquo;Lookup item”作為粗粒度業務服務的一個例子，我們希望從其中了解提供此業務服務所需的對應 IT 服務。

圖 3. Lookup item 業務服務

業務流程分解可幫助更好地理解用于提供此業務服務的復雜流程。圖 4 顯示了此業務流程內的復雜情況。其中使用了兩個其他服務，catalog 和 inventory 服務。

• catalog 服務用于查找正在尋找的商品的編號或 SKU。
• inventory 服務使用此 SKU 來確定庫存系統中是否存在此商品。該服務將首先查找本地庫存系統。如果此查找失敗，它將搜索數據倉庫目錄。該流程還可以隨后搜索外部供應商等。圖 4 中更為詳細地對此進行了說明：

圖 4. Lookup item 業務流程分解

業務流程分解會將業務服務與業務流程分離開。業務分析人員現在可以不必了解服務實現的復雜性，而直接考慮將作為某個總體服務流程的一部分的 Lookup item 服務。業務流程分解還可幫助理解提供此流程及其服務所必需的 IT 服務。

用例

此用例模型作為可重用資產規范（Reusable Asset Specification，RAS）資產存儲在 dW RAS 存儲庫中，可以從該菜譜進行訪問。圖 5 顯示了如何從此菜譜訪問和導入用例模型。請確保將用例模型導入到之前創建的 Retail 項目。

圖 5. 從菜譜導入用例模型資產

用例模型可幫助架構師或開發人員理解需要構建的軟件構件和服務。圖 6 中所示的用例模型與圖 3 中所示的業務流程模型非常相似。在此示例中，業務服務和 IT 服務之間存在非常緊密的映射，但并非總是如此。該用例模型從 IT 的角度對 Lookup item 進行了說明。

圖 6. Lookup item 用例模型

回頁首

服務標識

在本例中，業務服務和 IT 服務之間存在一對一的映射關系。但并非總是這樣。將 IT 服務和業務服務視為一體，認為二者一樣，這是一種常見且非常危險的錯誤想法。SOA 模式參考體系結構中包括兩個 IT 服務。分別是：

1. catalog 服務，在產品目錄中查找商品編號
2. inventory 服務，根據庫存系統查詢這些商品的現貨數量。

架構師將確定哪些用例可以使用之前已有的應用程序或服務實現，而哪些用例需要進行構造或擴展。在 SOA 模式參考示例中，有一個之前已有的 catalog 應用程序，該應用程序公開了一個 Java 接口。庫存系統需要包含一系列對現有后端數據庫（如本地商店數據庫和中央倉庫數據庫）的調用。在服務定義的下一部分，將從 UML 和 WSDL 的角度對每個用例進行更為詳細的復查。

可以采用兩種方法得到服務模型。這并不是二者任選其一，有時候某個方法相比之下更為合適。下面讓我們更為詳細地了解一下其中的相關信息：

1. 自頂向下方法：在 IBM 面向服務的建模方法（Service Oriented Modeling Approach，SOMA）等自頂向下方法中，將通過使用業務分析對服務進行標識和優先排序。服務的細節通過業務流程模型進行確定。保險行業豐富的領域特定模型（如業務流程模型、業務對象模型）的一個例子就是 IBM Insurance Application Architecture（請參閱側欄）。服務的細節是從業務流程模型確定的。描述 IT 服務的 WSDL 是從在 WebSphere® Business Integration Modeler 等工具中創建的業務流程模型生成的。
2. 自底向上方法：在自底向上方法中，服務是使用現有應用程序包及其接口的知識并結合用于創建組合服務的流程編排方法來定義的。這些服務的 WSDL 通常從類模型生成。

catalog 服務

此 inventory 服務模型包含 catalog 服務和 inventory lookup 服務，作為 RAS 資產存儲在 dW RAS 存儲庫中，可以從菜譜對其進行訪問。通過菜譜瀏覽到以下所示的位置，并將 Ref Example Asset：SOA Inventory Service model 導入到前面創建的 Rational Software Architect 項目 Retail 中?？梢詮牟俗V訪問 catalog 服務，如下圖中所示：

圖 7. SOA Inventory Design Model RAS 資產

catalog 服務將在產品目錄中查找商品編號——產品的庫存編號（Stock Keeping Unit，SKU）。在模型驅動的開發中，服務是應用了 UML 2.0 Profile for Software Services 的 UML 模型類模型。UML 2.0 Profile for Software Services 提供了用于描述服務的模型的公共語言。

UML 2.0 Profile for Software Services 提供了一種描述服務的公共語言（覆蓋了整個開發周期的一系列活動），還可為不同的干系人提供不同的視圖。UML Profile for Software Services 是 UML 2.0 的概要，對服務建模、SOA 和面向服務的解決方案進行了考慮。該概要已在 IBM Rational Sofware Architect 中實現，并成功地用于對復雜客戶場景進行建模，同時可以幫助人們了解開發面向服務的解決方案時的注意事項（請參閱參考資料）。

IBM Insurance Application Architecture IBM Insurance Application Architecture 是一組全面的信息、流程和集成模型集，代表了保險行業的系統開發最佳實踐。它是一個信息體系結構藍圖，包含了詳細的保險業務內容，可應用到整個企業，也可按具體的項目進行應用。它允許保險公司為信息系統創建詳細的規范和跨企業的體系結構。這些模型代表了 300 多年的經驗積累，包含了來自很多領先的金融機構的信息（請參閱參考資料）。

我們現在有了一個用于詳細地表示如何實際實現服務的模型。通過使用此類模型，可以對應用程序和體系結構模式進行應用，以滿足性能、可伸縮性等相關的非功能需求。catalog 服務示例使用了 WS 響應目標模式（請參閱參考資料）和安全模式等模式?？梢詮?catalog 服務模型應用從 UML 到 WSDL 的轉換和從 UML 到 XSD 的轉換，以創建服務的 WSDL 和 XSD 表示形式，從而提供兩種不同但相互補充的方法來在不同的抽象級別可視化服務。這些轉換不在本文的討論范圍之內，將在下一篇關于 WS 響應目標模式的文章中進行討論。

• catalog 服務 UML 模型：catalog 服務（參見下文）
• catalog 服務規范 (WSDL)：catalog 服務 WSDL

catalog 服務模型

圖 8 顯示了 catalog 服務模型。該模型包含兩個操作：

• getCatalog() 操作接受一個主鍵作為參數，并返回 Catalog
• getCatalogs() 操作接受一個主鍵數組為參數，并返回 Catalogs 數組

圖 8. Catalog 服務 UML 模型

catalog 數據模型

圖 9 顯示了 catalog 消息模型。此模型中包含以下非常明了的事實：

• 每個 Catalog 消息包含多個 CatalogItem 消息
• 每個 CatalogItem 消息包含多個 FeatureValue 消息
• 每個 FeatureValue 消息包含一個 Feature 消息

圖 9. Catalog 消息 UML 模型

inventory 服務

inventory 服務提供兩個操作。首先是一個查詢，確定庫存中是否包含足夠的商品，以滿足訂單所需的數量。在零售行業，倉庫中的現有商品數量稱為現貨量（Quantity on Hand，QoH）。第二個操作記錄庫存水平的變化，此變化是由于商品售出或新進貨物引起的：這稱為庫存動向。此服務也能在兩個不同的抽象級別進行可視化，與上面的 catalog 服務類似。

• inventory 服務 UML 模型：inventory 服務
• inventory 服務規范 (WSDL)：

inventory 服務模型

圖 10 顯示了 inventory 服務模型。根據上面的服務描述，該模型包含兩個操作：

• getQoH() 操作接受一個 QoHRequest 作為參數，并返回 QoHResponse
• inventoryMovement() 操作接受一個 Integer 作為參數，并返回 Boolean

圖 10. inventory 服務 UML 模型

inventory 數據模型

inventory 數據模型允許指定用于指定庫存源的位置的請求。這個源可以為商店或地區倉庫等。

圖 11. inventory 數據 UML 模型

回頁首

標識遺留應用程序

遺留 catalog 應用程序設計模型

參考示例遺留 catalog 應用程序設計模型可以從 SOA Implementation and Optimization of Service Recipe 進行訪問，其訪問方式與前面導入到 Rational Software Architect 中的 SOA inventory 服務模型和 SOA inventory 用例類似。

圖 12. 訪問遺留 catalog 應用程序設計模型

圖 13 顯示了遺留 catalog 應用程序的 UML 類關系圖。此應用程序是一個 Java™ 組件，公開了一個 Java 接口。getCatalog() 和 getCatalogs() 操作是非常粗粒度的操作，因為將分別返回整個目錄和目錄列表。

圖 13. 遺留 catalog 應用程序的 UML 類關系圖

回頁首

結束語

在本系列的第一篇文章中，我們介紹了如何將 Rational Software Architect 作為 RAS 客戶機來以菜譜的形式檢索可重用資產。本文對此方法進行了擴展，以演示如何使用這些菜譜產生服務，以及可以如何使用模式來構建這些服務，以滿足特定的非功能需求。

可以通過采用自頂向下業務分析方法（構建新服務時）或自底向上方法（將 SOA 用于遺留系統轉換時）來標識服務。

為了演示如何在服務構造期間應用模式，我們使用了一個參考服務示例（可作為 RAS 資產下載）：此參考示例以 SOA Implementation and Optimization of Services Recipe 為基礎，提供了使用此菜譜的詳細指南。

本系列的下一篇文章將說明如何將 WS 響應模板模式應用于 Catalog 服務模型（請參閱參考資料），以得到一個更為靈活的客戶機友好接口。

原文轉自：http://www.kjueaiud.com