The electromagnetic spectrum buzzes with activity. Smartphones, wireless headsets, desktop computers, in-car navigation systems, GPS-enabled gadgets, and many more devices compete for bandwidth as well as our attention. I served as the lead software developer for a team that recently completed a demonstration of a real-time, pedestrian monitoring system at Sakura Matsuri, a major street festival in Washington, D.C. We chose PubNub as our real-time messaging backbone and this article will provide some insight into how we used PubNub and why it was the right platform for us.
The Project
Our project team, which included members from Traffax, Inc., Michael Belisle Design and Agile Media Ventures, was awarded a grant via the Reliability IDEA program, which is administered by the Transportation Research Board. The program (http://www.trb.org/IDEAProgram/IDEAReliability.aspx) funded proposals with potential to test innovative ways to improve the consistency or dependability of travel times, improve travel time prediction, and provide information to travelers and other highway system users when dealing with unexpected delays. A major goal of our project was to develop, implement and document a real-time pedestrian monitoring system at a large, outdoor event.
We approached the Japan-America Society of Washington, D.C., sponsors of the Sakura Matsuri Festival, the largest one-day display of Japanese culture in the United States. It's held each April as the climax of the National Cherry Blossom Festival. In years past, the festival has attracted well over 100,000 visitors in an area that covers several city blocks near the National Mall.
Technical Architecture
The technical architecture for our project consisted of five key elements:
- BluFax sensors
Sensors were deployed in strategic locations, primarily entrances/exits and performance stages, at Sakura Matsuri. The sensors listened for BluetoothTM devices that are set in "discover" mode and uploaded detected devices to the Data server.
- Data server
The Data server received packets of data transmitted by the BluFax sensors, did some limited processing, and forwarded them to the Messaging server.
- Messaging server
The Messaging server was the heart of the system. It's where all of the incoming data, both the raw, sensor-generated data and the data from external publishers described below, was transformed into more usable information. This information was then published via PubNub. In addition to serving as the primary publisher, the Messaging server saved the sensor data in MongoDB for post-event analysis.
- Data publishers
For our demonstration, we developed a mobile web application that served as just another publisher in our architecture. In addition, we developed standalone services (using node.js) that monitored social networking sites, such as Twitter and Flickr, and published related tweets and pictures to PubNub.
- Information consumers
We developed two interfaces that consumed and presented the data generated by the event. One was a web page that presented the data, most of which was geotagged, on a Google Map in real-time. The second was a visual dashboard that showed key performance indicators of sensor-related data.
As the lead developer, my role on the project was to create the software architecture to support the demonstration at Sakura Matsuri. The remainder of this article will focus on how PubNub was integrated in the last three components of that architecture.
PubNub served as the primary messaging backbone for our technical architecture. I developed a simple specification for how all messages should be formatted throughout our application. Once the team committed to the spec, we were able to integrate publishers and subscribers very easily, across a variety of locations, platforms and technologies.
The standalone services we developed to monitor Twitter and Flickr for posts related to the event, either by tag or geolocation information, used the standard node.js libraries provided by PubNub to publish tweets and pictures. The web page (shown below), which showed a Google Map of the event with custom overlays that were based on data it consumed, included the standard JavaScript libraries that were hosted by PubNub via its content delivery network (CDN).
Figure 1: Main Web Display
The mobile web application, developed with PhoneGap, included a function which simulated a parking garage that updated festival attendees on the number of spaces available for patrons. Instead of spending our limited resources building and maintaining a fast, robust and scalable messaging infrastructure, PubNub allowed us to focus our energy on integrating several varied sources of data and building creative ways to present the information.
I explored several messaging options before settling on PubNub. My goals were to build something quickly using node.js, host it in the cloud, and support our "bursty" traffic load without getting bogged down in managing multiple servers and services. The first option I looked at was building our application on top of Socket.IO, a terrific library developed by Guillermo Rauch, a superstar in the node.js community. While Socket.IO is a solid library, we didn't have the time or development resources to build up the necessary infrastructure to host, manage and tune a server running Socket.IO.
At the time I was considering various options, the primary (commercial) competitor to PubNub was Pusher. While there is a key technical difference between the two services - PubNub uses HTTP streaming/long polling while Pusher uses websockets - for our use case, the base feature set and pricing offered by both were pretty similar. Since I had already hacked together a quick-and-dirty prototype using the tutorials, documentation and libraries provided by PubNub, it made the most sense to stick with PubNub.
One key benefit of PubNub now is the availability of data centers worldwide through its Multi-Region Deployment add-on. As we look to deploy our solution across the U.S. and internationally, having a technology partner who has a global presence, will be a critical success factor.
In the end, I was very happy my choice of PubNub. Their feature set and customer support were key factors in my success.
Conclusion
Our demonstration at Sakura Matsuri went extremely well and was well received by the sponsor as well as curious attendees. If you're interested, you can watch a short video documenting our project here, http://vimeo.com/50101608. Now that the event is over, I've had an opportunity to sit back and take a hard look at what we accomplished and the role that PubNub played in our solution. Here are a couple of things to keep in mind if you're evaluating PubNub as a real-time messaging component for your solution:
- Channels
For our demonstration at Sakura Matsuri, we did not take advantage of segregating messages via channels. One benefit of incorporating channels is that subscribers could decide which types of messages they were most interested in receiving. Traffic and parking messages would be useful to those driving to the event, but less helpful to folks taking public transportation.
- Latency
PubNub is fast. While a comprehensive performance analysis is beyond the scope of this article, let's just say that there were plenty of other components that were part of the overall architecture that were much slower than PubNub.
- Customer Support
For paid customers, PubNub offers 24x7 phone support and a service level agreement (SLA). As it turned out, I did have to call PubNub support on the day of the event. Like any good developer, I decided to modify code at the last minute (!) and wound up breaking something that had worked previously. I spoke to a PubNub customer support engineer, and he addressed my issue quickly and completely.
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
