<!-- 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)。这一类的异步交互(与之相对的是:本地或远程方法调用所代表的同步交互)被证明在某些应用环境中是非常有用的。某些时候,交互只需要通过间接的请求或回答来实现,即:在某些情况下,发出消息后不可能立即收到答复,但我们仍希望当消息发出者重新在线时,确保他能收到答复信息。