Web 2.0 Communication Layer: from HTTP to Comet to Internet Messaging Bus
October 13, 2006 – 9:34 pm by coachwei | Category WebDev, web 2.0 | 16 Comments »What is Internet Messaging Bus? Internet Messaging Bus is an enhanced web communication layer built on top of HTTP that supports two-way, bi-directional communications as well as reliable messaging.
We all know HTTP, the communication layer of Web 1.0. Recently, we also started to realize some of the limitations of HTTP. For example, HTTP is request/response only and does not support bi-directional communication. There are techniques to be employed for enabling bi-directional communications on top of HTTP. These techniques are being called as “comet”. However, comet addresses only a small part of the challenge. There are a lot of other challenges to be addressed in order for the web communications layer to work well. At Nexaweb, we took a fairly systematic look at this issue a few years ago and invented a set of techniques to address them. These techniques have been working out very well (A lot of customer applications having been depending on them, such as financial trading applications used by over 20000 traders). I call such a set of techniques “Internet Messaging Bus” (IMB).
The Web needs an enhanced communication layer in order to be more broadly adopted for enterprise business applications. This communication layer is beyond HTTP, beyond comet, and I think it is Internet Messaging Bus.
Historically speaking, the Internet was initially designed for presenting and sharing hyperlinked documents in the form of Web pages. Therefore, the communication layer is based on the HTTP “Request/Response” model, which adequately serves the purpose of “browsing.” Internet Messaging Bus is an enhanced communication layer that delivers reliability and two-way communications required by “mission critical” enterprise applications.
First off, Internet Messaging Bus supports guaranteed message delivery. Without IMB, when a user submits a request to the server, whether this request will actually arrive at the server or not is unpredictable. If there is a network problem (either with the ISP or within the corporate network itself), there is a good chance the request will be lost. However, this is not always a problem for Internet browsing, as the user can always click the link a second and third time if the first URL request is lost. Although this seems like a basic example in very basic terms, it is a serious problem for mission critical enterprise applications. The case and point being, that it is not out of the realm of possibility that a multi-million dollar transaction can be literally be “riding on the line.”
IMB supports guaranteed order of message delivery. Without IMB, if the user submits two requests in a row, there is no guarantee that the first request will arrive at the server before the second request. Again, while this is not necessarily a problem for browsing Web pages, the result of a later request can be dependent on an earlier request when using the Internet for business applications. A random ordering of message delivery makes the application behavior unpredictable — a pattern that many Web application users are familiar with.
IMB supports once and only once message delivery. Without IMB, a user request may arrive on the server side twice or even more, if some network problem caused the message to be cached and delivered more than once. Again, while this is not necessarily a problem for browsing Web pages, it can cause serious transactional problems for business applications.
IMB supports server-initiated communications (server push). For those who knows comet, this feature is really what comet is about. HTTP supports client-pull only. In a “client pull only” model, the server works like a phone that never rings. Obviously this is not a problem for browsing because the server needs to simply respond to page requests. However, many enterprise applications require the server to initiate interactions. For example, a stock trading application needs to push the latest stock price to the end user from the server. To side step this problem, developers typically use “client polling,” but this significantly increases the server/network load and therefore decreases application performance.
I always say “Web 1.0 architecture is seriously flawed” from an application point of view. The limitation of HTTP is one of these flaws. It is no surprise that the common perception is that Web applications are unreliable and problematic. Users often experience “404,” “resource unavailable” and “network unavailable” errors or even a mysterious application error telling them to “retry the application later.” The truth is that a fundamental source of all these problems is the HTTP communication layer of the Web itself, as it is often the cause of many of these problems. In order for the web to be adopted for enterprise business applications, Internet Messaging Bus is a must-have requirement.
Update on Oct 17 2006:
- My colleague Greg Wilkins has a fairly interesting blog on this subject;
- There is an active discusson on the www.serverside.com related to this subject:Web 2.0 Communication Layer: from HTTP to Comet to Internet Messsaging Bus;
- AjaxWorld Magazine covered this blog entry as an AjaxDesk news item.
16 Responses to “Web 2.0 Communication Layer: from HTTP to Comet to Internet Messaging Bus”
Hi, make sure you check http://www.webofweb.net, though it is not ajax but java, it's very potential a new milestone for web 2.0
By compl on Oct 16, 2006
Wow looks interesting.
Any chance that you can post some more info about it? it is a little hard to read and figure out what you are trying to achieve…
By andy on Oct 16, 2006
WoW is able to take the place of html in some fields of web, since its structual, secure and realtime collaborative feature. Mind Mapping is a good thing but its broad usage has been limited by implementations as single user, desktop applications, while WoW overcomes this shorthand, and enhance it to network structure by allowing phyical links.
Though WoW is only there to validate and practice my new oo database: AV5TOB, from my personal perspective, I see this possibility but I myself am not devoted in web 2.0 evolution. For this reason I released wow by opensrc, and licensed an binary version of TOB to be freely distributed with it, in hope that web 2.0 guys can see and feel its value an potential, and further benefit from WoW's free src and architecture to achieve their web 2.0 goals.
Not well documented yet, but WoW's Traverser/Scener architecture is going to supersede either Client/Server or Browser/Server architecture, for web based rich client systems. Though AJAX is current mainstream and hotest solution for this, T/S architecture will be more suitable and cost efficient. Again, T/S need some time to come with full doc and get popular.
By compl(http://www.ableverse.org/) on Oct 17, 2006
and in addition, here is a little info about Traverser/Scener Architecture: http://www.webofweb.net/traverse?r=412
And note you need to have Java 5.0 or later installed for browser to view it.
By Compl on Oct 17, 2006
XMMP does not cut it. It is a fine protocol but not suitable for Coach Wei's internet service bus. The problems are that it is suitable for XML only and that it can only send one message at the same time. If you need to do more, you must set up a direct connection. And who will define that connection?
Meet BEEP. Blocks Extensible Exchange Protocol (aka BXXP) is a feature rich protocol that enables you to create powerfull application protocols.
BEEP is:
- peer-wise, each side can initiate a message exchange
- full-duplex, messages can go in both directions simultaneously
- messages are never duplicated, altered or re-ordered, the sender is notified upon message loss
- defined in IETF RFCs
- implemented in many languages (even javascript is in the works)
Within a BEEP session you can create multiple channels. Messages are exchanged within the context of a channel. The protocol automatically uses push-back -per channel- for thin or just remote clients.
APEX connects multiple BEEP clients in a distributed way.
More information on the spec, libraries, products etc. can be found on http://www.beepcore.org.
Of course, the advantage of XMMP is that is already big. But be aware of making XMMP the HTTP of tomorrow.
By Erik van Oosten (http://www.day-to-day-stuff.blogspot.com/) on Oct 17, 2006
Sorry, I should have removed the XMMP stuff. This was a direct copy of my post at tss.
By Erik van Oosten (http://www.day-to-day-stuff.blogspot.com/) on Oct 17, 2006
Coach, I couldn't agree more with the need for a messaging paradigm. I look forward to working with you in the Open Ajax Alliance to achieve this.
By Greg Wilkins(http://blogs.webtide.com/gregw/) on Oct 18, 2006
great piece, Greg!
By Coach Wei on Oct 18, 2006
This was cool when I came up with it months ago, and started the Cometd project.
You're a little late…
Good idea though
By David(http://cometd.com) on Oct 31, 2006
This is exactly what was in the minds of Alex Russell, myself and a number of others when we described the comet name.
Nice to see you jumping on the bandwagon but rather than coining yet another name it'd be much appreciated if you'd collaborate with the cometd project instead
By Matt Trout(http://www.shadowcat.co.uk/) on Oct 31, 2006
I am totally lost with your post. I get the impression that this post is trying to say that HTTP is broken and does not work for the kind of apps you are talking about.
>>First off, Internet Messaging Bus supports guaranteed message delivery.
What are response codes in HTTP for?
>>IMB supports guaranteed order of message delivery.
What is TCP for? HTTP is based on TP. When you are sending asynchronous requests via a client API like XMLHttpRequest, of course, HTTP can't help guarantee the order of requests and responses.
>>IMB supports server-initiated communications (server push). For those who knows comet, this feature is really what comet is about.
This is not an accurate. When you are using HTTP based push, the client is initiating a connection for the server to write. Server can't initiate the communication without a client connecting to it.
>>The truth is that a fundamental source of all these problems is the HTTP communication layer of the Web itself, as it is often the cause of many of these problems.
I'm lost. This statement does not parse well. But I guess that you are trying to blame the protocol for application, network, or hardware level problems.
By Subbu Allamaraju(http://www.subbu.org) on Nov 23, 2006
I am totally lost with your post. I get the impression that this post is trying to say that HTTP is broken and does not work for the kind of apps you are talking about.
>>First off, Internet Messaging Bus supports guaranteed message delivery.
What are response codes in HTTP for?
>>IMB supports guaranteed order of message delivery.
What is TCP for? HTTP is based on TP. When you are sending asynchronous requests via a client API like XMLHttpRequest, of course, HTTP can't help guarantee the order of requests and responses.
>>IMB supports server-initiated communications (server push). For those who knows comet, this feature is really what comet is about.
This is not an accurate. When you are using HTTP based push, the client is initiating a connection for the server to write. Server can't initiate the communication without a client connecting to it.
>>The truth is that a fundamental source of all these problems is the HTTP communication layer of the Web itself, as it is often the cause of many of these problems.
I'm lost. This statement does not parse well. But I guess that you are trying to blame the protocol for application, network, or hardware level problems.
By Subbu Allamaraju(http://www.subbu.org) on Nov 23, 2006
Thanks for the comments. I have seen quite a few similar comments at various places and they definitely deserve to be explained.
>>>First off, Internet Messaging Bus supports guaranteed message delivery.
>What are response codes in HTTP for?
Answer: A response code will PROBABLY tell the developer about the response status of a request - but it does not mean the request is delivered. For example, if you send a request from the browser and the network got disconnected in the middle of transmission, your browser may give you a “404″ error or may not give you an error at all - because the browser may not know there is a problem over the network (the network problem could be happening 10000 miles away somewhere over the Internet) and it will just keep waiting until eventually it times out.
>>>IMB supports guaranteed order of message delivery.
>What is TCP for? HTTP is based on TP. When you are sending asynchronous requests via a client API like XMLHttpRequest, of course, HTTP can't help guarantee the order of requests and responses.
Answer: It is a common confusion that HTTP is reliable because TCP is reliable. TCP is called as a reliable protocol. TCP will gaurantee the relability of an individual message (within a certain limits) by breaking that message into packets and perform ACK between packets. If a packet is lost or out of order, TCP protocol can handle these problems.
However, the reliability of TCP's capability of handling the packets within an individual message does not mean a higher level protocol like HTTP is reliable:
1>If you are sending two HTTP requests (messages), TCP gaurantees that the individual bytes of each message will be delivered in order, but it does not gaurantee the order of delivery of these two HTTP messages. For example, a later sent HTTP request may arrive at the server before an earlier sent HTTP request;
2>TCP's reliablity has a certain limit - a message may still be dropped or timed out. Such problems are difficult to handle Without a higher level intelligence;
>>>IMB supports server-initiated communications (server >>>push). For those who knows comet, this feature is really >>>what comet is about.
>This is not an accurate. When you are using HTTP based push, the client is initiating a connection for the server to write. Server can't initiate the communication without a client connecting to it.
Answer: What you said it true that any HTTP browser based push connection has to be ultimately initiated by the client. However, once a connection is established, server can certainly initiate communications with the client.
>>>>The truth is that a fundamental source of all these problems >>is the HTTP communication layer of the Web itself, >>as it is often the cause of many of these problems.
>I'm lost. This statement does not parse well. But I guess that you are trying to blame the protocol for application, network, or hardware level problems
Answer: HTTP protocol does not have the capability to deal with network and hardware level errors. As a result, all these problems are left to application developers. Unfortunately, 99% web applications do not handle these problems either.
By Coach Wei on Nov 24, 2006
Opens with an absurd false statement. Poor fact checking calls the entire document into disrepute. The internet was initially designed specifically for voice and remote login, then text mail and instant messaging, years and years later hypertext publishing, easily verified by a quick glance at RFC titles by date. The author had best correct the error or face ridicule.
By Devon Sean McCullough(http://people.csail.mit.edu/devon/) on May 31, 2007
Guys, how long do you want to discuss all these strange things? Come on, download games and relax. Oh, jeez. I'm probably dreaming.
By Mike Stallone on Jun 27, 2007
Thanks!
Heres some info on intelligence
By Anonymous on Aug 17, 2007