This component consists abstractly of two interfaces: the Managed Job Factory Port Type(MJFPT) and the Managed Job Port Type (MJPT).

In actuality there are three service/resource implementations, two of which implement the basic MJPT. The first one is the service which actually talks to a particular local resource manager to execute a process on the remote computer or cluster. This one is called a Managed Executable Job Service (MEJS) and its resource is called the Managed Executable Job Resource (MEJR). The second is a special implementation which accepts a multi-job description, breaks the description up into single-job descriptions, and then submits each of these so-called "sub-jobs" to an MEJS. This implementation is called the Managed Multi-Job Service (MMJS). Its resource is called the Managed Multi-Job Resource (MMJR)

Because of the fact that these two job services use the same port type, the API for accessing both the MEJR and the MMJR are identical. The MJFS creates the appropriate job resource depending on the factory resource used to qualify the operation call. Most of the factory resources represent local resource managers used by the MEJS (PBS, LSF, Condor). There is a special Multi factory resource which represents an abstract multi-job resource manager. The appropriate job description type is required for the two different types of managed job.

Java API Documentation Links (Javadoc)

C API Documentation Links

WS-GRAM allows for remote execution and management of programs through the creation of a managed job. The management of the job is taken care of primarily by core toolkit functionality (WS-ResourceLifetime and WS-BaseN implementations). Please see the Java WS Core documentation on notifications and resource lifetime (destruction) for more information.

There are just two operations defined in the GRAM port types (not counting the Rendezvous port type which is used for MPI job synchronization): "createManagedJob" in the Managed Job Factory port type, and "release" in the Managed Job port type. All other operations (such as canceling/killing the job and querying for resource properties) are provided by the underlying WSRF implementation of the toolkit.

WSDL links:

Schema links:

The general form of a job description used to start a single job (meant for creating a Managed Executable Job Resource instance) is as follows:

<job>
    <!--put additional elements here-->
    <executable><!--put executable pat here--></executable>
    <!--put additional elements here-->
</job>

Here is a basic example of a job description for a single-job:

<job>
    <executable>bin/echo</executable>
    <argument>Testing</argument>
    <argument>1...2...3</argument>
    <stdout>${GLOBUS_USER_HOME}/stdout</stdout>
    <stderr>${GLOBUS_USER_HOME}/stderr</stderr>
</job>

The general form of a job description used to start a multi-job (meant for creating a Managed Multi Job Resource instance) is as follows:

<multiJob>
    <!--Put subjob default elements here.-->
    <job>
        <factoryEndpoint
                xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job"
                xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
            <wsa:Address>
                <!--put ManagedJobFactoryService address here-->
            </wsa:Address>
            <wsa:ReferenceProperties>
                <gram:ResourceID><!--put scheduler type here--></gram:ResourceID>
            </wsa:ReferenceProperties>
        </factoryEndpoint>
        <executable><!--put executable path here--></executable>
    </job>
    <!--put additional job elements here-->
</multiJob>

Here is a basic example of a job description for a multi-job:

<multiJob>
    <executable>/bin/echo</executable>
    <stdout>${GLOBUS_USER_HOME}/stdout</stdout>
    <stderr>${GLOBUS_USER_HOME}/stderr</stderr>
    <job>
        <factoryEndpoint
                xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job"
                xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
            <wsa:Address>
                https://mymachine.mydomain.com:8443/wsrf/services/ManagedJobFactoryService
            </wsa:Address>
            <wsa:ReferenceProperties>
                <gram:ResourceID>Pbs</gram:ResourceID>
            </wsa:ReferenceProperties>
        </factoryEndpoint>
        <argument>Testing</argument>
        <argument>1...2...3</argument>
    <job>
    <job>
        <factoryEndpoint
                xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job"
                xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
            <wsa:Address>
                https://myothermachine.myotherdomain.org:8443/wsrf/services/ManagedJobFactoryService
            </wsa:Address>
            <wsa:ReferenceProperties>
                <gram:ResourceID>Pbs</gram:ResourceID>
            </wsa:ReferenceProperties>
        </factoryEndpoint>
        <argument>Hi There!</argument>
        <argument>Dear John!</argument>
    </job>
</multiJob>

The WS-GRAM job description schema imports types from the RFT job description schema for specifying staging directives (i.e. fileStageIn, fileStageOut, and fileCleanUp). See the RFT domain-specific interface documentation for details on these imported types.

Since fileStageIn and fileStageOut are of type TransferRequestType and fileCleanUp is of type DeleteRequestType, mentally replace "transferRequest" with "fileStageIn" or "fileStageOut", and "deleteRequest" with "fileCleanUp" in the RFT domain-specific interface documentation. The Request Options section is of particular usefullness.

Please see the Job Description Schema documentation for details about the job description elements and substitution variables used to define GRAM jobs.