Mobile and Wireless Messaging

Messaging Basics

We begin by looking at some basics of messaging systems. The two areas of importance at this point are the differences between asynchronous and synchronous messaging, and between push and pull for message retrieval.

Asynchronous versus Synchronous Messaging

One of the fundamental benefits of messaging is its asynchronous nature. Asynchronous operations are nonblocking. This means that the sender of the message only initiates the operation, and does not have to wait for a response before he or she can continue working. If and when a response does appear, the application can then receive that message and respond to it appropriately. Even if the message takes some time to complete, the user does not notice the delay since he or she can continue to perform other tasks while waiting for a response.

This is the opposite of a synchronous operation, which blocks the process until the operation is completed. In these cases, the application is on hold until the operation is finished. Remote Procedure Call (RPC), a term used to describe the distributed computing model implemented by many middleware technologies such as CORBA, Java Remote Method Invocation (RMI), and Microsoft's Distributed Component Object Model (DCOM), is synchronous in nature. These technologies wait for a response before they continue. An example of synchronous communication is wireless Internet applications. Once a Web page is requested, users have to wait until the content comes back before they can continue working. This can lead to a poor user experience if the application is not designed correctly or if the network has high latency or low bandwidth. Unfortunately, both are common in today's wireless networks.

Asynchronous execution of messages is usually superior to synchronous execution, even on unreliable networks; that said, there are times when a synchronous response is required. An example would be an application that requires credit approval before making a purchase. You do not want to continue the purchase until the credit card is confirmed, thereby making synchronous messaging better suited for the task. The point is, when you are looking at implementing messaging within your applications, it may be worthwhile to determine whether you will need either synchronous or asynchronous messaging, and choose a solution that will provide the capabilities you require.

Push versus Pull

One of the common uses of messaging technology is to disperse information, such as notifying a mobile user when a specific event has occurred in the enterprise. The goal is for this type of notification to happen seamlessly, without user interaction. This is often referred to as push messaging. A message is pushed from the enterprise to the mobile user without the client having to request the information manually. In practice, rarely is the information actually pushed to the user without the client doing some form of check to see if new data is present.

Most wireless networks and devices do not support true push technology, but instead use a polling mechanism on the client device. Instead of users requesting new information, as they would in many smart client and thin client applications, the client application periodically polls the server to see if there is a new message for this client. If there is, it will then retrieve the message and react accordingly, often displaying some information to the application user. From the user's perspective, the information was pushed from the server, when in reality a pull mechanism was used.

Using this technique, you can enhance many smart client applications. When a new set of data is available on the server, you can initiate the data synchronization procedure from the server, allowing the data to be updated on the client device without the user having to constantly check for updates. For thin client applications, you can send out HDML notifications or WAP Push messages to notify users of new information, or link them to a wireless Web site that will be of interest to them. (More information on push messaging can be found in the sections "HDML Notifications" and "WAP Push" later in the chapter.)

Types of Messaging

In this section, we are going to take a look at each of the many different forms of messaging technology, giving an overview of how it works and where it fits into the development of the mobile applications. We start with the most common forms of messaging, such as email and paging, and work toward some of the newer and more advanced formats including WAP Push, instant messaging, and application-to-application messaging.

Email

When it comes to messaging, email is the killer application. This is definitely true for PC users and more and more so for mobile and wireless users. Every day, billions of email messages are sent; some users send and receive more than a hundred each day as a matter of course. Email has become the preferred means of communication for many companies, providing a quick and easy way to move information between users, often in the form of standard text or business documents such as Microsoft Word or Excel.

For mobile users, email is also a top priority. Many organizations implement email as their first mobile application, allowing users to get a feel for the mobile device and wireless connectivity before they implement other, more focused business applications. Companies such as Research In Motion (RIM) have built a strong following for their devices due to their capability to retrieve and send email messages. Many other companies have developed technology that enables mobile users to access their enterprise email accounts while away from the office. They provide server software that can integrate with common groupware infrastructure, such as Lotus Domino or Microsoft Exchange, as well as client software that can be used to access the messages. This client software is often available in both smart client and thin client formats.

Note

Since most readers of this book are familiar with sending and receiving email messages, this section provides only a brief overview of the components that comprise an email system.

Email systems employ store-and-forward messaging. That is, messages are stored in a repository until they are accessed by a client application, at which time they are forwarded to the user. The email client can be either a stand-alone client, such as Microsoft Outlook, Lotus Notes, Eudora, or Pegasus, or it can be browser-based, such as Microsoft Hotmail, Yahoo! email, or any of the other Web email offerings. Each of these client applications has to communicate with an email server to receive messages, and another to send messages. The two most widely used servers are the Simple Mail Transfer Protocol (SMTP) server, used to send messages, and the Post Office Protocol (POP) server, which stores incoming mail. The most recent version of POP is 3, which is commonly referred to as POP3. An alternative to using POP is the Internet Message Access Protocol (IMAP). IMAP is similar to POP in that it stores messages, but it accomplishes this in a more effective manner for users who want to access their email messages from multiple machines.

The process for accessing email from a mobile device is very similar. The only differences are the client application used to interact with the email servers and the type of attachments that are supported. For obvious reasons, some types of email attachments may not be supported from your mobile device, due to either size or format restrictions.

SMTP Server

When you send an email message from your client application, the email client will communicate with the SMTP from your email provider. This SMTP server will then look at the address to which this message is being sent and communicate with the SMTP server at the destination address domain (the part following the @ symbol). When the SMTP server at the destination receives the message, it communicates with the POP3 server at the same domain and puts the message into the recipient's account (the part preceding the @ symbol). From this point on, the POP3 server is used by the recipient to access this message. If, for some reason, the SMTP server at the destination domain cannot be reached, the email message will go into a queue, often called the sendmail queue. This queue will periodically try to resend the message to the destination SMTP server. If the message cannot be sent after a defined period of time, very often set at four hours, the sender may get a return message stating that it was not yet delivered. After a longer period of time, very often five days, the SMTP server will stop trying to send the message and will return it to the user marked as undelivered.

POP3 Server

The POP3 server is used to store received email messages. When users check their email, the client application connects to their POP3 server, providing an account name and a password. Once users are authenticated, the POP3 server allows them to access their stored email messages. The POP3 server essentially acts as an interface between your email clients and the data store containing your email messages. [For more detailed information on the mobile aspects of personal information management (PIM), including email, calendars, and to-do lists, see Chapter 16, "Mobile Information Management."]

Paging

One of the earliest forms of messaging to mobile devices was paging. Paging typically involves a caller dialing a telephone number associated with the intended recipient of the page. Once connected to the paging terminal, the person sending the page can enter a message that will be sent to the pager. The message can be either numeric, alphanumeric, or voice, depending on the system being used. When the message is complete, the paging terminal converts the message into a pager code and sends it to a series of transmitters to which it is connected. These transmitters then send out the message as a radio signal throughout the entire coverage area. Every pager within this area on the particular frequency will receive the message, but only the pager with the proper code (the intended recipient) will be alerted. In essence, the pager works much like an FM receiver.

The majority of pagers are used as one-way communication devices. When the user receives a message, that person responds either by calling the number sent in the page or by some other appropriate means. This is an effective way to alert people that you want to get in touch with them or have them carry out a task. Over the past few years, the capabilities of pagers have increased dramatically. Many of today's pagers provide two-way communication of various forms of data, ranging from short alphanumeric messages to wireless Internet content and email. While the underlying communication mechanism has remained the same, the client uses have become much more advanced. The most common two-way paging devices are the Motorola TimePort and RIM's BlackBerry.

Short Message Service (SMS)

The Short Message Service (SMS) was first introduced in Europe in 1991 as part of the GSM Phase 1 standard. Since that time it has had tremendous success, with more than 1 billion messages sent around the world daily. Though it continues to be more popular in European countries, SMS is catching on in North America as well, as more of the major wireless carriers add support for SMS and as SMS-capable devices start to proliferate in the marketplace. SMS is supported on digital wireless networks such as GSM, CDMA, and TDMA.

SMS makes it possible to send and receive short text messages to and from mobile telephones. The message can contain alphanumeric characters to a maximum length of 160 characters for Latin alphabets, including English, and 70 characters for non-Latin alphabets, such as Chinese. It provides an easy way for individuals to communicate with one another and with external systems. In this way, SMS can be used to turn a cellular phone into a pager. By adding the capability to receive short messages, users can receive the same kind of information that is typically received on pagers. This eliminates the need to carry both a pager and a cell phone, as SMS messages can even be received during a voice call.

Note

Even though the standard maximum length of an SMS message is 160 characters, many carriers have set their own limitations, which range from 100 to 280 characters.

New technologies such as SMS have gained widespread adoption because they offer compelling benefits to both the user and the network provider, such as:

• Guaranteed message delivery using a store-and-forward approach. Even when the recipient is out of the coverage area or does not have his or her device turned on, that person will still receive the message, though at a later time. Note, however, when a user does not retrieve the SMS message for an abnormally long period of time, the message may be removed from the system.

• Ease of use, without additional software or hardware. Sending or receiving SMS messages does not require a WAP browser. The ability to communicate using SMS comes pre-installed on the mobile device.

• Low-cost method for information delivery. SMS provides an alternative to making voice calls to deliver information.

• Revenue source for service providers. Network operators can deliver value-added services using SMS to generate revenue. SMS also helps drive the adoption of mobile phones to younger audiences.

It is estimated that close to 80 percent of SMS messages sent are consumer-oriented. The most common use is peer-to-peer communication, often replacing the need to make voice calls. Other uses include information services, such as stock and weather information, simple email access, and advertising. For corporate applications, SMS can be used for vehicle-positioning applications, job-dispatch services, and remote monitoring.

Unfortunately, when it comes to sending SMS messages from places other than another cellular phone, the process becomes more difficult. This is mainly due to the proprietary interfaces to each operator's short message service centers (SMSCs). you can see the route that a message takes as it moves from its origin to the destination mobile phone. Once the message is constructed, it is sent either over a wired connection or a wireless connection to the SMSC for that particular carrier. If the message originates from another mobile phone, the carrier takes care of the message delivery through the SMSC to the destination device. If however, the message originates from another source, such as an enterprise server, it is the enterprise's responsibility to communicate with the SMSC to have the message delivered. This is not a simple task, as most carriers do not expose their SMSC's APIs. In order to communicate directly with a carrier's SMSC, you either have to establish a relationship with that particular carrier and write to their proprietary interface, or use an aggregator that has established connections to the carrier or carriers you are interested in. The standard protocols used to communicate with SMSCs include Telocator Alphanumeric Protocol (TAP) and Short Message Point to Point (SMPP). (For more information about messaging aggregators, see the section entitled "Messaging Value Chain," later in this chapter.)

There is one other possible method to send SMS messages. Many carriers have made SMTP access available to their systems, allowing users to send SMS messages using an email interface. This usually involves sending an email message to an address containing the destination user's telephone number and carrier domain. For example, a message sent to an AT&T phone may have the address . When this message is sent, it is routed through the SMTP server to the SMSC, where it is then delivered to the mobile recipient over a wireless network.

Communicating directly with the SMSC does make it possible to retrieve the status of a message, which SMTP cannot. This comes at a cost, however, as there is usually a per-message fee for sending messages via the SMSC via a system aggregator.

The many benefits of SMS messages are easy to identify, but there are also some major limitations. The most serious of these is the 160-character maximum message length and the lack of support for more advanced data types such as audio and graphics. Another limitation is the lack of interoperability between network operators. The ability to send a message from one carrier to another has only recently been enabled by T-Mobile (formerly VoiceStream), AT&T Wireless, Verizon Wireless, and Cingular, thereby removing a major obstacle for SMS adoption in North America. Even with the cooperation between North American carriers, there are still limitations that need be overcome, including roaming outside of North America and the ability to encrypt the message content.

Enhanced Message Service (EMS)

The Enhanced Message Service (EMS) adds powerful new functionality to SMS. In addition to being able to send text, EMS allows users to send richer content, including pictures, animations, sounds, and formatted text. EMS can be added to existing SMS infrastructures, saving operators from having to make large investments to add these new features. This should help drive the adoption of EMS until more advanced messaging services, such as Multimedia Message Service (MMS) are rolled out in 2003 and 2004.

The following is an overview of the features introduced in EMS:

• Sounds and melodies. Users are able to send and receive either predefined sounds for such things as notifications or melodies to add new ringtones to the phone. It is possible to combine several sounds and melodies into a single message and to combine them with text and pictures.

• Pictures and animations. Users can send and receive predefined pictures that are included on the phone, as well as new pictures that they create or download from the Internet. Some phones may also contain the capability to edit the picture directly on the phone using a built-in picture editor.

• Formatted text. In addition to plain text, EMS makes it possible to format text. This may include changing font sizes; using text attributes such as boldfacing, italics, or underscoring; and changing text alignment. This feature will help to make news items and information updates more attractive.

• Concatenated messages. To help overcome the message size limitations, EMS allows for message concatenation. This can be accomplished directly on the mobile phone for both sending and receiving messages. This is very important for messages containing rich content, since EMS is still limited by message size as defined in SMS.

There is some doubt on whether EMS will truly succeed as a messaging standard. Ericsson is promoting it heavily, but other vendors, including Nokia, are not embracing EMS as warmly—for obvious reasons: Nokia has a competing messaging format called Nokia Smart Messaging, which the company is promoting until carriers and devices support MMS. The bottom line is that it looks as though SMS will continue to dominate for text messaging, and MMS will be the leader for multimedia content, leaving EMS with little hope for widespread adoption.

Multimedia Message Service (MMS)

The Multimedia Message Service (MMS) takes the capabilities of EMS one step further, adding true richness to the message content. In addition to the capability for pictures, formatted text, and sound introduced in EMS, MMS also provides support for voice, audio and video clips, and presentation information. This is accomplished in a manner very similar to SMS: providing automatic immediate delivery for custom content, as well as store-and-forward capabilities when the recipient is unable to receive the message. MMS also adds support for email addressing, so messages can be sent to an email address from the MMS client.

MMS has been standardized by both the Open Mobile Alliance (OMA) and 3^rd Generation Partnership Project (3GPP). OMA's MMS specification defines the message encapsulation and application protocols, while the 3GPP specification defines the network architecture and general functions. The transport for MMS is accomplished using WAP transport, making MMS bearer-independent, therefore not limited to GSM or WCDMA. This also makes it possible to use WAP Push features to deliver the message from the server to the recipient. (Note: For MMS to work, WAP 1.2 or above is required, although it will most likely be implemented alongside WAP 2.0 in many cases.)

To enable true multimedia content, the SMS message size limitation and the transport mechanism had to be discarded. And to avoid the problems encountered with SMS, and to enable future interoperability, no maximum size has been specified for MMS messages. This leaves the message size open to the implementation of each operator. That said, the message size will still be defined, but by the bandwidth and mobile device storage capabilities. It is expected that the first generation of MMS messages will typically be between 30 KB and 100 KB in size—a dramatic increase over the levels available in SMS. The obvious drawback to this message size is that many of today's wireless networks do not provide the bandwidth to support it. For this reason, MMS is a technology that requires 2.5G wireless networks, with a minimum bandwidth of 14.4 Kbps.

To help reduce the perceived wait times to download MMS messages, the MMS centers (MMSCs) use a store-and-automatic-forward mechanism to deliver the messages. The MMSC is a similar concept to the SMSC for SMS messages, whereby the MMSC can temporarily store a message for the time required to find the receiving phone. Once the receiving phone has been located, the message is immediately forwarded to the intended recipient and deleted from the MMSC. MMS messages cannot be sent without going through the MMSC. If the MMS message originates at an enterprise server rather than another mobile phone, the application developer will be responsible for integrating with the MMSC API to send the message. As with SMSCs, each vendor's MMSC will have its own API with which to interface, adding additional complexity. Unfortunately, unlike SMSCs that provide an SMTP interface, MMSCs are not expected to deliver this capability.

The first generation of MMS messages are laid out as slide shows. Each slide show will contain at least one slide, divided into two sections, one for text and the other for multimedia. The slides simply define the layout, while the actual content, such as video, audio, and text, are separate pieces sent along with the slides. These files are incorporated to the slide show using the Synchronized Multimedia Integration Language (SMIL). SMIL is an eXtensible Markup Language (XML)-based language specified by the World Wide Web Consortium (W3C); it is used to control the presentation of multimedia elements. Within the SMIL specification is a set of tags that can be used for defining images, text areas, and layouts. It is very similar to HTML, making it an easy transition for Web developers. (If you are interested in learning more about SMIL, visit for full detailed information on the SMIL 2.0 W3C Recommendation.)

Multimedia messaging on wireless devices is definitely of interest to many consumers and corporate users alike. Unfortunately, as of early 2002, only Japan's NTT DoCoMo was offering commercial MMS support on its 3G network. Trials are underway in other regions in Asia and Europe, but the lack of devices and suitable wireless networks is delaying its availability. In North America, adoption is even further off. There, SMS is just starting to catch on, and few users are willing to pay to download pictures and videos wirelessly when they can download them for free at home. It will still be a few years before MMS is available throughout the United States and Canada.

Instant Messaging

Instant messaging (IM) is well positioned to be the next killer application for the wireless industry. With the monumental growth rate of SMS, and more than 100 million desktop instant messaging users, the potential for wireless instant messaging is incredible. It provides similar capabilities to other two-way messaging technologies, such as paging, SMS, and email, with the addition of one significant feature: presence! Presence is so elemental to IM that this form of messaging is often referred to as Instant Messaging and Presence Services (IMPS).

Presence lets users know the current status of the people with whom they are conversing. This introduces a new way of communication. Presence information can include device availability, device capabilities, user status, location information, as well as personal information such as the user's mood. When a user wants to send a message to another party, he or she can first check the status of the intended recipient to make sure that person is available. Based on the presence information, the user may decide to send a message, try another means of communication, or simply wait until later. This is an important concept because instant messaging does not have store-and-forward capabilities. When a message is sent, it goes directly to the intended recipient. If that person is not able to receive the message, it is lost; it is not sent at a later time. This differs from how email, SMS, EMS, and MMS work.

Instant messaging has been available for fixed Internet users for some time and is very popular. Adding the mobile aspect to these services will enable users everywhere to communicate with one another, regardless of their type of connectivity. Unfortunately, before this can happen, and/or mobile instant messaging can meet its potential, the proprietary nature of the leading IM services will have to be resolved. Interoperability between IM services will be a key ingredient to its success. The leading desktop instant messaging services, such as AOL Instant Messenger, MSN Messenger, Yahoo! Messenger, and ICQ, do not allow for cross-service communication. Users can only communicate with others using the same vendor's product, resulting in many users having multiple IM clients on their PCs. In the mobile market, having multiple clients will not be an option, and in some cases, users will be required to use the IM service that comes preinstalled on their device.

Several mobile instant messaging clients are already available, including those from Microsoft, AOL, and Openwave, and the list is sure to grow. To promote interoperability, and in turn drive IM adoption, Nokia, Motorola, and Ericsson are involved in a joint effort called Wireless Village (which is now a component of the Open Mobile Alliance). Their goal is to create a set of standard specifications for handset makers and carriers to follow. This will enable all users to communicate with each other using instant messaging regardless of the device or carrier they are using. If successful, a user at his or her desktop will be able to send a message to a wireless user across the country with little effort, even if the recipient is using a different IM service.

The potential for mobile instant messaging is tremendous. As devices with always-on capabilities penetrate the market, the opportunity for IM will become even stronger. Some believe that IM will be the answer to the slow uptake of SMS services in North America, which would be a welcome relief for wireless carriers who are looking to capitalize on the growing messaging market.

HDML Notifications

HDML notifications were the first form of push messaging available to mobile Internet users. They allow for asynchronous communication, allowing the server to send relevant information to clients in a timely fashion—similar to SMS text message functionality. They are different from SMS in that they interact with the device's microbrowser. This interaction can take on many forms, including:

• Alert. A text message sent to the browser that will beep or display a visual signal to notify the user that new information is available. The alert will often contain a URL, which, if selected will load the URL's deck or page and display the content on the device's microbrowser. These notifications are often referred to as actionable alerts.

• Cache operation. These notifications can remove certain URLs or all URLS from the microbrowser's cache. This is done to prevent obsolete content from being viewed and enacted upon before the specified time to live (TTL) is reached. This type of operation can occur behind the scenes, without the user's involvement.

• HDML decks, images, and digests. These can all be preloaded into the microbrowser's cache to make interaction with the application more efficient.

To send one of these notifications, you are required to know the subscriber ID of the target device. If you do not have this information available, a script is available at that can help extract the subscriber ID. Once you know the ID of the device to which the message is being sent, you then need to interact with the carrier's HDML gateway. Methods of accomplishing this are covered in the "Mobile Message-Oriented Middleware" section later in this chapter.

There are two delivery channels for HDML notifications: the push channel and the pull channel. On packet-switched networks, all data transmissions are treated the same, allowing for push delivery of information, regardless of the size. Circuit-switched networks, on the other hand, use SMS to deliver asynchronous messages, preventing the HDML gateway from delivering messages that exceed the SMS message size limits. In all cases, the push channel is meant for delivering time sensitive material, using only alert or cache operations. The pull channel is better suited for data that is not critical, and for preloading content into the microbrowser.

Once an alert is sent to the HDML gateway, it is queued for delivery. The length of time it spends in the gateway's queue depends on the following information:

• For all push notifications and for pull notifications on packet-switched networks, the gateway will attempt to deliver the message immediately. If the destination phone is unavailable, the gateway will keep the message in its queue and reattempt to deliver it periodically. If the message TTL is exceeded, it will be removed from the queue.

• For pull notifications on circuit-switched networks, the message will remain in the queue until the destination phone opens up a circuit. At this time, the message will be sent to the user for viewing. If the message TTL is exceeded, it will be removed from the queue.

Any notification that is in the gateway's queue but has not been delivered is referred to as a pending notification. The sender of the notification can request to delete or get the status of any pending notification. The sender can also request the status of completed notifications. This capability is important for applications that require guaranteed message delivery.

HDML notifications provide a powerful way to push content to wireless users. In North America, where HDML is still widely used, these notifications are often the only option available for push services. However, because HDML notifications are a proprietary messaging technology developed by Openwave, they are only supported in Openwave microbrowsers. As HDML gateways are replaced by WAP gateways, and HDML handsets are replaced by WAP handsets, HDML notifications will gradually give way to WAP Push for push messaging capabilities.

WAP Push, first introduced in the WAP 1.2 specification, is the successor to HDML notifications. You will notice that its push capabilities and delivery channels are very similar to those used for HDML notifications. The main difference is that WAP Push is an industry standard for pushing content to WAP-enabled devices, defined by the WAP Forum. This allows for multiple gateway vendors, microbrowser providers, and wireless carriers to communicate using the same protocol, making it easier for application developers to create wireless Internet applications with push capabilities.

Architecture

depicts the WAP Push framework. Three parts of this framework are of interest to us:

• Push Initiator (PI). The PI is an application that pushes the content and delivery instructions to the Push Proxy Gateway (PPG). It typically runs on a standard Web server and communicates with the PPG using the Push Access Protocol (PAP).

• Push Proxy Gateway (PPG). The PPG does most of the work in the push framework. Its main responsibility is delivering push content to the WAP client. In doing so, it may have to translate the client address into a format understood by the wireless carrier. The PPG is also the location where messages are stored when they cannot be immediately delivered to the client. It also maintains the status of each message, allowing the PI to cancel, replace, and request the current status of a message. The PPG uses the Push Over-the-Air (OTA) Protocol to deliver push content over a wireless network.

  To send a WAP Push message, the PI must have two sets of information about the destination: the domain of the PPG and the client address. An arbitrary text string, such as an email address, can be used to identify the client. The PPG is then responsible for translating the string into a format that is understood by the mobile network.

• WAP client. The WAP client is typically a wireless device that contains a WAP microbrowser capable of receiving WAP Push content. This is where the user is able to view the content that was pushed from the PPG using the Push OTA Protocol.

The PAP has been designed to be independent of the underlying transport, making it suitable for any protocol that allows for the transport of MIME types over the Internet. Currently, HTTP is the only protocol specified as a transport, although new protocols may be added in the future. The content for a push message is specified using XML with a defined set of tags.

Within the XML document, the PI is able to communicate the following operations to the PPG:

• Push submission. Contains the push message itself.

• Push cancellation. A request to cancel a previously submitted message.

• Push replacement. A request to replace a previously submitted message.

• Status query. A request of the status of a previously submitted message.

• Client capabilities query. A request for the capabilities of a particular device on the network.

In turn, the PPG is able to respond to the PI with one operation: result notification. This response is an XML document that contains information indicating whether the message delivery was successful or unsuccessful. A successful delivery occurs only after the target application on the WAP device has taken responsibility for the pushed content. If it cannot take that responsibility, it must abort the operation, in which case, the PI will know that the content did not successfully reach its destination.

The Push OTA protocol is responsible for transporting the content over the wireless network from the PPG to the WAP client. It can run on top of either HTTP or the Wireless Session Protocol (WSP). The OTA-HTTP protocol is primarily used with IP bearers, while the OTA-WSP is used with WAP bearers.

Operations

The WAP Push specification adds three new MIME types for delivering WAP-specific content from the PI to the WAP client. These are supported in addition to any MIME media type that is already available. The following is a summary of each of these MIME types:

• Service indication (SI). Provides the ability to send notifications directly to end users. These notifications can contain information directly in the message or in a Uniform Resource Identifier (URI) that directs the user to a service, often containing WML content. When the user receives an SI message, he or she has the option of visiting the URI immediately or postponing the SI for later handling. Push messages that contain URI references are often called actionable alerts.

• Service loading (SL). Contains a URI that points to content loaded by the WAP client, without requiring user interaction. The SL also contains an instruction dictating whether the content should be executed immediately or placed in the cache memory. The PI is able to control the level of user intrusiveness of the SL message.

• Cache operation (CO). Removes individual objects or all objects that start with the same URI prefix from the WAP client's cache. This is typically used when the expiry times of the cached content cannot be specified beforehand.

Note, implementing SI is mandatory for clients implementing WAP Push. Both SL and CO are optional. These operations are very similar to those supported by HDML notifications.

FURTHER INFORMATION

A good source for more information on WAP Push is the OMA Web site at www.openmobilealliance.org. Here you will be able to find all of the specifications related to WAP and the WAP Push protocol.

Application-to-Application Messaging

Application-to-application messaging technology is different from all of the messaging technologies we have discussed so far. Rather than using standard client software, application-to-application messaging usually is incorporated to custom applications. This provides nearly unlimited flexibility as to the types of messages that can be sent and how messages are handled.

When implementing application-to-application messaging, the application on the mobile device is smart client in nature. This client application communicates directly back to the messaging server, without going through a gateway from the wireless carrier. This eliminates the requirement of having to communicate with SMSC or MMSC servers. Instead, the client application communicates directly to the messaging server—hence the name application-to-application messaging.

The vendor can choose the communication protocols to use, along with the compression techniques and security features. It is recommended that you select a solution that has addressed all of these issues and that has created a solution that is well suited for wireless communication networks. This involves using a suitable protocol, such as the User Datagram Protocol (UDP), that provides built-in message compression and integrated security, including data encryption and user authentication.

If you plan to deploy your messaging-based application to a variety of devices, it also is a good idea to look for a solution that features a messaging client for the mobile OS, device, and programming language that you will be using. This typically involves C/C++ or Java/J2ME support across the leading mobile operating systems, including Palm OS, Windows CE/Pocket PC, and Symbian OS. Java support is available for all of these operating systems, so native messaging support is not necessarily required.

Note

More information on developing smart client applications, with an overview of the mobile operating systems, is provided in Part II of this book, "Building Smart Client Applications."

Application-to-application messaging technology can be used to create stand-alone messaging applications or applications in conjunction with other smart client technology such as a mobile database and synchronization. When used on its own, application-to-application messaging technology provides a mechanism for the client application to communicate with enterprise data sources. The messaging server can interact with the enterprise data and then send a message to the client with the data relevant to the mobile user. The user of the application can then respond to this message in the appropriate way. For a field service worker, this may involve adding an entry to his or her list of work orders; for a salesperson, it may involve updating inventory levels or pricing information. Whatever the case may be, messaging technology is a fundamental way to disperse information to mobile workers.

In conjunction with mobile database and synchronization technology, application-to-application messaging can add some significant advantages. The foremost is the ability to add push capabilities to applications. In smart client applications, the application user typically initiates the data synchronization process. This occurs either when users want to send information back to the enterprise or when they want to update the information they have in their client application. Users who are concerned that they do not have the most up-to-date information may end up synchronizing with the server multiple times before they get the new data they were waiting for. This can be a time-consuming and costly procedure. In this scenario, application-to-application messaging technology can be used to push the enterprise data to the client device, thereby ensuring the data on the client is always accurate. This process is often referred to as server-initiated synchronization.

Whether you are creating a stand-alone messaging application or enhancing a smart client application, store-and-forward capabilities are important. Often, mobile users cannot send a message immediately, in which case store-and-forward makes it possible for the message to be put into a queue, from where it will be sent at the first opportunity. Users can be confident that the message will be sent; they do not have to be concerned with the wireless connection. This so-called fire-and-forget feature makes mobile applications much more approachable for application users, especially when they are new to wireless communication.

Application-to-application messaging is proprietary in nature. That means there is no industry standard that defines how to create or deliver messages. This can be both good and bad. It is good because it allows vendors to add advanced features into their products, resulting in very versatile solutions. When vendors do not have to adhere to a predefined specification, they can respond quickly to their customers' needs without having to wait for a new specification to be released. The downside is that there is no standard API to communicate with the messaging client or server, therefore vendors create the interface to their systems however they see fit. This can lead to a steep learning curve for developers who are new to a particular vendor's messaging product.

Fortunately, this does not have to be the case. The Java Message Service (JMS) provides an industry standard way that vendors can follow to implement messaging solutions. JMS is a core technology defined in the Java 2 Platform Enterprise Edition (J2EE). JMS is predominantly used to provide an abstract level of access into different message-oriented middleware (MOM) products. It enables messaging vendors to provide a common programming model that is portable across messaging systems. As a developer, you only have to learn the JMS API to be able to interact with all of the leading messaging solutions on the market. JMS can be used on both the server and the client. For mobile applications, we are starting to see the first JMS clients, or JMS-like clients, developed in other programming languages, including C++. This type of product lets developers use their knowledge of JMS to quickly create advanced application-to-application mobile messaging applications.