Re: BEEP vs. HTTP as transport for XMLP/SOAP (was xml transfer over TCP)

Thanks for the information. Have a look through our charter and
mailing list archives, you'll see that BEEP has been discussed at
some length to date.

The WG already has some ties into the BEEP community, and I imagine
there will be more interaction in the not-too-distant future. 

I'd also point out that with XMLP/SOAP, there is no 'vs.'; it's
designed to run over a choice of transports. HTTP is only the first
transport binding being defined.



On Thu, May 10, 2001 at 07:37:49PM +0100, Eamon O'Tuathail wrote:
> John,
> 
> HTTP is an excellent protocol for what it was designed for, but I think it
> is fair assessment to state that today it is being stretched in very many
> ways, sometimes trying to solve problems for which it was not originally
> designed.
> 
> BEEP is *much* more sophisticated compared to HTTP. BEEP is a better suited
> transport for XMLP/SOAP. As the limitations of XMLP/SOAP over HTTP become
> better known [one sample: asynchronous client notifications over HTTP is
> barely adaquate, at best; whereas with BEEP it is one of many natural forms
> of message exchange], BEEP will start to become very interesting for many
> people.
> 
> BEEP is a few weeks old, compared to many years for HTTP. The BEEP design
> has benefitted from the deployment experience of HTTP. Like any 'old' versus
> 'new' comparison, both solutions have advantages.
> 
> The advantages of HTTP are:
> * It is already deployed (people should not underestimate the importance of
> this)
> * Developers, administrators and security people understand it
> * It can sail through existing firewalls / proxy servers, etc.
> 
> The advantages of BEEP are:
> * It carries multiple channels (on the same TCP connection), each supporting
> a rich selection of message exchange styles (not just HTTP's client request
> and server response)
> * BEEP channels are independent of each other (think multithreaded peers can
> communicate using BEEP - this is not possible/very difficult with HTTP,
> without having undersirable serialization)
> * Messages can be originated by either peer (think peer-to-peer, event
> notification, data streaming)
> * "Profiles" describe the rules concerning what is permissible on each
> channel - profiles are defined separately, so extensibility is built in
> * BEEP is an IETF spec, and there is a whole series of other IETF specs
> coming soon that are based on BEEP
> 
> As firewall administrators become aware of BEEP, understand it is an IETF
> spec, realize its use for all these other protocols, they will be prepared
> to deploy BEEP proxy servers at the firewall based on the IETF TUNNEL.
> 
> Over the next few days I will be finishing off a draft of a detailed
> developer's guide for BEEP - if anyone is interested in having a read *and*
> promise faithfully to give me feedback on it, drop me an email, and I will
> gladly send them a copy.
> 
> Next week, Clipcode.com will be releasing a commercial BEEP implementation
> based on Microsoft .NET.
> 
> Clipcode.org will be releasing proposals for standards for a HTTP/BEEP
> gateway, a BEEP programming Object Model, and how SOAP may be correctly
> transported over a BEEP profile.
> 
> See below for useful BEEP links.
> 
> Even though very few people would agree with me now, I bet you within 12
> months BEEP is going to be the primary transport for XMLP/SOAP, not HTTP.
> 
> Eamon O'Tuathail
> Clipcode.com
> 
> ===========================================
> 
> Internet Sites
> The BEEP Core is RFC 3080 and is available from:
> .	http://www.ietf.org/rfc/rfc3080.txt
> The BEEP TCP Mapping is RFC 3081 and is available from:
> .	http://www.ietf.org/rfc/rfc3081.txt
> The IETF BEEP working group is at:
> .	http://www.ietf.org/html.charters/beep-charter.html
> An interesting paper discussing the rationale for BEEP is "On the Design of
> Application Protocols", which can be found at:
> .	http://www.ietf.org/internet-drafts/draft-mrose-beep-design-03.txt
> A portal dedicated to BEEP is at:
> .	http://www.beepcore.org
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 10 May 2001 15:06:01 UTC