Menu
The challenges of a wireless Web

The challenges of a wireless Web

Before the wireless Web becomes a reality, two fundamental constraints need to be addressed: the limitations of wireless devices, and the limitations of wireless networks.

The first problem is that wireless devices are significantly smaller and less powerful than laptops or PCs. Their functionality is limited by tiny displays, cramped keypads, slower processors and less memory.

Furthermore, the radio networks connecting these devices to the Web compare unfavourably with landline systems in terms of airtime costs, bandwidth, network availability and quality-of-service features such as latency, signal interruption and data loss.

However, various attempts are under way to get around these limitations. The most promising are a Web-clipping technique introduced by Palm and the growing acceptance of the wireless application protocol (WAP).

With Web clipping, which is used on the Palm VII wireless personal digital assistant (PDA), a customised wireless application is written and deployed in two parts: a Web-based back end, which serves the dynamic content, and a Palm Query Application (PQA), which lives on the Palm VII itself.

The server side of the application can be implemented using any of the standard technologies for database-driven, dynamic Web sites, such as Common Gateway Interface (CGI), parsed HTML and server APIs. However, the pages you serve must use a restricted subset of HTML 3.2, which means you can forget about fancy stuff like style sheets, imagemaps, frames, nested tables, cookies and client-side scripting.

The PQA is written in a "compiled" form of this same restricted subset of HTML and contains the relatively static user-interface elements needed to retrieve, update and display content (including images). The PQA gets onto the end user's device through a synching operation just as a standard Palm application would, and once in place, it behaves much the same way right up until the moment the user attempts to submit or retrieve new data.

At that point, a request is sent over a proprietary air link to a Palm proxy server, which in turn relays it, via standard HTTP, to the part of the application that lives on a Web server. The response retraces this route, from HTTP to Palm proxy and back out over the air link to the mobile device.

In effect, the PQA goes out and takes a "clipping" from the Web site with which it is permanently associated. Imagine, for example, that you needed to give your sales force access to the inventory, pricing and customer account information that lives on your corporate intranet. To do this with Web clipping would mean writing and distributing a PQA that contains all the menus and forms needed to input and output the data. Your servers, meanwhile, would host the extra files required to build the clippings on the fly, using Allaire's Cold Fusion, Microsoft Active Server Pages or CGI.

The advantages and disadvantages of Web clipping stem from the same source: the physical separation of static elements from dynamic ones. On the one hand, Web clipping keeps the costly wireless transaction to a minimum: only the information that needs to be updated is sent over the radio network, while the parts of the application that do not need to change (or not so frequently) reside on the device itself. Users get the benefit of access to a powerful, Web-based back end without the performance penalty of having to download bulky Web pages over the air.

The downside is that all interactions with the Web site must be planned ahead of time. Introducing a new form, for instance, would require writing and compiling a new version of the PQA, not to mention getting all your users to reload it onto their devices.

Nor can users freely browse a large site on their own to find what they need. Such restrictions are inherent in the Web-clipping model, which is optimised for short, highly structured types of transactions, such as checking on inventory and pricing, submitting orders at points-of-sale, accessing customer care or technical support information from the field.

The WAP solution

WAP is a global industry standard for bringing together wireless telephony with Internet content and services regardless of wireless network architecture or device type.

When it comes to linking digital phones to the Internet, WAP has quickly become the dominant model worldwide, and it's no wonder. Although the technical impetus for WAP came largely from a relative newcomer called Phone.com (formerly Unwired Planet), the organisation responsible for defining and promoting the standard, the WAP Forum, included among its founding members Nokia, Ericsson and Motorola. The resulting promise of interoperability has been key to WAP's appeal.

Because WAP is designed to work with any type of underlying wireless network architecture, it frees you to concentrate on the wireless application itself without having to worry, for example, whether something written for European customers will also work with devices common in the more fragmented digital phone market.

WAP provides something analogous to the familiar TCP/IP protocol stack used on the Internet and in corporate intranets. The difference is that the WAP protocol stack is specifically designed to accommodate the special challenges of wireless networking.

The WAP protocol stack

The application layer of this stack, called the wireless application environment (WAE), presupposes a user agent - the wireless terminal or client, equipped with a microbrowser. Also included in the WAE is an XML-based markup language called wireless markup language (WML). Through the protocol stack, the WAP client communicates with a server called a WAP gateway.

A WAP gateway server sits between the wireless carrier's network on one side and the public Internet or corporate intranet on the other. Gateways can be located within carrier or corporate firewalls, or both. In addition to taking care of various housekeeping chores (like keeping track of the WAP client's bookmarks or managing its cache, so that the very "thin" user agent doesn't have to), the WAP server handles the interface between the two sets of network protocols, wireless (WAP) and wireline (TCP/IP).

The WAP programming model is simply standard Web programming with a WAP gateway in the middle of the request/response cycle. A mobile phone or other wireless terminal requests, in byte code, a given URL which the WAP gateway server decodes and decompresses, then sends it on to the appropriate Web server as an ordinary HTTP request. The process is then repeated, in reverse, on the response side of the cycle.

The WAP model

The WAP gateway itself can live either within a cellular carrier's wireless network - Sprint PCS and others have already implemented WAP gateways - or for security reasons, in an enterprise environment, within your corporate firewall. In theory, the HTTP server can respond with HTML-based content. However, the WAE layer of WAP specifies an alternative markup language designed for use with thin wireless clients.

If standard HTML is served in response to the HTTP request, it falls to the WAP gateway server, or to an additional layer of middleware (which can be integrated with the gateway or on a separate server), to implement some form of content translation before the request can be relayed back to the WAP client.

The problem with this approach is twofold. First, accommodating wireless clients means leaving it up to a rules-based translation server to decide what Web-based content to include and what to leave out, in order to reduce major Web sites down to mobile phone (or even PDA) dimensions. Second, far too much legacy HTML on the Web is anything but well formed - trying to translate it on the fly simply won't work.

For the foreseeable future, therefore, the most effective WAP sites will be custom-coded in WML for wireless access.

In theory, WAP can support the same kind of mobile-centric applications as Web clipping, with the advantage that you don't have to worry about getting your users to download and sync applications from their desktops. In addition, because the user interface lives on the server and not the client, it can be updated more easily. Of course, if the devices you want to target are digital mobile phones, the user interface is going to be even more constrained than on a PDA.

This will likely limit the practicality of certain applications - just imagine trying to enter a lot of customer account information on a mobile phone's alphanumeric keypad.

In fact, if you want to use mobile phones as mobile terminals for accessing corporate data, you should also consider providing your field workers with a Web-based interface where they or their managers can personalise the content that appears on their phones.

This can help make the most of small form factors by targeting the right information and applications to the right users in the right circumstances. Imagine being able to set up different profiles for salespeople, delivery people, field technicians and project managers and then letting them each configure their own "views" of the wireless site depending on their client lists or routes.

Looking ahead

Of course, Web clipping and WAP don't exhaust the possibilities of the wireless Web. There are wireless modems and HTML-rendering browsers available for Palm III and V that give users the full Web experience, like WAP, without the need to go through a WAP gateway. Unfortunately, you will probably still have to custom-code your content (in a restricted subset of HTML), and you will lose the advantage of device and network interoperability. (Your new Cellular Digital Packet Data modems won't work on code division multiple access or GSM networks, for example.)On the other hand, PDAs (and larger devices) can increasingly be teamed with WAP phones through the use of data cables and/or PC or Compact Flash cards. (Windows CE devices have been out in front in this area.) This gives you some of the advantages of WAP without being tied to the mobile phone form factor and user interface. Looking ahead, expect to see more WAP-compatible mobile phone/PDA hybrids, such as the Ericsson R380, which is not yet available.

In such a rapidly evolving field as wireless, it is difficult to make predictions, but we can see a succession of new technologies just emerging or waiting in the wings.

The WAP standard includes the specification for a server-centric scripting language called WMLScript, support for which is gradually being implemented on the latest WAP-enabled mobile phones.

Mobile videoconferencing

With any luck, standards like WAP, and the new XHTML specification that lays the groundwork for a convergence of WML and HTML, should keep things relatively simple on the network side.

In-house Web developers will have to learn some new development tools and APIs, but, if all goes well, nobody will be called upon to reinvent the back-end


Follow Us

Join the newsletter!

Error: Please check your email address.
Show Comments