The dream came true! We have the winner! The BlazeDS!

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!