Dreaming about message-based internet applications

As a person who have been developing message oriented integration solutions for 6 years already and still continuing to do so and also as a follow up to my previous blog "Why are we still using HTTP" where I proposed a challenging idea to drop HTTP in favor of some other more appropriate protocol for modern asynchronous internet applications I feel a moral obligations to draw a little sketch of a protocol that perhaps would be suitable to fill the void.

The following describes the main ideas of the protocol and is open for further discussion and alterations. The name might be something like "WebMessaging" or "wmsg" for short and the urls would be like wmsg://www.google.com

The purpose of the protocol is to provide a flexible messaging mechanism between internet browser and a web server that would enable developers to create advanced network applications that are accessed over the internet with browsers. The protocol establishes the foundation of secure and dependable messaging that would enable asynchronous communication from client to server as well as from server to client.

The protocol would be based on trusted entities or tokens if you will and as trust is the basis of all, therefore the security is a must. Even if the payload is not encrypted, then the tokens representing the trust, must be properly encrypted and signed by trusted certificates. Something along the lines of HTTPS.

1. The initial connection is always made by the client towards the server. The connection could be made to popular and well-known port 80 where the specific protocol details will be negotiated.
2. After server receives the connection request, the handshake procedure is initiated.
3. The handshake procedure is there to establish a pair of secure, trusted and unique tokens between the browser and server. The tokens are generated by the server and browser and exhanged in secure fashion. Both tokens are stored in the memory of both systems for future use.
4. The browser will associate a client side session and a specific browser window/tab to a token received from the server.
5. The server will create a new session and associate that to a token. Also the client token is added to the association so that server has an association consisting of TCP/IP connection, server token, client token and session object. This should be no concern of an application developer but shall handled invisibly by the application container.
6. After the token/session associations are made the server delivers message to an application together with the session object. Application will always see only the message received by the client and a session object. No tokens are given to applications at any time.
7. The session object is used by the application to send messages to a client. If an application wishes to send message to a client, it uses appropriate session method to do so. Whenever that happens, the application container then maps the session to stored tokens and uses them to deliver the message to client over associated connection. Of course in order to deliver message to a client, the connection between client and server must be up and running.
8. If application wants to send asynchronous messages to client, one should store the session object for future use. Otherwise the application can communicate with client only upon request which causes session object and message to be passed to an application.
9. Each message exchanged between client and server must contain a token either directly or indirectly.
10. When browser receives a message from server, it relates a token in the message to a window/tab and delivers the message which either renders a new content or perhaps triggers a javascript function.

Also there could be a possibility for a client to add new tabs/windows to an existing session. This would mean a new security token creation and server-side association with an already present session. From server side, the session would contain several views or areas if you will that an application can address individually. This way it would be possible to create multi-window client applications. Even if client side displays several windows, they all would be part of the same application and could be updated from the server in any way and at any time fully asynchronously.

As the client-server correlation is established with tokens instead of IP connections, it creates a possibility for off-line applications. That is, the connection could be dropped in mid-session, then again established using handshake procedure and the trusted communication would be restored to a state before connection was lost.

Whenever the server would want to send a message to a client and the physical connection would not be present those messages would be queued at the server. If the client establishes a connection, those messages would be transferred to client.

As a true mesaging system, the TTL or time-to-live property would have a very important role to play. Each server side session will have a TTL and messages related to a session may not have longer TTL than that of a session. This means, that if the connection is not present and there are messages waiting to be transferred but the session reaches to a moment of timeout, all messages would be timed out also. Of course, messages may have shorter TTL and expired messages will not be transferred to the client.

As the protocol is fully message oriented then the browser would have a big responsibility of routing the incoming messages to their correct destinations within the browser address-space.

So this is a short overview of a protocol that would enable us to create truly asynchronous and modern internet applications. I hope, that someone will one day implement something along these lines and realize a possibility to create much more elegant solutions than the AJAX and Comet crap will allow us to do today. Perhaps it would be good idea to drop a line to W3C?

I believe that AJAX and Comet are not the solution to our problem, as they are not addressing the real problem underneath and therefore I still have a question to you all: why are we still using HTTP?