Web Services package overview
The Web Services optional package enables small devices to consume Web Services. The package takes into account the restrictions on resources and network performance of the devices supporting Java™ ME. The JSR-172: J2ME™ Web Services JAX-RPC package was first introduced in S60 2nd Edition Feature Pack 3. Implementation specific details for Symbian can be found in the J2ME™ Web Services (JSR-172): Implementation Notes.
The JSR-172 Web Services package is a subset of the J2SE API JAX-RPC 1.1.
As the name indicates, JAX-RPC provides the infrastructure to offer and consume
Web Services based on the model of synchronous Remote Procedure Calls using
XML messages. Although multiple types of XML-based RPC protocols are available,
JAX-RPC is mostly oriented to use SOAP as the wire protocol. The transmission
of the request and response can be done in a multitude of network protocols,
HTTP(S) being the most common. JAX-RPC uses many of the design principles
used in Java RMI, including the use of client-side stubs and explicit RemoteExceptions.
Although JAX-RPC contains support for Web Services both as a client and a
server in J2SE, JSR-172 restricts the scope to client-side functionality only.
Finally note that there are several restrictions on the JSR-172 version of JAX-RPC compared to the features supported in the J2SE version:
No support for asynchronous messaging
No support for SOAP messages with attachments
Support only for the literal representation of messages
No support for extensible type mapping
No support for discovery mechanism like UDDI.
Client-side implementations
The client-side programming model in JAX-RPC is based on the use of a proxy or stub that hides the implementation details about the connection to the remote service. The stub also implements a service interface that just contains the signature of the remote procedure including parameters and return type. The stub and service interface can be generated automatically based on the information contained in the service's Web Service Description (WSDL). This tool-oriented design considerably reduces the amount of work the developer needs to invest to connect to any given service. Hence, the developer doesn't need to worry about the underlying messaging protocol, and can only concentrate on the use of the service. The model also allows replacing the implementation if the underlying protocol needs to be modified. This model is depicted in the figure below.
Figure: Proxy/Stub model
Server-side implementations
Notice that the server side may also be implemented using JAX-RPC but this is not a requirement and it could be built using another language or runtime. When the client talks to a server also built using JAX-RPC, it is assured that the client and server will be compatible. Care must be taken to properly test the clients when the back-end service is built using other runtimes, especially considering that Web Services specifications are still evolving and there are differences between different servers and vendors. To ensure a certain level of interoperability with non JAX-RPC services, JSR-172 mandates that the implementation should follow the recommendations contained in WS-I Basic Profile.
Remote calls
One
of the goals of the design of JAX-RPC is to make the calls to the remote service
look like local calls. Nonetheless, it should not be forgotten that Remote
Procedure Calls are not local calls and this brings a set of issues to the
developer. This is made explicit in the design of JAX-RPC by tagging the generated
service interface with the java.rmi.Remote interface
and marking every operation as throwing RemoteException.
This makes it explicit to the caller that it is not a local call and issues
such as bad network connectivity and latency should be taken into account.
The JSR-172 specification explicitly allows Remote Procedure Calls using different protocols depending on the characteristics of the device and underlying network. For example, an alternative to SOAP over HTTP is to use other kind of encoding that may be more efficient, like binary encoding, over the cellular network or even over SMS. This should be transparent to the application developers since they only deal with the service interface and stub. Nokia devices, however, will only support RPC calls, encoding them as SOAP messages and using HTTP/WAP as the transport protocol.