[GRAAP-WG] minutes from Sep 27 telecon

[Mark.McKeown at manchester.ac.uk]

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