[GRAAP-WG] minutes from Sep 27 telecon

[Karl Czajkowski]

On Sep 27, Mark.McKeown at 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 at univa.com