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