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.


Ben Forta kicked things off this morning giving a talk he titled "ColdFusion 8 and Beyond." Here are my rough notes on the information Ben covered. He began by discussing the ColdFusion Open Process Initiative which is made up of the following:

  • public bug database
  • public enhancement request system
  • custom advisory board
    • CFML design
    • feature definitions
    • specification reviews
    • early release reviews

But what comes next in the world of ColdFusion? Work has begun on "Centaur" which is about improving the integration story of ColdFusion. CF has had an integration story since 1996 with ColdFusion 2. Centaur will be about improving the integration of ColdFusion especially with regard to Flex and AIR. Another thing Centaur will be about is improving the developer experience. Particularly making the process cleaner, easier, and better for developers writing CFML and technologies that surround CFML. More details on Centaur will be released at MAX this year in San Francisco on November 16-19..

CF has evolved into being the ideal backend for rich Internet applications. The trend started several years ago with the introduction of WDDX (Web Distributed Data Exchange) and Flash Remoting. This further evolved - with Adobe at the helm - into data services integration with LifeCycle Data Services and more recently the open source BlazeDS. LCDS adds two things to the mix from a CF perspective: messaging and data management (including data synchronization).

There are two ways LifeCycle can be installed

  • CF + LCDS installed as the same instance on a J2EE server
    • simplied installation
    • high performance (direct Java APIs instead of RMI calls)
    • requires CF8
  • External LCDS (external to CF for clarification)
    • simpler upgrading of LCDS because it is separate from CF
    • better suited if LCDS used by more than CF
    • supported by CF 7.0.2 and 8

Messaging is the term used to define sending any data at all from one destination to another destination. With CF and Flex, messaging is about ensuring your data makes it to its destination instead of hoping it does like e-mail.

LCDS push technology keeping the connection open between client and server.

  • Publish and subscribe
    • producer and consumer
  • Asynchronous communication
  • Messages have header and body
    • values can be complex types
    • values are converted to/from CFML and AS types
  • ColdFusion can be both a Producer and a Consumer
    • publish - SendGatewayMessage()
    • Subscribe - Event Gateway CFC
  • Data Management
    • the old last to save wins scenario was described
    • Data Services solves this problem
    • it can have a knowledge about structured data and who (which clients) and what data and what state that data is in
    • Data Services is the server component between the client and ColdFusion
    • automatically compares original data with changed data when it is returned from the server. it can say "oh, you changed this field and other users have this record, so we must send them the new copy."
    • can build conflict screens in apps to not only show what data has changed, but to show conflicts and allow users to choose how to handle them which in turn will tell LCDS what to do.
    • wizards available to the Eclipse environment generate all the CFCs needed to manage this type of data management process

LCDS has Flash Remoting, messaging, and data management.

BlazeDS has Flash Remoting and messaging but not data management.

LCDS is in beta version 2.6 now. It is going to integrate well with AIR clients. Think about an AIR client going offline and keeping up with changed data on the client. When the client reconnects, the changed data gets pushed back to LCDS which performs any necessary data management stuff it needs to from there.