XML和J2EE的组合技术 - 编程入门网

实现上述处理的方法数不胜数。我们还可以使用其他的解析器或解析器架构，如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消息。

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

为了在XML和JMS API之间架起桥梁，一些厂商提供了自定义的JMS扩展，以便直接支持XML消息机制。例如，BEA系统公司基于J2EE的WebLogic应用服

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!