QueTwo's Blog

thouoghts on telecommunications, programming, education and technology

Flash Builder Client-Side Data Management vs. LCDS

One question I am asked fairly regularly is this : “Now that Flash Builder will include what they call Client-Side Data Management, why would anybody need Adobe’s LiveCycle Data Services?” 

Until this latest version of Flash/Flex Builder and Flex, there was a very clear distinction for when you needed LiveCycle Data Services and when you could simply use BlazeDS.  If you wanted seemless interactions between your database and your client, you by default went to LCDS.  If all you cared about was sharing data between clients, then you could get away with BlazeDS.

With the upcoming version of Flash Builder there is a new set of wizards called the DCD or the Client-Side Data Management Wizards.  These wizards will emulate a lot of the functions and features that were previously only available to LCDS users.  Things like having changes to an ArrayCollection (via a DataGrid) auto-commit to the database are now available, as well as data pagination and some other time-saving features.  All of this work is done on the client-side with little work on the server.

You don’t get all the features of LCDS, however.  LCDS’s Data-Management features allow you to have the concept of ‘managed’ data on the server.  This means that you have a middle-ware application that stores a copy of your data in RAM and keeps track of which clients are accessing which parts of that data.  The concept allows you to do things like real-time conflict-resolution (client-side only supports last-in-wins) where both clients are notified if the data is changed in any connected client.  It also allows for real-time data updates — for example, if you have client-A update their data, client-B who is also viewing that data is instantly notified that their view is old and updated with the changed set.  This is immensely critical where you have data that is viewed and possibly updated in realtime by multiple people — and it is only available in LCDS.  LCDS also allows you to do lazy-loading out of the box, which is not available in the client-side version.

Adobe’s LiveCycle DS 3 also introduced the “Data Modeling” workflow in this past release.  This plugin to the Eclipse framework allows users to model their database (or pull in an existing database and have it modeled for them) and make changes to that database, regardless of what database server is in the backend.  This is using UML-like diagramming, and is extremely powerful.  LCDS Data Modeling View can then take that UML model and auto-create forms (with validation), data views, etc. with a few clicks of the mouse.  With this model, no server-side coding is required at all.

Flash Builder’s Client-Side Data Management emulates the form-building aspect of this, however it is not nearly as automated or point-and-click.  It will write some stub classes for you, and set you up with the basics, but things like validation have to be written by hand.  Furthermore, you have to customize your back-end server coding to match how DCD expects your classes/cfcs to work. 

Pretty much, to sum it up, if you need you plan on having your clients view and edit the same piece of data at the same time, you may still want to consider LCDS.  If you don’t want to write any back-end code, LCDS is also worth looking at as well.  Otherwise, see what Client-Side Data Management can do for you.  But remember, Adobe no longer offers their Community Edition / 1 CPU edition / Free Edition / Office Edition, so LCDS has become quite costly to get into.  I wish that wasn’t the case 😦


2 responses to “Flash Builder Client-Side Data Management vs. LCDS

  1. Steven Erat February 19, 2010 at 12:44 am

    Thanks for your post Nick. This helps clear up some of my confusion about the overlap in technologies.

    I think Adobe would be well served to have a feature comparison chart or something similar to make it crystal clear when DCD will solve your problem and when LCDS is the better choice.

    With the twitter dialogue I had about this last night, it became evident that the terminology for each approach overlaps too much. Yes they both have Data Management, but it would be better if they had different names for that feature to avoid a semantic nightmare when trying to explain it. Its a little like the Abbott & Costello skit about “Who’s on First?”

    • quetwo February 19, 2010 at 1:20 am

      I personally think that the sales team is using this to their advantage. Most of them have no idea what the product does (which clearly translates to a lot of the marketing material out there). I don’t think it is evil in nature, but LCDS is a very complex product. A simple comparison would really show that that this product adds very little to the table when multiple other products are added together. As BlazeDS gets more powerful, and people figure out how to do this DCD stuff by themselfs, it makes it very hard to sell the value (espically at $30k/cpu with a min of 2 cpu).

      LCDS has a lot of value, but I don’t think Adobe, nor many of their customers understand it. Many developers do, but unfortunatly, it is completely priced out of the market for 99% of the people who would use it. Heck, if they dropped the price to be comparable to CF Enterprise, I bet it would sell like crazy.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: