Folks,

Thanks to Ian for the snippet of GRAM. I'll use it as a basis for my action item to start the scoping exercise for this proposed BoF.

1) I would exclude the delegation stuff. This seems to layer well with GRAM (e.g. it is optional) and therefore should be a separate specification. The combined GRAM and delegation usage pattern would be the subject of a Profile.

2) I believe that the ManagedJobFactory::createManagedJob concept is in scope. I think it should take an open content job description so that the current Globus XML description, JSDL, a "run BLAST" thing , and even run Unicore AJO would all work. The Profile might later mandate that for interoperability only JSDL applies.

3) Now that we have a manageable-job, we need operations on it. From Ian's list, I only have a problem with the implied linkage between release and something the the job description (this is an inhibitor to composition, but that discussion it for the new WG). Some might want other control functions: hold, abort (stops execution but doesn't destroy the resource). This specification should be interoperable from the outset, e.g. no extensibility elements.

4) I agree that the data transfer aspects are out of scope, as is provisioning. A JSDL document (as well as the GRAM equivalent) tells the job container where to get the input files, where to put the output files, and what the source for the executable is. How this happens is not the problem of this interface.

5) The specification should be a WSDL interface and associated semantic description. This doesn't mean that only WSDL based presentations are allowed at the BoF or at the WG, just that the eventual output would be a WSDL spec.

6) The new specification must align and compose with the OGSA Base Profile. There some interesting questions here. The GRAM and Unicore interfaces certainly assume the WSRF infrastructure, but it is clearly possible to build job management web services without WSRF. The WG should discuss the extent to which composition (as opposed to extension) it possible without duplication of function. [Just to clarify: We should not include a 'cancel' operation that does the same function as the Resource Lifetime 'destroy' operation, but if the interface makes sense without either, then the dependancy on lifetime could be relaxed.] It should come as no surprise that I would like to see the whole Basic Profile exploited as much as possible, but that's a discussion for later.

7) Job naming, job migration, job scheduling, scheduling candidates, job placement, job restart/recovery, are all out of scope.

Thoughts?

Do we have a volunteer to start drafting a BoF Call and Draft Charter?

 (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.

--

Take care:

    Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
    Fujitsu Laboratories of Europe
    Hayes Park Central
    Hayes End Road
    Hayes, Middlesex  UB4 8FE

    +44-208-606-4649 (Office)
    +44-208-606-4539 (Fax)
    +44-7768-807526  (Mobile)