Saturday, December 6, 2008

Wireless Application Protocol (WAP)

Newspapers and television are now starting to carry adverts for the new WAP-enabled mobile phones. The companies' promises are a little exaggerated, and the ability to surf the web effectively on the phone is still some way off.

The WAP application strategy involves taking existing services that are at present supplied through a fixed-line environment and tailoring them to be user friendly and useful in a mobile wireless environment.

The WAP specifications define a set of protocols for applications, transactions, security and transport. They also define a Wireless Application Environment (WAE), which enables operators and manufacturers to develop applications such as microbrowsers, email and web-to-mobile messaging facilities.

If a device is said to be WAP capable it means that it has a microbrowser loaded into it which allows it to communicate, understand and handle all entities specified in the WML 1.1 DTD.

Many of the protocols are based around existing Internet standards such as HTTP but have been optimised for the unique constraints of the wireless environment, such as low bandwidth and connection instability.

Although this is a collection of new standards, these are all based on the use of XML. Every document and all output are in XML. In fact, there is very little within WAP that is new. The diagram below illustrates how a mobile device requests and receives data using this service.

A ‘GET’ request from a user is transmitted as a URL from the mobile phone to a WAP gateway, from where it is sent via standard HTTP to the Internet content provider. The request is handled by the server, which then transmits the requested data back across the same network.

Standard XHTML data could not be sent to mobile phones because of the size and complexity of content in the pages, the requirement to continually link to other pages within the server and the small screen size of the device. So another mark up language was needed to serve this environment.

WAP documents are written in Wireless Mark up Language (WML), which is a subset of XML. A WML document is known as a deck, and a single interaction by a user agent (ie the microbrowser) is called a card. A deck may consist of several cards. This simple architecture means that WAP sessions can cope with intermittent coverage and loss of server connection by downloading multiple screens to the client in one transaction.

The reduced processing power of the mobile devices concerned has the result that decks cannot contain too much information. This limitation means that multiple cards will have to be split into multiple decks to complete a complicated transaction.

Below is a link to a very simple example of a WML deck as defined by everything contained within the tag being turned on and off. It actually looks very similar to an HTML page, using similar tags, but it is actually an XML document. As stated in the earlier section, there is an XML statement at the top of the document, and there is a DTD statement. This deck containing three cards allows the user to select different options and then return to the front page.

The user can navigate from the front page (card 1), by either selecting the email address or phone number option. The secondary screens (defined by card 2 and card 3) give simple information and a link back to the first screen (card 1 again).

This example has only a limited amount of client interaction as there are only three cards in the deck and the only navigation is backwards and forwards.

As well as this basic display there are many features which allow client transactions to be completed. Variables within WML provide a mechanism for carrying selected data from one card to another. WMLScript, a slimmed-down version JavaScript, can deal with more complex elements.

It is obvious from this section that a standard HTML website will not deliver data across this medium. Further information on the structuring of documents, server architecture and delivery protocols can be seen at the following website.

0 comments: