Re: Proposal for Async Extensions

Marc Hadley wrote:

> 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.

I'm not sure either, but the idea is indeed that HTTP already does this,
and we're just trying to incorporate that behavior into a framework that
can handle a broader range of interactions.

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

I'm completely open to better names.  I almost called it "ack", but
balked for I don't remember what reason.

>
>> 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' ?

This would (most likely) just include other headers, notably [message
id] if correlation is not natively provided, and possibly headers
required by security etc.  See
http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jun/0005.html. 
There's at least a prima facie case that acks may still need to carry
non-trivial header information, and I would not want to rule that
possibility out.  Thus the ack is defined as a full-fledged SOAP
message, with an optimized representation if people like that sort of thing.

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

It appears by saying that an HTTP exchange (and an exchange on similar
bindings) is always a SOAP request-response MEP, a great deal of the
anguish over how to bind to SOAP MEPs simply goes away.  If the return
message were always just an empty marker, I would be indifferent.  But
if we get to use the SOAP processing model to handle problems like
reliability and security that will most likely come up anyway and we've
already solved using SOAP, I think the case becomes considerably stronger.

>
>
>> 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 ?

This is exactly the idea.  I may accept requests via HTTP, but be able
to send asynchronous responses via HTTP, some JMS binding, email and
whatever else.  The response binding elements provide a means to
advertise this, so the client knows in advance what will work.

> 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] ?

If you don't have an FTP [response binding] then you're saying you don't
support FTP replies (or at least you're not saying you do :-).

>
>> 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] ?

Yes.  Thanks.

>
>> 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 ?

A good question.  Probably the best place to work this out would be the
WSA WSDL binding.  The simplest approach in this context would be to
drop the reference to MEPs and say that [reply endpoint] and [fault
endpoint], when present, are always considered response endpoints.  That
would mean that you shouldn't (or mustn't) include a [reply endpoint] if
there aren't any supported response bindings.

I'm hesitating a bit because we know for sure what [reply endpoint]
means in request-response, and we know that the MEP just won't work
unless the [reply endpoint] is supported.  We don't necessarily know
this in the case of a [reply endpoint] on a one-way.  Maybe it's a fatal
problem, maybe not.

That said, I believe the terminology of response endpoints and supported
response bindings is still useful in such cases.  I just can't say from
here precisely how to apply it, because I don't know the larger picture.

>
>> 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.

That's why I caveatted this section.  On the other hand, it would be
good at least to apply some guidance here, along the lines of "if there
is a fault ..."

>
>> 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].

As above.

>
>> 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.

I intended this as a gloss on WSA, but that depends partly on where we
land with [message id].

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

Received on Wednesday, 15 June 2005 19:36:41 UTC