http://www.searchsoa.com.cn/showcontent_7639.htm
Web Service 通常將業務數據封裝在 SOAP 主體或者 SOAP 消息附件中進行傳輸，這些附件往往採用 Base64 編碼二進制方式進行封裝，這將大大增加待傳輸的數據量，消耗比較長的編碼時間和傳輸時間。隨着 SOA 以及 Web Service 技術的廣泛採用，由於網絡帶寬，延時的影響以及內存大小的限制，越來越多的應用對 Web Service 附件傳輸方式以及傳輸效率提出了更高的要求。
引言
本文對 Web Service 附件技術及其相關開發工具進行了總結，詳細介紹了 Web Service 附件技術的發展及其演變。近些年，先後有 SwA, DIME, WS-Attachments, PASwA, XOP, MTOM 等規範產生，經過不斷的改進，SOAP 消息附件封裝方法已經有了比較滿意的解決方案，附件傳輸和處理效率上得到了很大提高，其打包和傳輸方式也逐漸具有統一的處理方法。
Web Service 數據交換協議
Web Service 使用 SOAP 作爲其標準的數據交換協議。SOAP 是一個基於 XML 的輕量級協議，用於在無中心、分佈式環境中交換結構化的數據，該協議完全獨立於具體的系統平臺、軟件架構和編程語言，提供了一種開放和統一的方式支持應用間的集成和互操作。
SOAP 的設計目標是簡單性和擴展性，有助於大量異構程序和平臺之間的互操作性，從而使存在的應用程序能夠被廣泛的用戶訪問。目前，SOAP 已經成爲開放性互聯網絡應用中標準的數據交換技術。2000 年 W3C 推出了 SOAP1.1 版本，最新的 SOAP1.2 在 2007 年 4 月推出，併成爲 W3C 的推薦規範。
SOAP 只是爲上層應用提供一個數據的載體，數據的具體語義由上層應用定義。SOAP 報文最外層元素爲 Envelope，即 SOAP 信封。Envelope 之下有兩個子元素：Header 元素和 Body 元素。其中 Body 元素是 SOAP 報文的主要數據載體，該元素是必需的。用於存放待交換的信息，具體表示爲 Body 的子元素；Body 的每個直接子元素稱爲 Body Block，用於存放具體應用中在邏輯上相關的一組數據；Header 元素是可選的，主要用於擴展機制，Header 的直接子元素稱爲 Header Block，每個 Header Block 的擴展語義由基於 SOAP 的上層應用來定義，常用的擴展包括安全、事務、消息相關性等。
SOAP 故障 (Fault) 報文是一種特殊的 SOAP 報文，用於在發生故障的場景中運載錯誤信息。在 SOAP 故障報文中，Body 有且僅有一個名爲 Fault 的直接子元素，用於存放和具體故障有關的詳細錯誤信息，包括故障代碼、故障原因、發生故障的 SOAP 結點等。圖 1 爲 SOAP 數據報文和 SOAP Fault 報文示意圖。
圖 1. SOAP 數據報文和 SOAP Fault 報文
在 Web Service 的實現中，經常需要在 SOAP 報文中攜帶各種類型的附件 ( 如圖像、文檔等 ) 一起傳輸。例如，在典型的電子商務應用中，客戶向商家詢問某種商品的詳細信息，商家向客戶發回 SOAP 格式的回覆消息，其中包含有商品的詳細說明，商品的圖片等供客戶參考。這些附件可能是文本文件，XML 片段，二進制文件等等。然而，SOAP 是一種基於 XML 的文本協議，只能使用可見字符組成的文本來表示數據，無法在報文中直接包含其他格式的附件。因此，如何將 SOAP 報文同其他格式的附件組織在一起進行傳輸便成爲一個需要解決的重要問題。
爲了對 SOAP 及其他 Web Service 標準進行支持，Java 社區進程組織 (JCP: Java Community Process) 提供並實現了 Java 方面的 Web 服務的原始標準 JAX-RPC1.x (JavaTM APIs for XML based RPC) 和 JAX-WS (JavaTM API for XML-Based Web Services 2.0)。JAX-RPC 最早版本是 JAX-RPC1.0，進過一段時間使用便更新到 JAX-RPC1.1，在 J2EE1.4 中包含 JAX-RPC1.1。JAX-RPC1.1 使用約 1 年後 JCP 再次對其進行更新，考慮到 Web 服務中不單有 RPC Web 服務，還有面向消息的 Web 服務，因而將其更名爲更合理的 JAX-WS。目前 JAX-WS2.0 仍在進行當中。JAX-RPC1.1 提供對 SOAP1.1 的支持，JAX-WS2.0 對 SOAP1.1 和 SOAP1.2 進行支持。
Base64 編碼的二進制 SOAP 附件
爲了簡單和通用性，XML 被設計成了以文本的格式來表示數據。使用 SOAP 進行傳遞的數據首先被序列化，也就是將數據轉換成字符串在 XML 文檔中傳送。在目的地，字符串再被反序列化，即再被轉換成表示原來的值的數據類型。把二進制數據放入 SOAP 報文的最簡單的方法，就是使用 Base64 編碼的方式對其進行編碼，以實現數據的序列化和反序列化。
Base64 是一種很常見的編碼規範，其作用是將二進制序列轉換爲可讀的 ASCII 字符序列，常用在需用通過文本協議傳輸二進制數據的情況下，例如 HTTP 和 SMTP 協議。Base64 編碼基本原理是把每三個 8bit 的字節轉換爲四個 6bit 的字節，然後把 6bit 再添兩位高位 0，組成四個 8bit 的字節，不滿四個字節的以 '=' 填充。因爲 Base64 將輸入的數據編碼成只含有 {'A'-'Z', 'a'-'z', '0'-'9', '+', '/'} 這 64 個字符的串，所以稱之爲 Base64 編碼。可以看出，轉換後的字符串理論上將要比原來的長 1/3。
在 W3C 的 XML Schema Part 2: Datatypes 規範中，定義了 base64Binary 類型，SOAP 報文中使用 Base64 編碼的二進制內容可以定義爲該類型。一個使用 Base64 編碼的圖片數據在 SOAP 報文中的結構如清單 1 所示：
清單 1. 一個使用 Base64 對數據進行編碼的 SOAP 報文
<?xml version='1.0' ?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<Car name="myCar">
<BNZE xsi:type="xsi:base64Binary">L3EWw43eku34EEli34wejlE72=</BNZE>
</Car>
</soap:Body>
</soap:Envelope>
MIME 與 SOAP Messages with Attachments
儘管使用 Base64 編碼能夠將二進制數據放入 SOAP 報文中進行傳輸，然而，其效率非常低下。根據前面對 Base64 編碼原理的分析，採用 Base64 編碼將會引入 33% 的冗餘尺寸，從而使 SOAP 消息變大；另外，對二進制數據進行編碼和解碼將造成較大的時間開銷，嚴重影響應用程序的性能。鑑於這些問題，2000 年 12 月，W3C 組織推出了 SOAP 附件標準：SOAP Messages with Attachments (SwA) 規範，將 SOAP 附件置於 SOAP 主體之外，基於 MIME 技術實現了 SOAP 報文同 SOAP 附件的封裝。
MIME (Multipurpose Internet Mail Extensions) 多用途互聯網郵件擴展，是當前廣泛應用的一種電子郵件技術規範，基本內容定義於 RFC 2045-2049。MIME 出現之前，郵件中只能發送 ASCII 碼文本信息，如果要發送二進制文件，如聲音和視頻等，難以實現。MIME 使得在郵件中支持多種不同編碼文件成爲可能。儘管 MIME 一開始用於郵件傳輸中，現在 MIME 已經成爲 HTTP 協議標準的一部分。
MIME 消息由消息頭和消息體兩大部分組成，郵件頭與郵件體之間以空行進行分隔。郵件頭包含了發件人地址 (From)、收件人地址 (To)、主題 (Subject)、MIME 版本 (MIME-Version)、內容的類型 (Content-Type)，內容的傳輸編碼方式 (Content-Transfer-Encoding) 等信息，每條信息稱爲一個域。郵件體包含郵件的內容，類型由郵件頭的“Content-Type”域指明，分爲簡單類型和 Multipart 類型。簡單類型如 text/plain, text/html 等，Multipart 類型表明將郵件體分爲多個段，每段又分爲段頭和段體，也以空行分隔。常見的 Multipart 類型有三種：Multipart/Mixed, Multipart/Related 和 Multipart/Alternative。如果郵件中要添加附件，而且附件之間有相互關聯關係，則使用 Multipart/Related。
SOAP 附件標準 SwA 只針對 SOAP1.1 版本，其 MIME 類型爲 Multipart/Related，表示文檔的多個部分是相關的，Multipart/Related 報頭的 type 參數值爲”text/xml”。SOAP1.1 消息主體位於 Multipart/Related 結構的第一段，其 Content-Type 的值也爲”text/xml”。其餘的 MIME 段爲 SOAP 附件，附件可以是任意類型數據，每個附件 MIME 段由段頭的 Content-ID 或者 Content-Location 唯一標識，比較常用的是 Content-ID。
圖 2 爲 SwA 規範下的帶附件 SOAP 報文結構圖。圖中 SOAP 消息由 MIME 頭，一個封裝主體 SOAP1.1 消息的 MIME 段和一個或多個封裝 SOAP 附件的 MIME 段三部分組成。其中每部分以 MIME 邊界分隔，Context-Type 用於指定 MIME 段的數據的類型、Content Transfer-encoding 用於指定用於 MIME 段的編碼方式、Content-ID 或者 Content-Location 用於作爲該 MIME 部件的標識符。
圖 2. SwA 規範下帶有附件的 SOAP 報文
清單 2 是一個基於 SwA 的 SOAP 報文示例。例子中的圖像數據在一個 MIME 結構中，通過屬性”href”被引用的，href 的值爲一個 URI，URI 使用 MIME 頭的 Content-ID 值來找到附件。
清單 2. 一個基於 SwA 的 SOAP 報文
POST /test HTTP/1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml
Content-Length: XXXX
SOAPAction: http://www.soapattach.com/test
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
<?xml version='1.0'?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Car name="myCar">
<Picture href = “cid:[email protected]”/>
</Car>
</soap:Body>
</soap:Envelope>
--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <[email protected]>
...binary JPEG image...
--MIME_boundary--
SwA 避免了編碼的開銷和冗餘，但是也帶來了一些新的問題。首先，SwA 使用字符串作爲 MIME 結構的定界符，爲了解析出 MIME 結構，必須遍歷所有數據，當數據量較大時，效率非常低下，當 MIME 結構中出現和定界字符串相同內容的情況時，處理起來更復雜；其次，通用的 XML 技術，如 XPath、XQuery、XSLT 以及 XML schema 等，對於 XML 文件中包含的二進制內容無法處理，因而也無法對符合 SwA 的 SOAP 報文使用各種通用的 XML 技術進行處理。儘管程序知道附件數據的存在，但是文檔自身並不知道，另外，不同的
SOAP 報文處理器，以及 SOAP 消息和 WSDL 之間存在大量的互操作性問題。在 Web 服務互操作性組織 WS-I 的官方網站上可以找到其所總結的各種 Web Service 互操作性問題的詳細信息。
在 SwA 的具體實現中，涉及到三種主要的 API：SAAJ (SOAP with Attachments API for Java), JAXM (Java API for XML messaging), JAX-RPC。這三種 API 都是 JCP 所制定的 Web Service 的 Java 實現標準。SAAJ 是實現 SwA 規範的 API，是從 JAXM 1.1 中分離出來的。SAAJ 包含許多類和接口，用來定義 SOAP 元素 (Envelope, Body, Header, Fault 等 )，XML 名稱空間，以及 MIME 附件等。通過 SAAJ 提供的 API 可以生成帶 MIME 附件的 SOAP 消息。J2EE1.4 包含了 SAAJ1.2，該版本支持 SOAP1.1，J2EE1.5 包含了最新的 SAAJ1.3。而 JAXM 是面向文檔的用於將 SOAP 消息以 XML 格式進行異步傳送的 API。JAXM 客戶端使用 SAAJ 來構造和解析 SOAP 消息。JAX-RPC 依賴於 SAAJ，提供了 RPC 方式 Web 服務實現，定義了三種客戶端編程模型：Generated Stub、Dynamic Proxy 和 Dynamic Invocation Interface。
DIME 與 WS-Attachments
爲了解決 SwA 的效率低下問題，2002 年 7 月，IBM 和微軟向 IETF 提交了直接因特網消息封裝提議 (DIME: Direct Internet Message Encapsulation)，以及相應的 WS-Attachments 規範，使用 DIME 和 WS-Attachments 對 SOAP 消息附件進行封裝。
DIME 是一個輕量級二進制消息格式，能夠將任意格式數據的多個記錄序依次序列化爲流，使用有效的二進制標頭進行說明。
DIME 記錄標頭包含 DIME 版本、數據的類型信息、唯一標識每個記錄的 ID、數據長度信息以及可選信息等。DIME 消息的第一個記錄在標頭中設置了消息開始標誌 MB，最後一個記錄設置了消息結束標誌 ME。MB 和 ME 標誌均是一個 1 位字段，當被置位時，分別表明 DIME 消息的開始和結束。對於較大的記錄或最初不知道數據大小的記錄，DIME 定義了“記錄區塊”，使用記錄區塊將單個記錄分解成多個塊。記錄區塊在標頭中設置了區塊標誌 CF，表明該數據是分塊記錄的一部分，並且其後包含更多的數據。
數據字段攜帶 DIME 用戶應用程序的有效負載。數據字段內攜帶的數據的內部結構對 DIME 是不透明的。數據字段的長度必須是 4 個 8bit 數據的倍數。如果有效負載的長度不是 4 個 8bit 數據的倍數，那麼用全零 8bit 數據填充。填充部分並不算在數據長度字段中，並且絕不可以用超過 3 個 8bit 數據填充數據字段。圖 3 爲 DIME 數據記錄格式
圖 3. DIME 數據記錄格式
DIME 根據某個記錄的開始位置，可以輕鬆地定位到下一個記錄的位置，只需將標頭固定區域的長度與可選數據、ID、類型和數據部分的長度相加。這種以高效方式確定記錄長度對於在流的記錄之間快速移動十分重要。
DIME 本身只是一種用來對任意格式的數據記錄集合進行打包的機制。它對於記錄有效負載的內容、ID 字段中包含的內容或者如何將 SOAP 消息封裝到 DIME 消息中等沒有任何要求。DIME 的記錄內容沒有任何限制，其有效負載甚至可以包含其他 DIME 消息，只需將該記錄的類型設置爲“application/dime”。
WS-Attachments 定義瞭如何使用 DIME 數據包發送包含附件的 SOAP 消息，標識了 DIME 消息中哪些是 SOAP 消息，哪些是附件。對於包含附件的 SOAP 消息，將主要消息稱爲“主 SOAP 消息部分”，將附加的部分稱爲“從屬部分”。WS-Attachments 要求主 SOAP 消息部分必須包含在 DIME 消息的第一個記錄中，主 SOAP 消息部分通過使用 href 屬性引用附件，其值爲 HTTP URL。此外，WS-Attachments 還說明了如何使用 DIME 記錄標頭的 ID 字段引用特定的 DIME 記錄。
清單 3 是一個基於 WS-Attachments 的 SOAP 報文，其中 DIME 消息的從屬部分的 ID 爲 uuid：6FF57555-8750-4555-8237-95ELIWEK87B4F，引用了此類附件的主 SOAP 消息部分的代碼如下所示：
清單 3. 基於 WS-Attachments 規範的 SOAP 報文
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
<soap:Body>
<attach:responseMesssage xmlns:attach="http://example.net /attachment">
<attach:message
href="uuid: 6FF57555-8750-4555-8237-95ELIWEK87B4F"/>
</attach:responseMessage>
</soap:Body>
</soap:Envelope>
該消息正文中的 message 元素的 href 屬性用來指定 DIME 記錄的 ID。DIME 記錄中的數據可能是此消息所響應的另一個 SOAP 消息，此時 DIME 消息的接收方可以從 DIME 消息指定的從屬部分中找到該消息。WS-Attachments 不但可以從主 SOAP 消息部分中引用 DIME 消息的從屬部分，也可以從從屬部分中進行類似引用，這樣兩個從屬部分就可以相互引用，甚至一個從屬部分還可以引用主 SOAP 消息部分。
WS-Attachments 還說明了如何在 HTTP 請求中發送複合 SOAP 消息。這種情況下，HTTP 的 Content-Type 標頭必須設爲“application/dime”，HTTP 請求的正文爲 DIME 消息而不是 SOAP 消息。
儘管 DIME 解決了 SwA 中遍歷定界符導致的效率低下問題， DIME 強迫開發者從 MIME 完全轉向 DIME，最後導致 DIME 和 WS-Attachments 並沒有得到廣泛應用。
PASwA, XOP 和 MTOM
爲了解決 SwA 導致的互操作性問題，2003 年 4 月 Microsoft, BEA, Canon, SAP 和 Tibco 等公司提出了規範 Proposed Infoset Addendum to SOAP Messages with Attachments (PASwA)。PASwA 基於 SwA 規範，是對 SwA 規範的補充。
PASwA 一個重要目標是使 XML Infoset 具有一個統一的邏輯視圖，而不需要對由於 XML 中包含二進制數據，SwA 和 WSDL 之間的互操作性等問題而另外處理。XML Infoset 定義了一種抽象的方式，把 XML 文檔描述爲一系列信息項，爲需要引用 XML 文檔中的信息的規範提供了一致的定義。
PASwA 主要增加了如下內容：
xmime:mediaType 屬性：用於指明 XML 文件中 base64 編碼部分的媒體類型，例如 xmime:mediaType 的值可以爲 image/png，audio/mpeg，application/pkcs7-signature 等，這些值在 RFC 2045 和 RFC 2046 指定
xmime:Binary 類型：基於 xs:base64Binary 的複合類型，xmime:mediaType 爲其可選屬性
Swa:Accept 屬性：用於申明其所支持的媒體類型，主要用於 WSDL 中
帶有 herf 屬性的 xbinc:Include 元素：在 SOAP 消息中鏈接到相關的附件數據
在 SOAP 消息頭中增加了 xbinc:DoInclude 和 swa:Representation 塊：xbinc:DoInclude 用於表示 SOAP 報文中包含 xbinc:Include 元素，SOAP 消息處理器應該特殊處理；swa:Representation 表示允許 SOAP 節點發送緩存的 Web 資源
儘管 PASwA 並沒有被 W3C 所採納，然而，PASwA 直接導致了 W3C 的 XML 二進制優化打包 (XOP: XML-binary Optimized Packaging) 和 SOAP 消息傳輸優化機制 (MTOM: Message Transmission Optimization Mechanism) 規範的產生。
XOP 使用 MIME 將原始二進制數據引入到 XML 1.0 文檔中。XOP 是 XML 的可選序列化方法，在 XOP 數據包裏，被命名爲 base64 字符串的事物都可以作爲其附件，方法與 SwA 類似。所不同的是：數據和附件之間的鏈接不是依靠應用程序進行處理，而是由該格式自行處理。XOP 使用 xop:Include 元素顯式地將內容與附件關聯起來，並避免了 SwA 中存在的歧義性。
在 XOP 規範中主要有如下基本元素：Original XML Infoset，Optimized Content，XOP Infoset，XOP Document，XOP Package 和 Reconstituted XML Infoset。其定義如下：
Original XML Infoset 是需要被優化的原始 XML Infoset
Optimized Content 是原始 XML Infoset 中需要被優化的內容
XOP Infoset 是使用 xop:Include 元素替換掉原來 XML Infoset 中的相應信息得到的新的 XML Infoset
XOP Document 是符合 W3C recommendation 規範序列化後的 XOP Infoset
XOP Package 是 XOP Document 和 Optimized Content 的打包。XOP Package 是原始 XML Infoset 的一種可選的序列化方式
Reconstituted XML Infoset 是使用 XOP 包組成的 XML Infoset
一個完整的 XOP 消息包包括以下 3 個部分：MIME 頭，主體 SOAP 消息部分和附件部分。其中，MIME 頭的類型，即 Content-Type 的值總是爲 Multipart/Related，其 type 參數總是等於主體 SOAP 消息的 Content-Type 的值，也就是 application/xop+xml；主體 SOAP 消息部分，用於存儲 XOP Infoset 格式的 SOAP Envelop；附件部分，用於存儲二進制或者非二進制附件數據。
清單 4 爲原始 XML Infoset，其中 attach:Car 元素爲原始 XML Infoset 中需要被優化的內容。清單 5 爲序列化後的 XOP 包，該 XOP 包中只含有一個附件數據。
清單 4. 原始 XML Infoset
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xmlmime="http://www.w3.org/2004/06/xmlmime">
<soap:Body>
<attach:Car name="Eric" xmlns:attach="http://example.cn/attachment">
<attach:Picture xmlmime:content-type='image/jpeg'>WE72WEWTi2VuYJY=
</attach:Picture>
</attach:Car>
</soap:Body>
</soap:Envelope>
清單 5. 序列化後的 XOP Package
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary;
type= application/xop+xml;
start="<[email protected]>";
start-info="application/xop+xml"
--MIME_boundary
Content-Type: application/xop+xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <[email protected]>
<?xml version='1.0'?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xmlmime="http://www.w3.org/2004/06/xmlmime">
<soap:Body>
<attach:Car name="Eric" xmlns:attach="http://example.cn/attachment">
<attach:Picture xmlmime:content-type='image/jpeg'>
<xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include'
href="cid:[email protected]"/>
</attach:Picture>
</attach:Car>
</soap:Body>
</soap:Envelope>
--MIME_boundary
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <[email protected]>
...binary JPEG image...
--MIME_boundary--
在 SOAP 消息構造和傳輸中使用 XOP 的過程稱爲 MTOM。MTOM 的目的在於優化 base64 編碼數據的傳輸。只有具有 xs:base64Binary 標準格式的字符組成的節點纔可以被優化。使用 MTOM，SOAP 消息包以 XOP 消息包的格式傳輸。
此外，爲了解決 SwA 導致的互操作性問題，與 PASwA 和 MTOM 同時進行的，還有 WS-I 的附件概要規範。2004 年 8 月 24 日，WS-I 推出了附件概要 AP1.0 (Attachment Profile Version 1.0) 規範，用以解決 SOAP 消息和基於附件的 Web 服務之間的互操作性問題，最新版爲 2006 年 4 月 20 日發佈的 AP1.0 第二版。AP1.0 和 WS-I 的另一規範，簡單 SOAP 綁定概要 SSBP1.0 (Simple SOAP Binding Profile 1.0)，構成了 WS-I 的基本概要 BP1.1(Basic Profile Version 1.1) 的補充規範。由於 AP1.0 和 PASwA 以及 MTOM 的衝突，很多開發者並沒有採用 AP1.0，而是直接轉向 MTOM。
在 JAX-RPC1.1 中，提供了對 BP1.0 的支持，JAX-WS2.0 已經提供或者即將提供對 BP1.1, AP1.0, SSBP1.0, XOP 以及 MTOM 的支持。
目前，IBM WebSphere 產品已經提供了對 MTOM 和 XOP 的支持，在其最新發布 WebSphere Application Server Feature Pack for Web Services 中可以找到相應實現，用戶只需安裝 WAS 6.1 feature pack for Web Services，關於 IBM 對 MTOM 更詳細的實現信息可見參考資料中的 WAS6.1 專門針對 Web Service 包的介紹。
總結
隨着 Web Service 技術的廣泛採用，對其附件技術的要求也越來越高，先後出現了 SwA, DIME, WS-Attachments, AP1.0, PASwA, XOP, MTOM 等規範。其中，DIME, WS-Attachments 已經基本被淘汰了；目前使用比較廣泛的是 SwA 和 AP1.0，其缺點是存在大量的互操作性問題和效率問題；XOP 和 MTOM 提供了一種通用和高效的機制，其相應規範仍在完善中，隨着其推廣應用相信今後必將被廣泛採用。
關於作者
劉力，IBM 中國軟件開發實驗室 SOA 設計中心高級工程師，具有多年的 J2SE, J2EE 和 Web Service 開發經驗，目前專注於 SOA 項目實踐和相關的理論、工具的研究和開發。本文僅代表作者的個人觀點，不代表 IBM 的立場。如果您對本文的內容有任何的問題，歡迎通過郵件 ([email protected]) 和作者聯繫。
