[graap-wg] asynchronous binding

[Takuya Araki (Biglobe)]

Karl:

Thank you for your comments and new proposal. 
(And sorry about the late response.)

Basically, I agree with your new proposal.
* Your requestAgreement, accepctAgreement, rejectAgreement operations
  are mostly same as my proposal. Its OK for me to change operation names.
  - Letting acceptAgreement create a new service ( "5)" in your proposal)
    seems to be a new topic. If you want to include this, it might be better 
    to discuss it as a different topic in the WG. 
  - It is OK to drop async version of the Terminate operation as you mentioned
    in another mail. 
    I thought that it might be used as "destructor" of the agreement; there 
    might be something like clean-up which takes some time. If there are dependent
    agreements and they should be also terminated at the time, the whole time 
    might be long. 
    However, your discussion in another mail (terminate operation is inherently
    asynchronous operation, etc.) seems to be also convincing.
    (Terminate operation can return immediately if the provider accepts the termination; 
    clean-ups and calling terminate operations of dependent agreement can be executed 
    asynchronously...)
    Therefore, I agree with dropping async version of Terminate operation. 

* It's a bit pity to drop WSDL level polling operation :-) (considering scalability, etc.), 
  but if we have request/accept/rejectAgreement operations, they can be
  used if scalability is important. 

Some other comments are in line:
> ...
> No, I was merely trying to state that we would have to 
> consider what we are doing if we introduced some two-level 
> factory scheme, e.g.  an initial "lightweight" factory create 
> call that returns the EPR of a new "pending request" resource 
> which the client can poll to find the eventual "accepted 
> agreement" EPR.  I don't think this would be that much more 
> powerful than the binding-level solution I have promoted, and 
> it opens the can of worms as to what is the lifecycle of a 
> "pending request".
> 
> Another way of rendering this two-level scheme would be to 
> just return the Agreement EPR in a new enhanced lifecycle 
> where it has not been accepted yet. An asynchronous 
> state-change can indicate whether it is accepted or rejected 
> once the provider knows. This is pretty much what our 
> original state machine model looked like before we factored 
> out negotiation. :-)  It also happens to be what GRAM does today. :-(

Actually, "the EPR of a new pending request resource" is 
not created in my proposal. The polling method is defined at the factory; 
to identify the request, I used correlation ID.
In this case, it seems to have less lifecycle problem than two-level 
factory scheme.

> 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?

If there are request/accept/rejectAgreement operations, 
most of my needs can be satisfied, I think. 
If you still feel uncomfortable about the polling operation
I proposed(, though it is not two-level factory scheme), 
I agree with dropping the polling operation and using 
the binding level solution instead for the asymmetric case.
--
Takuya Araki
Grid System Technology Group
Internet Systems Research Laboratories 
NEC Corporation
<t-araki at dc.jp.nec.com>