We all know HTTP, the communication layer of Web 1.0. Recently, we also started to realize some of the limitations of HTTP. Recently 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. 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.He further describes the four components of an Internet Messaging Bus:
- Guaranteed delivery
- Once and only once delivery
- Guaranteed order of delivery
- Server push and client pull
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.What do you think the form of such an Internet Messaging Bus might take? It's easy enough to see JMS fitting the requirements for an internal bus, but what would an actual external bus look like?
Message was edited by: joeo@enigmastation.com