The WAP Forum, founded by Ericsson, Motorola, Nokia and Phone. com, controls the WAP specifications and boasts hundreds of members and considerable worldwide market momentum. Users typically interact with WAP content using microbrowsers built into cell phones, with screen sizes ranging from four to 11 lines, each line containing 12 to 16 characters. If WAP takes off, every mobile telephone could come with WAP built in within two years. And with hundreds of millions of cell phones, optimists predict massive production of mobile-oriented content and applications. The applications that make the most sense for WAP will be transactional in nature, compared with general Web surfing, because of form and bandwidth constraints. People will be checking the weather, buying theater tickets, rescheduling flights and ordering lattes using WAP.

WAP browsers are becoming available for other handheld platforms as well. Moreover, WAP does not limit screen size, which eventually will increase. Vendors are offering a growing number of tools for developing WAP applications, and there are also off-the-shelf solutions that let organizations extend standard business applications, such as Microsoft Exchange and Lotus Notes.

Maybe you have some intranet content you would like to deliver to your mobile work force. Examples include helpdesk automation, pricing information, telephone databases, messaging and calendar management. Or maybe you have a great idea for horizontal-market content you would like to sell to mobile users at large, such as rebooking people on alternative flights when original flights are cancelled. To do this, you'll need to be familiar with WAP's architecture, the steps involved in developing applications and some of WAP's problems.

WAP in Perspective

Wireless applications must match users' needs. There is no reason to deliver information over a wireless network if users can wait until they return to their offices to download it, and there is no point in designing applications that are frustrating to use because of the mobile device's physical limitations or bandwidth limitations.

The founders of WAP designed the protocol to address the bandwidth and latency issues of wireless networks. They also wanted to optimize menu-driven applications for microbrowsers operating on mobile telephones. Another goal was to provide a mechanism by which operators can control how users access different content and applications, paving the way for value-added objectives. WAP lets developers host content and applications on existing Web services for additional revenues. The WAP Forum has met these objectives successfully. WAP lets developers host content and applications on existing Web servers that mobile users can access regardless of device and wireless connection.

But there are severe limitations, such as the tiny amount of display space and the difficulty of entering text using a telephone keypad. WAP also requires that developers format the content using WML (Wireless Markup Language), which, though based on XML, involves new syntax.

Because cellular operators handle the WAP gateways through which WAP content passes, broad-market developers must negotiate with carriers to have the developers' sites listed on the phones' home pages. Finally, WAP is a set of proprietary protocols controlled by the WAP Forum and not subject to the open review process of Internet standards. Although there are efforts under way to eventually converge WAP with World Wide Web Consortium (W3C) standards, this could take years.

Keep in mind also that the speed of wireless networks is increasing. By the end of 2001, access speeds ranging from 28 Kbps to 128 Kbps will be common, at which point the standard HTML becomes feasible over wireless connections.

Nevertheless, WAP can make sense for carefully targeted applications. The key is to have small amounts of content that have high real-time value and require minimum user input.

WAP is not the only game in town. Major U.S. carriers still use WAP's precursor, HDML. In Japan, more than 10 million users have subscribed to a service called i-mode, which offers capabilities similar to WAP's but is based on a subset of HTML, called compact HTML. NTT DoCoMo, which created i-mode, is trying to export i-mode to other countries, and in fact a future version of WAP may support i-mode content. This is a quickly evolving area that requires close monitoring. Don't get involved with WAP unless you have a good feel for the market and have an appropriate application. WAP is not a cure-all, and skeptics consider it an interim technology at best.

WAP Architecture

More than just a set of protocols, WAP is an entire architecture (see "WAP Architecture," at right). The key components are the microbrowser in the mobile device (usually a mobile telephone, but browsers for handhelds are also coming) and the WAP gateway (also called the WAP proxy), which usually resides in the carrier's network. There is also the Web server that hosts the WAP content.

WAP's page model uses the concept of cards and decks. One card typically presents one screen of information. A deck is a group comprising one or more cards with links between them, allowing local navigation of content. When a device requests a deck of information, the request travels to the WAP gateway, which forwards the request to the server. The server responds by sending content in WML (or HDML) format to the WAP gateway, which forwards the response to the user.

Why have a gateway? For reliable wireless communications, the gateway and mobile browser use specialized transport protocols at Layer 4 of the protocol stack. For example, WAP specifies a reliable transaction protocol that is optimized for wireless communications and is more efficient than protocols such as TCP. WAP's transaction protocol does not use the three-step handshake used by TCP when it establishes a connection. As for Layer 3 of the wireless connection, some networks use IP while others use proprietary protocols. It is even possible to use the SMS (short message service) for transporting WML in digital cellular networks.

The advantage of WAP is that the wireless transport is independent of the content. In other words, developers can theoretically produce WAP applications without worrying about details of individual wireless networks or devices. The gateway also benefits carriers, as it controls access to services.

The default home page on the mobile telephone supplied by the carrier points to its gateway, and so the carrier determines what sites are listed on this all-important initial screen. Although users can enter any URL, this is awkward given the limited keypad.

Communication between the gateway and the Web server is based on standard TCP and HTTP. Because the application resides on the server, no application software needs to be installed on the mobile device. For security, WAP provides encryption and authentication through WTLS (Wireless Transport Layer Security), a protocol that operates between the browser and the gateway. WTLS is based on TLS (Transport Layer Security) and SSL (Secure Sockets Layer) but accommodates limitations of wireless connections, such as higher latency. Actual encryption options include DES and 3DES. Between the gateway and the Web server, standard Internet security protocols, such as SSL or TLS, can be used.