[graap-wg] asynchronous binding

[Karl Czajkowski]

On Feb 20, Karl Czajkowski loaded a tape reading:
...
> 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.
> 

Thanks to all who pointed out that the GGF site does indeed have an
archive for the GRAAP-WG mailing list. :-)

After reviewing the proposed changes, I think the above comments still
stand.  The only additional "async" interface proposal was for
termination, and I would also suggest dropping that because it is my
belief that there is no implication of long delays in this operation.

Termination is an inherently asynchronous mechanism by which the
client requests termination and finds out if his request is acceptable
or not; he does not get some response synchronized to happen "after"
termination but he should assume the resource is not to be accessed if
the response is successful.  This is a point that I think was argued
extensively (and convincingly, to me) in the OGSI and WSRF work
groups.

I actually would question why we have a wsag:Terminate instead of just
using the WS-ResourceLifetime mechanism.  I cannot see what value it
adds or what would be different about the semantics. The text in the
Agreement Context section is hardly convincing on this point. :-(
Is it supposed to I am afraid I must have been absent during the time
when this was decided... 


karl

-- 
Karl Czajkowski
karlcz at univa.com