In the past two Wireless & Mobile UPDATEs, I've written about Short Message Service (SMS) and UP.Link Alerts, technologies for delivering wireless push applications. In this issue, I'll continue the topic and take a closer look at the Wireless Application Protocol (WAP) Push framework.

Like UP.Link alerts, WAP Push lets wireless applications integrate both wireless data push (notifications) and wireless data pull (browse) functionality. WAP 1.2 and above include the WAP Push framework; in mid to late 2001, newly released Ericsson r520 and Nokia 6310 phones will include this functionality. With so few WAP Push-enabled devices available, the broader market might be slow to implement WAP Push applications. If you have specialized enterprise applications such as wireless sales automation, however, these specific devices will let you deploy WAP Push.

WAP Push Framework
The WAP Push framework's functionality closely resembles that of UP.Link Alerts. So why use WAP Push instead of UP.Link Alerts? The WAP Push framework is an industry standard; carriers around the world are releasing WAP-enabled devices. UP.Link Alerts technology, however, applies primarily to the US market. WAP Push also offers superior security that prevents wireless spamming—unauthenticated message delivery—because the user must subscribe to a WAP Push service to receive messages.

The WAP Push framework describes all the protocols, services, and interfaces that let a WAP device receive messages. I can't cover all the features and protocols of the WAP Push framework here, but I'll include a few terms and some code to help you understand how to send messages using WAP Push. In summary, the message is sent from a Push Initiator (Internet server) to a Push Proxy Gateway (PPG) using Push Access Protocol (PAP). The PPG then delivers the message to the WAP-enabled device using Push Over-the-air Protocol—as long as the appropriate message authentication has occurred.

How WAP Push Messages Work
WAP Push messages work in two primary ways:

  • Service Indication Content Type pushes a notification of the message to the WAP-enabled device, the user responds, and the user's device then retrieves Wireless Markup Language (WML) content from the Internet server.

  • Service Loading Content Type pushes WML content directly from the server to the WAP-enabled device.

    Service Indication Content Type sample code follows.

            <?xml version="1.0"?>
       <!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"
       "http://www.wapforum.org/DTD/si.dtd">
       <si>
       <indication
       href= "http://<server>/mystocks.wml"
       si-id= "cust-msg-num52"
                       created= "2000-03-31T15.28.19Z"
       si-expires= "2000-03-31T23.59.59Z"
       action= "signal-medium"
       View your stocks now?
       </indication>
       <info>
       <item class=MoreInfo>
       Your last update was Tuesday at 3 PM.
       </item>
       </info>
       </si>

    In the example above, the XML 1.0 document would be sent from the Push Initiator to the PPG and would require software on the Push Initiator to perform the authenticated action. The user receives only a short message on the wireless device: "View your stocks now?" The user could then select OK, and the "mystocks.wml" page would be loaded in the WAP micro-browser.

    In the next few years, I expect the WAP Push framework to become an essential part of wireless applications. For now, use UP.Link Alerts in the United States to get similar functionality. When WAP Push becomes available, however, use it to implement applications with a standardized approach.