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

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

From: Eamon O'Tuathail <eamon.otuathail@clipcode.com>
Date: Thu, 10 May 2001 19:37:49 +0100
To: "John J. Barton" <John_Barton@hpl.hp.com>, "Jean-Jacques Moreau" <moreau@crf.canon.fr>, "Lucas Gonze" <lucas@worldos.com>
Cc: <xml-dist-app@w3.org>
Message-ID: <NCBBIFBIECFPOABMKKBDGEOLDKAA.eamon.otuathail@clipcode.com>
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
Received on Thursday, 10 May 2001 14:37:40 GMT

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