注銷

來自Min Luo, Mark Endrei, Philippe Comte,Pal Krogdahl, Jenny Ang, Tony Newling , International Technical Support Organization, Raleigh Center

2004 年 6 月 01 日

在這一節中，我們簡要地描述了面向服務的體系結構的發展。然后，我們探究了面向組件的開發與面向服務的體系結構之間的關系，并且說明了如何將組件作為實現服務的基礎設施。

第一部分：新方法的商業驅動力

雖然 IT 經理一直面臨著削減成本和最大限度地利用現有技術的難題，但是與此同時，他們還必須不斷地努力，以期更好地服務客戶，更快地響應企業戰略重點，從而贏得更大的競爭力。

在所有這些壓力之下，有兩個基本的主題：異構和改變。現在，大多數企業都有各種各樣的系統、應用程序以及不同時期和技術的體系結構。集成來自多個廠商跨不同平臺的產品簡直就像一場噩夢。但是我們也不能單單使用一家廠商的產品，因為改變應用程序套件和支持基礎設施是如此之難。

在當今 IT 經理面臨的問題之中，改變是第二個主題。全球化和電子商務加快了改變的步伐。全球化帶來了激烈的競爭，產品周期縮短了，每個公司都想贏得超過競爭對手的優勢。在競爭產品和可以從 Internet 上獲得的大量產品信息的推動下，客戶要求更快速地進行改變。因而，在改進產品和服務方面展開的競爭進一步加劇了。

為了滿足客戶提出的越來越多的新要求，技術方面的改進也在不斷地加快。企業必須快速地適應這種改變，否則就難以生存，更別提在這個動蕩不安競爭激烈的環境中取得成功了，而 IT 基礎設施必須支持企業提高適應能力。

因此，企業組織正在從上世紀八十年代或更早的時期的相互隔離的垂直業務部門，到上世紀八十年代和九十年代關注業務流程的水平結構，向新的生態系統業務范例發展。重點是擴展供應鏈，支持客戶和合作伙伴訪問業務服務。第 19 頁的圖 2-1 展示了企業的這種發展。

圖 2-1 企業的發展

我如何使我的 IT 環境更靈活且更快地響應不斷改變的業務需求呢？ 我們如何使這些異構系統和應用程序盡可能無縫地進行通信呢？我們如何達到企業目標而不使企業走向破產的深淵呢？

IT 響應者/支持者是隨著企業的這種發展而并行發展的，如圖 2-2 所示。現在，許多 IT 經理和專業人員都同樣相信，我們真的快找到了一種滿意的答案——面向服務的體系結構。

圖 2-2 體系結構的發展

圖 2-2 體系結構的發展

為了減少異構性、互操作性和不斷改變的要求的問題，這樣的體系結構應該提供平臺來構建具有下列特征的應用程序服務：

• 松散耦合
• 位置透明
• 協議獨立

基于這樣的面向服務的體系結構，服務使用者甚至不必關心與之通信的特定服務，因為底層基礎設施或服務“總線”將代表使用者做出適當的選擇。基礎設施對請求者隱藏了盡可能多的技術。特別地，來自不同實現技術（如 J2EE 或 .NET）的技術規范不應該影響 SOA 用戶。如果已經存在一個服務實現，我們就還應該重新考慮用一個“更好”的服務實現來代替，新的服務實現必須具有更好的服務質量。

?

第二部分：作為解決方案的面向服務體系結構

自從“軟件危機”促進軟件工程的開創以來，IT 界一直在努力尋求解決上述問題的方案。在過去幾年里，下面簡要概述的核心技術進展使我們走到了今天。我們將簡要討論這些核心技術，而我們重點關注的將是這些技術如何幫助解決 IT 問題。

面向對象的分析和設計

在“Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design”中，Larman 將面向對象的分析和設計的本質描述為“從對象（物體、概念或實體）的角度考慮問題域和邏輯解決方案”。在“Object-Oriented SoftwareEngineering: A Use Case Driven Approach”中，Jacobson 等將這些對象定義為“特點在于具有許多操作和狀態（記憶這些操作的影響）的物體”。

在面向對象的分析中，這樣的對象是用問題域來標識和描述的，而在面向對象的設計中，它們轉變成邏輯軟件對象，這些對象最終將用面向對象的編程語言進行實現。

通過面向對象的分析和設計，可以封裝對象（或對象組）的某些方面，以簡化復雜業務場景的分析。為了降低復雜性，也可以抽象對象的某些特征，這樣就可以只捕獲重要或本質的方面。

基于組件的設計并不是一種新技術。它是從對象范例中自然發展而來的。在面向對象的分析和設計的早期，細粒度的對象被標榜為提供“重用”的機制，但是這樣的對象的粒度級別太低了，沒有適當的標準可以用來使重用廣泛應用于實踐之中。在應用程序開發和系統集成中，粗粒度組件越來越成為重用的目標。這些粗粒度對象通過內聚一些更細粒度的對象來提供定義良好的功能。通過這種方式，還可以將打包的解決方案套件封裝成這樣的“組件”。

一旦組織在更高層次上實現了基于完全獨立的功能組件的完備體系結構，就可以將支持企業的應用程序劃分成一組粒度越來越大的組件。可以將組件看作是打包、管理和公開服務的機制。它們可以共同使用一組技術：實現企業級用況的大粒度企業組件可以通過更新的面向對象的軟件開發與遺留系統相結合來實現

面向服務的設計

在“Component-Based Development for Enterprise Systems”中，Allen 涉及了服務的概念，“它是將組件描述成提供相關服務的物理黑盒封裝的可執行代碼單元。它的服務只能通過一致的已發布接口（它包括交互標準）進行訪問。組件必須能夠連接到其他組件（通過通信接口）以構成一個更大的組”。服務通常實現為粗粒度的可發現軟件實體，它作為單個實例存在，并且通過松散耦合的基于消息通信模型來與應用程序和其他服務交互。第 22 頁的圖 2-3 展示了重要的面向服務術語：

• 服務：邏輯實體，由一個或多個已發布接口定義的契約。
• 服務提供者：實現服務規范軟件實體。
• 服務使用者（或請求者）：調用服務提供者的軟件實體。傳統上，它稱為“客戶端”。服務使用者可以是終端用戶應用程序或另一個服務。
• 服務定位器：一種特殊類型的服務提供者，它作為一個注冊中心，允許查找服務提供者接口和服務位置。
• 服務代理：一種特殊類型的服務提供者，它可以將服務請求傳送到一個或多個其他的服務提供者。

圖 2-3 面向服務的術語

基于接口的設計

在組件和服務開發中，都需要進行接口設計，這樣軟件實體就可以實現和公開其定義的關鍵部分。因此，在基于組件和面向服務的系統中，“接口”的概念對于成功的設計非常關鍵。下面是一些與接口有關的重要定義：

• 接口：定義一組公共方法簽名，它按照邏輯分組但是沒有提供實現。接口定義服務的請求者和提供者之間的契約。接口的任何實現都必須提供所有的方法。
• 已發布接口：一種可唯一識別和可訪問的接口，客戶端可以通過注冊中心來發現它。
• 公共接口：一種可訪問的接口，可供客戶端使用，但是它沒有發布，因而需要關于客戶端部分的靜態知識。
• 雙接口：通常是成對開發的接口，這樣，一個接口就依賴于另一個接口；例如，客戶端必須實現一個接口來調用請求者，因為該客戶端接口提供了某些回調機制。

第 23 頁的圖 2-4 定義了客戶關系管理 (CRM) 服務的 UML 定義，它表示為一個 UML 組件，實現接口 AccountManagement、ContactManagement 和 SystemsManagement。在這些接口中只有頭兩個接口是已發布接口，不過，后者是公共接口。注意，SystemsManagement 接口和 ManagementService 接口構成了雙接口。CRMservice 可以實現許多這樣的接口，但是它以多種方式行為的能力取決于客戶端在行為的實現方面是否允許有大的靈活性。甚至有可能給特定類型的客戶端提供不同或附加的服務。在一些運行時環境中，這樣的功能也用于在單個組件或服務上支持相同接口的不同版本。

圖 2-4 已實現的服務

分層應用程序體系結構

如前所述，面向對象的技術和語言是實現組件的極好方式。雖然組件是實現服務的最好方法，但是您必須理解的一點是，好的基于組件的應用程序未必就構成好的面向服務的應用程序。一旦理解了服務在應用程序體系結構中所起的作用，組件開發人員就很有可能會利用現有的組件。進行這種轉變的關鍵是認識到面向服務的方法意味著附加的應用程序體系結構層。第 24 頁中的圖 2-5 演示了如何將技術層應用于程序體系結構以提供粒度更粗的實現（它更靠近應用程序的使用者）。為稱呼系統的這一部分而創造的術語是“應用程序邊界”，它反映了服務是公開系統的外部視圖的極好方法的事實（通過內部重用并結合使用傳統組件設計）。

圖 2-5 應用程序實現層：服務、組件、對象

?

第三部分：近距離審視面向服務的體系結構

面向服務的體系結構提供了一種方法，通過這種方法，可以構建分布式系統來將應用程序功能作為服務提供給終端用戶應用程序或其他服務。其組成元素可以分成功能元素和服務質量元素。第 25 頁的圖 2-6 展示了體系結構堆棧以及在一個面向服務的體系結構可能觀察到的元素。

注意：面向服務的體系結構堆棧可能是一個容易引起爭議的問題，因為各方面的支持者已經提出了幾種不同的堆棧。我們的堆棧不是作為服務堆棧提出的。我們之所以在此提出它，是因為我們想要搭建一個有用的框架，在本書的剩余章節中，我們將通過這個框架來組織對 SOA 的討論。

圖 2-6 面向服務的體系結構的元素

體系結構堆棧分成兩半，左邊的一半集中于體系結構的功能性方面，而右邊的一半集中于體系結構的服務質量方面。這些元素詳細描述如下：

功能性方面包括：

• 傳輸是一種機制，用于將來自服務使用者的服務請求傳送給服務提供者，并且將來自服務提供者的響應傳送給服務使用者。
• 服務通信協議是一種經過協商的機制，通過這種機制，服務提供者和服務使用者可以就將要請求的內容和將要返回的內容進行溝通。
• 服務描述是一種經過協商的模式，用于描述服務是什么、應該如何調用服務以及成功地調用服務需要什么數據。
• 服務描述實際可供使用的服務。
• 業務流程是一個服務的集合，可以按照特定的順序并使用一組特定的規則進行調用，以滿足業務要求。注意，可以將業務流程本身看作是服務，這樣就產生了業務流程可以由不同粒度的服務組成的觀念。
• 服務注冊中心是一個服務和數據描述的存儲庫，服務提供者可以通過服務注冊中心發布它們的服務，而服務使用者可以通過服務注冊中心發現或查找可用的服務。服務注冊中心可以給需要集中式存儲庫的服務提供其他的功能。

服務質量方面包括：

• 策略是一組條件和規則，在這些條件和規則之下，服務提供者可以使服務可用于使用者。策略既有功能性方面，也有與服務質量有關的方面；因此，我們在功能和服務質量兩個區中都有策略功能。
• 安全性是規則集，可以應用于調用服務的服務使用者的身份驗證、授權和訪問控制。
• 傳輸是屬性集，可以應用于一組服務，以提供一致的結果。例如，如果要使用一組服務來完成一項業務功能，則所有的服務必須都完成，或者沒有一個完成。
• 管理是屬性集，可以應用于管理提供的服務或使用的服務。

SOA 協作

圖 2-7 展示了面向服務的體系結構中的協作。這些協作遵循“查找、綁定和調用”范例，其中，服務使用者執行動態服務定位，方法是查詢服務注冊中心來查找與其標準匹配的服務。如果服務存在，注冊中心就給使用者提供接口契約和服務的端點地址。下圖展示了面向服務的體系結構中協作支持“查找、綁定和調用”范例的實體。

圖 2-7 面向服務的體系結構中的協作

面向服務的體系結構中的角色包括：

• 服務使用者：服務使用者是一個應用程序、一個軟件模塊或需要一個服務的另一個服務。它發起對注冊中心中的服務的查詢，通過傳輸綁定服務，并且執行服務功能。服務使用者根據接口契約來執行服務。
• 服務提供者：服務提供者是一個可通過網絡尋址的實體，它接受和執行來自使用者的請求。它將自己的服務和接口契約發布到服務注冊中心，以便服務使用者可以發現和訪問該服務。
• 服務注冊中心：服務注冊中心是服務發現的支持者。它包含一個可用服務的存儲庫，并允許感興趣的服務使用者查找服務提供者接口。

面向服務的體系結構中的每個實體都扮演著服務提供者、使用者和注冊中心這三種角色中的某一種（或多種）。面向服務的體系結構中的操作包括：

• 發布：為了使服務可訪問，需要發布服務描述以使服務使用者可以發現和調用它。
• 發現：服務請求者定位服務，方法是查詢服務注冊中心來找到滿足其標準的服務。
• 綁定和調用：在檢索完服務描述之后，服務使用者繼續根據服務描述中的信息來調用服務。

面向服務的體系結構中的構件包括：

• 服務：可以通過已發布接口使用服務，并且允許服務使用者調用服務。
• 服務描述：服務描述指定服務使用者與服務提供者交互的方式。它指定來自服務的請求和響應的格式。服務描述可以指定一組前提條件、后置條件和/或服務質量 (QoS) 級別。

除了動態服務發現和服務接口契約的定義之外，面向服務的體系結構還具有以下特征：

• 服務是自包含和模塊化的。
• 服務支持互操作性。
• 服務是松散耦合的。
• 服務是位置透明的。
• 服務是由組件組成的組合模塊。

這些特征也是滿足電子商務按需操作環境的要求的主要特征，如第 301 頁“e-business on demand and Service-oriented architecture”所定義的。

最后，我們需要說明的是，面向服務的體系結構并不是一個新的概念。如圖 2-8 所示，面向服務的體系結構所涉及的技術至少包括 CORBA、DCOM 和 J2EE。面向服務的體系結構的早期采用者還曾成功地基于消息傳遞系統（如 IBM WebSphere MQ）創建過他們自己的面向服務企業體系結構。最近，SOA 的活動舞臺已經擴展到包括 World Wide Web (WWW) 和 Web 服務。

圖 2-8 面向服務的體系結構的不同實現

SOA 范圍中的服務

在面向服務的體系結構中，映射到業務功能的服務是在業務流程分析的過程中確定的。服務可以是細粒度的，也可以是粗粒度的，這取決于業務流程。每個服務都有定義良好的接口，通過該接口就可以發現、發布和調用服務。 企業可以選擇將自己的服務向外發布到業務合作伙伴，也可以選擇在組織內部發布服務。服務還可以由其他服務組合而成。

服務與組件

服務是粗粒度的處理單元，它使用和產生由值傳送的對象集。它與編程語言術語中的對象不同。相反，它可能更接近于業務事務（如 CICS 或 IMS 事務）的概念而不是遠程 CORBA 對象的概念。

服務是由一些組件組成的，這些組件一起工作，共同提供服務所請求的業務功能。因此，相比之下，組件比服務的粒度更細。另外，雖然服務映射到業務功能，但是組件通常映射到業務實體和操作它們的業務規則。作為一個示例，讓我們看一看 WS-I 供應鏈管理（WS-I Supply Chain Management）樣本的定購單（PurchaseOrder）組件模型，如圖 2-9 所示。

圖 2-9 定購單組件模型

在基于組件的設計中，可以創建組件來嚴格匹配業務實體（如顧客（Customer）、定購單（Purchase Order）、定購項（Order Item）），并且封裝匹配這些實體所期望的行為的行為。

例如，定購單（Purchase Order）組件提供獲取關于已定購的產品列表和定購的總額的信息的功能；定購項（Order Item）組件提供獲取關于已定購的產品的數量和價格的信息的功能。每個組件的實現都封裝在接口的后面。因此，定購單（Purchase Order）組件的用戶不知道定購單（Purchase Order）表的模式、計算稅金的算法、以及定單總額中的回扣和/或折扣。

在面向服務的設計中，不能基于業務實體設計服務。相反，每個服務都是管理一組業務實體中的操作的完整單元。例如，顧客服務將響應來自任何其他系統或需要訪問顧客信息的服務的請求。顧客服務可以處理更新顧客信息的請求；添加、更新、刪除投資組合；以及查詢顧客的定單歷史。顧客服務擁有所有與它管理的顧客有關的數據，并且能夠代表調用方進行其他服務查詢，以提供統一的顧客服務視圖。這意味著服務是一個管理器對象，它創建和管理它的一組組件。

?

第四部分：面向服務的體系結構所帶來的好處

如前所述，企業正在處理兩個問題：迅速地改變的能力和降低成本的要求。為了保持競爭力，企業必須快速地適應內部因素（如兼并和重組）或外部因素（如競爭能力和顧客要求）。需要經濟而靈活的 IT 基礎設施來支持企業。

我們可以認識到，采用面向服務的體系結構將給我們帶來幾方面的好處，有助于我們在今天這個動蕩的商業環境中取得成功：

利用現有的資產。

SOA 提供了一個抽象層，通過這個抽象層，企業可以繼續利用它在 IT 方面的投資，方法是將這些現有的資產包裝成提供企業功能的服務。組織可以繼續從現有的資源中獲取價值，而不必重新從頭開始構建。

更易于集成和管理復雜性。

在面向服務的體系結構中，集成點是規范而不是實現。這提供了實現透明性，并將基礎設施和實現發生的改變所帶來的影響降到最低限度。通過提供針對基于完全不同的系統構建的現有資源和資產的服務規范，集成變得更加易于管理，因為復雜性是隔離的。當更多的企業一起協作提供價值鏈時，這會變得更加重要。

更快的響應和上市速度。

從現有的服務中組合新的服務的能力為需要靈活地響應苛刻的商業要求的組織提供了獨特的優勢。通過利用現有的組件和服務，可以減少完成軟件開發生命周期（包括收集需求、進行設計、開發和測試）所需的時間。這使得可以快速地開發新的業務服務，并允許組織迅速地對改變做出響應和減少上市準備時間。

減少成本和增加重用。

通過以松散耦合的方式公開的業務服務，企業可以根據業務要求更輕松地使用和組合服務。這意味資源副本的減少、以及重用和降低成本的可能性的增加。

說到做到

通過 SOA，企業可以未雨綢繆，為未來做好充分的準備。SOA 業務流程是由一系列業務服務組成的，可以更輕松地創建、修改和管理它來滿足不同時期的需要。

SOA 提供了靈活性和響應能力，這對于企業的生存和發展來說是至關重要的。但是面向服務的體系結構決不是靈丹妙藥，而遷移到 SOA 也并非一件可以輕而易舉就完成的事情。請別指望一個晚上就將整個企業系統遷移到面向服務的體系結構，我們推薦的方法是，在業務要求出現或露出苗頭時遷移企業功能的適當部分。