David: This seems reasonable to me at first glance. The interesting thing is that there is not that much there, if one assumes WSRF/WSN. Ian. At 11:09 AM 1/18/2005 +0000, David Snelling wrote:
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)
_______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org