The Complexity of Developing Mobile Networked Data Services, J2ME Wireless Connection Wizard For Sun ONE Studio

Print-friendly Version

by Enrique Ortiz
May 2003

The Evolution of Advanced Mobile Data and Services

With the proliferation of advanced wireless networks and devices, mobile operators and enterprises can now provide a variety of types of data services to their users. When combined with sophisticated software running on wireless devices, these services provide near real-time access to a broad range of information, from simple text messages and email to corporate data. Wireless technologies have become so accessible that anyone with the right set of skills can create and offer wireless-based services and solutions.

These advanced wireless applications are not standalone, however. They are part of a complex structure that spans wireless devices, wireless networks, the Internet, and back-end systems that typically reside on enterprise platforms.

Creating networked wireless applications requires a broad set of skills, and detailed knowledge of client technologies like the Mobile Information Device Profile (MIDP), a fundamental part of Java 2 Platform, Micro Edition (J2ME), of server technologies like servlets and web containers, and of the mechanisms they use to communicate with each other.

The J2ME Wireless Connection Wizard for Sun ONE Studio facilitates the creation of networked wireless applications and services by automating significant parts of the development process.

To see how the Connection Wizard can help you, you must first understand what is typically involved in the creation of networked wireless applications.

Elements of a Typical Networked Wireless Application

A typical networked wireless application is an end-to-end application, which relies on a complex infrastructure:

Figure 1: Environment of a Typical Networked Wireless Application (Click image to enlarge.)

A typical networked wireless application consists of:

• A network-aware application residing on a wireless device (the client).
• The wireless network and the Internet, and corresponding communication protocols.
• A secure private network that includes one or more firewalls, a proxy gateway or web server, and back-end applications and servers. This network typically resides on the enterprise's premises.

A closer look at the client device and server components is shown in Figure 2.

Figure 2: A Closer Look at a Networked Wireless Application (Click image to enlarge.)

This figure reveals an intricate set of components, indicating that the creation of a networked wireless application is a complex problem.

The Wireless (Client) Device and Application

On the wireless device we have the networked application, typically based on the J2ME platform's MIDP. The typical application structure may consist of the application logic, which drives the user interface and overall application behavior, and a remote service invocation and network layer that encodes requests to and and parses responses from a server on the Internet. The application may also store data locally, on the device. Figure 3 provides a high-level summary of a typical wireless client application.

Figure 3: Elements of a Typical Wireless Client Application

Creating the network logic requires developers to be familiar with how HTTP works, which services are available and their location, and how to encode requests and decode responses. This task can be cumbersome and must be repeated for each new application. To avoid repetition some developers may create a library of helper classes, but this can be bulky and complex.

To invoke remote services on a server on the Internet, some developers rely on their own application-level network protocols or XML dialects, while other developers may use XML-RPC and SOAP, both discussed soon. Standards such as Web Services for J2ME promise to standardize how clients consume remote services, but these are still emerging.

Because creating the application structure and implementing the network logic are very similar from one application to the next, both tasks are excellent candidates for automation - which is where the J2ME Wireless Connection Wizard for Sun ONE Studio becomes extremely useful.

The Server and Back-End Systems

At the other end of the networked wireless application are the server and back-end systems, which typically are based on the Java 2 Platform, Enterprise Edition (J2EE). The server has the actual published services that are available to the client.

As Figure 4 shows, the structure of the server side application typically consists of a web server running a servlet and JavaServer Pages (JSP) engine, the server-side Java Servlet or JSP that processes incoming service requests and generate responses, supporting application classes, and back-end resources such as Enterprise JavaBeanscomponents (EJB and databases.

Figure 4: Elements of a Typical Wireless Web Server Application

Creating the server side can also be an elaborate and cumbersome process that requires a broad set of skills. As in the case of the client application, creating the server application entails a number of steps that must be repeated for each new application. These include determining the structure of the Servlet, how to read requests and write responses, how to expose services (increasingly, web services), and how to abstract the back-end services. All these repetitive tasks are also excellent candidates for automation by the J2ME Wireless Connection Wizard.

The Wireless Network, Protocols, and Services

On MIDP devices, HTTP is the transport protocol of choice because it is flexible, universally available, and easy to integrate with. As a matter of fact, it is for those reasons that HTTP is the only connection type that the MIDP specification requires, and thus its availability is guaranteed. HTTP is also the transport protocol of choice for popular web-services mechanisms such as XML-RPC and SOAP, as well as the J2ME Wireless Connection Wizard.

In HTTP, network communication is based on a client-server model, where a client makes requests to and consumes responses from a server:

Figure 5: Typical Communication, Based on a Request-Response Model

What varies the most among the various service-request mechanisms such as XML-RPC and SOAP is the way the data is encoded and packaged. XML-RPC, the precursor of SOAP, provides a simpler approach for XML-based remote procedure calls, but SOAP is more in line with the defined standards for web services.

Because remote service invocation is not yet standard on J2ME platforms, to use remote services developers typically rely on their own solutions, or in third-party solutions such as kXML-RPC and kSOAP. And because both XML-RPC and SOAP are XML-based, they require an XML parser in both the client and the server, and the corresponding supporting classes. XML parsers are also not yet standard on J2ME platforms, and developers must embed parsers within their applications. Some XML parsers that can be used in J2ME platforms include:

• kXML1.2 (about 16KB, very stable, good memory management)
• kXML2 (about 9KB, newer, small, less extensively tested but stable, good memory management)
• NanoXML (about 10KB, stable but more memory-intensive)
• TinyXML (about 12KB, stable, memory-intenTinyXMLsive, larger memory footprint)

Embedding a remote service invocation mechanism and an XML parser in each application is an expensive proposition, in the resource-constrained devices that support MIDP. This is one of the reasons the Java Community Process introduced The Web Service for J2ME APIs, now evolving as JSR 172, which defines a standard approach to remote invocation and XML parsing for J2ME platforms. Remote invocation is based on a strict subset of the J2SE Remote Method Invocation (RMI), and the XML parser on a strict subset of the Simple API for XML, version 2 (SAX2). The idea is to have the remote invocation and XML parsing mechanism integrated within the device itself, freeing applications of that responsibility.

Resource constraints also oblige networked wireless applications to be smart about how network traffic between the client and the server is performed. With those constraints in mind, designers of wireless applications typically prefer to exchange binary data rather than XML. The Web Services for J2ME take this approach: Even though the client and server applications use XML, the specification recommends the transfer of binary data.

The J2ME Wireless Connection Wizard adopts this approach as well. To reduce demands on network bandwidth - and save users time and per-byte charges - the Wizard transfers raw data. This capability requires the addition of a framework to each application, but it's very lightweight. At as little as 3 kilobytes, it consumes less memory than XML-based remote service invocation and XML parsers, or protocols you create yourself, leaving more room for your application. Note that this lightweight framework does not introduce any new or proprietary APIs - the generated code is based on the standard MIDP APIs.

Testing

Testing is another important factor to consider when creating networked wireless applications. Without good development and testing tools development becomes more difficult.

The ideal development environment is integrated, allowing you to create, execute, and debug networked wireless applications in a single development environment - another benefit of the J2ME Wireless Connection Wizard, which can be integrated with Sun ONE Studio and the J2ME Wireless Toolkit, as well as with emulators from major device manufacturers.

The J2ME Wireless Connection Wizard

As you've seen, creating a networked wireless application could be a complex, involved process. The J2ME Wireless Connection Wizard simplifies development, by providing you with an alternative to homegrown or third-party network and remote service invocation mechanisms like XML-RPC and SOAP. The Wizard automatically generates the skeleton and support classes for both the MIDP application and the J2EE application; and your client application gives up only 3 kilobytes for a framework that is based on standard MIDP APIs.

The J2ME Wireless Connection Wizard makes two new templates available when you select the New File Wizard from the menu bar in Sun ONE Studio (choose File -> New):

Figure 6: J2ME Wireless Connection Wizard Templates (Click image to enlarge.)

By selecting Skeleton Application you can create simple versions of the client and server applications that you can use as the base for your networked application. Or you can select the Connection Mapping wizard seen in Figure 7, which walks you through a series of steps, allowing you to choose the services that you want to export, and the target client. The wizard then automatically generates the client and server communication components for you.

Figure 7: Wireless Connection Mapping Wizard Templates (Click image to enlarge.)

You can also extend existing applications, by selecting the Mapping node in the Explorer dialog, as in Figure 8a, which brings up the Mapping Wizard in Figure 8b:

Figure 8a: The Explorer

Figure 8b: The Mapping Wizard (Click image to enlarge.)

From there you can select any method to export (or remove unnecessary ones). The wizard will automatically update both the client and server skeletons and components for you.

Remember that this support adds only a small amount of network code to your application, uses HTTP as the transport, and exchanges raw data, keeping the volume of data exchanged to a minimum.

Because the J2ME Wireless Connection Wizard is integrated with Sun ONE Studio and the J2ME Wireless Toolkit, you can easily use their debugging capabilities to test your application:

Figure 9: The J2ME Wireless Connection Wizard Integrated with Sun ONE Studio (Click image to enlarge.)

The Wizard comes with documentation and sample code. For more information please see the J2ME Wireless Connection Wizard page.

Conclusion

This article has covered the typical elements of a networked wireless application. Creating an end-to-end wireless application can be a cumbersome task, and requires a broad set of skills. The J2ME Wireless Connection Wizard for Sun ONE Studio simplifies the creation of networked wireless applications, by automatically generating J2ME and J2EE code for you. You can concentrate on your application logic, and rely on the Wizard to handle the communications aspects of your applications.

Acknowledgments

We want to recognize the help given for this article by James Allen Senior Product Manager, Sun ONE Studio, Mobile Edition, Sun Microsystems, Inc. James is the product manager for the J2ME Wireless Toolkit and Sun ONE Studio, Mobile Edition developer products. He manages the mobile developer tools strategy at Sun Microsystems, Inc.