| In the context of GT3, information services have to fulfill the following requirements: -
A basis for configuration and adaptation in heterogeneous environments -
Uniform and flexible access to static and dynamic information -
Scalable and efficient access to data -
Access to multiple information sources -
Decentralized maintenance capabilities Our discussion will be focused on GT3, the latest toolkit based on the OGSI. In the GT3 base, the information services consist of a broad framework that includes any part of GT3. This framework can generate important capabilities, such as register, index, aggregate, subscribe, monitor, query, and/or display service data. The core concepts of information services in GT3 are centered on how to create, update, and query service data; this forms the public state of a service/resource. GT3 provides a set of information services built utilizing a service data component model. Utilizing the GT3 core programming features, which we have discussed in the last two chapters, develops this component model. The development of a component model helps service developers to deal with the complexity of software management in relatively small manageable software modules. The GT3- offered component model is based upon Java. Figure 14.2 shows the major information services available with the GT3 base, and the components utilized by these services. The details related to this discussion on this component model and services are as follows : -
The GT3 framework provides a component model that can be utilized to create and deliver information services. -
The GT3 framework provides high-level applications and services, built upon the above component model. Figure 14.2. The GT3 components and information services.  Component Model for Information Services These components provide a standard means -
to create the service data from other grid services and external applications. -
to aggregate the service data values and categorize them in a form required by the application. -
to provide the storage location(s) to register and store grid service handles. These registered grid services provide service data either through a provider "pull" or through notification on the service data change. Generally speaking, there are three types of components available: service data provider components, service data aggregation components, and registry components. Let us now further explore each of these components, their functionalities, and their programming models. Service Data Provider Components These providers enable a standard mechanism for dynamic service data generation from external programs. The GT3 core provides a set of providers, which provides some common set of functionalities. We will cover the usage of these providers later in this chapter when we introduce the index services. We can extend these providers, or add on new providers. The service data provider interfaces are designed to support the execution in either synchronous (pull) or asynchronous (push) modes. Different provider interfaces are available and selected based on their functionalities. These provider interfaces are: SimpleDataProvider. This is a synchronous provider that is capable of producing output in XML format in a Java OutputStream. Listing 14.1. The simpleDataProvider interface. public interface SimpleDataProvider { ........................................................ /* Triggers the execution of the provider in order to update the provider's internal state, but does not perform any output.*/ void update (String args) throws Exception; /* Triggers the provider to serialize its current internal state to the specified OutputStream */ void output (java.io.OutputStream outStream) throws Exception; /*Triggers the execution of the provider in order to update the provider's internal state, sending the output to the specified OutputStream. */ void run (String args, java.io.OutputStream outStream) throws Exception; } Listing 14.1 shows the important operations allowed on a simpleDataProvider. DOMDataProvider. Similar to the above SimpleDataProvider, this object, shown in Listing 14.2, is also a synchronous provider that can generate XML output in a w3c.dom.Document XML format. Listing 14.2. The DOMDataProvider interface. public interface DOMDataProvider extends SimpleDataProvider{ public org.w3c.dom.Document outputDocument () throws Exception; } This is an extension to the SimpleDataProvider, and provides an additional method to output the internal state of the provider as a DOM Document. AsyncDataProvider. Shown in Listing 14.3, this is an asynchronous provider that can support the above two data formats (i.e., XML data in OutputStream object, and XML document in w3c.dom.document format). Listing 14.3. The AsyncDataProvider. (Continued) public interface AsyncDataProvider extends SimpleDataProvider{ /* Triggers the asynchronous execution of the provider, sending the output to the specified callback object. It will execute the callback name on the callback object. Context is defined by the calling thread. */ void run (String args, String callbackName, ServiceDataProviderDocumentCallback callback, Object context) throws Exception; /* Signals the provider to shut down, cease data callbacks, and free any associated resources */ void terminate () throws Exception; /* Retrieve the current state */ int getState (); } This provider enables an asynchronous call to a specified object. The following section describes some of the internal details on this provider implementation. Internal Details on Provider Execution There is a provider manager (ServiceDataProviderManager) that is responsible for scheduling and managing the provider execution. This provider manager is a GT3 operation provider with two exposed methods , "enumProvider" and "executeProvider." These operations are exposed in the WSDL portType definition for the provider manager. The provider manager, in turn , delegates the execution to the provider of choice. These available providers are listed in a configuration file. For example, to register the provider called HostScriptProvider, add the following entry in the configuration file: <provider class="org.globus.ogsa.impl.base.providers.servicedata.impl .HostScriptProvider"/> The list below describes a simple ServiceDataProviderManager implementation: public class ServiceDataProviderManager implements ServiceDataProviderExecutionPortType, ServiceProviderExecutionCallback, ServiceDataProviderDocumentCallback, OperationProvider{ .................................... public ServiceDataProviderEnumType[] enumProvider(boolean rescanConfig){ } public void executeProvider(ServiceDataProviderExecutionType newServiceData, Object callback){ } ................................................... } Normally speaking, the provider manager will convert the provider output to an XML message in a ServiceDataElement, and then add that to the service's ServiceDataSet. Registering a custom callback (ServiceDataProviderExecutionCallback) with provider manager, and accessing the results from the provider, can override the preestablished functionality. This operation is simple to establish, as one can pass the callback object along with the "executeProvider" operation. The callback object must be of the type ServiceDataProviderDocumentCallback, it must provide an operation name, and the expected parameters. The provider manager will perform run-time introspection on the object method, and invoke the method with the expected parameters. The following describes how one can perform this operation: Public class myCallbackObject implements ServiceDataProviderDocumentCallback{ public String getdefaultCallbackMethodName(){ return "myMethod"; } public class[] getCallbackParamSig(String methodName){ return new class[] ={Class.forName("org.w3c.dom.Document")}; } public boolean myMethod(org.w3.dom.Document){ // the results of the provider execution comes here // we can do whatever we want } } To pass the above callback object call, execute the following: executeProvider(service data provider execution type, new myCallbackObject()); This is a very powerful feature by which grid developers can override the provider manager's default internal logic without having the provider manager source code. |
As we have just discussed, a provider manager can maintain two unique types of operations, "enumProviders" and "executeProvider." The "executeProvider" operation expects to receive a parameter of complex type, defined in WSDL, with the anticipated information, such as provider name, provider implementation class, provider argument, and service data name. This is relevant information for the provider for three reasons, which are instructions regarding service data type, refresh frequency, and whether to execute in synchronous or asynchronous fashion. We will later see how this powerful feature is utilized in the index service implementation. Service Data Aggregation Components This discussion will explore another very interesting aspect of service data management, where we will begin to better understand the aggregation component. Service data coming from various providers can be aggregated in different ways, and then indexed to provide for improved efficiencies related to query processing. This aggregator component is similar to server-side notification sink. [1] In addition to listening for notification of a service data change, this operation provides a mechanism to copy the incoming notification data as local service data elements. This component is implemented as an operation provider with the exposed operations "addSubscription," "removeSubscription," and "deliverNotification." Listing 14.4 shows an example of this implementation, with the extended interfaces. Listing 14.4. The serviceData aggregation operation. public class ServiceDataAggregatorImpl implements ServiceDataAggregatorPortType, OperationProvider, NotificationSinkCallback{ ................................. public String addSubscription(AggregatorSubscriptionType type){ } public void removeSubscription(String subscriptionID){ } public void deliverNotification(ExtensibilityType message){ } Registry Components Registry components are sets of available grid services that are maintained in a registry. This provides a soft state registration mechanism to periodically update service availability. This registry is implemented using the OGSI ServiceGroup mechanisms. A Sample Provider Creation Here are the steps for constructing a sample provider that can read system configurations, and send these as an XML document to the provider manager. -
Write a sample executable that can run and read system properties from the current runtime and dump the results to the output stream as a DOM document (here we are using System.out) Listing 14.5. A sample executable reading the system information and emitting a DOM document. public class SystemInformationCollector{ public static void main(String args[]) { try { SystemInformationCollector sysInfoCollector = new SystemInformationCollector(); // pass the default arguments and System.out as parameters sysInfoCollector.run(argstr,System.out); } catch(Exception e) { e.printStackTrace(); } } public void run(String args, java.io.OutputStream outStream) throws Exception{ Document doc = getSystemInfo(); // Write the DOM document to the provided output stream outStream.write(doc.toString()); } protected Document getSystemInfo() throws Exception{ Runtime runtime = Runtime.getRuntime(); // sample system information long totalMem = runtime.totalMemory(); long freeMem = runtime.freeMemory(); long usedMem = totalMem - freeMem; Document dom = doc = org.apache.axis.utils.XMLUtils.newDocument(); // initialize the DOM document with the above system information return dom; } } -
Write a sample provider, following the programming model that is discussed earlier, that can start the above executable we have created in step 1 and read the output from the output stream. Listing 14.6. A sample DOMDataProvider emitting org.w3c.dom.Document. public class SimpleExecutionProvider implements DOMDataProvider{ protected Document resultDoc = null; protected Process process = null; protected String errorString = ""; /** Creates a new instance of SimpleExecutionProvider */ public SimpleExecutionProvider () { } /** * Triggers the execution of the provider in order to update the provider's * internal state, sending the output to the specified OutputStream */ public org.w3c.dom.Document run(String args) throws Exception{ Document doc = null; /**** Execute the information provider application with the necessary arguments as we defined earlier **/ this.exec(args); // read the output stream of the above created process try{ if (this.process != null) { // assuming the results are written in XML format as specified in the earlier listing doc = org.apache.axis.utils.XMLUtils.newDocument(this.process.getInputStream()); } }catch (Exception e){ throw e; }finally{ // check for the exit state int exit = 0; try { exit = this.process.exitValue(); }catch (IllegalThreadStateException itse) { // if the process is running wait for that process to end. exit = this.process.waitFor(); } } return doc; } // execute the above defined sample system information application private void exec(String args) throws Exception{ // run the sample Runtime runtime = Runtime.getRuntime(); try { this.process = runtime.exec(args); } catch (Exception e) { this.errorString = "Provider Execution error: " + e.getMessage (); throw new Exception(this.errorString); } } } Listing 14.5 and 14.6 demonstrate how to construct a sample provider and how to manage the data. Conclusion Thus far, we have been discussing the component model introduced by GT3 for information services. In addition, we provided treatment to the programming model, and the interfaces associated with the core components. GT3 provides a set of standard components to support some of the built-in information services that comes with the toolkit. You can always create new components and add them to the high-level services through simple configuration options. Having discussed the component model in detail, now it is time to explore some of the GT3 high-level services that are integrated with the GT3 Toolkit. These information services are providing a wide variety of value-added features, and have remained in the Globus toolkit from its inception. This discussion covers the details of the information services, including their value, usage, and implementation aspects. Exploring the designs of these services help us to better understand the component model we have previously discussed. Some of the high-level services we will be reviewing include index services, resource information provider (RIP), and container/virtual organization registry. | 