XPath Query support for Service Data Elements (Experimental)

Globus Toolkit 3.0 - Last Updated 06/20/2003

Audience:

This document is targeted towards OGSA developers interested in evaluating XPath query expressions against OGSA Service Data Elements.

Summary:

This version of XPath query support for Service Data consists of a basic implementation that uses Xalan-J XPathAPI to evaluate XPath expressions on XML-serialized ServiceData elements and return the results as singleton XML elements or arrays of XML elements.

Usage:

An XPath query can be performed by issuing a findServiceData() method call and passing a ServiceDataXPathQueryExpressionType object as the parameter instead of ServiceDataNameQueryExpressionType.

ServiceDataXPathQueryExpressionType has the following WSDL structure:

 

<complexType name="ServiceDataXPathQueryExpressionType">

    <sequence>

        <element name="name" type="QName"/>

        <element name="XPath" type="string"/>

        <element name="namespaces" type="string" minOccurs="0" maxOccurs="unbounded"/>

    </sequence>

</complexType>

 

Parameter Explanation:

1. QName: "name":

This is the QName of the SDE to select as the basis of the search. Similar to the current ServiceDataNameEvaluator, wildcards are supported in either part of the QName. If a wildcard is specified, the XPath will be applied in turn to each matching element returned by the wildcard selection, and the entire results set will be returned as an array of Elements, with each element containing 1 or more result elements from the XPath query.

2. String: "XPath":

This is the XPath expression to apply to the SDE specified by the "name" parameter. The XPath language is sophisticated and the syntax is strict. Improper syntax in query expressions will generate Invalid Expression exceptions.  Improper semantic usage may yield an undesirable or unexpected result set, or no results at all. 

3. String[]: "namespaces":

XPath requires that the client provide a namespace mapping for every node in the query scope that has a corresponding namespace attribute. In the current implementation, this is provided via an array of Strings of the form "xmlns:<prefix>=<namespaceURI>". For example:

xmlns:gsdl=http://www.gridforum.org/namespaces/2002/10/gridServices

xmlns:wsil=http://schemas.xmlsoap.org/ws/2001/10/inspection/

If namespace mappings are not provided, the default behavior is to use the current context node (in our case the SDE root element) to resolve the namespaces. However, this may not be sufficient when searching for child nodes which contain namespace attributes that are not present in the root node, so one must be careful to provide all possible namespaces of interest that are likely to be encountered when traversing the SDE.

Note that while with XPath it *is* possible to do a wildcard selection on a QName localPart within the XPath string expression, it is *not* possible to wildcard the namespaceURI or prefix.

For example: //*:* is an invalid query, but //gsdl:* is valid -- as long as the "gsdl" prefix can be resolved to a URI.

Author's Note: It turns out you can get some queries to work without using namespaces by using XPath in-line functions like local-name() to accomplish namespace wildcarding, and namespace-uri() to facilitate specifying the namespace in the expression. However this seems like a cumbersome method that is not very robust, since it only works when selecting Element node types. So this is BAD for something like 'give me the goodUntil time value of ServiceData <x>', but it is a very quick-and-dirty way to get a whole bunch of arbitrary, like-named elements out of a document without knowing anything about the namespaces. Ultimately, in the OGSA namespace-intensive environment, this might prove to be a Bad Habit.

 

Current Client Implementations:

Test-Case

There is a basic test case that is run to issue an XPath query that checks if the QueryExpressionTypes SDE contains the queryByServiceDataXPath expression type. Its basically just a simple self-test. It can be found in the TestServiceData.java module.

Querying

The GridServicePortTypePanel.java of the OGSA Service Browser GUI has been modified to take the extra parameters of the String XPath expression and the Namespace mapping string. Specify the literal XPath expression string in the XPath text box and use a whitespace, semi-colon, or comma delimited set of namespace strings in the Namespace text box. The Service Browser was used to test XPath query evaluation on a variety of services, and was successful in getting the expected results when using properly formed queries. At this point it’s the best place to start if you want to try out a bunch of queries with out doing any programming.

 

Sample Queries:

Here are some sample queries that produced acceptable results. Please note that these are just scratching the surface of what is possible with XPath.  Please do *not* consider this a definitive resource on XPath usage in general, or with OGSA specifically.

 

1. Find if a specific service name exists in a registry using namespaces:

Using a fully qualified XPath:

xmlns:gsdl=http://www.gridforum.org/namespaces/2002/10/gridServices

xmlns:wsil=http://schemas.xmlsoap.org/ws/2001/10/inspection/

//gsdl:serviceData/wsil:inspection/wsil:service/wsil:name[.='Handle Resolver']

 

Below is a shorter form -- Any element that matches the wsil:service/wsil:name hierarchy and has a value equal to 'Handle Resolver' will be selected (though this may not be what is strictly desired):

//*/wsil:service/wsil:name[.='Handle Resolver']

 

It is also possible to do the same as above but without namespaces (Note that this approach is not very robust since local-name() doesn't work on attributes):

Fully Qualified:

    //*[local-name()='serviceData']/*[local-name()='inspection']/*[local-name()='service']/*[local-name()='name'][.='<service name>']

 

Any element that matches any service/name hierarchy and has a value equal to <service name>:

 //*[local-name()='service']/*[local-name()='name'][.='<service name>']

 

3. Self-Test to find if XPath Expressions are supported:

xmlns:gsdl=http://www.gridforum.org/namespaces/2002/10/gridServices

//gsdl:queryExpressionType[.='gsdl:queryByServiceDataXPath']

 

4. SubscribeByXPath supported? Not yet - and so this query will return no elements:

xmlns:gsdl=http://www.gridforum.org/namespaces/2002/10/gridServices

//gsdl:subscriptionExpressionType[.='gsdl:subscribeByServiceDataXPath']

 

5. Basic MDS-style Query - Find if a filesystem named "C:\" exists:

xmlns:mds=http://glue.base.ogsa.globus.org/ce/v_1_0_20020824

//mds:Host/mds:FileSystem[@mds:Name='C:\']

 

6. Basic MDS-style Query - Select all Host/MainMemory attributes named "RAMAvailable" that have a value >= 200000

xmlns:mds=http://glue.base.ogsa.globus.org/ce/v_1_0_20020824

//mds:Host/mds:MainMemory[@mds:RAMAvailable >= 200000]

 

Useful Links:

Here are some links to XPath docs that you may find useful:

XPath Spec: http://www.w3.org/TR/XPath

XPath tutorial: http://www.zvon.org/xxl/XPathTutorial/General/examples.html

Query Expression samples: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/htm/XPath_syntax2_3prn.asp?frame=true