Re: SOAP Binding Framework Concerns

At the risk of looking stupid, I want to retract my previous statement.

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

Ok, but why?  While it's true that HTTP can be accurately described with
a RR (request/response) MEP, it is not true that an application wanting
to do just RR should use HTTP.

Negotiating an application protocol at runtime could be done in some
fringe cases I suppose, but I see little value in bothering with it.
Take the example of an application wanting to add a message to a bulletin
board.  I only know two protocols that have those semantics; HTTP and NNTP
(the POST method for each).  But for anything more than the most trivial
application (like this example), HTTP and NNTP are not interchangeable.

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

AFAIK, "tunneling" only applies to application protocols.  Transport
protocols are designed to have other protocols built on top of them,
whereas application protocols aren't.

> Still, letting the application see all of these as common is very, very 
> useful.

I don't disagree that it's an interesting academic exercise to be able
to describe application protocol features with a set of MEPs.  What I
disagree with is that much can be done with this information, especially
at runtime.

>  If you really want a pattern or feature that truly exploits the 
> nuances of exactly one transport, that's fine too. 

For application protocols, that's what we'd be dealing with here; MEPs
that basically identify the protocol.  IMO, there's not a lot of value
to doing this.
 
MB
-- 
Mark Baker, CSO, Planetfred.
Ottawa, Ontario, CANADA.
mbaker@planetfred.com

Received on Sunday, 28 October 2001 22:06:15 UTC