[graap-wg] Telecon on 3/21

[Toshiyuki Nakata]

Karl Czajkowski wrote:

>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.
>

Yes, we do have something like that in mind ( of using JSDL document 
within WS-Agreement ..)

>
>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".
>

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


>
>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
>
>  
>

-- 
We have moved to a new Office!!
Toshiyuki Nakata ?????
Internet System Laboratories NEC 
t-nakata at cw.jp.nec.com
1753, Shimonumabe, Nakahara-Ku, 
Kawasaki,Kanagawa 211-8666,Japan 
Tel +81-44-431-7653 (NEC Internal 22-60210)
Fax +81-44-431-7681 (NEC Internal 22-60219)