GT4 Run-time
As GRID superscalar runtime is developed in C++, porting it to Globus Toolkit 4.0 was not extremely easy because when we did the porting there was no C Client API implemented (there was only a Java Client API available). Our first need then was to work directly with the C WS Core bindings in order to submit jobs to the WS GRAM. In order to keep simplicity from the GRID superscalar runtime we designed a little API which was intended to cover our needs of submitting a job, canceling a job, and receiving notifications from that job. The calls defined then are:
globus_wsgram_job_submit(
char * contact,
xmlDocPtr rsl,
wsgram_CreateManagedJobInputType * input,
globus_i_monitor_info_t * monitor,
globus_service_engine_t ** engine,
globus_notification_consumer_func_t callback);
globus_result_t
globus_wsgram_job_cancel(
globus_i_monitor_info_t * monitor,
wsgram_CreateManagedJobInputType * input);
As you can see from the header, one of the differences in the job submission between GT4 and GT2 is that now the RSL is specified in XML language. This means that all the RSL generation previously done had to be translated to XML format. Another important thing to mention is that the scratch_directory attribute that could be given to a GT2 RSL format is no more supported, so this implied adding the generation and final destruction of a scratch directory into the GRID superscalar's worker library, in order to avoid concurrency problems when working with temporary files.
Regarding the callback treatment, the job_contact provided by GT2 is now not available. Anyway, there is a similar information in the monitor related to the job, and available when a callback is received, named "submission_id".
With GT4, GRID superscalar now generates a job request to a remote container. The container then sends a request to the Application Server, that has the GRAM service available. That GRAM service spawns the final job that is going to run into the machine.
