More action with Struts 2
In a recent review of Struts 2 in Action, JW Blogger Oleg Mikheev notes that Struts 2 is "just a collection of extensions built upon WebWork, which is ultimately the right thing to learn before starting a Struts 2 project." While Struts 2 has some architectural flaws, Oleg calls WebWork well-designed, well-tested, and reliable. What are your experiences using Struts 2 and WebWork?

Also see "Hello World the WebWork way," a JavaWorld excerpt from WebWork in Action, by Patrick Lightbody and Jason Carreira.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Java Tip 123: Dial into the wireless world

Execute a simple phone book application with WML and JSP

By Manoj Agrawal, JavaWorld.com, 02/08/02

We have all heard the phrase killer wireless application. Unfortunately, those killer apps are more complicated than they look. Competing standards, myriad devices, and different browsers create a difficult development landscape. In this tip, I focus on cell phone development to show how to simplify that landscape. You will use the Wireless Markup Language (WML), a leading language for developing wireless applications, and the Wireless Application Protocol (WAP), a protocol mainly used to deliver content to cell phones. I will cover the basics of creating, deploying, and executing a WAP application using the Apache Tomcat Web server and Nokia Mobile Internet Toolkit.

WAP application architecture

When a user presses a cell phone key to access a Website, a WAP request is made to that cell phone's registered gateway. The WAP gateway decodes and translates the request into an HTTP request. The gateway routes the request to the Web server serving that request's URL. The Web server processes the request, and then delivers the HTTP response back to the gateway. The gateway translates the HTTP response into a WAP response and encodes it. It then delivers the response back to the cell phone. Figure 1 illustrates this process.

Figure 1. WAP application architecture

To understand the WAP application architecture and the proceeding example, you must understand several key components of wireless development: WAP, WML, and the WAP gateway.

WAP

The WAP specification consists of a wireless data protocol. That protocol standardizes the way in which a wireless device's micro browser communicates with a WAP gateway. The WAP specifications define a set of protocols in application, session, transaction, security, and transport layers that enable operators, manufacturers, and application providers to meet the challenges in advanced wireless-service differentiation and fast/flexible service creation. The specification also includes the Wireless Markup Language (WML). For general information on WAP, see Resources.

WML

The XML-based WML specifies the content and user interface for WAP-enabled devices. WML for WAP applications is analogous to HTML for HTTP applications. A WML document is a collection -- referred to as a deck -- of one or more cards. Each card is a well-defined unit of interaction between a user agent and a user (such as a menu, a text screen, or a text-entry field). Each card generally carries enough information to fit into one wireless device screen. For general information on WML, see Resources.

WAP gateway

As Figure 1 shows, the WAP gateway acts as the bridge between the wireless network containing wireless clients and the computer network containing application servers. A WAP gateway typically includes the following functionality:

  1. Protocol gateway: The protocol gateway translates requests from the WAP protocol stack to the WWW protocol stack (HTTP and TCP/IP).

  2. Content encoders and decoders: The content encoders translate Web content into compact encoded formats to reduce the number and size of packets traveling over the wireless data network. When a wireless client sends a request to a WAP application running on a Web server, the request first routes through the WAP gateway where it is decoded, translated to HTTP, and then forwarded to the appropriate URL. The response then reroutes back through the gateway, which translates the response to WAP, encodes it, and forwards it to the wireless client.


This proxy architecture allows application developers to build services that are network and terminal independent. For general information on the WAP gateway, see Resources.

The phone book example

The phone book program is quite simple: you just look up a phone number of a person listed in a phone/address book on your server. You will use the Nokia Simulator client application to simulate your cell phone. The screen will present options to the user for locating phone numbers via the Select option. Once the name is selected, the cell phone will display the phone number on the screen. On the server side, you will use the Apache Tomcat server. Figure 2 illustrates this architecture.

Figure 2. Phone book application architecture

The phone book system follows the WAP application architecture quite closely. First, the Nokia simulated WAP client requests the URL http://hostname:8080/PhoneBook/phonebook.wml (you can download this article's source code in Resources). The cell phone sends the WAP request through the built-in Nokia WAP server gateway (in real life, the gateway is located somewhere in the wireless network). That gateway generates a conventional HTTP request for the specified URL and sends it to the Tomcat Web server. Tomcat parses the HTTP request and determines what to retrieve.

As usual, if the URL specifies the static file, the Web server retrieves the file and returns it. On the other hand, if the URL is linked with a Java servlet, Common Gateway Interface (CGI), or other script application, the Web server passes the request to an associated application. In the example, you request the static file phonebook.wml. The phonebook.wml file is the WML deck file for the phone book example.

The Web server returns the WML deck with the appropriate HTTP headers. The WAP gateway verifies the response HTTP headers and WML content, then encodes them into binary form. From that, the gateway creates a WAP response and sends it back to the simulated cell phone client.

The cell phone client's micro browser interprets the WML and displays the first deck on the screen. The browser in Figure 3 shows the options for locating phone numbers via the Select button. When the user selects the name of the person whose phone number he or she wants, another WAP request routes through the WAP gateway to the Web server to locate that number.

Figure 3. The phone book application selects a name. Click on thumbnail to view full-size image.

You can also select all five persons listed under that option, as Figure 4 shows.

Figure 4. Phone book display selects all names

Once you have the name, request the following URL to look up the phone number in the phone book application:

Resources