與語言無關、基于組件的面向服務的體系結構 (SOA) 編程模型簡化了實現 Web 服務以及將其組裝到解決方案中的過程。使用編程模型，非編程人員可以在沒有掌握復雜的技術的情況下使用現有的 IT 資產。它滿足了解決方案設計人員和業務分析人員的需要，提供了更高級別的抽象來隱藏實現技術之間的差異，同時還提高了業務可靠性。
為什么需要基于組件的編程模型？
推動 IBM 的 SOA 編程模型的遠景依賴于兩個重要的觀察結果，請看以下兩段引言中的精辟描述：
“根據時髦詞語設計 (Design-by-buzzword) 是一種常見的情況。至少在軟件行業，這種行為或多或少與缺乏對一組給定的有用體系結構約束的理解有關。換句話說，在選擇要重用的軟件體系結構時，設計人員并沒有真正弄清楚這些體系結構之所以好的原因。”
——Roy Thomas Fielding，“Architectural Styles and the Design of Network-based Software Architectures”（請參閱參考資料以獲得指向此研究報告的鏈接）。
這個問題可以通過將詳細了解體系結構約束的原因的人的經驗融入一組模式、編程構件和工具來解決。
第二個重要的觀察結果同人以及人與技術的交互有關：
“創建面向服務的體系結構 (SOA) 意味著重新考慮當前用于構建系統的實踐、組織的技能，以及團隊成員協作的方式。面向服務的作用在于通過組裝不同的應用程序來開發解決方案，SOA 是體系結構樣式，強調獨立服務提供者的松散耦合。”
——A.W. Brown 等，“Realizing service-oriented solutions with the IBM software development platform”（請參閱參考資料以獲得指向這篇文章的鏈接）。
基于 XML 的 Web 服務標準使人想到了基于組件的編程模型的某些方面。諸如 Web 服務互操作性 (WS-I)、Web 服務描述語言 (WSDL) 和 Web 服務策略 (WS-Policy) 之類的標準嘗試創建與平臺無關的抽象和統一的框架來進行業務軟件集成。而 Web 服務的價值來源于在 SOA 中使用它們。
大多數關于 Web 服務的資料都集中于互操作性協議和服務接口及其使用。而本文把重點放在用于實現服務并將服務組裝成解決方案的編程模型上。組件模型簡化了構建和組裝服務的過程。
良好定義的組件應該支持生態系統中的各種用戶角色——例如業務分析人員、集成開發人員、適配器開發人員和解決方案管理員——通過實例化、使用、組裝和自定義符合用戶目標、技能和概念性框架的不同組件類型，來創建面向服務的應用程序。（注意：編程人員作為專業人員和重要的軟件開發角色仍然存在，但并非每個人都必須成為專業編程人員才能高效地使用 SOA 構件。）
Web 服務標準中的組件模型明確地定義了組件和組件類型，以及定義和構造組件的方式，以便由適合角色的工具重用和操作，這與我們對技術使用中人的方面的觀察結果是一致的。
基于組件的編程模型有許多好處，最顯著的好處是可以減少復雜性。沒有哪個角色需要了解實現功能的所有方式或所有的系統接口。公開給每個角色的復雜性是有限的，而公開給開發人員角色的復雜性有助于他們使用適合于其任務的工具以定義良好的方式開發解決方案。
組件模型必須是抽象的，并且與語言無關，因為它的作用在于隱藏技術細節和差異。
組件模型還必須簡化非編程人員組裝和定制“解決方案部分”的過程。因此，與組裝和調整有關的組件（或組件集合）的所有方面必須以與語言無關的方式顯式地聲明，這樣無需編程人員修改源代碼就可以通過工具操作它們。我們使用 XML 來表示這些聲明。
SOA 的確切特征還有待探討，不過一些關鍵的方面已經得到廣泛承認：
- SOA 是一種分布式組件 體系結構。不管在企業內部還是企業外部，SOA 組件都是透明的，并且可以通過一系列統一支持的、可互操作遠程過程調用和消息傳遞協議來統一訪問。接口定義標準支持開發人員工具之間的互操作性。網絡上 (on the wire) 協議互操作性——相對于代碼可移植性——是 SOA 組件的中心部分，支持統一訪問和平臺獨立。調用方不知道組件的基礎實現技術，例如 Java? 2 Platform、Enterprise Edition (J2EE)、Microsoft? .Net 和 PHP。
- SOA 組件封裝功能，并支持通過業務分析人員和業務模型建模的抽象級別的重用。這使 IT 功能和它所支持的業務功能之間的映射更加直接，從而提高了可靠性。
- 聲明性的、計算機可處理的約定允許第三方訪問 SOA 組件提供的服務。這些約定顯式地聲明功能性特征以及非功能性（服務質量或 QoS）特征和需求。SOA 組件使用 WSDL 記錄它們的操作。還可以使用用于 Web 服務的業務流程執行語言 (BPEL4WS) 來定義組件的有效操作序列。
- 可以動態地發現、選擇、綁定（通過其聲明性屬性）和集成（使用組合機制，例如本系列第 3 部分“Process choreography and business state machines”（developerWorks，2005 年 7 月）中描述的組合機制）SOA 組件。
組件實現和專用組件類型
開發人員可以選擇使用 J2EE、PHP 或其他工具實現基本組件。作為一種編程模型，從根本上講，SOA 更多地關系到與組件的交互以及如何將這些交互集成到復合組件、應用程序和解決方案。
我們的編程模型還引入了一些定義良好的組件類型，可以建模開發人員生產和部署到解決方案中的常見構件。其中包括 Plain Old Java Objects (POJOs)、Business Processes (BPEL4WS)、Structured Query Language (SQL) 服務、Adaptive Business Objects、通過 J2EE Connector (J2C) 體系結構資源適配器訪問的 Customer Information Control System (CICS) 程序、使用 SAP 的業務應用程序編程接口的應用程序、J2EE 無狀態會話 Bean 和 IBM MQSeries? 應用程序。
因為在性質上 SOA 組件模型是虛擬的，所以許多 SOA 組件自然支持多種實現技術。另一方面，不同的實現技術更好地適合于不同的任務。為了提高透明度，我們引入了服務組件類型的概念，每種類型都適合于具有特定技能、執行特定任務和使用特定工具的開發人員。對于查詢，編程人員實現了一個 SQL 文件和一個包含一組 XQuery 語句的文件；對于文檔轉換，使用為此任務優化的工具實現 XSLT 樣式表等等。不需要知道 Web 服務、Enterprise JavaBean (EJB) 或其他組件是在部署時生成的，這是因為總體結果是作為通用 SOA 組件公開和使用的。
編程人員構建一種適合于該任務的特定組件類型，集中于要解決的問題和要使用的工具，而不是結果構件。SOA 開發工具應該集中于開發人員的技能和他或她理解的概念。后續文章將簡要介紹一些組件類型，通過三個完全不同的示例——Java 對象、信息管理系統 (IMS) 事務和 SQL 語句——演示如何將任何實現技術映射到公共 SOA 組件模型，同時滿足特定開發人員的需要。
組合
雖然可以使用特定于平臺的技術實現 SOA 組合，但是新的以 SOA 為中心的組合類型可以自己實現，而無需轉換為另一種編程模型。
使用組合模型，可以發現具有所需的接口和所需的基礎設施 (QoS) 策略的服務，并且將這些服務聚合到新的服務、模塊和解決方案中。可以組合這些新的服務。
我們的方法統一了創建和訪問業務邏輯的范型。我們的 SOA 編程模型比現有的編程構造復雜，隱藏了實現技術之間的不同。在這種模型中，組件組裝到模塊中，而模塊又可以組合到解決方案中。組件公開了可以通過可尋址接口調用的接口。接口是使用 WSDL、Java 或其他語言描述的。實現可能有無法解析的對所需服務的引用，這些服務是執行之前由連接在一起的組件提供的。可以由解決方案集成人員或解決方案組裝人員使用適合于角色的工具進行連網操作，他們可以運用可能不為最初開發這些組件的人所知的企業策略和企業服務總線 (ESB) 部署拓撲知識來進行工作。
在沒有進行編程的情況下自定義
不可能始終在沒有進行配置、自定義或調整的情況下按原樣重用服務。在需要更改時，當前的技術發展水平是修改源代碼。然而，是否能夠交付可以大量重用的組件在很大程度上取決于組件適應其使用環境的功能。SOA 編程模型應該支持構建“編程人員”可以在沒有修改源代碼的情況下進行自定義的服務和模塊。當使用組件的編程人員與構建組件的編程人員不在一個單位時，這一點尤為重要。
基于組件的 SOA 編程模型提供了幾種在沒有進行編程的情況下自定義組件的機制。
旨在重用的組件可以打包成具有可變點 (points of variability) 的模板，在將模板放入解決方案時可以對其做一些調整。這種適應性是我們的編程模型最重要的部分，此外，編程模型還包括規則語言和相關工具，用于給新的用戶提供自定義功能。
中介主要用于處理動態消息。通常可以在沒有進行編程的情況下組合中介。作為一個多協議構造，企業服務總線發揮了重要的作用，可以將服務組件組合在一起進行無縫交互，另外，還允許在消息的路徑中插入稱為中介 的組件，以在不改變現有端點的情況下代理服務之間的交互，從而在主要方面解決整個企業范圍內的問題，例如審核、記錄、路由、不匹配接口的適應性、等效組件的增量替換和安全性。
SOA 編程模型的另一個好處（來源于前面提到的特性）是能夠在軟件生命周期的不同階段用一個組件替換另一個組件。通過將聲明的接口延遲綁定到支持這些接口的實現可以做到這一點。企業為什么需要替換功能單元，有許多方面的原因。其中最重要的原因可能是減少在大型企業中管理更改的困難。以增量的方式引入更改并且通過遵循定義的接口限制其影響可以提高靈活性。這種做法也適合于松散耦合，而松散耦合常常是大型組織的特征。此外，使用服務組件，有不同的技能、需求和時間安排的組可以以人力資源和系統資源兩方面的效率都最高的方式在 IT 基礎設施中協同工作，這樣企業就可以快速地響應業務級的更改，從而使企業大大獲益。
組件定義
我們的 SOA 是由以下規范定義的：
-
服務規范 以組件提供和使用的一組服務的形式提供了組件的視圖。它由以下三組規范定義：
- 接口，通常是 WSDL
portTypes。
- 策略，記錄 QoS 屬性，例如事務行為和安全性。
- 行為描述，例如 BPEL4WS 抽象流程。另一個例子可能是統一建模語言 V2 (UML2) 狀態模型，該模型指定了哪些操作對不同的狀態和操作所引發的狀態事務是有效的。調用方可以通過狀態模型計算有效的操作序列。
-
服務組件實現 是由以下四組規范定義的：
- 提供的服務規范。
- 需要的服務規范。
- 可以在組件上設置以調整或自定義的屬性。
- 為此提供基本支持的屬性；更復雜的方案使用可變點和對自定義組件的外部調用。
- 對所有實現實例都保持不變的容器指示（策略）。
- 定義組件實現的實現構件（例如 Java 類、BPEL 文檔或 XSLT 規則集）。
-
服務組件（實例）由以下規范定義：
- 名稱。
- 服務組件實現。
- 實現的任何屬性的值，設置用于調整實例。
- 任何服務的規范，解析實現需要的服務規范。它們可以是連接組件實例的“網絡”，也可以是在運行時執行以查找組件的“查詢”，所查找的組件實現相關接口，具有相關的 QoS 策略，并且匹配指定的行為（例如抽象流程或狀態模型）。
有兩種定義 SOA 組件的基本方法。這些定義可以通過開發工具生成，也可以由開發人員手動創建。
第一種方法是控制文件，顧名思義，控制文件即關聯或聯接組件的所有部分的文檔。例如，控制文件可以引用 WSDL 定義（提供的接口）、實現組件的 Java 類（實現構件）或相關的策略文檔（策略斷言）。 它們可以是對文件系統、類路徑、源代碼管理系統或 Web URL 的引用。控制文件方法將多個單獨開發的構件聚合在一起組成組件。應用程序開發工具可以幫助定義控制文件。
第二種方法是使用 pragmas，指定相同信息的語言元素，但是包含在單個源文件的主體中。Java 方面的支持正在不斷增加（例如，JSR 175 中的 XDoclet 標記），以用 Java 語言編寫這些批注部分。但是這種方法尚不支持其他等同的有效 SOA 組件實現技術（如 SQL 或 XQuery 語句集）。每種組件類型都有用于其實現構件的相關源文件格式，例如 Java 文件、狀態機或 SQL 文件。IBM WebSphere? Rapid Deployment 中的批注支持可以生成所有組成包含 pragmas 的源文件中的組件的單個元素。例如，Java 源文件中的結構化注釋指示哪些 Java 方法將成為所生成的定義組件的服務接口中的 Web 服務操作。
總結
基于組件的編程模型——由面向任務的工具和運行時基礎設施支持——是快速采用 SOA 的關鍵。借助于期望的優勢（如新的軟件重用方法），專業人員（不必是編程人員）可以在新的業務需求出現時使用 SOA 組件創建新的業務解決方案和改寫現有的業務解決方案。