In past Wireless & Mobile UPDATE columns, I talked about Wireless Application Protocol (WAP), Wireless Markup Language (WML), and many aspects of developing, deploying, and using WAP applications, all involving a type of wireless application functionality broadly categorized as data pull or browse. Data pull involves the user requesting a URL of the WAP application from a Web server, which returns content to the user as a HTTP/WAP response. The user can browse through the WAP content (deck and cards) to access specific information and/or accomplish particular tasks. Data pull requires the device to contain a WAP or pre-WAP Handheld Device Markup Language (HDML) microbrowser to request and interact with the data.
In the wireless world, you can use another technique to develop wireless applications. Data push, also called alerts/notifications, originated long before WAP, with 1- and 2-way paging networks and Short Message Service (SMS). Data push notifies a user, often by causing the target device to beep or vibrate.
The notification process can begin when someone sends a page or email to the device. The process can also start when an event occurs within a system or application that is set up to notify the user when that event occurs. Data push offers endless applications, but generally it's best suited to alerts or notifications of high importance in which the user must know about the event in a time-sensitive way.
A number of technologies can deliver alerts/notifications functionality over wireless networks: SMS, UP.Link Alerts, and soon, WAP push functionality. Over the next couple of Wireless & Mobile UPDATE columns, I'll explore in detail several ways to use the various push technologies—and some of the issues and limitations.
In the United States, personal communications services (PCS)/cellular carriers have implemented SMTP gateways for sending notifications to user devices. Thus, you don't need to worry about the particular technology; you just send an email to<subcriberid>@<smtpgatewaydomain> —for example, <A HREF="mailto:[email protected]">[email protected]</A>.
Upon receiving the message, the carrier SMTP gateway forwards it to the Short Message Service Center (SMSC) or UP.Link Gateway server for delivery to the wireless device. If the device is out of range or turned off, the carrier stores the message until the user returns to the network and then delivers the message. Two problems plague this use of carrier SMTP gateways: an often unacceptable time lag (latency) between sending and receiving messages, and the clutter produced by including the email header information in the alert message.
The two main notification-technology concepts are message originate and message terminate. In the United States, older cellular phones and one-way pagers employ only message terminate functionality, so they can receive messages but can't send them. All Global System for Mobile Communications (GSM) devices and two-way pagers, along with many other recent devices, let you both send and receive messages.
From an enterprise perspective, several wireless middleware platforms from Microsoft and other vendors can streamline notifications/alerts in wireless enterprise applications. In future columns, I'll consider various middleware platforms that deliver wireless application functionality.
The next Wireless & Mobile UPDATE will further discuss the use of push functionality with wireless alerts/notifications as well as look more closely at SMS, a key delivery technology for mobile application alerts and notifications.
