XQuery Implementation
October 1, 2003
Introduction
XQuery has earned a reputation for being for one of the most cautiously developed and, therefore, slowest evolving W3C standards. A key reason is that there is little industry experience in the retrieval of information stored in XML. Many companies are still innovating in this field and are generating a good deal of empirical information that has to be processed and distilled before a satisfactory level of comfort with the XML querying problem is achieved.
XQuery is still not a W3C Recommendation. The latest working drafts have been a significant move forward and are more or less implemented by a number of different vendors. Some of the market players like BEA and Software AG decided to release products based on these working drafts and not keep up with the standard until it becomes a W3C recommendation. The delay in the final release is one of the reasons why we have not seen large scale marketing campaigns of the implementations.
Another reason for the low publicity level of XQuery is that so far there has been little evidence that XML data storage can become the ubiquitous technology that will unseat relational data storage. Although XML databases exhibit a lot of valuable and exotic features, they can be closely compared to their object oriented counterparts in terms of market penetration. Both seem to be very convenient for solving a set of specialized problems and both seem to do well with small and mid-size systems. However, as the complexity of the storage problem increases, neither XML nor object oriented stores appears to be able to scale as well as the relational solutions. Actually, doing as well as the relational solutions will probably not cut the mustard either. Only a quantum leap in technology would move the mountain of investment away from the RDBMS legacy.
Hail Open Standards, All Is Not In Vain
XQuery will find its spot under the sun in a land little anticipated by its authors. We are witnessing the era of inter-company software integration. After decades of investment in IT infrastructure, companies are reaching a point where maintaining so many different software products is more expensive than they are comfortable with.
As more and more integration programs kick off, it becomes evident that there are no off-the-shelf turn-key solutions that will solve the problems quickly. It's not realistic to expect that a software vendor of any appreciable size will build the integration package which works out the millions of different ways enterprise applications can integrate with each other.
Loose integration is the word of the day. Rewriting significant portions of legacy systems to make them work together is an unobtainable utopia. Instead, each application, regardless of whether it is running on a mainframe, Java, Windows .NET, Unix, C++, CORBA, PHP or Perl, exposes its core functionality via a thin web services wrapper. Any company that runs a subset of these applications has a unique way of using them. Once integration requirements are clear, the company can hire consultants or use its own IT skill set to develop an integrating portal which brings cross-application functionality to a single web console.
Thanks to the unobtrusive nature of web services, the existing applications can continue to work the way they always did for quite some time. The other advantage of web services is that they are platform independent. The logical question becomes, then, what the best way to bridge two XML interfaces is?
We need a language that is convenient for writing business logic and can natively manipulate XML data. This is where XQuery shines. It is a very expressive functional language with a simple, familiar syntax and an organic connection to XML data structures.
Some of the bigger enterprise server vendors are already on board with this idea. BEA is moving aggressively in this direction with its Weblogic Integration offering. The enterprise software vendor invested heavily in its visual IDE to accelerate the development process of connecting applications, databases, enterprise information systems and business processes.
Software AG is also exploring the potential of XQuery for application integration, with Tamino Server 4.1, although its primary focus is still data storage.
IBM, Oracle, and Microsoft are shying away from selling commercial products based on XQuery yet, although they offer sample development kits. In the open source community, QEXO -- the GNU XQuery implementation -- is being actively developed.
The adoption of XQuery will be accelerated if there are convenient bridges to mainstream
technologies. IBM and Oracle realize that and have collectively launched an effort
to
connect XQuery to Java through a standard API packaged under javax.xml.xquery.
The initiative is being developed via JSR 225: http://www.jcp.org/en/jsr/detail?id=225. Oracle will write the Reference Implementation, and IBM will provide the Technology Compatibility kit. The vision for this API is to be an extension to JDBC, so that connection and transaction management can be leveraged. The API will also build on JAXP, JAXB, and other XML APIs. A half dozen major players in the Java and XML markets have joined the working group as reviewers.
|
More from Practical XQuery |
Unfortunately there are no public dates for the deliverables of this JSR since it depends on the availability of the XQuery Recommendation from W3C.
Conclusion
It seems that XQuery will become widely available around the time that loose software integration via web services is taking off. IT heavyweights like IBM, Oracle, and Microsoft, as well as lots of smaller players, are strategically positioning themselves to meet the opportunity once the flood gates open up. Bridging XQuery to Java is certainly a good sign that the adoption wave is not too far away.