Hi, here comes the written info for the scheduling use case: --8<-- snip --8<-- A client sends a request to a scheduler (could be EMS in OGSA speak) using an activity template which describes the requirements of the submitted work unit. The initially receiving (primary) scheduler takes the template and, if it is willing to handle it, creates an activity instance for it, storing the initial template and, if applicable, additional information. The latter should at least include a "provenance record" which denotes that the current scheduler has taken over responsibility for the execution of the given activity. Other candidate information may include scheduling attributes, dependencies to other activities, and the current state of the activity, possibly reusing the BES state model. On activity delegation, the delegator acts like a client towards the potential delegatee, offering the job to another scheduler. Again, if the delegatee is willing to accept the job, it takes over responsibility and the provenance records and depending information (e.g. the expected BES) are updated. If necessary, the activity template may be modified, as long as the manipulation history is kept. Throughout the whole process, state information is constantly updated in the activity record. After activity completion, the resource consumption is written to the activity record. The corresponding entries and dependent parts of the record could then be sealed (marked final) as to denote the completion of the activity. -->8-- snap -->8-- Spanking welcome... Regards, Alexander 2008/4/9, Philipp Wieder <philipp.wieder@udo.edu>:
Hi,
please find a sketch of the scheduling use case here https://forge.gridforum.org/sf/go/doc15178?nav=1. We will try to provide more written info in time before the call.
-- Dipl.-Inform. Alexander Papaspyrou http://ds.e-technik.uni-dortmund.de/~alexp Robotics Research Institute phone : +49(231)755-5058 Information Technology Section fax : +49(231)755-3251 Dortmund University of Technology, Germany