Figure 1: The elements of J2ME -- A J2ME environment is a combination of a configuration, a profile, and any optional packages.

Figure 2: Enter a stock symbol -- After you install the example application, the device should look like this.

Figure 3: View the 20-minute delayed stock value -- The example application makes a Web service call to a remote server to get the stock value.

J2ME

J2ME defines a set of technologies for limited-resource devices. As I mentioned, these devices have hardware and bandwidth limitations that make them unsuitable for use with the full-feature J2SE edition. Even among these devices, some are more capable than others. To allow for such variations in device capabilities and features, the J2ME specification defines configurations and profiles. A J2ME environment is a combination of a configuration, a profile, and any optional packages (figure 1). Each environment is optimized towards a set of devices with similar features and capabilities.

Configuration
A configuration is aimed at a horizontal set of devices with similar hardware features. The configuration defines the minimal set of Java libraries that must be present as well as the features of the K Virtual Machine (KVM). Currently available configurations are the Connected Device Configuration (CDC) and the Connected Limited Device Configuration (CLDC). You use the CLDC on devices with lesser capabilities, such as cell phones, whereas you use the CDC on more capable devices, such as high-end PDAs.

The KVM is a virtual machine designed to demonstrate the basic functionalities of the CLDC specification in conjunction with the CLDC libraries.

Profile
A profile is always implemented on top of a configuration. It defines additional features and APIs for a specific vertical segment. Some examples of profiles are the Mobile Information Device Profile (MIDP, used with CLDC), Foundation Profile (used with CDC), Personal Basis Profile (used with CDC), and the Personal Profile (used with CDC). Refer to http://java.sun.com/j2me for more details on configurations and profiles.

For the rest of the article, I'll use J2ME with the CLDC/MIDP environment.

The extended enterprise

Users no longer access enterprise applications only from dedicated terminals. They have to access these applications anytime, anywhere, and often from different types of devices. Often, these devices are wireless devices such as cell phones, PDAs, etc. Consider a situation where workers on the shop floor need reliable access to applications on their handheld devices. The challenge is to have useful applications running on these different devices, which often have hardware and bandwidth constraints.

Your options are to build the application based on the programming environment for each of those device types or build one J2ME application that will run on all of them, assuming that all the devices have a supported J2ME implementation. If you choose the first approach, then you have a maintenance nightmare of actually supporting the different application platforms. It's obviously beneficial to build the application once and deploy it on all of these varying device types. That's exactly what J2ME can do. Because the J2ME architecture assumes a certain set of device capabilities exist, you could build the application using J2ME and have it installed on all the devices.

In the remaining part of this article, I'll explore different aspects of writing a J2ME client application.

Message exchange mechanisms (between client and server)

How do you exchange messages between the J2ME client application and the server? I'll discuss some possible solutions. The actual solution you use will depend on your application's requirements and architecture.

The CLDC/MIDP lets you make HTTP and HTTPS calls to remote servers, so all communication with the server can take place via HTTP. The message format can be either plain text or XML, although the latter requires that you have an XML parser on the J2ME devices. Lightweight XML parsers, such as kXML, are available for mobile devices.

Listing 1 shows a code sample of how to communicate using HTTP from a J2ME device.

Listing 1: HTTP-based communication between a server and J2ME device.

HttpConnection conn = null;
InputStream is = null;
OutputStream os = null;

try
{
  String url = ...;
  byte[] body = ...;

  // --set up the connection
  conn =  (HttpConnection)Connector.open(url, Connector.READ_WRITE,true);
  conn.setRequestMethod("POST");
  conn.setRequestProperty("Content-Length", "" + body.length);
  os = conn.openOutputStream();
  os.write(body);

  // -- resolve the response
  is = conn.openInputStream();
  int code = conn.getResponseCode();

  // --Check http response code
  if (code != HttpConnection.HTTP_OK))
  {
    // something went wrong...handle that
  }

  // --get the response
  ByteArrayOutputStream stream = new ByteArrayOutputStream(100);
  byte buffer[] = new byte[100];
  int read = 0;
  while ((read = is.read(buffer)) != -1)
  {
    stream.write(buffer, 0, read);
  }
}
finally
{
  // close http connection
  conn.close();

  // close the streams 'is' and 'os'
  is.close();
  os.close();
}

Web services
Web services are a standards-based technology you can use to communicate between distributed and heterogeneous applications within the enterprise and with external entities. Web services use Simple Object Access Protocol (SOAP) as the XML-based protocol to communicate between applications. Applications advertise their services using Web Services Definition Language (WSDL). WSDL is an XML document that describes the services and where to find them. Using SOAP and WSDL, you can expose individual application services as Web services. And finally, Universal Description, Discovery, and Integration (UDDI) lets you publish the Web service definitions so that customers can find the services.

Your J2ME clients can communicate with the server using Web services as the underlying communication mechanism. You'll need a SOAP toolkit for your J2ME device. For a quick example (listing 2), you can use the open-source kSOAP 1.2 (see http://ksoap.enhydra.org), which is designed to work on CLDC/MIDP devices. kSOAP also requires the kXML parser for parsing XML (you can get it at http://www.kxml.org).

Listing 2: A short example of communicating with the server from a J2ME client using Web services as the underlying communication mechanism.

import org.ksoap.*;
import org.ksoap.http.*;
.....
String symbol = "IBM";

SoapObject soapRequest = new SoapObject("urn:xmethods-delayed-quotes", "getQuote");
soapRequest.addProperty ("symbol", symbol);

Object result =
  new HttpTransport("http://services.xmethods.net/soap",
    "urn:xmethods-delayed-quotes#getQuote").call (soapRequest);
.....

Building a sample application using J2ME

I strongly recommend that you download and make use of the J2ME Wireless Toolkit, available at http://java.sun.com/products/j2mewtoolkit. This toolkit is invaluable for development purposes.

My example application is simple. It returns the 20-minute delayed stock value for the symbol you enter. I'll make a Web service call to a remote server to get the stock value. I don't go into details of Sun's MIDP 2.0 and its programming environment (for more information, go to http://java.sun.com/products/midp). I'll leave it upon the reader to learn the finer points of the API and the environment.

The following are the steps required to build an application:

1. Create a new project using the J2ME toolkit. This generates a project tree where you can place files. Name the project StockMidlet.
2. Write your Midlet java class (and any supporting helper classes). Place the source files in the <project>/src folder. For my example, you can also place the StockMidlet.java source code, which is listed with this article (also listed is the StockMidlet.jad file for your reference).
3. Place the kSOAP library in the <project>/lib folder.
4. Specify the permissions required for your MIDlet suite in the .JAD file, using Project > Settings > Permissions. Give your application "http" permissions.
5. Build your project.
6. Now you can run the application. Enter the stock symbol, and you should get back the 20-minute delayed value.