Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples

The Realities of Deploying Wireless J2ME Solutions Over Unreliable Networks

by Mike Wilson

The major players in the handheld market have put their weight behind Java (Nokia, Ericsson, Motorola), the 2.5-3.0G networks are coming online, and you've been sweating over a MIDlet for the past few weeks, rearing to get it up and running on the latest device.

It should work -- after all, it works well on your desktop emulator connecting to your back-end service. Two weeks before launch you get a MIDP device and are hit by some real-world wireless realities:

You have no control over the 17MHz processor on the device. You can optimize your code and load it on the device, but what can you do about the network? The one thing you have not possibly taken into account -- a fundamental requirement of applications operating in a wireless environment -- is to have an optimized reliable communication model over unreliable network conditions.

This is clearly an analysis and design flaw. The Internet is fast and reliable, in comparison to a wireless environment. GPRS network operators say they will achieve as little as 9-20 Kbs (speeds similar to the Mobitex PALM VII Network in the U.S.), even using all eight channels for data. Add to that the complexity of shadows and ad hoc disconnects, and obviously you have a totally different set of challenges to overcome. WAP was a good idea that worked well in emulator mode, but when used away from the desktop on a wireless device, the user experience was sub-optimal, to say the least.

Inflated market expectations of WAP -- expectations of having the full capabilities of the Internet on wireless devices -- fell well short of reality, impeding market adoption rates. Unfortunately, J2ME is on track to take the same path.


A large majority of MIDlets work under the client/server, request/response model over HTTP, relying on back-end services to do all of the heavy lifting. This leaves the MIDlet thin and simple, a requirement mandated by the limitations of the device and network. Programmers can take for granted that HTTP will be available on MIDP devices, since it is part of the related specification. We will first take a look at a simple example using this technology.

Wireless Java

Related Reading

Wireless Java
Help for New J2ME Developers
By Qusay Mahmoud

Client J2ME Using HTTP

In the following example we use a MIDlet POSTing to a servlet over HTTP, running under a Tomcat server. Note: You need to remember to set the MIME types as in Example 1 below, and then to handle the request/response model.

Example 1. Setting the MIME Type for, and POSTing within, a MIDlet

 1 // Callback for making the HTTP connection.
 2 public void prepareRequest( String originalURL, HttpConnection conn ) throws IOException{
 4   conn.setRequestMethod(HttpConnection.POST );
 5   conn.setRequestProperty("User-Agent", "Profile/MIDP-1.0 Configuration/CLDC-1.0" );
 6   conn.setRequestProperty("Content-Language", "en-US" );
 7   conn.setRequestProperty("Accept", "application/octet-stream" );
 8   conn.setRequestProperty("Connection", "close" );
 9   conn.setRequestProperty("Content-Length", Integer.toString( data.length ) );
10   OutputStream os = conn.openOutputStream();
11   os.write( data );
12   os.close();
13  }
15  ...........................
16  //HTTP Connection
17  try {
18    conn = HttpConnectionHelper.connect( url, this );
19    display("Connecting to the server..." );
20    int rc = conn.getResponseCode();
21    if( rc == HttpConnection.HTTP_OK ){
22      StringBuffer text = new StringBuffer();
23   ...........
24  } catch( IOException e ){ }

Example 2. Servlet  processing

    1 public class SampleServer extends HttpServlet { 
    3 public void doPost( HttpServletRequest request, HttpServletResponse response ) 
             throws IOException,   ServletException { 
    5  // Get the input stream and read the data... 
    6  ServletInputStream in = request.getInputStream(); 
    7  DataInputStream    din =  new DataInputStream( in ); 
    8  String text = din.readUTF(); 
    9  din.close(); 
   11  // Do something with the data. In this case make the string upper case and split it into tokens. 
   13  text = text.toUpperCase(); 
   14  StringTokenizer tok = new StringTokenizer(text ); 
   15 ........ 
   16 }

On the server side we could have used JSP or Perl, but for convenience and consistency with languages, a servlet is used. Looking at this example from a higher level, the MIDlet makes a connection to the servlet and sends a request, which in turn is processed by the servlet and then returned to the MIDlet. This works "out of the box" and runs very well within the desktop/Internet environment (it's definitely not rocket science), but for the reasons mentioned earlier, this will not work well within a wireless environment. HTTP has inherently high overheads that cause the inefficient transfer of data; most importantly, network coverage failures cannot be handled at all.

In addition to inefficient protocols, the operator's network resources (speed and capacity) have limitations; this is something that cannot be programmed around. No matter how fat the pipe is, it will be filled.

The following are some things we should think about when designing a J2ME mobile solution.

In addition to these concerns, you will also have to write into your code a lot more exception handling to make your solution ready for "general release." java.io.IOException is clearly not an optimal user experience.

Sun has put together a great resource called the Wireless Blue Print that enables a developer to quickly connect a MIDlet to a back-end service using Enterprise Java Beans. A standards-based approach using a J2EE application server is a step in the right direction, but this still does not solve any of the main issues of running a solution within a wireless environment. SOAP MIDlet examples have also been produced, again over HTTP, using XML to communicate to many devices, using a variety of operating systems. XML, like HTML and cHTML, is a very verbose way to get a simple piece of text from the client to the server. The markup language adds significantly to the minimum requirement of the actual payload; this additional overhead is much too excessive for real-world wireless solutions.

Size Does Matter

Size matters in two respects when making a MIDlet for the wireless environment: in the size of the packaged byte code, and in the size of the packets you are pumping over the network. Due to the increased lines of code for exception handling, persistent storage of messages, and resend code, your MIDlet is starting to really look bloated, since the space to download onto in the mobile device is still extremely tight. It is quite likely you will not be able to fit all of these requirements on the device. In most cases, it is up to you to be smarter with the architecture of the MIDlet code, and to compromise on the quality of service you are able to deliver.

Message size across a network is something mobile data operators watch very closely. Text-based markup languages, in most situations, really chew up bandwidth fast, whereas binary and string data types produce more efficient results.

Wireless Requirements and the HTTP Communication Model Do Not Match

The classic client/server architecture is one that even a beginner can come to terms with relatively quickly. Systems that use this model have a very tightly coupled linear communication protocol (request/response). Errors can occur within such systems when one of components' semantics change without the other party's knowledge. When logic changes, the related protocol is changed in turn; the result is corrupted communications -- things just stop working (see Figure 3).

Figure 3. An Adaptation of Charles Perrow's Interaction/Coupling Chart.

Processes in systems that are complex and tightly coupled to each other result in a high likelihood that an error will occur (Figure 3, Quadrant 2). The Three Mile Island nuclear accident and the Challenger disaster have been associated with complex tightly-coupled system design. Design of any type of system that has tightly coupled, complex interactions are by nature prone to accidents, as the acclaimed sociologist Charles Perrow shows in his seminal work Normal Accidents.

CORBA is another example of a system that is inherently error-prone. Experience has shown CORBA to be a complex system to set up and maintain with a tightly-coupled communication model. When a WAN CORBA system is used over fixed lines with poor quality of service (such as those in some areas of Asia), the system becomes extremely brittle and unstable, regularly breaking down and re-establishing connections, each of which takes up to two to three minutes. CORBA, as with HTTP, just does not work under unreliable network conditions, because of the inherent nature of their communication models.

What is needed is a system that achieves the basic requirements for communication within the wireless environment at the infrastructure level. Those requirements are:

The major players have not provided leadership in this area, nor have they understood the basic requirements for the new mobile data industry. Consequently, existing infrastructure companies have developed poorly-analyzed proprietary platforms that are not suitable for large-scale bearer/device-agnostic deployments in a disconnected environment.

An appropriate communication model needs to be applied to this unreliable wireless environment!


Sun's Client-Server Communications between MIDlets and Servlets

Sun's Wireless Blue Print

Enhydra's kSOAP

Charles Perrow's Normal Accidents

Mike Wilson is the Director of Product Management at Softwired AG. He has worked within the Telecommunications Industry as a Field Technician and in IT as a Developer/Manager in Australasia, Asia and Europe for over 10 years.

Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.