The WAP Forum Push Access Protocol
The WAP Forum has developed a protocol to push content to mobile devices using the estab lished WAP architecture. While the entire WAP framework for pushing notifications includes the service interfaces and software, the Push Access Protocol is the layer that communicates between a Push Initiator and a Push Proxy Gateway.
Note
While the Push Access Protocol communicates between the Push Initiator and the Push Proxy Gateway, a different protocol is used to communicate between the Push Proxy Gateway and the user's WAP device. That protocol is called the Push Over-The- Air Protocol (OTA). You won't need to know the specifics of this protocol to create push notifications, but if you'd like more information on this or any of the other concepts in this section, check out the WAP Forum's protocol specifications at http://www.wapforum.org/what/technical.htm
Before we get too far into the particulars of the Push Access Protocol, let's take a look at how it fits into the larger push notification system that the WAP Forum has developed.
A push notification must be triggered by some kind of event or action. Typically, that trigger will come from the Internet, which uses a different protocol than the end user's WAP device. How will the trigger event (technically called a Push Initiator), and the target device communicate? They do so through a Push Proxy Gateway. The Push Proxy Gateway (PPG) handles most of the real work in sending a notification, everything from security to authentication to binary encoding to confirmations with the Push Initiator regarding delivery.
Because the Push Access Protocol is the language used to communicate between the Internet and the PPG, and will be the most relevant protocol in actually creating notifications, we will cover four basic operations that can be sent to the PPG: push submissions, push cancellations, status queries, and client capabilities queries.
Push Notification Submissions
To submit a push notification to the Push Proxy Gateway, you need to submit a multi-part message with up to three separate components: the content entity, the control entity, and a capability entity (which is optional).
The simplest piece is a content entity; this is the content that you want the device to accept with the push notification. The control entity will contain the address for the push notification and must be in XML format. The capability entity is optional, and it can tell the Push Proxy Gateway what capabilities the target device has, so that the push notification may be best formatted for that device. The capability entity must be in the WAP User Agent Profile (UAPROF) format.
Push Notification Cancellation
After you submit the multi-part message push notification request to the Push Proxy Gateway, you can use an XML entity to cancel that submission. The gateway will send a response to the Push Initiator regardless of the success of that notification.
Notification Status Query
Anytime after the push notification, the Push Initiator can query the Push Proxy Gateway for its status with an XML entity.
Client Capabilities Query
The Push Initiator can query for the capabilities of a specific device on the network using an XML entity.