Service-Oriented Architecture and Java ME

Many mobile applications today require the use of one or more server-side applications. These applications cannot function-or can only partially function-without the aid of one or more external applications. These mobile applications effectively become distributed applications.

Java ME developers build distributed applications all the time using custom protocols tunneled over HTTP. When end-to-end Java is possible (the endpoints of the communication path are both Java applications), it's common for the applications to exchange data in the form of custom serialized Java objects. (See Object Serialization in CLDC-Based Profiles for more information.)

A common problem with distributed computing architectures is the tight coupling between the different parts of the distributed application. The approach just mentioned of using custom object serialization for data transfer suffers from this problem: While convenient and simple, connections are restricted to the specific servers that understand the protocol, and any changes to that protocol require reconfiguration of those servers. The reality, though, is that when writing code for very constrained programming environments, there's often no other choice for creating such a tight coupling of client and server. But as constraints to memory and processor power are removed, the switch to a more flexible service-oriented architecture becomes possible.

The term service-oriented architecture, SOA for short, refers to a style of distributed computing that requires a loose coupling between the different components of an application. In the SOA model, services are provided in a platform-independent fashion and data is exchanged using portable and extensible formats. There are also ways to discover and manage the different services.

Applications that use the services exposed under a service-oriented architecture are independent of how those services are implemented, much the same way that Java interfaces are used within an application to decouple abstractions from their implementation. The loose coupling allows (and encourages) the use of services from different providers, offering the application developer more flexibility in building applications by combining services in new and interesting ways. Already, a marketplace of sorts is developing among service providers, with companies like Amazon providing pay-as-you-go services for storing and queuing data.

Web services are commonly used as the basis for service-oriented architectures, taking advantage of the near-universal support for HTTP to create services accessible from almost any device, wired or wireless, connected to the Internet. An abstraction layer on top of HTTP, typically REST (representational state transfer) or SOAP (simple object access protocol), is used to invoke services and to exchange data between client and server.

Java ME is particularly well-suited for client application development in a service-oriented architecture, as device constraints are still very limiting when compared to desktop environments. This makes it critical to offload expensive operations to external systems-hence the need to communicate with those systems via web services.

As it happens, HTTP support is present on almost all Java ME environments. The Connected Limited Device Configuration (CLDC) includes it as part of the Mobile Information Device Profile (MIDP) and the Information Module Profile (IMP), and the Connected Device Configuration (CDC) includes it as a core configuration feature.

HTTP support is only the first step. An XML parser is typically required to parse data returned by web service invocations. Unlike HTTP, Java ME support for XML is not universal. But parsers are available for inclusion on all Java ME environments, either via the J2ME Web Services Specification optional package or via open source projects like kXML.

REST-based services are loosely-defined and require custom coding to marshal data (often embedded within the URL of the service invocation), invoke a service (a simple HTTP call), and unmarshal the response (often an XML document).

SOAP-based services have more complicated semantics and require additional support beyond HTTP communication and XML parsing. The J2ME Web Services Specification extends its XML support to include a subset of the Java API for XML-based remote procedure invocation (JAX-RPC). SOAP 1.1 services can be invoked using this JAX-RPC subset. See Understanding the Web Services Subset API for Java ME for a comprehensive look at JAX-RPC on Java ME.

On devices that do not include the J2ME Web Services Specification, the kSOAP open source package offers similar functionality.

Armed with these tools, the Java ME developer is able to extend the reach of SOA-based applications to mobile devices.

Eric Giguere is an author and software developer who has written extensively about Java ME. Be sure to read his Java ME blog for more tips and information. You can learn more about Eric at EricGiguere.com.