WAP Push Framework Overview

Required background

Before using this component, you must understand ECom Framework and Open Mobile Alliance (OMA) standards.

Key concepts and terms

Push message

WAP push messages are specially formatted SMS messages that display an alert message to the user, and give the user the option of connecting directly to a particular URL through the mobile phone’s WAP Browser; for example, notification about a new email.

A push message has a header section and a body section. Header section has X-Wap-Application-Id and Content-Type fields. The message body can be any MIME content-type and optionally encoded. When a push message is received, the framework parses the message header and loads an appropriate plug-in to process and store the message in a Message Store.

Push plug-in

The handler (plug-in) supported by the framework are known as Push plug-in, such as Application Handler or Content Handler.

Architecture

WAP Push Framework provides support for connectionless (CL) OTA-WSP push.

The main components of the framework are Push Watcher, Application Handler and Content Handler. A Push Watcher is a plug-in that plug-in to the Messaging Watcher Framework and is responsible for listening on the WAP Stack for incoming push messages. Push Watcher after receiving the message, loads an appropriate Application Handler through Application Dispatcher. An Application Handler is responsible for loading the appropriate Content Handler using the X-Wap-Application-Id value contained in the received push message. The content handler is responsible to handle the push message and take any action on the message that may be necessary. However, if a plug-in for a given content-type is not available, the WAP Push Framework uses the unknown application handler plug-in (default) and discards the push message.

The following figure shows the architecture of WAP Push Framework.

Figure 1. WAP Push Framework Architecture

Push Watcher

There are two Push Watchers in the framework for CL OTA-WSP—one is for secure push and the other is for non-secure push. The insecure CL watcher is always active and waits asynchronously to receive message from WAP Stack at port 2948. On receiving a push message, the watcher wraps the message up in a CPushMessage, parses the message and calls the Application Dispatcher, passing in the X-Wap-Application-Id value obtained from the push message.

Dispatchers and Handlers

The framework contains an Application Dispatcher and a Content Dispatcher that are used to find the appropriate Application Handler and Content Handler respectively.

Application Dispatcher uses ECom to load an Application Handler using the application-ID passed to it by the Push Watcher. Two different Application Handlers are present in the framework—Unknown Application Handler for applications of unknown type and User Agent (UA) Application Handler that receives messages of type ‘x-wap-application:* ’ or ‘x-wap-application:wml.ua ’. The UA Application Handler looks at the content-type of the message and passes it to the Content Dispatcher. The content dispatcher then loads an appropriate Content Handler. The Unknown Application Handler deletes the push message.

The Content Dispatcher uses ECom to load a particular Content Handler (plug-in) based on the content-type passed in by the Application Handler. The following are the Content Handlers provided within the framework.

• SI Content Handler: These plug-ins process Service Indication (SI) messages. An SI message is a UA message with content-type text/vnd.wap.si or application/vnd.wap.sic. The basic form of an SI message is a short message with a URI indicating a service; for example, notification about new emails.

• SL Content Handler: These plug-ins process Service Load (SL) messages. An SL message is an UA message with content-type text/vnd.wap.sl or application/vnd.wap.slc. The SL message contains a URI indicating a service which gets loaded without user input.

• Multipart-mixed Content Handler: These plug-ins process multipart-mixed messages. These are messages with content-type application/vnd.wap.multipart.mixed or multipart/mixed. They create new sub-messages from each message part, and load appropriate content handler plug-ins to process each sub-message.

• Multipart-related, Multipart-alternative Content Handlers: These plug-ins process messages for the application/vnd.wap.multipart.alternative, multipart/alternative, application/vnd.wap and multipart.related content-types. They save the entire message in the Message Store, where each part is saved as a child entry to the main part.

• Unknown Content Handler: These plug-ins process content-types for which there are no handler plug-ins. They store the received push messages in Inbox of the Message Store.

APIs

Typical uses

WAP Push Framework is extensible, that is, new plug-ins can be installed to the framework and installed plug-ins can be removed from the framework without re-building the framework. It uses dynamically loaded plug-ins at run-time to support different content-types; for example, content of push message for Service Indicator (SI) application. ECom Framework is used to provide support for run-time loading.

• Creating content handler plug-ins.

  Note: Push plug-ins must inherit from the base push plug-in class and override a set of pure virtual functions.

• Removing any installed plug-ins.