First off, hope you had a good 2009 and wish you a very Happy New 2010.
We were recently on vacation in India, as you probably guessed from my lack of postings last month. Apart from a week in New Delhi, where we did a bit of historical tourism, we stayed in Kolkata, visiting family and friends.
As everyone knows, India has made a tremendous amount of progress in the last few decades, and I am pleasantly surprised each time I go back. The last time I went, one thing that struck me was the ubiquity of the cell phone - almost everyone I met carried one, although usage was limited to voice communication.
This time around, I saw evidence of further maturity in this area. Our driver showed us how he could get our train reservation status on his cell phone, thanks to the Rail Info on SMS system developed by Indian Railways. The application is uniquely suited to the Indian market - most people have fairly basic cell phones, but SMS and WAP are usually always available. Of course, there are people who sport smartphones such as Blackberries and IPhones, but these are also SMS and WAP compatible.
Elsewhere, such as the movie theater where I was standing in line one day, they have opted for more traditional implementations - a web based booking interface which can be used from your home computer or from a smartphone with web access. There was also a solitary self-service kiosk, which IMO made very little sense in the Indian context, with its copious availability of cheap skilled manpower (to man another counter in the ticketing booth). As I stood in line, being pushed and shoved by other anxious patrons, I began to think of how easy it would be to extend the ticketing system to have an SMS/WAP interface, thereby allowing people to get on their cell phones and out of the line.
The diagram above shows the sequence of interactions between the client's cell phone and the booking system. It is described in a bit more detail below:
- init ticket booking: this is the customer sending a formatted SMS to the server, something like BOOK 3IDIOTS, where the first word is the command (BOOK) and the second is the code for the movie for which I want tickets.
- booking url: the server responds by sending a booking URL, which is a URL with the client ID as a parameter. If I have booked a ticket before with this system, it already knows my cell phone number and uses my client ID to track me. If it doesn't know me, it generates a new client ID and adds me to the database before sending back the URL. The URL is packaged as a system instruction (SI) so the phone knows to open the URL and retrieve the WAP deck from the server.
- send booking info: the customer fills in the WAP form and hits submit, which sends the information over SMS back to the server. If the customer is recognized, then information such as credit card number is prefilled for convenience. Some information has to be filled by the customer, such as show date, time and number of tickets. To minimize the chance of bad bookings, the WAP deck is built so that sold out shows are not available for selection.
- send confirmation: the server books the tickets if they are available, and sends back a confirmation to the customer. The confirmation number can be used to pick up paper tickets - since there is less human interaction required to pick up tickets, presumably this line will move faster and there will be less anxiety.
As you can see, the sequence of interactions is similar to that of a traditional web application over HTTP. The difference is that each request and response is asynchronous. Because of this, the system can scale to handle larger volumes, since the incoming requests can be queued on the server side.
Although I know next to nothing about SMS and WAP, I don't think it should be that hard to add this sort of interface to an existing web application. Of course, such an interface would have very limited usefulness in countries such as the US - most people carry smartphones with which they can just access the standard web interface. But in places like India, having a SMS/WAP interface can extend an application's reach quite dramatically.