<!-- DTD for a hypothetical media management system --> <!-- Media assets are the root of the object hierarchy. Assets are also hierarchical - they can contain other assets. --> <!ELEMENT media-asset (name, desc?, type*, media-asset*, urn)> <!-- Metadata about the asset --> <!ELEMENT name (#PCDATA)> <!ELEMENT desc (#PCDATA)> <!ELEMENT type (desc, mime-type?)> <!ELEMENT mime-type (#PCDATA)> <!ELEMENT urn (#PCDATA)>
实现上述处理的方法数不胜数。我们还可以使用其他的解析器或解析器架构,如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)。这一类的异步交互(与之相对的是:本地或远程方法调用所代表的同步交互)被证明在某些应用环境中是非常有用的。某些时候,交互只需要通过间接的请求或回答来实现,即:在某些情况下,发出消息后不可能立即收到答复,但我们仍希望当消息发出者重新在线时,确保他能收到答复信息。