On Sep 27, Mark.McKeown@manchester.ac.uk modulated:
Perhaps the issue is more fundamental than you realise. WS-Agreement is dependent on WS-RF, which is in turn dependent on WS-Addressing. This means that messages in the WS-Agreement protocol will include WS-Addressing elements in the SOAP Headers. Mis-matchs between client/service versions of WS-Addressing might bite before processing of the SOAP Body even begins.
The difference is that an implementation of the transport can strip that off and support multiple versions without the application-level logic caring about the version. I agree that this has to be addressed (no pun intended) before deploying WS-Agreement on another standards stack makes sense. However, having explicit WS-Addressing references in the service WSDL, e.g. inside the application message content, means that even if the transport/container environment supports the new version, a valid WS-Agreement message would not allow the newer EPR. I agree on the SOAP header points, but in our implementation in Globus, that is a different layer of code than the application code. Our observation is that the "factory pattern" where EPRs are returned in application payload ties the application to a specific version, even if our container were to support multiple versions. The "be liberal in what you accept" means we would have to put an xsd:any in the position where we currently have an element with a versioned wsa:EndpointReference_Type, in the application's message schema. I am afraid I do not see where you have addressed the question of how the WS-Addressing features solve these practical problems: How can WS-Addressing solve the issue of arbitrary delay between the in and out message without "losing the connection", in any contemporary tooling environment? The EPR of an acceptance resource is passed specifically to simulate a very delayed "out" message using a new "in" message. This seems to me to require a more suitable transport than SOAP over HTTP, rather than an addressing solution. How can WS-Addressing allow one to convey a new EPR to an application without exposing the EPR in the application payload? The optional passing of an Agreement resource EPR is to establish a symmetric peer-to-peer environment where each side can initiate new message exchanges with the other. -- Karl Czajkowski karlcz@univa.com