原文：http://hi.baidu.com/zbzb/blog/item/903796237fc74b41ac34de65.html
Apache Axis2 Web 服務(wù)框架構(gòu)建于新的 AXIOM XML 文檔模型之上，可以進行高效的 SOAP 消息處理。與常規(guī)的文檔模型不同，AXIOM 僅在被訪問時才會在內(nèi)存中構(gòu)建文檔表示。了解為什么這種按需構(gòu)造的方法對于 SOAP 處理來說非常合適，以及為什么 XOP/MTOM 附件、數(shù)據(jù)綁定和性能非常適于這種情況。
為什么需要另一種文檔模型？

Apache Axis2 1.1 已經(jīng)發(fā)布，它為那些長期運行 Apache Web 服務(wù)框架系列的忠實用戶提供了令人興奮的新特性。我們將在后續(xù)的文章中討論關(guān)于 Axis2 的內(nèi)容，本文將深入研究 AXIs 對象模型 (AXIOM) XML 文檔模型，這是 Axis2 的核心。AXIOM 是 Axis2 中一個主要的創(chuàng)新，并且是 Axis2 能夠比原來的 Axis 提供更好性能的原因之一。本文將向您介紹 AXIOM 的工作原理、Axis2 的各個部分如何構(gòu)建于 AXIOM 之上，以及 AXIOM 與其他的 Java? 文檔對象模型的性能比較。

文檔模型通常用于對 XML 進行處理，并且在 Java 開發(fā)中有許多不同的文檔模型可供使用，包括原始 W3C DOM 規(guī)范的各種實現(xiàn)、JDOM、dom4j、XOM 等等。每種模型都聲稱與其他模型相比具有某些優(yōu)點，要么是在性能、靈活性方面，要么是在嚴格遵守 XML 標準的程度方面，并且每種模型都擁有忠實的支持者。那么，Axis2 為什么需要一種新的模型呢？答案在于 SOAP 消息的結(jié)構(gòu)，尤其是如何在基本的 SOAP 框架中添加相應(yīng)的擴展。

SOAP 簡介

SOAP 本身僅僅只是 XML 應(yīng)用程序負載的簡單包裝。清單 1 提供了一個示例，其中只有那些具有 soapenv 前綴的元素才真正是 SOAP 中定義的。文檔中大部分是應(yīng)用程序數(shù)據(jù)，這些數(shù)據(jù)組成了 soapenv:Body 元素的內(nèi)容。

清單 1. SOAP 示例:

?

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">? <soapenv:Header/>? <soapenv:Body>??? <matchQuakes xmlns="http://seismic.sosnoski.com/types">?????

<min-date>2001-01-06T11:10:43.446Z</min-date>?????

<max-date>2001-10-24T19:49:13.812Z</max-date>?????

<min-long>-150.94307</min-long>?????

?<max-long>-22.594208</max-long>?????

<min-lat>-11.44651</min-lat>?????

<max-lat>55.089058</max-lat>??? </matchQuakes>?

</soapenv:Body></soapenv:Envelope>

?

?

?

?

盡管基本的 SOAP 包裝非常簡單，但是通過使用稱為 Header 的可選組件，它提供了不受限制的擴展能力。Header 為添加各種各樣的元數(shù)據(jù)提供了合適的位置，這些元數(shù)據(jù)與應(yīng)用程序數(shù)據(jù)在一起，不會被應(yīng)用程序看到（可以 在 Header 中包括應(yīng)用程序數(shù)據(jù)，但是這樣做并不是很合理，您應(yīng)該將應(yīng)用程序數(shù)據(jù)放在消息的正文部分）。構(gòu)建于 SOAP 之上的擴展（如整個 WS-* 系列），可以使用 Header 實現(xiàn)相應(yīng)的目標，而不會對應(yīng)用程序造成任何影響。這允許將擴展作為外接程序使用，可以在部署時選擇某個應(yīng)用程序所需的特定擴展功能，而無需在代碼中對其進 行處理。

清單 2 顯示了與清單 1 SOAP 示例相同的應(yīng)用程序數(shù)據(jù)，但其中包括 WS-Addressing 信息。盡管原始的 SOAP 消息只能用于 HTTP 傳輸（因為 HTTP 提供了雙向的連接，使得響應(yīng)可以立即發(fā)送回客戶端），但清單 2 中的版本可以用于其他協(xié)議，因為 SOAP 請求消息中直接包括了響應(yīng)元數(shù)據(jù)。在對清單 2 的消息進行處理的過程中，甚至可以進行存儲轉(zhuǎn)發(fā)操作，因為這些元數(shù)據(jù)同時提供了請求目標和響應(yīng)目標信息。


清單 2. 使用 WS-Addressing 的 SOAP 示例

?

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"??? xmlns:wsa="http://www.w3.org/2005/08/addressing">? <soapenv:Header>??? <wsa:To>http://localhost:8800/axis2/services/SeisAxis2XBean</wsa:To>??? <wsa:ReplyTo>????? <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>??? </wsa:ReplyTo>??? <wsa:MessageID>urn:uuid:97AE2B17231A8584D811537402403691</wsa:MessageID>? </soapenv:Header>? <soapenv:Body>??? <matchQuakes xmlns="http://seismic.sosnoski.com/types">????? <min-date>2000-03-28T13:13:08.953Z</min-date>????? <max-date>2001-03-11T02:26:54.283Z</max-date>????? <min-long>-81.532234</min-long>????? <max-long>65.25895</max-long>????? <min-lat>-14.234512</min-lat>????? <max-lat>57.174187</max-lat>??? </matchQuakes>? </soapenv:Body></soapenv:Envelope>
?

?

文檔模型面臨的一個進退兩難的問題

因 為 SOAP Header 的關(guān)鍵思想是允許在消息中添加任何元數(shù)據(jù)，所以 SOAP 框架必須能夠接受某些擴展需要添加的任何內(nèi)容。一般來說，處理任意的 XML 的最簡單方法是使用某種形式的文檔模型。這正是文檔模型的任務(wù)所在，即不對該 XML 的形式進行任何假設(shè)，如實地表示 XML。

但 是對于處理在不同應(yīng)用程序之間進行數(shù)據(jù)交換時所使用的 XML 來說，文檔模型并不是一種非常高效的方法。通常，應(yīng)用程序數(shù)據(jù)具有預(yù)定義的結(jié)構(gòu)，并且大多數(shù)開發(fā)人員更傾向于以數(shù)據(jù)對象而不是原始的 XML 的形式對這些數(shù)據(jù)進行處理。數(shù)據(jù)對象和 XML 之間的轉(zhuǎn)換任務(wù)由數(shù)據(jù)綁定負責(zé)完成。與使用文檔模型相比，數(shù)據(jù)綁定為開發(fā)人員帶來了更大的方便，同時，它在性能和內(nèi)存使用方面的效率也更高。

所 以，大多數(shù)應(yīng)用程序希望使用數(shù)據(jù)綁定來處理 SOAP 消息的應(yīng)用程序負載，但是對于處理 Header 中的元數(shù)據(jù)，使用文檔模型的方法更合適。理想的方法是在 SOAP 框架中同時使用這兩種技術(shù)，但普通的文檔模型不支持這種用法。它們希望處理整個文檔，或者至少是文檔中一個完整的子樹。它們無法處理文檔中所選的部分，但 這是處理 SOAP 的最合適的方式。

以拉方式構(gòu)建 AXIOM 樹

除 了 AXIOM 之外，Axis2 還對 Axis 進行了另一個改進。原始的 Axis 使用標準的推式 (SAX) 解析器進行 XML 處理，而 Axis2 使用拉式 (StAX) 解析器。在使用推方式的情況下，由解析器來控制解析操作，需要向解析器提供要解析的文檔和處理程序。然后，在對輸入文檔進行處理的時候，它使用代碼中的處 理程序作為回調(diào)。處理程序代碼可以使用這些回調(diào)中傳遞的信息，但是不能影響解析過程（除了引發(fā)一個異常）。相反，在使用拉方式的情況下，解析器實際上是一 個高效的迭代器，可以根據(jù)需要對文檔中的不同部分進行遍歷。

推方式和拉方式分別具有各自的用途，但是對于處理包含邏輯上獨立的不同部分的 XML（如 SOAP），使用拉方式更有優(yōu)勢。。使用拉式解析器，處理文檔某一部分的代碼僅解析它所需的部分，然后由解析器進行接下來的文檔處理。

AXIOM 構(gòu)建于 StAX 拉式解析器接口的基礎(chǔ)之上。AXIOM 提供了一種可以按需擴展的虛擬文檔模型，僅構(gòu)建客戶端應(yīng)用程序所請求的樹結(jié)構(gòu)文檔模型表示。這種虛擬的文檔模型工作于 XML 文檔的元素級。當(dāng)解析器報告元素開始標記時創(chuàng)建元素表示，但是該元素的初始形式僅僅只是一個殼，其中保存了對解析器的引用。如果應(yīng)用程序需要獲取元素內(nèi)容 的細節(jié)信息，它只需要通過調(diào)用接口（如 org.apache.axiom.om.OMContainer.getChildren() 方法）的方法，就可以請求相應(yīng)的信息。然后，在對這個方法調(diào)用的響應(yīng)中，解析器將構(gòu)建該元素的子內(nèi)容。

因 為解析器按照文檔順序（與 XML 文檔文本中項目的出現(xiàn)順序相同）傳遞數(shù)據(jù)，所以 AXIOM 所實現(xiàn)的按需構(gòu)造需要某種靈活的處理方法。例如，通常有多個元素處于不完整的（正在構(gòu)建的過程中）狀態(tài)，但是這些元素都必須位于繼承結(jié)構(gòu)的一條直線中。如 果從根元素在頂端的標準 XML 樹關(guān)系圖的角度來看，不完整的元素將始終位于該樹右側(cè)的直線中。隨著應(yīng)用程序請求更多的數(shù)據(jù)，該樹逐漸向右擴充，并且首先完成頂端的元素。





回頁首

?

使用 AXIOM

就 所提供的 API 而言，所有的 XML 文檔模型都具有很多相同之處（這并不奇怪，因為它們都需要處理相同的基礎(chǔ)數(shù)據(jù)），但是與其他的文檔模型相比，它們又各有千秋。原始的 W3C 文檔對象模型 (DOM) 設(shè)計提供跨語言和跨平臺的兼容性，所以構(gòu)建于各種接口之上，并且在其自身的版本中避免使用 Java 特定的集合。JDOM 使用了具體類而不是接口，并且在這種 API 中集成了標準的 Java 集合類，許多 Java 開發(fā)人員認為它比 DOM 更友好。dom4j 將類似 DOM 的接口和 Java 集合類組合到一起，這種非常靈活的 API 提供了很多強大的功能，但卻在一定的程度上增加了復(fù)雜性。

AXIOM 與其他文檔模型有許多相似之處。它還具有一些與其按需構(gòu)建的處理過程相關(guān)的顯著特征，以及支持其用于 Web 服務(wù)的專門特性。

實際應(yīng)用中的 AXIOM

從整體上看，AXIOM 的 API 可能最接近于 DOM，但是它又具有自己的特點。例如，訪問方法以使用 java.util.Iterator 實例為基礎(chǔ)對不同的部分（如通過 org.apache.axiom.om.OMContainer.getChildren() 以及相關(guān)方法所返回的部分）進行訪問，而沒有使用任何形式的列表。沒有將不同的部分索引為列表，導(dǎo)航使用 org.apache.axiom.om.OMNode.getNextOMSibling() 和 org.apache.axiom.om.OMNode.getPreviousOMSibling() 方法，以便按順序遍歷文檔樹中同一個級別的節(jié)點（在這方面，它類似于 DOM）。這種訪問和導(dǎo)航方法的結(jié)構(gòu)與按需構(gòu)建樹的工作方式非常吻合，因為這意味著 AXIOM 可以允許您移動到開始元素的第一個子項，而無需首先處理所有的 子元素。

與 DOM 和 dom4j 一樣，AXIOM 使用接口定義了用于訪問和操作樹表示的 API。AXIOM 分發(fā)版中包括這些接口的幾種不同的專門實現(xiàn)。其中一種實現(xiàn)（在 org.apache.axiom.om.impl.dom 包中）是雙重功能的，使用相同的實現(xiàn)類同時支持 AXIOM 和 DOM 接口。因為需要使用數(shù)據(jù)的 DOM 視圖的 Web 服務(wù)外接程序的數(shù)目較多，所以這種實現(xiàn)可能很有價值。有關(guān)更一般的用法，org.apache.axiom.om.impl.llom 包提供了一種基于對象鏈表的實現(xiàn)（包名中的“l(fā)l”表示鏈表 (linked list)）。還對基本的 org.apache.axiom.om 接口和 org.apache.axiom.soap 包樹中的實現(xiàn)進行了擴展，后者專門用于處理 SOAP 消息。

為 了簡要地了解實際應(yīng)用中的 AXIOM API，我們將對一些示例進行研究，這些示例來自于對 AXIOM 與其他的文檔模型進行性能測試對比的代碼。清單 3 中提供了第一個示例，這個示例基于為輸入文檔構(gòu)建 AXIOM 表示的代碼。與使用 DOM 和 dom4j 一樣，在使用 AXIOM 進行任何工作之前，您需要獲得一個構(gòu)建模型組件對象的工廠。通過使用 org.apache.axiom.org.OMFactory 接口的 org.apache.axiom.om.impl.llom.factory.OMLinkedListImplFactory 實現(xiàn)，清單 3 中的代碼選擇了 AXIOM 接口的基本鏈表實現(xiàn)。這個工廠接口包括用于從各種來源直接構(gòu)建文檔的方法、用于創(chuàng)建 XML 文檔表示的不同部分的方法。清單 3 使用了相應(yīng)的方法從輸入流構(gòu)建文檔。build() 方法返回的對象實際上是 org.apache.axiom.om.OMDocument 的實例，盡管在這段代碼中沒有指明。


清單 3. 將文檔解析為 AXIOM

?

?

import org.apache.axiom.om.*;import org.apache.axiom.om.impl.builder.StAXOMBuilder;import org.apache.axiom.om.impl.llom.factory.OMLinkedListImplFactory;??? ...??? private XMLInputFactory m_parserFactory = XMLInputFactory.newInstance();??? private OMFactory m_factory = new OMLinkedListImplFactory();??? ...??? protected Object build(InputStream in) {??????? Object doc = null;??????? try {??????????? XMLStreamReader reader = m_parserFactory.createXMLStreamReader(in);??????????? StAXOMBuilder builder = new StAXOMBuilder(m_axiomFactory, reader);??????????? doc = builder.getDocument();??????? } catch (Exception ex) {??????????? ex.printStackTrace(System.out);??????????? System.exit(0);??????? }??????? return doc;??? }

?

?

清單 3 使用了 org.apache.axiom.om.impl.builder.StAXOMBuilder 類通過解析輸入流來構(gòu)建文檔表示。這段代碼在返回之前僅創(chuàng)建了 StAX 解析器實例和基本文檔結(jié)構(gòu)，并使得解析器定位到文檔的根元素，如果需要，稍后再構(gòu)建文檔表示的其他部分。并不一定 必須使用 StAX 解析器來構(gòu)建 AXIOM。事實上，org.apache.axiom.om.impl.builder.SAXOMBuilder 是基于 SAX 推式解析器的構(gòu)建程序的部分實現(xiàn)。但如果您使用其他方法來構(gòu)建它，那么就無法利用按需構(gòu)造所帶來的優(yōu)點。

清單 4 提供了用于遍歷文檔表示中的元素并累計摘要信息（元素的計數(shù)，屬性值文本的計數(shù)和總長度，以及文本內(nèi)容的計數(shù)和總長度）的代碼。底部的 walk() 方法接受需要進行匯總的文檔以及摘要數(shù)據(jù)結(jié)構(gòu)作為參數(shù)，而頂部的 walkElement() 方法則處理一個元素（遞歸地調(diào)用自己以便對子元素進行處理）。


清單 4. 導(dǎo)航 AXIOM

? /**???? * Walk subtree for element. This recursively walks through the document???? * nodes under an element, accumulating summary information.???? *???? * @param element element to be walked???? * @param summary document summary information???? */??? protected void walkElement(OMElement element, DocumentSummary summary) {??????? // include attribute values in summary??????? for (Iterator iter = element.getAllAttributes(); iter.hasNext();) {??????????? OMAttribute attr = (OMAttribute)iter.next();??????????? summary.addAttribute(attr.getAttributeValue().length());??????? }??????? // loop through children??????? for (Iterator iter = element.getChildren(); iter.hasNext();) {??????????? // handle child by type??????????? OMNode child = (OMNode)iter.next();??????????? int type = child.getType();??????????? if (type == OMNode.TEXT_NODE) {??????????????? summary.addContent(((OMText)child).getText().length());??????????? } else if (type == OMNode.ELEMENT_NODE) {??????????????? summary.addElements(1);??????????????? walkElement((OMElement)child, summary);??????????? }??????? }??? }??? /**???? * Walk and summarize document. This method walks through the nodes???? * of the document, accumulating summary information.???? *???? * @param doc document representation to be walked???? * @param summary output document summary information???? */??? protected void walk(Object doc, DocumentSummary summary) {??????? summary.addElements(1);??????? walkElement(((OMDocument)doc).getOMDocumentElement(), summary);??? }
?

?

最后，清單 5 給出了用于將該文檔表示轉(zhuǎn)換為輸出流的代碼。作為 OMNode 接口的一部分，AXIOM 定義了許多輸出方法，包括針對各種不同的目標（如輸出流、普通字符寫入程序、或 StAX 流寫入程序），帶和不帶格式信息，帶和不帶在寫入之后訪問文檔表示的功能（如果尚未構(gòu)建，這需要構(gòu)建完整的表示）。通過從元素中獲得 StAX 解析器，OMElement 接口定義了另一種訪問文檔信息的方法。這種使用解析器從文檔表示中提取 XML 的能力提供了很好的對稱性，當(dāng)按需構(gòu)建 AXIOM 表示時，這種方式非常合適（因為可以直接返回用于構(gòu)建該表示的解析器）。


清單 5. 從 AXIOM 寫入文檔

?

?

?? /**???? * Output a document as XML text.???? *???? * @param doc document representation to be output???? * @param out XML document output stream???? */??? protected void output(Object doc, OutputStream out) {??????? try {??????????? ((OMDocument)doc).serializeAndConsume(out);??????? } catch (Exception ex) {??????????? ex.printStackTrace(System.err);??????????? System.exit(0);??????? }??? }
?

?

?

AXIOM 為修改現(xiàn)有的文檔部分提供了一些基本的方法（如 OMElement.setText() 可用于將元素的內(nèi)容設(shè)置為一個文本值）。如果您正從頭開始寫入文檔，那么需要直接創(chuàng)建組件的新實例。因為 AXIOM API 是基于接口的，所以它使用各種工廠來創(chuàng)建不同部分的具體實現(xiàn)。

有關(guān) AXIOM API 的更詳細信息，請參見參考資料部分提供的 AXIOM 教程和 JavaDoc 鏈接。

AXIOM 中的 MTOM

AXIOM 的最有趣的特性之一是，它對 SOAP 附件最新版本中所使用的 W3C XOP 和 MTOM 標準提供了內(nèi)置的支持。這兩種標準協(xié)同工作，其中 XOP（XML 二進制優(yōu)化打包，XML-binary Optimized Packaging）提供了一種方式，使得 XML 文檔在邏輯上可以包含任意二進制數(shù)據(jù)的大對象，而 MTOM（SOAP 消息傳輸優(yōu)化機制，SOAP Message Transmission Optimization Mechanism）則將 XOP 技術(shù)應(yīng)用于 SOAP 消息。XOP 和 MTOM 都是新一代 Web 服務(wù)框架的關(guān)鍵特性，因為它們最終提供了可互操作的附件支持以及解決本領(lǐng)域中當(dāng)前問題的能力。

XOP 使用 Base64 編碼的字符數(shù)據(jù)內(nèi)容。通過對原始數(shù)據(jù)中的每六位使用一個 ASCII 字符來表示，Base64 編碼可以將任意的數(shù)據(jù)值轉(zhuǎn)換為可打印的 ASCII 字符。因為二進制數(shù)據(jù)通常不能嵌入到 XML 中（XML 只能處理字符，不能處理原始的字節(jié)，甚至有一些字符編碼也不允許出現(xiàn)在 XML 中），Base64 編碼非常適合于在 XML 消息中嵌入二進制數(shù)據(jù)。

XOP 使用 XOP 命名空間中特殊的“Include”元素來替換 Base64 文本。Include 元素給出了標識單獨實體（在該 XML 文檔之外）的 URI，該實體是希望包括在 XML 文檔中的實際數(shù)據(jù)。通常，這個 URI 將在與 XML 文檔相同的傳輸中標識一個單獨的塊（盡管可以不這樣做，但這樣提供的潛在優(yōu)勢可通過中間層或存儲文檔來交換文檔）。使用對原始數(shù)據(jù)的引用來替換 Base64 文本，可以在一定程度上減小文檔大小（對于普通字符編碼，最多可以減少百分之二十五的大小），并實現(xiàn)更快的處理速度，而無需承擔(dān)對 Base64 數(shù)據(jù)進行編碼和解碼所帶來的開銷。

MTOM 構(gòu)建于 XOP 之上，首先定義了一個抽象的模型，表示如何將 XOP 用于 SOAP 消息，然后對該模型進行特殊化使其專門用于 MIME Multipart/Related 打包，最后將其應(yīng)用于 HTTP 傳輸。通過這些處理，它提供了一種標準的方式，通過廣泛使用的 HTTP 傳輸將 XOP 應(yīng)用于 SOAP 消息。

AXIOM 通過 org.apache.AXIOM.om.OMText 接口以及該接口的實現(xiàn)來支持 XOP/MTOM。OMText 定義了相應(yīng)的方法以支持代表二進制數(shù)據(jù)的文本項目（以 javax.activation.DataHandler 的形式表示，這是 Java Web 服務(wù)框架中用于附件支持的廣泛使用的 Java Activation API 的一部分），以及一個“優(yōu)化”標志用來表示是否可以使用 XOP 對該項目進行處理。org.apache.AXIOM.om.impl.llom.OMTextImpl 實現(xiàn)添加了一個與 MTOM 兼容的內(nèi)容 ID，在創(chuàng)建或自動生成類的實例時，如果尚未設(shè)置，可以對其進行相應(yīng)的設(shè)置。

清單 6 通過一個示例介紹了如何在 AXIOM 中使用 XOP/MTOM 來構(gòu)建消息。這段代碼取自一個性能測試示例，該示例使用 Java 序列化將結(jié)果數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換為一個字節(jié)數(shù)組，然后返回這個數(shù)組作為附件。


清單 6. 創(chuàng)建 XOP/MTOM 消息

?

?

?? public OMElement matchQuakes(OMElement req) {??????? Query query = new Query();??????? Iterator iter = req.getChildElements();??????? try {??????????? ...??????????? // retrieve the matching quakes??????????? Response response = QuakeBase.getInstance().handleQuery(query);??????????????????????? // serialize response to byte array??????????? ByteArrayOutputStream bos = new ByteArrayOutputStream();??????????? ObjectOutputStream oos = new ObjectOutputStream(bos);??????????? oos.writeObject(response);??????????? byte[]byts = bos.toByteArray();??????????????????????? // generate response structure with reference to data??????????? ByteArrayDataSource ds = new ByteArrayDataSource(byts);??????????? OMFactory fac = OMAbstractFactory.getOMFactory();??????????? OMNamespace ns =??????????????? fac.createOMNamespace("http://seismic.sosnoski.com/types", "qk");??????????? OMElement resp = fac.createOMElement("response", ns);??????????? OMText data = fac.createOMText(new DataHandler(ds), true);??????????? resp.addChild(data);??????????? return resp;??????????????????? } catch (ParseException e) {??????????? e.printStackTrace();??????? } catch (IOException e) {??????????? e.printStackTrace();??????? }??????? return null;??? }

?

?

?

盡管清單 6 中的代碼生成了可以使用 XOP/MTOM 發(fā)送的響應(yīng)，但在 Axis2 的當(dāng)前版本中，在缺省情況下 XOP/MTOM 支持處于禁用狀態(tài)。要啟用它，需要在 Axis2 axis2.xml 文件或服務(wù)的 services.xml 文件中包括參數(shù) <parameter name="enableMTOM">true</parameter>。作為即將介紹的性能比較中的一部分，我們將提供這個示例的完整代碼，但現(xiàn)在我們將以一個實際使用 XOP/MTOM 的示例作為結(jié)束。

清單 7 顯示了由清單 6 的服務(wù)所生成的響應(yīng)消息的結(jié)構(gòu)，啟用或沒有啟用 XOP/MTOM（在第一個示例中不包含 MIME Header 和實際的二進制附件，而在第二個示例中刪除了大部分的數(shù)據(jù)）。


清單 7. 帶和不帶 XOP/MTOM 的響應(yīng)消息

?

<?xml version='1.0' encoding='UTF-8'?>? <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">??? <soapenv:Header />??? <soapenv:Body>????? <qk:response xmlns:qk="http://seismic.sosnoski.com/types"????????? xmlns:tns="http://ws.apache.org/axis2">??????? <xop:Include href="cid:1.urn:uuid:966CA4565647BEBA3D115028348657315@apache.org"??????????? xmlns:xop="http://www.w3.org/2004/08/xop/include" />????? </qk:response>??? </soapenv:Body>? </soapenv:Envelope>[actual binary data follows as separate MIME part with referenced content id]<?xml version='1.0' encoding='UTF-8'?>? <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">??? <soapenv:Header />??? <soapenv:Body>????? <qk:response xmlns:qk="http://seismic.sosnoski.com/types"????????? xmlns:tns="http://ws.apache.org/axis2">rO0ABXNyACdjb20uc29zb...</qk:response>??? </soapenv:Body>? </soapenv:Envelope>

?

?

數(shù)據(jù)綁定掛鉤

大 多數(shù) Web 服務(wù)開發(fā)人員需要以 Java 對象而不是 XML 文檔（或者甚至文檔模型，如 AXIOM）的形式使用數(shù)據(jù)。上一代框架，如 Axis 和 JAX-RPC，實現(xiàn)了自己的數(shù)據(jù)綁定，以便在 XML 和 Java 對象之間進行轉(zhuǎn)換，但這是一種非常有限的解決方案。Web 服務(wù)框架中的數(shù)據(jù)綁定實現(xiàn)通常無法與專門的數(shù)據(jù)綁定框架相比，所以希望更好地控制 XML 處理過程的用戶不得不將該框架與低效的轉(zhuǎn)換代碼結(jié)合在一起。因為這些問題，Axis2 重新進行了設(shè)計，以支持使用各種數(shù)據(jù)綁定框架作為數(shù)據(jù)綁定“插件”。

這種數(shù)據(jù)綁定支持使用對 Axis2 中包含的 WSDL2Java 工具的自定義擴展。該工具基于 WSDL 服務(wù)描述為客戶端或服務(wù)器端消息接收者以存根的形式生成 Axis2 連接代碼。客戶端存根可作為代理進行服務(wù)的調(diào)用，它定義了實現(xiàn)服務(wù)操作的方法調(diào)用。服務(wù)器端消息接收者可作為客戶端的代理，調(diào)用實際的用戶定義的服務(wù)方 法。當(dāng)在 WSDL2Java 命令行中請求數(shù)據(jù)綁定時，該工具將調(diào)用指定的數(shù)據(jù)綁定框架擴展，在存根或消息接收者中生成在 OMElement 和 Java 對象之間進行轉(zhuǎn)換的代碼。在使用存根的情況下，在方法調(diào)用中傳遞 Java 對象（或原始值），并將經(jīng)過轉(zhuǎn)換的 XML 作為請求發(fā)送到服務(wù)器。然后將返回的 XML 重新轉(zhuǎn)換為 Java 對象，再將后者作為方法調(diào)用的結(jié)果返回。服務(wù)器端的消息接收者以相反的方式進行轉(zhuǎn)換。

在入站或分解端（將接收到的 XML 轉(zhuǎn)換為 Java 對象），處理過程比較簡單。需要轉(zhuǎn)換為 Java 對象的 XML 文檔負載可以通過 OMElement 的形式獲得，并且數(shù)據(jù)綁定框架只需要處理該元素中的數(shù)據(jù)。OMElement 以 StAX javax.xml.stream.XMLStreamReader 的形式提供了對元素數(shù)據(jù)的訪問，當(dāng)前大多數(shù)的數(shù)據(jù)綁定框架可以直接使用 javax.xml.stream.XMLStreamReader 作為輸入。

出 站或封送端（將 Java 對象轉(zhuǎn)換為傳輸?shù)?XML）的處理稍微復(fù)雜一些。AXIOM 的關(guān)鍵思想是，除非在絕對必要的情況下，否則將避免構(gòu)建完整的 XML 數(shù)據(jù)表示。要在封送時支持這個原則，必須有一種方式使得可以僅在需要的時候調(diào)用數(shù)據(jù)綁定框架。AXIOM 通過使用 org.apache.AXIOM.om.OMDataSource 作為數(shù)據(jù)綁定轉(zhuǎn)換的包裝來處理這個問題。OMDataSource 定義了相應(yīng)的方法，以便使用 AXIOM 所支持的任何方法寫出包裝的內(nèi)容（到 java.io.OutputStream、java.io.Writer 或 StAX javax.xml.stream.XMLStreamWriter），以及為包裝的內(nèi)容返回解析器實例的另一種方法。OMElement 實現(xiàn)可以使用 OMDataSource 的實例按需提供數(shù)據(jù)，而 OMFactory 接口提供了創(chuàng)建這種類型的元素的方法。

?

?

回頁首




性能

我 們將對性能進行簡要的分析，以此總結(jié)關(guān)于 AXIOM 的內(nèi)容。在撰寫這篇文章的時候，AXIOM 1.1 已經(jīng)發(fā)布，這意味著本文中描述的接口應(yīng)該比較穩(wěn)定。另一方面，隨著實際實現(xiàn)代碼的修改，性能總在發(fā)生著變化。與其他的文檔模型相比，我們并不期望 AXIOM 在性能上有什么重大的改進，但是其中的一些具體細節(jié)可能有些差異。

為了將 AXIOM 與其他的文檔模型進行比較，我們對以前的文檔模型研究（請參見參考資料部分）中的代碼進行了更新，添加了 AXIOM 和另一種新的文檔模型 (XOM)，對代碼進行轉(zhuǎn)換使其使用 StAX 解析器標準，而不是較早的 SAX 標準，并切換到使用 Java 5 中引入的改進的 System.nanoTime() 計時方法。性能測試代碼首先將測試中使用到的文檔讀入到內(nèi)存中，然后對文檔進行一系列的操作。首先，使用解析器構(gòu)建文檔表示的某個數(shù)量的副本，并保存每個 結(jié)果文檔對象。接下來，對每個文檔對象進行遍歷，這意味著代碼將掃描整個文檔表示（包括所有的屬性、值和文本內(nèi)容）。最后，將所有的文檔對象寫入到輸出 流。對每項單獨的操作，記錄其時間，并在測試結(jié)束后計算其平均值。

因為 AXIOM（尤其是用于 Axis2 中時）主要關(guān)注于處理 SOAP 消息，所以我們使用了三個不同的 SOAP 消息測試用例來檢查性能。第一個測試用例是一個 Web 服務(wù)性能測試的示例響應(yīng)，該服務(wù)提供了某個時間段和經(jīng)/緯度范圍內(nèi)的地震信息（“quakes”文檔，18 KB）。這個文檔包含許多重復(fù)的元素和一些嵌套的情況，并大量使用了屬性。第二個測試用例是來自 Microsoft WCF 可互操作性測試的一個較大的示例，由單個重復(fù)的結(jié)構(gòu)組成，并且在取值上有一些細微的變化（“persons”文檔，202 KB）。這個文檔具有帶文本內(nèi)容的子元素，但是沒有使用屬性。第三個測試用例是由 30 個較小的 SOAP 消息文檔組成的集合，這些消息來自于一些較早的可互操作性測試（總大小為 19 KB）。從測試文檔中刪除了所有用來進行格式化的空格，以建立真正的生產(chǎn)服務(wù)（通常關(guān)閉格式化，以減少消息的大小）交換使用的 XML 文檔表示。

下 面的圖表顯示了對每個文檔進行 50 次處理所需的平均時間。測試環(huán)境為 Compaq 筆記本系統(tǒng)，1600 MHz ML-30 AMD Turion 處理器和 1.5 GB RAM，在 Mandriva 2006 Linux 上運行 Sun 的 1.5.0_07-b03 JVM。我們測試了 AXIOM 1.0、dom4j 1.6.1、JDOM 1.0、Xerces2 2.7.0 和 Nux 1.6 分發(fā)版中的 XOM。為 dom4j、JDOM 和 Xerces2 使用 StAX 解析器的自定義構(gòu)建程序，而對 XOM 則使用 Nux StAX 解析器構(gòu)建程序。所有的測試都使用了 Woodstox StAX 解析器 2.9.3。

圖 1 顯示了測試序列中前兩個步驟所需的平均時間的總和，即使用解析器構(gòu)建文檔，并遍歷文檔表示以檢查其中的內(nèi)容。如果單獨研究第一個步驟（這里沒有顯示時 間），AXIOM 要比其他的文檔模型好得多，至少對于前面兩個文檔來說是這樣的。然而，這僅表示 AXIOM 正如預(yù)料的那樣工作，直到需要時才真正構(gòu)建完整的文檔。我們希望使用在內(nèi)存中構(gòu)建完整的表示所需的時間來進行公平的比較，這正是圖表中將這兩個時間加在一 起的原因。


圖 1. 構(gòu)建和展開文檔的時間（單位為毫秒）

?

如圖 1 所示，從整體上看，除了 Xerces2 之外，AXIOM 比所測試的任何其他文檔模型都要慢一些。

在 處理較小的文檔組成的集合（“soaps”）時，有一些文檔模型出現(xiàn)了性能問題。Xerces2 在這種情況下最糟糕，但是 AXIOM 也出現(xiàn)了較大的開銷，這可能是該圖表中反映出來的最麻煩的問題。在許多 Web 服務(wù)中，較小的消息是很常見的，而 AXIOM 應(yīng)該可以高效地處理這些消息。因為 AXIOM 設(shè)計為按需展開文檔樹，所以對于兩個較大的文檔，在時間上并不存在很大的問題，至少與其他的文檔模型非常接近。


圖 2. 寫入文檔的時間（單位為毫秒）


圖 2 顯示了使用每種模型將文檔寫入到輸出流中的平均時間。這里，Xerces2 的性能要高出一大截（但這并不足以彌補它在構(gòu)建步驟中糟糕的性能，這兩張圖表的比例并不一樣），而 AXIOM 最差。同樣的，AXIOM 對于較小的文檔尤其糟糕。


圖 3. 文檔內(nèi)存大小（單位為 KB）


最 后，圖 3 顯示了每種框架在表示文檔時所使用的內(nèi)存大小。dom4j 又是最好的，而 AXIOM 則比其他的差了一大截。AXIOM 在內(nèi)存使用方面的糟糕性能，在一定程度上是由于在所構(gòu)建的文檔中引用了解析器，以便在使用文檔實例的過程中保存解析器實例。這也是 AXIOM 在處理較小文檔時尤其糟糕的原因中的一部分。然而，AXIOM 作為文檔組件所使用的對象也比其他文檔模型的對象大的多，這種差別可能正是 AXIOM 對兩個較大的測試文檔使用過多內(nèi)存空間的原因（其中，固定大小的解析器開銷和其他數(shù)據(jù)結(jié)構(gòu)只占總的內(nèi)存使用中的一小部分）。

如果將前兩個圖表的時間累加起來，dom4j 的總體性能最好，而 Xerces2 的性能最差（AXIOM 比它稍微好一點）。在內(nèi)存使用方面，dom4j 又是最好的，而 AXIOM 在這方面是毫無爭議的失敗者。是不是為 AXIOM 感到遺憾呢？

如果始終構(gòu)建完整的樹表示，那才是應(yīng)該 遺憾的，但請記住，AXIOM 的關(guān)鍵思想是在通常情況下并不需要完整的表示。圖 4 顯示了在 AXIOM 中初始文檔構(gòu)建的時間，并與其他文檔模型構(gòu)建文檔表示所需的時間進行了比較。在這個測試中，AXIOM 比其他的文檔模型快得多（對于兩個較大的文檔，甚至快得無法記錄時間）。同樣的比較也可以應(yīng)用于內(nèi)存方面。最后的結(jié)論是，如果只需要處理文檔模型中的某些 部分（如按文檔順序的“第一”部分），AXIOM 提供了優(yōu)秀的性能。


圖 4. 初始文檔構(gòu)建





回頁首




繼續(xù)學(xué)習(xí) Axis2

本 文深入研究了 Axis2 中的 AXIOM 文檔對象模型。AXIOM 中包含了一些有趣的思想，尤其是構(gòu)建完整表示的按需構(gòu)建方法。當(dāng)您需要完整地展開表示時，它無法與其他的 Java 文檔模型相比。尤其是對于較小的文檔，其性能比較糟糕，但是它為 Web 服務(wù)處理所提供的靈活性完全可以抵銷這些問題。

現(xiàn)在，您已經(jīng)了解了 Axis2 如何使用 AXIOM 處理 SOAP 消息表示，包括如何與數(shù)據(jù)綁定框架相互傳遞 XML。下一篇文章將從用戶的角度來研究 Axis2 如何支持不同的數(shù)據(jù)綁定框架，包括使用三種框架的代碼示例.

總結(jié)

以上是生活随笔為你收集整理的Axis2 探索 AXIOM的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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