Software Links
Getting Started
- Doc Structure
- A Globus Primer
- Globus Is Modular!
- Quickstart
- Installing GT
- Platform Notes
- Migrating from GT2
- Migrating from GT3
Reference
- PDF version
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces
- Resource Properties
- Samples
- Glossary
- Performance Studies
Common Runtime
Security
Data Mgt
Information Svcs
Execution Mgt
Table of Contents
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.
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.
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.
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.
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.
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!
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!
Contact the author at neillm@mcs.anl.gov.