Browse DevX
Sign up for e-mail newsletters from DevX


Turn Your J2ME Mobile Devices into Web Service Clients : Page 2

If Web services are expanding within your enterprise, it might be time for you to look at all those mobile devices as potential clients of your Web services. Learn how to use the J2ME Web Service APIs to extend the enterprise to include J2ME devices with a simple example application.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

The Example Application
Imagine you work for a large life insurance company. Insurance agents are meeting potential clients all the time. Using their J2ME mobile phones, these agents want to be able to gather some simple personal facts about their clients (name, age, whether the client smokes, etc.). They then want to send these facts off to the corporate office in order to get policy plans and quotes they can immediately share with their clients (see Figure 1). The example application in this article provides a Web service that serves up policy plans and a J2ME MIDlet that your insurance agents can use to access the Web service.

Figure 1. Tutorial Application User Interface: The life insurance agent enters data about a client into a J2ME MIDlet form (screen1), requests policy plans and quotes from the corporate Web service, and then shares the policy options and information with the client (screens 2 and 3).

Developing the Example Application
The formula for developing this application can be divided into two parts: developing the Web service and developing the J2ME MIDlet that accesses that Web service. The basic steps to create a Web service and deploy it to the Tomcat server are as follows:

  • Write the Web service interface class.
  • Write the Web service implementation class.
  • Write the associated descriptor files (all XML files).
  • Compile the service and generate Web services stubs/ties and WSDL file using tools provided with the Java Web Services Developer Pack.
  • Deploy the web service to the Tomcat server.
With the Web service ready to provide insurance information deployed and running, the basic steps to creating the J2ME Web service client are:
  • Use the generated WSDL file and the tools built into the Wireless Toolkit to generate the stubs and supporting code used by the MIDlet to access the Web service.
  • Code the MIDlet and associated classes using JAX-RPC to invoke the Web service and JAXP to process the SOAP message.
  • Build and test the MIDlet on the Wireless Toolkit emulator(s).
The Web Service
Those familiar with RMI, EJB, or other forms of distributed application development probably recognize the first two steps in developing a Web service. The interface class declares the methods on the insurance policy Web service that clients (in this case J2ME clients) can invoke. The code for the Web service is located in the server subdirectory of the InsuranceQuote folder you downloaded and set up earlier. Take a look at the com.roaminginsurer.QuoteService code in Listing 1. There's not a lot to it. It defines the protocol or contract by which the client and Web service communicate. In this case, the client calls the service, the getQuote method, with a client's name, age, marital status, number of children, salary, and smoking status. The Web service returns a string. The string is actually an XML document containing recommended life insurance policy information.

The implementation of the Web service com.roaminginsurer.QuoteImpl can be found in Listing 2. This Web service is constructed on JAX-RPC. Note that the interface extends java.rmi.Remote and the service method throws java.rmi.RemoteException. These are indications that Web services are very RMI like. The implementation class implements the javax.xml.rpc.server.ServiceLifecycle interface along with the Quote interface. By implementing the ServiceLifecycle methods, the Tomcat Web container can manage the Web service through the init and destroy methods.

Inside the getQuote method, the XML document response is created. The method creates a DOM object tree. The Document Object Model (DOM) is an API for working with XML documents and the API is used here to create a tree of policy objects. Inside of the init method, a document factory is created.

this.context = (ServletEndpointContext) context; factory = DocumentBuilderFactory.newInstance(); try { builder = factory.newDocumentBuilder(); } catch (ParserConfigurationException e) { builder = null; }

Then, in the getQuote method, elements representing policies are attached to the document. Each element has attributes that contain the policy coverage amount and annual rate. Below is the code that creates the "Gold" policy.

Element gold = document.createElement("Gold"); gold.setAttribute("coverage",coverage + ""); gold.setAttribute("cost",rate + ""); root.appendChild(gold);

The XML document must finally be converted to a string for transport to the client. This is accomplished in the toString method.

Compiling the Web Service
Three other descriptor files are required for completing the Web service and deploying it to Tomcat:

  • web.xml: The standard deployment descriptor describes how to deploy the components (in this case, the Web service component).
  • config.xml: An XML configuration file that describes the Web service.
  • jaxrpc-ri.xml: An XML configuration file that describes how to deploy the Web service.
Tools in Sun's Java Web Services Developer Pack 1.5 use these last two files. When compiling the Web service, the interface and implementation classes must be compiled (good old javac), but another process is also required. The wscompile tool, using information from the config.xml, generates the stubs, ties, and the Web Services Description Language (WSDL) file. Stubs and ties are the low-level classes that the server needs to communicate with a client. More information on the WSDL file will be provided later.

The download code contain Ant scripts (build.xml) for compiling, building, and deploying the Web service. In the server directory, a build.properties file contains the root directory location for Tomcat, the project directory, etc. Before using the ant script, edit the properties in the file listed below to match your environment.

tomcat-root=C:/tomcat50-jwsdp jaxrpc-root=${tomcat-root}/jaxrpc j2ee-root=${tomcat-root}/jwsdp-shared project-root=C:/WTK22/apps/InsuranceQuote/server

Before compiling the service, take a look at the call to the wscompile tool in the ant script.

<wscompile server="true" keep="true" features="wsi,documentliteral" xPrintStackTrace="true" verbose="true" base="${classes.dir}" model="${web.dir}/model.gz" classpath="${web.dir}" config="${src.dir}/config.xml"> <classpath> <path refid="compile.classpath"/> </classpath> </wscompile>

A very important argument to the wscompile task is the list of features to be enabled; namely wsi and documentliteral. As the JAX-RPC API for J2ME only supports the literal representation of a SOAP message (no XML encoding), these features will allow a simple J2ME client to communicate with the service.

To compile the Web service, simply call on Ant with the following directive:

ant compile

If all goes well, you should see the generated stubs and ties in a subdirectory of the server directory called generated and the compiled code in the WEB-INF subdirectory. The WSDL file should also be available in the WEB-INF/classes subdirectory.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date