First things first: If you have not read the older posts, then you should do so (the oldest first) before reading this post as they would clarify the problem for which this post suggests a solution.
Yesterday I started to look around in the Internet as I believed that there must be other people who are thinking the same way as I do and are actively looking around for a messaging protocol suitable for the web.
Having had some discussion about the issue with other people, I knew that the protocol must have streaming capabilities and actually that might also be a problem for wide adoption as it is a serious no go for many public sites.
So I was looking for a streaming protocols that would be specifically tuned for two-way message exchange. I even went as far as to think about the possibility of modifying an existing media streaming protocol for the task of general purpose light weight messaging but fortunately someone has already taken care of that.
I looked at the list of alternatives at Comet Wikipedia page (Comet was the initial reason for my frustration and active search for the alternatives) and noticed an interesting protocol being mentioned there. It was named the BlazeDS and from the first glance seemed the absolutely right tool for the job.
The BlazeDS was initially developed by Adobe to enable real-time messaging capabilities for its Flash products and it used to be a part on bigger proprietary offer Adobe LiveCycle DataServices ES. At the end of 2007, Adobe decided to open source the BlazeDS part of the offer and since then that web oriented messaging powerhouse is available for anyone to use and develop.
The BlazeDS has a lots of absolutely stunning features which makes it very very attractive. I will name a few here and you can find further information from the homepage http://opensource.adobe.com/wiki/display/blazeds/BlazeDS
First to mention is the fact that the protocol is based on binary messages and it uses Action Message Format (AMF) to transfer the data in real-time. This makes the protocol very effecient and allows the biggest bit-bangers and speed junkies to fullfill their wildest dreams. But don't be afraid, all binary protocols allow the transfer of the text, as actually the human readable characters are subset of the binary data domain. So it can easily be used to transfer HTML/XML fragments to a client.
The second feature to note, is the ability for the protocol to exchange messages in real-time. The real-time property might seem like an over-kill at first, but it is a nice value-adding feature, and there is nothing wrong if messages are exchanged in high-speed fashion. If you need real-time exchange, its already there, and if you don't care then all you get, is an effecient message exchange capability.
Next very big feature to me is the fact that protocol designers thought about the existing messaging protocols out there. More specifically, the tight integration options with JMS are already available. So basically what you can do is to attach your browser application pretty much directly to your messaging backend and the browser becomes the client to your enterprise messaging subsystem. So from browser you can send messages to enterprise, and whenever ther is something that enterprise wants to share, the channel is there and the messages are delivered in real-time straight to the web-page.
One more quite important feature is the fact, that the server side is java-based and that there is already latest Tomcat server available that has the BlazeDS integrated. So the protocol can be used with existing java-based application containers like Tomcat, JBoss and probably others (most of them use Tomcat as web-tier anyway). Also from server-side the Java programming model can be reused and no fancy techniques are required to use the protocol. On the client side though it seems to me that there must be a Flash module on the webpage that will be the client side communication endpoint. The Flash application will then relay the messages between the HTML page and the server. But there are ideas about attaching the BlazeDS directly to JavaScript wich would be quite a big plus (not that the Flash is something impossible and un-acceptable).
So this is the brief overview of the BlazeDS and how it looks on paper. I will start to tincker around with it in the coming days, so you can look back here later to see how it is going and what the hands-on experience has to say.
Mean while you can find all the information from Google with "BlazeDS" query and judge for yourself!
Monday, July 7, 2008
Sunday, July 6, 2008
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?
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?
Saturday, July 5, 2008
Why are we still using HTTP?
I have a big question to you all: why are we still using an HTTP protocol?
Another day, I browsed around to find information and resources about AJAX. I read a piece about one big problem for AJAX developers which is the server push technology. Also there were few solutions provided to overcome that problem. The more I read about it, the more I realized, that we are dealing with the wrong problem. It seems wrong to try to invent a mechanism to do a server push in AJAX and over HTTP, because what we actually try to do is to fit a square box into a round hole and it just does not fit!
We are desperately trying to establish an asynchronous communication model on top of synchronous HTTP protocol. This is totally beyond my mind. Why are we wasting energy on such a silly thing?
The inherent limitations af synchronous HTTP protocol simply put a huge restriction into developing modern internet applications. Our mind has turned towards asynchronous applications where client can dynamically ask additional information from server and server can also post information dynamically to client whenever needed. But why are we trying to establish this new application standard on top of an old protocol that is not able to meet the requirements?
I think that it is time to think just a little outside the box here and perhaps develop a new more suitable internet protocol to meet the demand.
Of course one could say, that HTTP is everywhere and browsers do not support any other protocols and therefore it is impossible. But why browsers do not support any other protocol? Well, because all the internet servers provide content over HTTP. And why is that? Because all browser support HTTP. Seems like an egg-chicken problem? Well lets look again.
Indeed truth is that HTTP is everywhere but lets take another analogue. There were days where all the pages in the internet were pure HTML and nothing but. If you look at current internet sites then you see, that there is still some HTML but there are also a lots of other technologies present like Java, Flash and so on. How is that possible? The fact that browsers support different plug-ins, has enriched our web-pages beyond recognition (compared to pure HTML era).
Why can't we make the same thing happen with protocols? Why couldn't a browser support several protocols through plug-ins? All internet users are accustomed with plug-in installation routines and nobody notices the fact, that web-page requires a flash plug-in to be installed. The user just makes a few clicks, installs the plug-in and enjoys a flash media. Is it that hard to make the same thing happening with protocols?
If we would have a fancy asynchronous protocol XYZ available and a user requests a page, then one would be greeted with a dialog that instructs user to install a missing plug-in for that protocol. After few clicks, the plug-in is installed and user can experience a fancy application.
One of course can say, that HTTP is still so popular that users cannot accept such a change. Tell me, how many people will type their addresses like h-t-t-p-:-/-/-w-w-w-.-g-o-o-g-l-e-.-c-o-m? I suspect that 90+% of users will simply type www.google.com and majority of them have already discovered that google.com works as well. And if you would ask from a user wether one would mind another protocol instead of HTTP, the probable response would be that 'what the heck is HTTP?'
So seems that there are no major obstacles to introduce a new protocol that is appropriate for a modern asynchronous internet applications. There are asynchronous message oriented protocols already available. One of the better known is JMS but there are others as well and nobody restricts to develop a new lean-mean internet oriented messaging protocol. There is a possibility to introduce plug-ins and if Firefox does not yet support protocol plug-in, then it is about time take advantage the open source nature of FF and make the necessary improvements. And users - well they probably just does not mind as long as the improved experience is guaranteed.
So my question to you is: why are we still using inappropriate HTTP protocol? When you, IT people, are not satisfied with Windows, you jump to Linux or OS X. When you are not satisfied with IE, you switch to FF. When you are not satisfied with present tools, you try to seek the way out. Why are you still so happy with sub-par HTTP protocol, is totally beyond me.
I am expecting just a little outside the box thinking from you all.
Over and out!
Another day, I browsed around to find information and resources about AJAX. I read a piece about one big problem for AJAX developers which is the server push technology. Also there were few solutions provided to overcome that problem. The more I read about it, the more I realized, that we are dealing with the wrong problem. It seems wrong to try to invent a mechanism to do a server push in AJAX and over HTTP, because what we actually try to do is to fit a square box into a round hole and it just does not fit!
We are desperately trying to establish an asynchronous communication model on top of synchronous HTTP protocol. This is totally beyond my mind. Why are we wasting energy on such a silly thing?
The inherent limitations af synchronous HTTP protocol simply put a huge restriction into developing modern internet applications. Our mind has turned towards asynchronous applications where client can dynamically ask additional information from server and server can also post information dynamically to client whenever needed. But why are we trying to establish this new application standard on top of an old protocol that is not able to meet the requirements?
I think that it is time to think just a little outside the box here and perhaps develop a new more suitable internet protocol to meet the demand.
Of course one could say, that HTTP is everywhere and browsers do not support any other protocols and therefore it is impossible. But why browsers do not support any other protocol? Well, because all the internet servers provide content over HTTP. And why is that? Because all browser support HTTP. Seems like an egg-chicken problem? Well lets look again.
Indeed truth is that HTTP is everywhere but lets take another analogue. There were days where all the pages in the internet were pure HTML and nothing but. If you look at current internet sites then you see, that there is still some HTML but there are also a lots of other technologies present like Java, Flash and so on. How is that possible? The fact that browsers support different plug-ins, has enriched our web-pages beyond recognition (compared to pure HTML era).
Why can't we make the same thing happen with protocols? Why couldn't a browser support several protocols through plug-ins? All internet users are accustomed with plug-in installation routines and nobody notices the fact, that web-page requires a flash plug-in to be installed. The user just makes a few clicks, installs the plug-in and enjoys a flash media. Is it that hard to make the same thing happening with protocols?
If we would have a fancy asynchronous protocol XYZ available and a user requests a page, then one would be greeted with a dialog that instructs user to install a missing plug-in for that protocol. After few clicks, the plug-in is installed and user can experience a fancy application.
One of course can say, that HTTP is still so popular that users cannot accept such a change. Tell me, how many people will type their addresses like h-t-t-p-:-/-/-w-w-w-.-g-o-o-g-l-e-.-c-o-m? I suspect that 90+% of users will simply type www.google.com and majority of them have already discovered that google.com works as well. And if you would ask from a user wether one would mind another protocol instead of HTTP, the probable response would be that 'what the heck is HTTP?'
So seems that there are no major obstacles to introduce a new protocol that is appropriate for a modern asynchronous internet applications. There are asynchronous message oriented protocols already available. One of the better known is JMS but there are others as well and nobody restricts to develop a new lean-mean internet oriented messaging protocol. There is a possibility to introduce plug-ins and if Firefox does not yet support protocol plug-in, then it is about time take advantage the open source nature of FF and make the necessary improvements. And users - well they probably just does not mind as long as the improved experience is guaranteed.
So my question to you is: why are we still using inappropriate HTTP protocol? When you, IT people, are not satisfied with Windows, you jump to Linux or OS X. When you are not satisfied with IE, you switch to FF. When you are not satisfied with present tools, you try to seek the way out. Why are you still so happy with sub-par HTTP protocol, is totally beyond me.
I am expecting just a little outside the box thinking from you all.
Over and out!
Subscribe to:
Posts (Atom)