從XML到Java代碼的資料繫結之一

本文轉自 IBM developerWorks 中國網站

　　　　　　　　　　　　　　　　　對象，無處不在的對象

　　在這個由四部分組成的系列文章的第一部分，我們將弄清什麼是資料繫結，與在 Java 應用程式中處理 XML 資料的其它方法相比它有什麼優勢，以及如何開始使用它。這一部分將考查為什麼使用資料繫結，以及如何為各種約束建立模型，使 XML 文檔能轉換成 Java 對象。同時還涵蓋用於產生資料繫結類的輸入和輸出。

　　您希望在您的 Java 應用程式中使用 XML 嗎？那麼好，同成千上萬的其他人一起上這條船吧。當您深入瞭解 XML 以後，也許您會發現 DOM 和 SAX API（請參閱參考資料）不過是唬人的東西。您可能認為肯定存在某種簡單方法可以取得 XML 文檔，並通過 Java 應用程式訪問它，對嗎？不必通過回調或複雜的樹狀結構，而是使用像 setOwner(Stringowner) 和 int getNumOrders() 這樣的方法，對嗎？如果您曾經沿著這一思路考慮問題，那麼資料繫結就是您要尋找的解決方案。

　　分析各種選擇

　　當今各種 XML 和 XML 主義正泛濫成災（XSL、RDF、命名空間、RSS、XML Schema、XSLT...），您可能認為現在會有很多方法去訪問 Java 應用程式中的 XML 資料。令人驚訝的是，如果您尋根究底，實際只存在三種訪問 XML 資料的方法。沒錯 -- 只有三種方法，其中的一種還是最近隨一種新的 Java API 才出現的。

　　應該這樣來看待這一問題：選擇範圍小使您更易於選出適合於您的方法。

　　回調

　　回調是作為一種事件驅動模型工作的。當分析 XML 文檔時，某些事件 -- 如文檔的起始和某個元素中的字元資料的起始 -- 將觸發回調方法。通過使用執行邏輯所需的資料，您可以實現這些事件的 Java 代碼。要弄清這種方法不能全靠直覺；開發人員通常要花費一段時間來理解和掌握回調模型的使用。SAX，用於 XML 的一種簡單 API，是這種 XML 使用方法的事實上的標準。

　　樹

　　更常見、更流行的是這種 API，它們取得一個 XML 文檔，然後建立資料的樹狀結構。XML 文檔成為樹首，充當一種容器。它有若干子級，如根項目。根項目又有其附加的子級，依此類推，直到（在某種意義上）獲得 XML 資料的一幅圖為止。因為幾乎每個大學生在某個階段肯定都處理過樹狀結構，所以這就可用作表示 XML 資料的一種非常直觀的方法。

　　用於 XML 文檔樹狀表示的最流行的 API 就是 W3C 的推薦標準，即文件物件模型 (DOM)。一種更新的 API，JDOM （這不是首字母縮寫詞）最近也正一直在推廣併流行開來。（雖然這個方案是我和 Jason Hunter 建立的，但我還得說實話。）另外，DOM 和 JDOM 都是 Spinnaker 方案設計的基本要求，Spinnaker 是一種新的 XML 分析器，它作為 Apache XML 方案的一部分正在開發之中。

　　雖然樹狀 API 看起來比事件驅動的 SAX 更便於使用，但它們並不總是合適的。非常大的文檔可能需要大量的記憶體（尤其是使用 DOM 時）；當對樹結構執行轉換 (XSLT) 時，系統可能停止運轉甚至徹底崩潰。雖然更新的 API（如 JDOM）能處理這些問題，但如果您必須處理極大量的資料，它們仍將是一個問題。並且，有時開發人員寧願將 XML 文檔中的資料建模為一個簡單的帶有值的讀寫方法的 Java 對象，而不用樹狀模型工作。例如，開發人員會寧願不去訪問名為 skuNumber 的子節點並設定該節點的文本值，而只想調用 setSkuNumber("mySKU") 並繼續進行。

　

術語解釋 　　資料繫結:從 Java 應用程式內部訪問 XML 資料的一種新方法，使用仍在開發中的一種 API，JSR-031。 　　JSR-031: Sun 仍在開發中的一種新的 Java 規範請求，設計用於將 XML 文檔編譯成一個或多個 Java 類，而在 Java 應用程式中可以方便地使用這些 Java 類。 　　打包:將 Java 對象轉換為 XML 表示，擁有當前值。 　　解包:根據 XML 對象建立 Java 對象，通常是根據打包產生一個 Java 對象。

　　用 Java 代碼訪問 XML 資料的最新方法要依賴於一套新的 Java 方法和相關的 API，這些 API 仍在開發之中。資料繫結是由 Sun 構建的一種“Java 規範要求”（JSR-031，見參考資料），它設計用於使 Java 對象綁定到 XML 文檔更加方便，這樣就使一種格式能夠容易地轉換為另一種格式，反之亦然。綁定引用一個具有讀寫方法的 Java 對象，讀寫方法都會影響到底層的 XML 文檔，並且也都直接映射為 XML 文檔中的元素及特徵的名稱。當您進入到本系列文章下一部分中的某些細節時，這一說明會更有意義，但在目前，只說一點就夠了：這樣做使 XML 文檔特徵 name 能夠通過一個稱為 setName() 的方法，來更改它的值，就像我上面暗示的那樣。

　　資料繫結

　　這種訪問方式正在得到普及，並且當在 XML 文檔中儲存配置資訊時特別有用。許多開發人員發現，它非常便於直接存取所需的參數，而無須使用更複雜的樹狀結構。雖然這種訪問對於文檔轉換或訊息傳送沒有什麼用處，但它對於簡單資料處理是極其方便的。它是我們在本文及本系列文章中關注的第三種使用 XML 的方法。

　　（當然，任何方法隨後都會引出一系列新的術語，所以請查看術語解釋以瞭解這些新的行話。）

　　是否任何 XML 文檔都可以轉換為 Java 對象？還是僅有某些類型的 XML 文檔才可以？問得好！您很可能只希望將滿足一組約束條件的文檔轉換為 Java 對象。這與定義 Java 介面的方法類似：您確保只執行個體化和使用適應該介面的對象，允許就如何操作該對象作出假定。同樣，您只允許將滿足一組約束條件的 XML 對象轉換成 Java 對象；這使您能夠按希望的方式來使用所建立的對象。

　　約束資料

　　在研究代碼之前，您需要回答幾個有關如何表示 XML 資料的問題。這是資料繫結的最具挑戰性的方面之一。是為每個文檔建立一個新類，還是建立某個現有類的一個執行個體？您要使用哪個現有類？並且最重要的是，您正在處理的文檔是否適宜轉換為 Java 對象？

　　那是一大堆問題，但您將在這裡找到全部答案。將這些問題看作一系列決策點，一系列選擇。首先，您必須確定您能否從該 XML 文檔建立 Java 對象（如前面所討論的那樣）。如果能，您就要決定轉換應該以新 Java 類的形式出現，還是僅以現有類的一個執行個體的形式出現。最後，如果選擇了現有類，那麼使用哪個類呢？結果就是各種各樣的決策樹。

　　如果我們考察清單 1 中所示的一個樣本 XML 文檔，然後再來處理這些問題，則決策樹的意義就更加清楚了。此範例文件表示 Enhydra Application Server 中某個服務（具體說就是一個 web 容器）的配置。

清單 1. 一個用於配置 Enhydra 中的 web 容器的 XML 文檔 ＜?xml version="1.0"?＞

＜webServiceConfiguration version="1.0" name="My Web Container" ＞ ＜port number="80" protocol="http" protected="false" /＞ ＜document root="/usr/local/enhydra/html" index="*.html,*.xml" error="error.html" /＞ ＜/webServiceConfiguration＞

　　此配置文檔包含有關服務本身的版本和名稱的資訊，以及幾個嵌套的項目，每個項目都表示有關該 web Container Service的一些附加資訊。它給出了有關連接埠的詳細資料（包括連接埠號碼、協議和安全性），也給出了文檔服務資訊（包括文檔根、用於索引頁的預設副檔名以及錯誤頁）。所有這些合在一起，就是配置一個新的 web Container Service所需的全部資訊。

　　記住這個樣本，您就可以開始回答資料表示的各個問題了。

　　是否適合轉換？

　　絕對適合！只要看一看清單 1 中的 XML 文檔就會發現，它表示一個對象（總體設定物件），具有若干特徵或變數。其中某些變數又是另外的對象（連接埠和文檔），這些對象又具有它們自己的特徵。實際上，這是適合轉換為 Java 對象的 XML 文檔的一個極好例子。為了進一步保證此對象是可用的，稍後我將向您展示一種方法來約束文檔中的資料。但是，還是先讓我們繼續沿著決策樹往下走。

　　轉換成類還是執行個體？

　　解決適宜性問題以後，現在就可以作出決定，是將每個 XML 配置文檔都變為一個全新的 Java 類呢，還是簡單地將其變為某個現有類的一個新執行個體。換句話說，就是到底應該產生新代碼，還是利用現有的代碼。照這樣來看，這就變成了一個簡單的可重用性問題。更容易且更明智的做法是，為每個 XML 文檔產生現有類的新執行個體。如果您一定要嘗試一下從每個文檔建立一個新的 Java 類，則得到的各個類之間可能沒有相容性 -- 即兩個完全相同的文檔可能導致兩個不同的 Java 類！

　　不用這個可能引起混亂的方法，您可以採用一組 XML 約束條件（由一個 DTD 或 XML 方案表示，將在下面講述），並根據這些約束條件來產生一個 Java 類（或多個類，根據需要）。這個產生的類將表示符合這些約束條件的任何 XML 文檔；這些 XML 文檔中的每一個都將被解包到產生的類的一個執行個體中。在這種情況下，就可以為表示 web 服務配置的文檔定義約束條件。這些約束條件將被映射為一個 Java 類，我們將稱之為 WebServiceConfiguration。然後您就可以獲得任何一種表示特定 web 服務配置的 XML 文檔，並假定此文檔符合我們的約束條件，由它而建立出前面產生的類的一個執行個體。這將允許應用程式將不同的 XML 文檔用作相同類型的對象，只要這些文檔中的資料對於該對象設計時要達到目的來說是有效即可。

　　新類還是現有的類？

　　現在您也已經有條件回答下一個問題了：您希望建立一個現有類即 WebServiceConfiguration 類的一個執行個體。剩下需要弄清的全部事情是，這個類是如何預先產生的。所以，現在請將您的注意力集中在這樣一個問題上：如何獲得一組約束條件，用 XML 實現它們，並保證文檔符合這些約束？再一個問題就是，您如何再從這些約束條件產生一個可重用的 Java 類？

　　利用文檔約束條件

　　既然您知道此文檔將轉換成一個 Java 執行個體，這就產生了另一個問題：要考慮到必須以某種方式保證可將此文檔正確地解包到一個選定的 Java 類中。缺少變數或資料類型不正確都可能導致在解包過程中出錯 -- 或者甚至在客戶機訪問配置錯誤的容器時出現運行時異常。

　　最好的情況是，在實際的解包過程開始之前，文檔的作者能夠保證，配置文檔對於他們選擇用來表示資料的類是“合法的”。閱讀到這一方案的 XML 人士說不定就會轉動他們的眼睛並嘀咕說，“好吧，當然您將使用 XML 文檔約束條件。”確認資料對選定類的合法性可以通過引用 DTD （文件類型定義）或 XML 方案來完成。

　　通過使用一組用外部 DTD 或方案檔案表示的約束條件，文檔作者就可以在這些資料的“介面”上測試組態資料。換句話說，您可以這樣來建立應用程式，使之能夠對照所需的資料來檢查包含在 XML 執行個體文檔中的資料，而所需資料則是在文檔約束條件的外部檔案中指定的。這樣，您就可以為資料建立一個介面。

　　在使用 DTD 方案還是使用 XML 方案之間作出決策是一種相當簡單的選擇：因為 Java 語言是高度類型化的，所以我們希望能在 XML 文檔中支援類型化。例如，資料介面應該能夠驗證，為 web 容器的連接埠號碼提供的是整數，而不是字串，後者在服務啟動時將引起錯誤。DTD 不支援類型檢查，所以我們無疑應該選擇 XML 方案。雖然 XML 方案在規範的領域在有一點不確定性，但它在很大程度上已趨於穩定，並可望在年內定型。我們可以在一個 XML 方案中編寫資料約束條件，然後用這個方案驗證可能的執行個體文檔，以確保解包能在這些執行個體文檔上進行。下面的 XML 方案表示我們的 web Container Service的資料介面。

　　清單 2. 表示一個 web 容器配置文檔的資料介面的 XML 方案 ＜?xml version="1.0"?＞

＜schema targetNamespace="http://www.enhydra.org" xmlns="http://www.w3.org/1999/xmlSchema" xmlns:enhydra="http://www.enhydra.org" ＞ ＜complexType name="ServiceConfiguration"＞ ＜attribute name="name" type="string" /＞ ＜attribute name="version" type="float" /＞ ＜/complexType＞ ＜element name="serviceConfiguration" type="ServiceConfiguration" /＞ ＜complexType name="WebServiceConfiguration" baseType="ServiceConfiguration" derivedBy="extension"＞ ＜element name="port"＞ ＜complexType＞ ＜attribute name="protocol" type="string" /＞ ＜attribute name="number" type="integer" /＞ ＜attribute name="protected" type="string" /＞ ＜/complexType＞ ＜/element＞ ＜element name="document"＞ ＜complexType＞ ＜attribute name="root" type="string" /＞ ＜attribute name="index" type="string" /＞ ＜attribute name="error" type="string" /＞ ＜/complexType＞ ＜/element＞ ＜/complexType＞ ＜element name="webServiceConfiguration" type="WebServiceConfiguration" /＞ ＜/schema＞

　　清單 2 中的 XML 方案定義了幾個不同的資料對象，它們合起來表示一個 web 服務的設定物件。首先，定義了一個核心服務配置（serviceConfiguration），它包含版本和名稱。這可用作所有服務（如負載平衡服務、EJB 容器，當然還有我們的 web 服務）的基本對象。然後，作為此基本服務的擴充，又定義了 web 服務配置（webServiceConfiguration）。請注意，Java 成型之後，方案就已經為資料介面建立了模型。我們將附加的 web 服務屬性 port 和 document 添加到 version 和 name 基本屬性中。這些屬性本身都是對象，具有它們自己的屬性（protocol、root、error 等）。

　　在此方案的定義方式中，特徵代表簡單的 Java 類型，通常是原始 (primitive) 類型。這樣，name 和 version 就分別成為類型 String 和 float 的 Java 原始類型。port 和 document 這樣的元素成為 Java 對象，它們可以有自己的屬性，還是用特徵來表示。這樣就出現了遞迴現象：元素變成新對象，並對它的每個屬性進行檢查。如果屬性是一個特徵，就為此對象建立一個簡單的 Java 原始成員變數；如果屬性是元素，則建立一個新的對象，並作為一個成員變數將其添加，然後在這個新對象上又開始同樣的過程，直到全部類都已建立為止。

　　從蘿蔔 ... 嗯 ... XML 獲得 Java

　　一旦建立了 XML 方案，您就需要從這個方案中提取出必需的資訊，來確定應該建立哪些 Java 類。這個過程的第一步是查看 XML 方案，並嚴格確定輸出應該是什麼。對於簡單的 serviceConfiguration 對象，定義了兩個 Java 原始屬性：name 和 version。對於這樣一個簡單的對象，確定所需的介面並不難。只需將被定義類型的名稱的首字母大寫，並將這些 Java 屬性添加到介面中即可，如清單 3 所示。

　　清單 3. 為 ServiceConfiguration 介面而從 XML 方案產生的 Java 代碼 public interface

ServiceConfiguration { 　public void setVersion(float version); 　public float getVersion(); 　public void setName(String name); 　public String getName(); }

　　　這是相當明白易懂的；清單 3 中的介面為 XML 方案中定義的屬性提供讀方法和寫方法。另外，您將需要產生一個實作類別來定義此介面的各個成員變數，並實現此介面中的每個方法。這種使介面從實現中分離出來的方法使我們能夠為特定的需要提中供多種實現。 例如，某個特定的服務可能需要執行計算，而不只是接受從寫方法中收到的值。現在考慮那種更複雜的情況還有點為時尚早，但我將在後續文章中重新提到它。然而，一般說來，您仍可以確定實作類別應該像什麼樣子，如清單 4 所示。

　　清單 4. 為 ServiceConfiguration 實現而從 XML 方案產生的 Java 代碼 public class

ServiceConfigurationImpl implements ServiceConfiguration { 　private String name; 　private float version; 　public void setVersion(float version) { 　　this.version = version; 　} 　public float getVersion() { 　　return version; 　} 　public void setName(String name) { 　　this.name = name; 　} 　public String getName() { 　　return name; 　} }

　　相同的原則也適用於 XML 方案中定義的其它對象。您可以在下面查看到其它 Java 類（因為它們都是應該產生的）：

　　PortType.java

　　PortTypeImpl.java

　　DocumentType.java

　　DocumentTypeImpl.java

　　WebServiceConfiguration.java

　　WebServiceConfigurationImpl.java

　　總結

　　到目前為止，您應該對資料繫結的各個方面都比較熟悉了。我已初步介紹了您應該使用資料繫結的原因，尤其是在配置資訊的範圍內，並概述了為實現此方法您所需要瞭解的一些基本概念。

　　此系列文章的下一篇將繼續考察資料繫結的過程。您將有機會去檢查 org.enhydra.xml.binding.SchemaMapper 類，它將接受這第一部分中建立的 XML 方案作為資料介面，並從它建立出一個 Java 介面和實作類別。本系列文章的第二部分將詳細說明這一過程的每個步驟，並說明如何確保方案被準確表示，以便 XML 文檔能接著被轉換為產生的類的執行個體。