[graap-wg] Telecon on 3/21

[Karl Czajkowski]

On Mar 22, Toshiyuki Nakata loaded a tape reading:

> >Specifically, agreements about "generic execution jobs" or "specific
> >kinds of job" are what we intended the basic agreement creation
> >pattern to handle. Creation==submission. 
> >
> Am I correct in understanding that
> (Agreement ) Creation == (Job) submission?
> 

Yes, or to put it more concretely:

    wsag:createAgreement(...jsdl:job...)

should be a reasonable replacement for

    gram:createManagedJob(...gram:job...).

If we (Globus) do this and there are job-related mechanisms we wish to
keep, we might augment the Agreement portType with those operations
and/or RPs.

Given the way JSDL has gone, it will be up to the context of the JSDL
document in the Agreement to indicate that the agreement is about
executing the job.  They have the word "submission" in the JSDL name,
but I think that is more about scoping the set of job-related
information that is captured in the JSDL specification.  A lot of
what/why the JSDL document exists is left to the messaging context
that makes use of the specification.

For example, one could easily describe two JSDL-bearing agreement
idioms:

  1) Advance reservation for job, indicating that the initiator
     wants a promise that such a job can be accepted later. Additional
     schedule/deadline terms may be introduced since JSDL leaves them
     out of scope.

     One can imagine omitting parts of the JSDL or having some other
     markup/annotations to indicate that some parts are variable
     and will be fixed later in the "submission" agreement.

  2) Job execution, indicating that the initiator wants a promise
     that such a job should be executed.

     One can imagine optionally referencing a reservation Agreement in
     this Agreement, either through the JSDL extensibility or through
     some other WS-Agreement extensibility.

I would be interested in others' opinions on whether an extra bit of
wrapping XML is needed around the JSDL in the service description to
distinguish these kinds of agreement, versus some other guarantee term
that distinguishes "execute job J" from "be able to execute job J".

This is the whole subtle RSLA/TSLA/BSLA distinction from SNAP, and I
believe it is largely an aesthetic issue to perfer it rendered one way
or another... however, if we do not provide guidance on expected use,
I expect all the early adopters of WS-Agreement will do wildly
different things because there are too many combinatorial avenues for
composing terms and concepts here.


karl

-- 
Karl Czajkowski
karlcz at univa.com