Exposing and consuming information as a service is a fundamental concept in today's corporate IT environment. Whether it's a "home grown" application, or software that is commercially purchased, fitting it into a SOA is likely to be a requirement.
But what about the file system? That old, trusty, reliable, unsophisticated repository for so much corporate information. Email attachments, files that are FTP'ed from business partners, extracts from business plans, etc. What if you could readily integrate data residing in the filesystem into your SOA?
Placing the files into a database is one way to solve this problem, but that can introduce a slew of other issues. What if the files are simply resident on a server? One or more folders containing one or more files?
Use Progress DataDirect XQuery! Its built-in support for exposing xqueries as a service, coupled with the ability to specify a folder as an xquery-recognized collection via a standard URI provides developers with a simple, elegant way of accessing file-resident information.
Progress DataDirect XQuery includes a feature, XQueryWebService, which operates in conjunction with virtually any java servlet container, including Apache Tomcat, IBM WebSphere, Oracle WebLogic, etc. When installed, documents in any accessible folder can be designated as a source, and one or more xqueries can be used to query documents in that folder! Using either SOAP or REST! For SQL folks, these xqueries are called in a manner similar to calling a stored procedure. An xquery may be called without any parameters, or they may be invoked with one or more variables. Without modifying the files in any way!
Consider a folder with two files, catalog.xml and catalog2.xml. For this example, these files happen to contain some dummy product information. They could, of course, contain any valid XML.
One requirement may be to simply list information, in this case, display the product information, contained in all files in a particular folder. No "lookup" involved - simply display all the product info there is, combined across all files.
For this, a very simply XQuery can be used. One that uses a wildcard to aggregate information across all .xml files in a particular folder. In this case, the "demofiles" folder contains the desired files. The name of the file containing this XQuery is simply "AllProducts.xquery", a simple text file.
But what if you could take this XQuery that queries a folder, and use it to make the same results available as a service? You can, by leveraging Progress DataDirect XQuery's XQueryWebService functionality!
For this example, we will use Apache Tomcat as our servlet container. After proper setup and configuration, "AllProducts.xquery" can be invoked by any REST-supporting client by simply specifying the URL with the name of the Tomcat application, followed by the name of the XQuery being invoked. No input parameters are used, since there is not any lookup being done.
Here, the URL is simply specified in FireFox, and the product detail is returned, iterating through all .xml files in the specified folder. (In this example, there are only the two files.)
While REST-style architectures are common, SOAP is frequently the standard for service integration. Could this same data be made available via SOAP?
XQueryWebService handles both REST and SOAP! XQueryWebService autogenerates a WSDL which describes any .xquery documents in a given servlet context. In this case, point a SOAP client at the Tomcat application folder used in the REST example, with "WSDL" appended to the URL, and all .xquery documents are exposed as individual SOAP services.
Using "SOAP Client", an independent SOAP/WSDL GUI tool now available at no-cost on Google Code, the "AllProducts.xquery" file is now shown as an available service! Without the developer having to do anything else! (Each .xquery is presented as an additional method in the popup in SOAP Client.)
Upon execution, the SOAP request can be easily inspected.
as can the SOAP response.
The same information that was presented using REST in the first scenario is now able to be accessed via SOAP. Data that had previously been inaccessible can now be readily integrated WITH VERY LITTLE WORK ON THE PART OF THE DEVELOPER!
In our next post, you will learn how you can selectively lookup and extract data from files in the filesystem, rather than simply retrieving everything.