目前比較流行的SOA程式設計模型有3種:Indigo,JBI和SCA.

一.Indigo

Indigo是Windows通訊基礎，它試圖為所有服務元件建立統一的OO模型來簡化服務程式設計。

Indigo將服務定義為暴露一組端點(endpoint)的程式，每個端點是3個主要元素的組合5：

• 　　端點的地址(address)——它是一個網路地址，通過它，端點可以被定址。
• 　　端點的繫結(Binding)——它指明瞭與端點進行通訊的額外細節，包括傳輸協議(如TCP、HTTP)和編碼策略(如文字、二進位制)，安全需求(如SSL、SOAP訊息安全)等。
• 　　端點的契約(Contract)——它指明由該端點暴露的操作，被這些操作使用的訊息，以及訊息交換模式(Message Exchange Patterns，MEP)，如單向、雙向和請求/答覆。

　　通過允許使用包含不同繫結和端點契約(QoS)的複合端點(multiple endpoints)來暴露相同的功能(服務)，這些定義有效地擴充套件了基於WSDL的服務定義。

　　Indigo程式設計模型的基礎之一是使用OO實現SOA程式設計的所有方面。

表1 Indigo中的SO實體和OO實體的關係。

　　表1顯示了SO實體與OO概念之間的對映(由Indigo程式設計模型定義)，以及將它們關聯起來的標註6。SO與OO的融合既是Indigo的主要優點，也是它的缺點：

• 　　OO是被大多數開發者所熟悉的行之有效的正規化。這意味著可以使用一種熟悉的技術開始開發新的面向服務架構解決方案。這種情況下，Indigo執行時會在幕後將OO風格的呼叫轉變成用來通訊的可互操作的SOAP訊息。
• 　　SO與OO有很大的不同。使用OO作為定義和實現服務的一種機制會創建出一個高度不匹配的實現(粒度、耦合等等)，這可能導致非最優甚至蒼白的面向服務架構實現。

　　Indigo支援2種主要的服務呼叫方式：

• 　　攜帶一組型別引數(最初的Web服務版本)的RPC風格呼叫(同步和非同步)。這種型別的服務呼叫非常類似傳統的方法呼叫，使用在分散式物件和RPC實現中。
• 　　訊息傳遞風格呼叫(同步和非同步)。這種型別的服務呼叫類似傳統的訊息系統(類似本書前面介紹的語義訊息傳遞)。

　　根據服務提供的訪問型別(RPC vs. 訊息傳遞)，它的契約被定義成介面(RPC)或訊息(訊息傳遞)契約形式(參見表1)。

Indigo的另一個基本特性是：引入聯結器(提供安全可靠的通訊的託管框架)用於訪問服務端點。通過將“管道部分”分離進入單獨的類(類層次)，並在大多數情況下提供“標準”實現，聯結器減少了用於構建互操作服務所必須的“管道程式碼(plumbing code)”，從而簡化了“被連線系統”網路的建立。

　　Indigo聯結器使用很少的概念(埠、訊息和通道)，使得服務呼叫獨立於傳輸協議或目標平臺。它們中最重要的是通道(channel)，它抽象了給(從)埠傳送(接收)訊息的處理過程。Indigo中定義了2類通道：

• 　　傳輸通道(Transport channels)用於支援特定的傳輸協議，如HTTP、TCP、UDP或MSMQ和拓撲結構，如點對點、使用中介(intermediaries)的端到端、對等、釋出/訂閱。
• 　　協議通道(Protocol channels)用於支援特定的QoS特性，如安全通道加密訊息和增加安全頭。Indigo使用 WS-*c規範來實現協議通道。堅持標準使得Indigo的實現可以與其他基於WS-*相容性實現的系統互操作。

　　Indigo同樣支援組合通道概念——將一個通道置於其他通道之上。如，可以使用將安全協議通道置於HTTP傳輸通道之上來提供安全的HTTP傳輸通訊。

　　Indigo聯結器提供了一個構建(Build)為中介提供支援，包括防火牆、代理和應用程式級閘道器。這些中介是成功實現SOA所必須的很多模式的實現基礎，包括訊息驗證、安全性加強、傳輸層交換、監視和管理、負載均衡和基於上下文的路由。

　　除了支援業務服務建立，Indigo還提供幾個系統服務，它們可以被任何業務服務實現使用。這些服務的例子如下：

• 　　聯邦認證。這個服務基於WS-Federation，支援企業內部和來自外部邊界的身份管理和驗證。它的實現在服務和相應的可信憑證之間代理認證。
• 　　事務支援。這個服務基於WS-AtomicTransaction規範，簡化了基於服務的事務程式設計

二.JBI

JBI 是Java Community Process管理的JSR中的一種，它通過建立專用(服務)容器形式的抽象層，解決服務程式設計的複雜度和可變性。

Java Community Process利用應用伺服器託管應用程式的成功，將它的JBI實現建立在服務容器概念之上。

　　就像Java業務整合(IEEE網際網路計算)中定義的那樣——“JBI是由容器和外掛(Plug-in)組成的可插入式架構。這個容器託管使用訊息路由進行通訊的外掛元件。架構上，元件通過一個抽象的服務模型(一個訊息傳遞模型，位於任何特殊協議或訊息編碼之上的抽象層中)進行互動。"

　　在基於JBI的實現中，服務之間並不直接互動。取而代之的是，採用類似EAI實現中廣泛應用的訊息代理架構，JBI容器扮演在服務之間路由訊息的通用中介，(見圖1)。

圖1 通過JBI協調訊息交換

　　分離交換的參與者(JBI架構的基礎)在服務提供者和消費者之間提供瞭解耦，以及一個用於協調(mediating)服務通訊量(或插入所有額外需要的功能)的明確位置。

　　此時，協調器(Mediation)可以支援廣泛的功能，從訊息傳送和安全加強，到基於內容的路由和服務標本標定。

JBI容器託管了2類不同的外掛元件：

• 　　服務引擎(Service Engine，SE)。SE本質上是用來託管JBI環境內部服務提供者和消費者的標準容器f。例如，在JBI環境中經常出現的SE包括資料轉換器、業務規則容器和BPEL引擎。
• 　　繫結元件(Binding Component，BC)。BC為JBI環境外部的服務消費者和提供者提供互聯性。BC允許整合不提供Java API的元件/應用程式，並使用遠端存取技術訪問它們。

　　元件間的互動利用了基於WSDL 2.0的標準化服務定義。WSDL 2.0定義在服務消費者和提供者之間提供了共享的協議，並作為JBI實現互操作能力的基礎。

　　除了標準化的服務定義，JBI使用“通用化(normalized)”訊息的概念支援全域性元件互操作能力。訊息通用化將協議與業務特定的上下文對映成一個通用的、可傳輸風格，這與EAI實現中經常使用的“規範(canonical)”訊息表示概念非常類似。

　　每個JBI容器存在於一個單獨的虛擬機器中，並容納所有的BC和SE，容器提供了一組服務，為SE和BC實現提供操作性支援。

　　JBI也定義了基於JMX的標準控制集合，允許外部管理工具執行不同的系統管理任務，也可以管理元件本身。管理支援為以下情形提供了標準機制：

• 　　安裝plug-in元件。
• 　　管理plug-in元件的生命週期(啟動/停止等。)。
• 　　部署伺服器件給元件。

三.SCA

 SCA由IBM、BEA、IONA、Oracle、SAP、Siebel、Sybase等公司共同制定，它基於的前提是：以結構良好的元件為基礎，兼具清晰的介面和明確的元件責任，這樣的體系結構有充分的理由被視為SOA。

儘管服務元件架構(SCA)被作為規範定義(該規範定義了使用面向服務架構構建系統的模型)，但它是一個有效的模型(該模型用來將元件組合成服務)，併為服務組合成解決方案提供了額外支援。

　　SCA基於2個主要的元模型：

• 　　型別元模型。
• 　　組合元模型。

　　型別元模型

　　這個元模型(見圖2)描述元件型別、介面和資料結構。

圖2 描述元件、介面和它們依賴的元模型

　　一個元件實現由以下的4組規範定義：

• 　　被提供的介面——元件定義的介面集。這些介面通常定義為WSDL埠型別或語言介面，如Java或C++。一個元件可以暴露0或多個介面。每個介面包含幾個方法。
• 　　被要求的規範(引用)——元件實現使用的介面集。這些介面通常定義為WSDL埠型別或語言介面，如Java或C++。一個元件可以有0或多個介面。
• 　　用來裁剪或自定義元件行為的屬性。每個屬性定義為一個屬性元素。一個元件可以包含0或多個屬性元素。
• 定義元件實現的實現元件。SCA允許很多不同的實現技術，如Java、BPEL、C++、SQL等。SCA為引入新的實現型別定義了擴充套件機制。

組合元模型

　　這個元模型(見圖3)定義了元件例項，以及它們是如何連線的。

圖3 元件例項和它們在組合元模型中的連線

　　這個元模型中例項的概念有別於在OO中使用的例項概念。此處的元件例項是指一個帶有被完整解析的屬性集，為解決特殊問題而修改元件行為的元件實現。

　　一個組合定義了很多元件例項，它們彼此互動，這裡的互動使用連線(wire)來定義。

　　在SCA中，連線使得絕大多數的底層程式碼被抽出(與Indigo中的通道類似)。如，連線可以被定義同步的或非同步的，支援元件呼叫的事務行為等。SCA在幕後處理這些底層細節。連線同樣可以在任意方向上連線2個不同的介面語言(如Java介面和WSDL 埠型別/介面)，只要這2個介面定義的操作是等價的就行了。

　　除了連線，SCA也支援通過特殊的元件型別，如匯入(imports)和匯出(exports)，進行模組間通訊。連線、匯入和匯出元件的結合使得元件可以引用外部服務。

　　組合元模型定義的元件組合，與服務組合既類似又不同，儘管兩者都定義了使元件/服務一起工作的方式。通過被組合本身引入的功能，服務組合增強了參與服務的功能;而這個元模型只定義元件(更接近於服務實現)間的連線。

　　SCA實現依賴於服務資料物件(Service Data Objects，SDO)，它提供了表示資料的通用模型的技術。SDO是元件的資料交換基礎。SDO架構中的基本概念是資料物件——包含基本型別資料和(或)其它資料物件的容器。元資料提供了被包含資料的資訊，它被資料物件顯式引用。在SDO中資料物件的組合由資料圖表示。除了物件本身，圖中還包含變更概要，用來記錄圖中資料物件和屬性在處理過程中變化的資訊(類似微軟環境中的ADO)。除了SDO，SCA還引入了服務訊息物件(Service message objects，SMO)，它提供了服務間處理和交換訊息的抽象層(類似JBI中的標準化訊息)。

　　SCA目前尚顯稚嫩(本文寫作時版本為0.9)，並且還不支援SOA實現要求的大多數?模式。作為替代，目前IBM的Websphere ESB/WPS 6.0的SCA實現引入了協調器框架，它基於SCA併為協調器實現和定位提供了定義良好的機制。(類似Indigo中的中介)。

　　如果GUI支援，SCA實現會非常強大，可以在面板上實現圖形化元件的連線，這種方式正是IBM的WebSphere Integration developer(WID)中所實現的。

在SCA的模型中使用者一般看到的都是Service。只有在這個粒度上，SCA服務才具體到實現層面，通過<implementation>元素跟具體的實現繫結起來。

可以看到，一個Component可以有Java（通過JDK1.5的Annotation進行實現繫結），BPEL、Composite等各種實現，這也是與SOA本身保持技術中立的立場是一致的。

從下圖可以看到，除了實現，還有若干關鍵概念：

首先是Properties。它用來設定一個Component的配置項，這確保了一個Component的外部可配置性，可複用性。

然後是該Component所實現的Service，即提供的服務。當然，一個Component也可以不提供任何服務。

最後是Reference，即Component所引用的東西。有點類似java裡的import或c#中的using概念。Component雖然是粒度最小的單元，但是並不意味著它是孤立的。它可以指定所依賴的其他部件。

Component作為最小粒度的構件，通過組合（即wire）可以上升一個層次，形成更大粒度的構件，即Composite。

Component可以選擇把它的Property上升成為Composite的Property，把它的Service和Reference上升為Composite的Service和Reference。即，把它們的可見性暴露出來。

那些不暴露出來的Service和Reference則可以通過wire將服務的引用和服務的實現串聯起來。所以服務可以是外部的，也可以是內部的。

Composite本身的名字容易使人聯想到Composite設計模式。的確，Composite是可以自聚合的。若干個小的Composite可以通過和Component類似的wire聚合成更大粒度的Composite。

此外，可以看到，Composite比Component多了interface和bingding的概念。

interface描述了服務是用什麼樣介面格式來描述的，如java interface或wsdl檔案。從這裡也可以看出，Composite是釋出服務的構件單元。

bingding則描述了服務的獲取方式。一個Service的實現可以走WebService、可以通過JMS訊息或者無狀態EJB來提供服務。

以上兩類描述讓Service的形式更靈活，可以適應大部分既有的系統介面。

通過Composite這樣的不斷組裝、聚合，一個subsystem就可以逐漸成型。

從下圖中可以看到一個SOA的subsystem內部與出傳統的module的構造有什麼不同。

基於SOA的系統是裝配(assemble)起來的，而不是搭建(build)起來的。這也是SOA跟傳統方法在構建系統上最大的不同。

此外，還可以看到，在構件之間傳遞有很多SDO物件夾雜在服務之間。他們的作用是負責服務資料的傳遞。

一個統一、中立的資料載體是異構服務之間有效通訊的必要條件。很難想象互不相容的資料結構之間如何進行服務的呼叫。