I'm hanging out at Webmaniacs this week and there's been a lot of confusion surrounding BlazeDS and push messaging. This confusion has been rooted in Adobe's marketing of BlazeDS including several presenters saying BlazeDS has the ability to push messages to a client just like LifeCycle Data Services (LCDS). Even this week at Webmaniacs presentations have been given talking about the differences between LCDS and BlazeDS. In a small grid of features including Flash Remoting, Messaging, and Data Management/Synchronization, the only missing check mark on the BlazeDS side was for data management and synchronization. Developers have taken this to mean BlazeDS includes the full spectrum of messaging that is included in LCDS.
Just after the introduction of BlazeDS in February, at Dealerskins we began creating a BlazeDS/HTML/Ajax/AIR application with the intent to push messages from a ColdFusion interface to an AIR application running on several dozen remote computers. After trudging our own path with BlazeDS (there is VERY little documentation and info online) we discovered you simply can't do push messaging without purchasing the full featured LifeCycle Data Services.
This week I was finally able to confirm with Adobe you cannot do push messaging in BlazeDS. Some folks have been quick to argue "push messaging" is a matter of definition or context. There are definitely different flavors of push messaging most of which are defined by whether the client is actively listening to the server or if it even knows it is in a position to receive a message from the server. Putting definitions aside, LCDS brings true push messaging to the table because it uses Adobe's proprietary Real Time Messaging Protocol (RTMP) to create a constant connection between itself and the client. BlazeDS is open source, and since RTMP isn't (incidentally, Adobe's AMF binary protocol _is_ now open source) it is not available as a channel in the BlazeDS configuration files. Your only option for implementing messaging is to create a channel for AMF polling, configure some settings for polling, and then define your message producers and consumers.
In the application we built at Dealerskins, ColdFusion was a message Producer and AIR on the desktop was a message Consumer. In other words, a ColdFusion application produced a message that was sent to a CFC which then talked to BlazeDS, which then waited for AIR clients to request/consume new messages. While this worked fine, it is in my opinion overkill as we could've written the AIR application such that it connected to ColdFusion directly (CFC) in order to get new messages.
I hope this clears up some differences in features between BlazeDS and LifeCycle DS.
