用 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 容器服务的一些附加信息。它给出了有关端口的详细信息（包括端口号、协议和安全性），也给出了文档服务信息（包括文档根、用于索引页的默认扩展名以及错误页）。所有这些合在一起，就是配置一个新的 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 方案 ＜?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 文档能接着被转换为生成的类的实例。
本文地址：http://com.8s8s.com/it/it15850.htm