On Sep 27, Mark McKeown modulated:
Hi Karl, I am not sure I understand your issue but I have recently read the WS-Agreement spec and have some questions regarding the use of WS-Addressing with WS-Agreement.
The basic issue is that the factory output message includes the EPR of the newly created Agreement resource. Currently, I believe the WSDL has used a specific wsa:EndpointReference_Type for this. Making it xsd:any would prevent us from having to reissue the WSDL, e.g. with a new namespace, each time someone wants to support a different endpoint reference type. The question is whether we want WS-Agreement to be generic in the face of multiple WS-Addressing versions, for whatever EPRs we must encode in the WS-Agreement message bodies. This is an issue today, with people trying to implement the specification in different tooling environments which use different drafts etc. I am not sure whether this issue will ever disappear, e.g. is there a "final" WS-Addressing specification which will never be revised and require more updates of WS-Agreement implementations in practice... ...
To me this means that the wsag:initiatorAgreementEPR and wsag:agreementAcceptanceEPR elements in Section 9.1.1.1 and 9.2.1.1 are not required: WS-Addressing provides the required functionality. Also there is no requirement for the Accept/Reject operation on the AgreementAcceptance resource; WS-Addressing wsa:MessageId and wsa:RelatesTo can be used to map agreement requests to responses.
The initiatorAgreement is not just for a "reply". It is making the service aware of an (optional) peer resource representing the same agreement, but from the "offering party's point of view". It would potentially be the target for multiple operations, resource propery queries, notification subscriptions etc. Many aspects of the WS-Agreement WSDL is geared to being implementable with "yesterday's and today's" WS tooling, where abstract in/out patterns are naively mapped to synchronous "RPC over SOAP over HTTP" implementations. The reason behind the PendingAgreement and AgreementAcceptance mechanism is to support a long delay in the agreement decision process, while not making WS-Agreement too difficult to use with older or simplistic tooling. For example, we can have unbounded delays in a resource manager, and we cannot depend on the SOAP tooling being capable of correlating the in/out message pair of the synchronous agreement creation across such a delay. With the naive SOAP over HTTP bindings, we would have a very fragile system if the "out" messages would be dropped frequently due to HTTP and TCP timeouts. Also, the forced ordering of in/out message pairs over HTTP would be a problem for making multiple agreement offers and needing to hear the responses in a different natural order than the offers were sent. Similarly, the Accept/Reject is known to be redundant in the face of notification. It provides an optional callback for environments where general subscription to monitor the agreement state is not possible. karl -- Karl Czajkowski karlcz@univa.com