SOA設計應用：理解模式之間的相互關系

申請免費試用、咨詢電話：400-8352-114

設計模式多年以來一直是IT領域的一部分。甚至出現(xiàn)了一個完整的模式團體來培育新模式的發(fā)展，并且要圍繞應該如何說明模式以及相關的事情制定一些指南。

這是正確的，模式之間是相互關聯(lián)的。要制定設計模式，你需要理解這些關系。這些關系對于SOA是特別重要的，因為SOA的實施范圍一般要大于傳統(tǒng)的應用。因此，SOA設計模式要涉及面更廣，因此影響力也越大。

首先讓我們了解一些基礎知識并且回顧一下一種模式如何與另一種模式相關聯(lián)。有許多不同類型的關系。但是，最重要的兩個關系式依賴關系和支持關系。

為了應用一種模式，你也許需要使用另一個模式(或者已經(jīng)使用了另一個模式)。這是很簡單的依賴關系。但是，這對于理解為什么存在依賴關系是很重要的。例如，在SOA設計模式目錄中，有一種模式稱作“邏輯集中化”。它實際上建立一個規(guī)則，按照這個規(guī)則，對于任何指定的解決方案邏輯的再利用部分來說，僅存在一個正式的服務。這就減少了冗余的風險，最大限度實現(xiàn)了在一個指定區(qū)域的服務的再利用潛力。它還構(gòu)成了不可知環(huán)境的基礎。這是一種設計模式，用于單個服務中，以便為它提供多功能的范圍(因為它對于任何邏輯來說都是不可知的，因此它僅限于一個單個的目的)。

不可知環(huán)境和邏輯集中化共享培育服務中的再利用這個共同的目標。雖然邏輯集中化建立了獨特的邏輯單元，但是，不可知環(huán)境將保證擁有再利用潛力的人和單元都將僅僅限制在多用途邏輯中。這樣，它們就成了純粹的再利用服務。

簡言之，你會提出理由說不可知環(huán)境依賴于邏輯集中化，因為沒有集中化獨特的邏輯體，就很難把它們分成不可知的單元。在應用邏輯集中化模式之前，使用不可知環(huán)境是沒有意義的。

我們提到的另外一種關系是一種應用模式支持另一種應用模式。因此，與依賴性的關系不同，在這個案例中沒有直接的依賴關系。這就意味著這些類型的關系很容易錯過。一種支持性的關系簡單地意味著一種模式幫助實現(xiàn)另一個模式的目標或者最終目的。

我們重新看一下邏輯集中化的例子。這個模式的目標是培育在服務中的再利用。然而，應用程序集成的歷史已經(jīng)教會了我們通過多個點對點的集成渠道實現(xiàn)連接，達到一個靈活性的架構(gòu)，使負擔沉重的企業(yè)能夠繼續(xù)發(fā)展，特別是面對業(yè)務變化的時候。

這與邏輯集中化有什么關系呢?設想一個包含若干數(shù)據(jù)庫和一個老式的系統(tǒng)的服務。既使我們集中了這個服務代表的邏輯，我們?nèi)匀徊荒茏鋈魏问虑閬碜柚雇ㄟ^傳統(tǒng)類型的集成渠道直接訪問這些基本的資源。這正是合同集中化進入這個環(huán)境的地方。

合同集中化設計模式限制外部訪問一個服務，訪問出版的技術合同(或者接口或者API)。這就意味著外部程序或者應用程序(我們可以指服務用戶)不能接觸這些基本的資源，因為這個唯一的進入點是這個服務合同。

這種簡單的限制從長遠看將增加服務的再利用性。隨著時間的推移，這個服務能夠有效地隨著業(yè)務的變化而發(fā)展，擴大或者甚至取代其基本的資源，同時最大限度地減少這些改進對外部服務消費者的影響(因為由于合同集中化，他們不能直接連接到這些資源)。這個服務的壽命越長，它的長期再利用的潛力就越大。

因此，雖然邏輯集中化不需要合同集中化，但是，它肯定會從其應用程序中受益。事實上，當這兩個基礎的方式一致地應用到一個服務目錄(服務集)中的時候，他們建立了一個非常能夠推廣業(yè)務靈活性的環(huán)境。因為這些服務能夠重復地再利用，我們要求對每一個新的解決方案建立較少的冗余的邏輯(減少解決方案交付的時間和成本)。因為這些服務只能通過其合同訪問，我們避開了建立很難改變的整合渠道。因此，我們最終將建立能夠有效地重復利用的服務并且與業(yè)務一起發(fā)展。

當然，SOA的戰(zhàn)略目標要實現(xiàn)的東西比僅僅使用這兩個模式多得多。然而，這是SOA設計模式建立的基礎，對于取得SOA的成功是至關重要的。甚至最強大的、可升級的和高級的基礎設施也不能幫助你把設計遭到的服務轉(zhuǎn)變?yōu)楦邇r值的IT資產(chǎn)，在不斷變化的商業(yè)環(huán)境中不斷帶來回報。服務需要從頭開始設計并且預測和適應變化。這就是所謂的面向服務的。

在我們做結(jié)論之前，讓我們簡單地介紹一下模式應用順序和模式語言的概念。我們僅解釋了合同集中化如何支持邏輯集中化的。但是，當設計服務時，你首先采用哪一種模式呢?雖然沒有絕對的規(guī)則，但是，你可能會有偏愛。例如，當同時建立一個服務集模型的時候，為了恰當?shù)匕逊辗譃楠毺氐倪壿媶卧?，受使用邏輯集中化是有意義的。然后，你可以使用合同集中化。這樣，這些單元(服務)的每一個部分都將得到一個技術合同，作為正式的進入點。

我們剛才解釋的是模式應用順序在一個具體順序中應用的兩個模式。一個模式目錄是理想地構(gòu)造的，因此，你能夠根據(jù)你們的要求、偏愛和局限性提出許多創(chuàng)造性的應用順序。有些目錄甚至提供了推薦的模式順序，許多單個的模式被認為是經(jīng)過證明的設計解決方案。這個應用順序本身也被認為是經(jīng)過證明的。

把許多模式結(jié)合到無止境的順序中的自由使一個模式目錄不僅僅是設計模式的記錄文件，而是一個“模式語言”。同任何書面語言一樣，你有能夠組成一個句子的詞匯。這些句子能夠進一步組成一段話、一篇文章等等。人們可以用同樣的方式想象一個模式語言。根據(jù)你的技能水平，當你拿筆在一張紙上寫字的時候，你可以寫出一個偉大的文學作品，也可以寫出不偉大的文學作品。同樣，使用模式語言工作的關鍵取決于你的知識和對模式本身的理解。通過理解模式是如何關聯(lián)的，可以理解模式內(nèi)部的主要部分。（CIO時代網(wǎng)）