7.1 Limited Device Hardware

The most visible difference between the mobile and PC platforms is the difference in computing hardware. Today's PCs have much faster CPUs and far more memory and storage spaces than any mobile computing devices. Desktop and server developers can afford the luxury to write applications with bloated features (e.g., Microsoft Office); they also have access to rich productivity features provided by large, all-in-one frameworks (such as the J2SE platform itself). However, on mobile devices, it is a completely different story. With CPUs as slow as 20MHz and RAM as little as 100KB, we must carefully evaluate the features we need, thoroughly optimize our code, and live with limited framework support. In this section, we discuss how to cope with those challenges.

7.1.1 Lightweight Libraries

The most common mistake beginners make is the "golden hammer" anti-pattern: choosing the wrong technology for the task. In the Java world, software tools are often available as reusable objects in standard or third-party libraries. To choose the best libraries that support required application features at the minimum hardware cost is essential.

J2ME Foundation and Personal Profiles (as well as PersonalJava) are compatible with J2SE at the bytecode level and inherit a large subset of the J2SE core API. In theory, we can port J2SE libraries (e.g., XML processing, cryptography, messaging, and UI) directly to mobile devices. However, to do so would defeat the purpose of J2ME and result in slow and bloated applications that can be deployed only to the most expensive devices. In most cases, we should choose from lightweight library alternatives that are specifically designed for the mobile platform. Multiple vendors often compete in the same market. Each vendor offers a slightly different lightweight product with an emphasis on different features.

CLDC and MIDP standard libraries are designed from the ground up as lightweight components. However, the need to select the right tools also applies to MIDP projects when it comes to third-party libraries. For a specific library, vendors often offer a version with J2SE-compatible APIs for larger MIDP devices (e.g., Symbian OS devices) and another extremely lightweight version that uses proprietary APIs. The latter often has a smaller memory footprint and better performance, but requires extra developer training and results in less portable applications. Examples of MIDP lightweight libraries include the PointBase MIDP relational database APIs and iBus//Mobile JMS client APIs ).

7.1.2 Reduce Application Footprint

Pervasive mobile devices have extremely limited memory and storage spaces, requiring us to minimize both the storage and runtime footprints of the application. Specific suggestions are as follows.

• Optimize the packaging process: Even after carefully choosing the best lightweight library, we may still find that the application utilizes only part of the library. In the packaging process, we should include only the classes we actually use. We can do this manually for smaller libraries or use automatic tools bundled with some J2ME IDEs (such as the IBM WebSphere Studio Device Developer) for large libraries. If you want to further reduce the binary application size, you can use a bytecode obfuscator to replace long variable names and class names with shorter, cryptic ones.

• Partition the application: Since the MIDP runtime loads classes only as needed, we can partition the application into separate parts to reduce the runtime footprint. For MIDP applications, the MIDlet suite can contain several relatively independent MIDlets.

7.1.3 Minimize the Garbage Collector

One great advantage of Java is the built-in garbage collector that automatically frees memory space used by stale objects. This allows developers to focus on the core logic rather than on mundane details of memory management. As a result, Java developers are usually unconcerned about object creation. In fact, many popular Java design patterns promote the idea of creating more objects in exchange of more maintainable code. For example, in the Sun Smart Ticket sample application, the use of the MVC and facade patterns results in many objects that simply delegate the action to the next layer. To get a feel for this problem, just look into the numerous classes that implement the RemoteModel interface.

But on mobile devices, due to the small amount of available memory, the garbage collector must run more often. When the garbage collector runs, its thread takes up precious CPU cycles and slows down all other application processes. For effective J2ME applications, we need to minimize object creation and quickly dispose of objects that are no longer in use. Specific suggestions are as follows:

• Carefully examine design patterns in early stages of the development cycle. For example, the screen flow-based approach demonstrated in the iFeedBack sample  results in many fewer objects than a traditional MVC implementation.

• Concisely reuse existing objects at the implementation level. For example, if a same button (e.g., the DONE button) appears in many screens, we should create it once and reuse it.

• Use arrays and StringBuffers. Arrays are much faster and more memory efficient than collection objects. When we modify or concatenate strings, the immutable String objects result in a lot of intermediate objects. The StringBuffer is much more efficient.

• Close network connections, file handlers, and Record Management System (RMS) record stores quickly after use. We need to look over the documentation carefully to find out all the close(), destroy(), and dispose() methods and use them judiciously. It is usually considered a best practice to place those methods in the finally block to make sure that the resources are released even if runtime exceptions are thrown.

  try {
  
    HttpConnection c =
  
      (HttpConnection) Connector.open("http://someurl");
  
    InputStream is = c.openInputStream ();
  
    // do something with the data
  
  } catch (Exception e) {
  
    // handle exceptions
  
  } finally {
  
    try {
  
      if ( c != null ) c.close();
  
      if ( is != null ) is.close();
  
    } catch (IOException ioe) { }
  
  }
  
  

• Free resources when using native libraries. In smart mobile applications, we sometimes need to access native libraries for better performance, restricted functionalities (e.g., to make a phone call), or simply native UI look and feel (e.g., the IBM SWT library for PocketPC). Native resources are not subject to garbage collection. It is important to follow proper instructions of the native libraries (and their Java wrapper classes) to free resources after use.

7.1.4 Use Mobile Portals

Smart mobile devices are getting more powerful every day. However, in complex enterprise environments, many tasks are still too resource-intensive for most mobile devices. In this case, a commonly used approach is to set up portal servers to which the mobile devices can delegate complex tasks. Mobile middleware portals bridge mobile clients to enterprise backend servers. The smart portal is much more than a proxy or a surrogate for mobile devices. The uses of mobile portals include the following.

• Allow mobile clients to utilize multiple communication and messaging protocols.

• Aggregate backend services and enable bundled services. For example, the Oracle9iAS Wireless server provides J2ME SDKs for Oracle's SQL database, push-based messaging, and location-based services. The BlackBerry Enterprise Server supports unified access to Microsoft Exchange-based or IBM Lotus Domino-based corporate information systems from BlackBerry MIDP devices .

• Provide simple mobile interfaces for powerful and sophisticated backend services. There are several notable examples:

  - The MapPoint facade, shows how to build an easy-to-access interface for a complex backend Web service.

  - Database synchronization servers synchronize J2ME mobile databases with backend enterprise data sources using complex conflict resolution logic.

  - The Simplicity Enterprise Mobile Server supports simple, visual ways to build J2ME clients for legacy (mainframe) applications.

7.1.5 Use Design Patterns Judiciously

No design pattern is the silver bullet for every situation. For example, the powerful MVC and Facade patterns demonstrated in the Smart Ticket blueprint  require several abstraction layers and are probably too heavy for simple applications. For simple applications, we can design the entire logic around screens, as we did in the iFeedBack example .
 

7.2 Slow, Unreliable Networks

Unlike always-on broadband networks for desktop and server computers, wireless networks have proven to be very slow, unreliable, and insecure. Developers from the PC world, especially those who used to develop server-based with thin client solutions, tend to make excessive use of the network. In this section, we discuss ways to make the best use of network resources.

7.2.1 Support the Offline Mode

As we discussed in , one of the most important advantages of the smart client paradigm is the ability to support offline operations when the network connection is temporarily unavailable. The key enabling technology is on-device persistence storage (cache). Other advantages of the on-device cache include reduced network round trips and improved performance.

Offline operations require careful design of the data model. On-device cache can be used explicitly by the application developer or can be built into the framework and become transparently available to applications. Examples of both approaches are illustrated in the iFeedBack  and Smart Ticket sample applications. For simple caches, the application-managed MIDP RMS stores, plain files, or XML documents are adequate. For more sophisticated data management solutions, we can use on-device relational data stores. For backend powered applications, we also need to keep the cache synchronized with backend data sources. Simple synchronization logic can be programmed into the application itself. Commercial mobile databases often come with advanced synchronization solutions.

7.2.2 Use Remote Facades

Remote facade is an effective pattern to have the best of two worlds: fine-grained object model at the server side and coarse-grained access interface for improved network efficiency. Another excellent example of remote facade is the Axis-based MapPoint facade gateway

7.2.3 Place Portals Locally

Mobile portals are essential components in enterprise mobile architectures. However, fixed portals residing in remote data centers are often not accessible from the national mobile networks due to limited coverage and unreliable connections.

Compared with wide area networks, local wireless networks often have better coverage, lower bandwidth cost, higher speed and better security. Mobile portals that reside on the local wireless networks boost the performance and availability of the client devices. Examples of such mobile portals include OSGi service gateways and IBM WebSphere MQe .In practice, we can build a mobile application architecture that contains a hierarchical structure of hubs and portals. Each portal handles part of the logic and delegates the rest to the next layer. That allows us to build an enterprise mobile architecture that continues to function with limited capabilities in different levels of network failures. Figure 7.1 illustrates the mobile portal network architecture discussed in this chapter.
 

7.2.4 Buffered I/O

Reading network data byte by byte is very slow. We should always read and write data in chunks. In Personal Profile applications, we can use the JDK's standard BufferedReader and BufferedWriter. In MIDP applications, we need to buffer the I/O ourselves (Listing 7.1).

Listing 7.1. The buffered input in MIDP

HttpConnection conn = (HttpConnection) Connector.open(url);

conn.setRequestMethod(HttpConnection.GET);

DataInputStream din = conn.openDataInputStream();

ByteArrayOutputStream bos = new ByteArrayOutputStream();

byte[] buf = new byte[256];

while (true) {

  int rd = din.read(buf, 0, 256);

  if (rd == -1) break;

  bos.write(buf, 0, rd);

}

bos.flush();

buf = bos.toByteArray();

// byte array buf now contains the downloaded data

7.2.5 Encrypt Your Data

Wireless networks broadcast data traffic into the air. Anyone can drop in and intercept the traffic. Built-in security for most wireless networks is not adequate for enterprise applications. The use of HTTPS for confidential communication is strongly recommended. Having said that, we must also understand that cryptography tasks are often CPU-intensive. Security comes at the cost of performance. For small devices, we must carefully evaluate the security requirements and come up with balanced solutions.

7.2.6 Obtain Server Status Efficiently

Many enterprise mobile applications, such as an Instant Messaging client or a database monitoring client, need to be updated with real-time server status at all times. Since the HTTP protocol is ubiquitously supported in all J2ME devices, inexperienced developers sometimes program the device to initiate periodic HTTP connections to poll the server for its status. The polling frequency must be much faster than the expected server status-change frequency to keep the device updated. The constant polling results in a lot of redundant data. It is a waste of bandwidth, server resources, and time. There are several ways to deal with this problem:

• Use HTTP conditional GET: The HTTP conditional GET operation allows the server to return data only when the data source has been updated since the last query. An excellent description of the HTTP conditional GET and its usage can be found in a blog entry from Charles Miller (see the "Resources" section). This method reduces the amount of network data but does not reduce the frequency of the polling operation. In a long latency network, it could still be a performance bottleneck.

Use PUSH-based protocols: To completely fix the "excessive poll" problem, let the server notify the client when the server status is updated. We cannot use the HTTP protocol for this purpose, since HTTP is designed to be a stateless request/response protocol. HTTP connections cannot be kept alive over an extended period of time. That requires us to explore other PUSH-based communication protocols on devices.

- SIP is a protocol specially designed for signaling in a PUSH-based network. The SIP API for J2ME has already been finalized 

7.3 Pervasive Devices

Pervasive mobile devices are at the core of the mobile enterprise solution's value proposition. However, unlike PCs, which can be centrally administrated, managing a large number of small devices that people carry around all the time is an IT nightmare. Many of the device management issues are both social and technical in nature. In this section, we discuss what the problems are and the technical tools that can help IT managers and users.

 

Note

The successful use of the technologies described in this section rely on proper user education and corporate policies.

7.3.1 Protect On-Device Data

Small devices are very easy to lose. Stolen enterprise devices that contain sensitive business data, user credentials, or even company private keys could pose a real security risk. The only way to guard against this is to use strong encryption to protect on-device data.

7.3.2 Synchronize Often

Today's battery technology lags far behind the device technology. A smart mobile device with a fast CPU; a large, backlit LCD; and multimedia features could drain its battery in a matter of hours. Most smart phone or high-end PDA devices require the user to recharge every day. If the user forgets, she will probably end up with drained batteries in the middle of the next day. Drained batteries could result in lost data. One way to cope with this is to synchronize the device periodically with backend data sources.

7.3.3 Optimize for Many Devices

Because pervasive devices are cheap and easy to carry around, there tends to be many of them in a company. Each worker could carry multiple interconnected devices. Enterprise solutions need to support all devices in use in the company. J2ME provides a device-independent platform to develop applications. But applications still need to be optimized for the specific target UI and other device characteristics. The use of the MVC pattern could ease the pain of customizing applications: Only the view layer needs to be modified. For example, when the Sun Smart Ticket blueprint teams decide to port the application to MIDP v2.0 devices, they need to recode only the view layer in a matter of days. Another way to implement an MVC solution is to use the clientside container.

7.3.4 Centralized Provisioning

Mobile enterprise users need to have the latest patched software and up-to-date application data. However, it just does not fit the mobile worker's busy life and work style to sit down, hook the devices to PCs, and follow detailed update instructions from the IT department every day. As a result, those instructions are often ignored. To manage and update software and data on a large number of mobile devices is a challenging task. The following are several tools that automate the device management process for both mobile users and IT administrators.

J2EE provisioning server: The JSR 124 develops a specification for J2EE client provisioning servers. The server allows operators to plug in adapters for any client provision scheme. For example, the MIDP Over-the-Air (OTA) support is provided by a bundled adaptor in the reference implementation. When the device requests a client software, the provisioning server matches the device with clients in the repository and deploys the client using the appropriate adaptor. The provisioning server also provides hooks for backend billing, tracking, and CRM applications. Figure 7.2 shows the overall design of the J2EE client provisioning server.

 

• OGSi bundles: OSGi bundles are self-contained mobile applications with managed life cycles. For devices running OSGi services, OSGi bundles could be the ideal way to deploy applications and contents.

• Synchronization server: Database synchronization can also be used to provision and update contents

7.4 Ubiquitous Integration

Enterprise mobile clients need to integrate with many different back end or middleware systems. In this section, we introduce several common integration technologies and discuss how to use them judiciously. Table 7.1 is a brief layout of the pros and cons of each approach. Figure 7.3 illustrates the characteristics of each integration scheme.

 

 

7.4.1 Proprietary Binary Protocols

Since HTTP support is mandatory on all J2ME devices, it is the basis for most other approaches. HTTP can transport text as well as any arbitrary binary content. Our examples iFeedBack  and Smart Ticket  both demonstrate the use of custom-designed binary protocols over HTTP. The binary protocols are designed to tailor the application needs and minimize the number of bytes needed to be sent over the network.

However, this approach results in tight coupling between the servers and clients. We have to develop both serverside and clientside components to interface with the custom protocol. If the design changes in the future, we have to change the application on both sides. If we do not have control over the server, we cannot take this approach. For applications that require frequent updates, the custom protocols are also not optimal.

7.4.2 Use Mobile RPC Frameworks

A more standardized integration approach is to use commercially available RPC frameworks. Such examples include the Open Source kCommand toolkit and the Simplicity transaction engine. The kCommand toolkit defines a set of open APIs that both the client and server can call to pass generic RPC parameters. Please refer to the link in the "Resources" section to find out more about its use. The Simplicity transaction engine is a proprietary solution tightly bundled with the Simplicity IDE. Using Simplicity RAD tools ,you can drag and drop your remote transaction components on an application composer and let the IDE generate the code for you. It is very easy to use for simple applications. However, the auto-generated source code can be hard to customize.

With the mobile RPC frameworks, we save the time to develop proprietary and hard-to-maintain interface components. But the server and client remain tightly coupled.

7.4.3 Messaging Is Our Friend

Messaging solutions, especially asynchronous messaging, decouple the client and the server through the messaging middleware. Properly designed messaging solutions could greatly improve the reliability and scalability of the system because resources can be allocated to respond to requests on a priority basis rather than a first-come-first-served basis. 

7.4.4 XML and Web Services

XML Web Services advocate platform-agnostic open interfaces. It supports both RPC style and messaging style integration. However, since XML Web Services pose large bandwidth and CPU overheads, we have to use them carefully. I suggest the use of XML Web Service only when the mobile client is interfacing external components or multiple client interoperability is required.

7.5 The Impatient User

The "anytime, anywhere" convenience is the biggest strength of mobile applications. However, it is a major challenge to implement a truly convenient solution for human users. Users treat mobile devices as personal belongings and have high expectations for their devices.

In this section, we discuss efficient and responsive UI designs, which are crucial to the adoption of mobile applications. Another aspect of personal devices is that users would like to customize them to fit their individual style. We discuss preference management as well in this section. Most issues we discuss in this section are covered in the Smart Ticket sample application .

7.5.1 Take Advantage of the Rich UI

Rich UI is one of the great appeals of smart clients. We should make judicious use of advanced UI components, such as direct draw on canvas and animation sprites. In the Smart Ticket application, the use of raw canvas to draw seating maps is an excellent example of appropriate UI usage. Advanced UI widgets are supported in the MIDP v2.0 specification. Device vendors also often provide their own UI enhancement APIs.

As described in Section 7.3.3, the MVC pattern is a powerful tool to support multiple optimized UIs for different devices while reusing the same business logic components.

7.5.2 Use Threads Judiciously

UI lock-up is one of the most annoying problems users can experience. On PCs, users are used to crashes in a certain popular operating system, and they can just hit the reboot button. But the user's tolerance for malfunctioning mobile devices is much lower. We expect our cell phones to work out of the box like any other electronic household appliance. The best practice to avoid hang-ups in the main UI thread is to put all lengthy or potentially blocking operations in separate threads. In fact, the MIDP specification clearly states that the UI event handler (i.e., the CommandListener. commandAction() method) must "return immediately," which implies that proper UI threading is actually mandated by the specification. Listing 7.2 shows the use of threads.

Listing 7.2. The use of threads

public class DemoMIDlet extends MIDlet implements CommandListener {



  // other methods



  public void commandAction(Command command, Displayable screen) {

    if (command == exit) {

      // handle exit

    } else if (command == action) {

      WorkerThread t = new WorkerThread ();

      t.start();

    }

  }



  class WorkerThread extends Thread {



    void run () {

      // Do the work

    }

  }

}

In the Smart Ticket sample application, the use of threads is pushed one step further: Each worker thread also has a helper thread that displays an animated gauge to indicate the progress of the worker thread. This is especially useful to keep the user informed during lengthy network operations.

7.5.3 One Screen at a Time

Mobile users have relatively short attention spans. We should break up lengthy operations into small pieces to show one screen at a time and offer users options to pause or abort in the middle of the process. Smart clients are especially well equipped to handle the screen flow process, since on-device storage could cache information between screens. A good example of screen flow is the "buy a ticket" action in the Smart Ticket application.

7.5.4 Store User Preferences

Mobile devices become more personal and hence have more value if they are customized to fit the user's personal preferences. Advanced mobile applications should store its owner's preference data on device. As we see in the Smart Ticket application, the stored preferences also allow users to have smoother workflow experiences. For example, the user does not need to stop and enter her credit card information in the middle of the purchasing flow.

7.5.5 Use Deployment Descriptors

The mobile application can also be customized at the back end before the user downloads it. For example, when a user signs up on a Web site, the site automatically customizes the download package with the profile derived from the submitted forms. We can customize the application without rebuilding it through the deployment descriptors. The MIDP specification defined the format and usage of Java Application Descriptor (JAD) files. But for other J2ME platforms, we still need to embed property files and/or other nonstandard configuration files in the custom-generated JAR package.

6.1 The Decorator Approach

One way to enhance the MIDP standard HTTP I/O is to provide a decorator class (CustomConnection) that wraps around the default MIDP HttpConnection implementation but overrides some methods to handle custom headers. Since the decorator class also implements the HttpConnection interface, it is transparent to existing MIDP applications that use HttpConnection.

6.1.1 The CustomConnector Factory Class

In order to instantiate the CustomConnection decorator, we need to write a new connection factory class CustomConnector (Listing 6.1). The custom request headers are set in the CustomConnector.open() method when a new connection is established.

Listing 6.1. The CustomConnector factory class

// In CustomConnector class

public static HttpConnection open(String url) throws IOException {

  HttpConnection c = (HttpConnection) Connector.open(url);

  setRequestHeaders(c);

  c.setRequestProperty("User-Agent",

    "Profile/MIDP-1.0, Configuration/CLDC-1.0");

  c.setRequestProperty("Content-Language", "en-US");

  CustomConnection sc = new CustomConnection(c);

  return sc;

}



private static void setRequestHeaders(HttpConnection c) {

  // Generate custom header for the request and

  // set the headers to the connection object.

}



private static void getResponseHeaders(HttpConnection c) {

  // Retrieve headers from the response stream

  // and process it.

}

6.1.2 The CustomConnection Class

Now, let's have a closer look at class CustomConnection (Listing 6.2). It overrides only two methods, openInputStream() and openDataInputStream(), which process custom headers when the response data is retrieved.

Listing 6.2. The CustomConnection class

class CustomConnection implements HttpConnection {

  private HttpConnection c;



  public CustomConnection(HttpConnection c) {

    this.c = c;

  }



  public String getURL() {

    return c.getURL();

  }



  public String getProtocol() {

    return c.getProtocol();

  }



  public String getHost() {

    return c.getHost();

  }



  // More HttpConnection methods

  public InputStream openInputStream() throws IOException {

    CustomConnector.getResponseHeaders(c);

    return c.openInputStream();

  }



  public DataInputStream openDataInputStream() throws IOException {

    CustomConnector.getResponseHeaders(c);

    return c.openDataInputStream();

  }

}

6.1.3 Decorator Pros and Cons

The decorator solution is elegant and transparent to existing applications. However, it has several weaknesses.

• It is not scalable. For each task involving custom HTTP headers, we need to write a pair of decorator and connector factory classes.

• The decorator solution does not work correctly with HTTP tasks that require automatic header resubmission from the client side. An example of such tasks is the HTTP Digest Authentication (see Section 6.5).

For general-purpose HTTP headers handling, we need a new framework that is more powerful than simple decorators.

 

6.2 The Process-Chain Approach

In this section, I present a process-chain-based HTTP transport framework that works on all J2ME platforms. For simplicity, the new transport class treats all requests and responses as byte arrays rather than streams. If your application requires stream I/O (e.g., a SAX XML parser), you can easily wrap a ByteArrayInputStream or ByteArrayOutputStream around those arrays. The key components in the new framework are listed in Table 6.1.

6.2.1 The HttpClient Source Code

The source code of the HttpClient class is shown in Listing 6.3. Notice how we walk through the handlers chain twice to process both the request and response headers in the query() method. The maxIteration property is used to prevent infinite loops in case of failed challenge-response cycles.

Listing 6.3. The HttpClient class

public class HttpClient {



  private String url;

  private String requestMethod;

  private Vector handlers = new Vector ();

  // Max number of challenge/response cycles.

  private int maxIteration = 3;



  public HttpClient() {}



  public void setUrl (String url) {

    this.url = url;

  }



  public void setRequestMethod (String method) {

    this.requestMethod = method;

  }



  public void setMaxIteration (int n) {

    maxIteration = n;

  }



  public void addHandler (Handler h) throws Exception {

    handlers.addElement(h);

  }



  public void removeAllHandlers () throws Exception {

    handlers = new Vector ();

  }



  public byte [] query (byte [] req) throws Exception {

    boolean needConnect = true;

    HttpConnection c = null;

    int currentIteration = 0;

    while (needConnect) {

      currentIteration++;

      if (currentIteration > maxIteration)

        throw new Exception("Too many Iterations");

      needConnect = false;



      if ( c != null ) {

        try {

          c.close();

        } catch (Exception ignore) {

        }

      }

      c = (HttpConnection) Connector.open (url);

      c.setRequestMethod( requestMethod );

      for (int i = 0; i < handlers.size(); i++)

((Handler) handlers.elementAt(i)).prepareHeaders(c);

      c.setRequestProperty("User-Agent",

       "Profile/MIDP-1.0, Configuration/CLDC-1.0");

      c.setRequestProperty("Content-Language", "en-US");



      if ( req != null ) {

        OutputStream os = c.openOutputStream ();

        os.write(req);

        os.close();

      }

      for (int i = 0; i < handlers.size(); i++) {

        needConnect =

    ((Handler) handlers.elementAt(i)).processHeaders(c) | | needConnect;

      }

    }

    InputStream is = c.openInputStream ();

    ByteArrayOutputStream bos = new ByteArrayOutputStream();

    byte[] buf = new byte[256];

    while (true) {

      int rd = is.read(buf, 0, 256);

      if (rd == -1) break;

      bos.write(buf, 0, rd);

    }

    buf = bos.toByteArray();

    is.close();

    c.close();

    return buf;

  }

}

Now, let's look at how to use those two frameworks to handle HTTP headers in the real world.

6.3 Session Tracking via HTTP Cookies

Cookies are pieces of NAME=VALUE formatted text embedded in HTTP headers. They are used to track client states. Since cookies reside in HTTP headers, they are transparent to applications and users. The server assigns new cookies to the client through the HTTP header set-cookie. The set-cookie header takes the following format:

set-cookie: NAME=VALUE; expires=DATE; path=PATH;

domain=DOMAIN_NAME; secure

The first NAME=VALUE is the cookie itself and is required. All the following attributes, such as expiration time, domain, and path, are optional. When the client makes subsequent requests, it sends the cookies back in the cookies header to identify itself.

cookie: NAME1=VALUE1; NAME1=VALUE2; ...

6.3.1 Handle Cookies via Decorator Classes

Sun Microsystems' Smart Ticket blueprint v1.1 provides a class SessionConnector that utilizes the decorator pattern to add cookie support into the standard MIDP HTTP framework. The source code of this class is available from this book's Web site. The following snippet demonstrates how to use this class.

HttpConnection c =

  (HttpConnection) SessionConnector.open(url);

// You can use "c" as a normal HttpConnection

// but it is session aware now.

6.3.2 Handle Cookies via HttpClient Handlers

To support cookie headers in the HttpClient framework, we need to write the handler class. The source code of handler class (CookieHandler) is shown in Listing 6.4. Method getCookie() parses the response header and stores cookies in a static data member cookies. Method addCookie() matches stored cookies with the current request URL to determine which cookies to send out. Please refer to this book's Web site for complete source code.

Listing 6.4. The CookieHandler class

public class CookieHandler implements Handler {



  private static Vector cookies;

  private static Vector domains;



  public CookieHandler() {

    cookies = new Vector ();

    domains = new Vector ();

  }



  public void prepareHeaders(HttpConnection c) throws Exception {

    String url = c.getURL ();

    addCookie(c, url);

  }



  public boolean processHeaders (HttpConnection c) throws Exception {

    getCookie(c);

    return false;

  }



  // Remove all cookies.

  public void removeCookies() throws Exception {

    cookies = new Vector ();

    domains = new Vector ();

    return;

  }



  // Retrieve cookies from the connection header

  // and save them with domain information

  private void getCookie(HttpConnection c) throws Exception {

    // Parse the incoming cookies and store them in

    // cookies and domains vectors.

  }



  private void addCookie(HttpConnection c,

                String url) throws Exception {

    // Match the url domain with existing cookies

    // in the cookies vector. If a match is found,

    // set it into the connection header.

  }

}

The use of CookieHandler is illustrated in Listing 6.5.

Listing 6.5. The CookieHandler usage

HttpClient client = new HttpClient ();

Handler h = new CookieHandler();

client.addHandler( h );

client.setUrl( url );

client.setRequestMethod( HttpConnection.GET );

byte [] result = client.query(null);

6.4 HTTP Basic Authentication
Some HTTP headers can carry client credential information. Those credentials are used by servers to determine the client's identity and then grant or deny access to the requested resources. In the HTTP basic authentication scheme, the client sends its username and password in plain text with every request. The procedure is the following:
Use the Base64 algorithm to encode a username : password string
Send the encoded string and string Basic in the HTTP header Authorization
For example, if the username is Aladdin and password is open sesame, the HTTP authentication header is the following.
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==



6.4.1 Code Example
To enable HTTP basic authentication in the HttpClient class, we need to plug in a handler (BasicAuthHandler). We can easily use BasicAuthHandler together with CookieHandler to make the HttpClient object keep track of a client session over an authentication connection (Listing 6.6).
Listing 6.6. Use cookies with HTTP basic authentication
HttpClient client = new HttpClient ();

Handler h1 = new CookieHandler();

Handler h2 = new BasicAuthHandler(user, pass);

client.addHandler( h1 );

client.addHandler( h2 );

client.setUrl( url );

client.setRequestMethod( HttpConnection.GET );

byte [] result = client.query(null);


Sample source code for the BasicAuthHandler class is shown in Listing 6.7.
Listing 6.7. The BasicAuthHandler class
public class BasicAuthHandler implements Handler {



  private String username;

  private String password;



  public BasicAuthHandler (String u, String p) {

    username = u;

    password = p;

  }



  public void prepareHeaders(HttpConnection c) throws Exception {

    String s = encode(username + ":" + password);

    c.setRequestProperty("Authorization", "Basic " + s);

  }



  public boolean processHeaders(HttpConnection c) throws Exception {

    // Do nothing.

    return false;

  }



  // Base64 encoding.

  //

  // This implementation is adopted from

  // Kenneth Ballard's HttpClient package.

  // Released under LGPL.

  private String encode(String d) {

   // Implementation details skipped

  }

}


6.5 HTTP Digest Authentication
Basic authentication can be used in a secure network environment. However, in an insecure network, such as the Internet, the problem for basic authentication is obvious: A cracker can easily intercept the clear text username and password, and forge the user's identity. A more secure scheme is to use one-way hashes (digests) to carry user credentials. The HTTP Digest Authentication works as follows.


    

    
The client contacts the server and requests a restricted resource.
    
    

    
The server sends a challenge to the client, including a randomly generated nonce value in predefined HTTP headers.
    
    

    
The client calculates a hash using its username, password, and the nonce value according to an algorithm defined in the specification.
    
    

    
The client resends its request with the new authentication header.
    
    

    
The server compares hashes with its own calculations. If the authentication is successful, the client will continue to use the same hash until the server changes the nonce value or the user changes its username and password.
    


Besides eliminating the clear text username and password, the digest authentication scheme has other important benefits. The server knows only the hash of the password but not the password itself. This prevents insider abuses. The server nonce value is embedded in the hash and therefore cannot be forged. This allows the server to have better control over the authentication process.

6.5.1 Code Example
We can use the DigestAuthHandler class to make the HttpClient object aware of digest authentication. The implementation of DigestAuthHandler is based on Kenneth Ballard's Open Source package "HttpClient." Code snippet from the DigestAuthHandler class is shown in Listing 6.8. Please note that the processHeaders() method returns false when the authentication fails, causing the HttpClient to recalculate the digest headers and resubmit its request. The digest value is generated using code adopted from the Bouncy Castle package (see Chapter 20).
Listing 6.8. The DigestAuthHandler class
public class DigestAuthHandler implements Handler {



  public DigestAuthHandler (String u, String p) {

    username = u;

    password = p;

  }



  public void prepareHeaders(HttpConnection c) throws Exception {

    String h = "Digest ";



    if(username != null)

      h = h + "username=\"" + username + "\", ";

    if(realm != null)

      h = h + "realm=\"" + realm + "\", ";

    if(nonce != null)

      h = h + "nonce=\"" + nonce + "\", ";

    if(uri != null)

      h = h + "uri=\"" + uri + "\", ";

    if(opaque != null)

      h = h + "opaque=\"" + opaque + "\", ";



    if(qop != null) {

      h = h + "qop=\"" + qop + "\", ";

      // cnonce is a random number generated by the

      // client. You should use your device build-in

      // random number generator to produce it.

      cnonce = "0123456789";

      h = h + "cnonce=\"" + cnonce + "\", ";



      h = h + "nc=" + count + ", ";



      // Increase counter by one. The counter will

      // be reset when a new nonce comes in.

      ncount++;

      String nc = Integer.toHexString(ncount);

      count = new String("00000000").substring(nc.length()) + nc;

    }

    h = h + "algorithm=\"MD5\", ";

    h = h + "response=\"" + getDigest() + "\"";

    c.setRequestProperty("Authorization", h);

  }



  public boolean processHeaders (HttpConnection c)

                                  throws Exception {

    if ( c.getResponseCode() == 401 ) {

      httpMethod = c.getRequestMethod();

      uri = c.getFile();

      parse (c.getHeaderField("WWW-Authenticate"));



      // need to re-send request

      return true;

    } else {

      return false;

    }

  }



  // Other utility methods

}
6.6 Secure HTTP
Both basic and digest HTTP authentication schemes discussed above are weak security measures. They only authenticate users but do not protect the

communication content. They do not prevent crackers from intercepting or even tampering with the communication data. For complete point-to-point HTTP 

security, we need the HTTPS protocol that is based on secure underlying transport protocols such as the Secure Socket Layer (SSL) and the Transport Layer 

Security (TLS). Compared with thin client solutions where security is provided by the fixed infrastructure, direct HTTPS connections allow more flexible security schemes. For example, the communication parties can decide what to encrypt, the level of encryption and how often the session key should be changed 

based on their business needs. In addition, by eliminating the middleman, HTTPS smart clients avoid the single point of failure and hence they are not affected

by infrastructure level security holes. The discovery of security weaknesses in WAP gateways and WiFi access points has made this an important concern.

Figure 6.1 illustrates the difference between HTTPS end-to-end solutions and WAP thin client solutions.











 


 




 
6.6.1 HTTPS Support in the MIDP
Support for HTTPS is mandatory in the MIDP v2.0 but optional in the MIDP v1.0. To establish an HTTPS connection, all you need to do is pass 

an https://-style URL string to the Connector.open() factory method.



 

On an HTTPS-enabled MIDP v1.0 device, a normal HttpConnection object will be returned. You can open input and output streams as
usual. But the underlying data are properly encrypted. The entire process is transparent to developers.
On a MIDP v2.0 device, an HttpsConnection object will be returned. Interface HttpsConnection extends HttpConnection with two 
more methods: getPort() and getSecurityInfo(). The getSecurityInfo() method returns a SecurityInfo object, which can be used to 
obtain further information on cipher and server certificate.

 
 
 
 
 
 
 
  
 

5.1 Getting Started

The Smart Ticket application is available from Sun Microsystems' blueprints Web site (see "Resources"). The zip package contains source code; ANT build scripts; and prebuilt, deployable application binaries.

The Smart Ticket sample contains a J2EE component for the enterprise back end and a J2ME component for the mobile front end. Running the application requires a J2EE application server and a MIDP v2.0-compatible device (or emulator) with Internet connectivity. For learning and testing purposes, we can run both the J2EE server and MIDP emulator on the same computer as follows.

Now, you are ready to order some movie tickets from the phone emulator!

Note

If you want to run the MIDP client on an actual smart phone device, the J2EE server must run on an Internet-accessible computer and you must configure the MIDP client for the correct server IP address.

5.2 Smart Ticket in Action

The Smart Ticket client allows the user to manage user preferences, browse movie schedules, order tickets, rate watched movies, and pre-download the schedule. We discuss those features one by one in this section.

Note

The Smart Ticket blueprint is designed for educational purposes. It demonstrates the use of design patterns. As developers, we should judicially use patterns learned from the Smart Ticket. The overuse of design patterns results in unnecessary abstraction layers and produces slow and large applications.

5.2.1 Manage User Preferences

When the user starts the MIDP client for the first time, she will be asked to create a profile. The profile includes two types of information:

• Account credentials: The username, password, and optional credit card numbers.

User preferences: The theater search zip codes, favorite day of the week, and preferred seating. Figure 5.1 shows how to manage user preferences.
 

 

After the user submits the profile, a corresponding user account is created on the J2EE server. The preference information is cached on the device. The user could configure the MIDP client to cache the account credentials so that she does not need to manually sign in every time she wants to purchase tickets or submit movie ratings. User preferences can be modified at any time through the MIDP UI.

Note

The Smart Ticket client does not encrypt the account and preference information stored on the device. That could create problems if the device is lost.

5.2.2 Search and Purchase Tickets

Once logged in, the user can browse theaters, movies, and show times in her zip code areas. This process involves a series of real-time queries to the J2EE server. Once she selects a show, she will be asked to select currently available seats from an interactive seating map to make reservations. The reservation is persisted to the server database.

5.2.3 Rate Movies

The user can rate movies she has seen . The ratings are not immediately submitted to the server. They are cached on device and can be synchronized to the server upon the user request. That allows the user to rate movies even when the phone is out of network range (for example, in a shielded cinema building!). The synchronization agent is smart: When the same user rates the same movie multiple times, it resolves the issue by keeping only the most recent rating in the backend database.

5.2.4 Cache Theater Schedules

Smart Ticket allows the user to download a theater's schedule to the mobile client. The cached schedule enables offline browsing and improves the performance by reducing network round trips. The user can delete or re-download the schedule as needed 

5.3 Important Architectural Patterns

Smart Ticket utilizes several architectural design patterns, which are commonly used by enterprise architects. It is important for enterprise mobile developers to understand those patterns.

5.3.1 The Overall MVC Pattern

The overall architecture of the Smart Ticket application follows the Model-View-Controller pattern. According to Martin Fowler in his Patterns of Enterprise Application Architecture, the MVC pattern "splits user interface interaction into three distinct roles." In an MVC application, the view and controller components work together as the UI, which primarily concerns how to present the information to the user through a series of displays and interactions. The model component represents the domain model. The model's primary concern is business logic and machine-to-machine interactions (e.g., database access). The use of the MVC patterns brings some important benefits:

• Since the presentation and the underlying data model are separated, we can employ different experts to work on different parts of the code. For example, a UI expert can design the views while a database expert optimizes the database connections at the same time.

• MVC allows us to develop multiple views for the same model. For example, the Smart Ticket v2.0 EA and v1.2 applications have the exact same model layer. The MVC pattern allows Sun developers to rewrite the UI for MIDP v2.0 in a short period of time.

• Nonvisual objects in the model layer are easier to test using automatic tools than are the UI components.

In the Smart Ticket application, the MVC pattern is implemented as follows:

• Model: Classes in the model layer contain all the business logic. In fact, the entire J2EE server component, on-device caches, and communication classes all belong to the model layer. The most notable design pattern in the model layer is the facades, which we discuss in the next sections.

• View: Each interactive screen is represented by a view class. There are 17 view classes in the Smart Ticket v2.0 EA client. Once the user generates a UI event (e.g., by pressing a button or selecting an item from a list), the view class's event handler captures the event and passes it to the controller class. Listing 5.1 demonstrates the UI classes for the screen to confirm ticket purchase.

• Controller: The controller class knows all the possible interactions between the user and the program. In the Smart Ticket application, the controller is the UIController class (Listing 5.2). It has one method for each possible action (e.g., purchaseRequested()). The action method often starts two new threads: one to perform the action in the background and the other to display a progress bar for the user. The background action thread is represented by the EventDispatcher class. The EventDispatcher.run() method contains a long list of switch statements that invoke the corresponding methods in the model layer to perform the action. When the model method returns, the controller displays the next UI screen using the appropriate view class.

Listing 5.1. The ConfirmTicketUI class represents the screen for confirming the ticket purchase

package com.sun.j2me.blueprints.smartticket.client.midp.ui

public class ConfirmTicketUI extends Form

           implements CommandListener, ItemCommandListener {



  private UIController uiController;

  private Command cancelCommand;

  private Command confirmCommand;

  private StringItem theater, movie, showTimeStr, seatsStr;

  private StringItem cost, totalCost, placeOrderBtn;



  public ConfirmTicketUI(UIController uiController) {

    super(uiController.getString(UIConstants.CONFIRM_TITLE));



    this.uiController = uiController;



    createItems();

    append(theater); append(movie); append(showTimeStr);

    append(seatsStr); append(cost); append(totalCost);

    append(placeOrderBtn);



    confirmCommand =

       new Command(uiController.getString(UIConstants.CONFIRM),

                    Command.OK, 5);

    cancelCommand =

        new Command(uiController.getString(UIConstants.CANCEL),

                    Command.EXIT, 5);

    addCommand(confirmCommand);

    addCommand(cancelCommand);

    setCommandListener(this);

    placeOrderBtn.setDefaultCommand(confirmCommand);

    placeOrderBtn.setItemCommandListener(this);

  }



  public void init(String theaterName, String movieName,

                            int[] showTime, Seat[] seats) {

    // Set the display strings to the correct values

  }



  // Command callback for UI events for text button "placeOrderBtn"

  public void commandAction(Command command, Item item) {

    if (command == confirmCommand) {

      uiController.purchaseRequested();

    }

  }



  // Command callback for UI events on the command buttons

  public void commandAction(Command command, Displayable displayable) {

    if (command == cancelCommand) {

        uiController.mainMenuRequested();

    } else if (command == confirmCommand) {

        uiController.purchaseRequested();

    }

  }

}

Listing 5.2. Process the purchaseTickets action in the UIController class in the controller layer

package com.sun.j2me.blueprints.smartticket.client.midp.ui;

public class UIController {



  // references to all UI classes

  // ... ...



  public UIController(MIDlet midlet, ModelFacade model) {

    this.display = Display.getDisplay(midlet);

    this.model = model;

  }



  // ... ...



    public void purchaseRequested() {

    runWithProgress(

       new EventDispatcher(EventIds.EVENT_ID_PURCHASEREQUESTED,

                           mainMenuUI),

       getString(UIConstants.PROCESSING), false);

  }



  class EventDispatcher extends Thread {

    private int taskId;

    private Displayable fallbackUI;



    EventDispatcher(int taskId, Displayable fallbackUI) {

      this.taskId = taskId;

      this.fallbackUI = fallbackUI;

      return;

    }



    public void run() {

      try {

        switch (taskId) {



          // cases ... ...



          case EventIds.EVENT_ID_PURCHASEREQUESTED: {

            model.purchaseTickets(reservation);

            purchaseCompleteUI.init(reservation.getId(),

                                   selectedTheater.getName(),

                                   selectedMovie.getTitle(),



                                   selectedShowTime);

            display.setCurrent(purchaseCompleteUI);



            break;

          }



          // Other cases ... ...



        }

      } catch (Exception exception) {

        // handle exceptions

      }

    } // end of run() method

  } // end of the EventDispatcher class

}

5.3.2 The Clientside Facade

The facade pattern is a structural pattern that provides a simple interface for complex subsystems. In the Smart Ticket application, the clientside subsystems in the model layer, such as the LocalModel, RemoteModelProxy, and SynchronizationAgent classes, are behind the facade class ModelFacade (Listing 5.3), which is the entry point from the controller to the model. The ModelFacade class contains one method for each action in the model layer. It delegates the actions to the subsystems as follows.

• The LocalModel class handles actions that access the local on-device storage. For example, the purchaseTickets() method adds the purchased movie to the on-device rating list. The addMovieRating() action method in the LocalModel class is called.

• The RemoteModelProxy class, which implements the RemoteModel interface, handles actions that require access to the remote J2EE server. For example, if the user decides to purchase tickets (reserveSeats() and purchaseTickets()), the transaction has to be done on the server side and be persisted to the database through the RemoteModelProxy. Action methods in the RemoteModelProxy class invoke remote procedure calls (RPC) to the remote facade on the server side. The details of the remote facade and the RPC format are discussed later in this chapter.

• The SynchronizationAgent class handles all synchronization actions from the local data storage to the remote server. In the case of the Smart Ticket application, it handles only the movie ratings synchronization. It has two action methods: The synchronizeMovieRatings() method synchronizes the ratings; the commitMovieRatings() method commits the resolved synchronization requests to the back end and updates the content of the local store.

The three interactions are illustrated in the following code snippet (Listing 5.3).

Listing 5.3. The ModelFacade class

package com.sun.j2me.blueprints.smartticket.client.midp.model;



public class ModelFacade {



  private SynchronizationAgent syncAgent;



  private RemoteModelProxy remoteModel;

  private LocalModel localModel;





  // Action methods ... ...

  public Reservation reserveSeats(String theaterKey,

        String movieKey, int[] showTime, Seat[] seats)

                        throws ApplicationException {

    try {

      return remoteModel.reserveSeats(theaterKey,

                         movieKey, showTime, seats);

    } catch (ModelException me) {

      // ... ...

    }

  }



  public void purchaseTickets(Reservation reservation)

                         throws ApplicationException {

    try {

      remoteModel.purchaseTickets(reservation.getId());



      // Purchased movies are eligible for rating.

      localModel.addMovieRating(

        new MovieRating(

          remoteModel.getMovie(reservation.getMovieId()),

                    reservation.getShowTime()));

    } catch (ModelException me) {

      // ... ...

    }

    return;

  }



  public void synchronizeMovieRatings(

                    int conflictResolutionStrategyId)

                          throws ApplicationException {

    try {

      syncAgent.synchronizeMovieRatings(conflictResolutionStrategyId);

      return;

    } catch (ModelException me) {

      // ... ...

    }

  }

  // ... ...

}

 

5.3.3 The Serverside Facade

One of the most important benefits of the facade pattern is that it reduces network round trips between remote systems. A properly designed facade allows us to use fine-grained objects in the subsystems yet still have a coarsegrained, simple network interface. It is especially important for mobile applications, since the wireless network is very slow.

When an RPC is made from the RemoteModelProxy to the server side, the HTTP servlet SmartTicketServlet (Listing 5.4) invokes the corresponding action method in Session EJB SmartTicketFacadeBean (Listing 5.6) through a business delegate object SmartTicketBD (Listing 5.5). Depending on the nature of the action, it is further delegated to either TicketingBean or SynchronizingBean, both of which are session EJBs too. The application data on the server side is persisted to the relational database through an array of Container Managed Persistence (CMP) v2.0 entity EJBs.

Listing 5.4. The gateway servlet SmartTicketServlet

package com.sun.j2me.blueprints.smartticket.server.web.midp;



public class SmartTicketServlet extends HttpServlet {



  public static final String SESSION_ATTRIBUTE_SMART_TICKET_BD =

   "com.sun.j2me.blueprints.smartticket.server.web.midp.SmartTicketBD";



  protected void doPost(HttpServletRequest request,

                        HttpServletResponse response)

                        throws ServletException, IOException {

     HttpSession session = request.getSession(true);

        SmartTicketBD smartTicketBD =

(SmartTicketBD) session.getAttribute(SESSION_ATTRIBUTE_SMART_TICKET_BD);



     // Calls handleCall() method and encode the URL for

     // session tracking

  }



  public int handleCall(SmartTicketBD smartTicketBD, InputStream in,

                         OutputStream out) throws IOException,

                         ApplicationException {

    // Identifies the requested action method



    // Execute the method through a list of switch -- case statements

    switch (method) {



    // ... ...



    case MessageConstants.OPERATION_GET_MOVIE:

         getMovie(smartTicketBD, call, successfulResult);

    break;



    // ... ...



    }

  }

}

Listing 5.5. The business delegate class SmartTicketBD

package com.sun.j2me.blueprints.smartticket.server.web.midp;



public class SmartTicketBD implements RemoteModel {

  public static final String EJB_REF_FACADE = "ejb/SmartTicketFacade";

  private SmartTicketFacadeLocal facade;

  private ServletContext servletContext = null;



  public SmartTicketBD(ServletContext servletContext)

        throws ApplicationException {

    this.servletContext = servletContext;



    try {

      Context context =

         (Context) new InitialContext().lookup("java:comp/env");

      facade =

 ((SmartTicketFacadeLocalHome)context.lookup(EJB_REF_FACADE)).create();



      return;

    } catch (Exception e) {

      throw new ApplicationException(e);

    }

  }



  public Movie getMovie(String movieKey)

            throws ModelException, ApplicationException {

    try {

      MovieLocal movieLocal = facade.getMovie(movieKey);

      Movie movie = new Movie(movieLocal.getId(),

                              movieLocal.getTitle(),

                              movieLocal.getSummary(),

                              movieLocal.getRating());



      return movie;

    } catch (SmartTicketFacadeException stfe) {

      throw new ModelException(ModelException.CAUSE_MOVIE_NOT_FOUND);

    } catch (Exception e) {

      throw new ApplicationException(e);

    }

  }



  // Other action methods in RemoteModel interface



}

Listing 5.6. The facade session bean SmartTicketFacadeBean

package com.sun.j2me.blueprints.smartticket.server.ejb;



public class SmartTicketFacadeBean implements SessionBean {



  // ... ...



  public void ejbCreate() throws CreateException {

    // ... ...

    Context context =

        (Context) new InitialContext().lookup("java:comp/env");

    ticketingHome =

        (TicketingLocalHome) context.lookup(EJB_REF_TICKETING);

    synchronizingHome =

      (SynchronizingLocalHome) context.lookup(EJB_REF_SYNCHRONIZING);

    // ... ...

  }



  public MovieLocal getMovie(String movieId)

          throws SmartTicketFacadeException {

    try {

      return movieHome.findByPrimaryKey(movieId);

    } catch (FinderException fe) {

      throw new SmartTicketFacadeException("No matching movie.");

    }

  }



  public void purchaseTickets(String reservationId)

            throws SmartTicketFacadeException {

    if (ticketing != null) {

      ticketing.purchaseTickets(reservationId);

      return;

    }

    throw new SmartTicketFacadeException("User not logged in.");

  }



  public MovieRatingData[] synchronizeMovieRatings(

                      MovieRatingData[] movieRatings,

                      int conflictResolutionStrategyId)

                        throws SmartTicketFacadeException {

    if (synchronizing != null) {

      return synchronizing.synchronizeMovieRatings(movieRatings,

                    conflictResolutionStrategyId);

    }

    throw new SmartTicketFacadeException("User not logged in.");

  }



  // ... ...

}

5.4 Implementation Techniques

The MVC and facade patterns define the overall architecture of the application. In addition, Smart Ticket showcases some important behavioral patterns and implementation techniques that could greatly improve developer productivity.

5.4.1 Chain of Handlers

On the J2ME device side, the RemoteModelProxy class (see Listing 5.3) further delegates the action to a chain of handler classes that transparently work out the dirty plumbing of the RMS and HTTP serialization. The chained handlers are based on the RequestHandler interface and the RemoteModelRequestHandler abstract class (Listing 5.7), which implements the former:

Listing 5.7. The RemoteModelRequestHandler class

public interface RequestHandler {



    RequestHandler getNextHandler();

    void init() throws ApplicationException;

    void destroy() throws ApplicationException;

}



abstract public class RemoteModelRequestHandler

           implements RequestHandler, RemoteModel {



  private RemoteModelRequestHandler nextHandler;

  private Preferences preferences;

  protected static ProgressObserver progressObserver;



  public RemoteModelRequestHandler(

      RemoteModelRequestHandler nextHandler) {

    this.nextHandler = nextHandler;

  }



  public RequestHandler getNextHandler() {

    return nextHandler;

  }



  public void init() throws ApplicationException {

    if (nextHandler != null) {

      nextHandler.init();

    }

    return;

  }



  public void destroy() throws ApplicationException {

    if (nextHandler != null) {

      nextHandler.destroy();

    }

    return;

  }



  public void login(String userName, String password)

            throws ModelException, ApplicationException {

    getRemoteModelRequestHandler().login(userName, password);

    return;

  }



  public void createAccount(AccountInfo accountInfo)

            throws ModelException, ApplicationException {

    getRemoteModelRequestHandler().createAccount(accountInfo);

    return;

  }



  // Other action methods declared in RemoteModel

  // ... ...

}

Concrete handler classes extend the RemoteModelRequestHandler class. A chain of handlers is established through nested constructors. Two handler classes are available in the Smart Ticket application: the RMSCacheHandler and HTTPCommunicationHandler classes. Listing 5.8 illustrates how the chain is assembled and used (e.g., getMovie()) in the RemoteModelProxy class.

Listing 5.8. Assemble the handler chain in class RemoteModelProxy

public class RemoteModelProxy extends ModelObjectLoader

                                 implements RemoteModel {



  private RemoteModelRequestHandler requestHandlerChain;

  private Preferences preferences = null;

  private Hashtable movies = new Hashtable();



  public RemoteModelProxy(String serviceURL)

                 throws ApplicationException {

    requestHandlerChain =

        new RMSCacheHandler(

            new HTTPCommunicationHandler(null, serviceURL));

    return;

  }



  // ... ...



  // get a movie from the chain of handlers

  public Movie getMovie(String movieKey)

            throws ModelException, ApplicationException {

    Movie movie = (Movie) movies.get(movieKey);



    if (movie == null) {

      movie = requestHandlerChain.getMovie(movieKey);

      movies.put(movieKey, movie);

    }

    return movie;

  }

  // Other action methods etc.



}

A handler can selectively implement any action methods in the RemoteModel interface. There are two possibilities:

• If a RemoteModelProxy class calls an action method not implemented by the first handler class in the chain, the default implementation in the base class RemoteModelRequestHandler ensures that the call is passed to the next handler in the chain.

• If a handler in a chain decides that it has finished processing an action, it returns directly. Otherwise, it can invoke the same action method in the base class to pass it to the next handler in the chain.

The following code snippets (Listing 5.9 and 5.10) illustrate how to implement the getMovie() method in the two handlers. The RMSCacheHandler looks up the on-device cache for the requested movie. If the requested movie is not cached, RMSCacheHandler calls its base class's getMovie() method, which passes the control to the next handler in the chain: the HTTPCommunicationHandler class. The getMovie() method in HTTPCommunicationHandler performs some network tasks to retrieve the movie object from the J2EE back end. To understand the inner workings of the HTTPCommunicationHandler class, you need to read on to the next section.

Listing 5.9. The getMovie() method in RMSCacheHandler

public class RMSCacheHandler extends RemoteModelRequestHandler {



  // ... ...



  public Movie getMovie(String movieKey)

            throws ModelException, ApplicationException {

    IndexEntry indexEntry = rmsAdapter.getIndexEntry(movieKey,

                IndexEntry.TYPE_MOVIE, IndexEntry.MODE_ANY);



    if (indexEntry != null) {

      return rmsAdapter.loadMovie(indexEntry.getRecordId());

    }

    return super.getMovie(movieKey);

  }



  // ... ...

}

Listing 5.10. The getMovie() method in HTTPCommunicationHandler

public class HTTPCommunicationHandler

            extends RemoteModelRequestHandler {

  // ... ...



  public Movie getMovie(String movieKey)

          throws ModelException, ApplicationException {

    HttpConnection connection = null;

    DataOutputStream outputStream = null;

    DataInputStream inputStream = null;



    try {

      connection = openConnection();

      updateProgress();



      outputStream = openConnectionOutputStream(connection);

      outputStream.writeByte(MessageConstants.OPERATION_GET_MOVIE);

      outputStream.writeUTF(movieKey);

      outputStream.close();

      updateProgress();



      inputStream = openConnectionInputStream(connection);

      Movie movie = Movie.deserialize(inputStream);

      updateProgress();

      return movie;

    } catch (IOException ioe) {

      throw new

         ApplicationException(ErrorMessageCodes.ERROR_CANNOT_CONNECT);

    }

    finally {

      closeConnection(connection, outputStream, inputStream);

    }

  }



  // ... ...

}

5.4.2 Binary RPC over HTTP

In the model layer, the HTTPCommunicationHandler class in the RemoteModelProxy class invokes remote procedures on the J2EE server side through a binary RPC protocol over the HTTP.

All RPC requests from the client to the server follow the same basic pattern: The first byte in the HTTP request data stream specifies the action method to be executed on the serverside session facade EJB. The RPC request code constants are defined in the MessageConstants class (Listing 5.11).

Listing 5.11. The RPC action codes in MessageConstants

package com.sun.j2me.blueprints.smartticket.shared.midp;



  public final class MessageConstants {

  public static final byte OPERATION_LOGIN_USER = 0;

  public static final byte OPERATION_CREATE_ACCOUNT = 1;

  public static final byte OPERATION_UPDATE_ACCOUNT = 2;

  public static final byte OPERATION_GET_THEATERS = 3;

  public static final byte OPERATION_GET_THEATER_SCHEDULE = 4;

  public static final byte OPERATION_GET_MOVIE = 5;

  public static final byte OPERATION_GET_MOVIE_POSTER = 6;

  public static final byte OPERATION_GET_MOVIE_SHOWTIMES = 7;

  public static final byte OPERATION_GET_SEATING_PLAN = 8;

  public static final byte OPERATION_RESERVE_SEATS = 9;

  public static final byte OPERATION_PURCHASE_TICKETS = 10;

  public static final byte OPERATION_CANCEL_SEAT_RESERVATION = 11;

  public static final byte OPERATION_GET_LOCALES = 12;

  public static final byte OPERATION_GET_RESOURCE_BUNDLE = 13;

  public static final byte OPERATION_INITIATE_SYNCHRONIZATION = 14;

  public static final byte OPERATION_SYNCHRONIZE_MOVIE_RATINGS = 15;

  public static final byte OPERATION_COMMIT_MOVIE_RATINGS = 16;

  public static final byte ERROR_NONE = 0;

  public static final byte ERROR_UNKNOWN_OPERATION = 1;

  public static final byte ERROR_SERVER_ERROR = 2;

  public static final byte ERROR_MODEL_EXCEPTION = 3;

  public static final byte ERROR_REQUEST_FORMAT = 4;



  private MessageConstants() {}

}

The second byte to the end of the request stream encodes a sequence of UTF strings that represent the parameters to be passed to the remote method. The response HTTP stream contains the RPC return value. The format is unique to each method, and you have to look at the source code for each method to figure out the exact format. The two code snippets below demonstrate the entire RPC round trip to get a list of theaters using a zip code. The RPC request is assembled in HTTPCommunicationHandler's action method getTheaters() (Listing 5.12), and the response array is unmarshaled by the shared model object Theater (Listing 5.13).

Listing 5.12. The HTTPCommunicationHandler class generates the RPC request in the handler chain

package com.sun.j2me.blueprints.smartticket.client.midp.model;



public class HTTPCommunicationHandler

             extends RemoteModelRequestHandler {

  // ... ...



 public Theater[] getTheaters(String zipCode)

            throws ModelException, ApplicationException {

    HttpConnection connection = null;

    DataOutputStream outputStream = null;

    DataInputStream inputStream = null;



    try {

      connection = openConnection();

      updateProgress();

      outputStream = openConnectionOutputStream(connection);



      outputStream.writeByte(MessageConstants.OPERATION_GET_THEATERS);

      outputStream.writeUTF(zipCode);

      outputStream.close();

      updateProgress();



      inputStream = openConnectionInputStream(connection);



      // The first number in the response stream indicates

      // the number of theater objects to follow.

      Theater[] theaters = new Theater[inputStream.readInt()];



      // Iterate to unmarshal all theater objects in the response.

      for (int i = 0; i < theaters.length; i++) {

        theaters[i] = Theater.deserialize(inputStream);

      }

      updateProgress();

      return theaters;

    } catch (IOException ioe) {

      throw new

        ApplicationException(ErrorMessageCodes.ERROR_CANNOT_CONNECT);

    } finally {

        closeConnection(connection, outputStream, inputStream);

    }

  }



  // Other action methods

}

Listing 5.13. The Theater class in the J2ME model layer unmarshals the RPC response

package com.sun.j2me.blueprints.smartticket.shared.midp.model;



public class Theater {

  private String primaryKey;

  private String name;

  private String address;

  private String zipCode;



  // ... ...



  public static Theater deserialize(DataInputStream dataStream)

                                     throws ApplicationException {

    try {

      Theater theater = new Theater();

      theater.zipCode = dataStream.readUTF();

      theater.primaryKey = dataStream.readUTF();

      theater.name = dataStream.readUTF();

      theater.address = dataStream.readUTF();

      return theater;

    } catch (IOException ioe) {

      throw new ApplicationException(ioe);

    }

  }

  // ... ...

}

The SmartTicketServlet first determines the RPC action code from the first byte in the request stream. It then dispatches the RPC to the corresponding action method through the facade and passes all the RPC parameters remaining in the stream. In the Smart Ticket application, the client and server are tightly coupled. This approach can improve network efficiency, since each RPC exchange can be specially designed and optimized. However, the trade-off is development speed and robustness. If we make small changes to the server, the protocol and the parsing code on the client are likely to need to change too. We need to keep track of and update the code in multiple places, which could prove error prone. We also often need to recompile and redistribute clients.

5.4.3 The Clientside Thread Model

The Smart Ticket application uses a sophisticated threading model on the mobile client side. During a prolonged background task, another thread displays a moving gauge to the user indicating the progress (Figure 5.6). The gauge screen could also provide a button for the user to cancel the long action if she does not want to wait.

 

 

As we have seen, action methods in the UIController class are simply wrappers of the runWithProgress() method (Listing 5.14), which sets the display to ProgressObserverUI and starts the EventDispatcher thread. The ProgressObserverUI screen displays a gauge and an optional Stop button, which is monitored by the main MIDlet system UI thread. As we described in Section 5.3.1, the EventDispatcher thread eventually delegates the action to methods in the model layer. The model action method calls the ProgressObserverUI's updateProgress() method (Listing 5.15) at certain stages over the execution to update the gauge and inform the user of the progress (see Listing 5.12).

Listing 5.14. The runWithProgress() method in the UIController class

public class UIController {



  // Action methods ...



  public void chooseMovieRequested() {

    runWithProgress(

      new EventDispatcher(

        EventIds.EVENT_ID_CHOOSEMOVIEREQUESTED, mainMenuUI),

        getString(UIConstants.PROCESSING), false);

  }



  // Action methods ...



  public void runWithProgress(Thread thread, String title,

                                boolean stoppable) {

    progressObserverUI.init(title, stoppable);

    getDisplay().setCurrent(progressObserverUI);

    thread.start();

  }



  class EventDispatcher extends Thread {

    // ... ...



    public void run() {

      // Switch -- case statements to delegate

      // actions to the model layer

    }

  }

}

Listing 5.15. The ProgressObserverUI class

public class ProgressObserverUI extends Form

     implements ProgressObserver, CommandListener {

  private UIController uiController;

  private static final int GAUGE_MAX = 8;

  private static final int GAUGE_LEVELS = 4;

  int current = 0;

  Gauge gauge;

  Command stopCommand;

  boolean stoppable;

  boolean stopped;



  public ProgressObserverUI(UIController uiController) {

      super("");

      gauge = new Gauge("", false, GAUGE_MAX, 0);

      stopCommand =

         new Command(uiController.getString(UIConstants.STOP),

                                Command.STOP, 10);

      append(gauge);

      setCommandListener(this);

  }



  public void init(String note, boolean stoppable) {

    gauge.setValue(0);

    setNote(note);

    setStoppable(stoppable);

    stopped = false;

  }



  public void setNote(String note) {

    setTitle(note);

  }



  public boolean isStoppable() {

    return stoppable;

  }



  public void setStoppable(boolean stoppable) {

    this.stoppable = stoppable;

    if (stoppable) {

      addCommand(stopCommand);

    } else {

      removeCommand(stopCommand);

    }

  }



  // Indicates whether the user has stopped the progress.

  // This message should be called before calling update.

  public boolean isStopped() {

    return stopped;

  }

  public void updateProgress() {

    current = (current + 1) % GAUGE_LEVELS;

    gauge.setValue(current * GAUGE_MAX / GAUGE_LEVELS);

  }



  public void commandAction(Command c, Displayable d) {

    if (c == stopCommand) {

      stopped = true;

    }

  }

}

 

Note

1. Start up the MIDlet.
2. Choose Update Token and put in username/password pair test01/pass01. Then click UPDATE. The MIDlet will contact the single sign-on server and obtain a new authentication token for future use.
3. Choose Add Course. Add in a new class survey nickname and endpoint URL. You can just accept the suggested values.
4. Now you should see CS 301 available for selection under the Choose Course menu item. If you want to add more class surveys, you can repeat the last step.
5. Choose a course. iFeedBack will fetch the current question and display it for you.
6. Choose the appropriate answer and put in any comments. Then click SAVE to save the time-stamped answer to the on-device persistent cache.
7. You can repeat the last two steps multiple times for different questions from different courses.
8. From the main menu, click Submit Answers to submit all cached answers to their corresponding endpoints. All successfully submitted answers will be deleted from the cache.
9. Now you can view the uploaded answers from the class survey server. Just point your HTML browser to the URL

              http://host:8080/iFeedBackSurvey/servlet/Server.

public abstract class MVCComponent implements CommandListener {

 // Set from outside at beginning

 public static Display display;

 // Returns the screen object from the derived class

 public abstract Displayable getScreen();

 public Displayable prepareScreen () throws Exception {

    if ( getScreen() == null ) {

      initModel();

      createView();

    } else {

      updateView();

    }

    getScreen().setCommandListener ( (CommandListener) this );

    return getScreen ();

 }

 public void showScreen() {

    try {

      display.setCurrent( prepareScreen() );

    } catch (Exception e) {

      e.printStackTrace();

      Alert a = new Alert("Error");

      a.setTimeout(Alert.FOREVER);

      display.setCurrent(a);

    }

 }

 // Initialize. If a data member is not backed by RMS,

 // make sure it is null before you put in values.

 protected abstract void initModel () throws Exception;

 protected abstract void createView () throws Exception;

 protected abstract void updateView () throws Exception;

 public abstract void commandAction(Command c, Displayable s);

}

public class UpdateToken extends MVCComponent {

 // MIDP UI components: Commands, TextFields etc.

 // ... ...

 // Model parameters

 private static String username;

 private static String password;

 private static String token;

 private static String endPointURL;

 // Bean-style methods to access data members

 // Event handler

 public void commandAction(Command c, Displayable s) {

    try {

      if (c == backCommand) {

        (new MainMenu()).showScreen();

      } else if (c == updateCommand) {

        username = usernameField.getString();

        password = passwordField.getString();

        UpdateTokenTask t =

          new UpdateTokenTask(endPointURL, display);

        t.go();

      }

    } catch (Exception e) {

      // Show some alerts

    }

 }

 public Displayable getScreen () {

    return screen;

 }

 // In initModel(), first check whether the

 // the data model is persistently saved.

 //

 // The use of persistent store is transparent

 // to this class's users.

 protected void initModel() throws Exception {

    try {

      securityInfoStore =

        RecordStore.openRecordStore("securityInfo", true);

      RecordEnumeration re =

        securityInfoStore.enumerateRecords(null, null, false);

      ByteArrayInputStream bais =

        new ByteArrayInputStream( re.nextRecord() );

      DataInputStream din = new DataInputStream(bais);

      username = din.readUTF();

      password = din.readUTF();

      token = din.readUTF();

      din.close();

      bais.close();

      securityInfoStore.closeRecordStore();

    } catch (Exception e) {

      username = Start.UsernameSugg;

      password = Start.PasswordSugg;

      token = "-1:-1";

    }

 }

 // createView() creates a view from the current

 // model into the screen object

 protected void createView() throws Exception {

    backCommand = new Command("MAIN", Command.SCREEN, 2);

    updateCommand = new Command("UPDATE", Command.SCREEN, 1);

    usernameField = new TextField("Username:",

                    username, 40, TextField.ANY);

    passwordField = new TextField("Password:",

                     password, 40, TextField.ANY);

    screen = new Form("Security Info");

    ((Form) screen).append( usernameField );

    ((Form) screen).append( passwordField );

    ((Form) screen).append( "Current Token is " + token );

    screen.addCommand( backCommand );

    screen.addCommand( updateCommand );

 }

 // updateView() updates the screen object when

 // the model changes.

 protected void updateView() throws Exception {

    // display updated username and password

    usernameField.setString( username );

    passwordField.setString( password );

    // Deletes the old token display

    ((Form) screen).delete(2);

    if ( "-1:-1".equals(token) ) {

      ((Form) screen).append("The current token is not valid");

    } else {

      ((Form) screen).append("Current Token is token");

    }

 }

}

 

public abstract class BackgroundTask extends TimerTask {

 private Thread th;

 private boolean stopped;

 // Could be set in derived class

 // If the task is successfully completed

 protected Displayable nextScreen;

 // If the task is aborted

 protected Displayable prevScreen;

 // Display to draw-on

 protected Display display;

 // The gauge screen title

 protected String title;

 // Do we need to display an alert before

 // moving to the nextScreen?

 protected boolean needAlert = false;

 protected Alert alertScreen;

 public BackgroundTask (Display d) {

    display = d;

    th = new Thread(this);

 }

 public void go () {

    stopped = false;

    th.start();

 }

 public void stop () {

    stopped = true;

    th.setPriority(Thread.MIN_PRIORITY);

 }

 public void run() {

    ProgressGauge pg = null;

    try {

      pg = new ProgressGauge(this, title, display, prevScreen);

      runTask ();

    } catch (Exception e) {

      // elaborate error handling using alerts

    } finally {

      // Since pg could callback and reset

      // "stopped" when its

      // Cancel key is pressed on Gauge.

      if (!stopped) {

        if ( needAlert ) {

          pg.setNextScreen(alertScreen, nextScreen);

        } else {

          pg.setNextScreen(nextScreen);

        }

        pg.stop(); // notify progress guage to quit

      }

    }

 }

 // template method.

 public abstract void runTask () throws Exception;

}

public class UpdateTokenTask

       extends BackgroundTask {

 private String endPointURL;

 public UpdateTokenTask (String url, Display d) throws Exception {

    super (d);

    endPointURL = url;

    prevScreen =

      (new UpdateToken()).prepareScreen();

 }

 public void runTask () throws Exception {

    String username = UpdateToken.getUsername ();

    String password = UpdateToken.getPassword ();

    String token = getToken(username, password);

    if ( "-1:-1".equals(token) ) {

      needAlert = true;

      alertScreen = new Alert("Cannot update token");

      alertScreen.setString(

          "Authentication failed!");

      alertScreen.setTimeout(Alert.FOREVER);

      nextScreen = prevScreen;

    } else {

      UpdateToken.setAll( username, password, token );

      needAlert = true;

      alertScreen = new Alert("Success!");

      alertScreen.setString("The new token is token");

      alertScreen.setTimeout(Alert.FOREVER);

      nextScreen = (new MainMenu()).prepareScreen();

    }

 }

 // ... ...

}

Public class SubmitAllTask extends BackgroundTask {

 public SubmitAllTask (Display d) throws Exception {

    // Set up screens

 }

 public void runTask () throws Exception {

    RecordStore answerStore =

        RecordStore.openRecordStore("answer", true);

    RecordEnumeration re =

        answerStore.enumerateRecords(null, null, false);

    int recordNum = 0;

    while ( re.hasNextElement() ) {

      recordNum++;

      int recordid = re.nextRecordId();

      ByteArrayInputStream bais =

        new ByteArrayInputStream( answerStore.getRecord(recordid) );

      DataInputStream din = new DataInputStream(bais);

      String url = din.readUTF();

      int qid = din.readInt();

      long timestamp = din.readLong();

      String answer = din.readUTF();

      String comment = din.readUTF();

      HttpConnection conn = null;

      DataInputStream hdin = null;

      DataOutputStream hdout = null;

      try {

        conn = (HttpConnection) Connector.open( url );

        conn.setRequestMethod(HttpConnection.POST);

        hdout = conn.openDataOutputStream();

        hdout.writeInt(1); // Submit opcode

        hdout.writeUTF( UpdateToken.getToken () );

        hdout.writeLong( timestamp );

        hdout.writeInt( qid );

        hdout.writeUTF( answer );

        hdout.writeUTF( comment );

        hdout.flush();

        hdin = conn.openDataInputStream();

        boolean authsucc = hdin.readBoolean();

        if (authsucc) {

          boolean updatesucc = hdin.readBoolean();

          if ( updatesucc ) {

            answerStore.deleteRecord( recordid );

          } else {

            // Server error. Show alert

          }

          nextScreen = prevScreen;

        } else {

          // Auth error. Show Auth token screen

        }

      } finally {

        // Close all connections

      }

    }

    re.destroy();

    answerStore.closeRecordStore();

    // Setup the next screen and show the number of

    // records submitted

 }

}

Managed Smart Clients

4.1 Container-Managed Applications

In the field of software engineering, the term container refers to specialized software that runs other software. For example,

• The MIDP Application Management Software (AMS) is a container that installs, starts, pauses, stops, updates, and deletes MIDlet applications. In the CDC Personal Basis Profile, the Xlet programming model also features container-managed life-cycle methods.

• A Java servlet engine is a container that invokes servlets and provides access to the HTTP context.

• The Java Virtual Machine (JVM) itself is a container. It monitors Java applications for proper memory usage (garbage collector) and security.

In the next two sections, we will discuss the features and benefits of mobile containers.

4.1.1 Container Features

As mobile enterprise applications become mainstream, the complexity of smart clients grows. For example, fully commercial applications often require features such as user login, logging, transaction, and transparent data access. Without proper tools for code and service reuse, mobile developers have to duplicate those functionalities for every smart client. Wasting time reinventing the wheel is not only inefficient but also causes error-prone code.

Hence, it makes sense to make those common features available as services in software containers that run on mobile devices. An advanced container usually provides the following functionalities.

• Self-contained applications: Applications run inside the container are self-contained with portable code and necessary configuration files. The interdependence of applications and library components could be managed by the container. Examples are the WAR files for servlet containers and EAR files for EJB containers.

• Life-cycle management: By calling the life-cycle methods defined in the container framework and implemented by all applications, the container can install, start, stop, update, and delete any application programmatically or through an interactive console.

• Application services: The container provides services that are common to all applications. For example, an authentication module in the container could allow all applications to authenticate against a single password database.

• Custom services: The container should also allow its applications to offer services to each other. That encourages code reuse and prompts architectures for layered and modularized applications.

In this book, we use the term container rather loosely. Our containers do not impose arbitrary boundaries for API usages. Applications installed inside the container can transparently access any Java or native API available on the device. These containers are often known as frameworks. The container architecture on J2ME mobile devices is illustrated in Figure 4.1 

4.1.2 Benefits of Containers

The above container features translate to real benefits in mobile development projects:

• Reduced code redundancy: Since the common services are not repeatedly implemented, we can reduce overall footprint and potential number of errors while improving the developer productivity.

• Managed update: When we fix a bug or add a new feature in a service, all applications that use it automatically get the update. Some containers support service versioning for more refined controls.

• Support for multitiered application models: Services in a container offer natural separations between application tiers (e.g., the presentation and business layers).

• Simplified application provisioning: Self-contained applications can be easily deployed to any container. That enhances Java's value proposition of "write once, run anywhere."

Given these benefits, containers or frameworks are widely used in mobile Java application development. In the next section, we introduce a standard container specification for lightweight mobile devices: the OSGi specification.

4.2 OSGi Containers

The OSGi Alliance is an industry consortium that creates open standard specifications for network-delivered services. Founded in March 1999, OSGi is a nonprofit organization with open membership. Its board of directors includes Acunia, BMW, Deutsche Telekom, Echelon, Gatespace, IBM, Motorola, Oracle, Philips, ProSyst, Samsung, Sun and Telcordia. The OSGi specification defines the mobile container framework and standard container services as Java APIs that span from J2ME to J2SE to J2EE.

The OSGi Service Platform Release 2 specification was released in October 2001. It has been widely adopted by vendors and has many implementations. The OSGi Service Platform Release 3 specification was made available in March 2003. The IBM Services Management Framework (SMF) v3.5 is targeted to be OSGi R3 compatible. It is available for free evaluation from the IBM Web site (see "Resources"). We discuss both Release 2 and 3 in this chapter. However, all examples are written for and tested on Release 2 containers.

Note

Despite the term Gateway in its name, the OSGi specification does not define any particular kind of gateway servers. It defines a framework for service components delivery and execution. The OSGi container provides the runtime environment for those services. Gateway server is only one of OSGi's application areas.

4.2.1 Bundles

OSGi applications are packaged as bundles, which are just standard JAR files. The OSGi bundle is completely self-contained with all the necessary metadata in its manifest file. The OSGi container completely manages the bundle life cycle:

• Install, update, and uninstall the bundle.

• Start and stop the bundle.

• Register, unregister, and track services in the bundle.

The bundle management interfaces are defined in the org.osgi.framework package. Since the bundles can be deployed to the container dynamically without restarting the container, the OSGi platform is an ideal choice for mobile application provisioning clients. It allows applications to be managed, tracked, and updated throughout its lifetime.

4.2.2 Standard Services

The OSGi container provides common crosscutting services such as device drivers, user preferences, and logging to all its bundles. Table 4.1 lists the OSGi services defined in OSGi Service Platform Release 2 specification. The new OSGi Service Platform Release 3 specification defines more services, some of which are of great importance to mobile applications. Those new services are listed in Table 4.2.


 

4.2.3 Bundle Interaction and Custom Services

The OSGi framework provides powerful ways for bundles to interact with each other. This encourages code reuse and makes it easier to architect complex multilayer applications. For example, the OSGi container on a stock trader's PDA might be provisioned with services bundles from major exchanges. Each bundle knows how to run real-time queries and execute trades in a specific exchange market, and it makes those functionalities available to other bundles. The trader can then deploy the actual trading client bundle, which provides a user interface, supports custom trade logic, and executes the query/trade through the individual service bundles. The possible interactions among bundles are as follows.

• Static sharing: The OSGi container runs on a single JVM instance but has a different classloader for each bundle. That means bundle namespaces are separate. We cannot directly access objects or classes in another bundle by default. However, a bundle can explicitly export some of its Java packages through the Export-Package attribute in its manifest file. It can also import Java packages exported by others using the Import-Package manifest attribute. The export and import features allow direct sharing of Java packages.

• Dynamic services: In addition to standard services provided by the container, any bundle can consume and provide services from/to other bundles at the same time:

  1. A bundle can dynamically register (or unregister) services with the container. The bundle needs to register the service interface with a concrete implementation class. Any change to the service (register, modify, unregister) will result in framework events that could be captured and processed.

  2. Another bundle finds the service reference through a lookup API in the framework. It calls a framework method to obtain the service implementation object from the service provider bundle. The service object is now ready to use.

The interacting bundles allow us to deliver reusable services to any OSGi node, from the high function grid to pervasive devices.

4.2.4 OSGi Runtime Requirements

Currently, different OSGi vendors have different requirements for their products. The required execution environments range from PersonalJava v1.1 to J2SE. This has created considerable confusion in the developer community. In an effort to standardize the runtime requirements, the OSGi Service Platform Release 3 specification formally defines the following runtime environments:

• The Java 2 Micro Edition: All OSGi implementations should run under the CDC v1.0 plus Foundation Profile v1.0 runtime environment.

• The OSGi minimum execution environment: The specification also defines a subset of CDC/FP APIs, which allows devices not powerful enough for the CDC/FP (e.g., Palm PDAs) to run the OSGi framework. The OSGi minimum execution environment is defined to be a proper subset of CDC/FP and J2SE.

The standard execution environments make it easier for developers, especially resource-conscious mobile developers, to choose the right OSGi product.

 

4.3 A Simple Echo Service Example

In this section, we first introduce a J2ME-compatible OSGi implementation from IBM. Using a simple echo example, we demonstrate how to implement bundles and share services among them.

 

4.3.1 The IBM Service Management Framework

The IBM SMF is a readily available OSGi implementation. It has a memory footprint of 3 MB and runs on both execution environments defined in the OSGi Service Platform Release 3 specification. IBM supports the J2ME environments through WME (WebSphere Micro Environment JVM) and the minimum execution environment through WCE (WebSphere Custom Environment JVM) products. It can be tightly integrated into IBM's WebSphere Studio Device Developer IDE. The SMF product versions we cover in this book are v3.1 for OSGi R2 and v3.5 for OSGi R3.

The SMF installation process varies among devices. It generally involves the following steps.

 

1. Download and unpack the SMF toolkit from IBM.

2. Copy the following directories and files to the target device (or to a local execution directory, if you want to run SMF on a desktop computer). For my PocketPC device, I put all four items under the device root directory.

   • The jarbundles directory contains installed bundles.

   • The smf.jar file provides implementation classes for the OSGi specification.

   • The smfconsole.jar file provides a command-line management console for the container.

   • The smf.properties file specifies the runtime configuration.

3. Make sure that the com.ibm.osg.smf.bundledir property in the smf.properties file points to the correct bundle directory. For example,

   com.ibm.osg.smf.bundledir=jarbundles
   
   

4. Now we can start the SMF console using the following command (in one line) or its equivalent on the device platform.

   java -classpath "smf.jar:smfconsole.jar"
   
   com.ibm.osg.smf.SMFLauncher -console "launch"
   
   

   For my PocketPC device with IBM WebSphere Micro Environment preinstalled, I use the following command (in one line). Please refer to the Appendix B for the steps to install the IBM J2ME runtimes on PDA devices.

   "\WSDD\j9.exe" -jcl:foun
   
   "-Xbootclasspath:\WSDD\lib\jclFoundation\classes.zip;
   
   \smf.jar;\smfconsole.jar" "com.ibm.osg.smf.SMFLauncher"
   
   -console "Launch"
   

After the SMF console is started, it loads all currently installed bundles into the container and presents the user a command-line interface for management tasks. For a complete list of management commands, please refer to the SMF manual. Table 4.3 lists some of the most frequently used commands.




In the next two sections, we describe how to create and deploy two OSGi bundles: The EchoService bundle exposes an echo service; the EchoUIConsumer bundle presents a simple GUI client and uses the EchoService in the container to echo user input. Figures 4.3 and 4.4 show the two bundles in action in J2SE and J2ME OSGi containers. Figure 4.5 shows user interactive OSGi bundles.
 

 

4.3.2 The EchoService Bundle

The EchoService bundle demonstrates how to implement and register a service in an OSGi bundle. The service itself is extremely simple: It only defines one method that does nothing more than echo a string input. The steps to create the bundle are as follows.

Define the service interface as a Java interface (Interface EchoService, Listing 4.1).

 

Listing 4.1. The EchoService interface

package com.enterprisej2me.osgi.echoservice;



public interface EchoService {

  public String echo (String s);

}

Listing 4.2. The EchoServiceImpI class

package com.enterprisej2me.osgi.echoserviceimpl;



import com.enterprisej2me.osgi.echoservice.*;



public class EchoServiceImpl implements EchoService {



  EchoServiceImpl () { }



  public String echo (String s) {

    return s;

  }



}

Listing 4.3. The EchoActivator class

package com.enterprisej2me.osgi.echoserviceimpl;



import org.osgi.framework.*;

import com.enterprisej2me.osgi.echoservice.*;





public class EchoActivator implements BundleActivator {



  private ServiceRegistration reg;



  public EchoActivator () { }



  public void start (BundleContext context) throws Exception {

    EchoServiceImpl impl = new EchoServiceImpl ();

    reg = context.registerService (

        EchoService.class.getName(), impl, null);

  }



  public void stop (BundleContext context) throws Exception {

    reg.unregister ();

  }

}

Listing 4.4. The JAR manifest for the echo service bundle

Manifest-Version: 1.0

Bundle-Name: Echo service

Bundle-Description: Echo the input

Bundle-Activator: com.enterprisej2me.osgi.echoserviceimpl.EchoActivator

Import-Package: org.osgi.framework; specification-version=1.1

Export-Package: com.enterprisej2me.osgi.echoservice

Export-Service: com.enterprisej2me.osgi.echoservice.EchoSerivce

Now, we can install and start the package in our SMF console.

4.3.3 The EchoUIConsumer Bundle

The EchoUIConsumer bundle is created to demonstrate how to use the echo service through the framework:

1. Create a BundleActivator implementation as the entry point to the bundle (Class EchoUIConsumer, Listing 4.5).

2. In the EchoUIConsumer.start() method, create and open a ServiceTracker object to track the echo service we started.

3. Create the UI frame class EchoFrame (Listing 4.6) and pass the ServiceTracker object and the current bundle (i.e., the echo consumer bundle) to EchoFrame.

4. The EchoFrame object obtains the EchoService object from the ServiceTracker and uses the EchoService to echo any user input. When we hit the Exit button in the UI frame, the AWT event handler calls the bundle's stop() method and triggers the container to invoke the EchoUIConsumer.stop() method. For more details, refer to method actionPerformed() in Listing 4.6.

5. In the EchoUIConsumer.stop() method, dispose the UI frame and close the ServiceTracker (Listing 4.5).

6. Create the manifest file (Listing 4.7). We import the package containing the EchoService interface here.

7. Package and deploy the JAR bundle.

Tracking the Services In the service consumer bundles, we could manually look up the service objects from the framework. Then, we would have to register event listener and callback methods to handle situations when other bundles or the container itself changes those services (e.g., removes the service). This could be a tedious task. Instead, we take a shortcut and use a pair of ServiceTracker objects to automatically track those services. The ServiceTracker object tracks a list of services meeting certain criteria passed to it in the constructor. It provides default event handlers for the services it tracks. The ServiceTracker object can be instantiated with a ServiceTrackerCustomizer object. When a service in the tracker is added, modified, or deleted, the appropriate method in its associated ServiceTrackerCustomizer is called. For more usage examples of the ServiceTracker class, please refer to Section 4.4.




Listing 4.5. The EchoUIConsumer class

package com.enterprisej2me.osgi.echouiconsumer;



import org.osgi.framework.*;

import org.osgi.util.tracker.*;

import com.enterprisej2me.osgi.echoservice.*;



public class EchoUIConsumer implements BundleActivator {



  ServiceTracker echoTracker;

  EchoFrame frame;



  public EchoUIConsumer () { }



  public void start (BundleContext context) {

    echoTracker = new ServiceTracker (context,

               EchoService.class.getName(), null );

    echoTracker.open ();

    frame = new EchoFrame(250, 250, echoTracker, context.getBundle());

  }



  public void stop (BundleContext context) {

    frame.dispose ();

    echoTracker.close();

  }

}

Listing 4.6. The EchoFrame class

package com.enterprisej2me.osgi.echouiconsumer;



import java.awt.*;

import java.awt.event.*;

import org.osgi.framework.*;

import org.osgi.util.tracker.*;

import com.enterprisej2me.osgi.echoservice.*;



public class EchoFrame extends Frame

    implements WindowListener, ActionListener {



  private TextField entryText;

  private Label echoedText;

  private Button submit;

  private Button exit;

  private Panel content, top, bottom, middle;

  private ServiceTracker echoTracker;

  private Bundle echoUIConsumerBundle;



  public EchoFrame (int width, int height,

                    ServiceTracker t, Bundle b) {

    super ("Echo UI");

    setBounds(0, 0, width, height);

    echoTracker = t;

    echoUIConsumerBundle = b;



    entryText = new TextField (20);



    echoedText = new Label (" ");

    submit = new Button ("Echo");

    exit = new Button ("Exit");

    submit.addActionListener (this);

    exit.addActionListener (this);



    top = new Panel ();

    middle = new Panel ();

    bottom = new Panel ();

    top.setLayout(new FlowLayout(FlowLayout.LEFT));

    top.add(new Label("Echo: "));

    top.add(echoedText);

    middle.setLayout(new FlowLayout(FlowLayout.LEFT));

    middle.add(new Label("Input: "));

    middle.add(entryText);

    bottom.setLayout(new FlowLayout(FlowLayout.CENTER));

    bottom.add(submit);

    bottom.add(exit);



    content = new Panel ();

    content.setLayout(new GridLayout(3, 1));

    content.add(top);

    content.add(middle);

    content.add(bottom);



    add (content);

    addWindowListener(this);

    pack ();

    setVisible (true);

  }



  public void actionPerformed (ActionEvent e) {

    if ( e.getSource() == submit ) {

      top.remove (echoedText);



      // Obtain the echo service object

      EchoService echoObj = (EchoService) echoTracker.getService();

      // Use the echo service to echo a string

      echoedText = new Label ( echoObj.echo(entryText.getText()) );



      top.add (echoedText);

      entryText.setText("");

      setVisible (true);

    } else if ( e.getSource() == exit ) {

      // see note



      // echoUIConsumerBundle.stop();

      dispose ();

    }

  }



  public void windowClosing(WindowEvent e) {}

  public void windowOpened(WindowEvent e) {}

  public void windowClosed(WindowEvent e) {}

  public void windowIconified(WindowEvent e) {}

  public void windowDeiconified(WindowEvent e) {}

  public void windowActivated(WindowEvent e) {}

  public void windowDeactivated(WindowEvent e) {}



}

Listing 4.7. The manifest file for the echo consumer bundle

Manifest-Version: 1.0

Bundle-Name: Echo UI consumer

Bundle-Description: Consume the echo service

Bundle-Activator: com.enterprisej2me.osgi.echouiconsumer.EchoUIConsumer

Import-Package: com.enterprisej2me.osgi.echoservice,

 org.osgi.framework; specification-version=1.1,

 org.osgi.util.tracker; specification-version=1.1

Import-Service: com.enterprisej2me.osgi.echoservice.EchoSerivce
         

 

4.4 Smart Client with HTTP Front End

The managed GUI bundle uses only a fraction of the power provided by the OSGi container. Through its services, the OSGi container supports external applications and devices over the network. To use a separate program to render the UI, we can more effectively separate the business and presentation layers.

The "pizza order" example application distributed with the SMF illustrates the use of HTTP services in the OSGi framework. After starting the bundle from the SMF console, we can launch the device's built-in HTML browser (Internet Explorer for PocketPC or the Opera browser for Embedded Linux) and point the URL to http://localhost/pizza. An HTML page of a dummy pizza store appears. We can fill out the pizza order form, submit the form, and get response from a servlet running inside the bundle.

This design allows us to build a simple UI very quickly, using HTML without messaging with complex event handlers in AWT code. It also allows the vast majority of serverside Java developers to transfer their skills and make use of their familiar patterns, such as the Model-Viewer-Controller pattern. The overall architecture of the smart client with HTTP front end is illustrated in Figure 4.7.

4.4.1 The Pizza Order Bundle

The PizzaBundle class (Listing 4.8) implements the BundleActivator interface. This bundle does not register or provide any new services. It customizes the container HTTP service to serve pizza order HTML content at a specified URL. It also uses the container logging services to record activities inside the bundle. If no logging service has been registered for this bundle, it logs to the standard output.

1. The bundle start() method instantiates trackers for LogService and HttpService. The bundle then invokes their open() methods.

2. When the ServiceTracker for the HttpService is opened, it obtains all registered HttpService references from the container, adds them into the tracker, and invokes the corresponding ServiceTrackerCustomizer's addingService() method for each added reference.

3. The addingService() method obtains the HTTP service object from the container and customizes it with the pizza order servlet and other resources.

4. When the bundle stops, its stop() method calls the close() methods of the two ServiceTrackers. The HttpService tracker in turn calls the removedService() method, which unplugs the servlet from the HTTP service.

Listing 4.8. The PizzaBundle class

public class PizzaBundle implements

  BundleActivator, ServiceTrackerCustomizer {



  /** BundleContext for this bundle */

  protected BundleContext context;



  /** Log Service wrapper object */

  protected LogTracker log;



  /** Http Service tracker object */

  protected ServiceTracker tracker;



  /** HttpContext for HTTP registrations */

  protected HttpContext httpContext;



  // ... ...



  public PizzaBundle() { }



  // Methods in BundleActivator

  public void start(BundleContext context) throws Exception {

    this.context = context;

    httpContext = new HttpContext() { ... ... };

    log = new LogTracker(context, System.err);

    tracker = new ServiceTracker(context,

        HttpService.class.getName(), this);

    tracker.open();

  }



  public void stop(BundleContext context) throws Exception {

    tracker.close();

    log.close();



  }



  // Methods for ServiceTrackerCustomizer

  public Object addingService(ServiceReference reference) {

    HttpService http = (HttpService)context.getService(reference);

    if (http != null) {

      try {

        http.registerServlet(servletURI,

            new Pizza(), null, httpContext);

        http.registerResources(servletURI+imagesURI,

                           imagesURI, httpContext);

        log.log(log.LOG_INFO, "Pizza Servlet registered");

      } catch (Exception e) {

        // handle the exception

      }

    }

    return http;

  }



  public void modifiedService(ServiceReference

                    reference, Object service) {

  }



  public void removedService(ServiceReference

                    reference, Object service) {

    HttpService http = (HttpService) service;



    http.unregister(servletURI);

    http.unregister(servletURI+imagesURI);



    context.ungetService(reference);

    log.log(log.LOG_INFO, "Pizza Servlet unregistered");

  }

}

4.4.2 The Pizza Order Servlet

In the addingService() method, we use a servlet Pizza (Listing 4.9) to provide the custom HTTP service (the application logic). This is just a standard Java servlet that reads from HttpRequest and writes HTML data to HttpResponse objects. Those HTTP context objects are provided by the container.

Listing 4.9. The Pizza servlet

import javax.servlet.*;

import javax.servlet.http.*;

import java.io.*;

import java.util.*;



public class Pizza extends HttpServlet {

  protected void doGet(HttpServletRequest req,

                       HttpServletResponse res)

            throws ServletException, IOException {

    // Generate some output

    res.setContentType("text/html;" + "charset=iso-8859-1");

    PrintWriter out = res.getWriter();

    out.print(" ... ... ");



    // Get query parameters

    String queryString = req.getQueryString();



    // any pizza order logic

    // ... ...



    out.println("

 

2.4.2 J2ME Components

 

2.5 Competing Technologies

• WAP/WML: WAP/WML is a platform for thin client applications (i.e. microbrowser-based applications). The thin client paradigm is completely different from the smart client paradigm enabled by the J2ME (Chapters 3 and 4). J2ME smart clients are likely to replace WAP/XML applications in the future.
• BREW: Qualcomm's Binary Runtime Environment for Wireless (BREW) is a technology that supports rich client development and provisioning. BREW applications are written in C/C++ and run natively on BREW-enabled phones. However, only a limited number of phones support BREW. Although BREW native applications can be heavily optimized, they are not executed in managed environments and therefore are prone to programming errors. J2ME applications could run on BREW devices through a J2ME runtime for BREW (e.g., the BREW MIDP runtimes from IBM and Insignia).
• NET Compact Framework (.NET CF): Microsoft's .NET CF is the closest competition to the J2ME. Like J2ME, it targets smart-managed mobile clients development. It has a strong focus on enterprise applications. However, the .NET CF runs only on high-end Windows CE and PocketPC devices. For a detailed analysis of the .NET CF and J2ME, please refer to the articles in the "Resources" section.

 

public class CacheFilter implements Filter {

 // a very simple cache

 private Map cache;

 public void doFilter(ServletRequest request,

   ServletResponse response, FilterChain chain)

 throws IOException, ServletException {

   ...

 if (!cache.containsKey(key)) {

    cache.put(key, data);

 }

   // fulfill the response from the cache      

   if (cache.containsKey(key)) {

          ...         

   }

 }

 public void init(FilterConfig filterConfig) {

   ...

   cache = new HashMap( );

 }

}

cache.put(key, new SoftReference(data));

if (cache.containsKey(key)) {

 SoftReference ref = (SoftReference) cache.get(key);

 Object result = ref.get( );

 if (result == null) {

    cache.remove(key);

 }

}

import java.io.*;

import javax.servlet.*;

import javax.servlet.http.*;

import javax.naming.*;

import javax.naming.directory.*;

import java.util.*;

public class MagicServlet extends HttpServlet {

 private DirContext peopleContext;

  // setup LDAP access

 public void init(ServletConfig config)

 throws ServletException {

    super.init(config);

    Properties env = new Properties( );

    env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");

    env.put(Context.PROVIDER_URL, "ldap://localhost/o=jndiTest");

    env.put(Context.SECURITY_PRINCIPAL, "cn=Manager, o=jndiTest");

    env.put(Context.SECURITY_CREDENTIALS, "secret");

    try {

      DirContext initalContext = new InitialDirContext(env);

      peopleContext = (DirContext)initalContext.lookup("ou=people");

    } catch (NamingException ne) 2{

      ne.printStackTrace( );

      throw new UnavailableException("Error inializing LDAP", ne);

    }

 }

  // close LDAP 

  public void destroy( ) {

    try {

      peopleContext.close( );

    } catch(NamingException ne) {

      ne.printStackTrace( );

    }

 }

  // "magic" function is model, view and controller

 protected void doGet(HttpServletRequest request, 

             HttpServletResponse response)

 throws ServletException, IOException {

    // view logic

    response.setContentType("text/html");

    java.io.PrintWriter out = response.getWriter( );

    out.println("<html>");

    out.println("<head>");

    out.println("<title>

Servlet</title>");

    out.println("</head>");

    out.println("<body>");

    out.println("<table>");2

    // model logic

    try {

      NamingEnumeration people = peopleContext.list("");

      while(people.hasMore( )) {

        NameClassPair personName = (NameClassPair)people.next( );

        Attributes personAttrs = peopleContext.getAttributes(personName.getName( ));

        Attribute cn = personAttrs.get("cn");

        Attribute sn = personAttrs.get("sn");

        Attribute phone = personAttrs.get("telephoneNumber");

        out.println("<tr><

td>" + cn.get( ) + " " + 

              sn.get( ) + "</td>" +

              "<td>" + phone.get( ) + 

              "</td></

tr>");

      }

    } catch(Exception ex) {

      out.println("Error " + ex + " getting data!");

    }

    // back to view logic

    out.println("</table>");

    out.println("</body>");

    out.println("</html>");

 }

}

public interface PersonCommand {

 // initialize the command

 public void initialize(HttpSession session) throws NamingException; 

  // execute the query

 public void runCommand( );

  // get the result of the query as a List of class Person

 public List getPeople( );        

}

<%@page contentType="text/html"%>

<%@taglib uri="/jstl/core" prefix="c"%>

<html>

<head><

title>Addresses</title>

</head>

<body>

<jsp:useBean id="personCommand" scope="request"

       class="PersonCommand" />

<table>

 <c:forEach var="person" items="${personCommand.people}"

> 

 <tr><

td><c:out value="${person.firstName}"/

></td>

    <td><c:out 

value="${person.lastName}"/></

td>

    <td><c:out 

value="${person.phoneNumber}"/></

td>

 </tr>

 </c:forEach>

</table>

</body>

</html>

import javax.servlet.*;

import javax.servlet.http.*;

import java.IO.*

import javax.naming.*;

public class PersonServlet extends HttpServlet {

 protected void doGet(HttpServletRequest request,

             HttpServletResponse response)

 throws ServletException, IOException {

    try {

      PersonCommand personCommand = new LdapPersonCommand( );

      personCommand.initialize( );

      personCommand.runCommand( );

      request.setAttribute("personCommand", personCommand);

    } catch(NamingException ne) {

      throw new ServletException("Error executing " + "command", ne);

    }

    RequestDispatcher dispatch =

      getServletContext( ).getRequestDispatcher("/PersonView.jsp");

    dispatch.forward(request, response);

 }

}

<%@page contentType="text/html"%>

<%@page import="antipatterns.LoginManager" %>

<html>

<% 

  LoginManager lm = new LoginManager( );

 ServletRequest req = pageContext.getRequest( );

 if (!lm.doLogin(req.getParameter("username"), 

          req.getParameter("password"))) {

%>

<head><

title>Login Page</title>

</head>

<body>

 <form action="/LoginPage.jsp" method="post">

 User name: <input type="text" name="username">

<br>

 Password: <input type="password" name="password"

><br>

 <input type="submit">

 </form>

</body>

<% } else { %>

<head><

title>First Page</title>

</head>

<body>

 Welcome to the page!

<% } %>

</body>

</html>

if (lm.doLogin(username, password)) {

        nextPage = "/welcome.jsp";

} else {

        nextPage = "/login.jsp";

}

RequestDispatcher dispatch = 

  getServletContext( ).getRequestDispatcher(nextPage);

dispatch.forward(request, response);

protected void doGet(HttpServletRequest request,

           HttpServletResponse response)

throws ServletException, IOException {

 HttpSession session = request.getSession( );

  // create the bean

 AddressBean address = new AddressBean( );

 address.setFirst(request.getParameter("first"));

 address.setLast(request.getParameter("last"));

  // pass the bean to the view

 session.setAttribute("antipatterns.address", address);

  // instantiate the view

 RequestDispatcher dispatcher = 

    getServletContext( ).getRequestDispatcher("/View.jsp");

 dispatcher.forward(request, response);

}