XML到Java代码的数据绑定之对象

　　在这个由四部分组成的系列文章的第一部分，我们将弄清什么是数据绑定，与在Java应用程序中处理XML数据的其它方法相比它有什么优势，以及如何开始使用它。这一部分将考查为什么使用数据绑定，以及如何为各种约束建立模型，使XML文档能转换成Java对象。同时还涵盖用于生成数据绑定类的输入和输出。

　　您希望在您的Java应用程序中使用XML吗？那么好，同成千上万的其他人一起上这条船吧。当您深入了解XML以后，也许您会发现DOM和SAXAPI（请参阅参考资料）不过是唬人的东西。您可能认为肯定存在某种简单方法可以取得XML文档，并通过Java应用程序访问它，对吗？不必通过回调或复杂的树状结构，而是使用像setOwner(Stringowner)和intgetNumOrders()这样的方法，对吗？如果您曾经沿着这一思路考虑问题，那么数据绑定就是您要寻找的解决方案。

　　分析各种选择

　　当今各种XML和XML主义正泛滥成灾（XSL、RDF、命名空间、RSS、XMLSchema、XSLT...），您可能认为现在会有很多方法去访问Java应用程序中的XML数据。令人惊讶的是，如果您寻根究底，实际只存在三种访问XML数据的方法。没错--只有三种方法，其中的一种还是最近随一种新的JavaAPI才出现的。

　　应该这样来看待这一问题：选择范围小使您更易于选出适合于您的方法。

　　回调

　　回调是作为一种事件驱动模型工作的。当分析XML文档时，某些事件--如文档的起始和某个元素中的字符数据的起始--将触发回调方法。通过使用执行逻辑所需的数据，您可以实现这些事件的Java代码。要弄清这种方法不能全靠直觉；开发人员通常要花费一段时间来理解和掌握回调模型的使用。SAX，用于XML的一种简单API，是这种XML使用方法的事实上的标准。

　　树

　　更常见、更流行的是这种API，它们取得一个XML文档，然后创建数据的树状结构。XML文档成为树首，充当一种容器。它有若干子级，如根元素。根元素又有其附加的子级，依此类推，直到（在某种意义上）获得XML数据的一幅图为止。因为几乎每个大学生在某个阶段肯定都处理过树状结构，所以这就可用作表示XML数据的一种非常直观的方法。

　　用于XML文档树状表示的最流行的API就是W3C的推荐标准，即文档对象模型(DOM)。一种更新的API，JDOM（这不是首字母缩写词）最近也正一直在推广并流行开来。（虽然这个方案是我和JasonHunter建立的，但我还得说实话。）另外，DOM和JDOM都是Spinnaker方案设计的基本要求，Spinnaker是一种新的XML分析器，它作为ApacheXML方案的一部分正在开发之中。

　　虽然树状API看起来比事件驱动的SAX更易于使用，但它们并不总是合适的。非常大的文档可能需要大量的内存（尤其是使用DOM时）；当对树结构执行转换(XSLT)时，系统可能停止运转甚至彻底崩溃。虽然更新的API（如JDOM）能处理这些问题，但如果您必须处理极大量的数据，它们仍将是一个问题。并且，有时开发人员宁愿将XML文档中的数据建模为一个简单的带有值的读写方法的Java对象，而不用树状模型工作。例如，开发人员会宁愿不去访问名为skuNumber的子节点并设置该节点的文本值，而只想调用setSkuNumber("mySKU")并继续进行。


　　用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文档，然后再来处理这些问题，则决策树的意义就更加清楚了。此示例文档表示EnhydraApplicationServer中某个服务（具体说就是一个web容器）的配置。

　　清单1.一个用于配置Enhydra中的web容器的XML文档＜?xmlversion="1.0"?＞


　　＜webServiceConfigurationversion="1.0"name="MyWebContainer"＞
　　＜portnumber="80"protocol="http"protected="false"/＞
　　＜documentroot="/usr/local/enhydra/html"index="*.html,*.xml"error="error.html"/＞
　　＜/webServiceConfiguration＞


　　此配置文档包含有关服务本身的版本和名称的信息，以及几个嵌套的项目，每个项目都表示有关该web容器服务的一些附加信息。它给出了有关端口的详细信息（包括端口号、协议和安全性），也给出了文档服务信息（包括文档根、用于索引页的默认扩展名以及错误页）。所有这些合在一起，就是配置一个新的web容器服务所需的全部信息。

　　记住这个示例，您就可以开始回答数据表示的各个问题了。

　　是否适合转换？

　　绝对适合！只要看一看清单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容器服务的数据接口。

　　清单2.表示一个web容器配置文档的数据接口的XML方案＜?xmlversion="1.0"?＞


　　＜schematargetNamespace="http://www.enhydra.org"xmlns="http://www.w3.org/1999/xmlSchema"xmlns:enhydra="http://www.enhydra.org"＞

　　＜complexTypename="ServiceConfiguration"＞
　　＜attributename="name"type="string"/＞
　　＜attributename="version"type="float"/＞
　　＜/complexType＞


　　＜elementname="serviceConfiguration"type="ServiceConfiguration"/＞

　　＜complexTypename="WebServiceConfiguration"baseType="ServiceConfiguration"derivedBy="extension"＞
　　＜elementname="port"＞
　　＜complexType＞
　　＜attributename="protocol"type="string"/＞
　　＜attributename="number"type="integer"/＞
　　＜attributename="protected"type="string"/＞
　　＜/complexType＞
　　＜/element＞

　　＜elementname="document"＞
　　＜complexType＞
　　＜attributename="root"type="string"/＞
　　＜attributename="index"type="string"/＞
　　＜attributename="error"type="string"/＞
　　＜/complexType＞
　　＜/element＞
　　＜/complexType＞

　　＜elementname="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代码publicinterface

　　ServiceConfiguration{
　　publicvoidsetVersion(floatversion);
　　publicfloatgetVersion();
　　publicvoidsetName(Stringname);
　　publicStringgetName();
　　}

　　　这是相当明白易懂的；清单3中的接口为XML方案中定义的属性提供读方法和写方法。另外，您将需要生成一个实现类来定义此接口的各个成员变量，并实现此接口中的每个方法。这种使接口从实现中分离出来的方法使我们能够为特定的需要提中供多种实现。例如，某个特定的服务可能需要执行计算，而不只是接受从写方法中收到的值。现在考虑那种更复杂的情况还有点为时尚早，但我将在后续文章中重新提到它。然而，一般说来，您仍可以确定实现类应该像什么样子，如清单4所示。

　　清单4.为ServiceConfiguration实现而从XML方案生成的Java代码publicclass

　　ServiceConfigurationImplimplementsServiceConfiguration{
　　privateStringname;
　　privatefloatversion;

　　publicvoidsetVersion(floatversion){
　　this.version=version;
　　}

　　publicfloatgetVersion(){
　　returnversion;
　　}

　　publicvoidsetName(Stringname){
　　this.name=name;
　　}

　　publicStringgetName(){
　　returnname;
　　}
　　}

　　相同的原则也适用于XML方案中定义的其它对象。您可以在下面查看到其它Java类（因为它们都是应该生成的）：

　　PortType.java
　　PortTypeImpl.java
　　DocumentType.java
　　DocumentTypeImpl.java
　　WebServiceConfiguration.java
　　WebServiceConfigurationImpl.java

　　总结

　　到目前为止，您应该对数据绑定的各个方面都比较熟悉了。我已初步介绍了您应该使用数据绑定的原因，尤其是在配置信息的范围内，并概述了为实现此方法您所需要了解的一些基本概念。