FramePersist: An Object Persistence Framework for ... - CiteSeerX

Download PDF
0 downloads 0 Views 206KB Size Report
Comment
Katy C. P. Magalhães1*, Windson V. Carvalho2**, Fabrício Lemos3, Javam C. Machado2,3,. Rossana M. C. Andrade2,3. 1Programa de Pós-Graduação em ...
FramePersist: An Object Persistence Framework for Mobile Device Applications Katy C. P. Magalhães1*, Windson V. Carvalho2**, Fabrício Lemos3, Javam C. Machado2,3, Rossana M. C. Andrade2,3 1 Programa de Pós-Graduação em Eng. Elétrica – Universidade Federal do Ceará (UFC) 2 Mestrado em Ciência da Computação – Universidade Federal do Ceará (UFC) 3 Departamento de Computação – Universidade Federal do Ceará (UFC) E-mail: {katy, windson, fabricio, javam, rossana}@lia.ufc.br

Abstract Traditional requirements for persistence layers do not consider limitations of the development platforms available for mobile devices. In order to facilitate the development of applications, which need to store data, for mobile devices, these traditional requirements are reevaluated in this paper and a framework for object persistence is proposed. This framework, called FramePersist, is constructed based on the concept of object serialization and allows to persist and to search objects efficiently. Mapping rules of objects for persistence are presented together with a case study using the Symbian OS native file systems.

1. Introduction One of the main concerns during the development process of mobile device applications is data storage. Although the development platforms for mobile devices are, in their great majority, based on object-oriented languages (e.g., Java, C++, C#), they do not offer efficient persistence mechanisms. For this work, we consider persistence as the capacity to store and recover data from an object, even after finishing the application that has created it [13]. In this context, the main goal of this work is to propose an object persistence framework that facilitates the development of mobile device applications, considering portability to different mobile devices and some of the mobile device limitations as requirements. However, the proposed framework can be also used for traditional systems (i.e., not mobile). According to [5], a framework determines the application architecture and defines project parameters previously, allowing software engineers to concentrate in specific details of the application. This paper is divided in seven sections. The next section describes the state of art of data storage mechanisms available for mobile devices, considering the diversity of devices and operational systems. Section 3 summarizes the investigation done for this work of the existing persistence layers, comparing them with the proposed framework. Section 4 presents FramePersist and its development methodology. Moreover, this section introduces the framework architecture, the generation of object identifiers, and the search mechanisms can be provided. Then, Section 5 presents mapping rules that should be followed by software engineers who will apply the framework for object persistence, hierarchies and relationships. As a case study, Section 6 shows the development of an

*

Graduate student supported by FUNCAP, Ceará, Brazil. Graduate student supported by CAPES, DF, Brazil.

**

application using FramePersist. Finally, Section 7 presents the main contributions of this work and future works. 2. Data Storage in Mobile Devices Mobile devices, such as PDAs and cell phones, use flash memories (e.g., Smart Media and MultiMediaCard - MMC [21]) to store data permanently. This kind of non-volatile memory uses EEPROM (Electrically Erasable Programmable Read-Only Memory) technology and it has the following characteristics: small physical size, reduced weight, electric shock resistance, and high performance for reading data. However, writing operations are slow and storage capacity is reduced when comparing with personal computers’ hard disks. Operating systems in these devices make available APIs (Application Programming Interfaces) that make possible to the applications to store data in flash memories. For example, in Palm OS [16], which is the most used operational system in PDAs (Personal Digital Assistants), the standard format used for data storage is called PDB (Palm DataBase File). PDB is constructed from a sequential structure of non-ordered registers and it allows operations of insertion, deletion and update. However, in such register structure, the following is not available: delimitation fields, index information, or primary key. Thus, the software engineer is responsible for tasks that involve writing and recovering data in the registers. On the other hand, Symbian OS, which is an open operating system for cell phones, offers DBMS (Database Management System). This storage system is more robust than PDB, allowing the creation of tables, fields and indices. DBMS also provides the execution of SQL basic queries as well as the support of DDLs (Data Definition Languages) for creating schemes. However, not all cell phones use this operating system and, for those that execute Symbian OS, only some models implement DBMS (e.g. Nokia 9210) [1]. There are few database management systems for mobile devices, for example, Oracle Lite [14] and DB2 EveryPlace [8], which are proprietary systems and execute only in Palm and Windows CE systems. Moreover, they do not have support to all programming platforms (e.g., J2ME/MIDP). The existing development platforms for mobile devices make available functionalities that are not offered for the operating systems APIs. For example, AppForge [16], which is a version of Visual Basic language for Palm OS, Windows CE and Symbian OS, allows the creation of tables in the databases. In MIDP (Mobile Information Device Profile) of J2ME platform, RMS (Record Management System) API [20] provides to the programmer the capability of creating groupings of registers called record stores. This API makes possible queries, insertion, updating and deletion of registers. In turn, SuperWaba [17], which is a development platform for Palm OS and Windows CE based on Java, make available a class called Catalog that allows insertion, deletion, updating and linear searches of registers stored in PDBs. However, these platforms do not present native support to indices, data queries (e.g., using SQL) and joining execution, offering only precarious resources of filter and search. In their great majority, development platforms for mobile devices are based on object-oriented languages (e.g., Java, C++, C#). Nevertheless, these platforms do not offer efficient persistence mechanisms, different from the most robust platforms of the personal computers. Moreover, the objects cannot be persisted following the same principles of the traditional platforms, due to the absence of reflectivity mechanisms [20].

3. Persistence Layers Conceptually, a persistence layer is a library that allows the execution of the persistence process transparently from the application [3]. Since there is independence between the persistence layer and the data repository used, it is also possible to manage the persistence of an object model in different kinds of repositories (e.g., relational database, objectoriented database or XML files). This concept gives to the software engineer the capability to work in an environment completely object-oriented using methods to include, to modify, and to remove objects as well as a query language to filter data, which return object collections that follow the search parameters. Generally, in traditional applications, data are stored in local files that are read easily and quickly from either the hard disk or the local network. However, mobile devices neither have local disks nor have permanent connection to a database located in a server. Therefore, it is necessary to reevaluate the requirements that a persistence layer should follow (such as the ones presented in [3] for a traditional persistence layer). Our goal is to adapt these requirements to the mobile computing environment in order to minimize the layer complexity, which reduces the performance degradation of the applications and becomes the use of the proposed framework feasible. In Java, C++, and Smalltalk, we can find libraries that implement persistence layers following all requirements defined in [3]. For example, we can mention Hibernate [9], Castor [18], OJB (Object-Relational Java Bridge) [14], and Torque [19]. Hibernate allows the transparent persistence of objects in databases using JDBC (Java DataBase Connectivity) as well as runs the mapping of classes for XML. Its main characteristics are: implementation relatively simple, high performance, definition of object/relational mapping (using XML), permission of Java object persistence, existence of the query language HQL (Hibernate Query Language), and support only to the relational databases. Castor is a framework for data binding that provides mapping between Java objects, XML documents, LDAP directories, and SQL data. It uses API JDO (Java Data Objects) for persistence in relational databases. Similar to Hibernate, Castor follows LGPL license. OJB is an implementation of the ODMG and JDO object mapping standards, allowing objects to be manipulated without the need of implementing a special interface or extending a specific class. Its library gives support to standalone or distributed applications as well as to the configuration of schemes in execution time, and to the generation of tables, which map a class hierarchy or classes related to a set of tables and implement elements to improve the persistence layer performance. Torque is a persistence framework developed as an Apache Turbine sub-project. Its classes allow generating database structures, SQL classes and codes for data access related to pre-configured schemes written in XML. Similar to OJB, its distribution is under the Apache license rules. All libraries that implement the persistence layers mentioned previously present support to DBMSs and they are designed to J2SE platform of the Java language, except OJB, which also has support to J2EE (Java 2 Enterprise Edition platform). For presenting functional dependence related to API languages (e.g., JDBC, JDO), they become impracticable to be used in applications for mobile devices. Therefore, there is a demand for a persistence layer designed to the mobile computing environment, which is the main motivation of this work.

4. The Persistence Framework According to [6], a framework is a collection of abstract classes, concrete classes, and the interfaces between them, consisting of a subsystem project. In this work, the proposed framework, called FramePersist, focuses on a specific domain of object persistence for mobile device applications and, for this reason, it is considered an application framework. For the development of the proposed framework, a methodology described in [12] is used. In this methodology, known as Oriented Examples Project, the domain abstraction is taken from the generalization of the applications and from the investigation of concrete examples where similar aspects of different applications can originate classes that group the similarities between them. This methodology has three stages as follows: domain analysis, design, and test. Domain analysis is applied to assimilate the already known abstractions, and to collect examples of programs that can be built from the framework. Design is used to design abstractions that can be specialized to incorporate the examples. Test is responsible for using the framework to develop the examples of the analysis domain stage. In FramePersist, this methodology was applied to investigate the existing functionalities for data storage in the programming platforms, presented in Section 2, as well as to reevaluate the requirements that a persistence layer should follow, mentioned in Section 3. The following object persistence requirements for mobile device applications had been defined during the framework development: Support to the different persistence mechanisms, which can be defined as the data storage structure, for example, a relational DBMS, a XML file or a DBMS OO. A persistence layer should support the changes of mechanisms and allow writing the state of objects in any of these mechanisms; Selective persistence, which allows the serialization and the persistence only of the desired attributes of an object, minimizing the stored space with transient attributes; Data layer complete encapsulation determines that the software engineer should use only high level messages (e.g., save or delete) to deal with the persistence objects, leaving to the persistence layer the execution of the message conversion in actions on the data; Object identifier, which guarantees that the application has a unique identity to work with objects; Selective object search, which offers search mechanisms for indices or attributes previously established; Extensibility consists of the persistence layer allowing the addition of new classes to the scheme and making possible the persistence mechanism update; Support multiple technologies, which means the support of several types of existing mobile devices included in the persistence layer that should be constructed aiming at reusability and easy adaptation to distinct technologies. From the requirements analysis, small applications had been built to store data in three platforms: J2ME/MIDP, J2ME/PersonalJava, and SuperWaba. Characteristics related to storage that are common among these applications had been grouped, and the differences had been isolated. After the application of some design patterns [6], FramePersist had been constructed. The following sub-sections present in more details the FramePersist architecture, the generation of object identifiers and the search mechanisms. 4.1. FramePersist Architecture

Figure 1 shows an overview of the FramePersist architecture. Some methods and attributes are omitted to illustrate the whole architecture clearly. Classes and interfaces presented in gray represent the framework part where the software engineer manipulates objects to be persisted or converted. The other classes in white correspond to the framework part that maps objects to a storage format and implement the search mechanisms. FramePersist uses serialization to persist objects. The serialization concept, in this case, consists in transforming the attributes of an object in one data array [10]. The serialization can be executed with the use of separators for the attributes or using existing structures in the programming languages. Codes, which are illustrated in Figure 2, show the serialization process in two platforms based on Java: J2ME and SuperWaba. The parts in italic correspond to the structures that make possible the serialization. The framework provides the selective persistence using the ObjectPersist class. This abstract class demands that the methods serialize and deserialize are rewritten, allowing that the software engineer decides which class attributes should be persisted. The selective persistence and the object serialization are described in details in Section 5. FramePersist guarantees support to different persistence mechanisms with the encapsulation of the operations for data storage. These operations are executed by two classes that belong to the white area of the framework: PersistenceHandler and HandlerSearchField. The methods of these classes should be rewritten to interact with each structure of storage (e.g., Catalog, DBMSs, PDB, RMS). This encapsulation provides the extensibility of the framework as well as portability for different development platforms and operating systems for mobile devices. The ObjectHandler class allows the data layer complete encapsulation. This class allows the objects persistence using high-level manipulation methods (e.g., insertObject, deleteObject, updateObject). Moreover, it offers methods for recovery and search of persisted objects (e.g., getObjectById, searchObject, openCollection). The ObjectHandler class uses methods of the classes represented in the white area of the framework to interact with the storage types and search structures. This class is also responsible for translating objects in registers and vice versa, using the invocation of serialize and deserialize methods of the manipulated object.

Figure 1. FramePersist Overview

Figure 2. Object serialization Codes in J2ME and SuperWaba

Moreover, FramePersist provides either the persistence or the conversion of objects. Using two interfaces, the software engineer can convert objects to XML or to SQL queries to be sent, for example, to a Web server or to be synchronized with a personal computer. 4.2. OIDs Generation The generation of object identifiers (OIDs) is one of the main requirements for persistence layer creation [3]. These OIDs should not have any meaning for the application, resembling itself to the concept of surrogate key of relational databases [2]. Three kinds of OID generation is presented in [2]: a unique OID amongst all the persisted objects, a unique OID in the class hierarchy and a unique OID for each instance of the same class. In the proposed framework, not all objects are persisted in the same database, which allows the application developer to specify in which data collection objects will be persisted. In this way, it is just demanded the OID uniqueness in the same object collection, what it is similar to the third type of OID generation mentioned previously. The OID uniqueness in the same data collection should be provided by the insertPersistenceRegister method of the PersistenceHandler class, since the identifier returned by this insertion is mapped to the OID of the insertObject method of the ObjectHandler class, as shown in the sequence diagram of Figure 3. Thus, it is mandatory that in the class implementation of the PersistenceHandler class there is a unique identifier for each register stored in the same repository. The implementations of the data storage, which are provided by the development platform of the applications for mobile devices, associate an identifier to each register stored in the same repository. This association facilitates the implementation of the PersistenceHandler class for the generation of the register identification that is mapped to the object OIDs.

Figure 3. Sequence diagram for the object persistence

4.3. Search Operations In Figure 1, HandlerSearchField and HandlerBinarySearch classes provides the search operations, through the. These classes are constructed based on the Strategy design pattern [6], in which a Context class should execute an algorithm that can have several strategies. In FramePersist, the Context class corresponds to the ObjectHandler class, which needs to insert search fields and to recover objects from them. When creating a class to be persisted, the application developer determines what attributes are search fields. The developer instantiates SearchField class objects to execute this operation. In the code shown in Figure 2, for example, this process is illustrated as follows: the attribute name of the Client class becomes a search field. When inserting an object, the ObjectHandler class uses the HandlerSearchField class to store the search field and the OID that are used to execute future searches. The sequence diagram of Figure 3, where the object to be persisted has a unique search field, shows this insertion. There are several strategies to store indices or search fields that facilitate data recovery, for example, registers ordered by indices and B+ trees. The former consists of storing the search fields sequentially and ordered, what allows executing binary search for their recovery as well of the OID related to the object. The latter allows a field to be found, in the worst case, in log2N operations, where N corresponds to the number of stored blocks [13]. This type of search is much more efficient than the linear search provided by the majority of the storage systems for mobile devices. Thus, in FramePersist, the HandlerBinarySearch class corresponds to the latter strategy, what does not prohibit that other strategies are used. 5. FramePersist Application Persistence object mapping rules have been developed in this work based on object mapping rules for relational databases, as detailed in [2].

5.1. Persisting an Object The mobile application developer, in order to persist an object, should be guided by the following steps: Create the class that will be responsible for persistence as an ObjectPersist subclass, which is a FramePersist hotspot for the application; Define which class attributes will be persisted; Write serialize and deserialize methods using the object serialization concept presented in Section 4.1. In the serialize method, the developer should group, in the same data array, the attributes to be persisted, and, in the deserialize method, should execute the inverse process to recover the attributes; Choose which attributes, besides the OID, will be used by the application to search and to recover objects; Create in the class constructor, for each chosen search field, a SearchField object and insert it in the existing schFields array in every object of the ObjectPersist class. The insertion order of the search attributes will be taken in consideration for the search execution, since, in the searchObject method of the ObjectHandler class, it should be passed the search field identifier that represents the index in the array schFields; Define a name for the object collection. In this step, it is the developer responsibility to guarantee that only the objects of the same class can be stored in the same collection.

Figure 4. Classes to illustrate the persistence process

Figure 4A illustrates a simple object of the persistence process. It presents a Client class with three attributes: name, birth and age. The last attribute is transient (i.e., it does not need to be stored), therefore, it can be derived from the attribute birth, which indicates the client birthday. The Client class is defined as an ObjectPersist subclass. In the serialize method, name and birth attributes are located in the same array of bytes. In the deserialize method, these two attributes are recovered. The calculateAge method calculates the transient age attribute. The developer has defined the name attribute to search the object collection (e.g., client´s name is Johnson). Thus, in the Client constructor, an object of the SearchField class, which contains the attribute name value, is created. Figure 2 illustrates this process in J2ME and SuperWaba. For persisting a Client class object, an ObjectHandler class instance should be created. In this creation, the object collection name is passed through (e.g., clients). After that, the developer should call the insertObject method from the ObjectHandler instance to persist a Client object. Figure 3 illustrates, using a sequence diagram, the insertObject method that maps the object in a register. During the persistence process of an object in a

collection, the mapping process to the device storage systems and the index search generation are transparent to the application developer. 5.2. Persisting an Object Hierarchy There are three solutions for the object hierarchy mapping to a relational database: (i) a collection for each concrete class from the hierarchy, (ii) a collection for each class, and (iii) a collection for the whole hierarchy [2][13]. In FramePersist, the third solution (iii) is not feasible since the creation of a collection for the whole hierarchy would disable the deserialization process executed by the ObjectHandler class. Thus, the choice of the object storage method using some of the other solutions - (i) or (ii) - is related to the execution type of the application search (i.e., how the application developer will search the persisted objects). In case of searches on each concrete object collection, a collection for each concrete class should be created and all attributes of each class should be stored in this collection. On the other hand, in case of executing searches on the whole hierarchy, it should be used a collection for each class, concrete or abstract. In this case, only specific attributes of each class should be stored in the correspondent collection. Figure 4B presents the class hierarchy that is used to illustrate these two mappings. In this example, there are three classes: an abstract class, Person, and two concrete classes, Employee and Student. In (i), the application developer should create a collection for Employee and a collection for Student, implementing serialize and deserialize methods in each class. All the attributes should be serialized, including the ones inherited from Person. For example, in the Employee class, the serialize method should serialize name and salary attributes. In such way, the searches could be made only in each two collections (e.g., to search the students whose name starts with letter ‘A’). In (ii), the application developer should create a collection for Person, a collention for Employee and a collection for Student. The methods serialize and deserialize should be implemented in each three classes. However, only specific attributes for each class should be serialized. For example, in case of the Employee class, just the attribute salary should be serialized. In this way, the attributes of an Employee object are distributed in several collections, as follows: the attribute name in the collection of Person objects; and the attribute salary in the collection of Employee objects. Despite the second mapping type demands more coding by the application developer than the first one, it allows more efficient searches on the search fields common to the hierarchy objects, since the search can be done only in the root class collection. For example, to recover a hierarchy object whose name starts with ‘John’, the application developer should search only the Person collection. 5.3. Persisting relationships between objects The application developer will not persist only objects, but also relationships between them. These relationships can be divided in associations and aggregations. In associations, the objects should be persisted in distinct collections and attributes can be used to act as foreign keys of the relational databases. It is important to mention that the operations for joining data are slow, which is a relational database limitation. In addition to this, there is the lower processing power of mobile devices that can increase this limitation.

In Figure 4A, for example, there is a relationship 1:N between the Doctor class and the Appointment class. It is omitted in the figure that these two classes inherit from the ObjectPersist class. To persist their relationship, it is necessary, when persisting an object of the Appointment class, to add an attribute that corresponds to the code of the Doctor object that the Appointement object refers to. This attribute should be a search field of the Appointment class. Thus, to recover the appointments of a Doctor object, it is necessary just search objects in the Appointment objects collection using the method searchForField of an ObjectHandler object. In aggregations, aggregate objects can be considered as a complex attribute of the aggregator class, then, they can be persisted in the same collection. A problem in this approach is the slow recovery of the object, since the aggregate objects will be also loaded in the memory. A solution for this problem is the use of the late fetching object technique, where the aggregate objects are only loaded to the memory when requested. To implement this approach using FramePersist, it is necessary the use of two collections, one for the aggregator object and another for aggregated objects. Figure 4A shows a Client class that has an aggregation relationship 1:N with the Examination class. The method serialize of the Client class should serialize its attributes (e.g., name, birth) with the object array that contains the Examination objects and persist them in just one collection (e.g., clients). To serialize an object array, it is enough to serialize each object and create a big array of bytes. With the use of the late fetching object technique, the search process becomes more efficient. For this, the creation of a new collection for each aggregator object is necessary (i.e., for each instance of the Client class, an Examination collection is needed). A suggestion for naming is to combine it with the aggregator OID. To serialize an object of the Client class, an external class has, first, to persist the object, then, to get the OID, and, finally, to persist the array of Examinations in a new collection. The search process is similar as follows. First, the Client object is recovered using the method deserialize, which only recovers the specific class attributes (i.e. name and birth). Thus, when it is necessary to access the Examinations, a method is called to deserialize the objects from a specific Examination collection of the object. This approach is applied in the case study that is presented in the next section. 6. Case Study FramePersist was implemented in PersonalJava to execute in the operating system Symbian OS of the Sony Ericsson P800 and P900 cell phones. PersonalJava is an implementation of the CDC configuration of the J2ME. This API is based on version 1.1 of the JDK, with some optional packages, classes, and methods [1]. Different from MIDP version, PersonalJava does not have data storage mechanisms, allowing just access to the file system. To overcome PersonalJava storage deficiency, a simple management system of non-ordered and variable size registers was created. For each set of registers, two files are used, as follows: a data file, which stores bytes of each register, and a location file, which contains the position and the size of the information stored in the data file for each register. The PersistenceHandler class was implemented to manipulate these two files and to provide the basic manipulation methods demanded by the framework (e.g., insertion, deletion, recovery). For example, to include a new register in the database, the PersistenceHandler class stores bytes of the register at the end of the data file, it updates the file location and, finally, it returns the register ID. This ID is unique in the repository,

which is a mandatory condition to guarantee the consistency demanded by the framework, as presented in Section 4.2. To supply the search mechanisms, another structure was created to store the search fields. In this case, for each field a correspondent file was created to store the ordered registers. This creation is possible due to the fixed size of the search fields that are stored together with the correspondent IDs to the positions in the location file of the objects they refer to. The strategy implemented for the search was the HandlerBinarySearch class. Thus, for each insertion of a SearchField, the ID of the object and the value of the SearchField are grouped, a binary search is executed on the correspondent file and occurs an insertion that always keeps the file ordered. To make a search in a certain SearchField, the instance of the HandlerBinarySearch class opens the correspondent file and, using a binary search, recovers the object IDS that satisfy the search. These IDS allow the ResultObjectSetBySearch class to access the location file and recover the position of the serialized data of each object in the data file. An application that was implemented in PersonalJava using FramePersist is presented in the next sub-section. 6.1. Mobile Medical Office: FramePersist Application in J2ME PersonalJava A FramePersist instantiation is done with the creation of an application of mobile medical doctor's office. This application allows a doctor to have access to a patient data, such as appointments, examinations and medical history, which have been previously registered in the application desktop version. The application allows the doctor to register a medical appointment in the cell phone, and, later, to synchronize these data with the desktop. Moreover, the doctor has access, through the application in the cell phone, to the agenda of booked appointments registered in the desktop version. Figure 4A presents a part of the application class diagram. The application uses FramePersist to persist the objects that represent clients (i.e., instances of the Client class) and its aggregations (e.g., instances of the Examination class). The framework is also used to persist the agenda of medical appointments (i.e., instances of the Appointment class), as well as, its relationship with clients. The implemented binary search in the HandlerBinarySearch class is used for search operations on the client data. In the application, searches can be done by name and client code. The application data synchronism is executed using sockets, which allows transmitting XML documents that contain information inserted in the cell phone and in the desktop version. The ConverterToXML interface is implemented in all persisted object classes to map both objects to XML and XML to objects. Figure 5 presents the architecture and some screenshots of the application. This application has been tested in Sony Ericsson P800 and P900 mobile devices, but it can be executed in any device that supports PersonalJava (e.g., iPaqs).

Figure 5. Case Study: a mobile assistant of a medical office

7. Conclusion and Future Work The main contribution of this work is the framework to persist objects of applications in mobile devices. FramePersist allows object storage as well as an efficient way to search these objects, which are inexistent functions in the platforms for mobile devices available currently. For this, data storage types in applications for mobile devices have been investigated, considering several operating systems and development platforms available currently. Based on these data, we have concluded that an efficient search mechanism is not possible using the existing implementations. A research about persistence layers has been also done and there is a lack of persistence framework for applications in mobile devices. From the requirements of a persistence layer of traditional applications, we could reach the requirements of a persistence layer for the application development of mobile devices, considering the limitations in these devices. Traditional object mapping rules and traditional relationships have been modified to facilitate the FramePersis use. The framework is instantiated using the CDC/PersonalJava configuration and an instance of a medical application presented as case study. As future work, we aim at instantiating the framework for other languages and applications, to improve FramePersist, since for each new instantiation, new abstractions can appear. New strategies to store indices or search fields that facilitate the recovery of data can be also added to FramePersist, as done previously with the binary search. A solution of compacting stored data is also desirable. Moreover, it is necessary to add characteristics of distributed applications to the persistence layer, such as control of concurrency and cache management. In this case, it is necessary to implement security mechanisms to provide integrity, authenticity, reliability and availability of the transmitted data. Acknowledgments First of all, we would like to thank the research government agencies Funcap, Capes and MEC/PET as well as Instituto Atlântico for their financial support. We are also indebted to the Grupo de Redes de Computadores, Engenharia de Software e Telecomunicações (GREaT), especially to José de Ribamar Bringel Filho for his help in reviewing this paper, and to Sarah Lima Bezerra, Carlos Eduardo Araújo Vieira, and Robson Teixeira da Silva for their technical support in the development of applications for the PersonalJava platform.

References [1] ALLIN, Jonathan. Wireless Java for Symbian Devices. John Wiley & Sons LTD, 2001. [2] AMBLER, Scott. Mapping Objects To Relational Databases. AmbySoft, 2000. Available at: . Access in: Jan 2004. [3] AMBLER, Scott. The Design of a Robust Persistent Layer for Relational Databases. AmbySoft, 2000. Available at: . Access in: Jan 2004. [4] BERNSTEIN, Ricardo G. Iniciando o Desenvolvimento na Plataforma PalmOS. ClubePalm, 20 Jan 2001. Available at . Access in: Sept 2002. [5] CARNEIRO, C. Frameworks de Aplicações Orientadas a Objetos – Uma Abordagem Iterativa e Incremental. 2003. 110 f. Dissertação (Mestrado em Redes de Computadores), Universidade Salvador, Salvador. [6] WOLFGANG, Pree. Design patterns for object-oriented software development. 2nd edition. 1995. [7] CORBA™/IIOP™ Specification. Available at: . Access in: Feb 2004. [8] DB2 EVERYPLACE. Available at: . Access in: Jan 2004. [9] HIBERNATE. Object/Relational Mapping and Transparent Object Persistence for Java and SQL Databases. Available at: . Access in: Apr 2004. [10] J2ME – Java 2 Plataform, Micro Edition. Available at . Access in: Sept 2002 - Sept 2003. [11] J2SE – Java 2 Plataform, Standard Edition. Available at: . Access in: Sept 2002 - Sept 2003. [12] JOHNSON, Ralph E. How to Design Framework. Notes for Proceedings of the Conference on Object-oriented programming system, languages, and applications OOPSLA93, University of Illinois, 1993. Available at: . Access in: 10 May 2001. [13] NAVATHE, S.; ELMASRI, Ramez. Fundamentals of Database Systems. 3rd edition, 2000. [14] OJB – Object Relacional Bridge. Available at: . Access in: Apr 2004. [15] ORACLE DATABASE LITE. Available at: . Access in: Jan 2004. [16] PALM. Products, Services e Company Information. Available at: . Access in: Jun 18th, 2003. [17] SUPERWABA. The REAL Power of Mobile Computing. Available at . Access in: Sept 2003. [18] THE CASTOR PROJECT. Available at: . Access in: Apr 2004. [19] TORQUE. Available at: . Access in: Apr 2004. [20] WHITE, J.; HEMPHILL, D. Java 2 Micro Edition. Manning Publications co. 2002.

[21] YIM, K. S.; BAHN, H.; KOH, K. A flash compression layer for smartmedia card systems. Consumer Electronics, IEEE Transactions on, Volume: 50, Issue: 1, Feb. 2004. Pages:192 - 197. [22] .NET FRAMEWORK. Available at: . Access in: Sept 2003.