I reviewed all of the comments on the GGF tracker, and I do not see any real surprises relative to the "big issues" that have been in discussion. Here, I want to group together a set of possible resolutions that go together if we accept my earlier proposal to handle "asynchronous agreement" via a new stateful Agreement life-cycle. A. Agreements get a new life-cycle state "Pending" which means that an offer has been made but no obligations are in effect yet. The term-level status is undefined at this point. B. Agreements get a new life-cycle state "Rejected" which means that the offer was rejected and no obligations will ever be in effect. C. Agreements get a new life-cycle state "Observed" which means that an offer has been accepted and all obligations are in effect. The term-level status is meaningful at this point. This state captures the semantics of the entire lifespan of the Dec 2004 draft (module the confusion around termination). 1. The life-cycle model includes transitions Pending->Observed and Pending->Rejected but NOT Observed->Rejected. 2. Additional states may be warranted to try to resolve the many questions surrounding "termination" and "expiration." D. The existing createAgreement operation remains as an interaction where an input offer initiates a synchronous acceptance decision; the response is either a fault for rejection or an EPR to an Agreement that MUST already be in the Observed state. 1. The optional initiatorAgreement EPR is retained but the responder is under no obligation to invoke anything on this service. It is an optional avenue for the responder to monitor the "initiator's view" of their agreement. (And to attempt to initiate other control processes?) E. An optional AgreementAcceptance portType is introduced with two operations: acceptAgreement and rejectAgreement. 1. Both operations accept an empty input, as the association with an agreement is implicit via the WSRF addressing model. 2. An optional fault might be useful on rejectAgreement input to communicate why the offer was rejected? 3. These operations are only meaningful when the AgreementAcceptance service is in a Pending state. The operations synchronously change the service state to Observed or Rejected, respectively. 4. The AgreementAcceptance and Agreement portTypes may be merged to form a single service interface, and the state is shared between them. (What is the right way to do this in WSDL? Provide portType combinations in specification?) F. A new createPendingAgreement operation is introduced where an input offer initiates an asynchronous acceptance decision; the response is either a fault (fatal errors/rejection) or an EPR to an Agreement that MAY be in Pending, Observed, or Rejected state. 1. The responder MUST update its state RP to either Observed or Rejected following its decision. 2. The initiator MAY use alternate mechanisms to determine if and when the Agreement transfers to Observed, including but not limited to the querying of a state RP. Until the initiator determines the state as changed to Observed or Rejected, it SHOULD NOT assume the outcome. 3. An optional initiatorAcceptance EPR MAY appear in the input message, in which case the responder MUST invoke acceptAgreement or rejectAgreement to communicate its decision, in addition to updating its state RP. 4. An optional initiatorAgreement EPR MAY appear as in createAgreement. This EPR MAY be the same as the initiatorAcceptance EPR, if the service implements both interfaces. 5. Should the output allow an optional state indicator? I think it is simpler to say "no" and uniformly assume an interaction after creation. G. Topic "Changing Offers" is resolved as the input offer is accepted or rejected WITHOUT MODIFICATION by the agreement acceptance decision. Because of this, no response Agreement document is required in any of the above mechanisms. 1. Should there be an optional mechanism to retrieve the agreement document from the responder in such a way that it MAY be signed or otherwise held as proof of acceptance for auditing purposes? If so, does a queryable "agreement RP" satisfy this need? karl -- Karl Czajkowski karlcz@univa.com
Hi karl thank you very much for your suggestion. Just to clarify.. May I understand that AgreementAcceptance portType is on the Agreement Initiator side and not on the Agreement Provider side? Best Regards Toshi
E. An optional AgreementAcceptance portType is introduced with two operations: acceptAgreement and rejectAgreement.
1. Both operations accept an empty input, as the association with an agreement is implicit via the WSRF addressing model.
2. An optional fault might be useful on rejectAgreement input to communicate why the offer was rejected?
3. These operations are only meaningful when the AgreementAcceptance service is in a Pending state. The operations synchronously change the service state to Observed or Rejected, respectively.
4. The AgreementAcceptance and Agreement portTypes may be merged to form a single service interface, and the state is shared between them. (What is the right way to do this in WSDL? Provide portType combinations in specification?)
-- 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)
On Mar 22, Toshiyuki Nakata loaded a tape reading:
Hi karl thank you very much for your suggestion. Just to clarify..
May I understand that
AgreementAcceptance portType is on the Agreement Initiator side and not on the Agreement Provider side?
Best Regards Toshi
Yes. It is the return signal path for a symmetric (peer-to-peer) variant of the asynchronous exchange. Do you think we need an explicit responder-side polling interface too? I had hoped RP query would be enough for the ugly client-server pattern, since we can return the (Pending) Agreement EPR immediately. karl -- Karl Czajkowski karlcz@univa.com
Karl Czajkowski wrote:
On Mar 22, Toshiyuki Nakata loaded a tape reading:
Hi karl thank you very much for your suggestion. Just to clarify..
May I understand that
AgreementAcceptance portType is on the Agreement Initiator side and not on the Agreement Provider side?
Best Regards Toshi
Yes. It is the return signal path for a symmetric (peer-to-peer) variant of the asynchronous exchange.
If I understand correctly, except for the names and the arguments it is quite similar to what Takuya was proposing... (Please refer to the PPT to see if i am mistaken or not) |
Do you think we need an explicit responder-side polling interface too? I had hoped RP query would be enough for the ugly client-server pattern, since we can return the (Pending) Agreement EPR immediately.
If we are to rely on WS-RP, I think we can rely on the RP query. I think this matter is still under discussion (No. 15 in my Comment list) https://forge.gridforum.org/forum/message.php?msg_id=1004 Best regards Toshi
karl
-- 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)
On Mar 22, Toshiyuki Nakata loaded a tape reading:
Yes. It is the return signal path for a symmetric (peer-to-peer) variant of the asynchronous exchange.
If I understand correctly, except for the names and the arguments it is quite similar to what Takuya was proposing... (Please refer to the PPT to see if i am mistaken or not)
Yes, I hope it is similar. I am just trying to do it in the same WSRF style as the existing features and rescue the existing draft's broken "symmetric agreement" mechanisms at the same time!
If we are to rely on WS-RP, I think we can rely on the RP query. I think this matter is still under discussion (No. 15 in my Comment list)
Ah, OK. I did not realize this was under discussion. karl -- Karl Czajkowski karlcz@univa.com
p.s. I do not think I am really proposing something new here, but trying to summarize the impact of the earlier discussions and hopefully get GRAAP-WG to a more explicit decision or discussion, instead of the implicit consensus we seem to be stuck on. :-) -- Karl Czajkowski karlcz@univa.com
Sorry to ask many snippets of questions rather than chunk them to gether. If an initiator issed five different createPendingAgreement operations, May I understand that it is the initiator's responsibility to create 5 different initiatorAcceptance EPR so that the response might be discriminated properly?
F. A new createPendingAgreement operation is introduced where an input offer initiates an asynchronous acceptance decision; the response is either a fault (fatal errors/rejection) or an EPR to an Agreement that MAY be in Pending, Observed, or Rejected state.
1. The responder MUST update its state RP to either Observed or Rejected following its decision.
2. The initiator MAY use alternate mechanisms to determine if and when the Agreement transfers to Observed, including but not limited to the querying of a state RP. Until the initiator determines the state as changed to Observed or Rejected, it SHOULD NOT assume the outcome.
3. An optional initiatorAcceptance EPR MAY appear in the input message, in which case the responder MUST invoke acceptAgreement or rejectAgreement to communicate its decision, in addition to updating its state RP.
4. An optional initiatorAgreement EPR MAY appear as in createAgreement. This EPR MAY be the same as the initiatorAcceptance EPR, if the service implements both interfaces.
5. Should the output allow an optional state indicator? I think it is simpler to say "no" and uniformly assume an interaction after creation.
-- 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)
The other option might be to pass the EPR of the Agreement as a parameter... Best regards Toshi Toshiyuki Nakata wrote:
Sorry to ask many snippets of questions rather than chunk them to gether.
If an initiator issed five different createPendingAgreement operations, May I understand that it is the initiator's responsibility to create 5 different initiatorAcceptance EPR so that the response might be discriminated properly?
F. A new createPendingAgreement operation is introduced where an input offer initiates an asynchronous acceptance decision; the response is either a fault (fatal errors/rejection) or an EPR to an Agreement that MAY be in Pending, Observed, or Rejected state.
1. The responder MUST update its state RP to either Observed or Rejected following its decision.
2. The initiator MAY use alternate mechanisms to determine if and when the Agreement transfers to Observed, including but not limited to the querying of a state RP. Until the initiator determines the state as changed to Observed or Rejected, it SHOULD NOT assume the outcome.
3. An optional initiatorAcceptance EPR MAY appear in the input message, in which case the responder MUST invoke acceptAgreement or rejectAgreement to communicate its decision, in addition to updating its state RP.
4. An optional initiatorAgreement EPR MAY appear as in createAgreement. This EPR MAY be the same as the initiatorAcceptance EPR, if the service implements both interfaces.
5. Should the output allow an optional state indicator? I think it is simpler to say "no" and uniformly assume an interaction after creation.
-- 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)
On Mar 22, Toshiyuki Nakata loaded a tape reading:
Sorry to ask many snippets of questions rather than chunk them to gether.
If an initiator issed five different createPendingAgreement operations, May I understand that it is the initiator's responsibility to create 5 different initiatorAcceptance EPR so that the response might be discriminated properly?
Yes, that is the idea... just like with the deliverNotification pattern in WS-BaseNotification. There is nothing particularly expensive about creating EPRs, e.g. new addressable resources. The alternative goes right back into the explicit correlation ID mess, which has all the same requirements for initiators keeping track of IDs and you still have to pass an EPR too. It hurts my brain to think about <EPR, ID> pairs for addressing. :-) Oh, I see your other email about using the Agreement EPR as a correlation ID. I think that is about the only way to upset the WSRF and anti-WSRF folks equally... ;-) I think EPRs should only be passed around when there is an expectation that a recipient will eventually invoke operations on it. karl -- Karl Czajkowski karlcz@univa.com
OK. I don't want to have both sides shooting/shouting at me :-) Best Regards Toshi Karl Czajkowski wrote:
On Mar 22, Toshiyuki Nakata loaded a tape reading:
Sorry to ask many snippets of questions rather than chunk them to gether.
If an initiator issed five different createPendingAgreement operations, May I understand that it is the initiator's responsibility to create 5 different initiatorAcceptance EPR so that the response might be discriminated properly?
Yes, that is the idea... just like with the deliverNotification pattern in WS-BaseNotification.
There is nothing particularly expensive about creating EPRs, e.g. new addressable resources. The alternative goes right back into the explicit correlation ID mess, which has all the same requirements for initiators keeping track of IDs and you still have to pass an EPR too. It hurts my brain to think about <EPR, ID> pairs for addressing. :-)
Oh, I see your other email about using the Agreement EPR as a correlation ID. I think that is about the only way to upset the WSRF and anti-WSRF folks equally... ;-) I think EPRs should only be passed around when there is an expectation that a recipient will eventually invoke operations on it.
karl
-- 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)
participants (2)
-
Karl Czajkowski -
Toshiyuki Nakata