Separating adaptable persistence attributes through computational reflection

Abstract

The separation of concerns principle is aimed at the ability to modularize separately those different parts of software that are relevant to a particular concept, goal, task or purpose. Appropriate separation of application concerns reduces software complexity, improves comprehensibility, and facilitates concerns reuse. Considering persistence as a common application concern, its separation from program's main code implies that applications can be developed without taking persistence requirements into consideration. As a result, persistence aspects may be plugged in at a later stage. This separation offers the developer handle persistence software attributes regardless the application functionality. We have analyzed different approaches to accomplish a complete separation of persistent features, appreciating that computational reflection achieves an entire transparency of persistence concerns, offering an enormous adaptability level. We present the implementation of a research-oriented prototype that illustrates how computational reflection can be used in future persistence systems to completely separate and adapt application persistence attributes at runtime.

Automatic Generation of Object-Oriented Type Checkers

“…We have implemented different type checkers using the flex, bison/yacc and ANTLR compiler construction tools. These implementations comprise both single-and multi-pass language processors [34].…”

JDiet: Footprint Reduction for Memory-constrained Systems

“…For example, deletion of data from the persistent store must be explicitly considered [Hohenstein et al, 2007;Rashid and Chitchyan, 2003], often causing orthogonal persistence solutions to break the persistence independence principle. Common approaches, such as PJava , also break this rule because they employ the persistence-by-reachability concept, which requires explicit binding to a persistent root [Al-Mansari et al, 2007;Ortín et al, 2004;Rashid and Chitchyan, 2003]. Those approaches that require all persistent types to extend the persistent root type are subject to the fragile base class problem [Mikhajlov and Sekerinski, 1998].…”

“…These applications have been termed persistent application systems (PAS) [Atkinson and Morrison, 1995]. The most common forms of persistence include the explicit use of a database, object-relational mapping, object-oriented databases, or file-persistence [Bläser, 2006;Ortín et al, 2004].…”

“…This approach has several notable drawbacks such as legibility, portability, readability and lack of reuse [Ortín et al, 2004]. Connector technologies such as Java Database Connectivity (JDBC) or Open Database Connectivity (ODBC) ease some of these drawbacks and DBMSs vendors supporting these connectors are ubiquitous.…”

“…Ortín et al [2004] developed a persistence system built on nitrO Cueva, 2001, 2002;Ortin et al, 2003], a system supporting non-restrictive computational reflection. By dynamically modifying the language semantics at runtime, this persistence system automated persistent storage using one of two update policies: (1) simple, which persists an object after a certain number of access or (2) timed, which persists an object whenever a certain configurable time period elapses.…”