Anil Channappa’s Blog

What do you think (and why) will be in the next version of LC DS? Want to guess?

I have already talked about Model Driven development, but there is more than that

p.s: If you guess correctly you will have the option to be included in the pre-release program in early 2009.

For anyone who is interested in the history of this product

• Flex 1.0 (includes the SDK and Server) – Released March 2004
• Flex 1.5  – Released Nov 2004
  
• FDS (Flex Data Services) was decoupled from the Flex SDK in Flex 2.0 – Released 2006
• FDS was renamed LiveCycle Data Services – released as LC DS 2.5 in summer 2007
• LC DS 2.5.1 in fall 2007
• An open source version of remoting and messaging was released as Blaze DS in early 2008
• LC DS 2.6 was released in mid 2008
• LC DS 2.6.1 was released in Nov 2008

A new version of LCDS (2.6.1) and Blaze DS () is now available for download.

Key highlights:

1. Support the new version of Adobe® Flex™ SDK 3.2
2. (LC DS Only) Support federated portal Architecture – http://www.adobe.com/go/lcds26_wsrp
3. Java AMFlibrary – With this, java applications outside of LC DS and Blaze DS can send data allowing you to use LC DS and Blaze DS as your data gateway in your enterprise. More Info
4. Obviously some nagging bugs

More details

Blaze DS Release Notes

LC DS 2.6.1 Release Notes

We demonstrated the early release of our current work at max. Here are some highlights:

1. LC DS will support a new feature known as the Adobe data model. This is similar to a UML, but developers can also define behaviors such as validations. Validations can be defined once on the model, but will be validated on the Flex client as well as the LC DS
2. You no longer have to create DAO and actionscript classes. We automatically generate this from the model. The generated code is visible to developers and can be easily extended to provide your own behavior.
3. You no longer have to implement custom assemblers to provide data management. For each entitiy defined, we automatically provide CRUD functionality out of the box.  LC DS server uses the data model to provide this functionality
4. The data model can be deployed from Flex Builder (or dropped to a folder in LC DS) to an active LC DS server dynamically. You don’t have to worry about configuring destination, we automatically create them.
5. FlexBuilder will provide a new feature called the service browser. LC DS data model will be available as services from which you can drag and drop to a design view to create Flex applications.

Here is what we were able to do in 10 minutes at Max:

1. Create a MySQL database with 2 tables Company and Employee. An employee has to belong to a company
2. Create a data model from the database using a wizard in FlexBuilder (This automatically generates the actionscript classes)
3. Deploy the model to the LC DS server (This automatically configures the destinations, and adds the CRUD functionality on the server at run time)
4. Using the services generated form the data model, create a Flex UI in FlexBuilder design view
5. Run the flex application

Note: we did not configure the server or write a single line of code on the LC DS server for this demo. I will soon post a visual of this demonstration.

We know it is not easy to create a Flex application using LC DS. How about creating a fully working Flex app in 5 (may be 10) minutes? That is the goal for the demo of the upcoming release of LCDS at Max.

Watch out for more updates!

adobe.max.com - If you are interested in more details about Max

Obviously LC DS offers more features compared to Blaze DS, but here are 2 reasons why LC DS might be of interest to you:

Performance and Scalability

If you offer a service where large number of concurrent users are expected to receive notifications either periodically or in real-time.

Here are a few examples:

Consumer Applications: Internet users following a game online, Stock Tickers, Online Gaming, track news feeds etc.

Enterprise Applications: Real-Time decision making Dashboards, Brokers trading platform, bulletin boards across your enterprise etc.

Ease of Maintenance and Enhanced Productivity

LC DS has a client (runs in the Flash player) and a server component. This allows us to insulate application developers from data communication and pluming details, thus allowing them to focus on the application rather than the infrastructure.

Here are some examples of things developers don’t have to worry about:

1. Object instance management - The Flex application has multiple UI components that may display a single object instance. How do you ensure that you maintain one version of the object across the application? Wouldn’t it be ideal to have one instance on the server no matter how many users are using your application?
   
2. Retrieve the object once from the server - Most applications retrieve objects from the server as necessary. What would it take to ensure that a Flex client retrieves an object once and uses it through out the lifetime of the user session? How would your application handle if the object you are using is modified by another user in the system?
3. Change Management – As users of your application makes changes, data related to the entire object is sent to your server (mainly because your server has no knowledge of data with out retrieving it again from the source). How fast and efficient can you see your application become if you could just send changes (not entire object data) to the server? How about sending these updates from the server to your flex clients exactly the same way (only changes not entire object data)? How about sending updates only to users who are currently using this data?
4. Conflict Management – You don’t want to read this part if you application is going to be used by only one user at any given time, this is just not relevant. If not, what happens when you try to change data that has already been changed by someone else? Wouldn’t it be useful if the server could detect conflicts and provide you options to fix it?

Folks, what I describe above is a brief description of data management in LC DS. Check out Christophe’s blog for some really cool demos.
Note: As a bonus you can also generate PDF’s and create Flex portlets

We will soon be annoucing details of Blaze DS and LC DS to support REST in addition to AMF!!!

Why is this important?

1. You can now migrate your application in stages – no need for a big bang approach
2. You can create applications that can have Ajax/HTML and Flex UI to coexist
3. The same business logic gets used from Flex and HTML/Ajax

Watch out for more information on this. Meanwhile, I would like to hear what you folks think about this.

2 reasons

Reason 1: Remoting = Faster performance

Flex enables applications to communicate with the server over AMF, a faster binary alternative to String encoding. If your business logic is available in Java, Blaze DS offers Remoting that enables Flex applications to direct communicate with your business logic over AMF.

Note: The fundamental difference between flex applications and web application is that you don’t generate your presentation logic on the server. The communication between the Flex client and your server (Blaze DS) is primarily data. Hence your application performs much faster than a typical web application.

Reason 2: Messaging = Live Flex Applications

The request response nature of HTTP makes it very challenging to create web applications that are not static with out any user interaction. Remember when you watching NFL (any sport scores) on the Internet, your screen updates every 2 minutes to get the latest scores. It is annoying and inefficient. Blaze DS offers a messaging infrastructure that enable you to build server applications that can push messages to Flex Application. Flex applications using Blaze DS don’t have to blink anymore.

To top it, Blaze DS is Open source and Free to use in production