Preface - Computer & Information Science & …ejkim/to_Dr_Helal/Ch2/2. Mobile... · Web viewOf late, the JSP has proposed a Java Specification Request to address this need (JSR 172,

CHAPTER2

MOBILE PLATFORMS

Pervasive Java

EDITORS’ INTRO

Welcome to the first installment of Standards, Tools, & Best Practices. This department will report on the latest in standards activities and development tools as they pertain to pervasive computing. The intended audience includes practitioners, technologists, and systems researchers who want to base their prototyping activities on industry standards and tools. I plan to discuss several exciting topics including

• platform standardization

• mobile services and their discovery protocols

• sensor networks

• wearable computers and their applications

• peer-to-peer programming over ad hoc networks

• standards and applications for smart homes

• commercial mobility-support middleware (data synchronizers,

Web, databases, email, and so forth)

• mobile commerce

I welcome suggestions and contributions for additional topics. In this first issue, I highlight pervasive Java—a surge of wireless and mobile platform standardization activities led by Sun Microsystems. Driven by a fast-pace proliferation of portable devices and appliances with embedded computers, pervasive Java (also called wireless Java and mobile Java) attempts to bridge the gap between disparate devices and platforms, and profitable business and application development. —Sumi Helal

Standards, Tools, & Best Practices

Today, mobile devices and gadgets come with more than just a

cool and cutting-edge design; they come equipped with small

brains and a common language, making them smarter and more

powerful than ever before. Perhaps they’re a little too smart—after

all, they can adapt and morph into each other and become many-in-

one super devices. Mobile phones with PDA capabilities and PDAs

packaged as mobile phones have started to invade the marketplace.

Furthermore, it won’t be long before we can shoot a presentation

right off our mobile phones or use a mobile phone as a wireless

mouse to more easily surf the Web on a laptop. Appliances are also

gaining amazing intelligence, thanks to embedded computers and

tiny communication interfaces. Pointof-sale equipment, gas pumps,

automobile dashboards, and digital cameras are examples of

today’s smart appliances. Refrigerators with Web pads,

microwaves that download recipes, and stereo systems that mute

when the phone rings are among the many smart appliances on the

horizon. The impressive leap in this technology led to a rapid

proliferation of many kinds of portable and embedded devices.

This proliferation signaled the beginning of a new and exciting era

of computing. It also quickly underpinned the new requirements

we must meet to mobilize this technology. The most critical

requirement was the need for a common yet flexible computing

and communication environment that could be fitted for— and

shared by—devices of different makes and capabilities.

Realizing this need, and recognizing that one size does not fit all,

Sun Micro-systems introduced the Java 2 Platform, Micro Edition,

a set of specifications that pertain to Java on small devices, ranging

from pagers and mobile phones to set-top boxes and car navigation

systems. Since its introduction, J2ME has evolved according to the

Java Community Process, a formalized process and an open

Sumi Helal, Chapter 22


organization of international Java developers and licensees whose

charter is to develop and revise Java technology specifications,

reference implementations, and technology compatibility kits.

The J2ME specifications are divided into configurations that are

specific to different device categories. Each configuration is

specialized into a set of profiles, which are specifications of

particular types of devices within a device category. Here, I

introduce J2ME and its configurations and profiles, emphasizing

mobile phones and PDAs that use the Mobile Information Device

Profile. In the next issue, I’ll survey available J2ME development

toolkits and MIDP devices, including mobile phones and PDAs.

2.1 JAVA 2 PLATFORM, MICRO

EDITION

In June 1999, Sun Microsystems introduced J2ME, targeted for

consumer electronics, portables, and embedded devices. This was

part of a reorganization effort of the Java technology into

Enterprise, Standard, and Micro editions (see Figure 2.1). To

support the kind of flexibility and customizable deployment that

the portables and embedded marketplace demand, the J2ME

architecture is composed of three modular and scalable layers: Java

Virtual Machine, Configurations, and Profiles.

The JVM layer implements a JVM customized for a particular

device’s host operating system and that supports a particular J2ME

configuration.

The configuration layer defines a minimum set of JVM features

and core Java class libraries available on a particular category of

Sumi Helal, Chapter 2 3


devices. These devices represent a particular market segment and

can be thought of as the lowest common denominator of the Java

platform features that a developer can assume will be available on

all devices.

Figure 2.1. One Java, three editions.

Figure 2.2. The relationship between Java 2 Platform, Micro

Edition configurations and the Java 2 Standard Edition.



The profile layer defines the minimum set of application

programming interfaces available on a particular group of devices,

which are developed on the underlying configuration. Profiles

serve two main purposes: device specialization (APIs that capture

or exploit particularities of the device interface and capability) and

device portability (APIs that behave consistently on any device

supporting the profile). Applications written for a particular profile

should therefore port to any device that conforms to that profile.

Generally, a device can support multiple profiles on which

different applications are built.

The configuration that defines small, mobile devices is called the

Connected, Limited Device Configuration. Examples of CLDC

devices are mobile phones and pagers. These devices will have

memory between 160 and 512 Kbytes and use the Kilobyte Virtual

Machine (KVM). A CLDC device uses either a 16- or 32-bit

processor and a low-bandwidth wireless network connection. The

only profile currently developed for the CLDC configuration is the

MIDP.

The Connected Device Configuration is considered a fixed type of

device that is always connected but still relatively resource poor.

An example would be set-top boxes such as a satellite TV receiver

or WebTV. The CDC configuration is a superset of the CLDC,

which ensures their compatibility. Figure 2.2 shows the

relationship between the various configurations.

Here, I highlight the main features of the KVM–CLDC

configuration and the MIDP. (For more information, see the Sun

Microsystems white paper, “Java 2 Platform Micro Edition (J2ME)

Technology for Creating Mobile Devices,” at

http://java.sun.com/products/cldc/ wp/KVMwp.pdf.)



2.1.1 KVM

The KVM is a new, smaller runtime environment for resource-

constrained devices. It is in the range of 40 to 80 Kbytes—hence

the “K” in KVM. Developing the KVM originated as a project,

known as the Spotless System, to create an execution engine for

the Palm PDA. The Spotless System development team soon

discovered that the runtime environment’s size is derived mainly

from its runtime libraries.

GLOSSARY

CDC Connected Device Configuration

CLDC Connected, Limited Device Configuration

J2ME Java 2 Platform, Micro Edition

J2SE Java 2 Platform, Standard Edition

JAD Java Application Descriptor

JAM Java Application Manager

JAR Java Archive

JVM Java Virtual Machine

KVM Kilobyte Virtual Machine

MIDP Mobile Information Device Profile

They then extracted classes that were too bloated or not as

critical to the system. The primary features eliminated were

The Java Native Interface, because native functionality is implementation dependent

The user-defined class loader, because CLDC will have a class loader that users can’t override, replace, or reconfigure

Reflection, to eliminate RMI, serialization, or any other features reliant on reflection

Thread groups and daemon threads (although the system supports multithreading)

Finalization of class instances

Weak references



AWT (Java Abstract Window Toolkit), which the developers

replaced with limited user interface classes, developed from the

javax.microedition. lcdui package

The floating-point type (although the system enables long

integers)

Figure 2.3. Relationships between Kilobyte Virtual Machine,

Connected Limited Device Configuration, and Mobile Information

Device Profile layers.

A reference implementation of KVM written in the C language is

available. Most of the code is common to all existing and future

implementations. A relatively small amount of platform-dependent

code is isolated in a few files. Porting KVM to a particular device

amounts to modifying only these dependency files. A special

startup mechanism of KVM and its applications is included in this

reference implementation. This is needed because, unlike a

general-purpose machine, small devices do not have a command-



line or special interface to start software atop the native operating

system. The Java Application Manager serves as an interface

between the native operating system and KVM. JAM downloads

and launches a J2ME application on top of KVM by connecting to

an HTTP server (using a serial line interface or some other means,

such as “over the air” in the case of mobile phones) to download

the application (called MIDlet) and a metadata file that describes

it. JAM uses the metadata file to uncompress and install the

MIDlet.

2.1.2 CLDC

The CLDC configuration defines a standard Java platform for

small, resource-constrained, connected devices and enables the

dynamic delivery of Java applications and content to those devices.

The small footprint configuration (limited to about 128 Kbytes) is

designed to run on many small devices, making minimal

assumptions about the native system software available. CLDC is

implemented as a set of additional classes contained in a separate

package (the java.io, java.lang, java.util, and javax.nicroedition.io

packages). This facilitates CLDC porting to different platforms.

CLDC requires that a JVM be able to identify and reject invalid

class files. The standard verification technique, such as that used

by J2SE (Standard Edition), is expensive in terms of memory use.

To reduce client-side verification overhead, CLDC uses a dual pre-

verification and verification process to push part of the verification

process into the development latform. The developer must pre-

verify the server or desktop prior to downloading the CLDC

MIDlet application into the mobile device. The pre-verification

process generates information (known as stackmap attributes) that



should be downloaded to the mobile device along with the

application classes. To streamline the packaging of this pre-

verification information and to enable dynamic downloading of

third-party applications and content, CLDC requires

implementations to support the distribution of Java applications

using compressed Java Archive (JAR) files. Whenever a Java

application intended for a CLDC device is created, it must be

formatted into a JAR file, and class files within a JAR file must

contain the stackmap attributes. The MIDP also imposes a similar

data requirement on third-party MIDlets.

2.1.3 MIDP

The MIDP is a set of JavaAPIs that, together with the CLDC,

provides a complete J2ME application runtime environment

targeted at mobile information devices, such as mobile phones,

PDAs, and two-way pagers. It is the only profile currently fully

specified for CLDC (another profile that specializes only on PDAs

—the PDA profile is currently being developed). The MDIP

provides API classes related to interface, persistence storage,

networking, and application model. For instance, the MIDP

specifications provide an API for persistent storage in the form of a

RecordStore. This is a Java object that can be instantiated and used

to store data objects as raw bytes. The profile also provides a set of

requirements for device manufactures to use as guidelines if they

want their devices to be CLDC and MIDP branded. For example,

the MIDP minimum display requirements are a 96 × 54 pixel

screen-size, a display depth of 1 bit, and a pixel shape (aspect

ratio) of approximately 1:1. Another MIDP minimum requirement

is memory, which is 128 Kbytes of RAM, 8 Kbytes of application-

created data, and 32 Kbytes of Java heap.



To enable the distribution of third-party MIDlets, developers must

generate a metadata file. Once they package an application (classes

and all auxiliary components) into a JAR file, the developers must

generate an associated Java Application Descriptor (JAD) and ship

it along with the JAR file. Toolkits exist to aid developers with the

packaging and to help them generate the JAR and JAD files. JAD

contains information that the JAM will use to properly verify and

configure the MIDlet application at loading time and that the

MIDlet will use during execution time.

MIDP has been created through the Java Community Process (see

the Java Specification Request JSR37 at http://

jcp.org/jsr/detail/37.jsp). The goal of the consortium that created

the MIDP (which consisted mainly of device manufacturers) was

to create an open third-party application development environment

for mobile information devices. Device manufacturers may include

additional original equipment manufacturer classes (such as APIs

optimized for packet data communication, gaming, or animated

images). MIDlet applications created or preinstalled on the device

by the manufacturers may use these additional classes and APIs.

Third-party developers, however, may not access the native device

operating system, or any OEM classes or applications. Figure 2.3

shows the architectural view of the relationships between the

KVM, CLDC, and MIDP layers.

2.1.4 Hello World MIDlet

Figure 2.4 shows a Hello World MIDlet. The MIDlet contains the

constructor method as well as the methods startApp(), pauseApp(),

and destroyApp(). It calls the first method when the application

starts or restarts after a pause state. It calls the pauseApp() during



the phone’s idle or paused mode and calls destroyApp() right

before it is unloaded. The JAM will create the Hello World

MIDlet, and then the public, no-argument constructor is called.

Figure 2.4. The Hello World MIDlet.

The JAM will then call theMIDlet’s startApp() method, which

loads the display to the instance of the Form class mainscreen. This

instance creates the Form used to hold the StringItem instance,

strItem, properly initialized to display “Hello World.” By

appending strings and many other components to the form, the

information is displayed into the Java phone.

Pervasive Java is a significant technology development that is

truly enabling mobile and pervasive computing. It is transforming


/** HelloWorld.java*/package com.mot.j2me.midlets.tutorials;import javax.microedition.lcdui.*;import javax.microedition.midlet.*;

/** A simple Hello World midlet*/public class HelloWorld extends MIDlet {

private Form mainscreen;private Display myDisplay;

HelloWorld1() {myDisplay = Display.getDisplay(this);mainscreen = new Form("Hello World");StringItem strItem = new StringItem("Hello", "HelloWorld");mainscreen.append(strItem);

}

public void startApp() throwsMIDletStateChangeException{

myDisplay.setCurrent(mainscreen);}protected void pauseApp() {}protected void destroyApp(boolean unconditional)

throws MIDletStateChangeException {}

}

/** HelloWorld.java*/package com.mot.j2me.midlets.tutorials;import javax.microedition.lcdui.*;import javax.microedition.midlet.*;

/** A simple Hello World midlet*/public class HelloWorld extends MIDlet {

private Form mainscreen;private Display myDisplay;

HelloWorld1() {myDisplay = Display.getDisplay(this);mainscreen = new Form("Hello World");StringItem strItem = new StringItem("Hello", "HelloWorld");mainscreen.append(strItem);

}

public void startApp() throwsMIDletStateChangeException{

myDisplay.setCurrent(mainscreen);}protected void pauseApp() {}protected void destroyApp(boolean unconditional)

throws MIDletStateChangeException {}

}


mobile devices and appliances from just “cool” gadgets into

essential players and integrated elements in the pervasive

computing world. By making mobile devices and appliances

smarter and by training them to speak the same language (allowing

baby devices to speak weaker dialects of the language), we’ve

come far closer to what a few pioneers in this field envisioned

years ago. The stage is now set to realize this vision, and the

opportunities are numerous to elevate and push the frontiers of

research and development, in pursuit of a better, more effective use

of computers in our lives.



Pervasive Java, Part II In the first issue, I covered Java 2, Micro Edition (J2ME)

technology, focusing on its Connection Limited Device

Configuration (CLDC) and Mobile Information Device Profile

(MIDP) (see the “Part I” sidebar). Here, I take a closer look at

J2ME’s business and commercial side, comparing several

development toolkits and addressing challenges the growing

community of J2ME developers faces.

2.2 J2ME PLATFORMS

Java-enabled phones and PDAs are a fast-growing market. Over

three million Java handsets have been sold since April 2001, and

companies are racing and teaming up with each other to capture a

piece of this new market. The main players are handset and PDA

manufacturers, wireless providers, Sun Micro-systems, and

companies specializing in software development tools.

GLOSSARY

3G Third-Generation Wireless Networks

CLDC Connected, Limited Device Configuration

IDE Integrated development environment

J2ME Java 2 Platform, Micro Edition

JCP Java Community Process

JSP Java Specification Request

MIDP Mobile Information Device Profile

OEM Original equipment manufacturer

PDA Personal Digital Assistant

PDAP PDA Profile



With new devices continually entering the marketplace, it would

be of little value to survey all available devices. Instead, I take a

quick sampling of Java-enabled phones and PDAs. For complete,

up-to-date information from over 12 different manufacturers, see

JavaMobiles (www.javamobiles.com), the MicroJava Network

(www.microjava.com/devices), and the Sun Microsystems Web

site (http://wireless.java.sun.com/device).

2.2.1 Java-enabled phones

I surveyed three markets: Japan, North America, and Europe.

Starting with Japan, its leading wireless provider, NTT DoCoMo,

was the first to adopt J2ME technology. Its Java-enabled i-mode

phones and services have attracted over 30 million subscribers

since February 1999. In fact, i-mode has been a success story for

DoCoMo, turning around its performance and revenues in the past

couple of years. Currently, i-mode phones don’t use the MIDP

profile (instead, they use DoJa or DoCoMo Java), but the company

plans to migrate the phones to the next MIDP generation (MIDP

2.0) by the end of the year.

Japan’s third-largest wireless carrier, J-Phone Communications,

has outlined its Java service for mobile phones and plans to offer

geographic information and multimedia services (with JPEG and

PNG graphics synchronized with sounds). The J-Phone group

offers several handsets based on J2ME technology, including a

built-in digital camera, color display, and 3D graphics engine,

which can display images with total freedom of perspective. The

service’s 3D features are offered in the form of J-Phone’s original

equipment manufacturer (OEM) proprietary Java library.



Mitsubishi, Matsushita, NEC, Sony, Fujitsu, Toshiba, and Sharp

are among the main handset manufacturers in the Japanese market

(see Figure 2.5).

Figure 2.5. A small sample of commercially available Java-

enabled phones.

PART 1

As I discussed in the January–March issue, J2ME specifications are divided into configurations that are specific to different device categories. Each configuration is further divided into profiles, which are specifications of particular types of devices within a device category. For instance, the Connected Limited Device Configuration is targeted toward devices with limited network connection. The Connected Device Configuration is a more powerful configuration targeted towards devices such as set top boxes. See the last issue’s column for further details.

In the US, Motorola introduced the world’s first MIDP-compliant

Java phone, the Motorola i85s. Motorola was also the first handset

manufacturer to introduce Java phones to the North American



market. The J2ME phones, serviced mainly by Nextel

Communications, are based on the iDEN wireless technology and

are currently directed at business users. The iDEN Java phones

provide OEM proprietary support for TCP/IP and mobile

networking, which makes these handsets unique in the North

American marketplace. Phones can be serviced with routable,

static IPs (a form of mobile IP), which lets the phones serve as

both mobile application clients and as mobile servers. Motorola

plans to move other handsets (for example, PCS and GSM) to the

J2ME platform.

SPECIFICATIONS

The specifications of the i95s, the first color-enabled J2ME mobile phone introduced in North America, are

Airlink Interface: iDEN/TDMA

Carrier: Nextel Communications

Platform/configuration/profiles: KVM/CLDC 1.0/MIDP 1.0

Display: 8-bit color display with PNG and JPEG support

Memory: The i95s has data memory, program memory,

and heap memory. The phones are supplied with approximately 1.5 Mbytes of data memory, approximately 1.5 Mbytes of program memory, and 640 Kbytes of heap memory. Data memory is used as an initial download storage of MIDlets, persistent storage for MIDlet programs available through APIs, and voice recordings handled by the native phone OS. Program memory stores a program in an executable image format after it has been loaded from the data memory, expanded, and verified. Heap memory is used for runtime execution of programs.

Network protocols: UDP and TCP/IP (wireless packet data,

including server sockets) and routable IP addressing (HTTP as well as SSL and HTTPS)

Serial interface: Java Serial Interface API

In January 2002, Sprint Communications announced its plans to

use third-generation phones from Hitachi when it launches its 3G



service in the US later this year. Sprint’s next-generation 3G

network (known as 3G1X) will provide up to 144-kbit-per-second

wireless packet data streams.

In one of the most ambitious efforts yet to use Java in cell phones,

mobile phone maker Nokia has announced that it will ship 50

million Java-enabled mobile phones by the end of 2002 and 100

million by 2003. The Finnish company wooed its biggest

competitors to join a mobile phone standard plan that will put Java,

among other features, in next-generation phones. If Nokia goes

through with its plans, the company could effectively increase the

number of existing Java phones by over 30 percent.

For space limitation, I list specifications for only one phone—the

Motorola i95cl (see the “Specifications” sidebar). It is the first

color-enabled Java phone to enter the US market, and it has

roughly twice the performance and features as the Motorola i85s.

(It is worth mentioning that this doubling in performance occurred

over 14 months.)

2.2.2 Java-enabled PDAs

So far, the only profile supported in commercially available

devices is the MIDP. Its capabilities are intentionally limited and

cannot replace native applications on PDAs such as the Palm,

PocketPC, or Nokia 9210 communicator. Nevertheless, J2ME is

supported on some of today’s PDA platforms, including the Palm

OS, RIM BlackBerry, and Windows CE (see Figure 2.6).

The Java Community Process (JCP) is developing a new CLDC

profile specification geared toward PDAs. This PDA Profile is

supposed to offer greater sophistication than MIDP, including a

richer user interface. The PDAP aims to provide a standard set of



Java APIs for small, resource-limited handheld devices

characterized as having

No less than 512 Kbytes total memory (ROM plus RAM)

available for 86 PERVASIVEcomputing

http://computer.org/pervasive Comparison of J2ME tools and

development toolkits. Java runtime and libraries, and no more

than 16 Mbytes total memory

Limited power, typically battery operated

UIs of varying degrees of sophistication with displays that have

a total resolution of at least 20,000 pixels, a pointing device,

and character input

Palm is actively driving the formation of the PDAP (Java

Specification Request 75, http://jcp.org) through the JCP.

Unfortunately, the PDAP has been so long in the making that it

might be too limited for where PDAs are headed and might not do

justice to the capabilities of a high-end device such as the Compaq

iPAQ. We will have to wait and see, but PDAP might be too little,

too late.

2.3 J2ME DEVELOPMENT TOOLKITS

To make business sense out of this emerging technology, we must

create a profitable community of J2ME developers. Online

communities such as the Motorola iDEN Developer Community

(www.idendev.com) and the Sprint PCS Application Developer

Program (www. developer.sprintpcs.com) offer shared resources

and communication forums among their registered developers. In

addition, handset manufacturers, carriers, and specialized software

productivity companies are offering several J2ME development



toolkits that aim to accelerate the process of introducing new

applications.

Figure 2.6. Sample Java-enabled PDAs.

J2ME developers must consider several factors when deciding

which toolkit best suits their needs. Developers also must often

deal with multiple toolkits, so knowing how they differ helps. Of

utmost importance are quality device emulators that can reliably

test a J2ME application on prospective devices. J2ME applications

also must pass through a preverification process, which lets the

desktop compiler verify that the compiled code can run with

J2ME’s K Virtual Machine (J2ME toolkits include pre-verification

tools that handle this process). In addition, several other features

such as packaging and debugging also play a role in deciding the

toolkit. Finally, most quality toolkits come complete with J2ME-

specific documentation and sample applications.

There are several different configurations available for the

software development kits. Some software packages presented here

are full-fledged J2ME software development kits with integrated

development environments (IDE), some are only development

front ends, and yet others are J2ME plug-ins to Java development

environments.

The following comparison of the main tools and software

development kits should help clarify the key aspects a developer



must examine when selecting a development environment (also see

Table 2.1).

2.3.1 CodeWarrior 6.0

CodeWarrior from Metrowerks combines an IDE with the original

MotoSDK development environment from Motorola

(www.metroworks.com/desktop/ java). Its MIDP support evolved

from a set of tools called the J2ME SDK Components Developer

Edition, formerly maintained and distributed by Motorola.

Developers can develop, debug, and test MIDlets using the

familiar CodeWarrior IDE but with the convenience of a graphical

user interface and menu-driven commands (the original MotoSDK

was command-line only). In addition, Code-Warrior 6 has more

bug fixes and enhancements, and developers can use Motorola

phone emulators to test MIDlets. The SKD comes with a JAD and

JAR packager and a handy debugger and preverifier.

2.3.2 Zucotto Wireless Whiteboard SDK

The Zucotto Wireless Whiteboard SDK is a free IDE and

emulation environment for developers to create and deploy J2ME

applications (www. zucotto.com/whiteboard/product_

downloads.html). The basic version (as well as support) is free, but

if you want the Bluetooth version, it will cost you some money.

The Zucotto package is by far the best overall package. It even

comes with a PNG editor for creating and editing the PNG

graphics files to be displayed in your MIDlet. This IDE is derived

from the Net-Beans package, so the interface looks similar to

Sun’s Forte interface (also derived from NetBeans). The software





development kit is the first to extend Bluetooth functionality to

wireless Java application development. This will come in handy

for emerging phones with integrated Bluetooth. Some of the

distinctive features include seamless creation of jad/jar files,

source-level debugging with multilevel tracing, a PNG Painter to

create colorful MIDP-compliant images, excellent documentation

to simplify development, and easy-toreuse templates and code

samples.

2.3.3 Sun Forte for Java

Forte for Java is a complete Java development environment

available from Sun (www.sun.com/forte). The Community Edition

is free, but commercial versions are available that have more

powerful functionality. Forte for Java supports Java development

in general with a configuration section for specific libraries and

compilers. You can set it up for Java IDE to use different J2ME

plug-ins, but you must set up Forte before installing the plug-in.

Forte 3.0 requires Java 2 1.3.1. It also requires the Netscape

browser version 4.7 or above.

2.3.4 Borland’s JBuilder 5.0 Personal and Mobileset

Combining Borland’s JBuilder 5.0 Personal and its Mobileset add-

on package (www.borland.com/jbuilder/ mobileset) lets developers

create MIDP applications and test them using one of three toolkits:

Sun’s Wireless Toolkit (any phone), Nokia’s Developer’s Suite for

J2ME (Nokia phones), or the Siemens Mobility Toolkit (Siemens

phones). JBuilder contains perhaps the nicest GUI features, such as

“drag and drop” creation of MIDlets and their resources. Similar to



CodeWarrior and Whiteboard, Jbuilder and Mobileset include

prime features such as a packager, debugger, and device editor.

They also offer clear online documentation. A free personal edition

is available, but it doesn’t package the jad and jar files for you.

2.3.5 IBM VisualAge Micro Edition

VisualAge Micro Edition is an IDE with a comprehensive set of

tools and runtime components for developing and deploying Java

applications on connected embedded devices (www.embedded.oti.

com). At its core is the J9 virtual machine, which is a single-

sourced, multiple processor and platform combination, a feature

that increases virtual-machine quality and provides a portability

layer. The latter gives developers the flexibility they need to port

applications to new processors and platforms quickly and easily.

The new J2ME Java Powered compatible configurations

(MIDP/CLDC) let developers create devices that can host several

applications written to the specifications. The combination of

virtual machine and J2ME Java Powered configurations and

profiles delivered across multiple target platforms, along with

integrated tooling, is an industry first.

However, IBM’s IDE differs from the others covered in this

column. It is built from a previous version that lets embedded Java

developers create their applications targeting the IBM J9 JVM.

This new version also allows the creation of J2ME applications,

although there is no device emulator available for it yet. This is a

professional package, but it is not integrated well for developers

who want to get set up and running quickly. It appears to be more

suited for embedded Java development.



2.3.6 Sun’s wireless toolkit

Sun’s toolkit is most appealing because it comes from the Java and

J2ME creator (http://java.sun.com/ products/j2mewtoolkit). There

is a version for Solaris and Linux, but Sun does not fully support it.

I tested one of the Windows packages (Windows 98/NT/ 2K

supported).

The toolkit requires the Java 2 Standard Edition 1.3.0 or higher. It

does not come with an editor, but does come with a special GUI

for compiling, preverifying, jad/jar file packaging, and device

emulation. The default development environment that the toolkit

supports is known as Ktoolbar, which lets developers edit project

settings using a GUI and select from a range of emulators to test

the application. The Sun toolkit installs nicely, and the user guide

that comes with it gets you started quickly. It explains how to run

an example MIDlet and create your own using one of many

different templates.

Although KToolbar is a great first step for J2ME beginners, the

toolkit can also integrate with Sun’s Forte development

environment to provide a full-featured J2ME solution with

sophisticated IDE. At the University of Florida, my students

and I took one of our own MIDlets we wrote and used the Forte

IDE to create a new MIDlet suite and to compile and emulate it.

Everything worked smoothly. The emulator includes several

default “skins” such as a color- and grayscalescreen mobile phone

and a two-way pager.

The latest version of the toolkit (1.0.4 Beta) became freely

available just before this issue went to press. It seems to include

powerful features such as support for profiling MIDlet’s

performance (memory, networking, methods, and so forth) as well



as support for obfuscators. The new version also provides much

better options for defining parameters of the target MIDP device’s

virtual machine. This is a great feature for the developer, which

lets him or her match the emulator’s performance with that of the

target device.

2.3.7 Nokia toolkit (beta)

The Nokia toolkit, which is available for free, comes with a GUI

interface to compile, package the jad/jar files, and emulate Nokia

devices (http://americas. forum.nokia.com/java/default.asp). This

package can be integrated into Sun’s Forte for Java or Borland’s

JBuilder to provide GUI project management functions. The only

device emulator provided is Nokia’s emulator.

2.3.8 Siemens Mobility Toolkit (beta)

The Siemens Mobility Toolkit is a set of tools based around

Siemens’s SL45i and 6688i mobile phones (www. siemens-

mobile.com). The SDK has two versions, a SL45i version for

European markets and a 6688i version (both available for free),

which includes emulator support for Chinese characters. The SDK

includes an emulator, the CLDC and MIDP classes, Siemens-

specific classes, and documentation. It comes with its own

emulator as well as command-line tools for compiling and

packaging the jad/jar combination. We can integrate this package,

like Sun’s WTK and Nokia’s Toolkit, into Sun’s Forte for Java or

Borland’s JBuilder to provide a GUI project management

functions. The only device emulator provided is a Siemens

emulator. Several other features, such as a device editor, are not

present in this toolkit.



Several challenges and uncertainties face application developers

that could limit pervasive Java’s progress. However, challenges

often bring new opportunities for creative research and better

practices.

For practical reasons, developers extensively use a device emulator

(of the type and “skin” of a target device) throughout most of an

application’s development and testing cycles. This unavoidable

emulation could be a major source of discrepancy between the

behavior of a MIDlet running on a given device emulator and that

running on an actual device, which raises a serious uncertainty

problem for the J2ME developer.

Another unexpected problem facing developers is the potential

difficulty in porting MIDlets across different MIDP devices. Each

device manufacturer can add its OEM’s “exotic features” to MIDP

in the form of an API. This has quickly led to market

fragmentation, which is contrary to the portability spirit of Java.

Developers will have to weigh the benefits of specializing their

applications for a specific device against the ease of porting their

MIDlets across multiple MIDP devices.

Developers could face another serious problem if they are unable

to freely download applications to MIDP devices. Consider the

wireless telecom industry. Currently, carriers attempt to stick to

their business territories when they deal with pervasive Java. One

legitimate goal is to increase revenue streams by selling minutes

(or packets) to subscribers and businesses. Another goal is to

safeguard against losing any business due to the loaded

applications (imagine voice over IP over Bluetooth on the phone).

Toward these goals, carriers are actively pursuing control of

application distribution to their subscribers’ Java phones.

Developers must follow whatever procedures the different carriers



set forth to be allowed to download MIDlets to the phones. This

could range from a registration requirement to signing legal

contracts.

Finally, developers risk lack of support for network-side

developments (especially Web services) in their development

processes. Most development toolkits focus on the MIDlet client,

which is certainly important. However, networked applications are

bound to use a “proxy” between the MIDlets and the network

resources and Web services. There is currently no support

available for developers to create MIDlet proxies. Many

functionalities and responsibilities of a MIDlet proxy are common

or at least similar, leading to code redundancy. For example,

protocol and graphics conversion are two examples of simple

adaptation tasks that any MIDlet proxy will have to perform.

Integrating MIDlet proxy support into J2ME Toolkits will speed

up development of the full application. Of late, the JSP has

proposed a Java Specification Request to address this need (JSR

172, accessible from http://jcp.org).



The .NET Compact Framework

EDITOR’S INTRODUCTION

The .NET Compact Framework lets developers easily and efficiently build robust applications that call XML Web services, thereby letting end users effectively access remote data, cache it locally for use when offline, and interact with it via rich user interfaces. This invited piece, written by Microsoft’s Craig Neable, highlights the .NET Compact Framework’s design goals, sheds light on what the first version contains, and speculates on future directions. —Sumi Helal

Over the last decade, three noteworthy trends have occurred—the

intersection of which has naturally led to the development of the

Microsoft .NET Compact Framework.

The first trend was the popularization of sophisticated development

and runtime environments that increase developer productivity and

application robustness. These environments offer features such as

integrated type safety at runtime, memory management (including

garbage collection), and a standardized, rich programming

framework that implements commonly used functionality. Such

environments become even more powerful when coupled with

development tools specifically designed to host and target their

complementary runtime environments. Microsoft Visual

Studio .NET and the .NET Framework are such a combination,

released in February 2002 and targeting Microsoft Windows.

The .NET Compact Framework was a natural extension, bringing

this high-productivity environment to devices with more limited

resources than desktop PCs.

The second trend was the impetus to write applications that

provide information and services in a wider variety of situations

than previously associated with traditional PCs. Specifically,

developers started writing applications targeting small devices



including PDAs, mobile phones, and various other embedded

devices. One major barrier for developing applications on these

types of devices, however, has been the deficiency of developer

skills and knowledge. Both the .NET Compact Framework and

the .NET Framework are based on the ECMA Common Language

Infrastructure standard (see the “What Is the CLI?” sidebar). So,

both source code and compiled binaries can run across Windows-

based desktops and servers and various other devices and

processors, thereby offering improved productivity and efficiency.

This is not to say that applications written for a server would

necessarily be useful running directly on a device, but it is a

testament to the portability of programming skills between these

two different targets.

WHAT IS THE CLI?

The CLI is an ECMA standard. It defines how to create applications in multiple high-level languages that can execute in different system environments without rewriting applications to consider each programming language or runtime environment’s specific characteristics. The CLI specifies many things to abstract these differences, including a file format for executables, a type system, a metadata system for binaries, the Microsoft Intermediate Language executed in the common language runtime, and a definition of the required base class libraries and how they should be factored. For more information, see www.ecma.ch.

The third trend was that developers throughout academia and

industry recognized that the Web is a well-deployed infrastructure

over which they can effectively connect applications. Therefore,

they have congregated and collaborated to standardize protocols

for doing so including SOAP and WSDL (Web Service

Description Language). (See the “Glossary” sidebar for terms used

throughout this department.) These protocols, generally known

collectively as XML Web services, are redefining how we think


http://www.ecma.ch/


about distributed data. Like the .NET Framework, Microsoft

designed the .NET Compact Framework from the ground up so

that it could easily access remote data using these Internet standard

protocols. It thus puts smart devices on par with PCs in terms of

their ability to access such data.

With its general availability in early 2003, the .NET Compact

Framework will offer developers a familiar, safe, and robust

programming environment that increases productivity. Developers

can use skills that they deploy for desktop and server development

directly on devices. Microsoft designed the .NET Compact

Framework to perform optimally on resource-constrained devices

and to let it call XML Web services as a central and native

platform component. It will release the platform simultaneously

with tools functionality in Visual Studio .NET, allowing end-to-

end development for devices running Windows CE.

2.4 NUTS AND BOLTS

In contrast to the .NET Framework, which is available for the

desktop or server running Windows, the .NET Compact

Framework is designed to run on a variety of different operating

systems and has a unique architecture to provide for this cross-OS

functionality. Known as the Platform Adaptation Layer, this

architecture provides an abstraction layer between the host

operating system’s specific APIs and the .NET Compact

Framework’s requirements. In the future, the .NET Compact

Framework could easily be ported to other host operating systems

by creating a corresponding PAL to match the common language

runtime’s (CLR) requirements and the new host operating system’s

capabilities.



Built on top of the PAL (see Figure 2.7), the .NET Compact

Framework implements a CLR. The runtime can run Microsoft

Intermediate Language, a processor-independent, model operation

code language that the compiler emits. It does this using a just-in-

time compiler (JIT) to convert this MSIL to the specific

processor’s machine code. For each processor the .NET Compact

Framework supports, there is a corresponding runtime

implementation that JIT compiles and that runs the applications.

The .NET Compact Framework supports all of the processors that

the Windows CE operating system supports, including

StrongARM, MIPS, x86, SH4, XScale, and several other related

processors.

GLOSSARY

CLI Common Language Infrastructure

CLR Common language runtime

JIT Just-in-time compiler

MSIL Microsoft Intermediate Language

PAL Platform Adaptation Layer

WSDL Web Service Description Language

Built on top of the CLR is the programming infrastructure from

which the entire system gets its name, the .NET Compact

Framework. The .NET Compact Framework’s core is a set of CLI-

compliant base class libraries that provide building block

functionality for all applications including basic file I/O,

networking, and XML.

In addition to meeting these ECMA-defined specifications,

the .NET Compact Framework includes higher-level functionality

such as XML Web service support and a graphics and Windows

Forms library that exploits the graphics capabilities of the

Windows CE operating system and Microsoft Pocket PC. An



interoperability mechanism that manages calls between the CLR

and natively compiled system components provides access to the

Figure 2.7. The .NET Component Framework.

platform’s native software components. Finally, the .NET Compact

Framework implements ADO.NET, the data-access technology

available in the .NET Framework. This data-access model consists

of an in-memory relation store that easily persists on disk as an

XML file or mapped to a device or server database. This lets

developers access data easily from remote databases, handle it in

memory, store it in local sources, and synchronize local sources

with remote ones.

2.5 CHOOSING THE RIGHT

PROGRAMMING LANGUAGE

Like the .NET Framework, the .NET Compact Framework answers

the age-old question, “What language is best?” Its novel response



is, “It doesn’t matter!” All code is compiled first to MSIL and then

to native code. Therefore, how the MSIL was originally created

does not impact the JIT, so developers can choose the language

best suited to the task at hand.

Microsoft currently supports two languages on the .NET Compact

Framework; C# (pronounced C-sharp) and Visual Basic .NET.

Because of this sourcecode-agnostic platform, Microsoft or third-

party language vendors might eventually add support for other

languages to meet developers’ language preference demands.

Indeed, at the time of writing this article, several independent

language and tools vendors are implementing their own languages

on the .NET Compact Framework.

2.6 BRINGING BIG FEATURES TO

SMALL DEVICES

The fundamental problems in designing the .NET Compact

Framework revolve around one concept: how to redesign and

refactor the feature-rich .NET Framework, which is designed to

run on desktop PCs and servers. Machines running the .NET

Framework typically run on Pentium-class or higher processors

with copious memory, whereas the .NET Compact Framework’s

hosts are small devices with few megabytes of memory and

processing speeds that might not even reach the triple digits. Thus,

the design goals were twofold:

Decrease the system’s footprint from the 20-plus Mbytes that

appear on machines running Windows to approximately 1.5

Mbytes.



Optimize the common language runtime’s various components

to provide the fastest-possible execution time on small devices.

2.6.1 The foundation: Execution and memory

management

The common language runtime must use JIT to compile code to

run on the host device and manage the memory available to

maximize the device’s performance.

In the .NET Compact Framework, the optimized JIT compiles

from MSIL to native code on a method-by-method or type-by-type

basis. It does not compile a segment of MSIL containing a

particular method or type to native code until the first time it is

called. Once it compiles that method, it caches the natively

compiled code for later reuse. The obvious advantage to this

system—compared to an interpreter-based system—is that each

and every time a particular method is called, it does not need to be

recompiled but, rather, can run as instructions native to the

processor. This adds overhead on the first method call in a

particular instance of an application. However, this cost is

amortized over subsequent calls of the method, bringing the

execution close to native speed over the life of the application and

reducing battery consumption by running more efficient code.

To optimize the memory used for execution, the CLR also has the

prerogative in situations of extreme memory pressure to “pitch”

compiled code—that is, to throw cached code out of memory to

provide a larger space in which the application can continue to run.

This happens only in extreme situations, such as when the

application loads large volumes of data into memory. It lets the



CLR reclaim memory occupied by seldom-run code to store data

or cache code that is run more frequently.

Finally, the garbage collector cleans up after the developer, while

the running application allocates and discards objects and types.

The garbage collector is a simple mark-and-sweep collector that

periodically marks memory that is marked for edit—that is,

memory containing objects and types no longer in scope. When the

ratio of marked memory to in-use memory hits a certain threshold,

heap compaction occurs, creating larger open pieces of memory

that the runtime can reallocate to the application for either code or

data storage.

The obvious advantage to this system is that each time a particular

method is called, it does not need to be recompiled but, rather, can

run as instructions native to the processor.

2.6.2 The building blocks: The .NET compact

framework libraries

The base class libraries are the fundamental building blocks of

every application. These are the libraries that provide such things

as file I/O, collections, primitive drawing types, localization and

globalization, and XML handling. These libraries provide a great

deal of functionality without requiring developers to reimplement

commonly used functionality every time they undertake a new

project.



2.6.3 Making connections: Networking and XML

Web services

The most interesting device applications are connected, which is

why Microsoft made it easy to connect the devices and share data

between them. At the network stack’s lowest level, the .NET

Compact Framework exposes both synchronous and asynchronous

socket operations to developers. Built on top of this model is a

richer HTTP layer, which lets developers build applications that

leverage the biggest data network in the world—the Internet.

At the most functionally rich end of the spectrum, the .NET

Compact Framework implements the SOAP 1.1 protocol

specification, which lets developers call remote methods over

HTTP and programmatically deal with the information returned at

the application level. This functionality puts devices on par with

other machines in distributed network architectures. Finally, many

small devices are enabled with infrared functionality, and the .NET

Compact Framework has built-in support to let people establish

connections and move data to other devices over this simple peer-

to-peer transport.

2.6.4 Data is power: Data access

On top of the base classes sits the ADO.NET components that

allow data access and handling. In the first version of the .NET

Compact Framework, there are two data providers that let

developers interact with specific data stores. One data provider lets

developers access Microsoft SQL Server 2000 on remote servers,

and another lets them access SQL Server CE, a local database that

runs on the device. SQL Server CE lets developers cache large



volumes of data on the device such that the data can be used while

offline; SQL Server CE also provides a synchronization

mechanism back to SQL Server.

This proves to be a powerful combination for developers,

simplifying mobile data access. In a few simple lines of code, the

developer can pull large volumes of data on the order of tens of

Mbytes down to the device. The device can then read and update

the data while the application works in a disconnected mode. Then,

another simple line of code lets the device synchronize changes

made to this data with the original server.

2.7 CHALLENGES AHEAD

Many difficult challenges undertaken with the .NET Compact

Framework—in particular, the functionalityto-performance ratio

and size—have proven to be within the system’s capabilities, as

each new preview and beta release move closer to the original

goals. Furthermore, Microsoft will continue to add more features

and functionality, working around design constraints.

Although the .NET Compact Framework solves many mobile

development problems, it does not completely solve some

particularly interesting development areas. These are the

challenges that application mobility and distributed networks

present.

One interesting and compelling problem the .NET Compact

Framework will continue to pursue through future releases is

increasingly better adoption of mobilephone-specific technology.

The types of functionality specific to mobile phones include using

text messages as a data transport between devices. Also, network



conditions over which devices—especially mobile phones—must

communicate typically tend to be more transient and unreliable

than traditional, permanently connected PCs. Other interesting

areas of development, however, do not completely pertain to the

implementation of the .NET Compact Framework but rather to the

challenges presented by application mobility and distributed

networks in general.

Another important area where the .NET Compact Framework will

strive to add value is in implementing and abstracting the ever-

emerging relevant standard protocols for sending data, messages,

and services to mobile devices over the network. Today, it is

difficult to move data to devices regardless of the particular

network the device is on, because simply addressing a device that

changes an IP address is frequently challenging. Because mobile

devices inherently have some of the greatest networking

requirements, they will be a strong testing ground for APIs that

support programming to these standards.

Finally, .NET Compact Framework development will continue to

extend into other form factors of devices. While the majority of

development with the .NET Compact Framework is likely to be on

PDAs and high-level mobile phones, other types of devices will

come into focus as demand grows for a rich

Because mobile devices inherently have some of the greatest

networking requirements, they will be a strong testing ground for

APIs that support programming to these standards.

development environment that is efficient for programming. This

presents perhaps the biggest challenge to the .NET Compact

Framework’s future development—to maximize portability of

applications and programming skills among different device form



factors without compromising the ability of applications to exploit

the unique and powerful resources for each of these different

platforms and form factors. Developers will want to minimize the

differences between similar applications for maintenance reasons.

However, applications that run identically on all form factors of

devices do not take full advantage of any of those platforms, so

they do not give end users the most dynamic application

experience. Providing the right level of abstraction of common

features has been—and will continue to be—one of the greatest

challenges, minimizing development efforts and maximizing end-

user experiences.

ith its release in early 2003, the .NET Compact Framework will

give devices the functionality that developers have come to expect

from modern, safe PC environments. The .NET Compact

Framework replicates this functionality so well that at a source-

code level, it is often impossible to tell whether the code was

written for a PC running the .NET Framework or a mobile phone

running the .NET Compact Framework. The .NET Compact

Framework lets developers take existing code and investment in an

application built for a PC and, with little modification, run it on a

variety of smart devices. It also lets devices participate in network

architectures on parity with other machines by letting them easily

consume XML Web services, display and process data locally, and

synchronize data back into the original source. The ultimate goal is

to open an entirely new opportunity for software developers

worldwide, letting them efficiently create solutions in the new and

exciting realm of mobile applications.



WAP: Present and Future

In 1997, several wireless-phone manufacturers organized an

industry group called the Wireless Application Protocol forum.

This group defined the WAP specification in the form of a long,

describes technical document series that defines standards for

implementing wireless-network applications. Hundreds of

industries strongly supported the WAP forum for standardization

to help the technology become widely adopted.

Unfortunately, most of the enthusiasm surrounding WAP has

evaporated owing to inherently low channel bandwidth, increased

round-trip delays, and a lack of security. WAP technology is

primitive and still evolving, and its future depends on how quickly

it can improve the transfer rate and effectively enhance its business

model.

2.8 THE WAP ARCHITECTURE

In the last few years, WAP has emerged as a standard Internet-

enabling wireless protocol and a browser framework for small,

limited-display-capable devices. WAP allows Internet access to

cell phones, PDAs, and other low-computational-power devices. In

addition, the lightweight WAP protocol has a layered architecture

and is designed to operate over a variety of wireless services,

including Code Division Multiple Access, Cellular Digital Packet

Data, General Packet Radio Service (GPRS), and so on.2.1 (For

more information on the layered architecture, see the “WAP

Layers” sidebar.)



Based on Internet standards such as HTTP, WAP wireless

protocols2.2–2.4 require transferring large amounts of mainly text-

based data. The WAP standard consists of two essential elements:

an end-to-end application protocol and an application environment

based on the browser. The application protocol is a communication

stack embedded in each WAP-enabled wireless device (also known

as the user agent). The server side defined as a WAP gateway

implements the other end of the protocol, which can communicate

with any WAP client.

The WAP network structure (see Figure 2.82.5) sets up a session

using these steps:2.6,2.7

1. A mobile telephone sends WAP requests to a WAP gateway.

2. The gateway, upon receiving a WAP request, sends an HTTP

request to a plain Web server, which provides the content

through a normal HTTP response (the Web server perceives

the gateway as a proxy server).

3. The gateway converts the HTTP response into a WAP response

for the mobile device.

4. The microbrowser in the mobile terminal interprets the

response and displays it appropriately.

2.9 WAP SUPPORTING COMPONENTS

WAP technology has three major supporting components. The first

is the Wireless Markup Language. WML is the WAP equivalent to

HTML and is based on XML.2.8 It makes optimal use of small

screens, with a built-in scalability from two-line text displays to

the full graphic screens on smart phones and communication

devices. The Wireless Application Environment specification



defines the syntax, variables, and elements used in a valid WML

file. WML employs the concept of decks and cards. Each card is a

frame displayed on the screen. We refer to a logical collection of

interlinked cards as a deck, usually stored in a single WML file.

The second is WMLScript, a client-side scripting language used

with WML that makes WML pages dynamic (similar to what

JavaScript2.9 allows with HTML). WMLScript makes minimal

demands on memory and CPU usage, omitting a number of

functions that are not required and that are present in other

scripting languages for wireless applications. Regular scripting

languages are resource intensive and can’t be used to display

interactive pages on a mobile phone. WMLScript is a scaled-down,

simplified script, developed specifically to fit the WAP

architecture of decks and cards. It lets the developer provide inter-

activity in WAP pages without taxing the valuable wireless

resources.

The third supporting component is Wireless Bitmaps. WBMP is

the default picture format for WAP. WBMPs are uncompressed,

monochrome blackand-white bitmaps for use in devices with small

screens and narrow bandwidth connections (see Figure 2.9).

However, the screen size and bandwidth, along with limited

graphics capabilities, are WBMP’s major constraints. Recent

developments in display technology provide color bitmaps for the

latest WAP browsers.

WAP LAYERS

The WAP protocol stack has five layers: application, session, transaction, security, and transport (see Figure A1). Each layer performs almost the same functions as the corresponding layers of the Internet model.

Application

The application layer consists of the Wireless Application Environment



and user agents. The most common type of user agent in the WAP architecture is a browser meant to interpret Wireless Markup Language and WMLScript. User agents that endeavor to provide services beyond those of a browser generally take advantage of the WAP specification’s Wireless Telephony Application features.

Session

The Wireless Session Protocol presents the application layer with a way to uniformly receive both “reliable” connection-oriented and “unreliable” connectionless transmissions.The WSP facilitates transmission mechanisms such as

• Providing HTTP functionality

• Enabling users to participate in long-lived data transmission sessions

• Allowing a server application to determine whether a client can support certain protocol facilities and configurations (this is known as “a capability negotiation”)

Transaction

The Wireless Transaction Protocol handles requests and responses to and from the user agent to the application server. The WTP concentrates on transaction services for online activities such as Web browsing. It is designed to decrease the number of transaction phases that typical wired-oriented protocols require.



Figure A. The five Wireless Application Protocol layers.1

Security

The Wireless Transport Layer Security implements many features to ensure secure data transmissions and to protect the users, the network and service operators, and the functionality of the upper layers of the WAP stack. The WTLS provides safe data transmission that could support services requiring a high level of security such as mobile e-commerce.

Transport

The Wireless Datagram Protocol transmits and receives data to and from the user agents. The WDP can exchange information with many types of wireless data carrier technologies or “bearers.” It effectively hides the differences in bearer technologies from the rest of the stack and provides a common interface to the upper-layer protocols. Layers can function independently of the underlying network and the wireless devices.

REFERENCE

1. D.P. Agrawal and Q.-A. Zeng, Introduction to Wireless and Mobile Systems, Brooks/Cole Publishing, Pacific Grove, Calif., 2003.

2.10 WAP ADVANTAGES

Many inherent WAP characteristics offer major advantages. First,

WAP saves time and money. A WAP-based application’s ability to

send and receive data in real time lets companies make field

changes and coordinate their staff more efficiently. Companies can

also speed up and automate their distribution cycle, thus

minimizing the required manpower.

Second, there’s no hardware obsolescence. One of the greatest

concerns for companies with mobile workers is the huge

investment in handheld hardware. Companies would be interested



if the standard could work on legacy hardware. This would help

them increase the lifetime of their prior ter decision-making and

enhanced business performance.

In addition, WAP’s invention has led to the development of WAP

telephony applications that add a telephony element to the basic

WAP infrastructure and make existing wireless network

capabilities available to enhance WAP services. WTAs provide a

framework for integrating wireless data and voice capabilities to

create innovative services.

Figure 2.8. A Wireless Application Protocol network architecture.

2.11 WAP CRITIQUES

Just as there is no dearth of WAP supporters, the number of WAP

bashers is growing. WAP technology is not flawless, and criticism



from leading technologists fall into the following categories.

Figure 2.9. Two images: (a) normal and (b) Wireless Bitmap.

2.11.1 WAP as a band-aid

WAP critics say that WAP is only a temporary fix. We will need it

only until greater bandwidth in the communication channel and

increased functionality in the personal terminal are widely

available. GPRS-enabled PDAs, which deliver

28.8 kbps, are already hitting the European market. Carriers such

as Verizon and Sprint are building 3G networks capable of

handling data and video.

2.11.2 Wrong bearer services

WAP is expensive when used with current bearer technologies.

With circuit-switched data, we can expect long connection calls for

any application that uses interactivity with the Internet or that lets

the user select more information.

2.11.3 Weak link

The WAP gateway must decrypt secure data coming from a caller

using Wireless Transport Layer Security, and then it must re-



encrypt the data before forwarding it to the bank or credit card

company (or anyone else receiving it). The reverse must also be

maintained. There is a window of vulnerability when the data is

momentarily unencrypted.

2.11.4 WAP designer’s nightmare

One of the biggest problems WAP developers face is that their

applications will likely be rendered in many different ways on

different mobile phones. Old WAP browsers support HDML

(Handheld Device Markup Language); later browsers support

WML. Different browsers treat certain tags and commands in

different ways, and myriad devices with the same browser also

function unpredictably. Generally, this lack of coordination among

handset providers, browsers, emulators, and the WAP standard

creates a frustrating environment for even the best developers.

2.11.5 User experience

So far, WAP has not lived up to its promise of being an exciting

way to access the Internet. Tradeoffs between functionality,

performance, and design have dampened user experiences. WAP

applications with broken links seem to be the norm, not the

exception. Some people have difficulty just figuring out how to

access the microbrowser on their mobile handset. Furthermore,

after waiting for 30 to 45 seconds to connect, users find what looks

like a walled garden that allows access only to certain sites. Access

to options such as “go to other sites” is cumbersome and

frustrating. Inputting a valid WAP URL through the existing

numeric keyboard is tedious.



2.11.6 Killer applications

The hype involving WAP has centered on the killer applications,

which were touted to herald a new era of mobile commerce.

However, even after almost five years of WAP development, a

stable killer application has yet to see the light of day. Many have

not yet been developed or, if developed, have not been marketed

well enough to catch consumers’ attention.

2.11.7 Pricing

The pricing of WAP services has been problematic for both

developers and consumers. On the developer side, operators have

not shared the wealth with content providers and have essentially

made it difficult for content providers to get any sort of valid return

for their efforts. No true, measurable incentives exist to develop

WAP content in the absence of wireless advertising and other

revenue agreements.

Many carriers offer an expensive flat-rate pricing fee to consumers,

in addition to subtracting voice minutes for time spent on data.

This impacts WAP services in two ways. First, carriers have no

efficient mechanism to establish fair revenue sharing with content

providers. Second, consumers are historically price-sensitive in the

services industry and view WAP as too expensive. An example of

how a correct business model can help WAP is Telesim, Turkey’s

second-largest GSM operator. It eliminated its monthly fee for

WAP usage and experienced a tenfold growth in its subscribers.



2.12 THIN VERSUS FAT CLIENTS

WAP, also implemented as a thin client, uses a centralized server

to store, fetch, and send data. The meager storage and low-memory

capacity would be sufficient to run varied applications using a thin

client. Remote-server-handling capability depends on the

bandwidth of the communication media between the server and the

client. On the other hand, fat clients implemented by Java 2 Micro

Edition and the .NET Compact Framework make storage and

processing more local than done remotely (for more information

on J2ME, see the Jan.–Mar. and Apr.–June 2002 installments of

this department; for information on .NETCF, see the July–Sept.

2002 installment). Fat clients require large memory and storage

capacities.

Each client type has its advantages and disadvantages. However, it

is difficult to say which is better, because both are application

oriented and the technology is constrained by technological

limitations. Whether wireless messaging should employ a thin or

fat client is still debatable.

The obvious disadvantage of a thin client might be its limited

feature set, which could worsen user experiences. Fat clients face

the storage constraints and limited processing power of mobile

devices. Applications such as the Virtual Private Network

(www.vpnc.org) and Virtual Network Connectivity (www.uk.

research.att.com/vnc) have allowed virtual access to desktops from

any computer. These technologies rely on the large bandwidth of

the wired medium. Much research has shown that thin-client

technology for desktops might not be a good practice for PC

management.2.10



The latest developments in memory and storage technologies for

handheld devices are enabling fat-client architecture by reducing

the burden on the bandwidth, because local processing would

eliminate some of the data transfer done at the remote server.

Because mobile devices go wherever we go, WAP technology

makes them suitable for the current storage, memory, and

processing capabilities of mobile devices. Unless there are

astronomical advances in the wireless medium to allow larger

bandwidths, fat clients seem to be the way to go for future

handheld devices.

AP optimists have been quick to rebut WAP shortcomings. WAP

security has been enhanced in the new version 2.0, and most

shortcomings have more to do with an inadequate business model

than the WAP technology itself. Also, analysts suggest that if

WAP is incompatible with current technologies, GPRS might

make it more practical.

WAP is an application protocol suite designed to function over any

bearer service. This is where GPRS comes into practice as an ideal

bearer for WAP resource requirements; its higher transfer rates are

needed to accommodate WAP’s unusually complex and frequent

network resource requirements. Furthermore, the increased

bandwidth will allow better and more varied applications with

pictures, video, and sound. Japan and South Korea are already

carrying packet data on their networks, and Europe is adhering to

the GSM standard

with many confirmed GPRS contracts. WAP technology could

bring about the convergence of mobile communications and the

Internet. With any newtechnology come risks, bugs, and

opportunities. With WAP, the opportunity and adventure definitely

outweigh the risks. However, WAP has not lived up to its lofty



expectations, and its growth has taken a beating. In responding to

the recent backlash against WAP, advocates quickly point out that

WAP exists today in a very primitive form.

Still, with the introduction of much faster bearer services such as

GPRS or UMTS and a proper consumer-oriented business model,

the struggling WAP might just get a much-needed lifeline.



Surviving Java for Mobiles

Mobile devices are gaining popularity worldwide, and constant

hardware improvement is increasing their computational power

every year. So, we can now equip mobile devices with more

powerful applications.

One of the most promising software platforms for mobile devices

is Java 2 Micro Edition. Sun representatives assert that 18 to 20

million mobile phones support the J2ME platform.2.11 Analysts

predict that within the next few years, this technology will become

omnipresent. According to Gartner Group estimates, in 2006,

approximately 80 percent of mobile phones will support Java.2.11

(For an introduction to Java for mobiles, see the Jan.–Mar. 2002

and Apr.–June 2002 installments of this column).

In our experience in creating applications for Java-enabled mobile

devices, we’ve had to deal with several unforeseen problems not

typical of desktop Java development projects. Unfortunately,

literature on the subject has only fleetingly mentioned most of

these problems. Here, we describe some of them and propose our

solutions.

2.13 DEVELOPING JAVA

APPLICATIONS FOR MOBILE

DEVICES

Software development is always constrained by the target

platform’s capabilities. This is especially true for the “ultralight”



J2ME platform, because developers face many difficulties related

to the platform’s physical limitations. These difficulties include:

The size of the application and its data (many business-class

mobile devices with more memory exist, but size is still a

problem for an overwhelming majority of phones— including

mass-market phones currently produced for entertainment

purposes and “legacy” phones still widely used)

Intermittent network connections with lower bandwidth

Small display size, which can cause problems for creating an

acceptable user interface

Primitive facilities for inputting text information

All these distinctive J2ME features are defined in the Connected

Limited Device Configuration (CLDC), which provides

specifications for all Java-enabled mobile phones and most PDAs.

2.13.1 Games for J2ME devices

Our first J2ME development projects were games for Java-enabled

mobile phones.

The initial task was to develop a demo application for illustrating

J2ME platform capabilities. We borrowed the first game’s script

from a traditional computer game, in which the user controls a

submarine and tries to destroy all enemies without dying (see

Figure 2.10). The game could store the best records and update

them using an HTTP server. It used a true-color image set and

looked best on mobile phones with a color display.



For the second game, we implemented an original scenario from

our client company in which the user controls a balloon. The goal

is to travel from the starting point to the terminal without colliding

with hills, birds, and so forth. For this game, we created a map

editor for the various levels to provide a user-friendly interface for

game designers and to store the data in a compressed binary form.

The main problem we encountered when developing these games

was minimizing each game and its data’s size to produce an

acceptable start-up time. For instance, the application size limit for

most popular Java-enabled phones was approximately 30 Kbytes.

However, remaining within this size limit using the usual coding

approaches is practically impossible. For example, the first version

of Submarines was 41.5 Kbytes.

We tried carrying out the optimizations Eric Giguere describes in

“Optimizing J2ME Application Size” (see

http://wireless.java.sun.com/midp/ttips/ appsize), but the resulting

code was still 37 Kbytes. To overcome this, we developed a new

technology for optimizing the size of standalone J2ME

applications.

2.13.2 Optimizing standalone J2ME applications

Our approach suggests that after creating the application’s initial

version, you must transform it by merging classes. Technically

speaking, we perform this by applying the inline class refactoring

pattern,2.12 even though the reasoning behind this transformation is

completely differ ent. In our case, this transformation’s main goal

was to remove all user-defined classes from the program so that

the final version would contain only standard classes that deal with



Figure 2.10. The Submarines (version 1.0) game for a Java-

enabled phone.

the user interface, display, timer, and so forth—that is, only the

indispensable minimum. In the case of Submarines, this

transformation had spectacular results: it reduced the application to

21 Kbytes.

We illustrate this refactoring on a small example adapted from a

real program (see Figure 2.11). The changes amount basically to

merging the user-defined classes with standard ones, creating new

interfaces, and moving methods to the new class.

After completing this transformation, however, achieving any

other significant decrease in size (that is, more than 1 Kbyte) is

hard. One of the still useful optimizations is obfuscation, which, in

this application domain, amounts to changing long identifiers to

shorter ones. In the case of Submarines, this optimization reduced

the size by 1.7 Kbytes to 19.3 Kbytes. Later, we managed to

further reduce the size to 18 Kbytes using the data-compression

techniques we tested while optimizing the second game.

Even though we developed the second game using the

optimizations just described, the first version was still too large for

the target platform (about 30 Kbytes). The problem was the

auxiliary data—including the layout of levels and graphics—which

formed more than 60 percent of the total application size. To

further reduce the application’s size, we wrote a WYSIWIG editor



for editing game levels that compressed the data into a binary

format. We also wrote a compression tool for graphics that pasted

the images together to optimize the ZIP algorithm used in Java

archive (JAR) files.

The compression tool, written in Java, takes a list of files as input

and produces two files as output. One output file is a simple

concatenation of all input files; the other is a hash table. This hash

table’s key is the relative path to the file from the JAR archive’s

root, and all keys point to the offset from the archive’s beginning

and the original file’s length.

Using a binary format to store the levels and using the archivator

for the images helped reduce our second game’s size to 22.4

Kbytes. The reason for the reduction is that the ZIP algorithm

creates a separate dictionary for every file. This approach yields

good results compressing large homogeneous files, but our case is

different. First, files with level descriptions are small (fewer than

100 bytes) and already compressed with a simple algorithm.

Second, the images are already stored in a PNG format, which also

uses a ZIP algorithm for compression. (The original reason for

using the PNG format for images on mobile devices was to avoid

implementing additional algorithms, thus reducing the Kilobyte

Virtual Machine’s size.) So, we can reduce the size only by

compressing the class headers, while the individual images can

even increase their size. File concatenation solves this problem.

From the programmer’s viewpoint, the decrease in application size

is not immediately clear; it becomes apparent only after generating

the corresponding JAR files. The development tools carry out

some optimizations, thus making them transparent to the

programmer. We hope that, in time, development tools will also

fully support the optimizations described here.



2.13.3 Portability issues

Universal portability is one of Java technology’s strongest points.

Unfortunately, ensuring J2ME application portability in practice is

quite difficult. Portability problems arise mostly because the

capabilities of various J2ME devices differ significantly. For

instance, there are different screen sizes (24 among existing J2ME

devices), both black-and-white and color screens with various

color depths, fundamentally different audio features, and so forth.

Therefore, J2ME applications developers must plan for portability

beforehand. “Write once—run anywhere” does not work for a

J2ME platform. You might argue that the portability of J2ME

applications is more similar to the portability of C++ programs

than that of mainstream Java programs: developers must take

special care to ensure that their programs work on more than one

J2ME device.

We encountered the portability problem while writing the games

described earlier. We managed to resolve it by reducing everything

to the basic setup.

For example, we adapted all images to the smallest existing screen

size. As another example, torpedoes are always launched from the

edge of the screen in the Submarine game, independent of the

screen size—see the following code snippet:

protected void paint(Graphics g) {

Rectangle clip = new Rectangle(

g.getClipX(), g.getClipY(), g.getClipWidth(), g.getClipHeight());

<...>

}



Figure 2.11. (a) The original version of a program’s code and (b)

the optimized version.

This design decision has a side effect: a player using a device with

a bigger screen has more time to avoid a coming torpedo. Of

course, we could compensate for this by moving the torpedo

proportionately to the screen size at every tick.


public class PilotMidlet extends MIDlet { private PilotDisp displayable; public Display display; /** Constructor */ public PilotMidlet() { displayable = new PilotDisp(); } /** Main method */ public void startApp() { display = Display.getDisplay(this); display.setCurrent(displayable); }<...> public static void quitApp() { destroyApp(true); notifyDestroyed(); }}public class PilotDisp extends Form implements CommandListener { public string content; private TextBox tb; private PilotMidlet pilotMidlet; private Command exitCommand = new Command("Exit", Command.EXIT, 1); private Command editCommand = new Command("Edit", Command.ITEM,2); private Command okCommand = new Command("OK", Command.OK,1); public PilotDisp(PilotMidlet _pilotMidlet) { super("Compression Demo"); pilotMidlet=_pilotMidlet; content = "LANIT-TERCOM"; tb = new TextBox("Edit", content, 50, TextField.ANY); tb.addCommand(okCommand); append(content); jbInit();}/**Component initialization*/ private void jbInit() { setCommandListener(this); addCommand(exitCommand); addCommand(editCommand);}

(a) (b)

public class PilotMidlet extends MIDlet implements CommandListener { public string content="LANIT-TERCOM"; private TextBox tb = new TextBox("Edit", content, 50, TextField.ANY);; private Command exitCommand = new Command("Exit", Command.EXIT, 1); private Command editCommand = new Command("Edit", Command.ITEM, 2); private Command okCommand = new Command("OK", Command.OK, 1); private Form displayable = new Form("Compression Demo"); public Display display;

/** Constructor */ public PilotMidlet() { displayable.append(content); addCommand(exitCommand); addCommand(editCommand); tb.addCommand(okCommand) setCommandListener(this);}

/** Main method */ public void startApp() { display = Display.getDisplay(this); display.setCurrent(displayable); }

<...>

/** Quit the MIDlet */ public void quitApp() { destroyApp(true); notifyDestroyed(); }

58


The screen size is more important for the balloon game, because

the complexity of its graphics exceeds the display capacity for

typical screen sizes. We solved this problem by fixing the image

width at exactly 100 pixels (the width of the smallest screen for

J2ME devices) and by implementing vertical scrolling to support

devices with either a small or large vertical screen size. We also

decided to use only black with a transparent background for

images. All these measures highly improved the game’s general

portability.

Later, we carried out compatibility testing of our games on several

J2ME devices. The tests confirmed that the programs perform well

on different Siemens, Nokia, and Samsung phones. However, this

is not because of J2ME’s universal portability but because of

deliberate advanced planning of all features. Clearly, we can solve

J2ME portability problems only through strict standardization of

the platform’s numerous parameters.

2.14 NETWORK APPLICATIONS

FOR THE J2ME PLATFORM

Standalone one-user games for Java-enabled phones is an

interesting and fast-growing application area, but the J2ME

platform can support more sophisticated applications. The J2ME

platform’s eventual success will depend on the sufficient quantity

of network applications taking advantage of location awareness.

These applications include, for example, systems for ticket

reservations, data backup and restoration, customer relationship

management, supply chain management, city navigation, and so

forth. Even the games we’ve mentioned could benefit from

supporting multi-user modes.



However, various difficulties, some typical for distributed

information systems and some J2ME-device specific, hamper the

development of network applications for the J2ME platform.

2.14.1 Distributing information between the client

and server

One of the first issues of information system design is optimizing

the distribution of information between the client and server for

speed and convenience. Consider a corporate information system

for a typical insurance company, which usually includes one or

more corporate servers and numerous salespeople equipped with

notebooks, PDA-size devices, and mobile phones. One of the most

difficult problems is supporting data sharing in a mobile

computing environment with a less than ideal (and perhaps

expensive) connection. Requirements for the architecture of such

systems have been enumerated elsewhere.2.13 In our case, they

translate into the following guidelines.

First, to reduce client idle time and ensure that the user can work in

a standalone mode (even in case of temporary loss of network

connection), implement data caching. However, mobile devices are

constrained in resources, so you should apply efficient cache

management techniques, such as semantic caching,2.14 to minimize

network traffic.

Second, to improve the server’s availability, use data replication.

The network’s intermittent nature hampers this process, but you

can overcome it using “epidemic” algorithms for update

propagation (such as an “anti-entropy” protocol5).

Third, to ensure data consistency and resolve various types of

conflicts, the application server keeps track of all data changes



during synchronization. Typically, a transactional model is not

well suited for mobile applications owing to the frequent

disconnection of the devices, which leads to numerous transaction

aborts. One way to resolve this problem is to use optimistic locking

techniques, although it decreases the application’s efficiency and is

not suitable for most tasks. Alan Demers and his colleagues have

proposed another technique based on the so-called merge proc

procedure for conflict resolution on both sides during

synchronization. The developers should implement this procedure

for the task at hand.2.13

However, a more feasible approach would be simply to reduce the

transaction length by committing the data as often as possible (or

as is practical).

Finally, using direct access to the database resolves most conflicts

on the application side. This improves the application’s flexibility

but reduces efficiency.

2.14.2 Sending information between the client and

server

Some data shuttling between the client and server is inevitable,

regardless of decisions on data distribution. Consequently, we must

answer the following questions related to implementing the

fundamental approaches described earlier:

How can we optimize dataflow and increase the efficiency of

data delivery through the network?

What data format is more applicable for data sending and

representation? (This is especially important for structured

data, such as database records, email messages, and news.)



How can we ensure data synchronization—for example, update

propagation—among different devices in practice?

The resulting algorithm would require sending the same

information over and over again until we receive confirmation or

we time-out (in which case the network is unstable, so we must

work locally). However, this algorithm is too costly if the network

connection is stable.

The first of these limitations questions should not present any

serious problems, because data transfer rates in 2.5G networks

with General Packet Radio Services (GPRS) support can

theoretically be as high as 170 Kbits/s. Although in practice this

value is rarely reached, the typical transfer rates, which are from

30 to 60 Kbit/s, should suffice for transferring even quite large

amounts of information.

For simple tasks, such as transmitting the user’s choice or simple

commands, we can use symbolic abbreviations. For example, in

multi-user dungeons, we could easily transform the user navigation

commands into sequences such as ($c*3$b*2$). On reception,

these sequences are easily restored to the original form or

converted to some other structured format on the server side.

Still, for purely structural data, such as news, contact information,

or appointments, the most convenient medium is a structures

description language. The most widespread and proven standard

for structured data representation is XML, but unfortunately the

standard classes of CLDC/MIDP do not support it. We could

attribute this to the fact that the first good implementations of

XML for mobile devices appeared only after J2ME’s initial

release. Nevertheless, plenty of useful libraries exist for this



purpose. For example, kXML (http://kxml.enhydra.org) is free and

provides a transparent solution for compression and transfer of

XML files. NanoXML/Lite (http://nanoxml. n3.net) doesn’t

support mixed content or DTD but is extremely small and efficient.

In recent years, SyncML has become a defacto standard for the

technical implementation of data synchronization among various

devices (see www.syncml. org). This standard intends to provide

for every eventuality; for instance, it includes a language for

describing new devices (SyncML Device Information DTD). Still,

using this standard is sometimes difficult in practice owing to the

target device’s low processing power and memory shortage.

2.14.3 Protecting sensitive information on mobile

devices

Modern information systems demand high levels of security and

data protection. In practice, this means that we must spell out

policies for handling a customer’s private information. For

instance, health care applications in the US must adhere to certain

information policies (most notably, the Health Insurance

Portability and Accountability Act of 1996), so we must take

special measures to guarantee the security and privacy of health

information in these applications. At the least, cached information

should be flushed on exit from the application— we could achieve

this in J2ME by performing an explicit call to the System.gc()

method.

Another consideration for protecting sensitive information is that

the data transferred over the network must be cryptographically

protected. Consider the following scenarios from the data

protection viewpoint. First, an adversary can eavesdrop on the



information transferred over the network. To protect from this

attack, we can use Secure HTTP protocol, which is based on a

secure sockets layer and is supported by most mobile network

providers.

Second, a mobile-device user might need strong cryptographic

algorithms or protocols to fulfill certain everyday tasks. For

instance, strong cryptography is required for authentification, key

exchange, or protection from adversaries getting hold of the mobile

device. Usually, the main problem in this case is the lack of

resources necessary to implement cryptographic algorithms and the

network connection’s low bandwidth—for example, today’s

typical mobile device doesn’t have enough processing power to

generate a 1,024bit RSA key in a reasonable time. So, a pressing

need clearly exists for new algorithms or efficient implementations

of the existing cryptographic schemes.

Researchers have already taken some steps in this direction. For

example, the BouncyCastle library (www.BouncyCastle.org)

implements several block and stream encryption algorithms (the

Data Encryption Standard, Blowfish, Rijndael, and RC4), as well

as algorithms for digital signatures and key exchange (Pretty Good

Privacy, IDEA, RSA). Research in the area of distributed

cryptographic algorithms has also yielded promising results. For

instance, Dan Boneh, Nagendra Modadugu, and Mike Kim

describe a new method for generating unbalanced 1024-bit RSA

keys, where the server carries out the biggest part of the

calculations and exchanges data through an open channel, but

neither the adversary nor the server can access information about

the generated key.2.16 The keys that this algorithm generates are

good enough for practical use, even though one of the multipliers

is a large random number rather than a prime.



2.14.4 User interface issues

System designers should also consider the user interface. Java-

enabled phone interface design is very different from the design

used for PC or Wireless Application Protocol interfaces. The J2ME

platform is somewhere in between these two platforms: it has

richer interface capabilities than WAP but a smaller screen size

and less processing power than a PC. To improve the usability of

J2ME applications, we must introduce quick search, automatic text

completion features, interface tuning options, and so forth. For this

reason, the client side of J2MEapplications is never thin; in fact,

the client side is always as fat as phone resources and other

applications permit. Problems of a similar nature occur with WAP

interfaces.2.17

Another consideration is that mobile applications must avoid a

situation in which the user must stare for several minutes at a

“Please wait …” message on his or her phone’s screen. This is

difficult, especially given the mobile network connection’s

intermittent nature: with a weak or bad signal transmitting, even a

small amount of information transfer can take from several

seconds to several minutes. Of course, from the user’s viewpoint,

this is one of the worst things that could happen, because the

mobile phone is usually not responding when sending or receiving

information. One way to solve this problem is to implement the

user interface actions in the main thread and the rest of the work

(for instance, code for establishing an HTTP connection) in a

background thread.

Keep this problem in mind for the whole network application’s

design, because even the smallest amount of information can be

delayed. For instance, if dozens of mobile phones interact with one



another through a single Web service, the whole system might

become clogged when the recovery time becomes greater than the

average transaction time. No single solution for this exists, because

the situation depends on many parameters, including the phone’s

physical characteristics and the mobile network’s capacity.

2.15 J2ME NETWORK

APPLICATION CONSTRAINTS

Arguably, the biggest question about J2ME is whether we can

build a sizable system on this platform. Here, we conservatively

estimate the maximum size of an information system that could be

implemented with J2ME.

We assume that we’re building a typical N-tier information system,

divided into several layers: the interface level, business logic layer,

and data representation layer. Clearly, as much computation as

possible should be off-loaded from the phone to the server. This

client will interact with business logic through an intermediate

Web application and will use the server computer’s computational

resources.

Apart from the data transfer rate, only one substantial limitation

exists for implementing this architecture—the size of the mobile

application on the phone. So, we must estimate the maximum size.

We assume that we’re going to use the libraries mentioned earlier

to transfer and protect structured data. We’ll also need the

following components:

A kXML 1.0 library (approximately 14 Kbytes)

DES64 cryptography from BouncyCastle.org (approximately

11 Kbytes)



A user interface (approximately 5 Kbytes)

Network data transfer (approximately 3 Kbytes)

Thus, the mandatory part of the application is 33 Kbytes. If we add

approximately 30 percent of this for business logics, we have a 44

Kbytes application. The maximum heap size for a mobile phone is

approximately 128 Kbytes. Naturally, optional applications should

occupy less space to allow for normal phone operation, so we

accept the stricter 100 Kbytes limit. Considering that the average

screen form with event handling and data validation fits into 1.5

Kbytes, we can implement approximately 45 moderately

complicated forms with data validation. This should be enough for

a medium-sized application.

Note that a mobile phone’s permanent memory could be higher

than 128 Kbytes—for instance, it is possible to plug a flash

multimedia card into the mobile device, adding over 256 Mbytes

of storage. However, this is practically useless for applications

because it wouldn’t increase the heap size. Nevertheless, we can

devise more complicated uses for this excessive storage— for

example, it could store a bigger replica of the remote database.

Some problems we’ve described occur because of deficiencies in

available development tools. The more deep-rooted problems

relate to the platform’s physical limitations, but these are also

likely to get easier over time. In general, we found that the J2ME

platform is mature enough to support serious applications.

However, unsolved technical problems will likely appear as well

on other mobile platforms such as i-Mode or Brew. We need

additional research on mobile applications development. Until

then, we hope this article helps programmers deal with some of



these development problems and provides ideas for better

development tools.



References

[2.1] D.P. Agrawal and Q.-A. Zeng, Introduction to Wireless

and Mobile Systems, Brooks/Cole Publishing, Pacific

Grove, Calif., 2003.

[2.2] Wireless Application Protocol (WAP), Int’l Eng.

Consortium, www.iec.org/tutorials/ acrobat/wap.pdf.

[2.3] WAP: An Introduction to the Wireless Application

Protocol, Mobile Lifestreams, 1999,

www.totaltele.com/whitepaper/docs/Moblifstrms_WAP.p

df.

[2.4] Wireless Application Protocol: The Corporate

Perspective, white paper, Nokia, 1999,

www.nokia.com/corporate/wap/files/whitepaper.pdf.

[2.5] Success 4 WAP, white paper, Cisco Systems, 2001,

www.mobilewhitepapers.com/pdf/wap.pdf.

[2.6] Yi-Bing Lin and Imrich Chlamtac, Wireless and Mobile

Network Architectures, John Wiley & Sons, New York,

2001.

[2.7] WAP White Paper, Mobileinfo.com,

www.mobileinfo.com/WAP/model.htm.

[2.8] D. Hougland and K. Zafar, Essential WAP for Web

Professionals, Prentice Hall, Upper Saddle River, N.J.,

2001.

[2.9] D. Flanagan, JavaScript: The Definitive Guide, 3rd ed.,

O’Reilly & Associates, Sebastopol, Calif., 2001.



[2.10] P. Lowber, “Thin Client vs. Fat Client TCO,” research

note, Gartner, 2001,

www.compaq.co.uk/lifecycle/reports/docs/thinclient.pdf.

[2.11] G. Lawton, “Moving Java into Mobile Phones,”

Computer, vol. 35, no. 6, June 2002, pp. 17–20.

[2.12] M. Fowler, Refactoring: Improving the Design of

Existing Code, Addison-Wesley, 2000, pp. 154–156.

[2.13] A.J. Demers et al., “The Bayou Architecture: Support for

Data Sharing among Mobile Users,” Proc. IEEE

Workshop Mobile Computing Systems & Applications,

IEEE CS Press, 1994, pp. 2–7.

[2.14] S. Dar et al., “Semantic Data Caching and Replacement,”

Proc. Very Large Database Conf., Morgan Kaufmann,

1996, pp. 330–341.

[2.15] A.J. Demers et al., “Epidemic Algorithms for Replicated

Database Maintenance,” Proc. 6th Symp. Principles of

Distributed Computing, ACM Press, 1987, pp. 1–12.

[2.16] D. Boneh, N. Modadugu, and M. Kim, “Generating RSA

Keys on a Handheld Using an Untrusted Server,” Proc.

1st Int’l Conf. Cryptology (INDOCRYPT 2000), LNCS

1977, Springer Verlag, 2000, pp. 271–282.

[2.17] D. Billsus et al., “Adaptive Interfaces for Ubiquitous Web

Access,” Comm. ACM, vol. 45, no. 5, May 2002, pp. 34–

38.


http://www.compaq.co.uk/lifecycle/reports/docs/thinclient.pdf

Documents

Preface - Computer & Information Science & …ejkim/to_Dr_Helal/Ch2/2. Mobile... · Web viewOf late, the JSP has proposed a Java Specification Request to address this need (JSR 172,