In the last two issues of Wireless & Mobile UPDATE, I introduced wireless push technology and Short Message Service (SMS). In this issue, I address UP.Link Alerts.
The wireless market in the United States has been slow to accept Wireless Application Protocol (WAP) technology, although WAP is now available on the latest devices from Cingular, Nextel, and VoiceStream and its use will continue to increase. The vast majority of wireless Web phones used in this country depends on Openwave's proprietary pre-WAP Handheld Device Markup Language (HDML) technology. The technology involves both UP.Browsers micro-browser and UP.Link servers, which act as the gateway. UP.Link Alerts, a feature of this technology, supports push alerts to UP.Browser-enabled wireless devices.
A critical advantage of UP.Link Alerts is tight integration of the push and pull mechanisms. An UP.Link Alert can be sent to the user's device with only a URL embedded in the notification. When the user selects and opens the message, the device initiates a data-browse session, pulling the message from the server.
Consider, for example, using the alert mechanism with a stock-trading application. UP.Link Alerts could notify a user when a stock hits a particular price. When the user clicked "read message," the handheld device would request a Wireless Markup Language (WML) deck from the server, which would download the alert to the device. This deck would show the stock symbol and price along with options to buy or sell. After choosing an option, the user would select stock quantity and submit the trade. New devices such as the Ericsson r520 WAP1.2 device will be capable of such functionality.
So how do you implement UP.Link alerts? First, download and install Openwave's UP.SDK on the server that will send the alerts—usually a Microsoft IIS Web server or SQL Server. The UP.SDK offers a number of APIs (COM components) that can be used to send messages.
When the message is sent, it travels from the component over HTTP to the carrier's UP.Link Server. The UP.Link Server processes the message and delivers it to the user's device. As with SMS, if the user isn't available, the message is stored and delivered when the user returns to the Web.
The following example code calls the UP.SDK APIs to send UP.Link Alerts.
Set objAlert = CreateObject("Ntfn3Client.Ntfn3Client.1")
AlertTitle = "Trading Alert"
SubID = "972924405-298404_devgate2.uplanet.com"
URL = http://<server>/Alert_Trade.asp"
TTL = "260"
AlertType = "D---"
objAlert.NtfnSetHost("pn.mobile.att.net")
objAlert.NtfnPostAlert SubID,URL,TTL,AlertType,AlertTitle
Set objAlert = nothing
The code shows an instance of the UP.SDK Ntfn3Client object, defines the value of several parameters, sets the property of the NtfnSetHost parameter, calls the NtfnPostAlert method, and passes in the parameters. The NtfnSetHost is the URL of the UP.Link Server. The SubID is the Subscriber ID of the device, the URL is the location of the alert message, TTL is the Time To Live (i.e., amount of time the alert will be stored for delivery before being deleted), and the AlertType contains preference information about the type of alert to be sent.
UP.Link alerts have multiple uses. But until WAP devices become more common in the United States, wireless push applications might be the most practical use of Up.Link Alerts.
In the next Wireless & Mobile UPDATE, I'll discuss WAP push specification, a forthcoming technology for delivering wireless alerts. Several readers have written with questions and suggested topics. I'll do my best to address them in future columns, and I continue to welcome your ideas and queries.
