MIDP Persistence with RMS
In the context of enterprise Java development, there are a number of standard APIs that can be used to support data and/or object persistence: serialization, JDBC, Java Data Objects, and entity Enterprise JavaBeans (Enterprise Edition only). In contrast, MIDP does not automatically support any of these persistence mechanisms. The CLDC java.io package contains only the lower-level streams, readers, and writers, and doesn't contain any file or object streams, or, indeed, the Serializable interface.

This means that persistence-related code in MIDP differs considerably from other Java programming contexts and uses the Record Management System (RMS). The RMS comprises variable length record stores, each of which is a collection of variable size binary data records. Each record store has a unique name, and each record within a store has a nonreusable integer index that acts as a primary key. Although individual operations on a record store are atomic, there is no transactional support, apart from a version number, that can be used to support manually implemented locking strategies.

The Java Data Objects Specification
The Java Data Objects specification is an output of the Java Community Process (JSR 12), which had its first final release in April 2003. JDO defines an interface-based standard for the persistence of domain objects. There are currently around 20 vendors offering JDO implementations with varying levels of specification compliance. JDO implementations can be used with a range of data stores and across all three editions of the Java 2 platform and is a recommended persistence mechanism for data-centric applications on mobile devices.

JDO can be used in the context of a nonmanaged or a managed scenario. The former case refers to a typical two-tier or embedded application, the latter to a server-based architecture with the JDO implementation resident within a J2EE container. In both cases the JDO implementation hides issues specific to the Enterprise Information System (EIS), such as data type mapping, relationship mapping, and data retrieval and storage, from the application components. In addition, the managed scenario allows the application to make use of J2EE container mechanisms for transactions, security, and connection management. Clearly any JDO implementation within J2ME would be nonmanaged, though a distributed architecture that used JDO on mobile devices and also on a remote server would be possible.

The rationale behind JDO is that an application needs to be extended only once to encompass the JDO architecture and will then be able to access multiple and different EISs: object database systems, relational database systems, mainframe transaction processing systems, or ERP systems. The EIS vendor will be able to create a single JDO implementation and in doing so will allow pluggable access to any JDO-compliant application. The ability to run JDO in a MIDP context depends on the ability of the JDO implementation to provide the services required by the specification using only the resources available in a small device.

From the application perspective, the primary interface is PersistenceManager, supported by the Query and Transaction interfaces. An object implementing this interface will be responsible for the management of the JDO instance life cycle. This includes reading and writing from the data source and working with Query and Transaction objects to create the illusion that the entire network of objects reachable from the application, including persistent objects, are resident in memory at the same time. Within a nonmanaged environment, a JDO application will retrieve a PersistenceManager directly from a Persistence-ManagerFactory instance provided by the JDO implementation.

Candidate persistent classes must implement the PersistenceCapable interface, typically through the use of an enhancement tool provided as part of the JDO implementation. Enhancement is carried out after the domain model is complete and is usually applied to the compiled byte code, making this a completely transparent process. The binary compatibility of JDO instances means that they are portable between EISs without recompilation, provided a JDO implementation is available. It would not be realistic to expect a mobile JDO implementation to include the development tools, such as the byte code enhancer, for JDO. Mobile devices are unlikely to be used as software development platforms. Rather, the device would be required to act as a JDO client, downloading pre-enhanced byte code and using the JDO client APIs. However, it's not enough for a JDO client application to have only byte code, since any class that is to be persisted must have a corresponding entry in an XML file, known as the persistence descriptor file. The developer may supply a separate descriptor file for each class or a single file for a package. This file, containing key mapping information, must be available to the JDO implementation at runtime. Therefore, a MIDP JDO implementation would need to include both the JDO client APIs and the means to process the persistence descriptor.

Implementation Issues for JDO on MIDP
Current JDO implementations cannot run on highly constrained devices using the J2ME CLDC configuration. The smallest realistic JDO platform is currently a CDC configuration using a larger nonstandard library, such as the IBM JCL Max available with the J9 VM. This kind of configuration is appropriate for Pocket PC type devices but not for mobile telephones.

There are a number of reasons why implementing JDO in a CLDC/MIDP environment is problematical. The core issue is the required footprint size, because a JDO implementation would require space for the implementation itself, plus the larger byte code of classes enhanced to become persistent. Object data would have to be stored using RMS or a proprietary JDBC implementation. Depending on the way that it mapped the objects, overall storage space requirements for JDO persistence would probably be larger than the most optimized equivalent using direct RMS. Another problem would be the speed of RMS, since it's just a set of indexed flat files that require either direct indexed access or sequential access to locate data. This could be very inefficient when attempting to implement the JDO query language, JDOQL.

As we've discussed, JDO also requires an XML persistence descriptor that is accessible at runtime. A full validating parser to process this file would be much too large, but there are highly optimized nonvalidating XML parsers designed for use with J2ME, such as kXML or others that implement the XML APIs of the J2ME Web Services Specification. An alternative strategy might be to use some other way of providing metadata; for example, using the optional JAD (application descriptor) or manifest files.

Another limitation of the MIDP APIs is that they don't include the JDK 1.2 collections framework. This means that the only container classes available are the Vector and Hashtable from 1.x versions of Java, which is inconsistent with the JDO requirements of at least supporting the HashSet. We could develop some kind of wrapper class around the Vector to produce a different type of container that can be used in a J2ME context, but this doesn't address the further issue that Vector is synchronized, which could impact performance. Another option is to write a custom HashSet class (using an array of linked lists) and/or other custom library classes.

To mitigate the potentially large footprint resulting from the proliferation of the additional classes necessary to make JDO function in a MIDP context, a byte code shrinkage and/or obfuscation tool could be used. Since the main shrinkage benefit is gained where only small parts of libraries are used, the already small J2ME libraries would not necessarily yield a major change in footprint. For example, test results show only a 16% reduction in size for a sample J2ME application, as opposed to a best result of 91%.

In addition to limitations of the MIDP APIs, the JTWI specification imposes further restrictions by mandating only version 1.0 of CLDC. This means that JDO implementations based on CLDC 1.1 could not be guaranteed to work on a device that was JTWI compliant. One significant issue here is the lack of floating point support, which is required by JDO but only supported in CLDC from version 1.1.

Similarly, options for providing the required support for the cache are restricted. Implementing a JDO-compatible cache requires weak or soft references, because the JDO specification requires that persistent objects remain in the cache as long as they are in use by the application, but that they be removed from the cache automatically when the application stops using them. Because the application does not report when objects are disposed of, the only way for a JDO application to know that an object can be removed from the cache is to use weak or soft references.

• Open Source, Open Sesame?

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