W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2001

Re: SOAP Binding Framework Concerns

From: <Noah_Mendelsohn@lotus.com>
Date: Thu, 25 Oct 2001 22:45:15 -0400
To: Mark Baker <distobj@acm.org>
Cc: kumeda@atc.yamatake.co.jp (Kumeda), marc.hadley@sun.com (Marc Hadley), ms@mitre.org (Marwan Sabbouh), skw@hplb.hpl.hp.com (Williams Stuart), xml-dist-app@w3.org
Message-ID: <OFF300E4AF.9CFEA58A-ON85256AF1.000FA0C7@lotus.com>
Mark Baker writes:

>> This is only appropriate in the tunnel view of 
>> the underlying protocol.

I don't think so.  I think you are missing a common case in which features 
are defined that map naturally to multiple protocols.  Take simple 
request/response.  I can do a reasonable mapping of certain forms of 
request/response to http without "tunnelling" in any very bizarre way. 
Http will understand to a fair degree that it is a req/resp.  I can map 
the same request response to smtp, possibly even using the "reply to" 
header for routing the reply.  In that case, SMTP also understands, and 
you're not really tunnelling.  I bet I could find several other transports 
that would provide a similar service without tunnelling (I.e., in which 
the transport knew I was doing req/resp, and was supporting it in a way 
natural to the transport.)

Sometimes the same pattern or feature is tunnelled on one protocol, but 
not another.  One could argue that request/response over TCP would in some 
sense necessarily be tunnelled, as TCP doesn't really have that flavor. 
Still, letting the application see all of these as common is very, very 
useful.  If you really want a pattern or feature that truly exploits the 
nuances of exactly one transport, that's fine too. 

------------------------------------------------------------------------
Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------
Received on Thursday, 25 October 2001 23:02:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:04 GMT