根據(jù) DTD 或模式生成數(shù)據(jù)類
Dennis M. Sosnoski總裁, Sosnoski Software Solutions，Inc.
2003 年 6 月
企業(yè) Java 專家 Dennis Sosnoski 研究了幾種 XML 數(shù)據(jù)綁定方法，這些方法根據(jù)用于 XML 文檔的 W3C XML Schema 或 DTD 文法來生成代碼。他從人們期待已久的 JAXB 標準（馬上就要由 Java Community Process，JCP 發(fā)布了）入手，然后總結(jié)了其它一些目前可用的框架。最后，他討論了如何以及何時以最佳方式將依據(jù)文法的代碼生成應(yīng)用到應(yīng)用程序中。
數(shù)據(jù)綁定 提供了一種簡單而直接的方法，以在 Java 平臺應(yīng)用程序中使用 XML。有了數(shù)據(jù)綁定，應(yīng)用程序可以在很大程度上忽略 XML 文檔的實際結(jié)構(gòu)，而直接使用那些文檔的數(shù)據(jù)內(nèi)容。雖然這種方法不能適合于所有應(yīng)用程序，但在一般情況下，對于那些將 XML 用于數(shù)據(jù)交換的應(yīng)用程序是比較理想的。
除了簡化編程之外，數(shù)據(jù)綁定還提供了其它一些好處。由于數(shù)據(jù)綁定對許多文檔細節(jié)進行了抽象，因此對于在內(nèi)存中處理文檔，它通常所需要的內(nèi)存比文檔模型方法（譬如 DOM 或 JDOM）要少。您還會發(fā)現(xiàn)，由于不需要遍歷文檔結(jié)構(gòu)以獲取數(shù)據(jù)，因此用數(shù)據(jù)綁定方法訪問程序內(nèi)的數(shù)據(jù)要比用文檔模型方法快。最后，在輸入時，一些特殊類型的數(shù)據(jù)（譬如數(shù)字和日期）可以被轉(zhuǎn)換成內(nèi)部表示，而不是保留為文本形式；這使應(yīng)用程序可以更有效地使用數(shù)據(jù)值。
您可能想知道，如果數(shù)據(jù)綁定有這么多的好處，那么何時使用文檔模型方法呢？基本上在以下兩種主要情形下需要用文檔模型方法：
當(dāng)應(yīng)用程序確實要關(guān)注文檔結(jié)構(gòu)的細節(jié)時。例如，如果您正在編寫一個 XML 文檔編輯器，則您會希望采用文檔模型，而不是使用數(shù)據(jù)綁定。 當(dāng)正在處理的文檔不需要遵循固定的結(jié)構(gòu)時。例如，對于實現(xiàn)常規(guī)的 XML 文檔數(shù)據(jù)庫，數(shù)據(jù)綁定不是一種很好的方法。
去年，我寫了一篇文章，講述了如何使用 Castor 框架以進行 Java 對象到 XML 文檔的映射數(shù)據(jù)綁定。我曾經(jīng)答應(yīng)要寫一篇后續(xù)文章，其中將探討代碼生成方法，包括介紹 JAXB，Java Community Process（JCP）正在開發(fā) JAXB，它是用 Java 語言編寫的、用于數(shù)據(jù)綁定的標準 API。就在較早的那篇文章發(fā)布不久，Sun 宣布對 JAXB 的方向做出了重大調(diào)整（請參閱
重新架構(gòu) JAXB）。由于這方面的變化，所以我想，為了更貼近最終的 JAXB 代碼，最好先不寫這篇后續(xù)文章，現(xiàn)在，我很高興，終于可以寫這篇文章了！
下面是一個微型字典，里面包含了我在本文中所使用的一些術(shù)語：
文法（Grammar） 是用于定義一系列 XML 文檔結(jié)構(gòu)的一套規(guī)則。其中一類文法是 XML 規(guī)范所定義的文檔類型定義（Document Type Definition，DTD）格式。另一類日漸普及的文法是 XML Schema 規(guī)范所定義的 W3C XML Schema（Schema）格式。文法定義了哪些元素和屬性可以出現(xiàn)在文檔中，以及在文檔中元素是如何嵌套的（通常包括嵌套元素的次序和數(shù)目）。一些類型的文法（譬如 Schema）還可以更進一步，使字符數(shù)據(jù)內(nèi)容與特定數(shù)據(jù)類型甚至正則表達式相匹配。在本文中，我會常使用術(shù)語 描述， 將它作為引用一系列文檔的文法的非正式方法。
編組（Marshalling）是在內(nèi)存中為對象生成 XML 表示的過程。與 Java 對象序列化一樣，這種表示需要包含所有依賴的對象：我們的主對象引用的對象、這些對象引用的對象等等。
數(shù)據(jù)分解（Unmarshalling） 是與編組相反的過程，在內(nèi)存中根據(jù) XML 表示構(gòu)建一個對象（而且可能是鏈接對象的圖）。
在本文中，我將討論根據(jù) XML 文檔文法生成 Java 語言代碼的五種 XML 數(shù)據(jù)綁定框架：JAXB、Castor、JBind、Quick 和 Zeus。它們都可以免費獲取，除了 JAXB 之外，其它四種框架都可以在開放源碼和專利項目中使用。當(dāng)前 JAXB 參考實現(xiàn) beta 測試版的許可證只允許用于評估，但當(dāng)它作為產(chǎn)品發(fā)行時，這種情形很可能會改變。JAXB、Castor 和 JBind 都提供了根據(jù) XML 文檔的 Schema 描述生成代碼，而 Quick 和 Zeus 根據(jù) DTD 描述生成代碼。Castor 和 Quick 還支持將現(xiàn)有類映射到 XML，以此作為另一種生成代碼的方法。
這些框架各有優(yōu)缺點，所以我會試圖逐步指出每種框架所具有的最佳（和最差）特性。在第 2 部分，我將進一步向您顯示這些框架如何對一些樣本文檔進行處理，另外，還將探討，對于許多類型的應(yīng)用程序，現(xiàn)有的數(shù)據(jù)綁定框架怎么會缺乏一些重要的特性。
相對于我在以前文章中所描述的映射綁定方法，根據(jù) Schema 或 DTD 文法生成 Java 語言代碼具有一些突出的優(yōu)點。使用生成的代碼，您可以確定數(shù)據(jù)對象被正確地鏈接到 XML 文檔，不象映射綁定方法，需要直接指定鏈接，并確保正確地涵蓋了所有的結(jié)構(gòu)變體。在使用 Schema 時，甚至可以利用文法所提供的類型信息，用合適的數(shù)據(jù)類型來生成代碼。
代碼生成方法也有一些不足之處。這種方法造成應(yīng)用程序數(shù)據(jù)結(jié)構(gòu)與 XML 文檔結(jié)構(gòu)之間緊密耦合。另外，它還可能限定您使用簡單的數(shù)據(jù)類（沒有關(guān)聯(lián)行為的被動數(shù)據(jù)容器），而不是真正的對象類，在編組和數(shù)據(jù)分解過程中，還可能限制應(yīng)用數(shù)據(jù)的定制轉(zhuǎn)換的靈活性。在本文后面，我會權(quán)衡代碼生成和映射綁定這兩種方法（請參閱
映射綁定 vs. 代碼生成）。
對于將在第 2 部分中討論的性能測試，我用每一種數(shù)據(jù)綁定框架來生成代碼。用于性能測試的文檔包含模擬航班時刻表的信息。下面是一個樣本文檔，您可以感受一下其中的結(jié)構(gòu)：
<?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>
圖 1 顯示了用于映射數(shù)據(jù)綁定到這些文檔的類結(jié)構(gòu)。為了進行比較，我將在有關(guān)各個數(shù)據(jù)綁定框架章節(jié)中顯示生成的類結(jié)構(gòu)。這里包含的這些圖僅僅是所有情況的縮略圖；如果要看全圖，請單擊這個小圖像。
圖 1. 映射綁定類圖（單擊進行放大）
用于 XML 綁定的 Java API（Java API for XML Binding，JAXB）是一個處于不斷發(fā)展中的 Java 平臺數(shù)據(jù)綁定標準。Java Community Process 正在開發(fā)作為“JSR-31 ― XML 數(shù)據(jù)綁定規(guī)范（XML Data Binding Specification）”的 JAXB。該項目始于 1999 年 8 月，其目的是定義一種方法，生成與 XML 結(jié)構(gòu)相鏈接的 Java 語言代碼。最初打算在 2000 年第 2 季度發(fā)布，但最后在 JavaOne 2001 上宣布了初步的 Early Access（EA）版本，該版本在 2001 年 6 月向公眾發(fā)布。
JAXB 的 EA 版本基于具有創(chuàng)新意義的拉解析器（pull parser）設(shè)計，這種設(shè)計使驗證可以方便地構(gòu)建到生成的數(shù)據(jù)分解代碼中。它根據(jù) DTD 生成代碼，構(gòu)建在解析 XML 文檔時自動驗證 XML 文檔結(jié)構(gòu)（而不是數(shù)據(jù)）的類。我們期望這種方法能快速和有效地處理 XML 和 Java 語言對象之間的轉(zhuǎn)換，但 EA 代碼僅僅是部分實現(xiàn)，顯然在成為完整的實現(xiàn)之前，仍需要做大量工作。
專家組不久之后開始收到關(guān)于 EA 發(fā)行版的反饋。作為對反饋意見的部分響應(yīng)中，他們研究決定重新架構(gòu) JAXB，之后更新了網(wǎng)站，聲明 JAXB 在幾個方面正在得到增強。該站點還聲明，下一版本在 API 級上不與早期版本兼容 ― 但您仍然可以下載 EA 版本。
直到 2002 年 3 月，新體系結(jié)構(gòu)的細節(jié)才公布于眾，在 JavaOne 上，Sun 宣布，作為在 JAXB 方面進一步工作的基礎(chǔ)，實際上正在放棄 EA 代碼。它將被新設(shè)計所替代，在新設(shè)計中，共享了一些常見的功能，但新設(shè)計使用不兼容的 API 和內(nèi)部體系結(jié)構(gòu)。發(fā)展方向變化如此之大，讓我和那些對 EA 代碼有興趣的人們感到驚訝。
JAXB 項目的 SUN JSR 負責(zé)人 Joseph Fialli 把這么大的變化歸結(jié)為以下一些因素。主要問題是擴展原有代碼庫以支持 W3C XML Schema 的復(fù)雜性。這是一個相當(dāng)復(fù)雜的規(guī)范，以至于在批準之后的兩年多時間里，在所有平臺上，仍然只有少數(shù)幾個解析器能接近完全符合規(guī)范。最初的 JAXB 代碼需要實際對象來控制驗證，而且將這種方法擴展到 Schema 將耗費太多精力，以至于在合理的期限內(nèi)無法實現(xiàn)這項工作。
為適應(yīng) Schema 而做出變更的同時，專家組還決定重新考慮處理驗證的方法。原來的 JAXB 代碼無條件地驗證文檔的結(jié)構(gòu)，如果發(fā)現(xiàn)錯誤，則拋出異常并中止處理。Fialli 說，在公眾的意見中，抱怨這種方法局限性太大、限制太嚴 ― 在一些情況下，用戶希望能夠一次檢查多個驗證錯誤，而在另一些情況下，則希望完全禁用驗證（或者由于性能原因，或者在編組沒有精確匹配文法的文檔時）。新的 JAXB 體系結(jié)構(gòu)能夠滿足這兩種需求。
最后，專家組決定放棄單個綁定框架運行時（就象在原來 EA 發(fā)行版中所看的）的想法。而采用接口方法，其實質(zhì)是可以使用不同的數(shù)據(jù)綁定框架。這使用戶代碼可以在各框架之間進行移植，而不需移植生成的類 ― 這些類特定于專門的數(shù)據(jù)綁定框架，它們只能由該框架運行。強制性的 SAX 2.0 解析器支持替代了 EA 運行時中所使用的拉解析器方法，對于其它解析器（可能包括新的拉解析器，該解析器基于用于 XML 的流式 API，JSR 173 正在定義此 API），提供可選的特定于框架的支持，數(shù)據(jù)結(jié)構(gòu)本身被更改為類 JavaBean 的數(shù)據(jù)對象，外部框架可以方便地操作此數(shù)據(jù)對象。
自 3 月以來，JAXB 項目一直在朝著這個新方向前進。這一工作的第一個公開成果是，去年夏天發(fā)布了該規(guī)范的新草案（但草案仍處于準備階段）。接著在 10 月，Sun 提供了 JAXB 參考實現(xiàn)新的 beta 測試版，最終它會替代過時已久的 EA 版本。在這些文章中，我用這個最近的 beta 測試版進行評估和性能測試。它直接根據(jù) Schema 文檔描述進行工作，生成與為文檔所定義的元素類型和用法相匹配的類的層次結(jié)構(gòu)。該層次結(jié)構(gòu)包括四種常規(guī)類型的類：用于已定義類型的接口、用于實際元素的接口和這兩組接口的實現(xiàn)。
圖 2. JAXB 接口類圖（單擊進行放大）
圖 3. JAXB 實現(xiàn)類圖（單擊進行放大）
從應(yīng)用程序的角度來看，類型接口是這些類最有趣的部分。對于類型內(nèi)的數(shù)據(jù)，存在著 JavaBean 樣式的 get 方法和 set 方法集合。包含在類型接口中的這些方法遵循 JAXB 規(guī)范所規(guī)定的規(guī)則，所以應(yīng)用程序代碼可以安全地使用這些接口來訪問所有數(shù)據(jù)，同時還保持了 JAXB 實現(xiàn)間的可移植性。這些接口使 JAXB 生成的代碼可以相當(dāng)容易地與現(xiàn)有文檔一起使用。然而，構(gòu)造和修改數(shù)據(jù)結(jié)構(gòu)有點困難。因為使用接口，所以不能直接構(gòu)造實例；而是必須使用工廠方法創(chuàng)建實例，然后使用類 JavaBean 的取值方法來填充數(shù)據(jù)值。
用 JAXB 根據(jù) Schema 描述生成代碼非常簡單。所提供的綁定編譯器 xjc 是一個命令行工具。它將 Schema 文檔作為輸入，將文件生成到指定的輸出包和目標目錄。其中所具有的選項還使用戶可以控制生成的代碼文件是否是只讀的，以及是否嚴格驗證 Schema 描述。
通過使用綁定聲明，JAXB 規(guī)范定義了一些方法來定制生成數(shù)據(jù)綁定的一些方面。包括：
用于控制所生成類的名稱和屬性的選項 指定由綁定所使用的現(xiàn)有實現(xiàn)類的方法 允許（有限地）控制驗證處理和用于編組和數(shù)據(jù)分解的序列化器／反序列化器（serializer/deserializer）的選項
要么在實際的 Schema 文檔中以注釋形式嵌入這些定制，要么通過使用單獨的外部綁定聲明文檔來單獨提供這些定制。參考實現(xiàn)的當(dāng)前 beta 測試版只支持第一種方法，但在以后的發(fā)行版中將支持使用外部綁定聲明文檔。
總體說來，JAXB 正成為一種功能強大而靈活的工具，它用于將 Java 語言代碼綁定到 W3C XML Schema 文法所定義的文檔。由于有可能批準將 JAXB 作為一個 Java 平臺標準，因此它將會受到廣泛支持，而且在各實現(xiàn)之間移動綁定應(yīng)用程序會象在 servlet 引擎之間移動 Web 應(yīng)用程序一樣容易（一般來講，很簡單，但偶爾也會有一些波折）。
然而，JAXB 確實也有一些缺點。目前最大的局限是只有用于評估用途的許可證。在該產(chǎn)品發(fā)行版（目前計劃在這個季度發(fā)布）之前，JAXB 還無法用于實際項目中。另外，定制的程度也局限于只能應(yīng)用到生成的代碼。在許多情形中，您可以為 JAXB 所定義的接口定義自己的實現(xiàn)類，但這些接口本身總是與 Schema 描述聯(lián)系在一起，不太可能進行修改。
用于 XML 數(shù)據(jù)綁定的 Castor 框架支持映射綁定和生成綁定。在我的上一篇文章中，我討論了 Castor 映射綁定方法的一些特性。對于本文，我只討論根據(jù) Schema 生成代碼，但在第 2 部分，我將研究這兩種方法的性能。請回顧以前的文章（請參閱
參考資料），了解有關(guān) Castor 中映射數(shù)據(jù)綁定工作方式的更多信息。
圖 4. Castor 生成的類圖（單擊進行放大）
在一些細節(jié)上，Castor 的代碼生成支持不同于 JAXB 方法，但在目的上，兩者非常相似。與使用 JAXB 一樣，Castor 向應(yīng)用程序提供類 JavaBean 結(jié)構(gòu)的數(shù)據(jù)模型。主要差別在于 Castor 避免使用接口，而是喜歡直接使用生成的實現(xiàn)類。除了每個實現(xiàn)類，Castor 還生成描述符（descriptor）類，該類包含綁定和驗證代碼。由于 Castor 使用具體的類，而不是接口，因此對于構(gòu)造或修改文檔數(shù)據(jù)結(jié)構(gòu)，它要比 JAXB 略微簡單?？梢詢H僅直接使用相應(yīng)類的構(gòu)造函數(shù)，而不用通過工廠類。
Castor 的當(dāng)前 beta 測試版（我寫這篇文章時，該版本為 0.9.4.1）不支持在代碼生成中進行任何實質(zhì)的定制，但這種情況有望得到改變。下一 beta 測試發(fā)行版預(yù)計將支持使用映射文件來控制代碼生成的各個方面。起初，在這些方面中，只支持類名和包名，但從更長遠來看，計劃將添加對用戶所提供的實現(xiàn)類的支持。Castor 開發(fā)人員還計劃在 Castor 中支持 JAXB，可能是通過使用某類兼容性層來實現(xiàn)這一點。
用 Castor 根據(jù) Schema 描述生成代碼與用 JAXB 一樣方便，使用的基本選項也一樣。Castor 確實使用一些附加的命令行參數(shù)選項，而且通過屬性文件設(shè)置，甚至提供了更多選項。這些選項主要用在一些特殊的情形中，但不包括象 JAXB 那樣通過 Schema 文檔注釋提供對類名和驗證的控制。
現(xiàn)在，用 Castor 來生成源代碼這種方法的主要缺點是對定制的支持有限。這種情形正在開始發(fā)生轉(zhuǎn)變，可以用 Castor 的映射數(shù)據(jù)綁定方法來實現(xiàn)實質(zhì)的定制（見前一篇文章中的描述 ― 請參閱
參考資料），我期望最終在定制方面至少與源代碼生成方法具有同樣的靈活性。從長遠來看，這將使它的適應(yīng)性比 JAXB 更強。
Castor 按照 BSD 樣式的許可證進行發(fā)布，完全可用于商業(yè)用途，而沒有什么重大限制。它看起來相當(dāng)穩(wěn)定，但每當(dāng)遇到需要修正錯誤時，您將需要更新到最新的開發(fā)代碼（或等待新的 beta 測試發(fā)行版）。
與 JAXB 和 Castor 類似，JBind 根據(jù) XML 文檔的 Schema 描述來生成綁定代碼。盡管具有這種相同的性質(zhì)，但實際上 JBind 的著重點與前兩個大不相同。JBind 的主要創(chuàng)建者 Stefan Wachter 稱此著重點為“XML 代碼”，他是這樣描述它的：它將由 Schema 所描述的 XML 數(shù)據(jù)和由 Java 語言代碼所實現(xiàn)的行為組合在了一起。JAXB 和 Castor 更多地著重于使 Java 語言應(yīng)用程序方便地使用 XML，而 JBind 是圍繞 XML 構(gòu)建應(yīng)用程序代碼框架。一旦 JBind 構(gòu)建好框架，則可以用自己的代碼擴展它來添加功能。
圖 5. JBind 生成的類圖（單擊進行放大）
JBind 還 可以 用于常規(guī)的數(shù)據(jù)綁定，在第 2 部分所討論的性能測試中，我就是以這種方式用 JBind 的。但這樣做略微有點笨拙，部分原因是由于 JBind 總是需要在運行時處理文檔的 Schema。如果實例文檔不直接引用相應(yīng)的 Schema，則需要使用特殊的映射文件，或在讀取實例文檔之前，用手工將正確的 Schema 裝入到自己的代碼。目前的文檔不會真正向您顯示這是如何做的。與其它數(shù)據(jù)綁定框架相比，對處理綁定文檔結(jié)構(gòu)的更改，JBind 也很嚴格。通過使用 ListIterator ，可以刪除現(xiàn)有的元素對象，但只有使用生成的 create（創(chuàng)建）方法才能創(chuàng)建新的元素對象，這些方法自動地將這些元素對象添加到現(xiàn)有內(nèi)容的后面。
實質(zhì)上，JBind 采用與前面框架大不相同的方法來處理文檔數(shù)據(jù)。JBind 不生成 JavaBean 樣式的數(shù)據(jù)類（但 JAXB 和 Castor 是這樣做的），而是將一切存儲在文檔模型（目前為 DOM 級別 2 實現(xiàn)）中，構(gòu)建綁定代碼做為前端（facade）來訪問存儲在文檔模型中的數(shù)據(jù)。這是一種非常有趣的方法，如果完全實現(xiàn)，這可能具有一些不錯的跨范例好處。目前這種方法所具有的唯一好處是在生成代碼中 。由于存儲機制相對于 JBind 的主旨是次要的，因此將來這種機制還可能會有所變動。
JBind 所具有的好處是，在考慮過的所有數(shù)據(jù)綁定框架中，它支持 Schema 最徹底，并且提供
上面 所說的 XPath 擴展。如果應(yīng)用程序的核心是處理 XML 文檔，則使用由 JBind 構(gòu)造的“XML 代碼”框架可能非常簡單。對于一般的數(shù)據(jù)綁定用法，如果應(yīng)用程序涉及到 XML 文檔，而不是其重點時，則其它數(shù)據(jù)綁定方法可能會更簡單些。由于數(shù)據(jù)分解時需要驗證以及由于文檔模型后端存儲機制（我將在第 2 部分更詳細地講述此問題），因此與其它框架相比，JBind 還存在明顯的性能劣勢。JBind 是按照 Apache 樣式的許可證分發(fā)的，完全可用于商業(yè)用途。
Quick 文檔將自身描述為：不是作為處理 XML 的工具，而是作為對使用 XML 的 Java 語言的 擴展 。它基于位于 Java 平臺和 XML 之前的一系列開發(fā)成果，在此過程中進行了大量的重構(gòu)工作。它確實為在 Java 平臺上使用 XML 提供了非常靈活的框架 ― 它所具有的靈活性遠遠超出了為寫本文我所能夠了解和使用到的。
圖 6. Quick 生成的類圖（單擊進行放大）
Quick 的靈活性是有代價的。它使用一系列相當(dāng)復(fù)雜的步驟來根據(jù) DTD 文檔描述移到生成的代碼，在此過程中使用了作為中間步驟的三個獨立的綁定模式（不要與 W3C XML Schema 混淆）文檔：
QDML 文檔提供文檔描述，它大致相當(dāng)于 DTD，不過添加了一些類型和繼承。 QJML 文檔定義了 XML 到 Java 語言對象的綁定。 QIML 文件基本上是 QJML 的編譯形式，可以用它來生成實際的綁定代碼。
在第 2 部分 Quick 的性能測試中，我盡可能少地定制這些文件，但為了得到預(yù)期的最終結(jié)果，仍然需要做一些手工編輯。根據(jù) DTD 文法生成 QDML 文件之后，必須編輯該文件來定義文檔的根元素，并為非 String 值（在這里，是幾個 int ）添加類型信息。然后，運行程序來從 QDML 生成 QJML 文件，并編輯生成的 QJML，從而向引用添加類型信息。其實，并不真正需要這一步，但有了這一步，就可以用針對對象引用的特定類型生成代碼（Castor 和 JAXB 代碼生成不支持該特性）。最后，運行該工具以從 QJML 生成 QIML 文件，然后運行代碼生成工具完成整個過程，從而獲得類 JavaBean 的對象類和實際的綁定類（用來從 XML 轉(zhuǎn)換到 Java 類以及從 Java 類轉(zhuǎn)換到 XML）。
再對這些文件進行一些手工編輯，則可以避免生成用于該對象類的新代碼，直接鏈接到 Castor 映射綁定所使用的現(xiàn)有的類。這種可以使用現(xiàn)有類的能力是一項功能非常強大的特性。由于模式文件很復(fù)雜，而且為了利用該特性必須做大量的更改，這些因素稍微降低了 Quick 的實用性，但這確實展示了 Quick 的靈活性。
靈活性是 Quick 最強大的特性。使用 Quick 的主要缺點是各種模式文件的復(fù)雜性，以及缺乏對 Schema 文法的支持。另外，使用 Quick 時，獲得幫助看來也很困難：在論壇和郵件列表中，提出的問題常常得不到任何響應(yīng)。Quick 的許可證遵循 GNU 庫（GNU Library）或次通用公共許可證（Lessor General Public License，LGPL），這種許可證允許自由項目和商業(yè)項目使用該軟件。
象 Quick 一樣，Zeus 也根據(jù) XML 文檔的 DTD 描述生成代碼。（現(xiàn)在正在開發(fā)對 Schema 的支持，但目前處在開發(fā)的 pre-alpha 階段）。這兩種框架只在這個方面是相似的。Quick 復(fù)雜而功能強大，而 Zeus 易于使用 ― 但功能非常有限。
圖 7. Zeus 生成的類圖（單擊進行放大）
在用法上，Zeus 代碼生成類似于 JAXB 或 Castor，它提供了命令行工具來構(gòu)造所需要的類。與使用 JAXB 一樣，綁定使用接口。JAXB 使用工廠來構(gòu)造對象類的新實例，而 Zeus 通過原型使用生成的實現(xiàn)類。用 Zeus 可以生成實現(xiàn)類的子類，當(dāng)對文檔進行數(shù)據(jù)分解時，使用子類而不是使用生成類。
不象前面所討論過的其它任何框架，Zeus 只支持 String ，而不支持其它類型的值，譬如 int 或 Date 。它還缺乏對引用的支持，所以不能直接進行數(shù)據(jù)分解或編組圖結(jié)構(gòu)。這存在很大的局限性 ― 由于數(shù)據(jù)綁定可以利用類型數(shù)據(jù)值和對象間鏈接的透明處理所提供的便利性，因此這給數(shù)據(jù)綁定帶來許多實用性。沒有這些特性的支持，Zeus 更象是一種經(jīng)過裁減的文檔模型，而不象是一個完整的數(shù)據(jù)綁定框架。
如果只使用 String 值，則考慮使用 Zeus 可能是不錯的選擇。使用 Zeus 的主要缺點是，提供的綁定形式有限，從整體上看，該項目進展緩慢。與使用 Quick 一樣，您可能會發(fā)現(xiàn)難以找到問題的答案。Zeus 按照 Enhydra 公共許可證 V1.1 進行分發(fā)，該許可證來自 Mozilla 公共許可證。
在本文中，我討論了幾種不同的框架，這些框架用于根據(jù) XML 文檔文法生成 Java 語言代碼。這只是處理用于 Java 語言應(yīng)用程序的 XML 數(shù)據(jù)綁定的一種方法。另一種主要方法是使用某種形式的映射綁定方法，在映射綁定方法中，構(gòu)建自己的類（或者最初根據(jù)文法來構(gòu)建類，然后修改它們以滿足您的要求），并向綁定框架指定這些類如何與 XML 文檔相關(guān)聯(lián)。每種方法有其利弊，它們都可能有最合適的用武之地。
代碼生成自動構(gòu)建反映 XML 文檔結(jié)構(gòu)（換句話說，是 DTD 或 Schema 形式的文法）的類，這使您可以非?？焖俚亻_始使用文檔。當(dāng)代碼生成基于 Schema 描述時，所構(gòu)造的類可以包括完整的數(shù)據(jù)類型信息（盡管用此方法存在一些問題；許多 Schema 數(shù)據(jù)類型在 Java 語言中沒有直接對應(yīng)的數(shù)據(jù)類型）。用代碼生成，您還可以將驗證構(gòu)建進所構(gòu)造的類中，從而要么自動檢查值（當(dāng)設(shè)置好它們時），要么按照需要檢查有效性。因此，您可以確保通過編組所生成的文檔總是與所期望的結(jié)構(gòu)相匹配。
代碼生成方法的主要缺點是相對于其優(yōu)點而言。通過如此貼實地反映文檔結(jié)構(gòu)，該方法使應(yīng)用程序代碼和文檔結(jié)構(gòu)之間緊密耦合。如果文檔結(jié)構(gòu)發(fā)生變化，再需要重新生成代碼，并修改應(yīng)用程序代碼以使用最終修改后的數(shù)據(jù)類。
通常您還需要使用整個文檔結(jié)構(gòu)，為了生成代碼，不易于對整個結(jié)構(gòu)劃分子集。如果正在使用帶有許多可選組件的復(fù)雜結(jié)構(gòu)（也許作為業(yè)界標準而定義的），而應(yīng)用程序使用的文檔只用這些組件中的某個子集，則這可能會有問題。對于這些框架中的大多數(shù)，使用它們時所生成的類將總是與整個文檔結(jié)構(gòu)匹配。您可能還需要在運行時包含所有這些生成的類，這取決于所使用的框架。對于應(yīng)用程序，這導(dǎo)致代碼過度膨脹以及數(shù)據(jù)模型過度復(fù)雜。當(dāng)然，通過編輯 DTD 或者 Schema 以消除不需要的組件，您可以避免這種情況 ― 但隨之而來當(dāng)基本文法發(fā)生任何變化時，都需要維護您的修改，這又帶來一組新的問題。
映射綁定（譬如由 Castor 或 Quick 實現(xiàn)的映射綁定）比代碼生成具有更大的靈活性。使用真正的對象類將數(shù)據(jù)和行為組合在一起。也可以在一定程度上解除對象類與實際 XML 之間的耦合。修改映射定義（而不需要改變應(yīng)用程序代碼）通常處理 XML 文檔結(jié)構(gòu)中微小的變化。甚至可以用一種格式定義單獨的輸入和輸出映射來對文檔進行數(shù)據(jù)分解，并用另一種格式編組它們。映射綁定的缺點是，在設(shè)置方面，它確實比生成代碼方法需要花費更多精力。
總之，對于所有應(yīng)用程序，沒有一種方法總是最佳的。如果使用由 Schema 或 DTD 定義的穩(wěn)定文檔結(jié)構(gòu)，并且該結(jié)構(gòu)適合應(yīng)用程序的需要，則代碼生成方法可能是最佳方法。如果使用現(xiàn)有的 Java 語言類，或者希望使用類的結(jié)構(gòu)，該結(jié)構(gòu)反映應(yīng)用程序?qū)?shù)據(jù)用法，而不是 XML 文檔結(jié)構(gòu)，則映射方法可能最佳。遺憾的是，當(dāng)前大多數(shù)的開發(fā)工作主要集中在代碼生成而不是映射。這種局限導(dǎo)致目前只有 Castor 和 Quick 才有這種映射方法。
在這第 1 部分中，我回顧了幾種主要的 XML 數(shù)據(jù)綁定框架，這些框架支持根據(jù) XML 文檔描述生成 Java 語言代碼。這些框架在能力方面區(qū)別很大（在性能方面亦是如此，我將在第 2 部分中討論此問題）。在基于 W3C XML Schema 定義的方法中，對于通用的數(shù)據(jù)綁定應(yīng)用程序，Castor 提供了當(dāng)前最佳支持。現(xiàn)在已經(jīng)可以使用 Castor，目前人們正在擴展它以提供更好的生成代碼定制功能和更完善的 Schema 支持。人們還期望 Castor 將來支持即將出現(xiàn)的 JAXB 標準。
一旦 JAXB 作為產(chǎn)品發(fā)行版使用（當(dāng)前的 beta 測試版許可證僅允許用于評估），則它看起來將是一項非常吸引人的選擇。目前 Castor 似乎比 JAXB 支持更多定制，但 JAXB 將提供可在各實現(xiàn)間進行移植的好處。JAXB 也很可能被用在其它 Java 平臺標準（譬如用于 Web 服務(wù)的 JAX-RPC 標準）中，所以編寫 JAXB 的應(yīng)用程序在將來可能在插件上兼容這些標準。
JBind 提供了最佳的 Schema 支持。如果應(yīng)用程序適合“XML 代碼”模型，并且對性能的需求也不迫切，則 JBind 可能是很好的選擇，但對于使用一般的 XML 數(shù)據(jù)綁定，它顯得比較笨拙。Quick 提供了非常大的靈活性且功能強大，但它只支持 DTD 文法，而且使用起來相當(dāng)復(fù)雜。Zeus 簡單且容易，但它（與 Quick 一樣）只支持 DTD，另外，只允許訪問作為 String 值的數(shù)據(jù)。
最后三個框架似乎更適合具有特殊需求的應(yīng)用程序，而非一般用途。如果文檔只有 DTD 描述，而沒有模式，則出于這個原因，您可能希望嘗試 Quick 或 Zeus。對于大多數(shù)應(yīng)用程序，這不是主要關(guān)心的問題，因為有許多可用于將 DTD 轉(zhuǎn)換到模式的應(yīng)用程序（盡管可能需要一些手工調(diào)整）。在 Castor 分發(fā)版中包括了一個這樣的程序（正如在 Castor XML FAQ 中所提到的， org.exolab.castor.xml.dtd.Converter ）。
在第 2 部分中，我將展示這些數(shù)據(jù)綁定框架的性能結(jié)果，這些性能是在一些樣本文檔上使用這些框架測試出的。這些結(jié)果涉及了生成代碼方法和映射綁定方法，為了進行比較，包含了文檔模型。我確實驚訝地看到……，但等等，現(xiàn)在我不能把 一切都告訴您。另外提醒您，在下個星期別錯過這個完全關(guān)于性能的“故事” ― 我保證您會找到值得一讀的結(jié)果！
您可以參閱本文在 developerWorks 全球站點上的
英文原文.
請參與本文的
論壇。（您也可以單擊本文頂部或底部的 討論來訪問該論壇）。
如果要了解有關(guān) XML 的背景知識，請嘗試參加 developerWorks教程
Introduction to XML（2002 年 8 月）。
閱讀作者以前的文章“
Data binding with Castor”，這篇文章講述了 Castor 的映射數(shù)據(jù)綁定技術(shù)（ developerWorks，2002 年 4 月）。
瀏覽作者以前的 developerWorks文章，
性能（2001 年 9 月）和
用法（2002 年 2 月），這兩篇文章比較了幾種 Java XML 文檔模型。
閱讀 Brett McLaughlin 的文章“
Converting between Java objects and XML with Quick”，該文概述了 Quick，并向您展示了如何使用該框架來快速方便地將 Java 數(shù)據(jù)轉(zhuǎn)換成 XML 文檔，而不需要其它數(shù)據(jù)綁定框架所需的類生成語義（ developerWorks，2002 年 8 月）。
有關(guān)對象關(guān)系數(shù)據(jù)綁定的基礎(chǔ)知識簡介，請閱讀“
Getting started with Castor JDO”一文（由 Bruce Snyder 撰寫， developerWorks，2002 年 8 月）。
數(shù)據(jù)綁定框架
查找更多有關(guān)
Java Architecture for XML Binding (JAXB)方面的內(nèi)容，JAXB 是一個處于正在發(fā)展中的 Java 平臺數(shù)據(jù)綁定標準。
更進一步了解
Castor框架，它支持映射綁定和生成綁定。
了解
JBind，它主要偏重于圍繞 XML 構(gòu)建應(yīng)用程序代碼框架，不太注重使 Java 語言應(yīng)用程序方便地使用 XML。
Quick 框架是基于 Java 平臺和 XML 出現(xiàn)之前的一系列開發(fā)成果。它為在 Java 平臺上使用 XML 提供了極其靈活的框架。
研究
Zeus的方方面面，它（類似于 Quick）根據(jù) XML 文檔的 DTD 描述來生成代碼，使用 Zeus 要比使用 Quick 簡單，但同時 Zeus 要更有限。
其它鏈接
閱讀有關(guān)
Java Technology and XML之間的相互影響。
參閱
JSR 31 — XML 數(shù)據(jù)綁定規(guī)范（XML Data Binding Specification）。
在 developerWorks
XML和
Java 技術(shù)專區(qū)查找更多有關(guān)本文所涵蓋的技術(shù)信息。
IBM WebSphere Studio提供了一套使 XML 開發(fā)自動化的工具（用 Java 和其它語言進行開發(fā)）。它與
WebSphere Application Server緊密集成，但它也可以與其它 J2EE 服務(wù)器一起使用。
了解如何成為一名
XML 及其相關(guān)技術(shù)的 IBM 認證開發(fā)人員。
關(guān)于作者
Dennis Sosnoski（
dms@sosnoski.com ）是西雅圖地區(qū)的 Java 技術(shù)咨詢公司
Sosnoski Software Solutions, Inc. 的創(chuàng)始人和首席顧問，他是 J2EE、XML 和 Web 服務(wù)支持方面的專家。Dennis 有 30 多年的專業(yè)軟件開發(fā)經(jīng)驗，最近幾年致力于服務(wù)器端的 Java 技術(shù)。他經(jīng)常在全國性的會議上就 Java 中的 XML 和 J2EE 技術(shù)發(fā)表言論，并主持
Seattle Java-XML SIG。
