Skip to main content

Taking Service-Oriented Architectures Mobile, Part 1: Thinking Mobile

June 21, 2005


First Approach: Servlets
Using a Service-Oriented
Architecture Approach
Building a Simple Mobile
Messaging Application
On the Device
Under the Hood
Factories and Connections
The Mobile Gateway

In recent times, Service Oriented Architectures (SOA) have become synonymous with web services, in which large enterprise systems communicate business-critical information. However, in this series of articles, we look at SOA as a wider design principle that can be applied to any distributed object-based system--casting the net wider to include devices that sit at the edge of the network, both fixed and mobile.

In this first article, we describe how we have taken SOA onto mobile devices and show how to implement a simple messaging application using mobile SOA design principles and point to some of the security implications and how to handle them.


Web services are just one of many possible implementation of the wider SOA model. Other more mature technologies, such as RPC, CORBA, RMI and Jini have also been used as highly efficient "connection" technologies on which to implement large-scale, SOA-based systems, and in fact many developers working with those technologies argue that theirs was the original platform for service-oriented architecture.

But instead of climbing into that particular bear pit--we aren't going to try to argue which technology is preferable--we will be concentrating on some of the design patterns applicable to SOA and how these can be applied to Java devices both on the move and for fixed clients that need to access business services.


Java mobile technology is now mature and is available on millions of cellular phones around the globe. This profusion of Java on the phone was initially led by a few far-sighted members of the Java team at Sun, and then by groups of like-minded people within the handset and device manufactures around the world who took up the job of getting small (sometimes tiny) devices to run a subset of the Java technologies available on desktop and server machines.

These efforts were combined and coordinated under the Java Community Process (JCP) with various JSRs. Most importantly, CLDC and MIDP standardization, which we discuss later, has meant that a "base" level of Java capability can be assumed for every Java phone on the market and that it is possible to write and test code to this standard.

Most, if not all, Java phones now support at least a basic J2ME implementation of the Mobile Information Device Profile (MIDP 1.0) and the Connected Limited Device Configuration (CLDC 1.0).

The combination of CLDC underlying the MIDP libraries provides sufficient functionality to write interactive clients that can connect to back-end business systems. These interactive clients take the form of MIDlets (named after the applet model). As an applet runs in a browser, a MIDlet runs on a mobile phone or device.

Hey--why not just use WAP?

Most phones also have web browsers and provide interactive content via WAP, so why not just use that?

Well, like most things, it boils down to "horses for courses." Just as in the server side of Java, in certain situations, JRMP is much more useful and effective than simple systems based on the Hyper Text Transfer Protocol (HTTP), with devices, sometimes the WAP protocol can prove limiting and inappropriate. So while accessing the internet via WAP could be very effective, this technology can be limiting when compared with the array of abilities available through device Java.

In the next section, we're going to explain how we implemented a SOA approach to the connected-device model with the intention of making both building and maintaining connected J2ME applications much easier.

First Approach: Servlets

Mobile Java comes equipped with the basic packages to make allow systems to connect to remote systems via HTTP, but generally these devices have not been considered powerful enough to support Java Remote Method Invocation (RMI).

In the current standards, RMI is ruled out of our set of possible technologies, so the first approach most developers take when starting to build a mobile business application is to connect via a Java servlet, as shown in Figure 1 below.

Figure 1
Figure 1. Connecting via a servlet

While this approach is a relatively easy way to start implementing a simple prototype or demo system, it quickly becomes difficult to maintain and scales poorly, because each time you need to add some functionality you have to:

  • Write new mapping code in the servlet.
  • Write new decoding code in your MIDlet.
  • Test that the code works together on all of your target platforms (server and device).

Using a Service-Oriented Architecture Approach

As we have seen, it's relatively easy to use a servlet as a mediator between a mobile client and a business service, but this solution doesn't scale well and is costly to maintain. So what we really need is something akin to RMI, but targeted squarely at the limitations of current mobile devices.

To provide this missing functionality, we set about designing an SOA model to provide a "transparent" transport layer and connectors to our remote business systems that could be generated from within an IDE, in much the same way as you can compile an RMI stub.

Figure 2
Figure 2. Mobile stub generation

One of the key design goals for the stub generator was to take an existing Java interface from "server-side" service and, after applying the limitations set by the CLDC specification, be able to generate stubs that will run on devices that implement the base CLDC/MIDP specs.

The stub generator builds a small set of classes capable of providing the transport layer the marshalling and unmarshalling of method calls over the air.

The design approach we have taken is to make writing mobile client code similar to writing any other Java service client. In order to understand how to use the stubs, we're going to dive into a simple example and then examine how the client discovers and connects to a business system.

Building a Simple Mobile Messaging Application

For our first code example we have been asked to build a simple messaging application by Packet Shifters, our favorite package delivery company. The van drivers have found that it is very useful to send short message service (SMS) messages between one another on their mobiles. Meanwhile, back in the office, the schedulers and operators use a mix of email and instant messaging. However, using all of the different message channels meant that messages were being missed, so the team agreed that they needed a new simplified message service that they could use from any device, at any location.

The first stage of the project was to build a unified messaging server, using a service-oriented architecture that runs on the "fixed-line" office network. The unified messaging service takes the form of an RMI-based service that can simply send and receive simple text messages to employees who give a valid user name and password.

The next phase of the project is to make the unified message service available to the van drivers via their mobiles.

On the Device

Because the unified messaging service is implemented as an RMI service, it necessarily has a Java interface. This interface is named UnifiedMessenger, which is already deployed and running within our fixed "server-side" network. This interface to the service is shown below.

public interface UnifiedMessenger  {

   String getMessage() throws RemoteException;
   void sendMessage(String recipient, String Message)
          throws RemoteException;

In order to produce the stubs, we need to communicate with the RMI service. We use the stub generator (Figure 2), which is available for download in the Resources section at the end of this article.

In addition to generating the stubs, the generator produces a factory. The mobile client uses the service-specific factory to get an interface to the UnifiedMessenger service, as is shown in the following code.

//MIDP code

UnifiedMessenger msgr = UnifiedMessengerFactory.getService();

String msg = msgr.getMessage();

The UnifiedMessengerFactory is also created by the stub generator, and returns a proxy that knows how to connect to the running UnifiedMessenger service. The MIDP client now has access to the UnifiedMessenger service running on the server via the "shadow" interface running within the MIDP client.

The MIDP code has a very direct and simple mapping to the RMI equivalent code, which you would find on a standard RMI system. It's shown below for reference.

//RMI client code

UnifiedMessenger msgr = (UnifiedMessenger)Naming.lookup( url );

String msg = msgr.getMessage();

As you can see, using an SOA approach on the client makes writing mobile clients that use remote services really simple and intuitive. If you consider the amount of code you would have to write to perform just a simple getMessage() call via a servlet, hopefully the benefits of the SOA approach are becoming clearer.

Under the Hood

The sequence diagram show in Figure 3 below shows the interactions between the generated proxy, which uses the stubs (not shown), the gateway, and a remote business service.

Figure 3
Figure 3. UML sequence diagram (Click image for full-size screen shot)

Under the hood, the factory (created by the stub generator) creates a new proxy object that implements the service's interface. The proxy uses the generated stubs, which in turn take the responsibility of marshalling and un-marshalling requests to and from the gateway.

The stubs contain special encoding that the gateway uses to identify and route requests to the business service. There is considerably more going on during these interactions than is shown on the diagram; however, for the moment, it is only necessary to understand these basic concepts and principles in order to build applications that use the generated code.

Factories and Connections

Factories running on the MIDP client make it simple to get a reference to an interface that shadows the interface of a network service, but stub and factory generation are only part of the solution, because the factories still need to be able to locate and connect the stubs to your business services.

There are two missing pieces to the puzzle that we haven't discussed so far--these are the mobile gateway and the service connectors.

Figure 4
Figure 4. The Net Caboodle architecture

The Mobile Gateway

The mobile gateway is the entry point for mobile clients connecting to remote business systems. The gateway uses connectors to communicate with business services and has a single port open to the internet, which is used by the code running on the Java device to receive and provide information to the mobile stubs.

The factories running on the device make contact with the gateway in an attempt to make method calls on the appropriate service. Two preconditions must be met. First, the device (or more specifically, the device user) must have "security clearance" to access the service (more on security in a moment). Secondly, the gateway must have access to a connector to the running service.


The mobile gateway uses connectors to allow objects to communicate with business services. Using a connector framework makes it possible for the platform to work with any type of service that has a Java interface.

Currently, the gateway has connectors for JavaBeans, JMX, RMI,
and Jini, making it possible to connect to running services without writing any server side code.

For example, the Java 1.5 JVM, which is a native application written partially in C, exports information by publishing Java beans that contain internal JVM statistics. The gateway's Java bean connector has direct access to this information and can make it available to a device by automatically building factories and stubs from the interface exported by the Java bean.

You can also connect to a large number of back-end services by building other connector formats. Using connectors makes it possible to connect to virtually any type of service written in any programming language, so long as these can be expressed as a Java interface by the time they reach the gateway.


One of the major concerns with any system that is exposed to the internet is security. As part of our SOA, we designed in the scope for various factory types that can be used to add functionality, such as security.

In our earlier UnifiedMessenger example, the mobile client code wasn't using any type of security to connect to the remote service. Also, there was no way for the UnifiedMessenger to know the identity of the person receiving or sending messages. The updated client example below shows how to enable a proxy to use security. This makes sure that the right person has access to the right service.

//get the basic interface as before
UnifiedMessenger msgr = UnifiedMessengerFactory.getService();

// calling a method on msgr here will cause a security exception(s)

//get a security provider
SecurityProvider securityProvider

//make the proxy secure
service= securityProvider.prepare(msgr);

//also any method invocation prior to authentication will fail

//perform a login

//if the gateway authenticates, then you can proceed as normal
String msg = msgr.getMessage();

The SecurityFactory and SecurityProvider are provided by the platform and in this case, we have bundled the security that both the gateway and the message service need, into a single set of standardized calls via the SecurityProvider object.


Using service-oriented architectures makes business information systems much easier to build and maintain. As the availability and use of Java on mobile devices has started to move into the mainstream, we have built a set of tools that allow SOAs to be extended to all kinds of mobile devices.

By using a combination of mobile stub factories, a mobile gateway, and service connectors, we've shown how to connect mobile Java applications into already-installed services.

Next time, we are going to look at using transactions on the device to implement a seat-booking system for the local movie theatre, so that people can reliably book seats while on the move.


Mobile Messaging Example & source code

NetBeans 4.2 plugin and stub generator

NetBeans version 4.2 (dev build) and NetBeans 4.2 Mobility Pack

NetBeans Mobility Pack Quick Start Guide

Net Caboodle

J2ME Wireless Toolkit

JMX mobile demo

Eclipse plugin and mobile stub generator

Eclipse J2ME plugin

width="1" height="1" border="0" alt=" " />
Nigel Warren is a co-founder of Net Caboodle and co-author, with Philip Bishop, of the books Java in Practice and JavaSpaces in Practice, both published by Addison Wesley Longman.
Gene Boggs O'Reilly software engineer