Working with WAP
![]() |
||||||||
Internet Appliance DesignTo read original PDF of the print article, click here. Working with WAPJeff Stefan |
||||||||
You can't run a desktop Web browser on a cell phone or PDA, but the Wireless Application Protocol can give you Web-like access to data, even when resources are limited.
The Wireless Application Protocol (WAP) is emerging as a standard wireless protocol and browser framework for small, limited display devices. WAP is an Internet-enabling protocol, based on XML, that allows data access for cell phones, PDAs, and other low-horsepower systems. WAP is a reaction to two phenomena: the explosive growth of the World Wide Web and digital wireless devices. Access to the Internet and Web on the desktop is a fairly mature technology, even despite its short existence. For the everyday user, modem speeds are tolerable, access is better than ever, and a large number of Internet service providers make mass access affordable. For companies and power users, technologies such as Digital Subscriber Lines, or DSL, offer ultra high speed, always-connected Internet access. This isn't the case with wireless Web access. Wireless Web is new, immature, and inherently slow. Desktop browsers, such as Netscape Navigator and Internet Explorer easily support complex text and graphics and render them relatively quickly, but the opposite is true with a wireless device. Wireless devices are slow and display-handicapped, but mobile Web access is still a great convenience. Several wireless phone manufacturers recognized this early and formed the WAP Forum (www.wapforum.org) to create a specification for a Web access environment based on current Internet and Web technology. Clients, servers, and proxies Typical client applications are web browsers such as Netscape Navigator and Internet Explorer. Browsers make information available to a user by navigating through hypertext links and forms. Unseen client applications may contain Web-enabled connectivity without the user really knowing it. An example is an application that logs data from a remote location and posts the data on a Web page. The client application accesses the data posted on the Web page and presents the data to the user in what appears to be a stand-alone application. Servers process requests from multiple clients across the Web. Desktop clients typically request servers to retrieve Web pages, navigate hypertext links, and access databases. Database access is achieved via the Common Gateway Interface, or CGI. A server invokes a CGI script using client data to access, process, and return data to the client. A proxy acts on behalf of the clients it serves, and behaves as a sort of funnel. Clients usually reside behind firewalls. Proxies receive requests from clients behind a firewall and wait for responses outside the firewall. All transactions go through the proxy, and proxies may flag or reject some transactions. Proxies can also be advantageous, especially in intranets. An intranet is an internal network that utilizes Internet protocols. Proxies can cache documents and Web pages, allowing faster access to frequently requested information. Web browsing on wireless non-PCs It's a different story on non-PCs, such as cellular phones and wireless PDAs. The computational power and display capabilities of handheld wireless devices are feeble compared to desktop devices. Having a four-line LCD display on a cellular phone with primitive graphics capability seems extravagant. PDAs are mild exceptions with bitmapped images and touchscreens. A desktop computer with a Megabit connection makes the Internet seem blazingly fast, but be aware that a cellular phone may be able to receive data only as quickly as 300bps. With the throughput, display, and computational limitations of handheld devices, running a browser that interprets and displays complex HTML information is out of the question. The alternative is to create a new, scaled down, highly structured language and protocol for limited capability wireless devices and still enable Web access. That's the idea behind WAP. WAP architecture fundamentals A card is the fundamental WAP display unit. A card represents one screen's worth of data. The basic data can be text, a form, a single-bit bitmap, or a menu. There can be one or more cards per WAP client application. Multiple cards reside in a deck. A WAP browser, or user agent, decides how the information in a card is rendered on its particular display. The rendering and application functionality resides in the top-level application layer called the Wireless Application Environment (WAE). The WAE encompasses a micro-browser, supports code written in WML and WMLScript, and also includes the Wireless Telephony Application (WTA). The WTA contains direct access to telephone related functions. Instead of calling the WAP browser a micro-browser or client program, the WAP documentation calls it a User Agent. WML XML allows designers to custom design document types. Whereas everyone developing in HTML is burdened with its all-inclusive nature, XML can be used to create any type of document. HTML must be all things to all application domains. Not so with XML. Custom languages for specific application domains can be created using XML. Rather than accommodating everyone, an XML-based markup language can service a specific domain, such as limited resource wireless devices. This reasoning prevailed when the decision was made to base WML on XML. WML is designed with small in mind: a small display, a small amount of memory in the target device, and a small amount of computing power. WML applications are composed of cards that reside in decks. A deck can contain multiple cards. A card contains units of user interaction. These units of interaction are simple menu selections, text entry fields, text formats, and the like. WML also provides an event-handling capability that is used to navigate from card to card within a deck and to control execution of WML scripts. WML structure and transactions At the WAP proxy, the incoming HTML is converted to WML by an HTML filter, then compressed into binary byte codes. If the incoming content from the Web server is already in WML, only compression takes place. The content is delivered to the WAP client and the user agent displays the new content, which is usually a new card. The entire transaction sequence is shown in Figure 1. With all this activity and the inherently slow data rate of wireless devices, one comes to appreciate the minimal nature and design of WML. Figure 1: WAP transaction sequence WML syntax elements Attributes are values associated with tags. WML tags have default values. If additional or specific information must be associated with a tag, then an attribute value needs to be specified within a tag. The general form of an attribute within a tag is A simple WML deck Working with WAP
A WML deck is enclosed by the tags and denote a paragraph, and the enclosed text, “Working with WAP,” is displayed. This is an entirely static example deck, with no provision for user input, and no soft keys specified. The most common construct for assigning soft keys and taking action is the
Two soft keys are assigned in this example, one labeled “Next” in Card1 and one labeled “Last” in Card2 . Card1 contains a small text block, “Working with WAP,” that is displayed first. If a user accesses the “Next” soft key, Card2 is retrieved and the text “Working with More WAP” is displayed. Both cards are cached on the client device, and the client user agent positions the text independently of the WML program since no formatting information is included. Different user agents display this simple program differently, depending on the client's display capability. A Nokia phone will display the program slightly differently than a Motorola phone. How does the user agent know that Card1 and Card2 are already on the client device? First, no URL is specified. Second, a hash mark, # , precedes the card name. The hash mark says the card is local. Think of it as a “load immediate” type of instruction. As a WML author, how do you know if your program is correct? Like any language, WML has syntax rules and requires a parser to determine if a submitted program is correct. WML, being based on XML, has a well specified document type. A document type declaration must appear at the beginning of every WML document. The type declaration is:
This rather cryptic statement says the WML document is based on XML version 1.0, and the version of WML used is 1.1 and can be found at the URL indicated. WML navigation and events Tasks WMLScript WMLScript looks much more like a conventional programming language than WML. Since WML is a static language, some serious issues come up, such as user data input validity testing, target device resource access, and local message generation to users. How does WML know if a user entered a name instead of a phone number? What if the user enters something wrong and an error message must be displayed to alert the user? Does this mean that a new card must be accessed through a WAP proxy and Web server just to get a simple error message? WMLScript addresses these problems and offers enough high level language features to solve them. WMLScript is function-oriented. There is no call to main(), as in a C program. All functions are stored in compilation units and stored on a server for execution. The forms of WMLScript functions are shown in Listing 2.
WMLScript functions follow specific rules and have rigid constraints, such as always returning a value, passing parameters by value only, and not allowing function nesting. WMLScript supports two types of functions: external and internal. External functions are declared when the function is used outside of its compilation unit. This is like making a class member public in C++. If a function is used strictly within its local compilation unit, then the function is declared normally and is not visible to the outside world. A block of code is like a block of code in C or C++. Listing 3 shows how to link WMLScript functions to a WML page. This example uses the WMLScript library function setVar() to set a variable in a WML program. The example displays the number 5 on the client's display. The function GetNum() is called from within the
A WMLScript source code file is parsed by a lexical and syntactic analyzer and translated into binary byte codes. The result of a WMLScript compilation is a compilation unit, which contains user-created functions along with calls to pre-defined library functions. The byte codes contained in a compilation unit are interpreted by a WMLScript interpreter. The functions within a compilation unit residing on a server are accessed by referencing a URL followed by a hash mark (# ), the function name, and a parameter list. An example is call http://www.host.com/script#AddIt(1,2) . The function is AddIt() with parameters 1 and 2. The bytecodes for the function are retrieved and processed by the WMLScript interpreter on the client. WMLScript library functions The Lang library is a catch-all source of functions that are related to core WMLScript. The Lang functions range from determining the absolute value of a numerical parameter to determining the character set supported by a WMLScript interpreter. The Float library supports floating-point functions typically used in an application, such as floor() and ceil() . The String library contains string manipulation functions such as compare() and length() . The String library also contains some handy instructions such as find() , which locates a substring, squeeze() , which removes extra white space between strings, and trim() , which eliminates excess leading and trailing white space in a string.The URL library contains functions that manipulate URLs. The URL syntax supported is as follows: The URL library functions range from checking the validity of a URL to resolving absolute URLs. The majority of the URL functions are prefaced by get, which returns URL content and string information. Functions such as getParameters() and getPort() return the parameter list used in a URL and the port number specified in a URL, respectively. The WMLBrowser library contains the functions that link to WML variables. Important functions such as getVar() and setVar() retrieve and set variables in a WML program. Other functions in the WMLBrowser library have the same name as base WML functions, such as go() and prev() . This duplicate naming can be a source of confusion if an author isn't careful. The Dialogs library contains user interface functions, such as prompts and alerts. These beneficial functions add quality to the user interface and save time, since the dialogs can be cached on the client device. If a simple prompt, confirmation, or alert is needed, the user agent doesn't need to generate requests to the WAP proxy, but simply accesses the code on the client. These are useful functions when responding to invalid user input. If a user inputs an out-of-range number, a simple call to alert() displays the error, as shown in the code segment in Listing 4.
WAP protocol stack Figure 2: The WAP six-layer protocol stack The first underlying layer is the Session Layer. The Session Layer contains the Wireless Session Protocol, or WSP. The WSP offers both connection-oriented and connectionless services. Connection-oriented services maintain a virtual connection throughout a session. Sessions may be suspended and resumed at a later time. The connectionless services provide datagrams that do not maintain a connection, similar to UDP. Underneath the Session Layer is the Transaction Layer, which contains the Wireless Transaction Protocol, or WTP. The WTP is designed with thin clients in mind. The Transaction Layer supports three transaction classes: unreliable one-way requests, reliable one-way requests, and reliable two-way request and reply transactions. The next two layers down the stack are the Security and Transport Layers. The security protocol is based on the Secure Sockets Layer (SSL) protocol. Data integrity is ensured at this layer, and data is encrypted using a private key algorithm. The Transport Layer contains the WDP, or Wireless Datagram Protocol. This layer provides the WAP equivalent of TCP and UDP, with the emphasis on connectionless datagrams. The Transport Layer allows the upper layers to operate transparently to the data requirements of the bearer services. On the bottom of the stack are the Bearer Services. Bearers are the digital phones and the data services they provide. Developing WAP applications Both development toolsets have well-thought-out user interfaces, and each has a virtual phone handset on the right of the screen where you can see your WML/WMLScript application in action. Go forth Jeff Stefan is a system engineer at OnStar. He has worked in embedded systems software for many years, is a frequent speaker at the Embedded Systems Conferences, and is the author of over 15 software articles. He is currently writing his first book, entitled Embedding Artificial Intelligence. His e-mail address is . Resources Nokia Wireless Data Forum. This offers a WAP server trial kit and the Nokia WAP Toolkit along with a well written documentation set that's loaded with good examples. The WAP Toolkit is free but requires developer registration: www.nokia.com/corporate/wap/sdk.html. Phone.com. Go to the Developer Web Site to download the development kit. Like Nokia, the toolkit is free but requires registration: www.phone.com/developers/index.html.
|