Re: Proposal for Async Extensions

A few questions and comments:

> 1.1      Anonymous Response feature
> SOAP bindings MAY support the anonymous response feature.  Such a  
> binding MUST provide a means of sending a reply directly to the  
> sender of a given message, independent of the contents of the SOAP  
> message itself.

The existing SOAP 1.2 HTTP binding already supports this feature but  
doesn't call that out. I'm not sure how you retrospectively indicate  
support for a new feature in an existing binding but I suspect we'd  
need XMLP to issue an errata at a minimum.

> 1.2      Marker message

This is basically a SOAP ACK right ? Marker isn't a very intuitive  
name IMO.

> Bindings MAY provide optimized means of transferring particular  
> forms of messages with this [action].

E.g. by not sending a SOAP message at all unless it:
> This message MAY also have any other content, as appropriate.

How would such 'other content' occur given that there's no  
'application level response or fault' ?

I must confess I really don't like these 'magic' SOAP messages that  
don't really exist. What's the point of this conceit.

> WSDL binding elements MAY include zero or more [response binding]  
> child elements.  The value of such an element MUST be an IRI  
> denoting a SOAP underlying transport binding.

Wouldn't the SOAP underlying transport binding already be specified  
elsewhere in the WSDL binding (assuming its SOAP of course). Or is  
the idea that you can specify a response binding for a different  
transport to the request ? Maybe I'm getting confused with the  
anonymous response feature ?

> WSDL binding elements MAY include zero or one [using addressing]  
> child elements.  If this element is present, the operation MUST  
> follow the rules specified in the WS-Addressing Core, SOAP Binding  
> and WSDL Binding specifications.

Subject to the constraints specified by the [response binding]  
elements though - right ? E.g. if I have a HTTP and SMTP [response  
binding] then do I still need to support a FTP [reply endpoint] ?

> 3.1      Supported Response Bindings
> For any given operation, the set of supported response bindings  
> contains all, and exactly all, of the following IRIs:
> The IRI http://www.w3.org/@@@@/@@/addressing/anonymous, if the  
> transport binding for the operation supports the anonymous response  
> feature.
> The values of all [response endpoint] children of the binding element
Should the final bullet be [response binding] rather than [response  
endpoint] ?

> All response endpoints for a message MUST be compatible with  
> exactly one of the supported response binding IRIs for the  
> operation.  Note that this is automatically true for an in-only  
> operation.

An in-only operation might specify no [response binding]s - does that  
mean that I can never send a [reply endpoint] to such an operation ?  
How does this compose with the use of ws-addr for longer running  
interactions ?

> the endpoint MUST attempt to send an appropriate fault on the  
> anonymous response channel

The SOAP 1.2 spec is careful to avoid ever requiring a fault to be  
sent, it just requires them to be generated, I think we should do the  
same.

> If the error occurs while the responding endpoint is in the  
> receiving state (i.e., it has not yet begun to send a response, and  
> no failure has occurred), the endpoint MAY attempt to send a fault  
> on either the anonymous response channel, or to the [fault  
> endpoint], but MUST attempt to send a fault.

Is it possible to tie this down further by refering to the SOAP  
processing model - there has been discussion elsewhere about mU  
faults never going to the [fault endpoint].

> In addition to any requirements placed by the WS-Addressing  
> specifications, an in message SHOULD contain a [message id]  
> property if the [address] of at least one response endpoint is not  
> http://www.w3.org/@@@@/@@/addressing/anonymous.

I'm not clear where this requirement is supposed to live, if its part  
of WS-Addr (which would make sense given its reliance on a WS-Addr  
property) then the first clause seems out of place.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.