570 likes | 737 Vues
Globus MDS for Developers. Mike D’Arcy Laura Pearlman USC Information Sciences Institute. Agenda. Review of MDS services and components Publishing information Publishing resource properties with the new Resource Property Provider component.
E N D
Globus MDS for Developers Mike D’Arcy Laura Pearlman USC Information Sciences Institute
Agenda • Review of MDS services and components • Publishing information • Publishing resource properties with the new Resource Property Provider component. • Using ExecutionAggregatorSource to monitor things other than WSRF services • Acting on Information • Using the Trigger Service to monitor both WSRF and non-WSRF services so that user programs may be invoked when specific conditions are detected. • Querying/displaying information • Querying the Index Service • Using the new TargetedXPath query dialect • Producing custom WebMDS views MDS for Developers
MDS Services • Index Service • Collects information • Publishes its data as resource properties • Trigger Service • Collects information using the same mechanism as the Index Service • Executes trigger actions when conditions are met. MDS for Developers
Data Flow in MDS WSRF Service WSRF Service With rpProvider Information Provider Resource property requests execution Query Aggregator Source Execution Aggregator Source Index Service Trigger Service Resource property requests Subscription / notiification Trigger actions anything Clients: wsrf-query, WebMDS, Java API, C API MDS for Developers
Resource Property Provider • The new RPProvider component provides a modular “plug-in” API for creating Resource Properties from various user-defined input sources. • This mechanism allows for the easy inclusion of custom XML content, represented as a WS-ResourceProperty, into GT4 services with significantly reduced integration overhead. • In many cases, no new code may be required at all. For example, periodically reading a XML file and storing the contents in the IndexService requires no custom coding and minimal configuration. MDS for Developers
RPProvider API Basics • The goal is the output of XML, bound to a QName that represents the name of the WS Resource Property that the data will be published as. • This task is handled by 3 sub-components: • Element Producers: perform the generation of the XML data to be used as the resource property value(s). • Element Transforms: optionally perform post-processing and validation on the output of element producers. • Execution Engine: reads configuration and performs the periodic execution of ResourcePropertyProviderTasks, which first executes a specified element producer, and then optionally executes any specified element transform. MDS for Developers
RPProvider: Element Producers • Element producers are required only to implement the single method of a Java interface of the form: public Element getElement(String[] args) throws Exception; • RPProvider comes with a default set of element producers that can be used for a variety of common tasks. • ExternalProcessElementProducer: executes a external process, then attempts to parse the STDOUT stream of that process into a valid XML document. • FileElementProducer: reads data directly from a XML file. • URLElementProducer: reads data by using an HTTP Get request to fetch a XML file. MDS for Developers
RPProvider: Element Transforms • Element transforms are required only to implement a single method of a Java interface of the form: public Object transformElement(Element source, String[] args) throws Exception; • The return type of the transformElement method is expected to be either a DOM Element, or a XML serializable Java bean object generated from WSDL or XSD with Axis WSDL2Java. • RPProvider includes a basic XSLT-based transform for general use, XSLTFileElementTransform, which reads in a XSLT file as specified by arg[0] and applies it to the result element generated by an element producer’s getElement method. MDS for Developers
RPProvider: Execution Engine • The execution engine of the RPProvider component is a set of Java classes which handles the creation and periodic execution of Java TimerTasks that generate data by invoking configured Element Producers and Element Transforms. • The execution engine is implemented as a GT4 operation provider. The implementation for the operation provider is contained primarily within the ResourcePropertyProviderCollection.java class. • The execution engine supplies utility classes that implement the ReflectionResourceProperty interface. These classes provide default mechanisms for returning element producer output as either a single value or an array of values. MDS for Developers
RPProvider: Execution Engine, continued • Pre-existing Factory and Singleton type services can include the operation provider without code modification by editing the service descriptor in the server-config.wsdd file. • Service resources created at runtime must have support for RPProvider compiled into the code by creating an instance of ResourcePropertyProviderCollection at resource initialization time. MDS for Developers
RPProvider: Configuration • Adding RPProvider support to a Factory or Singleton service via server-config.wsdd: <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/gluece-rpprovider-sample-config.xml"/> <parameter name="className" value="org.globus.mds.index.impl.DefaultIndexService"/> <wsdlFile>share/schema/mds/index/index_service.wsdl</wsdlFile> </service> MDS for Developers
Adding RPProvider Support to a Resource • Adding RPProvider support directly into a resource implementation class: ResourcePropertyProviderCollection rpCollection = new ResourcePropertyProviderCollection ( “path/to/config/file/rpConfig.xml”, // a full path to the configuration file this.getResourcePropertySet(),// the resource property set to add into true// initialize immediately after construction ); • Note: This code fragment assumes that the class referred to by the thisvariable implements the org.globus.wsrf.ResourceProperties interface. MDS for Developers
RPProvider usage in GT4 • The 4.1.x GRAM ManagedJobFactoryResource uses the latter approach to integrate resource-level RPProvider support for the Fork, PBS, and other GRAM job scheduler factory resources. • A refactored version of the GLUEResourceProperty.java class, based on the RPProvider API, is now used by GT4.1.x GRAM to publish the GLUECE Resource Property. • This newer version of GLUEResourceProperty supports more flexible configuration of the underlying information providers that compose the GLUECE RP for a given scheduler type. • Scheduler providers can now be easily swapped out and replaced with developer versions. MDS for Developers
RPProvider: Configuration • Sample RPProvider Configuration File Format as defined in rpprovider.xsd <ns1:ResourcePropertyProviderConfigArray xsi:type="ns1:ResourcePropertyProviderConfigArray" xmlns:ns1="http://mds.globus.org/rpprovider/2005/08" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ns1:configArray xsi:type="ns1:resourcePropertyProviderConfig"> <ns1:resourcePropertyName xsi:type="xsd:QName" xmlns:mds="http://mds.globus.org/glue/ce/1.1">mds:GLUECE</ns1:resourcePropertyName> <ns1:resourcePropertyImpl xsi:type="xsd:string">org.globus.mds.usefulrp.rpprovider.GLUEResourceProperty</ns1:resourcePropertyImpl> <ns1:resourcePropertyElementProducers xsi:type="ns1:resourcePropertyElementProducerConfig"> <ns1:className xsi:type="xsd:string">org.globus.mds.usefulrp.glue.GangliaElementProducer</ns1:className> <ns1:arguments xsi:type="xsd:string">localhost</ns1:arguments> <ns1:arguments xsi:type="xsd:string">8649</ns1:arguments> <ns1:period xsi:type="xsd:int">300</ns1:period> <ns1:transformClass xsi:type="xsd:string"> org.globus.mds.usefulrp.rpprovider.transforms.GLUEComputeElementTransform</ns1:transformClass> </ns1:resourcePropertyElementProducers> <ns1:resourcePropertyElementProducers xsi:type="ns1:resourcePropertyElementProducerConfig"> <ns1:className xsi:type="xsd:string"> org.globus.mds.usefulrp.rpprovider.producers.SchedulerInfoElementProducer</ns1:className> <ns1:arguments xsi:type="xsd:string">libexec/globus-scheduler-provider-pbs</ns1:arguments> <ns1:transformClass xsi:type="xsd:string"> org.globus.mds.usefulrp.rpprovider.transforms.GLUESchedulerElementTransform</ns1:transformClass> <ns1:period xsi:type="xsd:int">300</ns1:period> </ns1:resourcePropertyElementProducers> </ns1:configArray> </ns1:ResourcePropertyProviderConfigArray> MDS for Developers
RPProvider Example, Overview • Putting it all together: Adding a MOTD Resource Property to the DefaultIndexService • Step 1: Create the MOTD XML file that will contain the value(s) of the resource property. • Step 2: Create a RPProvider configuration file for the MOTD resource property. • Step 3: Configure the DefaultIndexService to use the ResourcePropertyProviderCollection operation provider. • Step 4: Start the container and query the MOTD resource property to verify that things are functional. MDS for Developers
RPProvider Example, Step 1 • Step 1: Create MOTD XML file • Our sample XML file will publish a Message of the Day as a resource property named: {http://mds.globus.org/MOTD}MessageOfTheDay • The motd.xml sample file contains the following data: <?xml version="1.0" encoding="UTF-8"?> <motd:MessageOfTheDay xmlns:motd="http://mds.globus.org/MOTD" > <motd:Message> The system will be going down for maintenance today at 3:00AM EST for approximately 10 minutes. We apologize for any inconvenience. </motd:Message> <motd:LastUpdated> Thu Aug 10 15:05:00 PDT 2006 </motd:LastUpdated> <motd:UpdatedBy> Ricky Bobby </motd:UpdatedBy> </motd:MessageOfTheDay> MDS for Developers
RPProvider Example, Step 2 • Step 2: Create a configuration file for the MOTD resource property • Create the file motd-sample-config.xml in the $GLOBUS_LOCATION/etc/globus_wsrf_mds_index directory. • The MOTD RP configuration file should contain the following data: <ns1:ResourcePropertyProviderConfigArray xsi:type="ns1:ResourcePropertyProviderConfigArray" xmlns:ns1="http://mds.globus.org/rpprovider/2005/08" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ns1:configArray xsi:type="ns1:resourcePropertyProviderConfig"> <ns1:resourcePropertyName xsi:type="xsd:QName" xmlns:motd="http://mds.globus.org/MOTD"> motd:MessageOfTheDay </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"> /full/path/to/motd.xml </ns1:arguments> <ns1:period xsi:type="xsd:int">86400</ns1:period> </ns1:resourcePropertyElementProducers> </ns1:configArray> </ns1:ResourcePropertyProviderConfigArray> MDS for Developers
RPProvider Example: Step 3 • Step 3: Configure the DefaultIndexService to use the ResourcePropertyProviderCollection operation provider. <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_index/motd-sample-config.xml"/> <parameter name="className" value="org.globus.mds.index.impl.DefaultIndexService"/> <wsdlFile>share/schema/mds/index/index_service.wsdl</wsdlFile> </service> MDS for Developers
RPProvider Example: Step 4 • Step 4: Start the container and query the MOTD resource property to verify that things are functional. • Start container: $GLOBUS_LOCATION/bin/globus-start-container [-nosec] • Issue a GetResourceProperty query: $GLOBUS_LOCATION/bin/wsrf-get-property –s http://localhost:8080/wsrf/services/DefaultIndexService {http://mds.globus.org/MOTD}MessageOfTheDay • The query command output should contain the following data: <motd:MessageOfTheDay xmlns:motd="http://mds.globus.org/MOTD"> <motd:Message> The system will be going down for maintenance today at 3:00AM EST for approximately 10 minutes. We apologize for any inconvenience. </motd:Message> <motd:LastUpdated> Thu Aug 10 15:05:00 PDT 2006 </motd:LastUpdated> <motd:UpdatedBy> Ricky Bobby </motd:UpdatedBy> </motd:MessageOfTheDay> MDS for Developers
ExecutionAggregatorSource • The ExecutionAggregatorSource provides a flexible data ingestion mechanism for WS-MDS Service Groups that are based on the Aggregator Framework. This includes: • Index Service • Trigger Service • ExecutionAggregatorSource functions by executing an external process and then parsing the process STDOUT stream into a XML file. • The result XML file is stored as the value of the Content ResourceProperty for the ServiceGroupEntry resource that is created when the Service Group Add operation is invoked against the service. MDS for Developers
ExecutionAggregatorSource Example • Prerequisite: Install the GridFTP information provider • Ensure that the information provider file gridftp-banner.pl is located in the following directory: $GLOBUS_LOCATION/libexec/aggrexec • Step 1: Enable the usage of gridftp-banner.pl by editing the executableMappings field of the AggregatorConfiguration block of the jndi-config.xml file for the Index or Trigger. • $GLOBUS_LOCATION/etc/globus_wsrf_mds_index/jndi-config.xml • $GLOBUS_LOCATION/etc/globus_wsrf_mds_trigger/jndi-config.xml • Step 2: Create or modify a mds-servicegroup-add registration file to contain the instructions to run the GridFTP information provider periodically against a specifed GridFTP server address. MDS for Developers
ExecutionAggregatorSource Example, continued • Configuring the Index and Trigger services to use ExecutionAggregatorSource to monitor GridFTP • Step 3: Start the container and run the mds-servicegroup-add program to register a new service group entry that will run the GridFTP information provider. • Step 4: Issue a wsrf-query to check the status of the provider: $GLOBUS_LOCATION/bin/wsrf-query –s http://myhost:8080/wsrf/services/DefaultIndexService MDS for Developers
ExecutionAggregatorSource Example: Step 1 • Step 1: Enable execution of gridftp-banner.pl • For security reasons, all executable programs used by the ExecutionAggregatorSource must be enumerated by the adminstrator of the Globus installation prior to starting the container. • The administrator is required to map a logical “probe name” to the physical filename of the information provider. Furthermore, the information provider executable file must by located in $GLOBUS_LOCATION/libexec/aggrexec (or symlinked from that location). • In this case, edit the AggregatorConfiguration block of the service jndi-config.xml as follows: <resource name="configuration" type="org.globus.mds.aggregator.impl.AggregatorConfiguration"> … <parameter> <name>executableMappings</name> <value> gridftp-info=gridftp-banner.pl, aggr-test=aggregator-exec-test.sh, pingexec=example-ping-exec </value> </parameter> … </resource> MDS for Developers
ExecutionAggregatorSource Example: Step 2 • Step 2: Create or modify a mds-servicegroup-add registration file for the GridFTP information provider <ServiceGroupRegistrations xmlns="http://mds.globus.org/servicegroup/client" xmlns:sgc="http://mds.globus.org/servicegroup/client" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance“ xmlns:wsa=“http://schemas.xmlsoap.org/ws/2004/03/addressing” xmlns:agg="http://mds.globus.org/aggregator/types"> <defaultServiceGroupEPR> <wsa:Address>https://yourhost:8443/wsrf/services/DefaultIndexService</wsa:Address> </defaultServiceGroupEPR> <ServiceGroupRegistrationParameters xmlns="http://mds.globus.org/servicegroup/client" > <RegistrantEPR xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsa=“http://schemas.xmlsoap.org/ws/2004/03/addressing” xmlns:agg="http://mds.globus.org/aggregator/types"> <wsa:Address>ftp://yourhost:2811</wsa:Address> </RegistrantEPR> <RefreshIntervalSecs>600</RefreshIntervalSecs> <Content xsi:type="agg:AggregatorContent" xmlns:agg="http://mds.globus.org/aggregator/types"> <agg:AggregatorConfig xsi:type="agg:AggregatorConfig"> <agg:ExecutionPollType> <agg:PollIntervalMillis>60000</agg:PollIntervalMillis> <agg:ProbeName>gridftp-info</agg:ProbeName> </agg:ExecutionPollType> </agg:AggregatorConfig> <agg:AggregatorData/> </Content> </ServiceGroupRegistrationParameters> </ServiceGroupRegistrations> MDS for Developers
ExecutionAggregatorSource Example: Step 3 • Step 3: Start the container and run the mds-servicegroup-add program to register a new service group entry that will run the GridFTP information provider. • Start container: $GLOBUS_LOCATION/bin/globus-start-container -nosec • Run mds-servicegroup-add: $GLOBUS_LOCATION/bin/mds-servicegroup-add my-gridftp-registration.xml MDS for Developers
ExecutionAggregatorSource Example: step 4 • Step 4: Issue a wsrf-query to check the status of the information provider: • Query: • $GLOBUS_LOCATION/bin/wsrf-query –s http://myhost:8080/wsrf/services/DefaultIndexService "//*[ local-name()='Address' and contains(.,'ftp://wiggum.mcs.anl.gov:2811') ]/../..//*[ local-name()='AggregatorData' ] " • Query Output: <ns11:AggregatorData xmlns:ns11="http://mds.globus.org/aggregator/types"> <test xmlns:mds="http://www.globus.org/namespaces/2006/8/mds" xmlns=""> <reporter> <name>./gridftp-banner.pl</name> <url>skynet-login</url> </reporter> <target> <name>GridFTP</name> <url>ftp://wiggum.mcs.anl.gov:2811</url> </target> <result> <status>UP</status> <comment applyTransform="true"> <![CDATA[ 220 GridFTP Server wiggum.mcs.anl.gov 2.0 (gcc32dbg, 1114447190-1) ready. ]]> </comment> </result> </test> </ns11:AggregatorData> MDS for Developers
ExecutionAggregatorSource: Conclusion • Useful for Non-WSRF Services • Developers can implement their own information providers using ExecutionAggregatorSource in a similar manner. • Benefits of this approach: • Information modeled as ServiceGroupEntry content. • WS-Lifetime interfaces used to manage information lifetime for each ServiceGroupEntry resource. • WSRF and Non-WSRF Service information can co-exist in the same Service Group, in this case, the DefaultIndexService. MDS for Developers
Trigger Service • Using the Trigger Service to monitor other services so that user programs may be invoked when specific conditions are detected. • The Trigger Service may be used to monitor the results of data aggregation operations for both WSRF and Non-WSRF services. • The Trigger Service can be configured to probe information directly, or can also be configured to probe summary information from another service already aggregating information, such as the IndexService. • This example will show how to use the DefaultTriggerService to monitor the DefaultIndexService in order to detect and trigger a status notification email when a GridFTP service (as described in the previous section) goes down. MDS for Developers
Trigger Service: Configuration • Configuring the container’s DefaultTriggerService: • Step 1: Enable the email action script that will be used by the DefaultTriggerService. • Step 2: Edit the email action script to specify the addressee and optional event description. • Step 3: Edit the registration file that will be used with mds-servicegroup-add that will be used to register the trigger configuration to the DefaultTriggerService. • Step 4: Run the mds-servicegroup-add command to register and activate the trigger and query the DefaultTriggerService for status about the trigger state. MDS for Developers
Trigger Service Example: Step 1 • Step 1: Enable the email action script that will be used by the DefaultTriggerService • Like the ExecutionAggregatorSource, for security reasons all trigger action scripts used by the TriggerService must be enumerated by the administrator of the Globus installation prior to starting the container. • The administrator is required to map a logical “action name” to the physical filename of the executable trigger action. Furthermore, the information provider executable file must by located in the following directory: $GLOBUS_LOCATION/libexec/trigger • In this case, edit the TriggerConfiguration block of the Trigger Service jndi-config.xml as follows: <resource name="configuration" type="org.globus.mds.aggregator.impl.AggregatorConfiguration"> … <parameter> <name>executableMappings</name> <value>email-trigger=email-trigger.sh, test-trigger=test-trigger-action.sh, glue-trigger=glue-trigger-action.sh, echo-trigger=echo-trigger-action.sh</value> </parameter> … </resource> MDS for Developers
Trigger Service Example, Step 2 • Step 2: Edit the email action script to specify the addressee and optional event description. • Create a file called email-trigger.sh file in $GLOBUS_LOCATION/libexec/trigger • NOTE: Make sure the file has permissions allowing it to be executed by the user account that the container process will run as. • The following file can be used as a template for those systems that have the mailx program installed. #!/bin/sh TO=user@addr.net CC= SUBJECT="Your event has been triggered" DATE=`date '+20%y-%m-%d'` MSG="The GridFTP server at ftp://wiggum.mcs.anl.gov:2811 is down." echo "$MSG" | mailx -s "$SUBJECT" $CC $TO cat <<FIN <?xml version="1.0" encoding="UTF-8"?> <TriggerAction> <message>$SUBJECT</message> <status>DOWN</status> <time>$DATE</time> </TriggerAction> FIN MDS for Developers
Trigger Service Example, Step 3 • Step 3: Edit the registration file that will be used with mds-servicegroup-add that will be used to register the trigger configuration to the DefaultTriggerService. <?xml version="1.0" encoding="UTF-8" ?> <ServiceGroupRegistrations> <defaultServiceGroupEPR><wsa:Address>http://localhost:8080/wsrf/services/DefaultTriggerService</wsa:Address></defaultServiceGroupEPR> <ServiceGroupRegistrationParameters> <RegistrantEPR xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"> <wsa:Address>http://localhost:8080/wsrf/services/DefaultIndexService</wsa:Address> </RegistrantEPR> <RefreshIntervalSecs>600</RefreshIntervalSecs> <Content xsi:type="agg:AggregatorContent" xmlns:agg="http://mds.globus.org/aggregator/types"> <agg:AggregatorConfig xsi:type="agg:AggregatorConfig"> <agg:GetMultipleResourcePropertiesPollType xmlns:wssg="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ServiceGroup-1.2-draft-01.xsd"> <agg:PollIntervalMillis>150000</agg:PollIntervalMillis> <agg:ResourcePropertyNames> wssg:Entry </agg:ResourcePropertyNames> </agg:GetMultipleResourcePropertiesPollType> <trigger:TriggerRuleType> <trigger:matchingRule> //test[target/url='ftp://wiggum.mcs.anl.gov:2811' and result/status='DOWN'] </trigger:matchingRule> <trigger:actionScript>email-trigger</trigger:actionScript> <trigger:minimumFiringInterval>86400</trigger:minimumFiringInterval> <trigger:minimumMatchTime>300</trigger:minimumMatchTime> <trigger:enableFilteredActionScriptInput>true</trigger:enableFilteredActionScriptInput> <trigger:disableUnmodifiedActionScriptInput>true</trigger:disableUnmodifiedActionScriptInput> </trigger:TriggerRuleType> </agg:AggregatorConfig> <agg:AggregatorData/> </Content> </ServiceGroupRegistrationParameters> </ServiceGroupRegistrations> MDS for Developers
Trigger Service Example, Step 4 • Step 4: Run the mds-servicegroup-add command to register and activate the trigger and query the DefaultTriggerService for status about the trigger state. • Run mds-servicegroup-add using the email trigger registration file. • Query the DefaultTriggerService for the trigger state: • wsrf-query -s http://localhost:8080/wsrf/services/DefaultTriggerService "//*[local-name()='TriggerStatusArray'] “ • Sample Query Output: <ns13:TriggerStatusArray xmlns:ns13="http://mds.globus.org/2004/08/trigger/types"> <ns13:triggerStatus> <ns13:triggerID>07b3f440-3710-11db-bf4d-89fc4ea14c8f</ns13:triggerID> <ns13:matchingRule>//test[target/url='ftp://wiggum.mcs.anl.gov:2815' and result/status='DOWN']</ns13:matchingRule> <ns13:conditionTrueSince>2006-08-29T03:40:52.575Z</ns13:conditionTrueSince> <ns13:actionFiredAt>2006-08-29T03:41:52.668Z</ns13:actionFiredAt> <ns13:ruleLastCheckedAt>2006-08-29T03:41:52.564Z</ns13:ruleLastCheckedAt> <ns13:actionOutput> <TriggerAction xmlns=""> <message>Your event has been triggered</message> <status>DOWN</status> <time>2006-08-28</time> </TriggerAction> </ns13:actionOutput> <ns13:statusInfo>The trigger action was executed successfully</ns13:statusInfo> </ns13:triggerStatus> </ns13:TriggerStatusArray> MDS for Developers
Querying the Index Service • Standard QueryResourceProperties WSRF request • takes a dialect and a query expression • GT4 supports the standard xpath dialect: • Examples: • / - returns entire xml tree • //glue:Cluster returns all elements of that type • Limitations: can’t specify namespace mappings (e.g., can’t guarantee that “glue” will be recognized in second example) • Workaround: use xpath functions like local-name • //*[local-name()='Cluster'] MDS for Developers
QueryResourceProperties Overview • Set up a porttype object. • Server address • security options • Create query arguments. • dialect • query • Run query request MDS for Developers
Set Up the Porttype Object String myURL = “https://myhost:8443/wsrf/services/DefaultIndexService” EndpointReferenceType endpoint = new EndpointReferenceType(); endpoint.setAddress(new AttributedURI(myURL)); WSResourcePropertiesServiceAddressingLocator locator = new WSResourcePropertiesServiceAddressingLocator(); QueryResourceProperties_PortType port; try { port = locator.getQueryResourcePropertiesPort(endpoint); } catch (ServiceException e) { // Do something. } ((Stub)port)._setProperty( Constants.GSI_ANONYMOUS, Boolean.TRUE); MDS for Developers
Create Query Arguments (XPath) String queryString = “/”; QueryExpressionType query = new QueryExpressionType(); try { query.setDialect(WSRFConstants.XPATH_1_DIALECT); } catch (MalformedURIException e) { // Do something. } query.setValue(queryString); QueryResourceProperties_Element request = new QueryResourceProperties_Element(); request.setQueryExpression(query); MDS for Developers
Run Query QueryResourcePropertiesResponse response; try { response = port.queryResourceProperties(request); } catch (RemoteException e) { // Do something. } // response is an array of MessageElement System.out.println( AnyHelper.toSingleString(response)); MDS for Developers
targetedXPath • GT4.1.x has a new dialect, targetedXPath • XPath dialect is still there • Allows the user to specify namespace mappings for use in queries • Usage is the same as with the XPath dialect, except that setting up the query args is different MDS for Developers
Create Query Arguments (targetedXPath) TargetedXPathQueryType targetedQuery = new TargetedXPathQueryType(); NamespaceMappingType nsMap[] = new NamespaceMappingType[1]; nsMap[0] = new NamespaceMappingType(); nsMap[0].setMappedName(“glue”); nsMap[0].setNamespace( new URI(“http://mds.globus.org/glue/ce/1.1”)); targetedQuery.setNamespaceMappings(nsMap); targetedQuery.setQueryString(“//glue:Cluster”); QueryExpressionType query = new QueryExpressionType(); try { query.setDialect(TargetedXPathConstants.TARGETED_XPATH_DIALECT); } catch (MalformedURIException e) { // Do something. } query.setValue(targetedQuery); MDS for Developers
WebMDS MDS for Developers
WebMDS: How it Works Index Service Web Form XSL Transform Resource property query plugin plugin HTML Output HTTP query with form arguments Web Browser WebMDS MDS for Developers
WebMDS and HTML Forms For a URL like http://myhost:8080/webmds/webmds?info=indexinfo • “info” arg tells WebMDS where to get data • Looks for “indexinfo” file in WebMDS conf directory • “info” is the only mandatory argument • Optional “xsl” arg tells WebMDS where to get the XSL transform • Uses same config mechanism as “info” arg • Other arguments are available MDS for Developers
WebMDS Plugins • Resource Property Plugin • Performs resource property queries • Can be configured to accept an EPR argument. • Implemented by “openEndedQuery” conf file • Can be configured to query a specific EPR • Implemented by “indexinfo” conf file • File Plugin • Reads a file • Useful for getting XML transforms • Also used for testing MDS for Developers
WebMDS openEndedQuery <WebmdsConfig> <description> Resource property query of the local default index service </description> <className>org.globus...NodeXmlSource</className> <parameter> <name>class</name> <value>org.globus...ResourcePropertyQueryNodeSource</value> </parameter> <parameter> <name>allowUserEndpoints</name> <value>true</value> </parameter> </WebmdsConfig> MDS for Developers
WebMDS Resource Property Plugin <WebmdsConfig> <description> Resource property query of the local default index service </description> <className>org.globus...xmlDomNode.NodeXmlSource</className> <parameter> <name>class</name> <value>org.globus.mds...ResourcePropertyQueryNodeSource</value> </parameter> <parameter> <name>endpoint</name> <value> https://127.0.0.1:8443/wsrf/services/DefaultIndexService </value> </parameter> </WebmdsConfig> MDS for Developers
WebMDS File Plugin <WebmdsConfig> <description> XSL file to show service group summary information </description> <className>org.globus...FileXmlSource</className> <suitableForXSL>true</suitableForXSL> <parameter> <name>file</name> <value>xslfiles/servicegrouptable.xsl</value> </parameter> </WebmdsConfig> MDS for Developers
Implementing a New XSL Transform • Write an XSL transform • Create a config file in $GLOBUS_LOCATION/lib/webmds/conf • Use a web browser to test the transform MDS for Developers
WebMDS – Write an XSL Transform • XSL is documented at http://www.w3.org/TR/xslt • There are many examples of XSL transforms in $GLOBUS_LOCATION/lib/webmds/xslfiles • Install the transform in $GLOBUS_LOCATION/lib/webmds/xslfiles/local • For purposes of this example, call the file “mytransform.xsl” MDS for Developers
WebMDS – Configure an XSL Transform • Create a config file in $GLOBUS_LOCATION/lib/webmds/conf • For this example, call the file “mytransform” <WebmdsConfig> <description> XSL file to implement my custom transform </description> <className>org.globus...FileXmlSource</className> <suitableForXSL>true</suitableForXSL> <parameter> <name>file</name> <value>xslfiles/local/mytransform.xsl</value> </parameter> </WebmdsConfig> MDS for Developers