Welcome!

Coach Wei

Subscribe to Coach Wei: eMailAlertsEmail Alerts
Get Coach Wei via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Web 2.0 Magazine

Web 2.0 : Article

Web 2.0 Communication Layer: from HTTP to Comet to Internet Messaging Bus

Recently, we also started to realize some of the limitations of HTTP...

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.

More Stories By Coach Wei

Coach Wei is founder and CEO of Yottaa, a web performance optimization company. He is also founder and Chairman of Nexaweb, an enterprise application modernization software company. Coding, running, magic, robot, big data, speed...are among his favorite list of things (not necessarily in that order. His coding capability is really at PowerPoint level right now). Caffeine, doing something entrepreneurial and getting out of sleeping are three reasons that he gets up in the morning and gets really excited.

Comments (7) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
omg 07/11/08 12:02:41 PM EDT

This is seriously the dumbest thing i read this year. The Windows Server 2008 ad in the top corner just adds to this farce.

Fernandez 12/12/06 10:40:15 AM EST

Complex user interfaces made with HTML and Javascript and communication based on HTTP just makes totally screwed systems. Impossible to debug and make secure. We cannot continue to ignore the lessons from the past.

We should build UI with high level languages and COMMS with specialized protocols.

David 10/31/06 03:04:25 AM EST

I agree with Kevin Ryan. Now THAT is a guy that knows what he is talking about. Unlike the post author, Coach Wei, aka 'AJAXWorld News Desk'.

"HTTP, the communication layer of Web 1.0."

buahahah Next, you'll tell me the internets is a series of tubes. All of this is quite amusing.

By the way, Cometd is comet with a messaging bus. Sound familiar? Oh, and it isn't vaporware like IMB.

Cheers!

Mike 10/30/06 01:55:29 PM EST

As more and more layers are piled on top of the HTTP layer, my jaw drops lower and lower. All the concerns of guaranteed, in-order, singular delivery, etc. are important to applications. It's all so inefficient and complex. Ironically, as standards evolve, I see a whole new market for security tools to deal with the problems introduced by these new ultra high level protocols. It all seems vaguely familiar...

Weren't all these concerns examined at a much lower level 15-20 years ago as TCP/IP really began to flourish? We need to take a step back and ask if everything needs to be piled on HTTP, just because it provides a pretty reliable and consistent path through firewalls and a ubiquitous browser client.

Wouldn't the better solution be to take another of the plethora of protocols that is more suitable to truly bidirectional communication? Or, build a new protocol that builds on what we already know, addresses the concerns of enterprise software (like security and synchronization), and is more suitable for functional scalability than HTTP. Even some minor enhancement of the more complex IIOP would be much more suitable than the bulk and complexity of all these layers on HTTP. However, I would more envision a new protocol with the simplicity of HTTP, designed to accepted modified versions of existing high level protocols like SOAP while accounting for many of the unsolved problems that are now rearing their ugly heads.

If such a development could proceed with industry consensus, it would attain broader support more easily, and stave off the the mess of complexity resulting from shoe horning solutions onto HTTP.

Me boo 10/24/06 08:41:37 PM EDT

This article is pure bullshit

Kevin Ryan 10/24/06 01:12:59 PM EDT

I totally disagree with this article; the Web is a hugh-scale example of an architecture that works well and HTTP (and the URL) is what makes it work!! HTTP was cleverly designed to be scalable for use with technology that did not exist when it was created (content negotiation between client and server). The fact that IMB is a 'layer on top of HTTP" (like SOAP and the other crippling layers), illustrates the flexibility of HTTP.

How can you imply that it is HTTP's fault for 404's? That is a server generated error message (that the requested resource is missing) - HTTP is just the messenger.

The article's example of message ordering is confusing. If the second request depends on the results of the first, then how could the second request ever arrive before the first? It would never have been sent until the results of the first were obtained. IMB's guarantee of message delivery is questionable - that is a tall order that so far has not been achieved in any networked system that I am aware of (although email tries real hard to come close).

HTTP purposefully does not allow server-initated communication - that is one reason why the Web works. Could you imagine if this were not the case (think SPAM)? The is not to say that HTTP does not support server-side push communication as the article states; it does indeed with the 'multipart/x-mixed-replace' content type. The client initiates a request for say stock quotes and the server will push them out all day long without requiring additional polls from the client.

The Web is not broken, it was carefully created to work well into the future.

Kevin Ryan
Software Engineer
National Radio Astronomy Observatory

AJAXWorld News Desk 10/18/06 12:57:12 PM EDT

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.