2.1　SOA技術

2.1.1　SOA基本概念

作為一種軟件設計模式，SOA技術為服務的開發者提供了良好的架構。該架構體現了較為徹底的接口和實現解耦的設計思想，主要表現在接口和實現分離、調用時機分離兩個方面。接口和實現分離：可使得軟件研發、部署更加靈活。調用時機分離：具體功能的選定推遲到運行時，該功能是SOA技術實現動態組裝、快速重組的基礎，也是SOA技術被廣泛推崇的原因之一。另外，隨著物聯網技術的廣泛應用，未來勢必產生海量數據，傳統硬件架構服務器將難以滿足數據管理和處理要求。將云計算技術運用到物聯網是必然選擇，采用云計算的物聯網服務平臺可在很大程度上提高運行效率。

SOA將應用程序的不同功能單元稱為服務（Service），并通過在服務間定義良好的接口和約定（Contract）將它們聯系起來。接口采用中立的方式定義，獨立于具體實現服務的硬件平臺、操作系統和編程語言，使構建在這樣的系統中的服務能采用統一和標準的方式進行通信。SOA最重要的兩個概念如下。

（1）SOA是一種軟件系統架構。SOA既不是一種語言，也不是一種具體的實現技術，更不是一種產品。從為軟件和應用的開發者推薦一種所有人都應該遵從的開發方法的這個角度上來說，可以將其視為一種設計模式。

（2）服務是整個SOA實現的核心。SOA的基本元素是服務，SOA指定一組實體（服務提供者、服務消費者、服務注冊表、服務條款、服務代理和服務契約），這些實體詳細說明了如何提供和消費服務。遵循 SOA 觀點的系統必須有服務，這些服務是可互操作的、獨立的、模塊化的、位置明確的、松耦合的，并且可以通過網絡查找其地址。

2.1.2　SOA對服務的要求

SOA的設計思想獨立于任何具體實現技術（如Web服務）。它描述了SOA應用的所有功能，此類應用以服務的形式提供給用戶。本質上來說，服務是一類按照特定模式、規范實現的應用。也就是說，SOA服務包含所有服務功能和應用的相關服務流程，以及SOA應用的基礎功能與必要的系統功能。除提供將應用功能分解為服務外，SOA對服務的其他要求如下。

1.自我約束

當服務自身狀態的維護獨立于使用它的應用時，此服務是自我約束的。

2.平臺無關

如果服務可以被客戶端通過使用任意網絡、硬件和軟件平臺（如操作系統、編程語言等）來訪問，則服務是平臺無關的。平臺無關性同樣意味著SOA服務是去除細節的簡明實現。

3.動態發現、調用和組裝

SOA要求服務能夠被動態發現、調用和組裝。服務動態發現的前提是該服務能夠隨時隨地地在網絡中被找到。服務查詢的途徑主要包括服務目錄、類別或拓撲，以便客戶端查詢，從而決定哪個服務能夠提供其所需的功能。SOA能夠提供網絡平臺無關性的服務調用機制，客戶端既不需要清楚服務調用的網絡協議，也不需要清楚建立連接的中間件平臺組件，SOA允許客戶端調用服務或者能夠被服務端按需通知。服務調用和網絡平臺的無關性，允許客戶端可以從網絡的任何地方、任何時間按需調用網絡中的任何服務。如果服務可以被特定服務模型所使用和組合，這些服務模型可能跨多個服務提供者和組織，那么服務是可組裝的。

每個基于SOA應用的服務都可能實現了一個全新功能，它們也可能使用部分原有應用，這些應用是被服務移植和封裝起來的，或者是由新代碼和部分原有代碼組成的。服務客戶端的用戶不必知曉服務的實現，而是間接地通過接口訪問該服務。例如，Web服務只是發布其服務接口而非公開其服務的具體實現，或者服務提供者的內部工作。因此，SOA允許企業創建、部署和集成不同的服務，以及通過組合封裝在服務中的新老應用來設計新的服務模型功能和流程。此外，由于它的動態特性，SOA能夠潛在地提供服務實時集成，該方法能夠提供從未向客戶端提供過的新服務。從這點上來說，SOA提供了一種實現和接口解耦合的設計模式，它主要體現在兩個方面：接口和實現分離、調用時機分離。

接口和實現分離指服務一旦定義好接口后，服務的具體實現可以進行完全獨立的開發、部署、更新，而不影響服務使用者的使用。調用時機分離指SOA的設計思想將服務的調用推遲到運行時決策，而不是在開發時決定，這一改變對于軟件開發者來說，影響是巨大的。

2.1.3　SOA模型

SOA模型涉及服務請求者、服務提供者、服務注冊中心三類實體。這三類實體通過服務請求實現交互。服務提供者將封裝與實現的各種服務向服務注冊中心進行注冊，服務請求者則根據需要在服務注冊中心查找服務，并根據服務注冊中心的返回結果調用或使用服務。SOA模型如圖2-1所示。服務發現、服務注冊和服務請求過程通?；赟OAP（Simple Object Access Protocol，簡單對象訪問協議）實現。

SOAP是一個輕量化協議，允許類RPC（Remote Procedure Call，遠程過程調用）的調用，而且這種調用是通過使用HTTP、HTTPS和SMTP（Simple Mail Transfer Protocol，簡單郵件傳輸協議）等傳輸協議實現的。原則上，SOAP消息可以使用任何協議來表達，只要同時綁定一個解析方法即可。SOAP請求是由運行的服務（SOAP監聽服務）來接收的，該服務專門接收SOAP消息、提取XML消息體、將XML消息轉換為所請求服務的協議，并在企業內部將請求轉交給實際功能或者服務進程。在處理請求之后，提供者需要給客戶端發送響應，該響應同樣是攜帶XML消息的SOAP消息。

服務請求者和服務提供者之間的交互過程是復雜的，因為它們需要從不同的潛在服務提供者那里發現/發布、協商、預定和使用服務。降低這種復雜性的方法是將服務提供者和服務請求者功能性地結合到一個服務聚合器（Service Aggregator，也稱聚合服務）。服務聚合器具有兩種角色，如圖2-2所示。首先，它可以像應用服務提供者一樣運行，通過創建更高級別的組合服務來提供完整的服務解決方案。服務聚合器能夠通過特定的組合語言（如BPEL或者BPML）實現此種組合。另外，它也可以是服務請求者。

所請求的Web服務操作是通過一個或者多個Web服務組件實現的。Web服務組件可能被托管在Web服務容器中，該服務容器作為Web服務和底層基礎設施服務間的接口。Web服務容器與J2EE容器很相似，能夠提供位置、路由、服務調用和管理等功能。一個服務容器能夠同時容納多個服務實例，即便它們不屬于同一個分布式進程。線程池允許將很多服務實例附加到單個容器中的多個監聽進程中。

2.1.4　面向服務

在SOA中有兩個基本的抽象元素：服務和消息。服務是網絡中一些物理資源或者邏輯資源的邏輯表現，并且/或者能夠在網絡中提供一些應用功能的執行邏輯。服務交互是通過消息交換來實現的。為了更好地描述面向服務的概念，從以下三個視圖對其進行描述。

1.結構視圖

結構視圖是一個面向服務系統的高層模型，SOA系統結構視圖如圖2-3所示，其中，系統的各個管理域是通過服務來溝通信息的，而服務就是發送和接收消息的簡單實體。服務可以看成支持“處理消息（Process Message）”的簡單邏輯操作，該邏輯操作允許服務使用網絡來進行消息交換及處理消息。該操作只存在于概念中，而且所有的服務都采用統一的語義；調用Process Message操作代表一個從發送者傳送到接收者的消息和對這個消息進行處理的請求。

在SOA系統中，需要轉換思維來研究Process Message，它提供了理解消息交換協議的方法，以及構建更多復雜精細消息交換模式的基礎構建模塊。當實現一個面向服務系統時，Process Message操作可以被底層傳輸技術的適當機制替換，但消息傳輸的語義是一樣的。

2.協議視圖

協議視圖規定了面向服務系統中消息的格式和服務消息交換的形式，它提供了系統結構中更詳細的內容。服務協議視圖如圖2-4所示。

服務之間消息交換協議的設計應遵循以下原則。

（1）邊界清晰。

（2）服務自治。

（3）服務之間只共享概要和條款。

（4）策略決定服務兼容性。

以上原則是為了表達面向服務應用的優點，包含但不局限于健壯性、易維護性、可擴展性和可靠性。忽略這些原則中的一條或者多條將會導致影響重要特性服務的開發。

3.實現視圖

實現視圖給出了面向服務系統中獨立服務功能的實現方法，以及服務如何被設計用來支持協議消息的交互。一個典型服務的組織結構如圖2-5所示。它由資源層、服務邏輯層和消息處理層組成。

（1）資源層：表示可能被服務中邏輯實體使用的資源。典型的資源包括網絡的通信帶寬、路由表等，以及通信節點的內存、操作系統資源、數據、設備、其他計算機系統及服務甚至人。

（2）服務邏輯層：包含服務的各種功能。一個服務邏輯的典型行為是接收從消息處理層發來的消息到達通知，消息處理層用于執行服務相關的工作，并且可能導致進一步的消息交互。功能粒度可以是任何級別，包括從一個單獨的操作系統進程到跨組織的多服務進程。

（3）消息處理層：為服務邏輯提供了程序級的抽象，以實現與其他服務的消息交換。服務中一個消息的到達通常會產生由消息處理層確認是否符合服務約定的消息，接著該消息通過協議棧交付給服務邏輯層。消息處理層將其采用的協議公布給服務邏輯層，這樣服務邏輯層就可以兼容服務所支持的消息協議中的行為、不完整性和復雜性。在本地范圍或者高耦合度的系統中，協議有可能被隱藏在方法調用這樣的高層抽象中，通常要求消息傳輸具有低延遲和低故障率的特點。然而，在某些情況下，如果服務實現被設計成容忍延遲、消息丟失等情況，那么就應增強系統的健壯性。

2.1.5　企業服務總線（ESB）

盡管Web服務技術是當前在SOA中使用最為廣泛的技術，但也存在很多其他常規的編程語言和集成平臺。任何一種遵循WSDL（Web Services Description Language，Web服務描述語言）并使用XML消息進行交互的技術都可以加入SOA系統。這樣的技術包括J2EE（Java2平臺企業版）和消息隊列（如IBM的WebSphere MQ）。

既然客戶端和服務可能由不同的開發者使用不同技術和不同設計理念來實現，那么它們之間就可能存在技術上的不匹配（例如，它們使用不同的通信協議），以及異構性（例如，消息語法和語義）。處理這樣的技術不匹配和異構性問題需要以下兩種方法。

（1）使用與不同客戶端可能調用的服務的相同技術和設計理念來實現客戶端。

（2）在服務及其客戶端之間加入一個提供可重用交互和集成邏輯的層。

第一種方法要求開發每個點到點連接的服務接口。這種點到點的網絡連接是非常難以管理和維護的，因為它們在服務器和客戶端之間引入緊耦合關系。這種耦合需要在傳輸協議、文檔格式、交互風格等方面下很大功夫。此方法會導致服務端和客戶端不可修改，因為對服務端的任何修改都有可能影響所有客戶端。此外，點到點通信非常復雜且缺乏可擴展性。隨著服務端和客戶端數量的不斷增加，它們可能很快就不可控制了。為了處理這些問題，企業使用集成（Enterprise Application Integration，EAI）中間件提供了一個對話中樞集成模式。這就使得第二種方法更為可行。

第二種方法是引入一個集成中間層，ESB（Enterprise Service Bus，企業服務總線）可解決服務和客戶端之間的互操作性，ESB提供了SOA和Web服務集成的基礎設施。ESB展示出兩個突出特點：一是它促進了服務端和客戶端的松耦合關系，二是ESB將集成邏輯分隔為獨立的、易于管理的分片。

ESB是一個開放的、基于標準的消息總線，用來實現、部署和管理基于SOA的解決方案。為了發揮其作用，ESB提供分布式處理、基于標準的集成和企業擴展所需的企業級基礎服務。ESB尤其用來設計在大粒度應用與其他組件之間通過標準適配器和接口提供互操作功能。為了達到此目標，ESB功能作為傳輸層和轉換器，此轉換器允許服務發布在完全不同的系統和計算環境中。

從概念上講，ESB是從中間件產品（如面向消息的中間件）的存儲轉發機制中演進而來的，它是傳統中間件技術與XML、Web服務等技術相互結合的產物，用于實現企業應用不同消息和信息的準確、高效、安全傳送。物理上，ESB提供了SOA的基礎功能實現，它建立了適當的消息控制機制，并滿足SOA對安全、策略、可靠性和統計的需求。ESB負責消息流的控制并執行服務間消息的轉換工作。ESB使應用和獨立的待集成組件組裝成一個服務流程的工作變得簡單方便，這反過來又促進了企業中的服務過程自動化。

ESB連接各種應用和技術的簡化結構如圖2-6所示。該結構集成了J2EE應用（使用JMS）、.NET應用（使用C#客戶端）和MQ應用（它連接已有應用、其他外部應用和數據源）。正如在圖2-6上半部分和中間部分所描繪的那樣，ESB提供了將許多不同應用組件放在面向服務的接口之下且使用Web服務技術集成這些應用組件的有效方法。在圖2-6中，一個分布式查詢引擎提供了抽象底層數據資源復雜度的數據服務。圖2-6上半部分的入口集合了很多ESB匯聚點，它們代表了服務資源且是面向用戶的。

圖2-6中所描述的ESB節點提供了物理網絡目的節點和連接信息（如TCP/IP主機名和端口號）的抽象，超越了傳統緊耦合分布式組件的管道級集成能力。這些節點允許服務使用邏輯連接名稱，由ESB在運行時來完成到真實物理網絡目的節點的映射工作。目的節點的獨立性使連接到ESB服務的升級、遷移、替換工作能夠在無須修改代碼或者打斷現有ESB應用運行的情況下完成。例如，一個現有的列表服務能夠很容易地通過新服務的替換而得到升級，并且無須中斷其他應用的運行。

另外，ESB通過創建完全相同的程序來處理一個網絡失效的情況。節點依賴服務容器之間異步和高可靠的通信。它們能夠通過配置使用不同級別的服務，例如，當網絡部分失效時能夠保證通信的服務。

為了能夠成功構建和部署分布式的面向服務結構，需要解決如下四個主要問題。

（1）服務支持：每個獨立的應用都作為服務提供給用戶。

（2）服務組合：分布的服務是在明確的具體進程中配置和組合的。

（3）服務部署：隨著基于SOA應用的部署，完整的服務和進程需要從測試轉移到產品環境中。

（4）服務管理：對服務必須進行監視，而且它們的調用和選擇需要調整以更好地實現特定應用的目標。

服務是通過使用很多應用開發工具（如微軟的.Net、Borland的Jbuilder或BEA的Web Logic WorkShop）來組合的，這些工具能夠使新的或者已有的分布應用以Web服務的方式提供給用戶。像JCA（J2EE Connector Architecture）這樣的技術也可能以集成打包形式提供給用戶的應用（如ERP系統）來創建服務。

為了達到可操作的目標，像連接和路由信息這樣的ESB集成服務是基于服務規則、數據轉換和應用適配器的。這些功能本身是基于SOA的，它們高度分散于整個總線，并且通常是由單獨部署的服務容器提供的，這是與高度集中且整體化的傳統集成代理模式的根本區別。ESB容器模型的分布式特點允許單個Web服務按需加入ESB骨干服務中。盡管ESB容器之間是相互獨立的，但該特點使得它們能夠高度分散且以高度分布的方式一起工作。圖2.6中所示的應用運行的不同平臺之間是相互獨立的，但可以通過總線相互連接，因為邏輯節點是以Web服務的方式提供的。

2.1.6　事件驅動的結構

在企業環境中，服務事件（例如，一名客戶的訂單、貨物到達裝卸碼頭或者支付賬單）可能在任何時間點發生影響服務常規模型的過程。這說明了服務處理不能被設計為一個先驗地認為事件會按照事先確定的常規模式處理，而是需要規定由異步事件驅動的動態處理流程。為了支持這樣的應用，SOA需要加強EDA（Event Driven Architecture，事件驅動架構）設計，它在實現SOA的同時考慮到了服務事件的高度動態特性。一個ESB要求應用和事件驅動的Web服務在松耦合SOA環境中綁定在一起，在支持同一個服務處理流程和方法的同時，EDA允許應用和Web服務相互獨立運行。

在ESB有效的EDA中，應用和服務被抽象在能夠快速響應異常事件的服務節點。EDA提供一套抽象底層連接和協議細節的方法。

SOA改進版中的服務不要求理解協議的實現或者有任何其他服務的路由消息。一個事件產生器通過ESB發送消息，然后ESB發布消息給訂閱此事件的服務。事件本身封裝一個服務活動中，并形成一個完整的特定事件描述。為了實現該功能，ESB支持已有Web服務技術，包括SOAP（Simple Object Accrss Protocol，簡單對象訪問協議）、WSDL（Web Services Description Language，Web服務描述語言）和BPEL（Business Process Execution Language，業務流程執行語言），以及正在出現的標準，如WS-Reliable Messaging和WS-Notification。

如前所述，在SOA代理中，服務的提供者和請求者之間僅有的依賴關系就是由WSDL描述并通過服務代理廣播出去的服務契約。服務請求者和服務提供者之間是運行時的依賴關系，而非編譯時的依賴關系，客戶端在運行時能夠獲取和使用所需服務的所有信息。服務接口是動態發現的，而且消息也是動態生成的。服務客戶直到需要服務時才需要知道請求消息的格式或者服務的位置。

為了能夠實現服務與其客戶端之間的解耦，EDA要求事件生產者和事件消費者能夠充分解耦。也就是說，事件生產者不需要特定的事件消費者信息。因此，不需要服務契約向客戶端解釋服務的行為。事件消費者和事件生產者之間僅有的關系就是通過ESB將自己注冊為事件生產者或者事件訂閱者。盡管EDA的重點放在了事件生產者和事件消費者之間的解耦，事件消費者可能需要它接收和處理事件的元數據。為了解決該需求，事件生產者經常根據一些對事件消費者有效的面向應用事件類型（有時是手動建立的約定）來組織事件。這種分類方法典型地規定事件的類型及其用來描述以下元數據，這些元數據是已發布的并且事件消費者能夠訂閱，包括事件相關屬性的格式和可能在事件生產者服務和事件消費者服務之間進行交互的相關消息。