分析和設計

　　在本系列的前幾篇文章的基礎上，第3部分將帶您繼續面向服務的體系結構(SOA)的術語之旅。您將學習一些新的術語，包括服務標識、規範、實現，以及設計原則，並瞭解它們為什麼是SOA成功的基礎。

　　引言

　　在任何領域中，語義都非常重要，而在SOA中更是如此。由於SOA涉及多個團隊和組織，因此就相關術語達成一致至關重要。本系列將帶著您開始SOA之旅，為您定義各種基礎術語和它們背後的重要概念。您將瞭解SOA領域中需要理解並用於溝通的各個詞彙。對於每個術語，將說明它在SOA領域中有何重要性、在這種情況下的含義、相關的標準有哪些以及與其他術語的區別如何。

　　第1部分中確定了業務的焦點，並通過定義服務、SOA等術語為後續部分打好了基礎。第2部分涵蓋了開發流程、模型和資產。這一部分是本系列的第三期，在其中，您將探索各種術語和技術，它們有的與在高抽象級別（分析）下設計SOA有關，另一些則涉及如何推進到較低的抽象級別（設計），後一種級別的下面緊接著程式碼級。

　　關於組織方式的說明

　　以下列出的術語並不是按照字母順序排列的，同時也未按照其重要性進行排列。相反，我們將按照構建塊的方式對其進行組織。第1部分最先介紹的是服務，因為若要理解SOA框架，它大概是最重要的一個概念。本系列接下來的各部分是以服務概念為基礎的，為了定義其他術語，它們對與特定原則有關的概念進行分組，如本文中的分析 和設計。

　　分析和設計

　　本系列的第2部分介紹了IBM Rational Unified Process (RUP)，後者在需求和實現之間定義了一套被稱為分析和設計 的原則。分析和設計的內容包括若干活動，通過這些活動，可根據功能和非功能需求集來指定初始的IT體系結構。其他一些活動也可作為分析和設計的基礎，這些活動對初始的體系結構加以細化，使抽象級別由分析級進入設計級，這一細化程度足以讓開發人員生成和編寫出實現程式碼。

　　SOA分析和設計也可以指以下術語中的一個或多個：

　　·服務建模
　　·面向服務的分析和設計
　　·面向服務的建模和體系結構(SOMA)
　　·Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA)

　　分析會在較高的（概念級）抽象級別上對將要構建的系統進行描述。分析的輸入是一組需求和現有的資產（或是應用程式或系統）。輸出則是對需要構建的各個方面的描述。分析對SOA來說是至關重要的，因為通過分析，可以在服務標識期間使IT與業務保持一致。分析結果將作為輸入在設計中使用。

　　設計會描述將要構建的系統，更重要的是，它還會對如何構建加以描述。

　　大多數體系結構（在第1部分中有述）工作是在分析和設計的工作流中、在專案的細化階段執行的。

　　面向服務的分析和設計利用了分析和設計原則（如物件導向的開發或基於元件的開發中的原則）。例如，您也許還記得所謂的物件導向的分析和設計(OOAD)。不過，必須注意的是，SOA的工作重點始終在於服務（而不是物件或元件）。

　　注意：分析級模型常會發展為設計級模型，所以對於分析和設計而言只有一套RUP原則。

面向服務的分析和設計工作的主要輸出是一個服務模型（即先前所說的服務規範）和一個設計模型，服務模型記錄了面向服務的系統中所有重要的體系結構部件，而設計模型則進一步闡述了服務模型應如何實現的細節。這兩個模型對SOA設計進行了全面說明，開發者可以據此明白無誤地執行這一實現。

　　在下列各部分中將描述相關任務，為您介紹面向服務的分析和設計的相關術語。

　　注意：術語標識和規範適用於基於元件的開發中，而術語規範和實現則是由通用建模語言(Unified Modeling Language, UML)定義的。這三個術語構成了RUP SOMA的核心活動（術語的含義未變）。

　　服務標識

　　服務標識 是核心的面向服務的分析活動。服務標識的目的是將各個分組的概念化服務及其操作標識出來。

　　這些經過標識的服務對於業務而言是有意義的，業務需要這些服務。事實上，業務分析師會幫助軟體架構師進行這項工作。下一部分將介紹服務設計原則，您會了解到對服務邏輯分組的需求、對服務及其操作的業務命名的需求。這些都是在服務標識期間決定的，其間使用了多種技術，RUP SOMA中描述的那些技術也包括在內。

　　在第1部分中，您將瞭解到解決方案堆疊參考模型和它的各個功能層次：處於頂端的是使用者和業務流程，服務位於中間，作業系統和元件在最底層。在這一模型的基礎上，您可以採取不同的方法標識服務（具體方法取決於您是從示意圖的頂部還是底部開始）。我們來深入瞭解一下：

　　自頂向下方法

　　業務體系結構工作從一組業務目標開始，標識出一個或多個應予關注的業務流程，這在SOA中是非常典型的。通過業務建模工作，可能會出現已經過設計的業務流程（即未來的流程），對於正在設計中的系統，它們可以被視為功能性的需求。

　　自頂向下方法旨在分解業務元素（主要是業務流程和用例），然後將它們細化為適合服務的粒度。在使用自頂向下方法的過程中，您通常要在業務任務中標識出各種服務操作。這種做法的好處在於，您可以確保標識的服務與業務保持一致。

　　自底向上方法

　　自底向上方法旨在分析現有的IT資產（如遺留的應用程式和系統），找出可以作為服務公開的功能，以便重用它們。

　　重用是SOA的一個重要組成部分，對於SOA的成功是極為關鍵的。您可能知道，遺留應用程式（即已經部署的應用程式）是您的公司最寶貴的資產，應該加以利用。例如，自底向上方法將分析現有的資訊管理系統(IMS)事務或COBOL程式。

　　對於自底向上的分析，有一句忠告：您必須謹慎從事，不要盲目地公開現有的IT功能。例如，用於建立、讀取、更新、刪除(CRUD)資料的各項服務的粒度可能太小，無法與業務保持一致。

　　此外還要注意，您應使用現有的資產分析工具（如IBM WebSphere Studio Asset Analyzer），這一點至關重要，因為準確的部署和執行情況常常是無人知曉的。

　　中間相遇方法

　　中間相遇方法在需求（由自頂向下的分析標識出來的服務）和現有的IT資產提供的功能之間進行協調。

　　中間相遇方法需要業務分析師、軟體架構師和遺留應用程式專家彼此協作。注意，雖然在特定專案的上下文環境之外進行的自底向上分析也是有價值的（例如，某個企業體系結構團隊對候選服務進行編目），但事實上，作為專案的一部分，在工作開始時通常會採用自頂向下方法，對一個或多個業務流程進行分解。此後，會在這個上下文環境中進行自底向上的分析，試著為所需的服務找到與之匹配的項（中間相遇方法）。

　　通過上述三種方法，可對服務集及其操作進行標識和驗證（例如，通過驗證，可以確保服務先前並不存在，或服務與業務保持一致），並對它們分組，歸入各個邏輯類別（如業務元件或業務功能區域）。另外還要標識業務項（如策略或索賠），這些業務項主要來自現有的資料遺留應用程式。下一個步驟是完整地指定這些服務及其操作，定義它們的結構和行為。

服務規範

　　服務規範和實現是核心的面向服務的設計活動。服務規範 旨在為那些在體系結構方面具有重要意義的服務元素設計它們的結構和行為。

　　服務模型

　　服務規範的主要輸出是一項RUP SOMA工作產品，叫做服務模型，它包含多種構件，如服務規範（介面）、服務提供者和服務協作。服務模型必須足夠完善，以使服務提供者和使用者能明確地知道該服務是怎樣的。

　　對服務的指定，包括以下各項設計：

　　服務規範

　　在服務模型中，服務規範構件是一個介面，用來描述由某個服務提供的各項操作。

　　此外，還可以通過設計，讓服務訊息充當操作輸入、輸出或故障引數。

　　您可能會認出源自物件導向範例的介面和各種操作概念。對訊息、協作和策略（在本文的稍後部分有述）的重視，這可以被看成是由面向服務帶來的一項進步。

　　服務規範充當了服務提供者和服務使用者之間的協議。它定義了服務的結構和行為。

　　服務提供者

　　在服務模型中，服務提供者構件會將相關的多個服務集中起來，進行分組。

　　服務提供者中包括：

　　·必需的服務規範（如果該服務如下列部分描述的那樣，是一個組合服務，且屬於某個協作的一部分）。
　　·提供的服務規範。
　　·提供的服務。

　　例如，有一個名為Sales Management的粗粒度服務提供者，它支援銷售管理功能區域。這個服務提供者可以提供兩個服務，分別稱作Account Activation和Application Inquiry，其中Account Activation服務的型別為Account Activation服務規範。

　　在服務提供者的設計中，應利用那些來自基於元件開發中的原則。通常，服務提供者是由UML元件表示的，服務將作為這些元件的UML埠。注意：服務（埠）的型別是由服務規範定義的。

　　服務協作

　　在服務模型中，服務協作構件代表兩個或多個服務之間的通訊。服務協作規定了服務在與其他服務組成的環境中的動態行為。

　　與協作相關以及意義相近的術語有編排、協調或組合。

　　原子服務是指不需要其他服務的細粒度服務。組合服務的粒度較大，需要其他服務為其提供服務。因此，組合服務充當了服務使用者的角色，它總是需要相關的服務協作。

　　在第1部分中，您已經瞭解到，業務流程執行語言(Business Process execution Language, BPEL)可以用於指定某個業務流程流的可執行版本。它在服務協作領域也扮演著重要角色，因為它可以用來實現一個組合服務，後者是由多個原子服務通過協作構成的。

　　注意，服務使用者和服務分割槽（即SOA的結構）也需要利用設計來處理；本文不會深入探討這一問題，因為它屬於細節內容。

　　服務質量方法

　　如果使用的是傳統的（非SOA的）方法，則設計需要處理功能性（如用例和業務流程）和非功能性（如服務質量，即QoS）需求。

　　QoS描述應當成為服務規範的一部分。此外，您還應使用被證明有效的設計模式來處理它們。（在服務實現期間，通常會頻繁地使用設計模式。）

　　與服務需求使用狀況有關的策略也需要在設計級進行處理。對於策略，將在本系列後面的部分予以介紹。

模型驅動的開發(MDD)方法

　　為了讓設計明確、完整、沒有歧義，您應當藉助UML（請參閱第2部分）等建模語言來設計服務。例如，您應記住，服務提供者通常是由帶有UML埠的UML元件來表示的。此外，UML協作或序列關係圖也支援服務協作的建模。更確切地說，您應當使用UML概要來進行面向服務的設計，如第2部分中介紹的UML 2.0 profile for Software Services。

　　MDD允許您在不同抽象級別對元素進行建模和指定。您可能已經注意到，在這一系列活動的進展過程中，是逐漸向較低的抽象級別深入的。先是業務級，然後是分析級，現在則到了設計級。在本系列以後的各篇文章中，您將瞭解程式碼級的實現。MDD提供了各抽象級別之間的半自動轉換。例如，您會發現，您可以根據服務模型工作產品生成Web服務描述語言(Web Services Definition Language, WSDL)檔案。而且，您最終還可生成程式碼（通常是根據設計模型生成的），作為SOA實現的基礎。

　　MDD方法還支援可跟蹤性，通常是從低抽象級到高抽象級的跟蹤。例如，您可以將某個設計決策與它處理的需求聯絡起來。這可以快速分析需求變化對您的設計造成的影響。

　　支援

　　在這一領域，我強烈建議您瞭解下列術語，它們在本系列前面的部分中有述。您還可以在本文的參考資料部分找到更多有關它們的資訊。

　　·Rational Unified Process for Service-Oriented Modeling and Architecture(RUP SOMA)流程
　　·IBM Rational Software Modeler(RSM)Rational Software Architect(RSA)工具
　　·UML 2 Profile for Software Services
　　·developerWorks RAS儲存庫中可供使用的SOA設計資產和模式
　　·業務服務建模，它能提供業務流程建模元素和UML元素之間的對映

　　服務實現

　　服務實現旨在對如何實現服務進行設計。這一設計已經達到最為詳細的程度（僅次於程式碼級）。它的目的並不是實現（構造）服務，而是在設計級描述如何實現服務，至於實現（構造）服務，將在第3部分予以介紹。服務實現是由軟體架構師和設計師來完成的。

　　在規範和實現之間有一道明顯的鴻溝。您可以用一個簡單的方法看出它們的區別：如果說服務規範解決的是是什麼的問題，服務實現介紹的就是怎樣做。

　　設計模型

　　由RUP SOMA定義的設計模型，是服務實現的核心輸出工作產品。它描述了SOA的實現，是對實現（包括程式碼）的抽象。服務實現的輸出將被輸入到服務的正式實現之中。

　　服務元件

　　您應當關注的主要設計模型元件是設計元件，它表示的是一個或多個服務規範是如何實現的，還描述瞭如何處理所有的功能性/非功能性需求，以及結構和行為規範。

　　在服務實現期間會建立大量的新類，對服務元件和服務進行細化。此外還會定義這些類的結構和行為。

　　正如先前所說的那樣，服務實現應當大量使用設計模式（如委託模式、獨立模式和工廠模式），這些模式一般是在服務實現期間被應用到各個類的。

　　WSDL和XML模式

　　在實現期間，您將針對各種技術作出決策。事實證明，Web服務對於SOA而言是一個可靠的平臺。MDD工具（如IBM Rational Software Architect）可以根據服務模型為服務提供者生成Web服務描述語言(WSDL)，以及相關的XML模式檔案(.xsd)，後者會定義在服務提供者和使用者之間流動的訊息。無疑，WSDL和XML模式既可以是服務實現的輸出，也可以是實際的服務實現過程的初始輸出之一。

QoS和服務分割槽

　　選擇採用什麼技術，對服務質量有巨大的影響。某些技術可能不支援您的某些需求。在可靠的訊息傳遞或效能（如吞吐量）方面就有這樣一個例子。對於傳統（非面向服務的）設計而言，您最好將各個供選擇的技術對映到分割槽。而對於SOA，在服務實現期間，可能需要對在服務規範期間定義的服務分割槽進行修改，以便讓特定的技術來處理相關的服務策略（訪問途徑、安全、效能等等）。例如，您可以想一想某些效能需求和互操作性需求，前者要求在記憶體中處理事務，而後者可能會使用SOAP和Web服務，或在某些情況下改用本地呼叫。

　　在您完成了服務設計之後，下一個步驟就是根據這一設計實現（構造）服務，這將在本系列的下一部分中介紹。

　　服務設計原則

　　這一部分將列出您在設計SOA解決方案時必須牢記的四項服務設計原則。不過請注意，這並不是一份官方的正式列表，而且也並不全面，其中一些概念來自於其他範例，如物件導向。這些原則在面向服務的解決方案設計中是十分重要的。

　　重用

　　在設計服務時，請把重用這一原則隨時記在心中。通常，在設計時，特定的服務使用者會有特定的要求。不過，如果您想從SOA中獲益，您會希望那些需求略有不同的其他使用者會重用自己設計的服務。而在您建立設計時，並不知道這些使用者，也不知道它們有什麼需求，因此這並不是一項輕鬆的任務。

　　下面是您可以考慮的事項：

　　·根據業務域（而不是技術）為服務及其操作提供一個有意義的描述性名稱。
　　·提供完整的、可由人工閱讀或計算機處理的規範，並將其公佈給服務註冊中心，使服務可以被發現（詳細資訊，請參閱本系列後續的部分）。
　　·各個使用場景的服務質量與初始場景不同，例如，如果服務被頻繁使用，需求和工作負載提高，可以制訂相應的計劃。
　　·是否有可能對服務提供的初始功能（是根據初始需求集提供的）進行擴充套件，以便完善服務。
　　·是否有可能在多種不同的平臺上實現某個服務規範。

　　鬆散耦合

　　耦合是指實體或系統彼此間的依存程度。在SOA的上下文中，您可以考慮服務規範與它的提供者或實現之間的耦合，或服務提供者與服務使用者間的耦合。如要支援 SOA 應有的靈活性，必須採用鬆散耦合。

　　服務提供者無需瞭解服務使用者的某個特定例項，反之亦然。如果要替換某個服務提供者或服務的實現，必須保證這樣做對使用者造成的影響可忽略不計，或不會對其造成干擾。

　　如果要幫助實現鬆散耦合，請考慮下列事項：

　　·將服務規範（本文中所述的服務和模型）與服務實現分離開來。正如第 2 部分有關MDD的那一節所描述的那樣，對於服務而言，擁有完整的規範是十分重要的，規範不會依賴於某個特定的實現。而且，服務契約應處於規範級別（而非實現級別）。
　　·使用工具，以一種人機可讀的標準格式（如WSDL和WS-Policy）描述服務規範，以使程式碼生成器能幫助您實現服務（ 本系列的第4部分將提供這一方面的詳細資訊）。
　　·當開發服務使用者的程式碼時，請記住，可能存在服務中間層或其他提供者，請不要對某個提供者的例項的任何資訊進行硬編碼。

　　無狀態性

　　事務狀態意味著服務必須具有關於某些發生的事件的資訊，這些事件是一個在服務提供者和服務使用者各自的特定例項間長期執行的事務的一部分。例如，如果服務操作已被呼叫，或在呼叫某個操作前需要先呼叫另一個操作，在這兩種情況下呼叫服務操作的結果是不同的。雖然在基於元件的開發中可以找到事務狀態的身影，但對於SOA來說，事務狀態卻是應該避免的。

　　資料（資訊）狀態意味著需要對資料例項的狀態進行管理。某些服務通常需要管理資料的狀態。以保險業中的索賠服務為例。該服務必須管理索賠例項的狀態，因為多個使用者會通過不同的業務事務訪問這些例項。注意，保持狀態不變的服務通常是原子（細粒度服務）。如要處理狀態需求，您應依靠一些在實現中運用的基礎技術，如Java?平臺、使用狀態會話Bean的Enterprise Edition(Java EE)等等。

　　粒度

　　對於面向服務的設計，您可以對粒度進行考慮，如服務提供者級或服務規範級的粒度（對於前者而言，要考慮應提供多少服務）。服務規範是一個針對服務操作的邏輯分組。在此處，邏輯表示它在業務方面的合理性。例如，在保險領域中，一個索賠處理介面將提供使用索賠處理的場景中所需的所有操作。這在IT實現方面也是合理的。例如，服務中所有被標識出的操作都可以通過同一種開發迭代實現。

　　在設計服務操作時，請考慮協作、使用場景，以及在服務提供者和使用者之間流動的訊息的數目和大小。粗粒度的操作可以提供更高的業務價值，而且使對實現的修改變得更容易了。粗粒度操作的引數（使用訊息作為輸入、輸出和故障引數）出錯率較低。不過，使用細粒度的引數（而不是訊息）通常具有更好的描述性。例如，如果某個操作服務簽名為determineEligibility(application: ApplicationMessage)，則您需要檢視ApplicationMessage的定義。如果簽名為determineEligibility(customer:Customer,product:Product,date:Date,amount:Amount)，則該簽名的描述性更好。此外，Customer或Product引數型別（舉例來說）可以在其他操作中重用，這與ApplicationMessage不同。

　　對於服務粒度，請務必記住，服務是可組合的。這涉及到重用和在現有功能基礎上提供新功能的能力。某一粒度級別的一組服務可以通過編排，形成另一個具有較粗粒度的服務。您可以想想這個例子：多個服務提供各種業務任務，然後將這些業務任務排成序列（一個業務流程），以提供另一個服務。

　　最終，如果要在設計決策中確定服務粒度，應當在效能（如在高效實現的前提下，用於交換的訊息的大小和數目）和重用的可能之間作出折衷。而且，一個典型的SOA會同時包括細粒度（原子服務）和粗粒度（組合服務）兩種服務。

　　結束語

　　本文介紹了與SOA解決方案的IT體系結構和設計相關的術語。您已經瞭解了在進行面向服務的分析期間，IT滿足業務需求的過程，您沿著抽象級別路徑逐級向下，對設計進行進一步細化。您從一組需求開始，逐步瞭解在設計符合需求的SOA時發生的各項活動（以及與之相關的術語）。您最終得到的是一個詳細而明確的設計，可以在實現的過程中加以運用，這是本系列的第4部分所要介紹的主題。 請繼續關注developerWorks，以獲取更多資訊（您可以使用參考資料部分中的RSS feed連結，以便在下一期文章釋出的第一時間搶先閱讀）。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-406922/，如需轉載，請註明出處，否則將追究法律責任。