Publishing and Resource Discovery with Registries

Student Exercise: Adding registry support into our Cone Search Client.

In this session, we will modify the Cone Search client from yesterday to use the registry to get Cone Search base URLs that can be used instead of the hard-coded one.

Creating your registry client code

We start by building our client-side interface to the Registry's Web Service.

Type: "wsdl2java registry.wsdl"
registry.wsdl is the WSDL file for the NVO Registry at STScI. Running wsdl2java creates interface classes along with classes representing the XML types that are sent in the soap messages.
For example, briefly examine org/us_vo/www/RegistrySoap.java. You will see a method for each of the Web Service methods supported by the STScI Registry.

Compile the client code: "ant compileWSDLcode"
This compiles all the generated code along with our application code within the coneclient directory.

Cone Search Finder class

We will now create a class that will look specifically for Cone Search services in the Registry.

Open up nvoregistry/coneclient/FindConeSearch.java.
Notice the function called search(). This is a front end to the Web Service's queryRegistry() function. It takes an SQL "WHERE" clause and combines it with a constraint that matches only Cone Search services:
```
// Combine our query with a constraint to return only Cone Searches.
// The resulting query will look something like this:
// 
//    ServiceType like '%CONE%' and (Title like '%parallax%')
// 
query = "ServiceType like '%CONE%' and (" + query + ")";
```
Our method sends this modified query to the Web Service method, queryRegistry(). From the result, we extract an array of resource descriptions. Note that the descriptions are not VOResource records; rather they use a custom schema, SimpleResource (primarily for historical reasons).

Test the finder class (from the directory containing the build.xml file):
```
java coneclient.FindConeSearch "Description like '%parallax%'"
```

Feed one of the returned service URLs into the ConeCaller application:
```
java coneclient.ConeCaller 180.0 60.0 1.0 "http://chart.stsci.edu/GSCVO/HIPVO.jsp?"
```
This version of ConeCaller was modified to take a Cone Search base URL from the command line.
Now try the second service returned by FindConeSearch:
```
java coneclient.ConeCaller 180.0 60.0 1.0 "http://vizier.u-strasbg.fr/viz-bin/votable/-dtd/-A?-out.add=_RAJ2000,_DEJ2000&-source=I/280"
```
This produces an exception. Why?
Look at coneclient/ConeCaller.java within callConeService() to see how the URL is formed:
```
URL cone = new URL(coneUrl + "RA="+ra+"&DEC="+dec+"&SR="+sr);
```
This is compliant with the Cone Search specification. Unfortunately, this particular base URL from the registry needs a trailing &. Despite the standard, many of the URLs in the registry are incorrectly entered in this manner.
Fortunately, this is not hard to fix in our client application. FindConeSearch.java includes a correctBaseURL() function. We can incorporate this into our FindConeSearch application. Within its main() function, find this line:
```
System.out.println("Address: " + cs[i].getServiceURL());
```
and change it to:
```
System.out.println("Address: " + 
     FindConeSearch.correctBaseURL(cs[i].getServiceURL()));
```
Recompile this class by typing "ant", and the try our registry query again.

Exercise: Create a keywordSearch() method.
A keywordSearch() method is provided already by the STScI Registry. It simply compares all the input words to selected text fields in the resource description. Unfortunately, this implementation returns VOResource (v0.9) records, not SimpleResource.
Nevertheless, it would not be difficult to implement our own keyword search that does return SimpleResource records in addition to restricting the match to Cone Search services.
FindConeSearch.java contains a stubbed version of a keywordSearch() method (the last method in the source file); that is, you need to complete the implementation to make it work. If you need to cheat a little, just look at the FindConeSearch.java in the solutions subdirectory.

Exercise: Incorporate a keyword registry query into the ConeCaller application.
In our version of ConeCaller, if the fourth command-line argument is a base URL, it will use it to call the specific Cone Search service. If it is not a URL, any arguments after the third one are interpreted as keywords for a registry search, and a keyword query string is formed. In this exercise, pass this query to our FindConeSearch class to retrieve Cone Search base URLs. Then call one or more of the matched services.
For extra credit, call each cone search service and print the number of records it returns. Again, you can peek at ConeCaller.java in the solutions directory.