Many portable devices let mobile users send and receive e-mail over a wireless network. These portable devices include Short Message Service (SMS)-enabled devices, two-way pagers, cellular phones with e-mail service, and portable networked laptops or Personal Data Assistants (PDA) with e-mail.
Although these devices can send and receive e-mail messages, they cannot yet access and run Web applications and Web services. The Web application client is the predominant browser.
However, as these portable devices become increasingly popular, using their e-mail capabilities to access the growing number of Web services and Web applications becomes increasingly beneficial. In this article, we detail an e-mail user interface that can interact with a Web application in a similar manner to that of a Web browser.
In the architecture we propose, the Hypertext Markup Language (HTML) model combines with e-mail technology by routing incoming e-mails to a Web application server. The Web application server parses and processes the e-mail messages and sends a formatted e-mail response back to the user. Figure 1 illustrates an example architecture.
Figure 1. Infrastructure diagram
In this architecture, we maintain a persistent session for each e-mail thread so we can keep state information on the server between e-mails. The system sends a reference ID in the e-mail subject along with a text message and a set of choices. The user receives this e-mail on a portable device and sends a reply with a selection. The response e-mail's subject field still contains the reference ID, which allows the e-mail processor to load the appropriate state information for this session. The e-mail then processes according to the user selection.
The user can start a new session by sending a generic e-mail. Because the starting e-mail does not contain a valid reference ID, the server creates a new session and sends a menu of starting options back to the user. In Listing 1, the subject field contains the reference ID:
Listing 1. Start a new session
To: johndoe@abc.com
From: www@ibm.com
Subject: Your order #234
Body: Your order has been...
|
Note that alternative implementations could store the reference ID elsewhere, such as in the "From:" address field (in this case, www234@ibm.com) or in the e-mail header's referrer field. The e-mail processor is likewise implemented to extract the reference ID from the proper location.
When an e-mail processor sends an e-mail, the system stores the e-mail session information in a hashtable, database, or other storage type. You can retrieve the session using the reference ID as the lookup key. The session information consists of one or more name/value pairs and includes options to execute when a user receives the reply e-mail. Consider Listing 2:
Listing 2. Retrieve a session
To: johndoe@abc.com
From: www@ibm.com
Subject: Review Meeting in 10 min #349
Body: Your Review Meeting is in 10 minutes.
Options:
1=cancel
2=notify that you will be 10 min late
3=20 min late
4=reschedule
|
The session information saved for Listing 2 would be:
Stored session information
| Reference ID | Name | Value |
| 349 | eventName | Review Meeting |
| 349 | option_1_cmd | cancel_meeting |
| 349 | option_2_cmd | notify_late |
| 349 | option_2_var | delay |
| 349 | option_2_value | 10 |
| 349 | option_3_cmd | notify_late |
| 349 | option_3_var | delay |
| 349 | option_3_value | 20 |
| 349 | option_4_cmd | reschedule_meeting |
Suppose John Doe responded with "2." Then www@ibm.com would receive the following e-mail:
To: www@ibm.com
From: johndoe@abc.com
Subject: Re: Review Meeting in 10 min #349
Body: 2
|
Once a user receives a message, the system removes the message's session information. This prevents additional replies to the same message. The server compares incoming and outgoing e-mail addresses to ensure that a user receives a message from the same address to which he or she sent it. You can further enhance security by digitally signing or encrypting the e-mail messages.
A timeout is associated with each session and can be individually adjusted for each ID. If the timeout expires before the system receives an e-mail reply, the system closes the session by removing the session information from the storage. If the system receives an e-mail with an invalid or expired reference ID, it returns the default main page with a new reference ID. The e-mail processor also verifies that the incoming e-mail's address is from a known user before processing it.
The e-mail processor extracts the reference ID from the subject and then retrieves all session information. Based upon the response of 2, the command for option 2 notify_late is called with an argument of 10. The system might access the same command object from a Web page containing an HTML form. Here is an example of the arguments in an HTML interface:
...
<FORM name="late" action="..." method="post">
<SELECT name="delay">
<OPTION value="10">Notify that you will be 10 min late
<OPTION value="20">20 min late
</SELECT>
<INPUT type="hidden" name="eventName" value="Review Meeting">
<INPUT type="hidden" name="cmd" value="notify_late">
<INPUT type="submit" name="notify" value="Notify">
</FORM>
...
|
Sharing server-side business logic
Developers can reuse server-side command objects across the Web and e-mail interfaces. Both the e-mail processor and the Web dispatcher route incoming requests to the same set of command objects, along with the session state. The command object performs the appropriate action on the session state and then exits. If you're using e-mail, the e-mail processor invokes an e-mail response formatter to generate a reply and then sends out a response e-mail back to the user. If you're using the Web, the Web dispatcher routes the result to a JSP for display on the browser client. Figure 2 illustrates the programming model.
Figure 2. Programming model
In an integrated solution that supports both e-mail and Web interfaces, the business logic must communicate with the e-mail server. Many existing e-mail servers do not support event notification when a user receives new e-mail. To utilize mail services interactively, you can implement periodic polling of the e-mail server to check for new mail.
Most Web servers cannot initiate periodic timed events. However, an external timer application can trigger such an event by making a Web service call every 10 seconds, for example. The Web service can check for new e-mail messages and process them accordingly.
The timer application can also send e-mail notification for scheduled appointments. The external timer application triggers this event; however, it might only do so once every minute. This Web service then checks if any appointments require notification and sends the appropriate e-mail. Figure 3 illustrates the external timer application receiving e-mail.
Figure 3. Receiving e-mail
The ideas we propose here detail a system for creating an e-mail user interface that accesses Web services and applications in a similar manner to the mechanisms used by standard Web browsers. Moreover, the system supports a persistent session state and reusable command objects that allow access from both e-mail and traditional Web interfaces. Web service developers can keep this in mind when they design an application inclusive of users with e-mail-capable pagers or cell phones.
- Learn about new software and programs related to Web Services on IBM's Web Services page.
- Vivek Malhotra's "Introduction to SMS" (developerWorks, June 2001) will help you get started with Short Message Service.
- Naveen Balani's "Deliver Web Services to Mobile Apps" (developerWorks, January 2003) shows you how to access Web services using J2ME-enabled mobile devices and the kSOAP library.
Bryce Curtis, Ph.D., is an senior engineer at IBM Austin, Texas. Dr. Curtis has a BSEE from Case Western Reserve University, an MSEE from Florida Atlantic University, and a Ph.D. in Electrical Engineering and Digital Signal Processing from Georgia Institute of Technology. Since joining IBM in 1984, Dr. Curtis has been involved in telephony application development, speech recognition and text-to-speech, virtual reality, and 3D audio. Currently, Dr. Curtis is a member of the IBM Software Group Technology Center, which involves defining IBM's software strategy in the areas of object technology and Web-based computing.
Jim Hsu is a member of the IBM Software Group Technology Center in Austin, Texas. Mr. Hsu received his bachelor's and master's degrees in electrical engineering and computer science from MIT. He is interested in technologies with immediate widespread impact and has worked on the development of Java programs that involve the Internet.
