Master J2ME for live data delivery

Support multiple applications on multiple devices with this J2ME framework

1 2 Page 2
Page 2 of 2

The framework uses only one servlet as the entry point for all requests. Whether the request is a GET or a POST, the master servlet acts essentially the same: it decodes request and passes it on to the gateway. When the application returns a response, the master servlet encodes the data and attaches any necessary HTTP headers.

A notification engine is standard equipment on most application server setups, but in a wireless situation, those engines take on added importance and complexity. In wireless communications, a notification like a pager message can be an integral part of the application logic instead of an after-the-fact throwaway.

Ideally, to implement server push, you want to use SMS to notify a phone and have the MIDlet on the phone receive the message. Though simpler and more reliable than using a socket, this approach is not possible under standard MIDP. Some advanced phones, such as the Siemens SL45i, have native support along with Java extensions to do this; but, in general, a MIDlet lacks access to SMS. This might not be the case forever, so keep in mind when building your framework that SMS-enabled MIDP might become standard in the future.

Sending paging messages is also somewhat problematic. Pager service providers typically offer either a Web form or an email interface (and sometimes both) to let users send pages on their networks, but the multitude of such providers requires that a user register her pager with the application provider. Currently, no third-party products present a unified API for all paging networks.

J2EE-enabling the framework

The sample applications are not J2EE-enabled, but you can easily envision how to convert them. You could replace the explicit session ID in the sample framework with a cookie-based system and stateful session beans. Then, by giving the other application objects EJB interfaces, the sample would fit into any J2EE application server context. If you have many applications with frequently changing functionality, you might consider adding a Web services layer. This requires adding a lightweight XML parser (about 30 KB) and other components to the client, but lets the client discover services dynamically and reap other Web services benefits. The Resources section links to a whitepaper in Sun's BluePrint series on some issues surrounding J2EE for wireless application provisioning.

Implement Live Chess

The Live Chess client's job is minimal: it lets the user select a game to view and dumbly displays that game's positions. For server-oriented applications, you want to structure the client to be as thin as possible and process heavy data on the server. This seems contradictory. Usually in client/server development, you aim to offload as much processing as possible on the client; but when delivering to micro platforms like mobile phones, you want to minimize resource usage. Also, because the server runs J2SE/J2EE, it has much more powerful language capabilities than the stripped down client. These factors reverse the design logic normal in J2ME development.

Currently, MIDP 1.0 is strictly a client-initiated specification—no vendor-independent way exists for the server to push data or signal the device to begin receiving. Therefore, the Live Chess client control only implements its polling interface. You should also have a notification interface because MIDP 2.0 (also known as MIDP_NG), which entered public review in mid-April 2002, will support push similarly to how BlackBerry devices currently do: a separate thread on the device runs a listener on a well-known port to receive incoming data connections. Also, Live Chess could theoretically implement its notification interface with specific support for devices like BlackBerry.

Implement Event Alert

In the course of a clinical medical trial, anything negative and unexpected that happens to a patient is called an adverse event, and the investigating physician needs to be notified immediately if one occurs. The Event Alert application illustrates a typical adverse event system using our framework. In the example project, you implement Event Alert on top of the same framework that already delivers Live Chess. The framework's true test is whether it can implement the new application cleanly without interfering with existing applications. From Figure 4, you can see how the framework's various applications exist completely independently from the server's communications areas. The gateway unifies the external connections into one API for the applications and protects the applications from connection-related problems and error handling.

Event Alert defines the concrete class DataPacket_AdverseEvent to hold its information transfer. Because this class is derived from DataPacket, the gateway can handle it generically (see Listing 2). As far as the gateway is concerned, an Event Alert data packet does not differ from Live Chess's packet. The abstract class DataPacket defines base class methods that route data packets correctly:

Listing 2. Event Alert

import javax.servlet.*;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import org.johnchamberlain.j2meframework.DataPacket;
public class MasterServlet extends HttpServlet {
      private static final String DATA_PACKET_PARAM = "DP";
    public MasterServlet() {}
      public void init(ServletConfig config) throws ServletException {
            super.init(config);
      }
      public void destroy() {}
      public void doGet(HttpServletRequest request, 
                        HttpServletResponse response) 
                              throws ServletException, IOException {
            this.vHandleRequest(request, response);
      }
      public void doPost(HttpServletRequest request, 
                        HttpServletResponse response) 
                              throws ServletException, IOException {
            this.vHandleRequest(request, response);
      }
      public void doPut(HttpServletRequest request, 
                        HttpServletResponse response) 
                              throws ServletException, IOException {
            response.sendError (HttpServletResponse.SC_BAD_REQUEST, 
                                    "PUT not supported.");
      }
      public long getLastModified(HttpServletRequest request) { return -1; }
      void vHandleRequest(HttpServletRequest request, 
                              HttpServletResponse response){
            try {
                  String sRequestPath = request.getPathInfo();
                  String sDataPacket = request.getParameter(DATA_PACKET_PARAM);
                  Class classDataPacket = getDataPacketClass( sDataPacket );
                  Constructor con = 
                  classDataPacket.getConstructor(new Class[]{String.class});
                  DataPacket dpIn = 
                  (DataPacket)con.newInstance(new Object[]{sDataPacket});
                  ApplicationHandler app = getHandlerForURL( sRequestPath );
                  DataPacket dpOut = app.dpProcessPacket(dpIn);
                  response.setContentType("application/octet-stream");
                  response.setContentLength(dpOut.length());
                  response.getOutputStream().write(dpOut.getBytes());
                  response.getOutputStream().flush();
            } catch(Exception ex) {}
      }
      // ...
}

Unlike Live Chess, Event Alert uses the notification engine to page its users. A mobile phone might be turned off or have other availability problems. Users are also more likely to carry a pager than a phone. When a doctor needs to receive an alert, the paging system is the first line of defense. To make a paging notification, the application calls the appropriate API on the gateway, which in turn calls the appropriate module in the notification engine. Note that the notification engine will log the page—an important auditing function.

Even though Event Alert has different needs and functionality than Live Chess, it can easily live on the same servers because the framework keeps each application happy in its own sandbox.

Live! With J2ME

This article described the overall design considerations for a framework for delivering live data via a wireless device. You then saw how to implement two completely independent applications using the framework. The right design allows multiple applications to coexist peacefully and simultaneously support a range of different devices and communication protocols. Also, the framework must have a clear path for scalability.

Many developers unnecessarily restrict their delivery methods and range of supported devices to sidestep the complexity of multiplatform development. The whole idea of using Java, however, is to enable multiplatform development, which can be simple if you architect for it. For specialized applications, such as 3D games, for example, you might want to hardwire your delivery mechanism, but typical business applications that tend to use standard text controls and simple, scalable graphics can and should be supported across as many environments and transports as possible. By using a framework such as this one, you have the basis for maximum support for your J2ME systems.

John Chamberlain is a longtime consultant in the Boston area. He holds a master's degree in computer science, is a frequent contributor to technical journals, and has spoken at JavaOne. Check out his Website at http://johnchamberlain.com.

Learn more about this topic

Related:
1 2 Page 2
Page 2 of 2