In a services-oriented architecture (SOA), a business process is implemented as a web service that programs (orchestrates in SOA terminology) other web services. An orchestrator web service is usually coded in a language outside the XML domain (e.g., Java), and in this context XQuery is used only to query and transform data—not to orchestrate other web services. However, here we show how a few extensions to XQuery give it the additional role of web service orchestrator, allowing this XML-domain-specific language to implement all the steps in a complex SOA processes. This article explains the choice of extensions, outlines their implementation for a specific XQuery processor, and shows how extended XQuery was used to create web services to process complex financial data. While web services created in this way are usable within any SOA, they can also act as the highest-level orchestrators in what some authors refer to as SOA lite. The extensions applied here for XQuery work equally well for XSLT 2.0.
Why orchestrate with XQuery?
XQuery (See References 1 and 2) has the potential to become the most applicable language for extracting and transforming data from any source that can be represented as a real or virtual XML document. Its SQL-like syntax is relatively easy to learn and it already has a role in SOA for extracting and transforming data. In its unextended state, XQuery has some capability to orchestrate web services via the XPath 2.0 function doc(uri), which can call the uri using HTTP GET. But XQuery was designed to be extensible by custom functions, which can call code modules external to the processor.
