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.

Aaron West's Gravatar
About this post:

This entry was posted by Aaron West on May 21, 2008 at 9:50 AM. It was filed in the following categories: Adobe AIR, ColdFusion, BlazeDS, Webmaniacs 2008, Dealerskins. It has been viewed 63182 times and has 15 comments.

15 Responses to The Truth About BlazeDS and Push Messaging

  1. Mete Atamel

    The term "push messaging" is vague and usually misused but in general, it is the type of messaging where the client does not have to ask to the server for updates in regular intervals (i.e. polling) but rather server sends the updates to the client when available without client asking for them.

    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:

  2. Amen dude. I work for Adobe and I was really confused when I started digging into LCDS and BlazeDS. BlazeDS is great but it doesn't do push messaging.

    But hey, buy LiveCycle - it gives you push AND data management!

    And helps the stock price ;)


  3. Really?

    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: 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.

  4. Mete Atamel

    You're right Derek. BlazeDS lives in a Servlet container and hence constrained by one-thread-per-connection limit whereas LCDS has NIO-based channels that can scale up to 1000s of requests.

  5. Once the servlet that implements BlazeDS is revved to support Comet Events under Tomcat 6, and then Jetty Continuations, then the long polling technique will be fine.

    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.

  6. Well spotted. There was also JMS support in FDS prior to version 2.5 (afair). But I think this "real-push" may be done with Red5. It supports RTMP and data may be easily streamed to it using NIO sockets or Red5 may pull the data from any other data source (as it is Java) and push later on to connected clients.

  7. I should add that we have BlazeDS wired into JMS in the date center in order to facilitate integration with other distributed software systems. Our Flex clients are able to be subscribers to JMS topics via BlazeDS adapter to JMS, and can publish messages to JMS topics as well.

    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.

  8. There is an open source implementation of the Real Time Messaging Protocol (RTMP), see

  9. LM

    It needs to be called what it is.

    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.

  10. com

    I think you should re-edit your post and stop being such a sensationalist... long polling is an accepted technique of server push, regardless whether you like to think so or not.

  11. @com - We'll have to agree to disagree. While a long-polling channel in BlazeDS gives a certain "push-like" feel to data transmission it isn't in my opinion a push technology. Pushing data from a server to a client should not require the client to initiate a connection or keep a connection with the server. This is what occurs with BlazeDS. I gave a presentation at BFlex ( this year where I talked about the different communication mechanisms built into BlazeDS. If you interested in more detail on why I don't believe BlazeDS brings true push messaging to the Web, check out my presentation slides and code.

  12. Jb

    I know it's been two years since the last post, but I called adobe today to get pricing on lcds. They're asking $30k per CPU! I think it was the first time i've been rude to a sales rep. All I need is there stupid assembler with the NIO service. I guess I'll hack together a consumer/producer with blaze ds. Anybody know what happens when the amf/servlet runs out of threads ???

  13. Thanks for the information shared here. that was an interesting and informative. I had a good experience by participating in the Adobe Summit in 2009 which features the latest developments on the Adobe Flash Platform that is of utmost importance to both developers, as well as designers.. I learnt lot of new technologies in Adobe. And I am planning to attend 2010 edition as well. I found the information about the conference from

  14. hDave

    I'm not push this book or anything, but in the book "Enterprise Development with Flex" the authors show a completely open-source server push alternative to LCDS...that uses NIO within BlazeDS.

  15. Thanks Dave. For those interested, the book Dave mentions came out in March 2010. You can check it out here: