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