W3C home > Mailing lists > Public > public-ws-addressing-comments@w3.org > April 2005

SOAP Binding & Core: Interaction between Faults and [message id] and [reply endpoint] etc.

From: Prasad Yendluri <pyendluri@webmethods.com>
Date: Tue, 05 Apr 2005 17:11:13 -0700
Message-ID: <42532921.8010903@webmethods.com>
To: public-ws-addressing-comments@w3.org

Ref:  [1] WS-Addressing 1.0 Core 
(http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/)
        [2] WS-Addressing 1.0 SOAP Binding 
(http://www.w3.org/TR/2005/WD-ws-addr-soap-20050331)

The Core specification require [message id] property in a message only 
if expects a reply, as indicated by presence of [reply endpoint] or 
[fault endpoint] properties. Accordingly  [reply endpoint] is required 
only if a reply is expected. Same goes for [fault endpoint] which is 
also optional.

Also messages that are replies do not need to have a [message id] property.

Given the above, how the faults described in section 5 of the WS-A SOAP 
Binding specification [2] could be received by the sender of the message 
if these properties are not supplied? I understand that the spec says 
faults are "generated" (and not necessarily transmitted) but, for faults 
like "5.5  Endpoint Unavailable" that also supply a <wsa:RetryAfter>, 
the intent is to send it so that the receiver can retry the message. 
These are faults outside of what the service defines in its WSDL.

So, it seems we are saying that WS-A SOAP binding users SHOULD be 
prepared to receive such faults even when the underlying service (WSDL) 
does not define any but we make it difficult for that to happen by not 
requiring the needed properties.

IMO to enable this, the core spec should highly encourage the use of 
(SHOULD) [message id] and [fault endpoint] / [reply endpoint] 
properties?, so that the WS-A defined faults have a chance of reaching 
the sender of the message (including when it is a reply)? Ideally I 
would make them required properties always.

Prasad Yendluri
Received on Wednesday, 6 April 2005 00:13:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:19:38 GMT