The complete chain of processing that occurs to WAP content on its journey to the user is illustrated in Figure 0.2. (This figure omits the details of the communications, since they’re not very important, and they change depending on the precise low-level bearer protocol in use.)
The WAP browser in the figure can run on any supported device, from a cell phone to a PDA. Generally, cell phones need to be designed to support WAP, but most modern PDAs can be upgraded to support WAP simply by purchasing the browser software and installing it. PDAs need to be used with a cell phone to provide the connectivity.
The origin server (on the far right of the figure) stores or generates the content itself. In nearly all cases, the protocol used to communicate with the origin server is standard HTTP, so this can be a standard web server. It’s usually necessary to make a couple of minor modifications[1] to the server’s configuration, so it can serve WAP content. All the most popular web-server software can perform this task. An interesting solution is to use a technology such as XSLT (XML Stylesheet Language Transformations), which allows both HTML and WML to be automatically generated from the same raw data.
Not included in the picture but quite likely to be present is some sort of backend database server. The origin server uses standard web technologies (such as CGI scripts or Java servlets, for instance) to generate any required dynamic content. These scripts probably need to communicate with a database to get the raw data to output. (This is going beyond the scope of this book, however. All standard techniques for generating web content on a server will also work for WAP, so you should read a book on one of those.)
The WAP gateway box in Figure 0.2 is the more interesting. The job of the WAP gateway is to convert between the browser’s WAP communication protocols (WSP, WTP, and so on) and the standard HTTP and TCP/IP protocols required by the origin server. It’s also responsible for converting the content output by the origin server (formatted as text) into the compressed binary formats of WML and WMLScript as required by the browser.
The gateway consists of some software to do this conversion, usually running on some sort of standard hardware. (Most proper gateways run on heavy-duty Unix servers, but there is low-end gateway software available that even runs on a Windows-based PC.) The gateway’s owner must also handle the connection to the bearer network. For a dialup-based bearer, this process is achieved through a standard access server (the same pieces of hardware people use to dial in to the Internet), but for such bearers as SMS and GPRS, the connection will probably involve a leased line to a carrier.
Because of all these infrastructure requirements, most people offering WAP content will not run their own gateways. (Many people will run their own origin servers, since this is not much different from running a normal web server, but far fewer people will run full WAP gateways.) All cell phone carriers that want to support WAP (which is most of them) will probably run their own gateways, and a number of other portal sites already exist, which also run gateways. Since most of these allow users to connect to any content on the Internet, a user just needs an account on one of these to access all the third-party content available.
[1] Specifically, modifications include adding support for the WAP content types. The types that need to be added are described in Appendix D.
Get Learning WML, and WMLScript now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
