Re: wire stack words and diagram

Ugo Corda wrote:
> Option 1.
> This can be a problem if the SOAP message has to go through different
> intermediaries and transports, some of which might not be able to handle the
> address information at the protocol level. In that case, it might just be
> better to use option 2 throughout.

Yes, I agree, option 1 is good only for some scenarios.

> Option 2.
> This is my original scenario, and the reason I brought it up is because it
> seems to imply an interaction between binding and headers which, in my view,
> is not well addressed in the current SOAP spec (and you might agree, since
> you are using the words "I think" in your response).

Well, is this not (binding-) implementation specific? (Although 
possibly this will not be hidden to intermediaries, i.e. the 
binding-secret headers would be exposed to intermediaries.)

> Option 3.
> Could this case still be classified as a request-response MEP, or would it
> become a collection of two one-way MEPs? (In your original note you said
> that MEPs are supported by bindings only).

It could be either. In the case of Request-Response, the 
application would simply not use, for example, the value of the 
reqres:ImmediateSender property, as indicated by the binding, to 
determine the return address, but the information contained in 
the ReturnAddress header block.

Jean-Jacques.

> Ugo
> 
> -----Original Message-----
> From: Jean-Jacques Moreau [mailto:[email protected]]
> Sent: Thursday, October 03, 2002 4:56 AM
> To: Ugo Corda
> Cc: [email protected]; Hugo Haas
> Subject: Re: wire stack words and diagram
> 
> 
> As all SOAP 1.2 bindings, the MOM-based binding would be expected 
> to make the sender's address available via the 
> reqres:ImmediateSender property. If that was not the return 
> address, the return address could be carried in a binding 
> specific manner, for example via a header field of the underlying 
> protocol. The EMail binding shows how you can do this for the 
> Correlation feature[1].
> 
> Rather than implementing the ReturnAddress feature via a binding, 
> one could implement it via a SOAP Module, as you are pointing 
> out. Bindings are not supposed to consumme or otherwise process 
> application modules (headers that are normally processed by 
> applications); but bindings are allowed, I think, to augment the 
> infoset to transport, and so a binding might very well decide to 
> insert its own header before sending the message, that header 
> being consummed by the receiving binding, and made available to 
> the application via a specific property, for example 
> myBinding:returnAddress.
> 
> A third option would be to implement the ReturnAddress feature as 
> a SOAP Module explicitely handled by the application. The binding 
> would not be involved at all.
> 
> Does this help?
> 
> [1] http://www.w3.org/TR/2002/NOTE-soap12-email-20020626#correlation
> 
> Ugo Corda wrote:
> 
>>>This has to be contrasted with other features (e.g. signature) 
>>>that may leave outside the binding, e.g. expressed as SOAP header 
>>>block(s).
>>
>>
>>What if I had a Request-Response MEP and a MOM-based binding. In that
> 
> case,
> 
>>I would probably need to put the return address information in some
> 
> header,
> 
>>so that the receiving service can know where to send the (asynchronous)
>>answer back to. Would you consider that header to be part of the binding?