Data Synchronization Visualization
Among the many valuable features of Adobe Flex Data Services is the ability to keep client-side applications in sync with their appropriate data-structures on the server. While this generally means relational databases and lists or tables of data on the client, it doesn’t always have to be that way. I recently came across an interesting scenario, which afforded me the luxury of building an application that represented client-side data outside of a list.
You can pick any number of potential uses for this type of scenario. Maybe there’s a police chase and in which the movement and history are being tracked and analyzed in a database. Maybe the aircraft in your fleet are reporting their position and you want to see all those aircraft as icons on a map, in real-time as they report. Maybe you’re a mission commander evaluating field readiness and you need to know where combat assets are located at this very moment.
The bottom line is that some object is being tracked and its location needs to be monitored in real-time across any given number of client applications.
The downside to being able to develop something like this is that I don’t actually have anything reporting to a server. No information is being stored in a database and the only person who needs to know about it is me. In order to simulate this, I built two separate applications.
The first application acts as a viewport into data that will change over time. It does little more than show where everything in the database is located. It also summarizes the view, telling the end user how many items are reporting, when the last report arrived at the client and offering the traditional tabular display of data as an alternative view. I built a “map” component that shows the items being tracked as blue dots.
The second part of the application leverages the exact same “map” component for the purposes of being able to visualize the data, but it also acts as an emulator that causes data to change. There’s a timer control to dictate how often the data is being updated, and a numeric stepper to specify how many items should be reporting. For every iteration of the timer, this part of the application makes random changes to items being tracked. This forces an update in the database and subsequent propagation of the new values out the “viewport” applications.
The real bonus here is that thanks to Flex Data Services, all the synchronization happens automatically. Furthermore, changes to the data don’t happen by RPC calls to specific endpoints, but rather to client side data object in a collection. When the changes occur, Flex Data Services (FDS) automatically sends a list of the changes made out to the server. The server then synchronizes and/or commits those changes into a database, and propagates the changes out to all the clients.
From the developer perspective, there’s no need to know where RPC endpoints are located. There’s no need to invent a way for all the clients to check-in for the most recent data on a regular basis. There’s no need even to worry about network connectivity, or how the connection is made. Firewall? No problem, FDS can automatically failover to HTTP polling. The abstraction that FDS affords allows developers to focus on the visualization and in adding new features to the applications - and in turn not having to think about all the infrastructure and plumbing.
I’ve packaged this sample up and made the source available should you like to download it and see just how simple all this really becomes thanks to FDS. The example has been built on Christophe Coenraets’ recently released FDS Test Drive Server that’s based on Tomcat. You can download that tutorial, unzip the archive and be up and running with FDS in minutes. There’s no invasive installation or database configuration, just a single start-up batch file and tons of invaluable tutorials.
To add this example to the mix you’ll need to take a few additional steps as follows:
- Add the assetsdb.script entries to the db/flexdemodb.script file
- Note: The SQL statements in assetsdb.script need to be grouped with their respective statements in the flexdemodb.script file (i.e. CREATE with CREATE, ALTER with ALTER, and INSERTs at the bottom with the other INSERTs)
- Put the poc folder found in java/classes into the webapps/ROOT/WEB-INF/classes directory
- Copy the destination entry from flex/data-management-config.xml into webapps/ROOT/WEB-INF/flex/data-management-config.xml
- Put all the remaining files in the flex directory in a “map” directory in webapps/ROOT
At this point you can start the Tomcat installation as instructed in the tutorial (bin/startup.bat). You’ll probably want to open the manager view first which is the “manager.mxml” file you just put in the map directory. Then you’ll want to create a new browser window (or tab) and open the “viewer.mxml” file. As the manager application changes the data randomly, those changes are put into the database and propagated out the viewer instances. Don’t forget that the manager is a viewer too, leveraging the same “map” component as the viewer.