Article:		Beep BEEP!
Subject:		BEEP and HTTP
Date:		2002-10-21 16:02:57
From:		Ward Harold
Response to: BEEP and HTTP
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.

Previous Message

Up

Next Message

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