- graap-wg - lists.ogf.org

Asynchronous operations
by Takuya Araki (Biglobe) 01 Dec '04

01 Dec '04

(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(a)dc.jp.nec.com> ----- Original Message ----- From: "Toshiyuki Nakata" <t-nakata(a)cw.jp.nec.com> To: "Karl Czajkowski" <karlcz(a)ISI.EDU> Cc: "Alain Andrieux" <alain(a)ISI.EDU>; <graap-wg(a)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(a)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(a)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) > > > >

1 0

comments from GGF editor
by Jim Pruyne 29 Nov '04

29 Nov '04

Here are the comments we received from the GGF editor (Greg Newby): Sorry for my delay in responding. This document is now in 15-day GFSG comment period. After that, and any suggested changes, public comment is the next phase. Here are some comments that you might want to incorporate in a further revision before public comment (you can do these immediately, or wait until after the GFSG comment period, in case there are other suggestions). In the header: Consider whether all the people listed should be Authors or Editors. With such a large group, maybe you really only have one or two Editors, and the rest belong in a separate Contributor's section. Remember that Authors (or Editors) are expected to fully endorse the complete documenta, and to remain responsible/responsive for the document for the future. The GGF full copyright & IP statement can be moved to the end, rather than the beginning (I think GFD-1 specifies this, but even if not, that seems to be current practice). References: I would *much* rather see references to actual *documents*, not just Web sites. Web sites are transient (the sites today are not the same as yesterday or tomorrow). Documents (published by the same people doing the site) are, we hope, more permanent. The purpose of References is so that someone who reads your document in, say, a few years, will be able to recreate the foundations on which your standards are built, by reviewing the documents you cite in your references. Please revisit these, and add specific documents/standards whenever possible. For the others, Web sites should not be in the References, they should simply be mentioned inline in the text. In the Appendices, you have some examples in blue, some with syntax highlighting, and some in black/grey. Any reason why these can't be consistent? Overall, this document is clearly written and seems to be well-designed. Thanks very much for your work on it. Good news is that it looks like we're now counting down to public comment period at long last. --- Jim

1 0

WS-Agreement - public comment soon?
by Jon MacLaren 25 Nov '04

25 Nov '04

All, Does anyone know the status of the WS-Agreement document? It seems to be taking an incredibly long time to reach the public comment period. I could hardly believe that it wasn't in the list that Stacey is sending round. Very frustrating! Jon.

2 1