Discussions

News: Web 2.0 Communication Layer: from HTTP to Comet to Internet Mess

  1. In a recent blog entry titled "Web 2.0 Communication Layer: from HTTP to Comet to Internet Mess", Rich Internet Application pioneer Coach Wei talks about the architectural flaws of the web, in particular, the communications layer. He says:
    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

    Threaded Messages (23)

  2. Why not call it transmission control protocol or even internet protocal. Heck, call it TCP/IP for short.
  3. Why not call it transmission control protocol or even internet protocal. Heck, call it TCP/IP for short.
    Well, the obvious answer to my mind is that TCP/IP doesn't guarantee delivery or order. So that would eliminate that as an internet messaging bus.
  4. Read your spec again on reliable sequenced packets. More to the point. Talking about using HTTP as a message bus is like the guy who uses Excel as a wordprocessor. What might be more in line is building on AMQ (http://www.theserverside.com/news/thread.tss?thread_id=41008) which is open, cross-technology, and seems to have a following where messaging rules. This would build on TCP not HTTP.
  5. TCP does guarantee...[ Go to top ]

    Mr. Ottinger, TCP most certainly does guarantee in-order, once-and-only-once, and error-free transmission of packets (or an error in the process). Of course, as for the point of this article, TCP doesn't provide a server-push model. And IP doesn't have any such guarantees of packet delivery. Of course, this is why UDP is capable of so much more throughput than TCP.
  6. Why not call it transmission control protocol or even internet protocal. Heck, call it TCP/IP for short.
    Well, the obvious answer to my mind is that TCP/IP doesn't guarantee delivery or order. So that would eliminate that as an internet messaging bus.
    I am sorry to counterdict but the TCP protocol gatantees message delivery and order. Jacques Ledoux
  7. Why not call it transmission control protocol or even internet protocal. Heck, call it TCP/IP for short.
    Well, the obvious answer to my mind is that TCP/IP doesn't guarantee delivery or order. So that would eliminate that as an internet messaging bus.
    To Jon Postel: please, don't worry, you didn't live in vain Guido.
  8. The biggest problem today with the web is that there is no real "push" technology available: it almost inevitably boils down to bandwidth hogging and process-intensive clientside polling. What is needed is true push-technology, where a server can push data and updates out to clients who are either connected or registered with the server. There are some ways of achieving this, but none that are applicable in a wider context, due to firewalls, different network topologies etc creating barriers.. All of the other stuff, like guaranteed delivery etc can always be addressed on an application level, but the lack of "push" is something that I think needs to be addressed on the protocol- and network level if it is to be applicable to any client anywhere, in any type of network.
  9. We have those technologies today[ Go to top ]

    but they are neither standard or widely available beyond commercial products and a small handful of open source projects (Commercial/open source JMS for example, SonicMQ, ActiveMQ). Other than that, there are many creative ways one can achieve the same effect but it all boils down to something one has to embed into a browser that is non-standard (via applets/activex controls). It would be nice if there were a standard client/server messaging protocol for cross-platform browsers and servers, let's write one ;-) Jin
  10. +1 Clients should be able to register for server side events if you want to properly talk about distributed computing. http is over(ab)used. OK it is easy to only use your 80-port and block all others, but I think it's time to reconsider the use of internet as a means of distributed computing.
  11. I think that NAT is one of the biggest problems here. If everyone had an IP address, push would be closer to reality. Maybe we need a new type of firewall/router that would help with "push" AND NAT? This firewall/router would accept requests for specific internal MAC addresses and forward packets to those clients. The web server would need know the IP of the firewall/router and the MAC to push a connection. Is this already possible?
  12. This is an interesting issue that I've been thinking about a lot. I agree with the blog points, but there are a couple of points I would add: * A successful platform needs to be ubiquitous. You want it on every user desktop and to have broad server support. That's what turned HTTP into a platform. Any protocol evolution will also need to share that quality. * The notion of presence can be incredibly useful for next generation protocols, especially in loosely coupled services between many servers. For those reasons, I think that instant messaging, and especially the XMPP (Jabber) protocol make for a very compelling platform. It's already supported by Google, IM will be on every single user desktop very soon, and XMPP already has some *very* powerful tools for developers such as a full pub-sub specification. XMPP is also branching out into more than just IM, becoming a full real-time communication protocol including VOIP. Our library for XMPP was recently mentioned on TSS: http://www.theserverside.com/news/thread.tss?thread_id=42516 What do others think? Is XMPP a potential alternative to HTTP protocols in some use cases? Regards, Matt
  13. If everyone had an IP address, push would be closer to reality.
    I think that instant messaging, and especially the XMPP (Jabber) protocol make for a very compelling platform.
    I think it's coming a time when we'll need that every desktop be a server, too. We want IP addresses for everybody, we need push technologies, we need stateful protocols... This thread is about the flaws of HTTP, and I've read another thread about the flaws of the current client platform, that is, browsers. Put these two together and we see we need servers everywhere.
    A successful platform needs to be ubiquitous.
    For short, I think we (maybe) need a stateful protocol, another generation of client platform with some basic server abilities and fixed IP addresses. Is this it?
  14. The W3C group started addressing some of these issues with HTTP-NG specification, but it seemed to just die: http://www.w3.org/Protocols/HTTP-NG/1998/11/draft-frystyk-httpng-overview-00
  15. For short, I think we (maybe) need a stateful protocol, another generation of client platform with some basic server abilities and fixed IP addresses.

    Is this it?
    I don't think NAT networks are going to go away. However, newer technologies nicely work around the issues and make it unnecessary for every machine to act as a server: * XMPP is a constant connection, which allows the server to push data any time it needs to. * XMPP has built-in support for federation. So, I can connect to my server and then talk to anyone else on the internet from there (like email). * ICE is now offering a good way to tunnel through NAT's for high-bandwidth peer to peer type connections. This is how Google Talk works behind firewalls, for example. For XMPP, all this work is being done through an extension called Jingle. You use Jingle when you want to do things like voice, video, and perhaps file transfer (although there are existing file transfer solutions as well). When using ICE with Jingle, that's a pretty powerful combo. http://www.voip-info.org/wiki/view/ICE
  16. How scalable are open connections via XMPP. On a typical dual processor machine with 2GB of RAM, how may open connections can be handled? With federation can I actually connect two people/clients between two servers?
  17. SIP will fix this issue[ Go to top ]

    Session Intiation Protocol can do the push and pull and is the http protocol for devises and we can seamlessly move from a IP phone to a brower to an IVR etc
  18. Robert, It all totally depends on the server implementation, but it should be possible to easily hit 20K concurrent connections per modest server box. XMPP implementations have been proven to scale. For example, Google Talk services millions of users. And yes, federation lets you connect between multiple different servers and it actually works well. :) Regards, Matt
  19. I really like P2P technologies. Some time ago, I and a partner modeled a workflow system based in a P2P interface. Just like we receive messages with MSN Messenger, we planned to receive work lists, work items and other notifications via P2P and IM. Well, it never left blueprints...
    XMPP is a constant connection, which allows the server to push data any time it needs to.
    I don't know... I may be completely wrong, but constant connections seem like waste of resources. It would be more appropriate to ensure the client is reachable by the server when it needs to send data, don't you think?
  20. Wow, it's nice that folks are catching on to this. Apache ActiveMQ and Jetty have been working in tandem to provide a highly scalable message bus API to javascript clients and it's been available for several months! For more details, see: http://activemq.org/site/ajax.html This provides a simple messaging API from java script to send and receive message from the broker. I think we will see more of this in kind of thing from the vendors. But remember... ActiveMQ brought it to you first and free! Regards, Hiram LogicBlaze Inc blog
  21. Sounds like BEEP[ Go to top ]

    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.
  22. Re: Sounds like BEEP[ Go to top ]

    Actually, XMPP might cut it (it doesn't all have to be xml does it?). I only say this b/c if the projects like smack gain enough traction than enough features may get developed to make it compelling. I read they are working on an AS3 port on the forum (with Flex2 at least the eye candy would be nice ;-), and if so it may be a cheaper alternative to FDS. In any event, enough of the semantics around p2p and s2s seem to be defined/built onto XMPP already. just a thought ;-)
  23. Maybe ICE from ZeroC already fits. Guido
  24. I have blogged a reply in length:
    I do not think the solution is in picking a winner among protocols. I think the solutions is recognizing that the paradigm for Ajax communication is messaging and not raw HTTP request. A common messaging API in the browser would allow multiple protocols to be tried and tested. New protocols can be developed and eventual browser/infrastructure support may even take us away from HTTP. The Open Ajax Alliance can certainly provide this common API and then we can all innovate above or below that API.