Globus Toolkit 3.0 FAQ

General

  1. What would one gain by turning an existing Web Service into a Grid Service?
  2. One of our goals is for data sharing. Does GT3 provide the capability to query data from multiple sources in a Grid environment? For example, if I wanted to search for data among all Grid Services that may provide it.
  3. We would like to know more about the security in GT3. If we want to develop multiple Grid Services and deploy them in a Grid, should user authentication and authorization data be saved in a centralized DB?
  4. How would one convert an existing Web Service to a Grid Service?
  5. We would like to make our Grid Services fully portable to other sites. How easily can one download, install and deploy a Grid service?
  6. Are there any other OGSI implementations?
  7. Does GT3 and/or OGSI support operation overloading?

GT3 Core

  1. Can I deploy my services into a container at run time?
  2. What do I have to do to make sure that my service is activated when the container starts up?
  3. Why can I only access my service running on Linux from the local host?
  4. How do I make my service publish itself with a host name instead of an IP address?
  5. I get a socket read timeout error during heavy load, how can I change that behavior?
  6. Is Apache Ant a required or optional tool?

GRAM

  1. How do I shut down the container after the MMJFS is deployed?
  2. How do I fix the following error: "org.globus.gsi.proxy.ProxyPathValidatorException: Desired service path not found in policy"?
  3. How do I fix the following error: "org.globus.gsi.proxy.ProxyPathValidatorException: Client DN not found in policy"?
  4. Can GRAM we deployed into Tomcat?

Tomcat

  1. How do I change the ogsi logging settings in Tomcat?
  2. What Tomcat versions does GT3 support?
  3. Can a gar file be directly deployed into GT3 running in Tomcat?

General

What would one gain by turning an existing Web Service into a Grid Service?

Grid Services are Web Services that provide a well-defined set of basic functionality. Specifically, all Grid Services provide the basic set of methods described in the OGSI (Open Grid Services Infrastructure) specification.

The general value added for Grid Services above and beyond ordinary Web Services includes:

  • A sophisticated security infrastructure (see question on security below)
  • A standard service invocation mechanism for service lifetime management
  • State management
  • A standard service inquiry mechanism

Grid Services are invoked using a "service factory" mechanism. When an application needs to use a Grid service, it contacts a "factory" and requests an instance of the service. The factory creates a service instance and gives the application a reference to the instance. This standard mechanism enables sophisticated service management capabilities.

Service lifetime management provides a mechanism for ensuring that services are "cleaned up" when they are no longer needed. Each service invocation includes an indication of how long the service will be needed. If a client application "crashes" or simply stops communicating with a service, the service and all resources it uses will automatically be cleaned up when the lifetime expires. Applications may extend the lifetime of a service if they continue to require the service beyond the original lifetime.

State management allows Grid Services to maintain state between separate requests. Rather than providing a strict request/response interface like most Web Services, Grid service instances are persistent (within their lifetime), enabling connectionless interactions, multiple client connections, and client failure recovery. State management allows a Grid service to maintain internal state between connections.

Grid Services provide a standard interface for applications and other services to inquire about their internal state. For example, a service that provides computation capabilities might provide an interface for inquiring about the state of a computation in progress, the type of system on which computation requests are executed, and/or the types of computation requests that will be honored. All of these would use a standard inquiry mechanism provided by all Grid Services, and thus the information provided can be aggregated using standard push and pull mechanisms and used for a variety of purposes. (E.g., a dynamic directory of available services, aggregation of information on available computing power, graphical viewers showing locations and characteristics of sites and services in a Grid, etc.)

[ top ]

One of our goals is for data sharing. Does GT3 provide the capability to query data from multiple sources in a Grid environment? For example, if I wanted to search for data among all Grid Services that may provide it.

The scenario described in this question is common among data-intensive scientific applications, and one that figures prominently in our work on Grid technologies. Key elements of the solution include:

  1. A standard framework (OGSI) for all Grid Services used in the application; this greatly simplifies the complexity of the application and the manageability of the Grid Services
  2. A security framework (GSI) that enables the user to delegate their credentials to the searching service so that it can authenticate to the many data repositories on the user's behalf (see security question below)
  3. An OGSI-compliant metadata catalog that enables the application to translate high-level, domain-specific descriptions of the necessary data into specific filenames, data tables, or other physical data objects.
  4. An OGSI-compliant replica location service that tracks the locations of all copies of physical files and data tables.
  5. An OGSI-compliant mechanism for retrieving the data from the physical system.
  6. Standard ways to aggregate state information from a large number of services and perform queries across all of the aggregated data.

The end user's application would allow the user to sign on once? using their Grid pass phrase, and then would invoke the data search service, giving it a domain-specific description of the required data. The search service would use the metadata catalog service to identify specific files and/or data tables, and then the replica location service to identify physical locations for the data. The application would then retrieve and process the data from the physical locations.

[ top ]

We would like to know more about the security in GT3. If we want to develop multiple Grid Services and deploy them in a Grid, should user authentication and authorization data be saved in a centralized DB?

Security is one of the areas where the Grid provides compelling value, and it is one of the prime motivating forces behind the Grid movement. The Grid approach to security is to use PKI (Public Key Infrastructure) technology coupled with Web Services. Grid technology offers a compelling "single sign on" capability that allows end-user applications to utilize many Grid Services without forcing the end user to keep track of multiple credentials or to enter authorization information more than once.

Authentication is accomplished using Grid certificates. Each end user and each service has a certificate associated with it. The end user must enter a "pass phrase" in order to allow an application to access their certificate, and the application may then use the same certificate to authenticate the user to any number of Grid Services. The application may also "delegate" the user's credential to a Grid service, allowing that Grid service to use other Grid Services on the end user's behalf. The end user's certificate may be stored on their local computer system, in an electronic "smartcard," or in a secure online "credential repository" where it can be accessed by the user from any location. (The latter capability is useful for people who use multiple computer systems, including public terminals.)

Each Grid service must be configured to authorize specific users to use the service. (Users are specified by the name in their Grid certificate, as opposed to a local account name that would vary from system to system.) In large Grids, manual configuration of every user on every service may not be possible, so the Grid community has developed a number of tools to ease this work, including tools to synchronize authorization data for multiple services and tools to manage authorization in a collective fashion (essentially enabling management of entire classes or groups of users rather than individuals).

Grid security relies on trusted "certificate authorities" to issue certificates for both users and Grid Services. A Grid service may accept certificates from several certificate authorities, and an end user may have certificates issued by more than one certificate authority. A number of public and private certificate authorities are available, and open source software for operating a certificate authority is also available.

[ top ]

How would one convert an existing Web Service to a Grid Service?

Grid Services are web services that provide the basic set of methods described in the OGSI (Open Grid Services Infrastructure) specification. The Globus Toolkit 3.0 provides Java classes that implement the OGSI core features. If an existing web service is written in Java, the service implementation can be modified to be a subclass of these basic Grid service classes, so that the OGSI functionality is provided automatically. Additional work could then be done to more cleanly integrate the capabilities offered by the OGSI methods and the features offered by the original web service. To take full advantage of the capabilities offered by the OGSA architecture, the application might require some reorganization. The degree to which OGSA is incorporated into an application is actually quite flexible.

[ top ]

We would like to make our Grid Services fully portable to other sites. How easily can one download, install and deploy a Grid service?

Grid Services are essentially the same as Web Services. They require a hosting environment and an OGSI implementation, but otherwise they are fairly simple pieces of Java, Python, or .NET code.

There are several options for the hosting environment, ranging from a standalone hosting environment provided with the Globus Toolkit 3.0 to open source hosting environments such as J2EE/J2SE or commercial hosting environments such as Oracle Application Server or IBM's WebSphere.

The Globus Toolkit 3.0's OGSI implementation (a set of Java classes) can be easily installed with or without the rest of the Globus Toolkit. (Python and .NET OGSI implementations are also available from the Grid community.)

Once the hosting environment and OGSI implementation are installed, installing and deploying a Grid Service is roughly the same as installing and deploying a Web Service.

We have a couple of packaging techniques using GPT and gars which you might find useful.

[ top ]

Are there any other OGSI implementations?

Yes! There are a few other OGSI implementations available from the Grid community:

[ top ]

Does GT3 and/or OGSI support operation overloading?

OGSI has no notion of operation overloading. Operation overloading was allowed under WSDL 1.1 but it is not allowed in WSDL 1.2. We do not recommend relying on operation overloading as it may cause problems with dynamic systems such as workflow engines.

Use separately named operations with different syntaxes, or one generic operation with generic/document-extensible syntax instead.

[ top ]

GT3 Core

Can I deploy my services into a container at run time?

We currently don't support this for persistent services. All persistent services have to be deployed into the container when its hosting environment is not running. Transient services (created by factories) are however designed to be deployed at run time into a container. Future versions may allow run time deployment of persistent services as well.

[ top ]

What do I have to do to make sure that my service is activated when the container starts up?

When a container starts up, all its services are deactivated by default. In order to change that behavior you need to set the property "activateOnStartup" to "true" in the service section of your service in the deployment descriptor. Note that activation will then take place the first time the container is loaded. In the case of our standalone container this happens at server startup, but in the case of a Servlet Engine, like Tomcat, it does not happen until the servlet is loaded as result of an invocation.

[ top ]

Why can I only access my service running on Linux from the local host?

If you do not have an entry in etc/hosts for your current IP address, the loopback address 127.0.0.1 will be used to publish the service handle, and thus limiting access to it to the local host. Updating the etc/hosts file is hence recommended. You can however also specify what DNS name should be exposed in the handle of a service by setting the global parameter "logicalHostName" in you server-config.wsdd file in the globalConfiguration section. See User's Guide for details.

[ top ]

How do I make my service publish itself with a host name instead of an IP address?

In the server-config.wsdd file in the globalConfiguration section set the parameter "publishHostName" to "true". See User's Guide for details.

[ top ]

I get a socket read timeout error during heavy load, how can I change that behavior?

The ogsilogging.properties file contains the log filter settings you would need to change. This file must be in your current directory or in the classpath in order to be correctly read by our container. When deploying your services into Tomcat this file ends up in <tomcat dir>/webapps/ogsa/WEB-INF. In order to read the settings in this file after your modifications you need to add that directory to your CLASSPATH variable before you start tomcat.

I get a socket read timeout error during heavy load, how can I change that behavior?

By default the timeout of a Grid service invocation is 60 seconds. In order to change this behavior you have two options:

  1. Change a property on the stub that you use to invoke the service. How to do that is described in the following FAQ:

    See our Performance Guide for more details.

  2. In you client JVM set the system property: 
     -Dorg.globus.ogsa.client.timeout=(milliseconds)

    To set system properties for the globus provided command line clients in the bin directory set the OPTIONS environment variable to the full string -Dorg....

    If you use version 3.0 or earlier you need to do two additional things to enable this feature:

      2.1 Download timeout handler gar from:

      and deploy it using: 

       ant deploy -Dgar.name=ogsa-timeout.gar

      2.2 Change the client-config.wsdd file in your distribution to contain this handle in the requestFlow Ex: 

       <requestFlow>
   <handler type="java:org.globus.ogsa.handlers.TimeOutHandler"/>
   <handler type="java:org.globus.ogsa.handlers.RoutingRequestHandler"/>
...

      Make sure that your modified client-config.wsdd is either in the same directory from where you run the client or in the classpath of the client JVM.

[ top ]

Is Apache Ant a required or optional tool?

Apache Ant is a required tool for the GT3 source distribution. It is used to compile and assemble all the GT3 code. With the binary installations, Ant is needed to generate platform-specific command-line scripts for executing GT3 clients. It is also needed to deploy and undeploy new services to and from the GT3 container. If you don't need this functionality Ant is not required for binary installations. For developing new services we recommend using Ant as GT3 already provides lots of common operations as callable Ant tasks.

[ top ]

GRAM

How do I shut down the container after the MMJFS is deployed?

If you installed the MMJFS, then the container will start up with the grim credentials by default. To shut it down you then also need to use the grim credentials. The easiest way of doing that is to set the X509_USER_PROXY environment variable to point to the grim proxy that was generated for your user. Typically that is /tmp/x509cp_[user]_grim.

[ top ]

How do I fix the following error: "org.globus.gsi.proxy.ProxyPathValidatorException: Desired service path not found in policy"?

All of the "policy" based errors come from globus-grim. This particular error means that the /etc/grid-security/grim-port-type.xml file has not been properly formatted. If you copied it from step 3.2 in the Admin Guide, make sure you did not introduce any extra newlines or spaces. The <port_type> entry should all be on one line.

[ top ]

How do I fix the following error: "org.globus.gsi.proxy.ProxyPathValidatorException: Client DN not found in policy"?

All of the "policy" based errors come from globus-grim. This particular error means that the /etc/grid-security/grim-port-type.xml file has not been properly configured. Each user that can start a job with MMJFS must have a have <port_type> entry in grim-port-type.xml file. Also, the user that is running the master container must have an entry in the grim-port-type.xml file. Please see the Admin Guide for details

[ top ]

Can GRAM we deployed into Tomcat?

Yes, but we currently do not test and recommend such configuration.

[ top ]

Tomcat

How do I change the ogsi logging settings in Tomcat?

The ogsilogging.properties file contains the log filter settings you would need to change. This file must be in your current directory or in the classpath in order to be correctly read by our container. When deploying your services into Tomcat this file ends up in webapps/ogsa/WEB-INF. In order to read the settings in this file after your modifications you need to add that directory to your CLASSPATH variable before you start tomcat.

[ top ]

What Tomcat versions does GT3 support?

GT3 was tested with Tomcat 4.1.27 and 4.0.6. It was not tested with any Tomcat 5.0.x versions.

[ top ]

Can a gar file be directly deployed into GT3 running in Tomcat?

No, right now such deployment option is not supported.

[ top ]