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@dc.jp.nec.com>