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