Web Service 附件技术的发展及演变
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: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 結構的定界符，為了解析出 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="<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 消息構造和傳輸中使用 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 提供了一種通用和高效的機制，其相應規范仍在完善中，隨著其推廣應用相信今后必將被廣泛采用。
參考資料
- “SOAP Specifications”：W3C 上 SOAP1.1 和 SOAP1.2 規范的鏈接
- “SOAP Optimized Serialization Use Cases and Requirements”：了解 SOAP 優化的需求和應用場景
- “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”：MIME 第一部分：因特網消息格式
- “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”：MIME 第二部分：媒體類型
- “W3C XML Schema Part 2: Datatypes”：XML Schema 定義的數據類型，可以作為 SOAP 消息中的數據類型
- “SOAP Messages with Attachments”：SOAP 消息附件規范
- “直接因特網消息封裝 (Direct Internet Message Encapsulation)”：了解 DIME 更詳細的信息
- “XML-binary Optimized Packaging”：XML 二進制優化打包規范
- “SOAP Message Transmission Optimization Mechanism”：SOAP 消息傳輸優化機制規范
- “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”：詳細介紹 IBM WebSphere Application Server6.1 針對 Web Service 的包，其中包含對 MTOM 和 XOP 的支持
- “使用 XML 二進制優化打包規范加速 Web 服務應用程序”，“使用 WebSphere Business Modeler 和 Rational Web Developer for WebSphere 將基于 XOP 的 Web 服務連接到外部服務”：了解 developworks 上其他關于使用 IBM 產品進行 XML 優化打包的方法
?
完。
?
轉載于:https://www.cnblogs.com/liyou-blog/p/4177872.html
總結
以上是生活随笔為你收集整理的Web Service 附件技术的发展及演变的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Redis站点流量统计HyperLogL
- 下一篇： 系统架构