SOA Without SOAP: The Java ME Perspective

Web services accessed via HTTP are often at the heart of a service-oriented architecture (SOA). As explained in Service-Oriented Architecture and Java ME, this use of HTTP as a generic data transport is a key reason that Java ME applications can use web services to create SOA-based distributed applications. But HTTP by itself does not a web service make, otherwise every site on the Web would be a provider of web services. A web service is really just a contract between a service provider and its customers where everyone agrees to use HTTP as the transport. But specifying HTTP as the transport isn't enough-the parties to the contract must agree on how they use HTTP to exchange their data.

The best-known protocol for accessing web services is known as the Simple Object Access Protocol, or SOAP for short. Initially popularized by Microsoft, SOAP eventually became the World Wide Web Consortium (W3C) standard for XML-based data exchange. (It's ironic to note that another key technology for service-based client applications, AJAX's XMLHttpRequest object, also came from Microsoft. It, too, has been adopted by the W3C.) Because it uses XML, SOAP data transfer is not tied to a specific programming language or operating system. It makes SOAP-based web services open and accessible to all.

SOAP's dependence on XML is also a disadvantage, however. While it's true that the Web Services APIs for Java ME (WSA) support a subset of the SOAP 1.1 standard and a simple API for parsing XML, WSA support is far from widespread. (See Understanding the Web Services Subset API for Java ME for an introduction to WSA.) The pragmatic Java ME developer understands this, which is why alternative approaches must often be explored. And even if SOAP was universally supported on Java ME platforms, some developers would look for different solutions because of the extra overhead involved in using SOAP. (If SOAP is required and WSA is not available, the kSOAP 2 open source SOAP library is an option to consider.)

The first thing you must consider with a "no SOAP" approach is whether or not the required services are accessible via other protocols. If SOAP is the only supported option, you'll need to use a server-based proxy to act on the device's behalf if you're truly intent on avoiding SOAP usage. (Using a proxy may make sense even if non-SOAP services are supported-see below.)

The ideal web service for our purposes is one that uses a simple REST-like interface. (REST stands for Representational State Transfer. See Building Web Services the REST Way for a good summary of the fundamental REST concepts.) In other words, services are invoked using the HTTP GET and POST methods, with any input data passed in using query parameters (for GET requests) or the request body (for POST requests). Amazon's E-Commerce Service (ECS), for example, offers a REST-like interface in addition to a SOAP interface that is very easy to use from any Java ME platform. If no REST-like interface is available, a proxy will be required.

Note that encryption is sometimes an issue in these instances, as not all platforms support HTTPS-based communication. If data security is a concern, use code from the Bouncy Castle Crytographic APIs-an open source cryptography project-to encrypt the communication, as described in Data Encryption for J2ME Profiles. Such a solution almost certainly entails the use of a proxy, however.

REST-like interfaces have a lot of flexibility in terms of the formats used for data exchange. As already mentioned, most request data can be passed either as part of the URL (using query parameters) or in the request body. Responses come back via HTTP status codes and/or the response body. There is no single perfect format for data exchange-it really depends on the data requirements. General REST-like interfaces usually return data as XML, although the XML is often much simpler than what a SOAP interface would return. This is what the Amazon ECS does, for example. An XML parser then maps the data into the appropriate Java data structures. A memory-efficient parser like kXML 2 is an obvious choice if there is no built-in parser available.

If end-to-end Java is used-if, in other words, the web service endpoint is itself written in Java-then serialized data structures are often the most efficient way to pass information between the client and the server. This method uses the simple, custom serialization technique described in Object Serialization in CLDC-based Profiles. Data structures are converted into packed binary forms for transport in order to minimize the amount of data transferred. Serialization and deserialization is relatively quick and can be done quite efficiently if some care is taken in defining the interfaces. (As a bonus, these data structures can often be stored unchanged directly into a record store or other persistent store.) This approach is not without its drawbacks, of course, especially when it comes to new or upgraded data formats. Careful coding is required to ensure that client applications fail gracefully (or not at all) with new data formats.

Of course, there are times when the server-based proxy approach is the only one that makes sense. A proxy can define its own service interface for faster request-response cycles. A proxy can also act as a multiplexer/demultiplexer by combining many lower-level operations into a single, higher-level transaction. But a proxy has its disadvantages, too, by adding another point of failure to the system and yet another server to maintain. Proxy scalability is also a concern if a client application is widely deployed.

There's no right or wrong answer on how web services are invoked in a service-oriented architecture. Java ME developers should carefully consider whether a SOAP-based client implementation is efficient and effective enough for use on the devices they're targeting. Applications targeted at CDC-based set-top boxes with high-speed Internet connections can do much more than applications for CLDC-based mobile phones, and the use of web services should be adjusted accordingly.

Eric Giguere 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 synclastic.com. Eric works as a software developer for Sybase iAnywhere.