[graap-wg] Asynchronous operations

Tue Nov 30 19:40:06 CST 2004

(I resend this mail since it seems that my last post was not delivered.
I am sorry if you receive the same mail twice.)
--
Dear All, 

After discussion with Nakata-san, I was convinced of the importance
of asynchronous operations. (It reminded me that I had to change timeout
parameter when I made an agreement-based system in the Fusion project.)
So I tried to define asynchronous version of createAgreement and Terminate, 
though I am neither dedicated nor a champion. 

I added asynchronous operations as Section 8.4 and its WSDL as Appendix 2.
These operations are optional, and there was no need to change the original
specification other than that.

I added asynchronous request operations (e.g. createAgreementAsync), 
polling operations for getting the result (e.g. createAgreementGetResult), 
and response operations (e.g. createAgreementResult).  
Please see the attached document for detail. It also includes some minor comments
to the original specification.

I am not sure if this is appropriate timing since we are waiting for public comment 
period, but it would be better to ask you for comments about the change anyway.

Regards,
--
Takuya Araki
Grid System Technology Group
NEC Internet Systems Research Laboratories
<t-araki at dc.jp.nec.com>

----- Original Message ----- 
From: "Toshiyuki Nakata" <t-nakata at cw.jp.nec.com>
To: "Karl Czajkowski" <karlcz at ISI.EDU>
Cc: "Alain Andrieux" <alain at ISI.EDU>; <graap-wg at gridforum.org>
Sent: Tuesday, October 19, 2004 12:07 PM
Subject: Re: [graap-wg] post-GGF12 changes to the spec

> Karl: Thank you very much for your comments.
> I had been hoping that (in order to not add more specs)
> current spec had rooms in it for asynchronous handling
> but if not, then
> 
> 
> 
> Karl Czajkowski wrote:
> 
>>I am not sure if you are too worried about implementation, or just
>>wanting something we decided is out of scope.  In theory, there is no
>>limit to how long a Web service invocation can take.  It is, as you
>>said an issue of a specific binding mechanism where there are limits
>>on asynchrony.  
>>
> 
> Something like
> 
> createAgreementAsync()
> and a 
> Notification event which would be 
> 
> 
> something like
> 
> asyncCreationResponse() operation
> you mention below 
> (from the provider to the initiator)
> 
> 
>>For example, I could imagine adding some sort of
>>asyncCreationResponse() operation to the Agreement that would bear the
>>current factory's output messages as input.  Then, the factory would
>>probably need a new createAgreementAsync() operation that does not
>>return an Agreement EPR or indicate acceptance of the offer, but
>>instead returns success if and only if the asyncCreationResponse
>>operation of the initiator will later be driven.
>>
>>I think such additions would need a dedicated champion to write them
>>up as concrete (and minimal) changes to the specification so that the
>>group could review them.
>>
> 
> If it is needed,
> Uh I am neither dedicated nor a champion, but I'll try get my colleagues 
> to come
> up with their way and try to translate it into English.
> 
> Best regards
> Toshi
> 
> 
>>
>>
>>
>>karl
>>
>>
>>On Oct 19, Toshiyuki Nakata loaded a tape reading:
>>  
>>
>>>hello: I am still not sure whether the suggestion I had mentioned in my 
>>>previous
>>>post had been accepted or not, but anyway;:
>>>-----
>>>
>>>While we were discussing this, some one pointed out that
>>>we would need an asynchronous version of CreateAgreement + Notification
>>>at completion as some of the sub searches might  span many data-centers
>>>and there will certainly be problems with timeouts as well as efficiency
>>>problems.
>>>
>>>My question is, does WS-Agreement spec really specify only synchronous
>>>version of the CreateAgreement? ( I am hoping not..)
>>>
>>>I think you were trying to specify an abstract notion of an Agreement
>>>and not trying to specify too much implementation specific issues. On
>>>the other hand  the WSDL example looks like specifying a synchronous one.)
>>>
>>>BTW that the wsdl spec also says in "2.4.2 Request-response Operation" that
>>>Begin Quote
>>>"Note that a request-response operation is an abstract notion; a
>>>particular binding must be consulted to determine how the messages are
>>>actually sent:
>>>within a single communication (such as a HTTP request/response), or as
>>>two independent communications (such as two HTTP requests).
>>>End Quote,
>>>
>>>So am I getting too much worrie about implementation specific issues?
>>>
>>>
>>>
>>>Alain Andrieux wrote:
>>>
>>>    
>>>
>>>>Everyone please review these proposed concrete changes to the spec 
>>>>(of course my earlier general comments do still apply, for instance 
>>>>we should look for things we can remove).
>>>>
>>>>If anything you mentioned in an earlier email is missing 
>>>>please reply with questions and sugestions.
>>>>
>>>>See my comments email as well as the GG12 minutes for 
>>>>reasons behind these proposed changes.
>>>>
>>>>
>>>>- remove related agreements 
>>>>
>>>>- make value expression of Penalty an xsd:any
>>>>
>>>>- make assessment interval an xsd:any
>>>>
>>>>- move glossary to beginning of document
>>>>
>>>>- change abstract and reuse OGSA definition of an agreement in it
>>>>
>>>>- "agreement offer" not defined
>>>>  - define precisely in the glossary AND 
>>>>    in the body of the spec (like we explain template and agreement)
>>>>  - clarify the distinction b/w agreement and offer.
>>>>
>>>>- constraints in templates:
>>>> - clarify meaning of constraints in particular meaning 
>>>>   of no constraint at all 
>>>> - can we find solution to avoid having to declare every 
>>>>   constraint while preserving schema-validity of the template?
>>>>
>>>>- wsag:ExpirationTime:
>>>>   - remove from wsag:Context
>>>>   - make it an service description term instead 
>>>>   - make its content generic  i.e. an xsd:any
>>>>
>>>>- review all the time-related concepts in the spec.
>>>>
>>>>- "Service Properties":
>>>>   - rename to "Guarantee Variables"
>>>>   - simplify schema structure
>>>>
>>>>- state machine p. 31: clarify how the overall state is computed
>>>>(this is not trivial).
>>>>
>>>>- discuss ease of use of "service runtime state" as opposed 
>>>>to domain-specific RPs...
>>>>
>>>>- logical compositors: should we add wsag:ZeroOrMore?
>>>>
>>>>Another thing to do that is not a spec change:
>>>>- start section of Web site dedicated to links to external projects 
>>>>such as implementations of the spec, projects using it, concrete 
>>>>project use cases etc.
>>>>
>>>>--
>>>>Alain Andrieux 
>>>>Globus Alliance
>>>>
>>>>
>>>>
>>>>
>>>>      
>>>>
>>>-- 
>>>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)
>>>
>>>
>>>    
>>>
>>
>>  
>>
> 
> -- 
> 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)
> 
> 
> 
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WS-AgreementSpecificationModified.doc
Type: application/msword
Size: 776192 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/graap-wg/attachments/20041201/4373ee9a/attachment.doc 