The XML world is driving new emerging technologies that can be utilized to provide solutions to a variety of problems. This article focuses on two of these technologies: Web services and XQuery. As separate entities, these technologies provide a powerful set of features; but when combined they have the potential to present ever more sophisticated feature sets designed for very specific goals.

Web services, while not strictly an XML technology, depends heavily on XML for both its definition language, Web Services Description Language (WSDL), and its messaging protocol, Simple Object Access Protocol (SOAP). Alongside its various descendants, WSDL itself builds on previous XML technologies, such as XML Schema, to provide an abstraction layer over which service endpoints can be defined in terms of messages and operations. Similarly, SOAP provides a mechanism for issuing remote procedural calls and document transactions between distributed systems.

Correspondingly, XQuery provides a rich, data-oriented language for interacting with XML and XML-mapped data sources. It builds on existing XML technologies such as XPath and XML Schema to provide a unified query language over both weakly typed (streams, Web sites) and strongly typed (databases, messages) XML sources. Unlike other query languages, such as SQL, it is intended to not only be a database query language, but a general language for natively interacting with XML as well.

Both technologies have starring roles in new methodologies for solving old problems. Service-oriented architecture (SOA) promises to open up all of the applications in the enterprise via Web services. With it, application developers can build new applications from the functions and features of existing applications. Enterprise Information Integration (EII), utilizing XQuery, makes a similar promise: to present a single front end to all of the databases and data sources available on the network. In both cases, the goal is to bring together the processes and data we interact with individually in a manner that reduces the amount of custom mapping required for each source.

Our ultimate goal herein will be to demonstrate how Web services and XQuery combined can ease the task of developing applications on top of heterogeneous distributed systems. Essentially, we're looking to these technologies to hide all of the differences between the systems with which we wish to interact and allow developers to concentrate on the applications being developed.

Integrating XQuery with Web Services
Whether you look at adding XQuery to Web services or Web services to XQuery, the respective technology will gain something it did not previously have. On one hand XQuery, a language intended to manage, restrict, and combine static data from multiple sources of data (relational databases, XML databases, static Web content), can simplify interactions with XML-based Web services. On the other hand, Web services open XQuery up to more sophisticated interactions with systems outside its local scope. By combining XQuery and Web services, XQuery receives a new interaction model with external sources and Web services along with a sophisticated language for handling its input and output.

To illustrate just one possibility offered by the interaction, consider the following scenario. Super Travel Agency (STA) wishes to present a new feature on its Web site, awarding its repeat customers with fare estimates based not only on best fares but on their participation in frequent flyer programs. STA has a complete customer database with profiles listing their frequent flyer codes for each airline. For this system, STA needs to interact with the airlines via Web services that are defined using completely different result formats.

This fairly straightforward usecase can be accomplished in a discrete series of steps. First, the user profile is accessed and the relevant frequent flyer codes extracted. Combining these codes with destinations and dates, we then pass them to the appropriate airline services and receive a quote from each in a different XML format. We then have to define either a transformation or a custom extraction routine to extract the prices. Finally, we have to take this correlated data and produce a single report for consumption by the client.

In traditional modern programming languages, this problem could be solved by defining a number of discrete modules. One module would access and interpret the client database result, one would be defined for interacting with each airline Web service, one each for the extraction routines to parse the XML results and extract the relevant information, and finally a module for generating the final report. All of the interactions are defined in terms of XML messages, but given the disparate requirements of each such message format the solution will typically have to define a number of custom parsers to convert in and out of the data-oriented XML and object-oriented language paradigms. Simply put, this requires specialized coding and, while extensible, usually requires much more code to integrate new airlines and new client profiling data.

By allowing existing WSDL definitions to be referenced in the query and their services exposed as standard XQuery functions, the steps followed to achieve the solution can be more concise using XQuery. The simplicity is achieved by leaving the entire sequence of interactions in the XML world and taking advantage of XQuery's rich set of features for dealing with XML data to seamlessly interact with all of the various data and function points.

In order to facilitate this interaction between XQuery and Web services, we'll employ an extension to the XQuery language. This syntax parallels the built-in schema import facility in XQuery and was first proposed in XQuery at your Web service. We'll see below how it allows the query author to specify the services to be used in the query by simply importing the WSDL documents defining those services.

Bridging the Gap
In technology, gaps force us to build new technology to bridge disparate paradigms. XQuery sought to bridge the gap between modern programming languages and data. Web services sought to bridge the gap between those same programming languages and distributed processes. We've defined how to bridge the gap between XQuery and Web services; now in closing the gap between the posited airline scenario and the XQuery/Web services solution, we'll hopefully demonstrate how many of the gaps in existing solutions are now bridged.

Recall that the basic problem STA faced could be solved in a discrete series of steps. All steps essentially revolved around the disparate data requirements at each point in the interaction: the client, the database, and the airline services. We'll take each in turn and build up to a total solution. The inputs to our scenario are the client's identification ($client-id) and request parameters ($city and $date).

• Figure 1
• Figure 2
• Figure 3
• Source Code