On Feb 19, Karl Czajkowski loaded a tape reading: ...
Would a corrected version of the symmetric agreement mechanism satisfy your needs here, or do you also still feel that a two-phase creation mechanism must be available for asymmetric initiators who will not host any WS-Agreement related endpoints?
karl
While waiting for a response, I dug back in my email archive and found this comment from Takuya on 1 Dec 2004: 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. but unfortunately my archive does not retain the Word document attachment, so I cannot review the specific changes. (Does anyone know of a public archive where I can easily retrieve such GRAAP messages with attachments?) Just based on the above summary, I would say that I am proposing we drop the createAgreementGetResult operation in favor of an equivalent binding-level behavior to reliably get (or "re-get" by polling) the result of the existing createAgreement call in case it takes too long for the baseline bindings. I am also proposing that we attempt to incorporate his notion of a "reverse direction" createAgreementResult operation (which I separated as acceptAgreement and rejectAgreement) into a repair for the now underspecified and broken symmetric agreement pattern. Does anybody else have opinions on these issues? Will there be a GRAAP call today (Monday 20 Feb)? karl -- Karl Czajkowski karlcz@univa.com