一、曆史回顧
自2005年11月開始，18家廠商緻力于聯合制定簡化SOA應用開發新的行業規範(聯盟廠商包括BEA，Cape Clear，IBM，Interface21，IONA，Oracle，Primeton Technologies(普元軟體)，Progress Software，Red Hat，Rogue Wave Software，SAP AG，Siemens AG，Software AG，Sun Microsystems，Sybase，TIBCO Software，和Xcalia),宣布了SCA(Service Component Architecture，服務元件架構)和SDO(Service Data Objects，服務資料對象)規範中關鍵部分的完成，并将正式送出給OASIS(The Organization for the Advancement of Structured Information Standards，結構化資訊标準促進組織)，通過其開放式标準過程進行推動。
此外，聯盟廠商的廠商中立網站(www.OSOA.org)将繼續用作擷取草拟規範、白皮書的資訊來源，并提供一個進行行業資訊輸入和回報的論壇。
SCA規範旨在簡化服務的建立和合成，對于運用基于SOA方式服務的應用建構十分關鍵。随着SCA規範的完成，聯盟合作廠商希望将其标準化過程送出給OASIS。此外，聯盟廠商也已完成了SDO規範，旨在實作對多個站點中多種格式資料的統一通路，并将把SDO基于Java的規範開發和管理送出給Java社團過程(JCP)組織，而基于非Java的規範(C++ )送出給OASIS。
SCA和SDO規範能幫助企業更便捷地建立新的以及改造現有的IT資産，使之可複用、易整合，以滿足不斷變化的業務需求。這些規範提供了統一服務的途徑，大大降低了在應用開發過程中，因程式設計語言與部署平台的不同而産生的複雜性。SCA和SDO規範都是用于簡化業務邏輯和業務資料呈現的新興技術。
二、SOA 程式設計模型
[支援原創：http://www.infoq.com/cn/articles/SOA-programming-models]
随着面向服務架構（Service-Oriented Architecture）使用率的增長，由Web服務API（目前最流行的SOA實作技術），如Java中的JAX-RPC或.NET中的Web服務擴充（Web Services Extension，WSE）API，所提供的抽象級别對于有效實作SOA越來越顯得力不從心：
- 這些API的語義更偏向服務調用的技術方面和SOAP處理過程，其次才是服務的使用和支援。
- 它們中的大多數隻提供SOAP over HTTP的支援a，對于SOA實作來說，這并不總是最優的傳輸方式。
- 它們中的大多數隻提供同步和單向的服務調用b，而這隻是服務互動風格的子集。
- 這些API直接暴露給實作代碼，導緻了以下後果：
- 業務實作代碼經常與服務通信支援代碼攪和在一起，它使得實作、了解、維護和調試變得更加困難。
- 任何API改變（至少每一年發生一次）都要求在業務實作中更改。
- 這些API對于很多重要的服務運作時模式沒有提供直接支援。如，要實作動态路由請求必須自己程式設計，同時使用額外的API（Java中是JAX-R）來通路注冊中心。
目前嘗試通過定義SOA程式設計模型（其中，從其他技術中借用了很多元素）來提高API 的抽象級别，這樣可解決目前API 集合中的一些問題。程式設計模型的目标是，降低應用程式開發者直接進行中間件或Web服務特定API時面臨的複雜度。通過從業務代碼中移除大部分的通信支援，并将它們隐藏在程式設計模型抽象/實作之後，這樣可以獲得以下好處1：
1）簡化業務服務的開發。
2）簡化作為服務網絡建構的業務解決方案的裝配和部署。
3）增加靈活和靈活性。
4）保護業務邏輯資産，使其不受底層技術改變的影響。
5）改善測試能力。
Web服務調用架構（Web Services Invocation Framework，WSIF）2 3是建立這種模型的最早嘗試之一，最初由IBM發起，目前是Apache基金的一部分。
WSIF試圖将服務使用模型與基于WSDL的服務定義結合起來——WSIF API直接支援WSDL語義。這使得WSIF能為使用不同傳輸協定的不同服務實作提供統一的調用模型。盡管WSIF本身從來沒有獲得廣泛地采用，但它作為服務調用的API，被很多BPEL引擎使用，如IBM的WPC和Oracle的BPEL管理器。
對于SOA實作來說，以下3個模型是目前最流行的：
- 來自微軟的Windows通信基礎（Indigo）程式設計模型，它試圖為所有服務元件建立統一的OO模型來簡化服務程式設計。
- 來自Java Community Process的Java Business Integration（JBI）模型，它通過建立專用（服務）容器形式的抽象層，解決服務程式設計的複雜度和可變性。
- 來自IBM、BEA、IONA、Oracle、SAP、Siebel、Sybase等的服務元件架構（Service Components Architecture，SCA），它基于的前提是：以結構良好的元件為基礎，兼具清晰的接口和明确的元件責任，這樣的體系結構有充分的理由被視為SOA。4。
通過支援無縫的服務編排（orchestration）和許多對于成功實作SOA必需的模式，這些程式設計模型試圖超越簡單的服務調用，并期望提供更多的功能。它們同樣也是實作企業服務總線（Enterprise Service Bus，ESB）的基礎。在本文中，我們将對每個程式設計模型進行簡單的概覽。
Indigo程式設計模型
Indigo是微軟最新的面向服務架構的程式設計模型實作，支援豐富的技術集合，用于“建立，消費，處理和傳送消息”。Indigo計劃與下一版的Windows Vista一起釋出。
Indigo将服務定義為暴露一組端點（endpoint）的程式，每個端點是3個主要元素的組合5：
- 端點的位址（address）——它是一個網絡位址，通過它，端點可以被尋址。
- 端點的綁定（Binding）——它指明了與端點進行通信的額外細節，包括傳輸協定（如TCP、HTTP）和編碼政策（如文本、二進制），安全需求（如SSL、SOAP消息安全）等。
- 端點的契約（Contract）——它指明由該端點暴露的操作，被這些操作使用的消息，以及消息交換模式（Message Exchange Patterns，MEP），如單向、雙向和請求/答複。
通過允許使用包含不同綁定和端點契約（QoS）的複合端點（multiple endpoints）來暴露相同的功能（服務），這些定義有效地擴充了基于WSDL的服務定義。
Indigo程式設計模型的基礎之一是使用OO實作SOA程式設計的所有方面。
| SO實體 | OO實體 | 标注 |
| 服務契約 | 接口 | 使用[ServiceContract]]标注接口 |
| 服務操作 | 方法 | 使用[OperationContract]标注接口方法 |
| 實作類 | 類 | 使用[ServiceBehavior]标注類，它由服務契約接口派生。 |
| 實作方法 | 方法 | 使用[OperationBehavior] |
| 資料契約 | 類 | 使用[DataContract]标注類，[DataMember]标注成員 |
表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）”，進而簡化了“被連接配接系統”網絡的建立7。
Indigo連接配接器使用很少的概念（端口、消息和信道），使得服務調用獨立于傳輸協定或目标平台。它們中最重要的是信道（channel），它抽象了給（從）端口發送（接收）消息的處理過程。Indigo5中定義了2類信道：
- 傳輸信道（Transport channels）用于支援特定的傳輸協定，如HTTP、TCP、UDP或MSMQ和拓撲結構，如點對點、使用中介（intermediaries）的端到端、對等、釋出/訂閱。
- 協定信道（Protocol channels）用于支援特定的QoS特性，如安全信道加密消息和增加安全頭。Indigo使用 WS-*c規範來實作協定信道。堅持标準使得Indigo的實作可以與其他基于WS-*相容性實作的系統互操作d。
Indigo同樣支援組合信道概念——将一個信道置于其他信道之上。如，可以使用将安全協定信道置于HTTP傳輸信道之上來提供安全的HTTP傳輸通信。
Indigo連接配接器提供了一個建構（Build）為中介提供支援，包括防火牆、代理和應用程式級網關。這些中介是成功實作SOA所必須的很多模式的實作基礎，包括消息驗證、安全性加強、傳輸層交換、監視和管理、負載均衡和基于上下文的路由。
除了支援業務服務建立，Indigo還提供幾個系統服務，它們可以被任何業務服務實作使用。這些服務的例子如下：
- 聯邦認證。這個服務基于WS-Federation，支援企業内部和來自外部邊界的身份管理和驗證。它的實作在服務和相應的可信憑證之間代理認證。
- 事務支援。這個服務基于WS-AtomicTransaction規範，簡化了基于服務的事務程式設計（它支援SQL Server、ADO.NET、MSMQ、分布式事務協調器（DTC）等）。
JBI程式設計模型
Java Community Process利用應用伺服器托管應用程式的成功，将它的JBI實作建立在服務容器概念之上。
就像Java業務內建（IEEE網際網路計算）8中定義的那樣——“JBI是由容器和插件（Plug-in）組成的可插入式架構。這個容器托管使用消息路由進行通信的插件元件。架構上，元件通過一個抽象的服務模型（一個消息傳遞模型，位于任何特殊協定或消息編碼之上的抽象層中）進行互動。"
在基于JBI的實作中，服務之間并不直接互動。取而代之的是，采用類似EAI實作中廣泛應用的消息代理架構，JBI容器扮演在服務之間路由消息的通用中介，（見圖1）。
圖1 通過JBI協調消息交換
分離交換的參與者（JBI架構的基礎9）在服務提供者和消費者之間提供了解耦，以及一個用于協調（mediating）服務通信量（或插入所有額外需要的功能）的明确位置e。
此時，協調器（Mediation）可以支援廣泛的功能，從消息傳送和安全加強，到基于内容的路由和服務标本标定。
JBI容器托管了2類不同的插件元件9：
- 服務引擎（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）”消息表示概念非常類似g。
每個JBI容器存在于一個單獨的虛拟機中，并容納所有的BC和SE，容器提供了一組服務，為SE和BC實作提供操作性支援。
JBI也定義了基于JMX的标準控制集合，允許外部管理工具執行不同的系統管理任務，也可以管理元件本身。管理支援為以下情形提供了标準機制9：
- 安裝plug-in元件。
- 管理plug-in元件的生命周期（啟動/停止等。）。
- 部署伺服器件給元件。
服務元件架構（Service component Architecture，SCA）
盡管服務元件架構（SCA）10被作為規範定義（該規範定義了使用面向服務架構建構系統的模型），但它是一個有效的模型（該模型用來将元件組合成服務），并為服務組合成解決方案提供了額外支援。
SCA基于2個主要的元模型11：
- 類型元模型。
- 組合元模型。
類型元模型
這個元模型（見圖2）描述元件類型、接口和資料結構11。
圖2 描述元件、接口和它們依賴的元模型
一個元件實作由以下的4組規範定義10：
- 被提供的接口——元件定義的接口集。這些接口通常定義為WSDL端口類型或語言接口，如Java或C++。一個元件可以暴露0或多個接口。每個接口包含幾個方法。
- 被要求的規範（引用）——元件實作使用的接口集。這些接口通常定義為WSDL端口類型或語言接口，如Java或C++。一個元件可以有0或多個接口。
- 用來裁剪或自定義元件行為的屬性。每個屬性定義為一個屬性元素。一個元件可以包含0或多個屬性元素。
- 定義元件實作的實作元件。SCA允許很多不同的實作技術，如Java、BPEL、C++、SQL等。SCA為引入新的實作類型定義了擴充機制。
組合元模型
這個元模型（見圖3）定義了元件執行個體，以及它們是如何連接配接的11。
圖3 元件執行個體和它們在組合元模型中的連接配接
這個元模型中執行個體的概念有别于在OO中使用的執行個體概念。此處的元件執行個體是指一個帶有被完整解析的屬性集，為解決特殊問題而修改元件行為的元件實作。
一個組合定義了很多元件執行個體，它們彼此互動，這裡的互動使用連線（wire）來定義。
在SCA中，連線使得絕大多數的底層代碼被抽出（與Indigo中的信道類似）。如，連線可以被定義同步的或異步的，支援元件調用的事務行為等。SCA在幕後處理這些底層細節。連線同樣可以在任意方向上連接配接2個不同的接口語言（如Java接口和WSDL 端口類型/接口），隻要這2個接口定義的操作是等價的就行了。
除了連線，SCA也支援通過特殊的元件類型，如導入（imports）和導出（exports），進行子產品間通信。連線、導入和導出元件的結合使得元件可以引用外部服務。
組合元模型定義的元件組合，與服務組合既類似又不同，盡管兩者都定義了使元件/服務一起工作的方式。通過被組合本身引入的功能，服務組合增強了參與服務的功能；而這個元模型隻定義元件（更接近于服務實作）間的連接配接。
SCA實作依賴于服務資料對象（Service Data Objects，SDO）10，它提供了表示資料的通用模型的技術。SDO是元件的資料交換基礎。SDO架構中的基本概念是資料對象——包含基本類型資料和（或）其它資料對象的容器。中繼資料提供了被包含資料的資訊，它被資料對象顯式引用。在SDO中資料對象的組合由資料圖表示。除了對象本身，圖中還包含變更概要，用來記錄圖中資料對象和屬性在處理過程中變化的資訊（類似微軟環境中的ADO）。除了SDO，SCA還引入了服務消息對象（Service message objects，SMO），它提供了服務間處理和交換消息的抽象層（類似JBI中的标準化消息）。
SCA目前尚顯稚嫩（本文寫作時版本為0.9），并且還不支援SOA實作要求的大多數模式。作為替代，目前IBM的Websphere ESB/WPS 6.0的SCA實作引入了協調器架構12 ，它基于SCA并為協調器實作和定位提供了定義良好的機制。（類似Indigo中的中介）。
如果GUI支援，SCA實作會非常強大，可以在面闆上實作圖形化元件的連接配接，這種方式正是IBM的WebSphere Integration developer（WID）13 14 中所實作的。