因为篇幅的关系省略了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的简单例子仅仅是演示了这一处理过程的底层模型。
上述示例表明，在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消息。
