軟件質量保證SOA設計模式應用技巧：理解模式相互關系 SOA架構
關鍵字：SOA設計模式 模式相互
設計模式多年以來一直是IT領域的一部分。甚至出現了一個完整的模式團體來培育新模式的發展，并且要圍繞應該如何說明模式以及相關的事情制定一些指南。
這是正確的，模式之間是相互關聯的。要制定設計模式，你需要理解這些關系。這些關系對于SOA是特別重要的，因為SOA的實施范圍一般要大于傳統的應用。因此，SOA設計模式要涉及面更廣，因此影響力也越大。
首先讓我們了解一些基礎知識并且回顧一下一種模式如何與另一種模式相關聯。有許多不同類型的關系。但是，最重要的兩個關系式依賴關系和支持關系。
為了應用一種模式，你也許需要使用另一個模式(或者已經使用了另一個模式)。這是很簡單的依賴關系。但是，這對于理解為什么存在依賴關系是很重要的。例如，在SOA設計模式目錄中，有一種模式稱作“邏輯集中化”。它實際上建立一個規則，按照這個規則，對于任何指定的解決方案邏輯的再利用部分來說，僅存在一個正式的服務。這就減少了冗余的風險，最大限度實現了在一個指定區域的服務的再利用潛力。它還構成了不可知環境的基礎。這是一種設計模式，用于單個服務中，以便為它提供多功能的范圍(因為它對于任何邏輯來說都是不可知的，因此它僅限于一個單個的目的)。
不可知環境和邏輯集中化共享培育服務中的再利用這個共同的目標。雖然邏輯集中化建立了獨特的邏輯單元，但是，不可知環境將保證擁有再利用潛力的人和單元都將僅僅限制在多用途邏輯中。這樣，它們就成了純粹的再利用服務。
簡言之，你會提出理由說不可知環境依賴于邏輯集中化，因為沒有集中化獨特的邏輯體，就很難把它們分成不可知的單元。在應用邏輯集中化模式之前，使用不可知環境是沒有意義的。
我們提到的另外一種關系是一種應用模式支持另一種應用模式。因此，與依賴性的關系不同，在這個案例中沒有直接的依賴關系。這就意味著這些類型的關系很容易錯過。一種支持性的關系簡單地意味著一種模式幫助實現另一個模式的目標或者最終目的。
我們重新看一下邏輯集中化的例子。這個模式的目標是培育在服務中的再利用。然而，應用程序集成的歷史已經教會了我們通過多個點對點的集成渠道實現連接，達到一個靈活性的架構，使負擔沉重的企業能夠繼續發展，特別是面對業務變化的時候。
這與邏輯集中化有什么關系呢?設想一個包含若干數據庫和一個老式的系統的服務。既使我們集中了這個服務代表的邏輯，我們仍然不能做任何事情來阻止通過傳統類型的集成渠道直接訪問這些基本的資源。這正是合同集中化進入這個環境的地方。
合同集中化設計模式限制外部訪問一個服務，訪問出版的技術合同(或者接口或者API)。這就意味著外部程序或者應用程序(我們可以指服務用戶)不能接觸這些基本的資源，因為這個唯一的進入點是這個服務合同。
文章來源于領測軟件測試網 http://www.kjueaiud.com/