Enterprise J2ME Developing Mobile Java Applications [Electronic resources] نسخه متنی

17.3 The JAX-RPC API

The J2ME Web Services Optional Package also defines a strict subset of the JAX-RPC v1.0 API that runs on both CLDC and CDC devices. JAX-RPC allows Java developers to use their familiar RMI-like APIs to invoke remote SOAP services without caring about the underlying transport or marshaling mechanisms. This is a Java-centric approach in which the developer never sees SOAP messages. All remote procedure calls are simply mapped to local calls to stub objects. Figure 17.1 illustrates the architecture of the JAX-RPC package for J2ME.

17.3.1 Features

The J2ME Web Services Optional Package is required to implement the following JAX-RPC v1.0 features.

Support for SOAP v1.2.

HTTP Basic Authentication and session support in the underlying message transport. HTTPS support is optional.

Simple SOAP type mappings defined in Table 17.2. XML structs and complex composite types are supported. This allows passing simple JavaBean objects as RPC parameters and return values. However, extensible type mapping is not supported.

Mapping SOAP (or WSDL) Fault messages to the appropriate Java exceptions on the client side.

Both document and literal styles of SOAP messages.

Generating J2ME client stubs for remote services from their WSDL documents.

Note

The xsd:float and xsd:double types are mapped to Strings on handsets that do not support float and double data types (i.e. CLDC v1.0 devices).

Serverside APIs and SOAP attachments are not supported.

17.3.2 The API

Table 17.3 lists user APIs defined in the J2ME Web Services Optional Package. All of them are J2SE/J2EE (especially JAX-RPC) classes that are added back to J2ME. The RMI classes are also available from the CDC RMI Optional Package.

Now, let's have a look at exactly how we use the J2ME Web Services Optional Package.

17.3.3 A User Scenario

To build a Web Services client using the Optional Package, we need to go through several steps.

Fetch the WSDL document from the service provider and generate a javax.xml.rpc.Stub class for each service. The stub class generator is a desktop utility. For example, we can generate a GoogleSearchStub class using the WSDL file fetched from the Google Web site (see Section 16.2.2 for more details).

Put the generated class into the project class path and instantiate an instance of the Stub when necessary in the application code.

GoogleSearchStub stub = new GoogleSearchStub ();
stub._setProperty(
Stub.ENDPOINT_ADDRESS_PROPERTY,
"http://api.google.com/search/beta2");
// Set more properties if authentication is needed

Use the Stub object to invoke remote services and get the return value as a Java object.

String key = "Google license key";
String query = "badspell";
String suggestion = stub.doSpellingSuggestion(key, query);
// Go on and make use of the suggested word

When the development work is done, we need to bundle the generated Stub classes with the application before deploying them to devices.

Now, we have seen how to use J2ME Web Services Optional Package from the user point of view. The generated Stub class shields the underlying complexity from us. Since the Stub interface is standardized, we can change the Optional Package vendors without changing the application code. JSR 172 does not stop here. It made further efforts to standardize the operation of the Stub by defining standard Service Provider Interfaces (SPIs).