Serve clients' specific protocol requirements with Brazil, Part 3

Economically sustain PQA, UP.SDK, and J2ME with the Brazil project

In Part 1 of this Brazil technology series, I introduced the concept of a developer-friendly experimental Web server technology called Brazil. The Brazil technology supports additional functionality via handlers, the simple Brazil Scripting Language (BSL), and a global dictionary of system and user properties (for more information on BSL, properties, and handlers, see Part 1

In Part 2, I discussed how to produce and synthesize XML content. In Part 3, I will demonstrate how to deploy a simple application to three different mobile targets using commonly available technology. You can't control the software and hardware environment of wireless devices but, by using well-constructed server technologies, you can economically adapt to them. Deployment, maintenance, and development costs drop if we only use one language. Of course, I would prefer Java to be that universal language for wireless devices, and that day may come to pass. In the meantime, however, you can utilize the methodology described in this article to support the various languages.

The 1-wire weather station provides a data source for many of the examples in Part 3. It is interfaced to the Brazil technology via a handler and can be found at Note that the concepts in this article apply to any data source and are not specific to the 1-wire weather station.

Read the whole series on Brazil technology:

One of the benefits of Brazil technology is that it removes the distinction between where the data is coming from and how it is delivered. For example, a client connected to a server utilizing the Brazil technology does little to facilitate communication with the device.

In this article's examples, you will look at the weather station data as content. In Part 2, I discussed how to convert the data to XML. As ubiquitous as XML may be, many XML extensions and unrelated approaches often require support on the server. It would be nice to only support XML, which is a perfectly valid approach, and ignore XML extensions. If you did, you can bet that everyone would come to your standard. Or you could architect your code to support multiple standards, which is a goal I hope to help you meet.

In this article, I provide all of the required URLS, examples, and some of the problems that I stumbled upon so that you can avoid the mistakes I made. All of the examples provide end-to-end solutions; a Brazil handler delivers data from a remote weather station to a remote wireless client using one of the following environments:

  • Palm query application (PQA)
  • Openwave UP.SDK
  • Java 2 Micro Edition's (J2ME) Connected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP)

This article will focus on basic architecture and will describe how to deliver content from point A to B with respect to the particular client. I will not go into detail about the best way to design a user interface using J2ME or, in the case of WAP-enabled phones, how to organize cards in a WAP application using WML.

To understand what the server must provide to meet the client requirements, let's discuss each of the clients.

Palm query application

Due to unpredictable communication errors, wireless environments can produce a hostile communication environment. Palm has designed a hardware/software solution with the Palm VII that addresses the challenges of that volatile environment. Palm's handheld device Palm VII performs low bandwidth wireless operations. To facilitate application development for the device, Palm developed an environment commonly referred to as Web clipping; it features the following drawbacks:

  • Slow connection speeds
  • Real throughput is often less than 9,600 bits per second
  • Significant advances in speed are not expected until G3
  • Dropped connections
  • Small screens

To tackle those challenges, Palm developed a special type of database for wireless access called Palm query application (PQA).

You can think of a PQA as a self-contained mini-Website and Web clipping as the results page that answers the query sent from the PQA on the Palm VII organizer. To develop a Palm Web clipping application, write some HTML pages using standard HTML tags with some restrictions, such as no cookies. See the Web clipping programming guide for more details.

Run the Webpages through a program called QAB.exe, (unfortunately a Windows-only product) to create a .prc file that you will download to the Palm. Normally, you go to a Website by entering the URL; however, with PQAs, you create a PQA for the Website that users install to access Web applications. As technology progresses, we hopefully will not have to preinstall those apps, or perhaps Palm will provide a facility for downloading PQAs over its proprietary wireless network.

I wrote a small PQA, shown below, that sends a query to the Brazil handlers Website and returns users the results on their Palm VII. If you don't have a Palm VII, you can test that out with the emulator for the Palm VII called POSE. Each of the three technologies I discuss in this article provide emulators.

Listing 1: HTML file for the Web clipping application

   <meta name="palmcomputingplatform" content="true">
      <td><a href="about_weather.html"><img
      <td align="center"><h1>Weather Handlers</h1>
<p><font size="+1"><b>1-wire Weather
<a href=>Get
<p align="center"><a href="about_weather.html">About</a>

In this case, the Brazil server uses remapping to map requests from to if the first part of the incoming URL is /brazil.

The Brazil handler then parses the URL request, since the Config file maps /weather to the weather handler. The weather handler distinguishes GetSample as a valid command, adds some additional properties in the request object, and returns because the .html suffix indicates that the request should be treated as an HTML file. The request object is passed on to the next set of handlers, which then reads in a file called GetSample.html. That file contains BSL, so the BSL handler processes the file and adds some values into it. The file finally returns, and the request from the Palm VII is completed.

Figures 1 and 2 show the weather PQA applications installed before and after requesting data from the remote weather station. When a user activates submit in Figure 1, a gateway sends a request to Palm's network. The Palm gateway performs optimizations to decrease bandwidth usage and returns the data.

Figure 2 demonstrates the results. Normally when you query a Web server, you also receive the page shown in Figure 1, but not with Palm PQA; that page must already be installed as a PQA.

The Palm gateway can also perform SSL; however, an intermediary mediates the SSL connection, which may not meet some security requirements. Palm explains how the network works in its developer Website listed in Resources below.

Figure 1. PQA application Click on thumbnail to view full-size image (32KB)
Figure 2. Web clipping results page Click on thumbnail to view full-size image (39 KB)

Openwave UP.SDK

Prior to merging with to form Openwave, developed handheld device markup language (HDML) to facilitate the development of wireless applications for commercially available Wireless Application Protocol (WAP) phones. Established in 1997 by Ericsson, Motorola, Nokia, and, WAP provides the de facto standard for wireless computing. In the example I provide in this article, I use Wireless Markup Language (WML), which is an XML-based language loosely similar to HTML. Like HTML, WML uses some familiar tags, but it is much smaller than HTML, and some of the tags behave differently. WML provides the following functionality for small-screen memory-constrained devices with or without keypads and intermittent communication channels:

  • Cards -- A WAP card is like an HMTL page. Users can navigate between cards. A collection of cards can be viewed as a deck, which is a single file containing many cards. Since they collect the cards into a single file, decks are similar to a PQA, but much easier to deploy. With WAP you don't have to preload the PQA, which forever binds you to some other device such as a PC. WAP applications are delivered dynamically from the server.
  • Images -- Unique format for mobile devices.
  • User input via standard types such as choice, choice list, text entry.
  • User navigation, state, and context management -- Rudimentary ability to pass data between cards to reduce server involvement.

Leveraging our investment in server technology, we will support the UP.SDK, a WAP 1.1-compliant development environment for creating wireless Internet applications. See Resources for links to the free development kit. You can use the UP.SDK to develop client functionality that utilizes the same Brazil handlers discussed above. One of the challenges faced by nascent wireless programmers is developing server applications that support many clients. Though it is always easier to support only one type of client, given the diversity in wireless technology today, you must have a server architecture that supports numerous clients.

Test the examples hosted at (direct link available in Resources below) by downloading the UP.SDK and setting the URL in the UP.Link menu item under Settings to Figures 3 and 4 show what you would see on a Motorola iDEN phone screen.

Figure 3. WML client using UP.SDK main screen displays index.wml
Figure 4. WML client using a UP.SDK emulator displays GetSample.wml

How does that all work? The UP.SDK implements a browser that can interact with Websites that have WML-compliant files; prior products and instances of the tools from were based on HDML. The Brazil technology server returns the .wml file, and the minibrowser, which is already installed on the phone, then displays the file on the device. Also, unlike the Palm VII application, you don't have to install .pqa files for each Website before visiting it.

Below is the simple WML index file, which allows users to select different services at the Brazil handlers Website. For more information on the WML syntax, see Resources below.

Listing 2: index.wml

<?xml version="1.0"?>
  <card title="BrazilHandlers">
        <p mode="nowrap">
        <b>Weather at 06612</b>
                <onevent type="onpick">
                  <spawn href="">
                    <catch />
                <onevent type="onpick">
                  <spawn href="staytuned.html">
                    <catch />
                Access Home
                <onevent type="onpick">
                  <spawn href="staytuned.html">
                    <catch />
           <option onpick="#support">Developer Info</option>
  <card id="support">
          Point your Web browser to the Website at
        <p align="center">
          for additional information downloads and technical resources.

If selected, the first option in the index file directs the requester to GetSample.wml on the server. Brazil processes the file, which utilizes BSL to synthesize a new page. Notice the if statement that creates two output files, one with more data than the other.

Finally, you arrive at some WML code. When a WAP-enabled phone selects the choice that directs the user to GetSample.wml, the code below is delivered to the phone after being processed by the Brazil technology. Please note that the core Brazil handler provides support for many different architectures simultaneously from the same data source. Future articles will demonstrate requests for the same data from Jini, Remote Method Invocation (RMI), Java Reliable Multicast Service (JRMS), and Java Messaging Service (JMS) clients.

1 2 Page 1
Page 1 of 2