Building the server side of the Tour de Flex real-time dashboard
Modified
6 July 2009
Requirements
User level
Beginning
Note: Content on this page first appeared in the author's blog on May 26, 2009.
Greg Wilson and Damien Mandrioli are also blogging about the new Tour de Flex real time dashboard today. Greg is the inspiration behind everything "Tour de Flex", including the idea of the dashboard. He has the story behind the genesis of this project on his blog. Damien (from IBM/ILOG) did a fantastic job at building the client-side of the dashboard using the very cool ILOG Elixir components, and he walks you through the details on his blog.
My contribution to the project is the "real-time messaging" infrastructure. I provide the details below.
First the overall workflow…
The reason we are combining PHP and Java in this workflow is mostly historical. In the initial version of Tour de Flex, there was no Java involved: Greg was persisting loaded samples data (sample id and timestamp) directly from his PHP page. We later added LiveCycle Data Services to the picture to support the data push requirement of the dashboard, and we took the opportunity to move some code (such as the database persistence) from PHP to Java. Note that we are using LCDS for the performance and scalability of its high-end channels, but the application could also be deployed on BlazeDS.
A more straightforward architecture would be for the client to communicate directly with LCDS. For example, the client could invoke a remote object that would directly publish the loaded sample data (sample id and geolocation of the client) to the message destination. Alternatively, the client could use a Producer object to directly publish the message to the destination. Because some logic (such as geolocating the IP address and persisting the data) has to be executed at the server-side before routing the messages to the subscribed clients, you would have to write a custom message adapter if you used this approach.
We will probably streamline the workflow with one of these two approaches in the future, but in the meantime here is the source code for the servlet (logging and non-essential code removed for brevity):
package com.adobe.tdf;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Date;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import com.maxmind.geoip.Location;
import com.maxmind.geoip.LookupService;
import flex.messaging.MessageBroker;
import flex.messaging.messages.AsyncMessage;
import flex.messaging.util.UUIDUtils;
publicclass TDFServlet extends HttpServlet {
// Unique clientID for the message service
private String clientID = UUIDUtils.createUUID();
// The geocoding service
protected LookupService lookupService;
// A DAO to store sample requests in a database
protected SampleRequestDAO dao = new SampleRequestDAO();
// The LCDS message broker
protected MessageBroker messageBroker;
// The LCDS messaging destination where real time sample requests information is pushed
protected String destination;
publicvoid init() throws ServletException {
ServletConfig config = getServletConfig();
destination = config.getInitParameter("messaging.destination.name");
String path = config.getInitParameter("geocoding.database.path");
try {
// Load the geocoding database in init() to make sure we load it only once
lookupService = new LookupService(path, LookupService.GEOIP_MEMORY_CACHE);
} catch (IOException e) {
// We swallow the exception here. If the database is not available, the feed
// will still work but won't provide the location info.
}
}
protectedvoid doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
if (messageBroker == null)
{
messageBroker = MessageBroker.getMessageBroker(null);
}
SampleRequest sampleRequest = new SampleRequest();
try {
sampleRequest.setSampleId(Integer.parseInt(request.getParameter("sampleId")));
} catch (Exception e) {
String message = "A valid sampleId is required to process this request";
thrownew RuntimeException(message);
}
sampleRequest.setTimestamp(new Date());
String ipAddress = request.getParameter("ipAddress");
// Geolocate the IP address and add the info to the message
if (lookupService != null && ipAddress != null)
{
Location location = lookupService.getLocation(ipAddress);
if (location != null)
{
sampleRequest.setLatitude(location.latitude);
sampleRequest.setLongitude(location.longitude);
sampleRequest.setCountry(location.countryCode);
sampleRequest.setCity(location.city);
}
}
try {
dao.create(sampleRequest, ipAddress);
} catch (RuntimeException e) {
}
String subtopic = request.getParameter("subtopic");
if (subtopic == null) subtopic = "flex";
// Publish the message to specified destination and subtopic.
AsyncMessage msg = new AsyncMessage();
msg.setDestination(destination);
msg.setHeader("DSSubtopic", subtopic);
msg.setClientId(clientID);
msg.setMessageId(UUIDUtils.createUUID());
msg.setTimestamp(System.currentTimeMillis());
msg.setBody(sampleRequest);
messageBroker.routeMessageToService(msg, null);
PrintWriter out = response.getWriter();
out.println("<html><body>ok</body></html>");
}
}
The servlet is responsible for three things:
- Geolocate the IP address of the client requesting the sample. We currently use the MaxMind Geolocation API. The API is straightforward and the results seem pretty accurate.
- Save the information about the loaded sample in a database. We keep track of historical data to be able to support future data visualization projects.
- Publish the data about the loaded sample to a message destination. The servlet uses the Message Service Java API to directly push messages to the Flex destination (lines 97 to 104). Note that the same API exists for ColdFusion, so CF developers could use a CF page instead of this servlet to push messages to the client.
Channels
The messaging destination is set up to support different communication channels: RTMP, long polling, and regular polling. The client-side developer can decide which channel to use to communicate with the server. For example, if you wanted to use RTMP as the primary channel, fall back to long polling if the RTMP connection fails, and fall back to regular polling if the long polling connection fails you could set up your client-side ChannelSet as follows:
<mx:ChannelSet id="channelSet"><mx:RTMPChannel id="rtmp" url="rtmp://hostname:2037"/>
<mx:AMFChannel url="http://hostname/context/messagebroker/amflongpolling"/>
<mx:AMFChannel url="http://hostname/context/messagebroker/amfpolling"/>
</mx:ChannelSet>
More Like This
- Building a Flex application that connects to a BlazeDS Remoting destination using Flash Builder 4
- Project Hendrix: A call center Customer Experience Management solution
- Working with Doctrine 2, Zend AMF, Flex, and Flash Builder
- Building a Flex application that connects to a BlazeDS Remoting destination using Flash Builder 4.5
- Set up and build your first Flex and ColdFusion application – Part 3: Use ColdFusion and Flash Builder 4 to create an application
- Introducing the MXML and ActionScript languages
- Set up and build your first Flex and ColdFusion application – Part 1: Database setup
- Getting started with ColdFusion and Flash Builder 4 – Database, CFC, and data services setup
- Understanding Flex in the client/server model
- Set up and build your first Flex and ColdFusion application – Part 2: Generating ColdFusion components
