CF –> Adobe CF 7+ works but 8+ has LCDS baked in. No Railo/BlueDragon/etc.
LCDS –> middleware app designed to move data
Flex –> 2.0.1+
Data –> any serializable data including DB, LDAP, email, FTP, mapping software, web services, etc.

LCDS – expensive? yes and no.
BlazeDS is light, open source version without data management
LCDS ES – J2EE app that Adobe sells that includes all the features of BlazeDS, plus DM, NIO messaging, etc.
LCDS ES Single CPU License (was Express Edition) – free version that works on 1 CPU and will not cluster. Can be used for dev/testing/production environments. based into CF8 download. MSU has done 3-400 clients on this free version.

Flex SDK “Next” will be offering client side data management. Why should I care?
great for small data but not much else.
no data sync, data caching, or conflict resolution

Data Management
pass data to LCDS and let it handle passing it to the client. You can control how it passes including pagination and data sync.
LCDS assumes its the only one interacting with the DB.

Data Messaging
allows flex clients to communicate with each other without tying up resources on the app server
over TCP, HTTP polling, etc.

Data Proxying
you can proxy your web sevice or remoting calls through the LCDS to help get around restrictions in firewalls and policies

Example of data management
2 clients. change data on one and see the changes on another. reduce the chances of clients having conflicting data. Revert is built-in with hardly any code.

Coding the Flex Side
create a new collection to store the data
create a value object so the data serializes properly
utilize the DataService MXML tag and call the fill function

Why it works?
data is packaged up into value objects or packages of data
each VO is tracked separately as to who is viewing, editing, etc.
users then subscribe to a set of data
LCDS will ‘listen’ to any changes made to the data in the client
if the collection that holds the data is changed, LCDS will take change, change VO in memory, send change to app server and update clients
when an update is sent to other clients, it will check its local copy to make sure it hasn’t changed. if it has, it will issue “conflict” event and allow the client to choose.
on the client, 95% of work is handled by collection class
handles updating LCDS with changes and notifying other visual components of the change
when a dataGrid broadcast the change event, the collection hears, updates its own data and passes on the change.

Blackbox of LCDS
config files in wwwroot
master is services-config.xml
other files include channel info (services), messaging config (messaging), DM (data-management) and flash remoting (remoting)

Channels
Default Channels:
my-cfamf –> does AMF endpoints. binary over HTTP. firewalls might break it but normally a good way to go.
cf-polling-amf –> works well with nasty firewall. every X seconds ask server if there is new data
air-rtmp (Nick will provide downloads) –> direct connection through tcp socket which stays open. offloads some i/o from your application server. port 2050
cf-rtmp –> port 2048
port range recommendation: typically stay around 2048. that is registered by Adobe for RTMP. above 1024 because below that is well defined ports. it will all depend on the client firewalls.

Destinations
a destination needs an endpoint which is used to encapsulate your data based on server.
multiple channels are allowed as fall backs. if the first is not available, the next in the list is used after a “reasonable amount of time”. limit of 16 channels.

Properties
component: cfc that does the data handling
scope: how long the data lives
access: remote (default) corresponds to the access of the cfc
property-case: change the case of functions/variables
metadata: identity – normally ID of the table ie PARKNAME, query-row-type – path to value object

Documentation in default file contains all the options/values.

Lots of channel options
AMF typically run over HTTP. Tend to be slower or designed for one time polls and can be combined with HTTPS.
RTMP typically run over 2048. real-time, quick, easy but firewalls have been known to block on occasion.

Don’t worry about selecting a single channel. Normally RTMP and then polling is a good option.
Each destination can define channels which it wants to use
Each destination is just a name but must be unique to the server.

CF Fun!
final part of this puzzle is the CF side. could be any language by why?
traditional CRUD
fill() – think of this as the get all
get() – this is to get a single item
sync() this performs create, delete, and update
count() – this needs to return the number of records for pagination, finding updates, etc

Unsolicited Updates
one of the coolest features is the fact that you can push unsolicited updates to clients
examples: non-flex client update data, customer buys something from your store, or new email comes in

Creating unsolicited updates
3 easy steps:
create event gateway of type “DateManagement”
create some sort of VO
pass this VO to the event gateway – the update will be pushed to your clients.

With FB/RDS, there is a wizard for creating the value object/cfc. Flex 4 will include more wizards.

Examples of uses:
CRUD for DB
Directory watcher
collaborative doc management
email client
collaborative GIS app

Intro to LCDS
consists of: flex messaging service, flex data management, flex proxy service, and remote object service

Push vs Pull
pull is client asks server for data
push is server actually pushing data to client

Types
Simple AMF – stateful approach
RTMP – real time messaging protocol
maintains persistent connection
allows real time
uses java-nio facilities
Polling
flex client sends requests for messages periodically

Configuring channel/destination
-CFGateway: messages sent between cf8/flex
-JMS Adapter: allows to use both JMS/Flex clients to communicate
-AS Adapter: flex default allows only flex clients to participate in communication

Channels
my-cf-amf
cf-polling-amf
cf-long-polling-amf
cf-streaming-amf
cf-rtmp

Examples using LCDS (chat) and then CFGateway (Facebook notifications)