2 min overview – LCDS
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.
| Version | Features | Details |
|---|---|---|
| 2.6 | NIO Channels, RTMP, Quality Of Service | RTMP - A high performance and scalable protocol. Unlike HTTP, RTMP maintains a dedicated socket connection from the client to the server. The same connection is used for data push and handling request and responses NIO Server – This is a java new I/O based socket server that supports both HTTP and RTMP. Quality of Service – Provides controls to control the messages pushed to clients |
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:
- 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?
- 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?
- 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?
- 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
[...] 2 min overview – LCDS (from Anil Channappa’s Blog) [...]
Flex Monkey Patches » Blog Archive » Rubbernecker’s Review - Week 21
November 18, 2008 at 10:57 am