Dear All:

I promised on today's call to send some information on the GT4 GRAM design. Here it is. I'm sure it's not the ultimate answer, but a lot of thought and experience have gone into defining this set of WSRF/WSN-compliant portTypes for job submission and management.

Comments and questions would be appreciated.

Regards -- Ian.

GT4 GRAM

The GRAM documentation is at: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/wsgram/

Architecture and concepts are described at: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/key/WS_GRAM_Approach.html

In brief, a "GRAM server" is implemented by a "managed job factory", which responds to requests to create managed jobs, and a "delegation factory", which responds to requests to create delegated credentials. Internally, its implementation uses an RFT server to manage staging of input, executables, and output, including streaming output.

The interfaces for the managed job factory and managed job are described here: http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/wsgram/WS_GRAM_Public_Interfaces.html

The delegation interfaces are described here: http://www-unix.globus.org/toolkit/docs/development/3.9.4/security/delegation/WS_AA_Delegation_Service_Public_Interfaces.html

The only really complex operation is ManagedJobFactory::createManagedJob, which takes as an argument a job description in an XML-format job description language described at http://www-unix.globus.org/toolkit/docs/development/3.9.4/execution/wsgram/schemas/mjs_job_description.html. This language can describe arguments, executables, staging requirements, resource requirements, etc.

I also enclose a draft document that may be of interest. This is a very early draft of a GT4 Primer that I'm working on. Pages 29-43 provide a tutorial introduction to GT4 GRAM components from the client perspective. [BTW Any comments would be of great interest!!]

Finally, the following (from the "Architecture and Concepts" page referenced above) describes the protocol:

Protocol Overview

As depicted above, the WS GRAM protocol is centered around the creation of a stateful ManagedJob resource using the ManagedJobFactory createJob() operation. A simple batch job may involve nothing more than this initial client creation step, with all other job lifecycle steps occuring automatically in the server. A number of optional protocol elements are available for more complex scenarios.

(Need to verify operation names.)DelegationFactory::createDelegation

This (optional) step allows a client to delegate credentials that will be required for correct operation of WS GRAM, RFT, or the user's job process. Such credentials are only used when referenced in the subsequent job request and under the condition that WS GRAM or RFT is configured to make use of the DelegationFactory, respectively.

Delegation::refresh

This (optional) step allows a client to update the credentials already established for use with the previous createDelegation step.

ManagedJobFactory::createManagedJob

This required step establishes the stateful ManagedJob resource which implements the job processing described in the input request.

ManagedJob::release

This (optional) step allows the ManagedJob to continue through a state in its lifecycle where it was previously held or scheduled to be held according to details of the original job request. It is a fault to try to release a hold that was not set in the job request or that was already released.

ManagedJob::setTerminationTime

This (optional) step allows the client to reschedule automatic termination to be different than was originally set during creation of the ManagedJob resource.

ManagedJob::destroy

This (optional) step allows the client to explicitly abort a job and destroy the ManagedJob resource, in the event that the scheduled automatic termination time is not adequate.

ManagedJob::subscribe

This (optional) step allows a client to subscribe for notifications of status (and particularly lifecycle status) of the ManagedJob resource. For responsiveness, it is possible to establish an initial subscription in the createJob() operation without an additional round-trip communication to the newly created job.

ManagedJob::queryProperty and queryMultipleProperties

These (optional) steps allow a client to query the status (and particularly lifecycle status) of the ManagedJob resource.