As pervasive and ubiquitous as Web services may become in the IT landscape, the universal approach of providing and processing XML type payloads in the same fashion for every possible system will not scale, a statement that proves more than evident in the area of mobile applications. Up next, we will analyze how Java ME(Java Micro Edition) -- Java's answer to mobile development -- tackles the issue of Web services.
Mobile clients form that special group of devices such as personal digital assistants(PDA's) and mobile phones, that even though they serve as on-the-go access points to vital data, they are hindered in areas such as memory, display and high latency networks. A quick glance at earlier technologies targeting these same devices should provide enough evidence as to why Web services require special consideration in this space.
HTML, which to this day still serves to markup pretty much every Internet page, does not have the optimal characteristics to be used by most mobile devices. In its place, markup languages such as WML and HDML have been created to confront many issues facing PDA's and mobile phones, so this should be an indicator that what works for most scenarios does not necessarily fit into the mobile world.
Java ME Web services or JSR-172 tackles two issues in the mobile applications realm: Accessing SOAP/XML Web services from Java-enabled mobile devices and processing the XML messages that compose such service requests. In this sense, JSR-172 is concentrated exclusively on client side consumption of Web services, not on the possibility of publishing services from a mobile device.
If you have previous experience tapping Web services from Java clients, then you should be fairly comfortable working with Java ME Web services, since both XML processing and Web services access are based on the greater superset API's JAXP and JAX-RPC, which are use...
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
d for the same tasks in full-fledged Java environments.
What is unique about these subset API's for JAXP and JAX-RPC is that their implementation target size is around 35Kb, which is common for a Connected Limited Device Configuration (CLDC) like the one used in Java ME. While the JAX-RPC implementation for Java ME and standard Java are approximately the same kilobytes in size, the underlying classes onto which JAXP plugs into are very different since access to the full suite of XML processing capabilities available in standard Java is not readily available for mobile applications due to platform size restrictions.
Shifting our focus to functionality, in regards to Java ME's JAX-RPC vs. JAX-RPC standard Java implementation, the former lacks support for the following features which are present in the latter :
- Does not support service endpoints, which is another name for saying a device cannot be a web service producer.
- Does not offer service discovery (UDDI).
- Does not support SOAP Messages with Attachments.
- Does not support SOAP message handlers.
And as hinted earlier, what differentiates Java ME's JAXP implementation from its standard Java parent for processing XML is the following:
- Does not support the document object model (DOM), as its considered to spacious.
- Does not support extensible style-sheet language transformations (XSLT)
We will now take a look at Java ME's JAX-RPC API, and see how its used to call a Web service available on the wider Internet. Keep in mind this is only part of a Java ME application built to conform to the Mobile Information Device Profile (MIDP). Like any other software application, a Java ME application has to incorporate business logic classes, a user interface and application state management among other things. Addressing such issues would go beyond the scope of this article since they are more related to Java ME than Web services, so you are advised to consult Java ME's site or the Sun Wireless Toolkit , which is an environment for developing Java ME applications.
The first step in creating a Java ME Web service is to generate a Java stub from the service provider via its WSDL contract, this step is similar to a standard Java Web service that uses a WSDL contract to obtain a language specific interface on which to tap a particular servic. However, in Java ME's case the stub needs to be built around a JSR-172 implementation, for which the Sun Wireless Toolkit provides such a tool.
Once you have this stub, a concrete class needs to be built around it, listing 1.1 illustrates what this class would look like when implementing a Java ME Web service for a weather application.
Notice that we use a series classes which form part of Java ME's core and, with the exception of , the bulk of JAX-RPC's usage is tucked away in the stub created from the Web services WSDL contract. Be aware that all these tasks take place at a developer workstation, from obtaining the WSDL contract to packaging the application. The actual involvement of a mobile device should be left only for final deployment, once the mobile Web service has been thoroughly debugged and tested on a workstation emulator.
With this we conclude our overview of Java ME's capabilities for tapping Web services used throughout many organizations. With it, you are now in a capacity of providing your users the same web services data, whether they are next to their PC or on the road with access to only a mobile phone or PDA.
About the author
Daniel Rubio is an independent technology consultant specializing in enterprise and Web-based software, He blogs regularly on these and other software areas at http://www.webforefront.com/
