解析J2EE与XML组合技术（3）

最新推荐文章于 2025-06-14 10:28:08 发布

转载最新推荐文章于 2025-06-14 10:28:08 发布 · 357 阅读

本文探讨了如何在Java环境中解析或生成XML，并讨论了XML与J2EE架构的集成方式，包括使用JMS API进行面向消息的通信及XML消息处理。

　　 MediaParser 类的构造函数初始化了一个 Xerces DOM 解析器。 parse （）方法告诉解析器到哪个 URL 去找 XML 源，然后得到结果文档并返回。 loadAssets （）方法调用 parse （）方法从某个 XML 源加载文档，然后为文档中找到的每个 “media － asset” 节点创建一个 MediaAsset 对象。

　　以下是一个使用 MediaAsset 类的例子：

　　 package jaf ． xml ；

　　 import java ． util ． * ；

　　 public class MediaAsset {

　　 // 资源元数据(软件设计师)

　　 private String mName ＝ "" ；

　　 private String mDesc ＝ "" ；

　　 private Collection mChildren ＝ new LinkedList （）；

　　 private Vector mTypes ＝ new Vector （）；

　　 private String mUrn ＝ "" ；

　　 protected MediaAsset （ org ． w3c ． dom ． Node assetNode ） {

　　 // 为简洁起见省略后面代码(软件设计师)

　　．

　　 }

　　因为篇幅的关系省略了 MediaAsset 类的详细代码，但应用模式依然是清晰的。 MediaAsset 类遍历文档的节点，当它碰到不同的子节点时，它用子节点的内容填充自己的成员数据。如果它发现了一个嵌套的子资源节点，它只需要创建一个新的 MediaAsset 对象，然后将子资源节点的数据填充到新对象的成员数据中。

　　实现上述处理的方法数不胜数。我们还可以使用其他的解析器或解析器架构，如 Java API for XML Parsing （ JAXP ）。除了使用 DOM 模型外，事件驱动的 SAX 模型也可用于解析 XML 。类似的程序也可用来产生 XML 数据 —— 前提是允许产生新的数据对象（在本例中是 MediaAsset ），它可将其相应的 XML 实体插入到 DOM 中，然后将 DOM 输出到一个流中（诸如一个文件，一个 Socket ，或者一个 HTTP 连接．．．）。还有其他更高层次的标准，可将 XML 映射到 Java 对象的过程进一步自动化（或简化）。例如，使用 XML 概要（ Schema ）和 XML 绑定处理引擎，您可以半自动地将满足某个 XML 概要的 XML 数据转变成 Java 数据对象。代表性的引擎是 Castor ，是由 ExoLab 小组管理的一个开放源代码项目的产物。上述使用 Xerces DOM 的简单例子仅仅是演示了这一处理过程的底层模型。（文章来源：http://it.100xuexi.com/HF/it/ruanjianshejishi/ ）

　　上述示例表明，在 Java 环境中解析或产生 XML 是非常方便的，这与 J2EE 没有必然关联。格式化为 XML 的数据可以从应用程序的任何层次流入或输出，这使得与外部系统的集成性无可限量。但我们能否以一种更为直接的方式将 XML 数据源集成到 J2EE 架构中去呢 ?

　　驾驭消息

　　 J2EE 架构包含了对 JMS （ Java 消息服务） API 的访问，以实现面向消息的通信（ J2EE 1 ． 2 ． 1 版只需 JMS API 即可，在 J2EE 1 ． 3 版中 JMS 基本定型，此时必须由某个兼容 J2EE 平台的服务器提供一个 JMS API Provider ）。这一类的异步交互（与之相对的是：本地或远程方法调用所代表的同步交互）被证明在某些应用环境中是非常有用的。某些时候，交互只需要通过间接的请求或回答来实现，即：在某些情况下，发出消息后不可能立即收到答复，但我们仍希望当消息发出者重新在线时，确保他能收到答复信息。

　　面向消息系统的实际应用之一就是企业之间的松散集成。类似于 EDI （电子文档交换）时代的文档交换，两个企业由于业务的需要而交换消息，此时通常不能为了使用 RPC 或者 RMI 、 CORBA 、 DCOM 之类的远程方法交互而在两者之间进行紧密集成。象 JMS API 这样的消息系统允许双方交换基于 JMS API 的消息载荷，前提是双方在会话的时候均能提供兼容的 JMS API 服务。当前仍然存在的困难是：双方是否能尊从相同的格式或协议。

　　这正是 XML 大显身手的时候。 XML 明确地被设计来解决此类数据交换问题 —— 灵丹妙药就是 “ 面向消息的概要表 ” （ Message － Oriented Communication Scheme ），实质就是基于一个双方认同的 DTD 或 schema ，用 XML 格式来交换消息载荷。

　　 JMS API 支持好几种消息，其中的 TextMessage 代表文本消息载荷。一个简单而有效的 XML 消息交换方案是，在一端将我们的 XML 文档插入 TextMessage ，然后在另一端用自制的 XML 解析程序（如前面的 MediaParser ）解开数据并（可选地）将其转换成 Java 对象。这使得我们既可以用 JMS API 支持的公开预订的消息模型，也可以用 JMS API 支持的点对点的消息模型来发送 XML 消息。

　　上述方法有一些局限，因为对于 JMS 运行时处理而言， XML 的内容基本上是不透明的。例如， JMS API 允许使用基于特定消息头的路由。这很容易理解，尤其当我们希望 XML 消息根据其内容采取不同走向时。例如在我们的 MediaAsset 例子中，我们希望公开讲座内容，但只想把特定的内容传送给那些预订了课程的人，或传送给那些表明可以接受某些媒体格式（如视频流）的人。为了发挥 JMS API 的价值，以便实现上述基于内容的消息路由，我们有必要从 XML 数据中解析出关键信息，然后在构造标准 JMS API 消息头时插入这些信息。这是可行的，但要实现 XML 信息我们就得额外地写很多代码（交换消息的双方均如此）。

　　为了在 XML 和 JMS API 之间架起桥梁，一些厂商提供了自定义的 JMS 扩展，以便直接支持 XML 消息机制。例如， BEA 系统公司基于 J2EE 的 WebLogic 应用服务器特别为 TextMessage 提供了 XMLMessage 子类，允许用 XPath 表达式来过滤 XML 消息。不过这是一种专有的扩展，这要求交换消息的双方必须都能处理这类消息。