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
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...
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. Since WS-Addressing[1] is now a W3C Recommendation I assume that is the only version of the standard that should be referenced in another specification. Quoting the WS-Addressing standard: "It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web." Clearly changes to WS-Addressing from now on will have enormous impact as soo many specifications are now reliant on it. However as you point out there are practical issues. Perhaps implementations could apply Postel's Law[2]: "Be conservative in what you do; be liberal in which you accept from others." In which case an implementation could accept any version of WS-Addressing, or some subset of the versions. A service recieving a message could check the SOAP Headers to see which version of wsa is being used by the client, and then it can use the same version in the response. However, I am not really sure how practical this is as many people feel Postel's law does not apply to XML[3]. (As I pointed out below WS-Addressing could be used in a way to avoid needing to include EPRs in the SOAP Body.)
...
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.
I can appreciate the problems with WS-*/SOAP that you outlined, and have tried to avoid in the WS-Agreement specification. However, the GRAAP group must inherently have faith in the future of WS-*/SOAP, or else it would not have choosen to use them in the first place. I am reading WS-Agreement from a historical perspective as I haven't followed the work closely. From this perspective it seems strange that WS-Agreement has a dependence on WS-Addressing, yet doesn't fully utilise it. cheers Mark [1] http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/ [2] http://en.wikipedia.org/wiki/Robustness_Principle [3] http://www.tbray.org/ongoing/When/200x/2004/01/11/PostelPilgrim
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
participants (2)
-
Karl Czajkowski -
Mark.McKeown＠manchester.ac.uk