简介

　　XQuery是一种发展得最为慎重的W3C标准，因而演化得也最为缓慢，XQuery也因此而闻名。造成这种现象的一个主要原因就是，对于如何获得以XML形式存储的信息，业界还没有什么经验。许多公司仍然在这个领域创新，并且正不断产生大量的经验信息，这些信息必须经过处理和提炼，才能使解决XML查询问题的水平达到令人满意的程度。

　　XQuery还不是W3C推荐标准。最新的工作草案已经有了显着的进展，并且正在被许多不同的供应商或多或少地实现。一些市场主导供应商例如BEA和Software AG已经决定发布一些基于这些工作草案的产品，但是直到其成为W3C的推荐标准前，这些厂商并不准备紧跟这一标准。由于最终发布版的延迟推出，有关其实施的大规模市场推广计划尚未开始。

　　XQuery低公开度的另一个原因就是，到目前为止，还没什么证据能表明XML格式的数据存储能够成为将关系型数据存储拉下马的通用技术。虽然XML数据库展现出很多有价值的和特殊的特性，但是它们在市场渗透方面与面向对象数据库比较相似。这两种数据库都可以很方便地解决专业问题，并且适用于中小型系统。不过，随着存储问题复杂性的增加，XML和面向对象数据库看起来都没有关系型数据库那样容易扩展。实际上，像关系型数据库那样运作可能也不会取得成功。只有在技术方面的大踏步前进才会减少对关系型数据库管理系统遗留项目的大量投资。

　　欢迎开放标准，并不都是徒劳

　　XQuery将会发现自己占据了一席之地，这是连它的作者们都没有期盼过的事情。我们正在见证着公司内软件整合的时代。经过对IT基础设施数十载的投资后，各个公司都达成了一个共识，也就是说，维护如此之多的不同软件产品是很费精力的。

　　随着越来越多的集成项目的开始，没有现成的整厂解决方案可以快速解决问题，这一点变得明显起来。不论软件供应商的规模大小，期待他开发集成包来集成数以万计不同方式的企业应用，这一点是不现实的。 松散集成是当今的流行话题。重写遗留系统的重要部分以使它们共同工作，这是无法实现的乌托邦。相反，对于每个应用程序来说，不论它是否运行于大型机、JAVA、Windows .NET、Unix、C++、CORBA、PHP或者Perl环境中，都可以将其核心功能通过一层瘦Web服务包装器展现。运行这些应用程序子集的任何公司都有使用它们的不同方法。一旦集成的需求明确，公司就可以雇佣咨询师或者使用其自身的IT技术部门来开发集成门户，这将使单个Web控制台具有跨应用程序的功能。

　　由于Web服务的稳定本质，现有应用程序可以继续按照它们熟悉的方式工作一段时间。Web服务的另一个优势就是它们是平台无关的。那么，什么才是连接两个XML接口的最佳方式，这将是个重要的问题。

　　我们需要一种语言，可以方便地编写业务逻辑并且本质上就可以操作XML数据。这就是XQuery大放光彩的地方。它是一种表现力很强的功能性语言，语法简单、熟悉，并且与XML数据结构有机地联系起来。

　　一些较大型企业的服务器供应商已经开始打它的主意了。BEA正在向这个方向发动猛攻，提供了Weblogic集成。该企业软件供应商大量投资于其可视IDE的开发以加快连接应用程序、数据库、企业信息系统与商务处理的开发过程。

　　Software AG也在探索在Tamino Server 4.1上使用XQuery进行应用程序集成的可能，虽然它的主要目标仍然是数据存储。

　　IBM、Oracle和Microsoft虽然提供了样本开发工具包，但是他们也正在避开销售基于XQuery的商业产品。在开放源代码社区，QEXO–GNU XQuery实现–的开发正在踊跃地进行着。

　　如果存在介于主流技术之间的方便桥梁的话，那么将加速XQuer的采用。IBM和Oracle已经意识到这一点，并且都在努力通过javax.xml.XQuery中的标准API包将XQuery与Java联系起来。

　　这些主动的努力正在通过JSR 225: http://www.jcp.org/en/jsr/detail?id=225而变成现实。Oracle即将编写参考实现手册，IBM也将提供技术兼容包。这个API的前景可以看做是JDBC的扩展，以便利用数据库连接与事务管理。此API也会基于JAXP、JAXB和其他XML API。Java与XML市场中一半的主要竞争者已经加入工作组中进行测评工作。

　　不幸的是，还不知道哪一天才能揭开JSR的面纱，这取决于W3C推出XQuery正式版的时间。

　　结束语

　　随着通过Web服务而成的松散软件集成逐渐发展，XQuery将会被人广泛地接受。例如IBM、Oracle和Microsof这样的IT巨头与许许多多的小公司一样，都从策略上调整自身，以便在适当的时候抓住机会。在XQuery与Java之间建立桥梁当然是一个好的信号：采用XQuery的浪潮不会太远。