Re: Proposal for Async Extensions

On Jun 15, 2005, at 3:36 PM, David Hull wrote:
>>
>>> 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.
>
But then we get into the problem of getting two responses in a simple  
request-response MEP and you have to answer questions like which is  
the 'real' response, how can you tell, are there any explicit timing  
concerns etc. It sounds simple on the surface but raises a lot of  
questions, at least in my mind.

Marc.


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

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