Web Service 通常將業(yè)務(wù)數(shù)據(jù)封裝在 SOAP 主體或者 SOAP 消息附件中進(jìn)行傳輸，這些附件往往采用 Base64 編碼二進(jìn)制方式進(jìn)行封裝，這將大大增加待傳輸?shù)臄?shù)據(jù)量，消耗比較長的編碼時間和傳輸時間。隨著 SOA 以及 Web Service 技術(shù)的廣泛采用，由于網(wǎng)絡(luò)帶寬，延時的影響以及內(nèi)存大小的限制，越來越多的應(yīng)用對 Web Service 附件傳輸方式以及傳輸效率提出了更高的要求。

引言

本文對 Web Service 附件技術(shù)及其相關(guān)開發(fā)工具進(jìn)行了總結(jié)，詳細(xì)介紹了 Web Service 附件技術(shù)的發(fā)展及其演變。近些年，先后有 SwA, DIME, WS-Attachments, PASwA, XOP, MTOM 等規(guī)范產(chǎn)生，經(jīng)過不斷的改進(jìn)，SOAP 消息附件封裝方法已經(jīng)有了比較滿意的解決方案，附件傳輸和處理效率上得到了很大提高，其打包和傳輸方式也逐漸具有統(tǒng)一的處理方法。

---

Web Service 數(shù)據(jù)交換協(xié)議

Web Service 使用 SOAP 作為其標(biāo)準(zhǔn)的數(shù)據(jù)交換協(xié)議。SOAP 是一個基于 XML 的輕量級協(xié)議，用于在無中心、分布式環(huán)境中交換結(jié)構(gòu)化的數(shù)據(jù)，該協(xié)議完全獨立于具體的系統(tǒng)平臺、軟件架構(gòu)和編程語言，提供了一種開放和統(tǒng)一的方式支持應(yīng)用間的集成和互操作。

SOAP 的設(shè)計目標(biāo)是簡單性和擴展性，有助于大量異構(gòu)程序和平臺之間的互操作性，從而使存在的應(yīng)用程序能夠被廣泛的用戶訪問。目前，SOAP 已經(jīng)成為開放性互聯(lián)網(wǎng)絡(luò)應(yīng)用中標(biāo)準(zhǔn)的數(shù)據(jù)交換技術(shù)。2000 年 W3C 推出了 SOAP1.1 版本，最新的 SOAP1.2 在 2007 年 4 月推出，并成為 W3C 的推薦規(guī)范。

SOAP 只是為上層應(yīng)用提供一個數(shù)據(jù)的載體，數(shù)據(jù)的具體語義由上層應(yīng)用定義。SOAP 報文最外層元素為 Envelope，即 SOAP 信封。Envelope 之下有兩個子元素：Header 元素和 Body 元素。其中 Body 元素是 SOAP 報文的主要數(shù)據(jù)載體，該元素是必需的。用于存放待交換的信息，具體表示為 Body 的子元素；Body 的每個直接子元素稱為 Body Block，用于存放具體應(yīng)用中在邏輯上相關(guān)的一組數(shù)據(jù)；Header 元素是可選的，主要用于擴展機制，Header 的直接子元素稱為 Header Block，每個 Header Block 的擴展語義由基于 SOAP 的上層應(yīng)用來定義，常用的擴展包括安全、事務(wù)、消息相關(guān)性等。

SOAP 故障 (Fault) 報文是一種特殊的 SOAP 報文，用于在發(fā)生故障的場景中運載錯誤信息。在 SOAP 故障報文中，Body 有且僅有一個名為 Fault 的直接子元素，用于存放和具體故障有關(guān)的詳細(xì)錯誤信息，包括故障代碼、故障原因、發(fā)生故障的 SOAP 結(jié)點等。圖 1 為 SOAP 數(shù)據(jù)報文和 SOAP Fault 報文示意圖。

圖 1. SOAP 數(shù)據(jù)報文和 SOAP Fault 報文

在 Web Service 的實現(xiàn)中，經(jīng)常需要在 SOAP 報文中攜帶各種類型的附件 ( 如圖像、文檔等 ) 一起傳輸。例如，在典型的電子商務(wù)應(yīng)用中，客戶向商家詢問某種商品的詳細(xì)信息，商家向客戶發(fā)回 SOAP 格式的回復(fù)消息，其中包含有商品的詳細(xì)說明，商品的圖片等供客戶參考。這些附件可能是文本文件，XML 片段，二進(jìn)制文件等等。然而，SOAP 是一種基于 XML 的文本協(xié)議，只能使用可見字符組成的文本來表示數(shù)據(jù)，無法在報文中直接包含其他格式的附件。因此，如何將 SOAP 報文同其他格式的附件組織在一起進(jìn)行傳輸便成為一個需要解決的重要問題。

為了對 SOAP 及其他 Web Service 標(biāo)準(zhǔn)進(jìn)行支持，Java 社區(qū)進(jìn)程組織 (JCP: Java Community Process) 提供并實現(xiàn)了 Java 方面的 Web 服務(wù)的原始標(biāo)準(zhǔn) 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，進(jìn)過一段時間使用便更新到 JAX-RPC1.1，在 J2EE1.4 中包含 JAX-RPC1.1。JAX-RPC1.1 使用約 1 年后 JCP 再次對其進(jìn)行更新，考慮到 Web 服務(wù)中不單有 RPC Web 服務(wù)，還有面向消息的 Web 服務(wù)，因而將其更名為更合理的 JAX-WS。目前 JAX-WS2.0 仍在進(jìn)行當(dāng)中。JAX-RPC1.1 提供對 SOAP1.1 的支持，JAX-WS2.0 對 SOAP1.1 和 SOAP1.2 進(jìn)行支持。

---

Base64 編碼的二進(jìn)制 SOAP 附件

為了簡單和通用性，XML 被設(shè)計成了以文本的格式來表示數(shù)據(jù)。使用 SOAP 進(jìn)行傳遞的數(shù)據(jù)首先被序列化，也就是將數(shù)據(jù)轉(zhuǎn)換成字符串在 XML 文檔中傳送。在目的地，字符串再被反序列化，即再被轉(zhuǎn)換成表示原來的值的數(shù)據(jù)類型。把二進(jìn)制數(shù)據(jù)放入 SOAP 報文的最簡單的方法，就是使用 Base64 編碼的方式對其進(jìn)行編碼，以實現(xiàn)數(shù)據(jù)的序列化和反序列化。

Base64 是一種很常見的編碼規(guī)范，其作用是將二進(jìn)制序列轉(zhuǎn)換為可讀的 ASCII 字符序列，常用在需用通過文本協(xié)議傳輸二進(jìn)制數(shù)據(jù)的情況下，例如 HTTP 和 SMTP 協(xié)議。Base64 編碼基本原理是把每三個 8bit 的字節(jié)轉(zhuǎn)換為四個 6bit 的字節(jié)，然后把 6bit 再添兩位高位 0，組成四個 8bit 的字節(jié)，不滿四個字節(jié)的以 '=' 填充。因為 Base64 將輸入的數(shù)據(jù)編碼成只含有 {'A'-'Z', 'a'-'z', '0'-'9', '+', '/'} 這 64 個字符的串，所以稱之為 Base64 編碼。可以看出，轉(zhuǎn)換后的字符串理論上將要比原來的長 1/3。

在 W3C 的 XML Schema Part 2: Datatypes 規(guī)范中，定義了 base64Binary 類型，SOAP 報文中使用 Base64 編碼的二進(jìn)制內(nèi)容可以定義為該類型。一個使用 Base64 編碼的圖片數(shù)據(jù)在 SOAP 報文中的結(jié)構(gòu)如清單 1 所示：

清單 1. 一個使用 Base64 對數(shù)據(jù)進(jìn)行編碼的 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 編碼能夠?qū)⒍M(jìn)制數(shù)據(jù)放入 SOAP 報文中進(jìn)行傳輸，然而，其效率非常低下。根據(jù)前面對 Base64 編碼原理的分析，采用 Base64 編碼將會引入 33% 的冗余尺寸，從而使 SOAP 消息變大；另外，對二進(jìn)制數(shù)據(jù)進(jìn)行編碼和解碼將造成較大的時間開銷，嚴(yán)重影響應(yīng)用程序的性能。鑒于這些問題，2000 年 12 月，W3C 組織推出了 SOAP 附件標(biāo)準(zhǔn)：SOAP Messages with Attachments (SwA) 規(guī)范，將 SOAP 附件置于 SOAP 主體之外，基于 MIME 技術(shù)實現(xiàn)了 SOAP 報文同 SOAP 附件的封裝。

MIME (Multipurpose Internet Mail Extensions) 多用途互聯(lián)網(wǎng)郵件擴展，是當(dāng)前廣泛應(yīng)用的一種電子郵件技術(shù)規(guī)范，基本內(nèi)容定義于 RFC 2045-2049。MIME 出現(xiàn)之前，郵件中只能發(fā)送 ASCII 碼文本信息，如果要發(fā)送二進(jìn)制文件，如聲音和視頻等，難以實現(xiàn)。MIME 使得在郵件中支持多種不同編碼文件成為可能。盡管 MIME 一開始用于郵件傳輸中，現(xiàn)在 MIME 已經(jīng)成為 HTTP 協(xié)議標(biāo)準(zhǔn)的一部分。

MIME 消息由消息頭和消息體兩大部分組成，郵件頭與郵件體之間以空行進(jìn)行分隔。郵件頭包含了發(fā)件人地址 (From)、收件人地址 (To)、主題 (Subject)、MIME 版本 (MIME-Version)、內(nèi)容的類型 (Content-Type)，內(nèi)容的傳輸編碼方式 (Content-Transfer-Encoding) 等信息，每條信息稱為一個域。郵件體包含郵件的內(nèi)容，類型由郵件頭的“Content-Type”域指明，分為簡單類型和 Multipart 類型。簡單類型如 text/plain, text/html 等，Multipart 類型表明將郵件體分為多個段，每段又分為段頭和段體，也以空行分隔。常見的 Multipart 類型有三種：Multipart/Mixed, Multipart/Related 和 Multipart/Alternative。如果郵件中要添加附件，而且附件之間有相互關(guān)聯(lián)關(guān)系，則使用 Multipart/Related。

SOAP 附件標(biāo)準(zhǔn) SwA 只針對 SOAP1.1 版本，其 MIME 類型為 Multipart/Related，表示文檔的多個部分是相關(guān)的，Multipart/Related 報頭的 type 參數(shù)值為”text/xml”。SOAP1.1 消息主體位于 Multipart/Related 結(jié)構(gòu)的第一段，其 Content-Type 的值也為”text/xml”。其余的 MIME 段為 SOAP 附件，附件可以是任意類型數(shù)據(jù)，每個附件 MIME 段由段頭的 Content-ID 或者 Content-Location 唯一標(biāo)識，比較常用的是 Content-ID。

圖 2 為 SwA 規(guī)范下的帶附件 SOAP 報文結(jié)構(gòu)圖。圖中 SOAP 消息由 MIME 頭，一個封裝主體 SOAP1.1 消息的 MIME 段和一個或多個封裝 SOAP 附件的 MIME 段三部分組成。其中每部分以 MIME 邊界分隔，Context-Type 用于指定 MIME 段的數(shù)據(jù)的類型、Content Transfer-encoding 用于指定用于 MIME 段的編碼方式、Content-ID 或者 Content-Location 用于作為該 MIME 部件的標(biāo)識符。

圖 2. SwA 規(guī)范下帶有附件的 SOAP 報文

?

清單 2 是一個基于 SwA 的 SOAP 報文示例。例子中的圖像數(shù)據(jù)在一個 MIME 結(jié)構(gòu)中，通過屬性”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:benz@pictures.soapattach.com”/></Car></soap:Body> </soap:Envelope>--MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <benz@pictures.soapattach.com>...binary JPEG image...--MIME_boundary--

SwA 避免了編碼的開銷和冗余，但是也帶來了一些新的問題。首先，SwA 使用字符串作為 MIME 結(jié)構(gòu)的定界符，為了解析出 MIME 結(jié)構(gòu)，必須遍歷所有數(shù)據(jù)，當(dāng)數(shù)據(jù)量較大時，效率非常低下，當(dāng) MIME 結(jié)構(gòu)中出現(xiàn)和定界字符串相同內(nèi)容的情況時，處理起來更復(fù)雜；其次，通用的 XML 技術(shù)，如 XPath、XQuery、XSLT 以及 XML schema 等，對于 XML 文件中包含的二進(jìn)制內(nèi)容無法處理，因而也無法對符合 SwA 的 SOAP 報文使用各種通用的 XML 技術(shù)進(jìn)行處理。盡管程序知道附件數(shù)據(jù)的存在，但是文檔自身并不知道，另外，不同的 SOAP 報文處理器，以及 SOAP 消息和 WSDL 之間存在大量的互操作性問題。在 Web 服務(wù)互操作性組織 WS-I 的官方網(wǎng)站上可以找到其所總結(jié)的各種 Web Service 互操作性問題的詳細(xì)信息。

在 SwA 的具體實現(xiàn)中，涉及到三種主要的 API：SAAJ (SOAP with Attachments API for Java), JAXM (Java API for XML messaging), JAX-RPC。這三種 API 都是 JCP 所制定的 Web Service 的 Java 實現(xiàn)標(biāo)準(zhǔn)。SAAJ 是實現(xiàn) SwA 規(guī)范的 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 格式進(jìn)行異步傳送的 API。JAXM 客戶端使用 SAAJ 來構(gòu)造和解析 SOAP 消息。JAX-RPC 依賴于 SAAJ，提供了 RPC 方式 Web 服務(wù)實現(xiàn)，定義了三種客戶端編程模型：Generated Stub、Dynamic Proxy 和 Dynamic Invocation Interface。

---

DIME 與 WS-Attachments

為了解決 SwA 的效率低下問題，2002 年 7 月，IBM 和微軟向 IETF 提交了直接因特網(wǎng)消息封裝提議 (DIME: Direct Internet Message Encapsulation)，以及相應(yīng)的 WS-Attachments 規(guī)范，使用 DIME 和 WS-Attachments 對 SOAP 消息附件進(jìn)行封裝。

DIME 是一個輕量級二進(jìn)制消息格式，能夠?qū)⑷我飧袷綌?shù)據(jù)的多個記錄序依次序列化為流，使用有效的二進(jìn)制標(biāo)頭進(jìn)行說明。

DIME 記錄標(biāo)頭包含 DIME 版本、數(shù)據(jù)的類型信息、唯一標(biāo)識每個記錄的 ID、數(shù)據(jù)長度信息以及可選信息等。DIME 消息的第一個記錄在標(biāo)頭中設(shè)置了消息開始標(biāo)志 MB，最后一個記錄設(shè)置了消息結(jié)束標(biāo)志 ME。MB 和 ME 標(biāo)志均是一個 1 位字段，當(dāng)被置位時，分別表明 DIME 消息的開始和結(jié)束。對于較大的記錄或最初不知道數(shù)據(jù)大小的記錄，DIME 定義了“記錄區(qū)塊”，使用記錄區(qū)塊將單個記錄分解成多個塊。記錄區(qū)塊在標(biāo)頭中設(shè)置了區(qū)塊標(biāo)志 CF，表明該數(shù)據(jù)是分塊記錄的一部分，并且其后包含更多的數(shù)據(jù)。

數(shù)據(jù)字段攜帶 DIME 用戶應(yīng)用程序的有效負(fù)載。數(shù)據(jù)字段內(nèi)攜帶的數(shù)據(jù)的內(nèi)部結(jié)構(gòu)對 DIME 是不透明的。數(shù)據(jù)字段的長度必須是 4 個 8bit 數(shù)據(jù)的倍數(shù)。如果有效負(fù)載的長度不是 4 個 8bit 數(shù)據(jù)的倍數(shù)，那么用全零 8bit 數(shù)據(jù)填充。填充部分并不算在數(shù)據(jù)長度字段中，并且絕不可以用超過 3 個 8bit 數(shù)據(jù)填充數(shù)據(jù)字段。圖 3 為 DIME 數(shù)據(jù)記錄格式

圖 3. DIME 數(shù)據(jù)記錄格式

DIME 根據(jù)某個記錄的開始位置，可以輕松地定位到下一個記錄的位置，只需將標(biāo)頭固定區(qū)域的長度與可選數(shù)據(jù)、ID、類型和數(shù)據(jù)部分的長度相加。這種以高效方式確定記錄長度對于在流的記錄之間快速移動十分重要。

DIME 本身只是一種用來對任意格式的數(shù)據(jù)記錄集合進(jìn)行打包的機制。它對于記錄有效負(fù)載的內(nèi)容、ID 字段中包含的內(nèi)容或者如何將 SOAP 消息封裝到 DIME 消息中等沒有任何要求。DIME 的記錄內(nèi)容沒有任何限制，其有效負(fù)載甚至可以包含其他 DIME 消息，只需將該記錄的類型設(shè)置為“application/dime”。

WS-Attachments 定義了如何使用 DIME 數(shù)據(jù)包發(fā)送包含附件的 SOAP 消息，標(biāo)識了 DIME 消息中哪些是 SOAP 消息，哪些是附件。對于包含附件的 SOAP 消息，將主要消息稱為“主 SOAP 消息部分”，將附加的部分稱為“從屬部分”。WS-Attachments 要求主 SOAP 消息部分必須包含在 DIME 消息的第一個記錄中，主 SOAP 消息部分通過使用 href 屬性引用附件，其值為 HTTP URL。此外，WS-Attachments 還說明了如何使用 DIME 記錄標(biāo)頭的 ID 字段引用特定的 DIME 記錄。

清單 3 是一個基于 WS-Attachments 的 SOAP 報文，其中 DIME 消息的從屬部分的 ID 為 uuid：6FF57555-8750-4555-8237-95ELIWEK87B4F，引用了此類附件的主 SOAP 消息部分的代碼如下所示：

清單 3. 基于 WS-Attachments 規(guī)范的 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 記錄中的數(shù)據(jù)可能是此消息所響應(yīng)的另一個 SOAP 消息，此時 DIME 消息的接收方可以從 DIME 消息指定的從屬部分中找到該消息。WS-Attachments 不但可以從主 SOAP 消息部分中引用 DIME 消息的從屬部分，也可以從從屬部分中進(jìn)行類似引用，這樣兩個從屬部分就可以相互引用，甚至一個從屬部分還可以引用主 SOAP 消息部分。

WS-Attachments 還說明了如何在 HTTP 請求中發(fā)送復(fù)合 SOAP 消息。這種情況下，HTTP 的 Content-Type 標(biāo)頭必須設(shè)為“application/dime”，HTTP 請求的正文為 DIME 消息而不是 SOAP 消息。

盡管 DIME 解決了 SwA 中遍歷定界符導(dǎo)致的效率低下問題， DIME 強迫開發(fā)者從 MIME 完全轉(zhuǎn)向 DIME，最后導(dǎo)致 DIME 和 WS-Attachments 并沒有得到廣泛應(yīng)用。

---

PASwA, XOP 和 MTOM

為了解決 SwA 導(dǎo)致的互操作性問題，2003 年 4 月 Microsoft, BEA, Canon, SAP 和 Tibco 等公司提出了規(guī)范 Proposed Infoset Addendum to SOAP Messages with Attachments (PASwA)。PASwA 基于 SwA 規(guī)范，是對 SwA 規(guī)范的補充。

PASwA 一個重要目標(biāo)是使 XML Infoset 具有一個統(tǒng)一的邏輯視圖，而不需要對由于 XML 中包含二進(jìn)制數(shù)據(jù)，SwA 和 WSDL 之間的互操作性等問題而另外處理。XML Infoset 定義了一種抽象的方式，把 XML 文檔描述為一系列信息項，為需要引用 XML 文檔中的信息的規(guī)范提供了一致的定義。

PASwA 主要增加了如下內(nèi)容：

• xmime:mediaType 屬性：用于指明 XML 文件中 base64 編碼部分的媒體類型，例如 xmime:mediaType 的值可以為 image/png，audio/mpeg，application/pkcs7-signature 等，這些值在 RFC 2045 和 RFC 2046 指定
• xmime:Binary 類型：基于 xs:base64Binary 的復(fù)合類型，xmime:mediaType 為其可選屬性
• Swa:Accept 屬性：用于申明其所支持的媒體類型，主要用于 WSDL 中
• 帶有 herf 屬性的 xbinc:Include 元素：在 SOAP 消息中鏈接到相關(guān)的附件數(shù)據(jù)
• 在 SOAP 消息頭中增加了 xbinc:DoInclude 和 swa:Representation 塊：xbinc:DoInclude 用于表示 SOAP 報文中包含 xbinc:Include 元素，SOAP 消息處理器應(yīng)該特殊處理；swa:Representation 表示允許 SOAP 節(jié)點發(fā)送緩存的 Web 資源

盡管 PASwA 并沒有被 W3C 所采納，然而，PASwA 直接導(dǎo)致了 W3C 的 XML 二進(jìn)制優(yōu)化打包 (XOP: XML-binary Optimized Packaging) 和 SOAP 消息傳輸優(yōu)化機制 (MTOM: Message Transmission Optimization Mechanism) 規(guī)范的產(chǎn)生。

XOP 使用 MIME 將原始二進(jìn)制數(shù)據(jù)引入到 XML 1.0 文檔中。XOP 是 XML 的可選序列化方法，在 XOP 數(shù)據(jù)包里，被命名為 base64 字符串的事物都可以作為其附件，方法與 SwA 類似。所不同的是：數(shù)據(jù)和附件之間的鏈接不是依靠應(yīng)用程序進(jìn)行處理，而是由該格式自行處理。XOP 使用 xop:Include 元素顯式地將內(nèi)容與附件關(guān)聯(lián)起來，并避免了 SwA 中存在的歧義性。

在 XOP 規(guī)范中主要有如下基本元素：Original XML Infoset，Optimized Content，XOP Infoset，XOP Document，XOP Package 和 Reconstituted XML Infoset。其定義如下：

• Original XML Infoset 是需要被優(yōu)化的原始 XML Infoset
• Optimized Content 是原始 XML Infoset 中需要被優(yōu)化的內(nèi)容
• XOP Infoset 是使用 xop:Include 元素替換掉原來 XML Infoset 中的相應(yīng)信息得到的新的 XML Infoset
• XOP Document 是符合 W3C recommendation 規(guī)范序列化后的 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 參數(shù)總是等于主體 SOAP 消息的 Content-Type 的值，也就是 application/xop+xml；主體 SOAP 消息部分，用于存儲 XOP Infoset 格式的 SOAP Envelop；附件部分，用于存儲二進(jìn)制或者非二進(jìn)制附件數(shù)據(jù)。

清單 4 為原始 XML Infoset，其中 attach:Car 元素為原始 XML Infoset 中需要被優(yōu)化的內(nèi)容。清單 5 為序列化后的 XOP 包，該 XOP 包中只含有一個附件數(shù)據(jù)。

清單 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="<paper@example.cn>"; start-info="application/xop+xml"--MIME_boundary Content-Type: application/xop+xml; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-ID: <paper@example.cn><?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:Eric@pictures.example.com"/></attach:Picture></attach:Car></soap:Body> </soap:Envelope>--MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <Eric@pictures.example.com>...binary JPEG image...--MIME_boundary--

在 SOAP 消息構(gòu)造和傳輸中使用 XOP 的過程稱為 MTOM。MTOM 的目的在于優(yōu)化 base64 編碼數(shù)據(jù)的傳輸。只有具有 xs:base64Binary 標(biāo)準(zhǔn)格式的字符組成的節(jié)點才可以被優(yōu)化。使用 MTOM，SOAP 消息包以 XOP 消息包的格式傳輸。

此外，為了解決 SwA 導(dǎo)致的互操作性問題，與 PASwA 和 MTOM 同時進(jìn)行的，還有 WS-I 的附件概要規(guī)范。2004 年 8 月 24 日，WS-I 推出了附件概要 AP1.0 (Attachment Profile Version 1.0) 規(guī)范，用以解決 SOAP 消息和基于附件的 Web 服務(wù)之間的互操作性問題，最新版為 2006 年 4 月 20 日發(fā)布的 AP1.0 第二版。AP1.0 和 WS-I 的另一規(guī)范，簡單 SOAP 綁定概要 SSBP1.0 (Simple SOAP Binding Profile 1.0)，構(gòu)成了 WS-I 的基本概要 BP1.1(Basic Profile Version 1.1) 的補充規(guī)范。由于 AP1.0 和 PASwA 以及 MTOM 的沖突，很多開發(fā)者并沒有采用 AP1.0，而是直接轉(zhuǎn)向 MTOM。

在 JAX-RPC1.1 中，提供了對 BP1.0 的支持，JAX-WS2.0 已經(jīng)提供或者即將提供對 BP1.1, AP1.0, SSBP1.0, XOP 以及 MTOM 的支持。

目前，IBM WebSphere 產(chǎn)品已經(jīng)提供了對 MTOM 和 XOP 的支持，在其最新發(fā)布 WebSphere Application Server Feature Pack for Web Services 中可以找到相應(yīng)實現(xiàn)，用戶只需安裝 WAS 6.1 feature pack for Web Services，關(guān)于 IBM 對 MTOM 更詳細(xì)的實現(xiàn)信息可見參考資料中的 WAS6.1 專門針對 Web Service 包的介紹。

---

總結(jié)

隨著 Web Service 技術(shù)的廣泛采用，對其附件技術(shù)的要求也越來越高，先后出現(xiàn)了 SwA, DIME, WS-Attachments, AP1.0, PASwA, XOP, MTOM 等規(guī)范。其中，DIME, WS-Attachments 已經(jīng)基本被淘汰了；目前使用比較廣泛的是 SwA 和 AP1.0，其缺點是存在大量的互操作性問題和效率問題；XOP 和 MTOM 提供了一種通用和高效的機制，其相應(yīng)規(guī)范仍在完善中，隨著其推廣應(yīng)用相信今后必將被廣泛采用。

---

參考資料

• “SOAP Specifications”：W3C 上 SOAP1.1 和 SOAP1.2 規(guī)范的鏈接
• “SOAP Optimized Serialization Use Cases and Requirements”：了解 SOAP 優(yōu)化的需求和應(yīng)用場景
• “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”：MIME 第一部分：因特網(wǎng)消息格式
• “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”：MIME 第二部分：媒體類型
• “W3C XML Schema Part 2: Datatypes”：XML Schema 定義的數(shù)據(jù)類型，可以作為 SOAP 消息中的數(shù)據(jù)類型
• “SOAP Messages with Attachments”：SOAP 消息附件規(guī)范
• “直接因特網(wǎng)消息封裝 (Direct Internet Message Encapsulation)”：了解 DIME 更詳細(xì)的信息
• “XML-binary Optimized Packaging”：XML 二進(jìn)制優(yōu)化打包規(guī)范
• “SOAP Message Transmission Optimization Mechanism”：SOAP 消息傳輸優(yōu)化機制規(guī)范
• “Basic Profile Version 1.0”，“Basic Profile Version 1.1”，“Attachments Profile Version 1.0”，“Simple SOAP Binding Profile 1.0”：WS-I 的基本概要 1.0，基本概要 1.1，附件概要 1.0 以及簡單 SOAP 綁定概要 1.0
• “JavaTM APIs for XML based RPC”，“JavaTM API for XML-Based Web Services (JAX-WS) 2.0”，“JAX-RPC 與 JAX-WS 的比較”：JCP 提供的針對 Web Service 的 Java API
• “Info Center of WAS Feature Pack for Web Services”：詳細(xì)介紹 IBM WebSphere Application Server6.1 針對 Web Service 的包，其中包含對 MTOM 和 XOP 的支持
• “使用 XML 二進(jìn)制優(yōu)化打包規(guī)范加速 Web 服務(wù)應(yīng)用程序”，“使用 WebSphere Business Modeler 和 Rational Web Developer for WebSphere 將基于 XOP 的 Web 服務(wù)連接到外部服務(wù)”：了解 developworks 上其他關(guān)于使用 IBM 產(chǎn)品進(jìn)行 XML 優(yōu)化打包的方法

?

完。

?

轉(zhuǎn)載于:https://www.cnblogs.com/liyou-blog/p/4177872.html

總結(jié)

以上是生活随笔為你收集整理的Web Service 附件技术的发展及演变的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。