XML与java文档格式.docx

1、去年，我写了一篇文章，讲述了如何使用 Castor 框架以进行 Java 对象到 XML 文档的映射数据绑定。我曾经答应要写一篇后续文章，其中将探讨代码生成方法，包括介绍 JAXB，Java Community Process（JCP）正在开发 JAXB，它是用 Java 语言编写的、用于数据绑定的标准 API。就在较早的那篇文章发布不久，Sun 宣布对 JAXB 的方向做出了重大调整（请参阅 重新架构 JAXB）。由于这方面的变化，所以我想，为了更贴近最终的 JAXB 代码，最好先不写这篇后续文章，现在，我很高兴，终于可以写这篇文章了！数据绑定字典下面是一个微型字典，里面包含了我在本文中所使

2、用的一些术语：文法（Grammar） 是用于定义一系列 XML 文档结构的一套规则。其中一类文法是 XML 规范所定义的文档类型定义（Document Type Definition，DTD）格式。另一类日渐普及的文法是 XML Schema 规范所定义的 W3C XML Schema（Schema）格式。文法定义了哪些元素和属性可以出现在文档中，以及在文档中元素是如何嵌套的（通常包括嵌套元素的次序和数目）。一些类型的文法（譬如 Schema）还可以更进一步，使字符数据内容与特定数据类型甚至正则表达式相匹配。在本文中，我会常使用术语 描述， 将它作为引用一系列文档的文法的非正式方法。编组（Ma

3、rshalling）是在内存中为对象生成 XML 表示的过程。与 Java 对象序列化一样，这种表示需要包含所有依赖的对象：我们的主对象引用的对象、这些对象引用的对象等等。数据分解（Unmarshalling） 是与编组相反的过程，在内存中根据 XML 表示构建一个对象（而且可能是链接对象的图）。在本文中，我将讨论根据 XML 文档文法生成 Java 语言代码的五种 XML 数据绑定框架：JAXB、Castor、JBind、Quick 和 Zeus。它们都可以免费获取，除了 JAXB 之外，其它四种框架都可以在开放源码和专利项目中使用。当前 JAXB 参考实现 beta 测试版的许可证只允许用

4、于评估，但当它作为产品发行时，这种情形很可能会改变。JAXB、Castor 和 JBind 都提供了根据 XML 文档的 Schema 描述生成代码，而 Quick 和 Zeus 根据 DTD 描述生成代码。Castor 和 Quick 还支持将现有类映射到 XML，以此作为另一种生成代码的方法。这些框架各有优缺点，所以我会试图逐步指出每种框架所具有的最佳（和最差）特性。在第 2 部分，我将进一步向您显示这些框架如何对一些样本文档进行处理，另外，还将探讨，对于许多类型的应用程序，现有的数据绑定框架怎么会缺乏一些重要的特性。相对于我在以前文章中所描述的映射绑定方法，根据 Schema 或 DTD

5、 文法生成 Java 语言代码具有一些突出的优点。使用生成的代码，您可以确定数据对象被正确地链接到 XML 文档，不象映射绑定方法，需要直接指定链接，并确保正确地涵盖了所有的结构变体。在使用 Schema 时，甚至可以利用文法所提供的类型信息，用合适的数据类型来生成代码。代码生成方法也有一些不足之处。这种方法造成应用程序数据结构与 XML 文档结构之间紧密耦合。另外，它还可能限定您使用简单的数据类（没有关联行为的被动数据容器），而不是真正的对象类，在编组和数据分解过程中，还可能限制应用数据的定制转换的灵活性。在本文后面，我会权衡代码生成和映射绑定这两种方法（请参阅 映射绑定 vs. 代码生成）

6、。回页首数据和代码对于将在第 2 部分中讨论的性能测试，我用每一种数据绑定框架来生成代码。用于性能测试的文档包含模拟航班时刻表的信息。下面是一个样本文档，您可以感受一下其中的结构：清单 1. 样本文档timetable 9URL/URLnameArctic Airlines/carrierCA7Combined AirlinesSeattle, WASeattle-Tacoma International AirportLAXLos Angeles, CALos Angeles International Airport426depart6:23aarrive8:42a/flight83310

7、a10:52a4339:00a11:36a3117:45a20a59327a12:04p10230p3:07p图 1 显示了用于映射数据绑定到这些文档的类结构。为了进行比较，我将在有关各个数据绑定框架章节中显示生成的类结构。这里包含的这些图仅仅是所有情况的缩略图；如果要看全图，请单击这个小图像。图 1. 映射绑定类图（单击进行放大） JAXB 面前的漫漫长路用于 XML 绑定的 Java API（Java API for XML Binding，JAXB）是一个处于不断发展中的 Java 平台数据绑定标准。Java Community Process 正在开发作为“JSR-31 XML 数据绑

8、定规范（XML Data Binding Specification）”的 JAXB。该项目始于 1999 年 8 月，其目的是定义一种方法，生成与 XML 结构相链接的 Java 语言代码。最初打算在 2000 年第 2 季度发布，但最后在 JavaOne 2001 上宣布了初步的 Early Access（EA）版本，该版本在 2001 年 6 月向公众发布。JAXB 的 EA 版本基于具有创新意义的拉解析器（pull parser）设计，这种设计使验证可以方便地构建到生成的数据分解代码中。它根据 DTD 生成代码，构建在解析 XML 文档时自动验证 XML 文档结构（而不是数据）的类。我

9、们期望这种方法能快速和有效地处理 XML 和 Java 语言对象之间的转换，但 EA 代码仅仅是部分实现，显然在成为完整的实现之前，仍需要做大量工作。专家组不久之后开始收到关于 EA 发行版的反馈。作为对反馈意见的部分响应中，他们研究决定重新架构 JAXB，之后更新了网站，声明 JAXB 在几个方面正在得到增强。该站点还声明，下一版本在 API 级上不与早期版本兼容 但您仍然可以下载 EA 版本。重新架构 JAXB直到 2002 年 3 月，新体系结构的细节才公布于众，在 JavaOne 上，Sun 宣布，作为在 JAXB 方面进一步工作的基础，实际上正在放弃 EA 代码。它将被新设计所替代，

10、在新设计中，共享了一些常见的功能，但新设计使用不兼容的 API 和内部体系结构。发展方向变化如此之大，让我和那些对 EA 代码有兴趣的人们感到惊讶。JAXB 项目的 SUN JSR 负责人 Joseph Fialli 把这么大的变化归结为以下一些因素。主要问题是扩展原有代码库以支持 W3C XML Schema 的复杂性。这是一个相当复杂的规范，以至于在批准之后的两年多时间里，在所有平台上，仍然只有少数几个解析器能接近完全符合规范。最初的 JAXB 代码需要实际对象来控制验证，而且将这种方法扩展到 Schema 将耗费太多精力，以至于在合理的期限内无法实现这项工作。为适应 Schema 而做出

11、变更的同时，专家组还决定重新考虑处理验证的方法。原来的 JAXB 代码无条件地验证文档的结构，如果发现错误，则抛出异常并中止处理。Fialli 说，在公众的意见中，抱怨这种方法局限性太大、限制太严 在一些情况下，用户希望能够一次检查多个验证错误，而在另一些情况下，则希望完全禁用验证（或者由于性能原因，或者在编组没有精确匹配文法的文档时）。新的 JAXB 体系结构能够满足这两种需求。最后，专家组决定放弃单个绑定框架运行时（就象在原来 EA 发行版中所看的）的想法。而采用接口方法，其实质是可以使用不同的数据绑定框架。这使用户代码可以在各框架之间进行移植，而不需移植生成的类 这些类特定于专门的数据绑

12、定框架，它们只能由该框架运行。强制性的 SAX 2.0 解析器支持替代了 EA 运行时中所使用的拉解析器方法，对于其它解析器（可能包括新的拉解析器，该解析器基于用于 XML 的流式 API，JSR 173 正在定义此 API），提供可选的特定于框架的支持，数据结构本身被更改为类 JavaBean 的数据对象，外部框架可以方便地操作此数据对象。JAXB beta 测试版自 3 月以来，JAXB 项目一直在朝着这个新方向前进。这一工作的第一个公开成果是，去年夏天发布了该规范的新草案（但草案仍处于准备阶段）。接着在 10 月，Sun 提供了 JAXB 参考实现新的 beta 测试版，最终它会替代过时

13、已久的 EA 版本。在这些文章中，我用这个最近的 beta 测试版进行评估和性能测试。它直接根据 Schema 文档描述进行工作，生成与为文档所定义的元素类型和用法相匹配的类的层次结构。该层次结构包括四种常规类型的类：用于已定义类型的接口、用于实际元素的接口和这两组接口的实现。图 2. JAXB 接口类图（单击进行放大） 图 3. JAXB 实现类图（单击进行放大） 从应用程序的角度来看，类型接口是这些类最有趣的部分。对于类型内的数据，存在着 JavaBean 样式的 get 方法和 set 方法集合。包含在类型接口中的这些方法遵循 JAXB 规范所规定的规则，所以应用程序代码可以安全地使用这

14、些接口来访问所有数据，同时还保持了 JAXB 实现间的可移植性。这些接口使 JAXB 生成的代码可以相当容易地与现有文档一起使用。然而，构造和修改数据结构有点困难。因为使用接口，所以不能直接构造实例；而是必须使用工厂方法创建实例，然后使用类 JavaBean 的取值方法来填充数据值。用 JAXB 根据 Schema 描述生成代码非常简单。所提供的绑定编译器 xjc 是一个命令行工具。它将 Schema 文档作为输入，将文件生成到指定的输出包和目标目录。其中所具有的选项还使用户可以控制生成的代码文件是否是只读的，以及是否严格验证 Schema 描述。通过使用绑定声明，JAXB 规范定义了一些方法

15、来定制生成数据绑定的一些方面。包括： 用于控制所生成类的名称和属性的选项 指定由绑定所使用的现有实现类的方法 允许（有限地）控制验证处理和用于编组和数据分解的序列化器反序列化器（serializer/deserializer）的选项 要么在实际的 Schema 文档中以注释形式嵌入这些定制，要么通过使用单独的外部绑定声明文档来单独提供这些定制。参考实现的当前 beta 测试版只支持第一种方法，但在以后的发行版中将支持使用外部绑定声明文档。总体说来，JAXB 正成为一种功能强大而灵活的工具，它用于将 Java 语言代码绑定到 W3C XML Schema 文法所定义的文档。由于有可能批准将 JA

16、XB 作为一个 Java 平台标准，因此它将会受到广泛支持，而且在各实现之间移动绑定应用程序会象在 servlet 引擎之间移动 Web 应用程序一样容易（一般来讲，很简单，但偶尔也会有一些波折）。然而，JAXB 确实也有一些缺点。目前最大的局限是只有用于评估用途的许可证。在该产品发行版（目前计划在这个季度发布）之前，JAXB 还无法用于实际项目中。另外，定制的程度也局限于只能应用到生成的代码。在许多情形中，您可以为 JAXB 所定义的接口定义自己的实现类，但这些接口本身总是与 Schema 描述联系在一起，不太可能进行修改。Castor用于 XML 数据绑定的 Castor 框架支持映射绑定

17、和生成绑定。在我的上一篇文章中，我讨论了 Castor 映射绑定方法的一些特性。对于本文，我只讨论根据 Schema 生成代码，但在第 2 部分，我将研究这两种方法的性能。请回顾以前的文章（请参阅 参考资料），了解有关 Castor 中映射数据绑定工作方式的更多信息。图 4. Castor 生成的类图（单击进行放大） 在一些细节上，Castor 的代码生成支持不同于 JAXB 方法，但在目的上，两者非常相似。与使用 JAXB 一样，Castor 向应用程序提供类 JavaBean 结构的数据模型。主要差别在于 Castor 避免使用接口，而是喜欢直接使用生成的实现类。除了每个实现类，Casto

18、r 还生成描述符（descriptor）类，该类包含绑定和验证代码。由于 Castor 使用具体的类，而不是接口，因此对于构造或修改文档数据结构，它要比 JAXB 略微简单。可以仅仅直接使用相应类的构造函数，而不用通过工厂类。Castor 的当前 beta 测试版（我写这篇文章时，该版本为 0.9.4.1）不支持在代码生成中进行任何实质的定制，但这种情况有望得到改变。下一 beta 测试发行版预计将支持使用映射文件来控制代码生成的各个方面。起初，在这些方面中，只支持类名和包名，但从更长远来看，计划将添加对用户所提供的实现类的支持。Castor 开发人员还计划在 Castor 中支持 JAXB，

19、可能是通过使用某类兼容性层来实现这一点。用 Castor 根据 Schema 描述生成代码与用 JAXB 一样方便，使用的基本选项也一样。Castor 确实使用一些附加的命令行参数选项，而且通过属性文件设置，甚至提供了更多选项。这些选项主要用在一些特殊的情形中，但不包括象 JAXB 那样通过 Schema 文档注释提供对类名和验证的控制。现在，用 Castor 来生成源代码这种方法的主要缺点是对定制的支持有限。这种情形正在开始发生转变，可以用 Castor 的映射数据绑定方法来实现实质的定制（见前一篇文章中的描述 请参阅 参考资料），我期望最终在定制方面至少与源代码生成方法具有同样的灵活性。从

20、长远来看，这将使它的适应性比 JAXB 更强。Castor 按照 BSD 样式的许可证进行发布，完全可用于商业用途，而没有什么重大限制。它看起来相当稳定，但每当遇到需要修正错误时，您将需要更新到最新的开发代码（或等待新的 beta 测试发行版）。JBind与 JAXB 和 Castor 类似，JBind 根据 XML 文档的 Schema 描述来生成绑定代码。尽管具有这种相同的性质，但实际上 JBind 的着重点与前两个大不相同。JBind 的主要创建者 Stefan Wachter 称此着重点为“XML 代码”，他是这样描述它的：它将由 Schema 所描述的 XML 数据和由 Java 语

21、言代码所实现的行为组合在了一起。JAXB 和 Castor 更多地着重于使 Java 语言应用程序方便地使用 XML，而 JBind 是围绕 XML 构建应用程序代码框架。一旦 JBind 构建好框架，则可以用自己的代码扩展它来添加功能。图 5. JBind 生成的类图（单击进行放大） JBind 还 可以 用于常规的数据绑定，在第 2 部分所讨论的性能测试中，我就是以这种方式用 JBind 的。但这样做略微有点笨拙，部分原因是由于 JBind 总是需要在运行时处理文档的 Schema。如果实例文档不直接引用相应的 Schema，则需要使用特殊的映射文件，或在读取实例文档之前，用手工将正确的

22、Schema 装入到自己的代码。目前的文档不会真正向您显示这是如何做的。与其它数据绑定框架相比，对处理绑定文档结构的更改，JBind 也很严格。通过使用 ListIterator ，可以删除现有的元素对象，但只有使用生成的 create（创建）方法才能创建新的元素对象，这些方法自动地将这些元素对象添加到现有内容的后面。实质上，JBind 采用与前面框架大不相同的方法来处理文档数据。JBind 不生成 JavaBean 样式的数据类（但 JAXB 和 Castor 是这样做的），而是将一切存储在文档模型（目前为 DOM 级别 2 实现）中，构建绑定代码做为前端（facade）来访问存储在文档模型

23、中的数据。这是一种非常有趣的方法，如果完全实现，这可能具有一些不错的跨范例好处。目前这种方法所具有的唯一好处是在生成代码中 支持基于 XPath 的约束和访问方法。由于存储机制相对于 JBind 的主旨是次要的，因此将来这种机制还可能会有所变动。JBind 所具有的好处是，在考虑过的所有数据绑定框架中，它支持 Schema 最彻底，并且提供 上面 所说的 XPath 扩展。如果应用程序的核心是处理 XML 文档，则使用由 JBind 构造的“XML 代码”框架可能非常简单。对于一般的数据绑定用法，如果应用程序涉及到 XML 文档，而不是其重点时，则其它数据绑定方法可能会更简单些。由于数据分解时

24、需要验证以及由于文档模型后端存储机制（我将在第 2 部分更详细地讲述此问题），因此与其它框架相比，JBind 还存在明显的性能劣势。JBind 是按照 Apache 样式的许可证分发的，完全可用于商业用途。QuickQuick 文档将自身描述为：不是作为处理 XML 的工具，而是作为对使用 XML 的 Java 语言的 扩展 。它基于位于 Java 平台和 XML 之前的一系列开发成果，在此过程中进行了大量的重构工作。它确实为在 Java 平台上使用 XML 提供了非常灵活的框架 它所具有的灵活性远远超出了为写本文我所能够了解和使用到的。图 6. Quick 生成的类图（单击进行放大） Qui

25、ck 的灵活性是有代价的。它使用一系列相当复杂的步骤来根据 DTD 文档描述移到生成的代码，在此过程中使用了作为中间步骤的三个独立的绑定模式（不要与 W3C XML Schema 混淆）文档： QDML 文档提供文档描述，它大致相当于 DTD，不过添加了一些类型和继承。 QJML 文档定义了 XML 到 Java 语言对象的绑定。 QIML 文件基本上是 QJML 的编译形式，可以用它来生成实际的绑定代码。在第 2 部分 Quick 的性能测试中，我尽可能少地定制这些文件，但为了得到预期的最终结果，仍然需要做一些手工编辑。根据 DTD 文法生成 QDML 文件之后，必须编辑该文件来定义文档的根

26、元素，并为非 String 值（在这里，是几个 int ）添加类型信息。然后，运行程序来从 QDML 生成 QJML 文件，并编辑生成的 QJML，从而向引用添加类型信息。其实，并不真正需要这一步，但有了这一步，就可以用针对对象引用的特定类型生成代码（Castor 和 JAXB 代码生成不支持该特性）。最后，运行该工具以从 QJML 生成 QIML 文件，然后运行代码生成工具完成整个过程，从而获得类 JavaBean 的对象类和实际的绑定类（用来从 XML 转换到 Java 类以及从 Java 类转换到 XML）。再对这些文件进行一些手工编辑，则可以避免生成用于该对象类的新代码，直接链接到 Castor 映射绑定所使用的现有的类。这种可以使用现有类的能力是一项功能非常强大的特性。由于模式文件很复杂，而且为了利用该特性必须做大量的更