Coach Wei's Blog

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.