Appendix I. GT 4.1.1 Index Service: How to Write a File Element producer using the RPProvider Framework in MDS4

1. Introduction

This document is intended to be a starting guide to writing one of the simplest kinds of information providers for the MDS4 using the RPProvider Framework. It covers the concepts and walks through a simple example of how to get arbitrary information into the MDS4 using the File Element producer. This File Element producer is part of the RPProvider Framework and is used for storing arbitrary XML information by pulling in the static contents from a file. This is mostly useful for scenarios where you would like to publish static information into the MDS4.

This document covers writing a simple information provider that takes the contents of a Message Of The Day (MOTD) file and stores it in the MDS4's Index Service. While the XML data stored in the file is static, the MDS4 will check it periodically and pull in any changes so that it works in some sense, like a logging system as well. This example was chosen because it is dynamic and simple, yet it illustrates all the fundamentals of this type of information provider.

2. Choosing (or conforming to) a Schema

The first step to getting information into the MDS4 is to decide which information you would like to have published. Since the data is in XML format, you should choose (or pick) the schema that you'd like the data to conform to. This generally means coming up with element names and types and creating some mapping of the data you're about to retrieve from the MOTD file before putting it in to the MDS4. For this example, I'm going to choose this very simple format for the data:

<myns:MOTD xmlns:myns="http://myorg.ns.for.testing">

  <myns:MessageEntry myns:Status="STATUS">
    <myns:DateEntered>START DATE</myns:DateEntered>
    <myns:DateValidUntil>END DATE</myns:DateValidUntil>
    <myns:Content> ... content here ... </myns:Content>
  </myns:MessageEntry>

  <myns:MessageEntry myns:Status="STATUS">
     ... another message can be here ...
  </myns:MessageEntry>

</myns:MOTD>

As you can see, that format is very simple. An example output will look like this:

<myns:MOTD>
  <myns:MessageEntry myns:Status="Urgent">
    <myns:DateEntered>Wed Nov 15 10:38:25 CST 2006</myns:DateEntered>
    <myns:DateValidUntil>Wed Nov 15 11:38:25 CST 2006</myns:DateValidUntil>
    <myns:Content>
    URGENT:  It has come to our attention that a disk in the BBX
    machine is failing and we will be replacing it within the hour.
    Sorry for the inconvenience.
    -- Your friendly Systems Staff (systems@foo.org)
    </myns:Content>
  </myns:MessageEntry>
</myns:MOTD>

Once you've chosen how to represent your data in XML format, you can start thinking about how you're going to retrieve and prepare that data for publication. For this kind of information provider, the most common scenarios of getting the formatted XML data into a file published to the Index Service is either by editing it by hand, or by having it auto-generated by some kind of script. For this example, we will assume hand edits are done by a System's person with adequate permissions to the MOTD file.

3. The File

The second step to getting information into the MDS4 is to write a file that contains the appropriate data. For this example, we've provided a sample file that you can download and test. After you've verified that it's all working, feel free to modify the file as you see fit.

Download the sample file: motd.xml.

This file could be saved in your $GLOBUS_LOCATION/etc directory, although if you feel more comfortable placing it somewhere else on your file system, it's ok to do so. For this example, we will assume it's located at the suggested location.

4. Enabling The Provider

Now that we have the data for publication, the next step is to enable it so that we can test it. To do this you will need to do a few things. First, enable the RPProvider framework (if it's not already). Second, enable the MOTD Provider that we've just prepared, and finally restart your container to view the new information.

4.1. Enable the RPProvider framework

It's possible that your Globus Toolkit installation already has the RPProvider framework enabled. This section shows you how to verify if it is, and what to do if it is not. To do this, you will need to edit the $GLOBUS_LOCATION/etc/globus_wsrf_mds_index/server-config.wsdd file.

You should see an DefaultIndexService Handler section that looks something like this:

<service name="DefaultIndexService" provider="Handler"
     use="literal" style="document">
     <parameter name="providers"
                value="org.globus.wsrf.impl.servicegroup.ServiceGroupRegistrationProvider
                       org.globus.mds.usefulrp.rpprovider.ResourcePropertyProviderCollection
                       GetRPProvider
                       GetMRPProvider
                       QueryRPProvider
                       DestroyProvider
                       SetTerminationTimeProvider
                       SubscribeProvider
                       GetCurrentMessageProvider"/>

     <parameter name="handlerClass"
         value="org.globus.axis.providers.RPCProvider"/>
     <parameter name="scope" value="Application"/>
     <parameter name="allowedMethods" value="*"/>
     <parameter name="rpProviderConfigFile"
         value="/etc/globus_wsrf_mds_usefulrp/rp-provider-config.xml"/>
     <parameter name="className"
         value="org.globus.mds.index.impl.DefaultIndexService"/>
     <wsdlFile>share/schema/mds/index/index_service.wsdl</wsdlFile>
</service>

If the DefaultIndexService Handler section doesn't look like this, cut and paste the above and replace the existing Handler section for the DefaultIndexService. The two key distinctions are in the providers value section that has the line org.globus.mds.usefulrp.rpprovider.ResourcePropertyProviderCollection and the rpProviderConfigFile value. This latter value can be anything you want (relative to the system's $GLOBUS_LOCATION), but this document assumes the value that's specified above.

4.2. Enable the MOTD Provider

This step involves editing the $GLOBUS_LOCATION/etc/globus_wsrf_mds_usefulrp/rp-provider-config.xml file that was specified in the above step. It can be a different file, but you will have to adjust the value in the above step to change it here. For now, we're assuming that it's left as the default. If this file doesn't already exist, feel free to copy the sample file located at $GLOBUS_LOCATION/etc/globus_wsrf_mds_usefulrp/gluece-rpprovider-sample-config.xml to $GLOBUS_LOCATION/etc/globus_wsrf_mds_usefulrp/rp-provider-config.xml and start editing from there.

To enable the MOTD provider, you will need to add a config block that looks like this:

<ns1:resourcePropertyProviderConfiguration xsi:type="ns1:resourcePropertyProviderConfig">
 <ns1:resourcePropertyName xsi:type="xsd:QName" xmlns:myns="http://myorg.ns.for.testing">myns:MOTD</ns1:resourcePropertyName>
 <ns1:resourcePropertyImpl xsi:type="xsd:string">org.globus.mds.usefulrp.rpprovider.SingleValueResourcePropertyProvider</ns1:resourcePropertyImpl>
 <ns1:resourcePropertyElementProducers xsi:type="ns1:resourcePropertyElementProducerConfig">
   <ns1:className xsi:type="xsd:string">org.globus.mds.usefulrp.rpprovider.producers.FileElementProducer</ns1:className>
   <ns1:arguments xsi:type="xsd:string">/PATH/TO/GLOBUS_LOCATION/etc/motd.xml</ns1:arguments>
   <ns1:period xsi:type="xsd:int">120</ns1:period>
 </ns1:resourcePropertyElementProducers>
</ns1:resourcePropertyProviderConfiguration>

As you can see, there are a number of configurable parameters there such as the name of the RP that the data will be published as, the location of the MOTD file (motd.xml), as well as the period at which it will be checked for updates and refreshed. Feel free to edit those as necessary. In this example, any updates to the file will appear in the Index Service within 2 minutes (120 seconds). This should generally be sufficient for hand edited updates, but of course it can be configured to suit your needs.

At this point, the MOTD provider has been enabled for use with the RPProvider framework! As you can see, this framework simplifies much of the work of details of getting information into the IndexService. Simply restart the container and make sure there are no errors. If errors are reported, please check over all of the above steps and make sure that they were completed successfully. It's very easy to make unexpected typos!

5. An Example Query

neillm@macglob /usr/local/gt-current/bin $ ./wsrf-query -s
http://127.0.0.1:20202/wsrf/services/DefaultIndexService "//*[local-name()='MOTD']"

<myns:MOTD xmlns:myns="http://myorg.ns.for.testing">

  <myns:MessageEntry myns:Status="Urgent">
    <myns:DateEntered>Wed Nov 15 10:38:25 CST 2006</myns:DateEntered>
    <myns:DateValidUntil>Wed Nov 15 11:38:25 CST
    2006</myns:DateValidUntil>
    <myns:Content>
    URGENT:  It has come to our attention that a disk in the BBX
    machine is failing and we will be replacing it within the hour.
    Sorry for the inconvenience.
    -- Your friendly Systems Staff (systems@foo.org)
    </myns:Content>
  </myns:MessageEntry>

  <myns:MessageEntry myns:Status="Normal">
    <myns:DateEntered>Tue Nov 14 10:00:25 CST 2006</myns:DateEntered>
    <myns:DateValidUntil>--</myns:DateValidUntil>
    <myns:Content>
    Free donuts in the Coffee Room!  Come one, Come All!!  Get 'em
    while they're hot!
    -- Bob (bob@foo.org)
    </myns:Content>
  </myns:MessageEntry>

</myns:MOTD>

This segment of the query output represents the MOTD data we've just written and configured for use. As you can see the MOTD block was properly published into the Index Service since it's now been properly configured!

6. Contact the author

Contact the author at neillm@mcs.anl.gov.