CLDC does not include support for soft references and weak references have only been supported since version 1.1. An alternative approach for managing the cache could be to hold objects in the cache only when a transaction is active. When the application reports the transaction closed, all the objects that were retrieved during that transaction could be removed from the cache. This approach was common in object database implementations for older Java versions, in which weak or soft references were not provided.

Given these constraints, a JDO implementation for MIDP cannot easily meet the full JDO specification and pass the Technology Compatibility Kit (TDK) tests. It would be realistic to follow the model adopted by Oracle TopLink of supporting the JDO APIs as closely as possible within the constraints imposed. Braig and Gemkow, in their article "The BonSai Principle," demonstrate a similarly cut-down implementation, supporting only parts of the API (e.g., no query language) based on AspectJ. However, their implementation does at least run within the confines of a MIDP environment.

It may be that the best that can be achieved given current constraints is an architecture where remote proxies are used in combination with the JDO implementation running on the server. This should not be seen as a purely negative situation, since any enterprise-level application is likely to require distributed access to applications and data that would not benefit from very heavyweight mobile clients. Rather, the bulk of the system's services and data would be server-centric, with only small subprocesses and data caches being devolved down to individual devices. In this type of architecture, a JDO implementation could encapsulate the distributed cache management required and assist in the transparency of developing distributed applications.

JDO Architectures for MIDP Devices
A MIDP application can benefit from using JDO in two different scenarios. In the first scenario, the data store is located on a central server and a MIDP application running on a client mobile device uses JDO to access the remote data. The JDO layer in this case functions as a high-level wrapper for communication with the remote server's data store. In the second scenario, JDO is used to manage local data on the mobile device. The JDO layer in this case functions as a high-level wrapper around the MIDP RMS mechanism. In both scenarios, JDO provides a similar, easy-to-use API for managing the data, whether local or remote, using the application domain model. Each scenario, however, requires a different design solution.

Client JDO Architecture
A common technique in the design of JDO implementations is to build a JDO-JDBC bridge. An implementation that functions as a wrapper layer around JDBC can easily support a wide range of data sources. Figure 2 shows a naive architecture for using a client JDO implementation of MIDP based on this approach.

In this architecture, the data store is managed by a remote process that runs on a central server. A JDBC driver on the mobile device communicates with the remote server process, while the JDO implementation functions as a layer between the MIDP application and the JDBC driver.

This architecture has several disadvantages. First, because the entire JDO implementation, including the JDBC driver, is running on the mobile device, substantial memory resources are required. Second, standard JDO operations, such as converting queries from JDOQL to SQL (i.e., from the query language of JDO to a format that a JDBC driver can handle), might be too slow on the standard CPU of a mobile device. A further issue is the limited number of JDBC drivers that are available today for MIDP.

Client/Server JDO Architecture
Because of the problems associated with deploying the entire JDO implementation on the mobile client, a more realistic architecture to develop would be a client/server JDO framework (see Figure 3). In this architecture the JDO implementation is split between the mobile device and the server. A "fat" JDO process runs on the central server, communicating with the data store using a JDBC driver.

On the mobile device, the MIDP application uses a thin JDO client library to access the data store. Only operations that must be implemented on the client side are included in the thin JDO client library; all other operations are implemented by the JDO server. For instance, converting queries from JDOQL to SQL should be done on the server side due to the limited resources, in terms of memory size and CPU speed, of the mobile device.

To keep the footprint of the client as small as possible, some features of JDO, such as supporting local queries on memory collections (which, if supported, would have to be implemented on the client), may be omitted. This would mean the loss of full JDO compatibility.

The client/server JDO architecture is very flexible and can be tailored according to requirements. For example, instead of using a two-tier architecture, in which the data store and the JDO server are located on the same machine, a three-tier architecture can be used, deploying them on two different machines. Another design change is required when a JDBC driver is not available, for example, if the data store is an object database. In that case, the JDO server is expected to access the data store directly.

Local Storage JDO Architecture
There are many benefits to storing the application data on a central server, but in some situations local storage may be preferred. For example, a MIDP application that manages a contact list or a personal organizer should keep the data locally on the mobile device (possibly in addition to a backup of that data on a remote server). This can provide a faster response time and also ensures the availability of data when the server is unreachable because of network problems or maintenance. However, the JDO implementation, which acts as a wrapper around the RMS APIs, is complex (see Figure 4).

To understand what is expected from local storage JDO for MIDP, it might be helpful to distinguish between two types of JDO implementations: those that provide JDO support for relational databases by implementing a JDO-JDBC bridge and those that use object databases to support the JDO APIs. Because object databases do not rely on another database system as back-end storage, they must provide all the services that a standard database system provides, including (among others) storage management, lock management, query processing, and transaction support. For example, object database JDO implementations cannot convert JDOQL into an SQL query that is executed by a relational database, but rather have to include their own mechanism for processing and executing queries.

A local storage JDO implementation for MIDP would be very similar to a JDO object database implementation. Such an implementation has to support all the standard services that a database provides and everything has to be implemented on the mobile device. RMS as a low-level storage system is at least as good as binary files, but does not provide the database services that JDBC provides.

A storage solution can be based on allocating the first record in the RMS record set for general database information and an additional record for every object and every class schema. Other common internal database data structures, such as BTree+ for indexes, can be implemented by multiple RMS records (for instance, every node in the tree could be stored in a record). We have to consider whether or not the local management of such data structures is realistic because of the memory resources that they consume on the device, both for storing the data structures and in the implementation byte code that they add. A more appropriate solution might be to avoid supporting indexes (which are not required by the JDO specification) and to process queries by iteration over all the objects one by one (using RMS filters).

Hybrid Architecture
The most flexible solution for JDO on MIDP would be a hybrid architecture that included elements of both the client/server and local storage approaches. This would provide the benefits of a fully featured JDO implementation running in the server, plus the ability to preserve disconnected local data to maintain quality of service (see Figure 5). Of course, this type of solution is much more complex, since it requires the JDO implementation to manage the distributed data that is being cached on mobile devices. We can expect the development of systems using this kind of architecture to be supported by implementations of the Java synchronization APIs.

• Open Source, Open Sesame?

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5