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