W3C home > Mailing lists > Public > www-ws-arch@w3.org > October 2002

Re: wire stack words and diagram

From: Jean-Jacques Moreau <moreau@crf.canon.fr>
Date: Thu, 03 Oct 2002 13:55:48 +0200
Message-ID: <3D9C3044.4020800@crf.canon.fr>
To: Ugo Corda <UCorda@SeeBeyond.com>
CC: www-ws-arch@w3.org, Hugo Haas <hugo@w3.org>

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 

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 
> 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?
Received on Thursday, 3 October 2002 07:55:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:41 UTC