On Mar 22, Toshiyuki Nakata loaded a tape reading: ...
Hmmm. in business oriented jobs we would have a life-cycle of
Job reservation Deployment of the application (including data-bases) Starting the Application Stopping the Application Undeploying the Application
And had assumed that the ageement provider which would understand this kind of job would be able to understand this without having it explicitly stated..
(Also, except for Jobreservation, Deploying/Starting/Stopping/Undeploying would be interfaces of the service provider and not the Agreement Provider..
(I am afraid I am getting off the WS-Agreement topic and so would stop here..)
Best regards Toshi
The job life-cycle you describe is more along the lines of "job submission or service deployment with guarantees" than "advance reservation". All we need to do is add some performance guarantee terms together with the JSDL and the job host can handle all the planning in one step. This is an interesting area where job submission (or generically, service deployment) can be extended with guarantee terms without fundamentally changing the signalling protocol. I think the starting/stopping etc. are additional (optional) management operations on the newly deployed service. We have something similar in GRAM, where we support "hold states" that can pause the otherwise automatic lifecycle. Another rendering choice is whether these management operations are part of the service or part of the "container". We take the latter view in GRAM, so they would extend the Agreement interface which already represents our new transient container for jobs. The actual user job (deployed service) may or may not have any meaningful message interfaces of its own (web or otherwise). I think this is the way to generalize for BES in the way Andrew has advocated, where "jobs" may be of different types, e.g. a web service, a JVM, a fortran code, etc.! You can easily see how a broker might satisfy an abstract web service obligation by establishing more "concrete" agreements to run the underlying implementation components. Advance reservation, in the sense described in the GARA and SNAP work on which this was based, is the explicit decoupling of the "resource promise" from the binding of the resource to a service. It is a 2-phase protocol where one negotiates for the promise of capability and then later binds or "claims" the resource. It is not strictly necessary unless one needs to defer the binding decision or parameterization or deal with differences in cardinality, but it is what I was referring to when I described it separately from job-submission. This is a capability that multiple current batch schedulers possess, and I expect we should be able to expose it via WS-Agreement. karl -- Karl Czajkowski karlcz@univa.com