AstroGrid registry client lite

The Client area's main purpose is to give the users a delegate to go by and to interact with a Registry server or cache. The Client section will read in a config file and determine to use a Registry server which will be the most common or use a a local cache through it's config file. It determines rather to use a server or local config file by simply determining if the endpoints are in the config file. It should be noted current implementation only queries based on identifiers when using the local config cache. The current client is now associated with the ivoa standard now of querying via ADQL and is OAI conformed on the web service interface.

Builds

The registry allows you to build at the top level or at it's sub-project level. Here are the maven goals for building the registry.

  • astrogrid-clean - cleans out and removes all previous builds.
  • astrogrid-install-snapshot - Builds all the necessry jar and war files.
  • astrogrid-deploy-snapshot - Builds and deploys the snapshot onto the repository.
  • astrogrid-deploy-site - Generates reports and documents to be deployed on the site repository.

Deployment/Installation

It is expected that this jar will be bunded with an appropriate war file for use with other components. There is no seperate installation just for the client itself. After a build a jar file is produced in the "target" directory. When ever it is bundled with another component, it is expected to have in the System properties or JNDI a key value of "org.astrogrid.config.url" pointing to a config file. An example config file is given in cvs under the config directory for this client area. Current config properties needed to use a server:

  • org.astrogrid.registry.admin.endpoint - administration endpoint for updates.
  • org.astrogrid.registry.query.endpoint - query endpoint.
just define no properties and define an identifier pointing to a xml file of the Resource for that identifier when using the local config cache.

How to Use for Other Components

Once the configuration is complete and ready for another component to use. It may use the various delegates with the delegate factory.

The Query:

Instantiate with: org.astrogrid.registry.client.query.RegistryService rs = org.astrogrid.registry.client.RegistryDelegateFactory.createQuery()

From there you have access to all the delegate methods mentioned below for the Query section. It is of course advisable to use import statements at the top of your code to make things easier. Still need to put some examples of the query schema/string here

Delegate - Helper methods to the Interface

This section is a quick description of what delegate methods can be used for other components to take advantage of. This is not necessarily the actual web service interface methods on the server side registry.

First the Query:

  • submitQuery - Queries the Registry. Examples of the queries can be found in config/junitcache, but will add a section here soon. There are various submitQueries that can be used.
  • getResourceByIdentifier - returns a Document DOM object of this one resource entry.
  • getEndPointByIdentifier - returns a string which is a endpoint of a Service entry by looking at the WSDL if it is a Web service.
  • getBasicWSDLInformation - returns a WSDLBasicInformation object containting a targetNamespace and endpoints found in a WSDL.
  • loadRegistry - returns a Document DOM object of just the registry resource entry.
  • search - A query based on ADQL.
  • listRecords - OAI list records.
  • getRecord - OAI getRecord.
  • listmetadataprefix - OAI listmetadataprefix.
  • listidentifiers - OAI listidentifiers.
  • identify - OAI identify.
The Update:
  • update(Document) - updates a resource entries in the registry given a one or more Resources from a Document DOM object.
  • updateFromUrl(URL url) - Not yet implemented.
  • updateFromFile(File fi) - Not Yet imnplemented.

More on Queries

The queries should be done in ADQL now, but current components still use an old style xml, look below on more information about that.

Currently the queries conform to an old style xml schema and syntax and will be changed shortly in itn06 to conform to the IVOA schema. The schema can be found: Registry ~Query Schema, but look at the examples below to see basic syntax of the queries, it is very SQL like and easy to understand. In the current iteration the parsing looks for all namespaces "*", and the current sectionOp values are "AND|OR". The section items can be set to any text node or attribute, and finally for itemOp is much like the Xquery syntax see the itemOp list.

ItemOp List:

  • CONTAINS - constains or substring
  • EQ - equals
  • NE - not equals
  • GE - greater-than-or-equals
  • LE - less-than-or-equals
  • GT - greater-than
  • LT - less-than


Examples: