經(jīng)過(guò)了第 1 部分對數據綁定框架的介紹后，現在對其進(jìn)行測試
級別: 中級
Dennis M. Sosnoski總裁, SosnoskiSoftware Solutions，Inc.
2003 年 6 月
企業(yè) Java 專(zhuān)家 Dennis Sosnoski 研究了 Java 中用于 XML 數據綁定的幾種框架的速度和內存使用情況。這些框架包含第 1 部分中討論的所有代碼生成方法、更早的一篇文章中討論的 Castor 映射綁定方法和一種令人驚訝的有可能成功的新方法。如果您正在您的 Java 應用程序中使用 XML，那么您會(huì )希望了解如何將這些數據綁定方法結合在一起！
第 1 部分介紹了有關(guān)為什么您希望對 XML 使用數據綁定的背景知識，還概述了可用于數據綁定的 Java 框架。如果您尚未閱讀
第 1 部分，那么現在您也許至少應該瀏覽一下那篇文章。在本部分中，我將直接討論性能問(wèn)題，而不會(huì )進(jìn)一步討論原因和方法！
為了對數據綁定框架進(jìn)行性能測試，我生成了包含模擬的航班時(shí)刻表信息的文檔。這些文檔的結構與我在較早的有關(guān)利用 Castor 進(jìn)行映射數據綁定的文章（請參閱
參考資料）中定義的結構相同。下面是該結構的樣本，之所以稱(chēng)其為 緊湊格式是因為它主要對數據使用了屬性：
<?xml version="1.0"?><timetable><carrier ident="AR" rating="9"><URL>http://www.arcticairlines.com</URL><name>Arctic Airlines</name></carrier><carrier ident="CA" rating="7"><URL>http://www.combinedlines.com</URL><name>Combined Airlines</name></carrier><airport ident="SEA"><location>Seattle, WA</location><name>Seattle-Tacoma InternationalAirport</name></airport><airport ident="LAX"><location>Los Angeles, CA</location><name>Los Angeles InternationalAirport</name></airport><route from="SEA" to="LAX"><flight carrier="AR" depart="6:23a"arrive="8:42a" number="426"/><flight carrier="CA" depart="8:10a"arrive="10:52a" number="833"/><flight carrier="AR" depart="9:00a"arrive="11:36a" number="433"/></route><route from="LAX" to="SEA"><flight carrier="CA" depart="7:45a"arrive="10:20a" number="311"/><flight carrier="AR" depart="9:27a"arrive="12:04p" number="593"/><flight carrier="AR" depart="12:30p"arrive="3:07p" number="102"/></route></timetable>
注：
清單 1中的機場(chǎng)名稱(chēng)信息通常是一行代碼。為了適應列大小，一些代碼行被拆開(kāi)，出現在兩行上。
除了緊湊格式外，我還嘗試了一個(gè)變體，它的數據值更多地使用了子元素（只對 ID 和 IDREF 繼續使用屬性）。下面是用在此被稱(chēng)為 完整格式的格式表示的同一個(gè)數據：
<?xml version="1.0"?><timetable><carrier ident="AR"><rating>9</rating><URL>http://www.arcticairlines.com</URL><name>Arctic Airlines</name></carrier><carrier ident="CA"><rating>7</rating><URL>http://www.combinedlines.com</URL><name>Combined Airlines</name></carrier><airport ident="SEA"><location>Seattle, WA</location><name>Seattle-Tacoma International Airport</name></airport><airport ident="LAX"><location>Los Angeles, CA</location><name>Los Angeles International Airport</name></airport><route from="SEA" to="LAX"><flight carrier="AR"><number>426</number><depart>6:23a</depart><arrive>8:42a</arrive></flight><flight carrier="CA"><number>833</number><depart>8:10a</depart><arrive>10:52a</arrive></flight><flight carrier="AR"><number>433</number><depart>9:00a</depart><arrive>11:36a</arrive></flight></route><route from="LAX" to="SEA"><flight carrier="CA"><number>311</number><depart>7:45a</depart><arrive>10:20a</arrive></flight><flight carrier="AR"><number>593</number><depart>9:27a</depart><arrive>12:04p</arrive></flight><flight carrier="AR"><number>102</number><depart>12:30p</depart><arrive>3:07p</arrive></flight></route></timetable>
通常，根據所用文檔的大小不同，XML 框架的相對性能會(huì )有巨大差異，因此在這些性能測試中，我同時(shí)包含了大文檔和小文檔。大文檔（ time-comp.xml和 time-full.xml）使用相同的數據值（分別以如上所示的兩種不同格式表示）。因此大小明顯不同（緊湊格式的為 106 KB，而完整格式的為 211 KB）。小文檔都在集合中，每個(gè)集合包含 34 個(gè)文檔，緊湊格式（ ttcomp）的大小從 1.4-3.3 KB 不等，完整格式（ ttfull）的大小從 2.2-5.8 KB 不等。與大文檔一樣，小文檔集合中的相應文檔包含相同的數據值?？梢詮南螺d頁(yè)面（請參閱
參考資料）獲得測試中使用的完整文檔集。
下面是我在本文中使用的一些術(shù)語(yǔ)的一個(gè)袖珍字典：
編組（Marshalling）是在內存中為對象生成 XML 表示的過(guò)程。與 Java 對象序列化一樣，該表示需要包含所有從屬對象：我們的主對象引用的那些對象，以及那些對象引用的對象等等。
數據分解（Unmarshalling）是編組的逆過(guò)程，它根據 XML 表示在內存中構建對象（可能還有一幅鏈接對象的圖）。
映射（Mapping）是一組規則，用于顯式地將對象編組到 XML 文檔和根據 XML 文檔分解對象。使用代碼生成（基于文檔的 DTD 或 W3C XML Schema 描述）的數據綁定方法通常包含隱式的映射，這些映射內置在已構造的對象中，因此在本文中，術(shù)語(yǔ) 映射只用于將用戶(hù)定義的 Java 對象與 XML 文檔進(jìn)行關(guān)聯(lián)的方法。
我更希望這些結果能使用更多的文檔變體而不只有兩種格式來(lái)進(jìn)行測試。但是，由于需要為代碼生成提供 W3C XML Schema（Schema）和文檔類(lèi)型定義（Document Type Definition，DTD）描述，還要為映射版本提供映射文件和基類(lèi)，因此為數據綁定測試添加更多文檔所涉及的工作量是可觀(guān)的。本文使用的兩種格式（包含大文檔和小文檔變體）至少會(huì )相當具有代表性地說(shuō)明，對于典型的業(yè)務(wù)文檔，數據綁定備用方案是如何執行的。但是，由于這些文檔中的大多數數據值可以轉換成基本類(lèi)型 ，所以它們可能會(huì )使映射綁定方法顯示出，內存使用情況將好于典型的普通文檔。這導致一種非常緊湊的內部表示。對于其中大多數數據值都需要保存為 String 的文檔而言，映射綁定方法的內存優(yōu)勢就會(huì )被削弱。
所有測試結果都是使用 1.4GHz Athlon 系統（擁有 256MB DDR RAM，運行 RedHat Linux 7.2）獲得的。在所有測試中，我都使用了 Sun 的 JDK 1.4.1 for Linux。所測試的每個(gè)數據綁定框架的特定版本如下：JAXB Beta 1、Castor 0.9.4.1、JBind 1.0 Beta 12/07、Quick 4.3.1 和 Zeus Beta 3.5（JiBX 是一個(gè)特例 — 請參閱測試結果后面的
那么什么是 JiBX？以獲取詳細信息）。除了 JBind 和 JiBX 之外，所有測試都使用了 Piccolo SAX2 解析器 V1.0.3。這是我知道的最快的 SAX2 解析器，它通?？梢赃_到或超出用于 JiBX 測試的 XMLPull 解析器（XPP3 V1.1.2）的速度。JBind 無(wú)法使用 Piccolo 解析器，因此為測試 JBind，我使用了 Xerces Java 2 V2.2.0。
為了提供數據綁定和其它備用方法之間的性能比較，我還只使用 SAX2 解析器對相同文件運行了計時(shí)測試，并且使用 dom4j 文檔模型（文檔模型中的性能佼佼者，它允許使用不同的 SAX2 解析器解析輸入文檔）運行了計時(shí)和內存測試。對于這些測試，我使用了 dom4j V1.3。
在這些計時(shí)和內存使用量測試中，我使用的基本框架與以前的文檔模型測試（請在
參考資料中參閱作者有關(guān)文檔模型性能的文章。）中所用的相同。這個(gè)基準測試框架首先將所有文檔讀入內存緩沖區，然后對針對文檔的輸入和輸出操作的多次傳遞進(jìn)行計時(shí)。
輸入計時(shí)和
輸出計時(shí)中顯示的測試結果是數次傳遞過(guò)程中的最佳計時(shí)。這應當代表了服務(wù)器類(lèi)型的環(huán)境（其中重復執行相同的代碼）中的長(cháng)期性能。
圖
1和
2顯示了使用 dom4j 文檔模型和各種數據綁定方法讀取 XML 文檔（就數據綁定而言，就是對其進(jìn)行數據分解）以及構造內存中表示的計時(shí)結果。在這些圖表中，您可以將第一個(gè) SAX2 計時(shí)值作為解析文檔的基本時(shí)間。文檔模型和數據綁定實(shí)現使用該解析結果來(lái)構建其在內存中的表示，因此它們決不會(huì )比解析器本身快。標有說(shuō)明的兩個(gè)數據綁定測試基于映射而不是代碼生成。
p>
dom4j 構造文檔的內存表示所花費的時(shí)間不到單獨使用解析器所花費時(shí)間的兩倍。優(yōu)于該性能的唯一數據綁定框架是 JiBX。與 dom4j 相比，JAXB、Quick 和 Zeus 都獲得了不錯的性能數字，但是所花費的時(shí)間整體來(lái)說(shuō)都幾乎是 JiBX 的兩倍。比較起來(lái)，Castor 非常緩慢，使用映射綁定和生成代碼都如此。
相對于這些測試中的大多數綁定框架，JBind 的執行速度慢了整整一個(gè)數量級。這樣拙劣的性能一小部分原因是由于用于 JBind 測試的解析器比較慢（因為它無(wú)法使用其它測試所用的解析器）。更大的原因可能是由于 JBind 強制在輸入時(shí)對照 Schema 進(jìn)行文檔驗證，這樣會(huì )增加大量開(kāi)銷(xiāo)。但是，導致這一拙劣性能的最主要原因可能是由于 JBind 框架本身，該框架使用非常間接的方法來(lái)進(jìn)行綁定（在當前實(shí)現中，綁定建立在 DOM 文檔模型之上）。
除了 JBind 以外的所有測試都是在不進(jìn)行完全驗證的情況下運行的。大多數數據綁定框架僅按照其設計包含某個(gè)固有的驗證級別（例如，確保元素的內容模型是匹配的）。大多數框架還可以使用驗證解析器（如 Xerces Java 2）在輸入時(shí)對文檔進(jìn)行完全檢查，并且有框架（包括 JAXB）可以在內存中執行綁定數據的完全驗證。因為在這些測試中主要關(guān)心的是性能，所以我盡可能地禁用了可選驗證（包括在 Castor 中使用屬性文件和數據分組程序／編組程序設置）。
圖
3和
4顯示了使用 dom4j 和各種數據綁定方法生成內存中表示的 XML 文本序列（就數據綁定而言，就是對其進(jìn)行編組）的計時(shí)結果。這些圖表使用的縱坐標與前兩幅圖表相同，以使比較變得簡(jiǎn)化，但是區別在于沒(méi)有與 SAX2 解析器數字相對應的數字。
在該領(lǐng)域中，dom4j 提供的性能是所有數據綁定方法中最好的，比 JiBX 稍好一點(diǎn)，比 Zeus 更加好一點(diǎn)。其它數據綁定框架都花費了約兩倍的時(shí)間，Quick 是所有框架中最慢的（當然，不是故意在說(shuō)雙關(guān)語(yǔ)）。盡管這里的結果與輸入測試的幾乎沒(méi)有太大的變化，但是 dom4j 的確優(yōu)于其它任何數據綁定框架的這一事實(shí)表明它們仍然有改進(jìn)的余地。
圖
5和
6顯示了性能情形的另一部分，研究了內存使用情況。當利用文檔模型使用非常大的文檔（通常有 5+ MB 大?。r(shí)，運行時(shí)內存的不足會(huì )成為一個(gè)問(wèn)題。對數據綁定方法如何進(jìn)行文檔表示所使用的內存量的比較呢？
這里的差異比時(shí)間性能比較中的差異更大，并且表現出了一個(gè)非常不同的模式。盡管 dom4j 在時(shí)間測量中執行的很好，但是在內存使用方面，它比任何數據綁定框架（除了 JBind，它構建在與 dom4j 的表示相當的內部文檔模型上）差遠了。與該領(lǐng)域中最優(yōu)秀的執行者相比，表示相同的數據，dom4j 所占用的內存是前者的 10 倍。
兩種映射綁定方法為綁定數據使用了同一種內部結構，所以它們表現出了相同的內存使用情況。這讓它們在內存效率的“競技場(chǎng)”上并列第一，從而產(chǎn)生了比使用生成代碼的數據綁定方法優(yōu)越幾倍的性能。部分原因是因為 映射綁定使用了數據值的緊湊表示。在這些測試中，映射綁定將大多數數據值轉換成 int 值（在大多數 Java 虛擬機（Java Virtual Machine，JVM）中， String 即使只包含一個(gè)或兩個(gè)字符，都將占用 20 個(gè)以上的字節，而 int 只占用 4 個(gè)字節）。該轉換的開(kāi)銷(xiāo)增加了讀寫(xiě)次數，但是除了只是內存大小減小了以外，它的確還有其它優(yōu)點(diǎn)。當實(shí)際使用數據時(shí)， int 遠比 String 更便利和有效。
映射綁定方法之所以能獲得較高的內存效率，除了因為它更為廣泛地使用了原語(yǔ)值外，另一個(gè)原因是生成代碼方法通常會(huì )將控制信息添加到出現在每個(gè)綁定對象中的實(shí)際數據中去。該控制信息增加了對象的大小，因而數據綁定少了一個(gè)主要優(yōu)點(diǎn)。
在這些測試中，使用生成代碼的數據綁定框架消耗的內存至少是映射綁定的幾倍，但是（除 JBind 外）仍然比 dom4j 的文檔模型表示小很多。這一點(diǎn)不足為奇 — 諸如 dom4j 的文檔模型需要構造一些對象以表示文檔的每個(gè)組件（包括實(shí)際的數據文本以及諸如元素和屬性之類(lèi)的結構組件），而數據綁定只需要保存實(shí)際的數據。對于生成代碼綁定而言，許多實(shí)際數據仍然是作為 String 存儲的，但是一些值可以被轉換成 int ，而其它值可被轉換成對象引用。
這里，Zeus 被認為是唯一直接將所有數據存儲為 String 的數據綁定方法，這使它成為常用的數據綁定方法中占用內存最大的一種方法。到目前為止，JBind 的內存使用情況仍然較大。這有一部分是由于它在內部使用了文檔模型，但是 JBind 使用的內存量要比單獨使用文檔模型（如 dom4j）所需的內存量大好幾倍。從該內存使用情況判斷，似乎 JBind 創(chuàng )建了許多其它對象，以建立綁定虛包（facade）和文檔模型中實(shí)際數據之間的鏈接。
圖
1到
6說(shuō)明了數據綁定框架在擴展的測試運行（代表了服務(wù)器環(huán)境）中執行結果如何。我認為，研究這些框架在僅執行一次（single-execution）環(huán)境（例如其中有一個(gè)應用程序正在使用數據綁定代碼來(lái)讀或寫(xiě)配置文件）中使用時(shí)的比較結果也很有趣。圖 7 顯示了結果。
圖
7顯示了啟動(dòng)一個(gè)短文檔所花費的時(shí)間 — 從基準測試程序開(kāi)始執行到整個(gè)操作返回為止（將數據分解成對象，然后將對象編組回文檔）。同前面的計時(shí)數字不同：這里大多數的時(shí)間花費在了類(lèi)裝入，以及為獲得數據綁定框架代碼而由 JVM 進(jìn)行的本機代碼生成。通過(guò)將這些結果與前面的計時(shí)圖表進(jìn)行比較，可以看到這一啟動(dòng)時(shí)間通常比實(shí)際處理時(shí)間（即使是處理相當大的文檔）要大好幾倍。如果您的程序每次執行時(shí)將只使用一些文檔，那么該啟動(dòng)時(shí)間將是比前面顯示的最佳情形時(shí)間更重要的因素。
數據綁定框架使用的 jar 文件的大小是影響這一啟動(dòng)時(shí)間的一個(gè)主要因素。JiBX 是最小的，運行時(shí)和解析器的總大小不足 60KB。JAXB、Castor 和 JBind 是最大的，每個(gè)大小大約為 1MB。該時(shí)間還受每個(gè)框架所需的初始化影響。在使用映射綁定的 Castor 情形中，該時(shí)間包含處理映射定義文件，而對于 JBind 而言，它包含處理文檔的 Schema 定義。
既然我已經(jīng)展示了性能結果，那么我可能應該介紹一下這個(gè)幾乎在每項測試中都能占據小組中的第一名的框架。是的，事實(shí)上它是“作弊的參加者”— JiBX 是一種針對性能而設計的數據綁定框架，因此如果它滿(mǎn)足了其設計需求，那么在這些測試中它 應該是最佳的執行者。
JiBX 實(shí)際上源于本系列文章。當我開(kāi)始研究可用的數據綁定框架時(shí)，我驚奇地看到：與文檔模型（如 dom4j）相比，它們并不是執行得都那樣好。這與我的期望相反，因為數據綁定方法實(shí)際上減少了保存在內存中的文檔信息的數量 — 而文檔模型在內存中保存 所有事物，同時(shí)數據綁定只需要實(shí)際數據。我認為，數據用得少的方法通常應該比那些數據用得多的方法要快。
在研究現有數據綁定框架是如何操作的過(guò)程中，我發(fā)現從性能角度來(lái)說(shuō)有兩個(gè)方面看上去不是很好。第一個(gè)方面就是許多框架中廣泛使用了反射。反射是在運行時(shí)訪(fǎng)問(wèn)有關(guān) Java 語(yǔ)言類(lèi)的信息的一種方法?？捎盟鼇?lái)訪(fǎng)問(wèn)類(lèi)實(shí)例中的字段和方法，從而提供了一種在運行時(shí)將類(lèi)動(dòng)態(tài)地掛鉤在一起，卻無(wú)需類(lèi)之間有任何源代碼鏈接的方法。反射是一種功能非常強大的 Java 技術(shù)特性，但是將其與調用方法或直接訪(fǎng)問(wèn)已編譯代碼中的字段相比，它在性能上有些欠缺。
我質(zhì)疑的第二個(gè)方面是使用 SAX2 解析器對文檔進(jìn)行數據分解。SAX2 是一種非常有用的解析 XML 的標準，但是其事件驅動(dòng)方法并不非常適合數據綁定和類(lèi)似的應用程序。這里的問(wèn)題在于，處理 SAX2 事件的代碼需要維護其處理的所有事情的狀態(tài)信息，這既增加了復雜性又增加了開(kāi)銷(xiāo)。
我創(chuàng )建了形成 JiBX 的代碼，以對一些方法（解決其它數據綁定框架中所存在的這些問(wèn)題）進(jìn)行測試，并實(shí)驗擴展超出 Castor 支持范圍的映射綁定方法。JiBX 使用字節代碼增強而不是反射來(lái)在項目構建時(shí)將掛鉤添加進(jìn)應用程序代碼。JiBX 基于拉（pull）解析器體系結構（當前是 XMLPull），而不是 SAX2。JiBX 不是根據 DTD 或 Schema 生成代碼，而是使用綁定定義，該定義將用戶(hù)提供的類(lèi)與 XML 結構相關(guān)聯(lián)。
這些技術(shù)并不是 JiBX 所特有的。許多 Java 數據對象（Java Data Object，JDO）實(shí)現都使用字節代碼增強，基本上都是為了達到與 JiBX 相同的目的（將訪(fǎng)問(wèn)掛鉤添加到現有的已編譯代碼中）。原始的 JAXB 代碼（已被丟棄）基于類(lèi)似 XMLPull 的拉解析器體系結構。Castor 和 Quick 都支持數據綁定的映射方法（盡管有一些限制）。即使個(gè)別技術(shù)不是很新，但是它們的組合仍然可以形成其它數據綁定框架非常有趣的備用方案。
在本系列文章的第 3 部分，我將完整地介紹有關(guān) JiBX 的知識。JiBX 仍然處于初期開(kāi)發(fā)階段。為了性能測試，我手工編寫(xiě)了代碼，通常通過(guò)字節代碼增強添加該代碼，并使用 JiBX 運行時(shí)的當時(shí)版本來(lái)運行它。到本文發(fā)表時(shí)，我仍在著(zhù)手完成增強代碼，有許多其它特性我希望添加到其中。如果您在第 3 部分發(fā)表前就希望了解更多有關(guān) JiBX 的知識，請查閱
參考資料以獲取到 JiBX 站點(diǎn)的鏈接。您甚至可以為 JiBX 的未來(lái)開(kāi)發(fā)獻策獻力，也可以在您自己的應用程序中使用 JiBX。
這篇對數據綁定性能的研究展示了一些有趣的結果，但是并未對第 1 部分中的推薦做根本上的更改。Castor 為使用代碼生成（根據 W3C XML Schema 定義）的數據綁定提供了最佳的當前支持。與其它備用方案相比，它的數據分解性能比較差，但是它的確可以提供較好的內存利用率和相當快的啟動(dòng)時(shí)間。Castor 的開(kāi)發(fā)人員說(shuō)，在他們的 1.0 發(fā)布以前，他們計劃專(zhuān)注于解決性能問(wèn)題，所以到那個(gè)時(shí)候，您也可能會(huì )看到在數據分解性能方面的一些改進(jìn)。
JAXB 看上去將來(lái)仍是代碼生成方法的一個(gè)不錯選擇（測試版許可證只允許評估使用）。當前的參考實(shí)現測試版在 jar 大小方面非常龐大，并且在內存使用方面的效率也略嫌不足，但是這里再重申一次，將來(lái)您可能會(huì )看到更佳的性能。在撰寫(xiě)本文的時(shí)候，當前版本仍然是測試版，只有當它作為商業(yè)或開(kāi)放源碼項目發(fā)布以后，它的性能才可能優(yōu)于參考實(shí)現。由于它將作為 J2EE 平臺的標準部分，所以關(guān)于在 Java 中使用 XML 方面，JAXB 無(wú)疑會(huì )扮演重要的角色。
性能結果也證實(shí)：JBind、Quick 和 Zeus 最適用于有特殊需求的應用程序，而不應該用于一般用途。JBind 的 XML 代碼方法可以為圍繞 XML 文檔處理而構建的應用程序提供重要基礎，但是當前實(shí)現的性能容易導致問(wèn)題。Quick 和 Zeus 提供根據 DTD 進(jìn)行代碼生成，但是正如我在第 1 部分中提到的那樣，將 DTD 轉換成 Schema 通常相當簡(jiǎn)單。缺點(diǎn)是，Quick 使用起來(lái)似乎過(guò)于復雜，而 Zeus 只支持 String 用于綁定數據值（沒(méi)有原語(yǔ)或使用 ID-IDREF 或等價(jià)物的對象引用）。
對于數據綁定的映射方法，Castor 的優(yōu)點(diǎn)是：它是一個(gè)相當穩定的實(shí)現，并可投入實(shí)際使用。Quick 也可以用于這類(lèi)的綁定，但是似乎也難于設置。JiBX 是新事物，并且尚未完全投入使用，但是它提供了卓越的性能和高度的靈活性。
如果您還未閱讀
第 1 部分，您也許應該回頭閱讀一下那篇文章，以便了解更多有關(guān)這些數據綁定框架特性的知識。第 1 部分還討論了數據綁定的代碼生成和映射方法之間的權衡。在第 3 部分中，我將深入介紹新的 JiBX 框架。這包括 JiBX 如何將 Java 對象映射到 XML，以及 JiBX 為最小化運行時(shí)開(kāi)銷(xiāo)而在構建時(shí)使用的字節代碼增強過(guò)程。請回來(lái)查看有關(guān)這個(gè)令人振奮的方法的完整信息，以提升框架性能！
您可以參閱本文在 developerWorks 全球站點(diǎn)上的
英文原文.
參與有關(guān)本文的
論壇。（您也可以通過(guò)單擊文章頂部或底部的 討論來(lái)訪(fǎng)問(wèn)論壇。） 有關(guān)數據綁定的本系列文章的
第 1 部分提供了關(guān)于為什么您希望對 XML 使用數據綁定的背景知識，還概述了可用于數據綁定的 Java 框架（ developerWorks，2003 年 1 月）。
下載本文測試中使用的完整文檔集。 請查閱作者以前有關(guān)“
Data Binding with Castor”的文章，它介紹了利用 Castor 進(jìn)行的映射數據綁定技術(shù)（ developerWorks，2002 年 4 月）。 在作者有關(guān)
Java 中的 XML 的解析系列文章中，了解事件驅動(dòng)方法（SAX2）與拉解析器方法在解析 XML 方面的差異。 如果您需要了解有關(guān) XML 的背景知識，請嘗試查閱 developerWorks“
Introduction to XML”教程（2002 年 8 月）。 請回顧作者以前的 developerWorks文章，它們介紹了各種 Java XML 文檔模型在
性能（2001 年 9 月）和
使用情況（2002 年 2 月）方面所做的比較。 請閱讀 Brett McLaughlin 所寫(xiě)的“
Converting between Java objects and XML with Quick”中有關(guān) Quick 的概述，它向您展示了在不使用其它數據綁定框架必需的類(lèi)生成語(yǔ)義的情況下，如何使用該框架快速而輕松地將您的 Java 數據轉變成 XML 文檔（ developerWorks，2002 年 8 月）。 有關(guān)對象-關(guān)系型數據綁定（本意與 JDO 標準類(lèi)似，但不兼容）的基礎知識簡(jiǎn)介，請閱讀由 Bruce Snyder 撰寫(xiě)的“
Getting started with Castor JDO”（ developerWorks，2002 年 8 月）。 獲取有關(guān)用于 Java 語(yǔ)言對象持久性的
Java 數據對象（Java Data Objects，JDO）API 的詳細信息。
數據綁定框架
了解更多有關(guān)
Java Architecture for XML Binding（JAXB）的知識，這是一個(gè)正在發(fā)展的針對 Java 平臺數據綁定的標準。 進(jìn)一步研究
Castor框架，它支持映射綁定和生成綁定。 了解
JBind，該框架對于允許 Java 語(yǔ)言應用程序方便地使用 XML 關(guān)注得較少，它更多地關(guān)注于如何圍繞 XML 構建應用程序代碼框架。
Quick框架以一系列先于 Java 平臺和 XML 的開(kāi)發(fā)成果為基礎。它提供了一個(gè)極其靈活的框架以便在 Java 平臺上使用 XML。 研究
Zeus的詳細信息，它（跟 Quick 一樣）根據 XML 文檔的 DTD 描述生成代碼，但是比 Quick 更易于使用且限制更多。 了解更多有關(guān)新的用于映射綁定的
JiBX框架的知識。
其它鏈接 請閱讀更多有關(guān)
Java Technology and XML相互影響的文章。 請參考
JSR 31 — XML Data Binding Specification。 在 developerWorks
XML和
Java 技術(shù)專(zhuān)區查找更多有關(guān)本文所涉及技術(shù)的信息。
IBM WebSphere Studio提供了一套使 XML 開(kāi)發(fā)（以 Java 和其它語(yǔ)言）自動(dòng)化的工具。它與
WebSphere Application Server進(jìn)行了緊密的集成，但是也可以與其它 J2EE 服務(wù)器一起使用。 了解您怎樣可以成為一名
IBM 認證的 XML 及相關(guān)技術(shù)開(kāi)發(fā)人員。
關(guān)于作者
Dennis Sosnoski（
dms@sosnoski.com）是西雅圖地區的 Java 咨詢(xún)公司
Sosnoski Software Solutions, Inc.的創(chuàng )始人和首席顧問(wèn)，他是 J2EE、XML 和 Web 服務(wù)支持方面的專(zhuān)家。Dennis 有 30 多年的專(zhuān)業(yè)軟件開(kāi)發(fā)經(jīng)驗，最近幾年致力于服務(wù)器端 Java 技術(shù)。他經(jīng)常在全美范圍的會(huì )議上就 Java 中的 XML 和 J2EE 技術(shù)發(fā)言，并主持
Seattle Java-XML SIG。
