[graap-wg] Telecon on 3/21

[Karl Czajkowski]

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 at univa.com