Proceed to WirelessDevNet Home Page
Publications, e-books, and more! Community Tutorials Store Downloads, tools, & Freebies! IT Career Center News Home
newnav.gif

Newsletters
EMail Address:



   Content
  - Articles
  - Columns
  - Training
  - Library
  - Glossary
 
   Career Center
  - Career Center Home
  - View Jobs
  - Post A Job
  - Resumes/CVs
  - Resource Center
 
   Marketplace
  - Marketplace Home
  - Software Products
  - Wireless Market Data
  - Technical Books
 
   News
  - Daily News
  - Submit News
  - Events Calendar
  - Unsubscribe
  - Delivery Options
 
   Community
  - Discussion Boards
  - Mailing List
  - Mailing List Archives
 
   About Us
  - About WirelessDevNet
  - Wireless Source Disks
  - Partners
  - About MindSites Group
  - Advertising Information
 

Introduction to the Wireless Application Protocol

Overview

The Wireless Application Protocol is a standard developed by the WAP Forum, a group founded by Nokia, Ericsson, Phone.com (formerly Unwired Planet), and Motorola. The WAP Forum’s membership roster now includes computer industry heavyweights such as Microsoft, Oracle, IBM, and Intel along with several hundred other companies. According to the WAP Forum, the goals of WAP are to be:

  • Independent of wireless network standard.
  • Open to all.
  • Proposed to the appropriate standards bodies.
  • Scalable across transport options.
  • Scalable across device types.
  • Extensible over time to new networks and transports.

As part of the Forum’s goals, WAP will also be accessible to (but not limited to) the following:

  • GSM-900, GSM-1800, GSM-1900
  • CDMA IS-95
  • TDMA IS-136
  • 3G systems - IMT-2000, UMTS, W-CDMA, Wideband IS-95

WAP defines a communications protocol as well as an application environment. In essence, it is a standardized technology for cross-platform, distributed computing. Sound similar to the World Wide Web? If you think so, you’re on the right track! WAP is very similar to the combination of HTML and HTTP except that it adds in one very important feature: optimization for low-bandwidth, low-memory, and low-display capability environments. These types of environments include PDAs, wireless phones, pagers, and virtually any other communications device.

The remainder of this overview will concentrate on presenting WAP from a software developer’s perspective so that other software developer’s can be quickly brought up to speed. Other documents on this site go into much greater detail on development specifics including in-depth reviews and demonstrations using a variety of vendor packages.

WAP and the Web

From a certain viewpoint, the WAP approach to content distribution and the Web approach are virtually identical in concept. Both concentrate on distributing content to remote devices using inexpensive, standardized client software. Both rely on back-end servers to handle user authentication, database queries, and intensive processing. Both use markup languages derived from SGML for delivering content to the client. In fact, as WAP continues to grow in support and popularity, it is highly likely that WAP application developers will make use of their existing Web infrastructure (in the form of application servers) for data storage and retrieval.

WAP (and its parent technology, XML) will serve to highlight the Web’s status as the premier n-tier application in existence today. WAP allows a further extension of this concept as existing “server” layers can be reused and extended to reach out to the vast array of wireless devices in business and personal use today. Note that XML, as opposed to HTML, contains no screen formatting instructions; instead, it concentrates on returning structured data that the client can use as it sees fits.

Why Wireless? Why WAP?

Suppose that you work at a large shipyard involved with the construction and repair of commercial and naval ships. Typical projects are discussed in the hundreds or even thousands of man-years. Your organization long ago learned to make use of advances in computing technology by delivering real-time access to information via mainframe terminals on employee desks or on shop floors. As time went on, managers were eventually even able to make the business case for client/server access to mainframe databases from Windows applications. This opened up existing databases to improved reporting, charting, and other user interface features. Managers and shop foremen can access parts inventories, repair schedules, shop budgets, and other useful information in order to plan work crew schedules and employee tasking.

It was just another small step from there for management to take advantage of your Web development skills by Web-enabling various mainframe applications (buzzword alert: we now call this Enterprise Application Integration, or EAI). With this information on the Web, information can be shared with parts suppliers and contractors which has greatly reduced ordering times and costs involved. One problem remains, however: out of 10,000 employees and contractors, only about 500 actually interact with the databases. The remainder of the employees continually fill out paperwork, issue reports to their manager, or manually key in data when they return from working on a ship.

Then, you read this article. Imagine if the other 9500 employees actively involved in welding, pipefitting, installing electrical cable, and testing electronics could all wirelessly retrieve and/or edit data when they actually need to! Small, inexpensive devices are given to each employee based on their tasking requirements. Some require handheld devices with built-in barcode scanners, others require keypads, others require simple digital displays. WAP allows a suite of client applications to be built which reuse existing server applications and databases. In addition, these applications can be dynamically downloaded and run on any of these devices. If an electronics tester runs into a bad vacuum tube, he scans the barcode. If a cable installer realizes that 500 more feet of a specific type of cable are required, he selects the “Order Cable” menu option from his wireless phone. If someone installing HVAC ventilation wants to know which pipes or cables run through a specific section of the ship, he enters the query in on his PDA and retrieves either data or imagery information.

In any industry that involves employees stepping out of their office to complete a job, wireless applications will be abundant. In Rifaat A. Dayem’s book Mobile Data & Wireless LAN Technologies (Prentice Hall, 1997), he estimates that over 50% of the applications for this type of technology have not even been thought of yet!! WAP helps standardize the applications that will proliferate using wireless communication technologies. Imagine the Web without the combination of HTML and HTTP leaving us instead with “open” specifications from Sun Microsystems, Microsoft, and IBM. I will go out on a limb and say that there is no chance the Web would be where it was today without freely available, vendor-neutral, open standards.

How Does It Work?

WAP uses some new technologies and terminologies which may be foreign to the software developer, however the overall concepts should be very familiar. WAP client applications make requests very similar in concept to the URL concept in use on the Web. As a general example, consider the following explanation (exact details may vary on a vendor-to-vendor basis).

A WAP request is routed through a WAP gateway which acts as an intermediary between the “bearer” used by the client (GSM, CDMA, TDMA, etc.) and the computing network that the WAP gateway resides on (TCP/IP in most cases). The gateway then processes the request, retrieves contents or calls CGI scripts, Java servlets, or some other dynamic mechanism, then formats data for return to the client. This data is formatted as WML (Wireless Markup Language), a markup language based directly on XML. Once the WML has been prepared (known as a deck), the gateway then sends the completed request back (in binary form due to bandwidth restrictions) to the client for display and/or processing. The client retrieves the first card off of the deck and displays it on the monitor.

The deck of cards metaphor is designed specifically to take advantage of small display areas on handheld devices. Instead of continually requesting and retrieving cards (the WAP equivalent of HTML pages), each client request results in the retrieval of a deck of one or more cards. The client device can employ logic via embedded WMLScript (the WAP equivalent of client-side JavaScript) for intelligently processing these cards and the resultant user inputs.

To sum up, the client makes a request. This request is received by a WAP gateway that then processes the request and formulates a reply using WML. When ready, the WML is sent back to the client for display. As mentioned earlier, this is very similar in concept to the standard stateless HTTP transaction involving client Web browsers.

Communications Between Client and Server

The WAP Protocol Stack is implemented via a layered approach (similar to the OSI network model). These layers consist (from top to bottom) of:

  • Wireless Application Environment (WAE)
  • Wireless Session Protocol (WSP)
  • Wireless Transaction Protocol (WTP)
  • Wireless Transport Layer Security (WTLS)
  • Wireless Datagram Protocol (WDP)
  • Bearers (GSM, IS-136, CDMA, GPRS, CDPD, etc.)

According to the WAP specification, WSP offers means to:

  • provide HTTP/1.1 functionality:
    • extensible request-reply methods,
    • composite objects,
    • content type negotiation
  • exchange client and server session headers
  • interrupt transactions in process
  • push content from server to client in an unsynchronized manner
  • negotiate support for multiple, simultaneous asynchronous transactions

WTP provides the protocol that allows for interactive browsing (request/response) applications. It supports three transaction classes: unreliable with no result message, reliable with no result message, and reliable with one reliable result message. Essentially, WTP defines the transaction environment in which clients and servers will interact and exchange data.

The WDP layer operates above the bearer layer used by your communications provider. Therefore, this additional layer allows applications to operate transparently over varying bearer services. While WDP uses IP as the routing protocol, unlike the Web, it does not use TCP. Instead, it uses UDP (User Datagram Protocol) which does not require messages to be split into multiple packets and sent out only to be reassembled on the client. Due to the nature of wireless communications, the mobile application must be talking directly to a WAP gateway (as opposed to being routed through myriad WAP access points across the wireless Web) which greatly reduces the overhead required by TCP.

For secure communications, WTLS is available to provide security. It is based on SSL and TLS.

The Wireless Markup Language (WML)

Many references I’ve come across use terminology such as "WML is derived from HTML" or "WML is loosely based on XML". Warning bells went off in my head when I see statements like this because: (a) it often means that a vendor has added proprietary extensions to some technology and (b) it means that I’m going to have to learn yet another language. Having said that, let me express my relief to find that WML is, in fact, an XML document type defined by a standard XML Document Type Definition, or DTD. The WML 1.1 DTD is defined at:

http://www.wapforum.org/DTD/wml_1.1.xml

Much greater detail on XML and WML are given in the WML tutorial located under the WAP training topic, however the following code gives you an example of a simple WML file. If you’re familiar at all with XML, you should have no problem understanding its meaning.






Hello World!

The first two lines are required. They give the XML version number and the public document identifier, respectively. From there, all WML decks (one WML file equals one deck) begin and end with the
tags. Individuals cards are arranged with the
tags. Also, note that WML, like XML, is case-sensitive!

Included in the WML specification are elements that fall into the following categories: Decks/Cards, Events, Tasks, Variables, User Input, Anchors/Images/Timers, and Text Formatting. See the WML tutorial for specific examples on using these elements to build applications.

Additional Intelligence via WMLScript

The purpose of WMLScript is to provide client-side procedural logic. It is based on ECMAScript (which is based on Netscape’s JavaScript language), however it has been modified in places to support low bandwidth communications and thin clients. The inclusion of a scripting language into the base standard was an absolute must. While many Web developers regularly choose not to use client-side JavaScript due to browser incompatibilities (or clients running older browsers), this logic must still be replaced by additional server-side scripts. This involves extra roundtrips between clients and servers which is something all wireless developers want to avoid. WMLScript allows code to be built into files transferred to mobile client so that many of these round-trips can be eliminated. According to the WMLScript specification, some capabilities supported by WMLScript that are not supported by WML are:

  • Check the validity of user input
  • Access to facilities of the device. For example, on a phone, allow the programmer to make phone calls, send messages, add phone numbers to the address book, access the SIM card etc.
  • Generate messages and dialogs locally thus reducing the need for expensive round-trip to show alerts, error messages, confirmations etc.
  • Allow extensions to the device software and configuring a device after it has been deployed.

WMLScript is a case-sensitive language that supports standard variable declarations, functions, and other common constructs such as if-then statements, and for/while loops. Among the standard’s more interesting features are the ability to use external compilation units (via the use url pragma), access control (via the access pragma), and a set of standard libraries defined by the specification (including the Lang, Float, String, URL, WMLBrowser, and Dialogs libaries). The WMLScript standard also defines a bytecode interpreter since WMLScript code is actually compiled into binary form (by the WAP gateway) before being sent to the client. For more information on WMLScript, see the tutorial on this site.

The Business Case

Pros

WAP’s biggest business advantage are the prominent communications vendors who have lined up to support it. The ability to build a single application that can be used across a wide range of clients and bearers makes WAP pretty much the only option for mobile handset developers at the current time. Whether this advantage will carry into the future depends on how well vendors continue to cooperate and also on how well standards are followed.

Cons

It is very, very early on in the ballgame and already vendor toolkits are offering proprietary tags that will only work with their microbrowser. Given the history of the computing industry and competition, in general, this was to be expected. However, further differentiation between vendor products and implementations may lead to a fragmented wireless Web.

WAP also could be found lacking if compared to more powerful GUI platforms such as Java, for instance. For now, processor speeds, power requirements, and vendor support are all limiting factors to Java deployment but it’s not hard to imagine a day in the near future where Java and WAP exist side-by-side just as Java and HTML do today. In that circumstance, Java would hold a clear advantage over WAP due to the fact that a single technology could be used to build applications for the complete range of operating devices. Of course, on the flip side, the world is not all Java and there will always be a place for markup languages in lieu of full-blown object-oriented platforms.

Conclusion

Some critics and second-guessers have pondered the need for a technology such as WAP in the marketplace. With the widespread proliferation of HTML, is yet another markup language really required? As we’ve discussed here, in a word, YES! WAP’s use of the deck of cards “pattern” and use of binary file distribution meshes well with the display size and bandwidth constraints of typical wireless devices. Scripting support gives us support for client-side user validation and interaction with the portable device again helping to eliminate round trips to remote servers. WAP is a young technology that is certain to mature as the wireless data industry as a whole matures; however, even as it exists today, it can be used as an extremely powerful tool in every software developer’s toolbox.

Next: The Wireless Markup Language

Sponsors

Search

Eliminate irrelevant hits with our industry-specific search engine!









Wireless Developer Network - A MindSites Group Trade Community
Copyright© 2000-2010 MindSites Group / Privacy Policy
Send Comments to:
feedback@wirelessdevnet.com