Extending Web Services to the real world: using SOAP to access a J2EE-enabled mobile device

Extending Web Services to the real world: using SOAP to access a J2EE-enabled mobile device – Mobile Web Services

Ashwin Rao

This is the first in a series of articles that will explore the realm of Web services, the challenges that lie ahead, and advancements that enable extending Web services to the real world.

Applications for real-world scenarios have significant dependencies on development time and ROI and must be robust, platform neutral, and performance sensitive. Most important, these scenarios need to be highly flexible to changes in requirements and applicability. Web services are an effective way to balance all these aspects of real-world applications and provide a rich and extensible infrastructure for advanced topics such as J2ME interaction, portals, business on the Web, choreography, and collaboration. This article assumes that you have a basic understanding of Web services, SOAP, and the J2ME platform.

Why Web Services Make Sense for Devices

As we know, Web services can be defined as software components that are reusable, distributed, and loosely coupled, and can encapsulate functionality and be accessed programmatically using standard Internet protocols.

The growth in e-business has led to an increased demand for instant access to real-time information and content. Users are now looking into accessing business applications not only via PCs but on mobile devices as well. Web browsers fit like a glove for over-the-wire Internet desktop computing, but were not appropriate for a wireless world that requires interactive and mobile access. Also, using browser technology on mobile devices poses challenges based on limitations in data input, client GUIs, and latency in wireless networks. And, users on-the-go find it highly cumbersome to use browse and search capabilities.

Consider a scenario in which a user would like to access real-time stock quotes. In Figure 1, the user accesses a Stock Portfolio Management Application over the wire on the back end from a Web page in a browser to look up the value of the stock.

[FIGURE 1 OMITTED]

If we extend this scenario to a user who is constantly on the move and would like to interactively access the same information in real time, we are presented with a situation in which a mobile device such as a PDA would provide such a convenience. In Figure 2, the user interactively queries a client application on a PDA that contains a list of stocks in a portfolio. The user can then select a stock by clicking on a link that forwards a request to a Web service over the air using Web services technology and standard Internet protocols. The Web services accessed at the back end then interact with the Stock Portfolio Management Application.

[FIGURE 2 OMITTED]

This ability to interactively access information anytime, from anywhere, and any-how has led to the proliferation of Web-enabled mobile clients with small form factors. More important, these clients would be ideally suited to actively participate in e-commerce transactions on the Web. This model also exposes existing legacy application services to cross-platform clients, thus enabling clients across multiple ranges of platforms to communicate with each other using an XML-based communication protocol. Such clients could perhaps be developed in different languages, OS, and hardware environments, and would be able to communicate with back-end services, once again developed in different languages, OS, and hardware environments.

Thus, the value of Web services in a mobile environment lies in the fact that they can deliver pertinent and timely information to the mobile user and provide a reliable, reconnectable infrastructure that works across platforms and architectures. This article will use Simple Object Access Protocol (SOAP) to access a Web service.

The Architecture of J2ME Devices

The popularity of mobile devices provides a far greater opportunity to take advantage of the power of Java, with its inherent benefits such as networking and security. However, in this opportunity, there existed a quandary. The multitude of devices, with different form factors–essentially, different power consumption requirements, processing requirements, display requirements, I/O requirements–needs to be addressed by the architectural model.

Rather than adopt the least common denominator approach, the Java community developed an architecture consisting of a combination of elements that are optimized for the memory, processing power, and I/O capabilities of a related category of devices. The elements are comprised of Configurations, Profiles, and Optional Packages. This architecture is referred to as the Java 2, Micro Edition (J2ME).

A configuration is the lowest layer sitting on top of the device OS, and consists of a Java Virtual Machine (JVM) and a minimum set of class libraries that provides for the basic functionality of a related category of devices. Currently, two configurations have been defined based on the form factor of mobile devices: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC).

CLDC consists of a scaled-down JVM called Kilo Virtual Machine (KVM) and is targeted at devices with slower processing power provided by 16- to 32-bit processors. CLDC is the smaller of the two configurations and is optimized for devices with low memory, in the range of 128KB to 512KB, and with a typically intermittent network connection with a small bandwidth. CDC consists of a full-fledged JVM and is targeted at devices with faster processing power with 32-bit processors. It is optimized for devices with more memory, typically 2MB, and with larger network bandwidth.

Profiles are higher-level APIs that are associated with Configurations and are layered on top of them. These APIs address the application life cycle, user interface, and device specification functionality for a related category of devices. Based on device form factors, a number of profiles, such as the Mobile Information Device Profile, (MIDP), Foundation Profile, Personal Profile and Personal Basis Profile, have been defined and are associated with the appropriate Configurations.

Layered on top of the profiles are Optional Packages. These packages are device specific and may be proprietary in nature. They consist of APIs that cater to specific market segment technologies, for instance SMS messaging APIs applicable to mobile phones, and also any emerging technology associated with devices.

SOAP Overview

According to the SOAP 1.1 specification, SOAP is a lightweight protocol that allows communication between objects of any kind, on any platform, and developed in any programming language. It is also a format for sending messages via the Internet, is simple and extensible, and allows you to get around firewalls. SOAP is developed as a W3C standard.

You can send an XML request to a SOAP server over HTTP and receive the response back in XML format. Since HTTP is the accepted protocol in the Internet world, and as all Web servers understand HTTP requests, it is an ideal communication mode to use to enable the integration of various systems. Also, XML is emerging as the standard to exchange information over different systems. SOAP’s use of XML to send and receive messages thus enables any system on any platform to read and process the messages.

Web Services Description Language (WSDL) is a standard mechanism that can define the SOAP message used to access the Web services, the protocols, and the Internet locations where these Web services can be accessed. A WSDL document describes what functionality a Web service offers, how it communicates, and where to find it. A WSDL document can be compiled to generate a SOAP client proxy that can call the Web service.

A SOAP client will initiate the process by making a SOAP request. In this process, the client will refer to the WSDL file that resides in the SOAP server to form a valid SOAP request, as shown in Figures 1 and 2. The client will then send the request to the SOAP server using HTTP.

SOAP 1.1 Implementations on the J2ME Platform

At this juncture it is important to look at a few compact, fast, and portable SOAP 1.1 implementations for J2ME. The key features of such implementations must include an XML parser, XML writing support, and a very small footprint SOAP API. Wingfoot SOAP, available at www.wingfoot.com, is a lightweight client implementation of SOAP that is specifically targeted at the J2ME CDC and CLDC platform. However, it can also be used in J2SE and J2EE environments. In this article, we will concentrate on the kXML and kSOAP open-source projects available at www.enhydra.org.

kXML provides a small-footprint XML pull parser and writer suitable for all Java platforms and J2ME CDC and CLDC, making it especially suitable for applets, Java applications, or Web services running on mobile devices like PDAs or MIDP-enabled mobile phones. It also has XML writing support, optional kDOM, and optional WAP support (WBXML/WML). kSOAP is a very small footprint SOAP API suitable for the J2ME platform and based on kXML. Figure 3 depicts the interaction between a kSOAP MIDP client applet–a MIDlet deployed on J2ME kXML and kSOAP stack–and a WSDL for the Web service available on a SOAP server infrastructure.

[FIGURE 3 OMITTED]

JSR 172: J2ME Web Services Specification

A step towards enabling developers to create and display Web services on J2ME devices has recently surfaced in the form of a Java Community Process (JCP) specification called JSR 172, designed to provide standard APIs to enable Web services for the two J2ME Optional Packages, CDC and CLDC. Content is normally delivered to the J2ME client as XML in a SOAP message, and an application on the J2ME device is used to interpret and process the message. This specification will enable service providers, device manufacturers, and content creators to realize significant ROI by rapidly and economically developing and deploying new applications, services and content to existing and new customers. This JSR extends Web services standards, including XML, SOAP, and communication with registries like UDDI to connect mobile and consumer devices. It also provides a programming model for interaction between a J2ME client and Web services.

As part of this initiative, infrastructure such as APIs for parsing structured XML data, APIs and conventions for enabling SOAP communication from J2ME, run-time APIs to support stubs generated according to the mapping, supporting XML as a transport and encoding component, and an investigation of a suitable and compact encoding mechanism for SOAP messages are being developed to enable J2ME Web services per JSR 172. (For more information on the proceedings of this JSR, please refer to http://jcp.org /en/jsr/detail?id=172.)

Listing 1 is the source code for the StockQuoteDemo MIDlet, a SOAP client developed using kSOAP. This MIDlet is a client application that can be installed on a J2ME device to provide access to the Stock Quote service hosted at www.xmeth ods.com, to retrieve and display real-time stock quotes. The link to the Web service is www.xmethods.com/ve2/ViewListing.po;j sessionid=xHaCLLIDxdHkI-R0WtWfcnL v(QhxieSRM)?serviceid=. The Endpoint URL is http://66.28.98.121:9090/soap. The link to the WSDL file is http://services. xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl.

Listing 1: StockQuoteDemo MIDlet

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

import java.io.*;

import javax.microedition.io.*;

import org.ksoap.*;

import org.ksoap.http.*;

public class StockQuoteDemo extends MIDlet implements

CommandListener {

Form mainForm = new Form (“StockQuotes”);

TextField symbolField = new TextField (“Symbol”, “SUNW”, 5,

TextField.ANY);

StringItem resultItem = new StringItem (“”, “”);

Command getCommand = new Command (“Get”, Command.SCREEN, 1);

public StockQuoteDemo () {

mainForm.append (symbolField);

mainForm.append (resultItem);

mainForm.addCommand (getCommand);

mainForm.setCommandListener (this);

}

public void startApp () {

Display.getDisplay (this).setCurrent (mainForm);

}

public void pauseApp () {

}

public void destroyApp (boolean unconditional) {

}

public void commandAction (Command c, Displayable d) {

try {

// Build request string

String symbol = symbolField.getString ();

resultItem.setLabel (symbol);

// Create a SoapObject by specifying the URN and the

method name

// of the SOAP RPC Web Service.

SoapObject rpc = new SoapObject

(“urn:xmethods-delayed-quotes”, “getQuote”);

// The addProperty method allows you to specify parameters

to for

// the method used.

rpc.addProperty (“symbol”, symbol);

// The HttpTransport class can be used to make the actual

call.

// Its constructor accepts the Web Service endpoint

as well as

// the method to be called.

resultItem.setText (“”+new HttpTransport

(“http://services.xmethods.net/soap”,

“urn:xmethods-delayed-quotes#getQuote”).call (rpc));

}

catch (Exception e) {

e.printStackTrace ();

resultItem.setLabel (“Error:”);

resultItem.setText (e.toString ());

}

}

public static void main (String [] argv) {

new StockQuoteDemo ().startApp ();

}

}

As you would do with any J2ME MIDlet, install this file in the src directory of a new J2ME Wireless Toolkit project, and then install ksoap-midp in the lib directory. (For information on downloading and using the J2ME Wireless Toolkit, please refer to http://java. sun.com/j me.)

After deploying the StockQuoteDemo Web Service client in the J2ME Wireless Toolkit environment, you can build and run the MIDlet by launching it from the KToolbar (see Figure 4).

[FIGURE 4 OMITTED]

A request for a stock quote is then made from the client device, after which the Web service retrieves and displays the latest market price of the stock (see Figure 5).

[FIGURE 5 OMITTED]

J2ME Web Services Development Tools Available

There are a number of free J2ME development tools available today, such as the IBM WebSphere Micro Environment; Sun ONE Studio (formerly Forte for Java); Borland JBuilder MobileSet; Sun’s J2ME Wireless Toolkit, which optionally plugs into Sun ONE Studio and Borland IDEs; MIDP reference, MIDP for PalmOS and CLDC SDK; Motorola/ Metrowerks J2ME tools for CodeWarrior; RIM BlackBerry IDE; and Zucotto WHITE-board SDK, to name a few. The J2ME Web service implementations used in conjunction with these tools could be based on the SOAP 1.1 implementations such as kSOAP or Wingfoot SOAP, discussed earlier.

Conclusion

This article showed you how a Web service is accessed from a SOAP client running on a J2ME mobile device. In the next article, we’ll look at accessing a Web service through a centralized portal, using the provisioning paradigm to manage access based on a user and device profile, and usage based on billing and metering.

Author Bio

Ash Parikh has over 10 years of computer and IT experience, including object-oriented analysis and design, distributed architecture, middleware architecture, and software design and development. He has served in many architect-level roles with technology leaders such as Oracle Corporation, BEA Systems, Sun Microsystems, and PeopleSoft. Ash is the president of the Bay Area Chapter of the Worldwide Institute of Software Architects, an initiative close to his heart, through which he evangelizes various software architecture paradigms. He is a contributing author of Oracle9i AS Building J2EE Applications (Osborne Press).

ASHISHPA@HOTMAIL.COM

Ashwin Rao, the vice president of the Bay Area Chapter of the Worldwide Institute of Software Architects, has over six years of experience in software development, having begun his career writing defense industry software for real-time, embedded systems. His current focus is J2EE architecture and development and Web services. He has authored a number of articles on Web services.

ARAO@MAIL.COM

COPYRIGHT 2003 Sys-Con Publications, Inc.

COPYRIGHT 2003 Gale Group