[GRAAP-WG] minutes from Sep 27 telecon

[Karl Czajkowski]

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 at univa.com