Article:		Beep BEEP!
Subject:		BEEP and HTTP
Date:		2002-10-17 16:49:49
From:		Mark Baker
It's funny to hear BEEP promoted over HTTP, for several reasons. First, is because they're different types of protocols; BEEP is a presentation layer protocol, where HTTP is application layer. So any comparison (almost, see below 8-) is apples-to-oranges. Second, both attempt to solve a similar problem; how can we build commonality between the multitude of application protocols out there, and those yet to come? BEEP's answer is to build a common lower layer on which application protocols can be built, while HTTP's answer is to be an application protocol whose semantics are so general as to be able to engulf many other protocols (as FTP and Gopher have been engulfed). The advantage of BEEP's approach is that a large number of application protocols can be built this way, say 90%. And while HTTP is perhaps only suitable for, say, 70% of them, it's principle (huge!) advantage is that it defines interoperability *between* applications. For example, Yahoo can link to both stock quotes and sports scores, while a BEEP based "stock quote" application has no meaningful way to interoperate with a BEEP based "sport scores" app. This means that there are minimal, if any, network effects generated by BEEP's common layer, whereas HTTP's general application semantics induces huge effects. That's why I don't think BEEP will see much success, and why HTTP will continue to grow in use, even beyond browsers and humans.

Previous Message

Next Message

• BEEP and HTTP
  2002-10-21 16:02:57 Ward Harold [Reply]
  
  To the extent that it's a useful characterization BEEP actually fits better at the OSI Session Layer. HTTP could be reasonably placed at layer 6 as well:

  
  Application --> Browser
  Presentation --> HTML
  Session --> HTTP

  
  Whatever. I'm not a big fan of OSI Layer pigeon holing so let's move on to your second statement.

  
  You claim both HTTP and BEEP address the problem of building "commonality between the multitude of application protocols out there". This is absolutely false. HTTP was designed as part of a software architecture designed to meet the needs of an Internet-scale distributed hypermedia application ["Principled design of the modern Web architecture" Fielding, Taylor]. BEEP was designed to be a "generic application protocol kernel for connection-oriented, asynchronous interactions" [RFC 3080]. HTTP has been pressed into service, with mixed results, as a generic application protocol substrate but that's not how it was designed to be used.

  
  Regarding "network effects", if the stock quote and sports scores services both support SOAP (over BEEP) and publish WSDL descriptions of their interfaces then the same application can access both services. In fact, if they are hosted on the same server I can use a single session to retrieve scores and quotes. Further, I can define an additional BEEP profile that allows the quote service to stream real-time quotes back to the client - again, using a single session.

  
  In programming language terms HTTP is Basic while BEEP is C.
  
  

  • BEEP and HTTP
    2002-10-25 11:33:58 Mark Baker [Reply]
    
    HTTP is an *application* protocol. That should be your first hint that it's layer 7. 8-) The application code, like a browser, isn't part of the protocol stack because it's not a protocol; it's just code that uses the application semantics of the application protocol. I'm amazed how many people don't understand this.

    
    To refute my point about generality, you claim "HTTP was designed as part of a software architecture designed to meet the needs of an Internet-scale distributed hypermedia application", which is entirely true. But a "distributed hypermedia application" is exactly what a generalization of other forms of distributed computation looks like.

    
    As for network effects, having an app that know what the methods in one WSDL document means, and can even parse other WSDL documents, doesn't in any way help them understand what the methods in the other WSDL documents mean. There are no network effects there. On the other hand, having an app that knows what GET, PUT, POST means, can help it interact with anything that presents that same interface. This is REST's uniform interface constraint, and the reason Web services are not being deployed (and will never be deployed) in quantity on the Internet.