Books I've recently read and recommend!
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.
If we take this definition, then BlazeDS certainly supports "push messaging" via long-polling and streaming channels. It's true that RTMP is still better than long-polling and streaming in terms of latency and client notifications because RTMP provides a duplex socket connection between the client and the server. Long-polling and streaming are also limited by the number of threads the app server can provide.
Please see more information of Channels/Endpoints in BlazeDS/LCDS provided by Seth Hodgson on Damon Cooper's blog:
http://www.dcooper.org/blog/client/index.cfm?mode=...
But hey, buy LiveCycle - it gives you push AND data management!
And helps the stock price ;)
=Ryan
rstewart@adobe.com
I am sure it does all depend on your definition of "true" server push, but it is my understanding (and experience) that BlazeDS can go beyond basic polling and use a long lived, comet style, HTTP connection to stream data from the server to the client. There may not be much documentation out there, but it does state this pretty clearly: http://livedocs.adobe.com/blazeds/1/blazeds_devgui... Are the docs wrong?
My understanding is that while BlazeDS can do server push, it is only practical in very limited situations because it does not use a non-blocking IO So the amount of connections that a single server can handle is pretty small (hundreds?). Whereas LCDS does use Java NIO so it can handle many, many more simultaneous connections.
What will happen is that web servers will support or be configurable to allow longer and longer polling durations from client HTTP request as the Comet Pattern will become better supported.
Under Tomcat 6 with the Java NIO HTTP listener in effect, the Comet Events servlet protocol will be an efficient way for a blocked long-polling client to be connected with no thread being utilized on the server. Under today's 64-bit OSs and 64-bit Java JVMs, can probably expect concurrent long polling connections up to 20,000 to 40,000 per physical server.
BlazeDS has the advantage that it'll work over port 80/443, whereas LCDS will use some port for persistent connections that would require a firewall configuration.
Hence BlazeDS will be Internet friendly, while LCDS is basically appropriate for enterprise software in intranets.
Because we use Spring Framework, we have a very uniform way of creating Spring POJO beans to process BlazeDS async remoting calls, async Flex HttpService calls (GET/POST/PUT), and Spring template classes for JMS Spring beans. Spring Security 2.0 is used to apply authorization security across all these kinds of beans in a uniform manner.
So really Tomcat, Spring, BlazeDS, and a JMS broker are better combination than JEE app server and LCDS - IMHO.
Polling, regardless of whether it is short interval polling or long cycle polling is still _polling_.
Push is ONLY available when the client is connected throughout the entire life of the session.
Honestly, as an analogy -- I don't care how many times you check your mailbox, or how long you wait there each time, you are still polling your mailbox for letters.