Hacia la evolución del esquema en BarbadosJ. Baltasar García Perez-Schofield1

David Martínez Torres3

Emilio García Roselló1

Tim B. Cooper2

Manuel Pérez Cota1

1 Facultad de Informática. Edif. Politécnico, s/n. Campus As Lagoas (Univ. Vigo) 32004Ourense, España (Spain).

2Director of Smarts, Pty Ltd. Australia.3Departamento de Electrónica y Computación, Universidad Tecnológica de la

Mixteca, Huajuapan de León, 69000 Oaxaca – México. {jbgarcia|erosello|mpcota}@uvigo.es

tco@smarts.com.audtorres@nuyoo.utm.mx

AbstractLa evolución del esquema es un problema que cada sistema persistente debe cubrir para ser útil en la

práctica. Consiste básicamente en soportar la modificación de clases, tratando la conversión de los objetos que secrearon y guardaron bajo las definiciones de la clase antiguas. Se han hecho varias propuestas para manejar esteproblema en sistemas que siguen una aproximación ortogonal a la persistencia, pero, no hay ninguna propuesta parasistemas persistentes basados en containers. En este artículo describimos un mecanismo de evolución del esquemadiseñado para el prototipo Barbados. Barbados es un entorno de la programación completo que está basado en unaarquitectura de containers que proporciona un almacenamiento persistente. Barbados no proporciona persistenciaortogonal plena, pero, como se describirá en este artículo, su arquitectura tiene varias ventajas, como una adecuaciónespecial para una aproximación novel en este campo.

Key words: persistence, containers, C++, schema evolution.

1. Introducción

Un sistema persistente es aquel en el que las estructuras de datos y los mismos datos persisten más allá de laejecución de un proceso [1]. Una estructura, en el caso de un lenguaje no orientado a objetos, así como una clase, enel caso de un lenguaje como C++ o Java, debe poder ser modificada, permitiendo así a su vez cambios en unadeterminada aplicación, que como sabemos, debe adaptarse a las nuevas necesidades que surjan con el paso deltiempo. El modelo de persistencia más utilizado hoy día en sistemas persistentes es el ortogonal, [2] si bien nosotroslos autores hemos diseñado un modelo pseudo-ortogonal (de hecho, sólo ortogonal al tipo), el modelo basado encontenedores (containers) [6][11], que defendemos [14], y así se ha demostrado [15], tiene ciertas ventajas, comopor ejemplo un mejor rendimiento.

En un sistema persistente, el sistema ha de enfrentarse a todos los problemas de recuperación yalmacenamiento de objetos en el almacenamiento persistente, siendo un proceso totalmente transparente al usuario.Así, el sistema también debe dar soporte a la posibilidad de que un objeto esté desfasado respecto a su clase,proponiendo tres posibles estrategias [4]: a) el sistema convertirá los objetos afectados de una manera inmediata(estrategia eager) o simplemente esperando a que los objetos afectados sean utilizados (estrategia lazy), b) darásoporte a diferentes versiones de una misma clase, con, por lo tanto, diferentes objetos relativos a cada una de esasdiferentes versiones, y c) simplemente, no permitirá a los programadores cambiar ningún tipo, obligando a definirnuevas versiones y sus respectivas conversiones de objetos manualmente. Esta última posibilidad es la mayor parte delas veces inaceptable, mientras que la segunda sólo suele utilizarse en sistemas donde diferentes versiones de unobjeto dado son necesarias, como las OODBMS asociadas a entornos CAD [3][16].

Aunque la evolución del esquema ha sido un campo de investigación activo durante mucho tiempo, continúasin ser resuelto de una forma universalmente aceptada. Mientras la conversión inmediata (o eager) tiene la ventaja deque a su término, el almacenamiento persistente está en un estado totalmente consistente, requiere poner elalmacenamiento persistente en un estado de inactividad, o fuera de línea mientras no ha sido totalmente actualizado,lo cuál requiere un periodo de tiempo considerable en un almacenamiento de tamaño medio. Esta aproximación es la

utilizada en PJama [7]. La aproximación de transformación tardía (o lazy), no requiere del requisito de tiempo de laanterior, lo que la hace más atractiva [10][24]. Su única desventaja es que objetos actualizados conviven en elalmacenamiento persistente con objetos no actualizados (es decir, todavía no accedidos) respecto a su clase.

1.1. El modelo basado en containersEn el presente artículo proponemos una solución a la evolución del esquema en el modelo basado en

contenedores, y por ende, al prototipo Barbados [5][12]. A través del estudio de la aproximación presentada aquí,veremos cómo este modelo se revela especialmente adecuado para la resolución de este problema, específicamentegracias a su estructura basada en containers [11][12], que permiten el desarrollo de una estrategia mixta, combinandolas ventajas de ambas técnicas: inmediata (eager) y tardía (lazy).

Como ya se dijo, Barbados es un sistema persistente empleando una estrategia de clustering [23] basada encontainers. Puede verse la estructura general de un container en la figura 1. Los containers son además visibles alusuario, que los maneja como directorios (de objetos), con sus relaciones jerárquicas, de una forma similar a lossistemas de ficheros. Nótese que ésto supone una estrategia de clustering totalmente manual (del que el usuario esinconsciente), lo cuál no es del todo indeseable dado el insatisfactorio rendimiento de los métodos automáticos [25].Por otra parte, los containers pueden referenciar objetos en otros containers, a través de un mecanismo llamado C-NSwizzling [13]. Entre otros tipos de relaciones, se permite la que sucede cuando un objeto reside en un container,mientras que la definición de su clase reside en otro. Esta relación es denominada TypeClass, y se ve totalmenteafectada por el problema de la evolución de la esquema. Esto es normal, pues el esquema típico de una aplicación enBarbados consiste en uno o más containers de datos, acompañado de uno o más de código, en modo de sólo lectura.En los primeros se encontrarían los objetos de la aplicación, mientras en los segundos se encontrarían las clases deesos objetos.

Las relaciones TypeClass conllevan que en el container donde se guarda el objeto se guarde también unacopia reducida de su clase. De esta forma, puede detectarse cuándo los objetos en ese container están desfasadosrespecto a su clase. Esta copia se denomina AbbreviatedClassdef, (definición de clase abreviada), y toma un papelactivo en la evolución del esquema. Un ejemplo acerca de ésto puede verse en la figura 2, en la que un objeto en elcontainer 68 tiene su clase definida en el container 753.

El resto del artículo se reparte como sigue: a continuación presentamos una discusión acerca del diseño deevolución del esquema. Seguidamente, se hace una breve referencia acerca de otros trabajos relacionados deevolución del esquema (aunque muchas veces, donde sea apropiado, se hace referencia a otros sistemas), parafinalmente presentar las conclusiones.

Figura 2. Funcionamiento de la información AbbreviatedClassdef(información de clase abreviada), en una relación de clase entre dos

containers.

Figura 1. Estructura básica de un container.

2. Evolución del esquema en el modelo basado en containers.

Uno de las referencias más importantes con respecto al soporte de la evolución del esquema es sin duda elGestor de Base de Datos Orientado a Objetos (SGBDOO) O2 [9], en el que muchos otros sistemas se han inspirado,como por ejemplo PJama [8]. Otros SGBDOO, auténticos precursores en este campo, como por ejemplo, Orion [20],no alcanzan el grado de sofisticación de O2. Uno de los puntos fuertes de O2 es el soporte de funciones de conversión[9], también presentes en PJama [7][8] y en Barbados. Otros investigadores han estudiado el efecto del soporte de laevolución del esquema en sus sistemas, como por ejemplo, en Napier [19], o –más recientemente- en Oberon-D [18].

Las premisas del mecanismo de evolución del esquema para un sistema persistente como Barbados fueron a)soporte semi-automático: es decir, conversión automática en todos los casos posibles, y en aquellos donde no lo sea,se espera la intervención del usuario, incluso con una función de conversión, si se desea -ya que reunciamos deentrada a un sistema totalmente automático, por considerarlo poco satisfactorio [4][18]-; b) un soporte que norequiera poner el almacenamiento fuera de servicio [10][7], y por supuesto, que permita obtener ventajas del modelode containers en el que se basa Barbados.

2.1. Detectando la necesidad de evolución del esquema.

Tal y como se ha discutido previamente, el escenario más típico de evolución del esquema se producirácuando un objeto reside en un container diferente a su clase.

Valor Significado

SEConvert Convierte todos los objetos en el nuevo container para que concuerdencon su definición de clase. Modo automático.

SESplit Crea la antigua clase en el nuevo container, eliminando la relación entrelos dos containers.

SEFail La carga simplemente falla. El valor (error) de retorno es E_SCHEVOL.

SEAsk El usuario es preguntado acerca del camino a tomar (la respuesta es otravez una de las anteriores).

Tabla 1. Posibilidades disponibles para el parámetro de evolución del esquema.

En Barbados, el punto más claro para detectar la necesidad de evolución es en el momento de carga de uncontainer en memoria; además de cargarlo a él, se cargan también todos los containers relacionados: por ejemplo,aquellos donde se guardan las clases de los objetos almacenados en el container principal (si es que no están ya enmemoria). En ese momento, puede detectarse si los objetos del container están desfasados con respecto a sus clases,comparando las definiciones de clase abreviadas (AbbreviatedClassdef's), guardadas en los containers de los objetos,y las clases reales.

Un cierto control del proceso de evolución se obtiene a través de un argumento a una de las llamadas delAPI de Barbados, que gestiona la apertura (carga) de un container en memoria. Ésta llamada es OpenContainer(), y admite dos parámetros: uno relativo a la protección contra escritura del container, y un segundo que se refierea la evolución del esquema y cuyos posibles valores pueden verse en la tabla 1. OpenContainer() será llamadaen procesos interactivos (como por ejemplo, a través de 'cd()', donde sería útil SEAsk) o programáticos (porejemplo a través de una función de usuario, donde serían útiles SEConvert y SEFail). El modo de conversión dadopor SEAsk soporta el uso de funciones de conversión (se presenta al usuario una plantilla con la anterior función deconversión utilizada para esa clase, si se realizó alguna conversión), mientras que con SEConvert se utiliza la anteriorfunción de conversión de existir, o bien una función de conversión por defecto, sin intervención del usuario.

En cuanto a las funciones de conversión por defecto, éstas son aquellas que inicializan a un valor nuloaquellos datos miembros nuevos en la clase, mientras que asigna los valores de aquellos datos miembros compatibles(según la tabla 2) de los objetos (entre la antigua versión y la nueva versión de la clase).

int float double char char *

int assign assign atoi()

float assign assign assign atof()

double assign assign atod()

char cast cast cast

char * itoa() fcvt() fcvt() assign strcpy()

Tabla 2. Conversiones automáticas entre datos miembro compatibles.Acerca del resto de los valores para el argumento de evolución del esquema, SESplit implica que una copia

de la antigua versión de la clase (utilizando la AbbreviatedClassdef) es creada en el container donde residen losobjetos, eliminando la relación entre ambos containers. SEFail hace que el proceso de carga del container falle si sepresenta la necesidad de evolución del esquema, aunque la próxima vez que se cargue el container se tendrá de nuevola oportunidad de modificar los objetos. Si la clase de los objetos, en el container que se está cargando en memoria,ha sido eliminada de su container, entonces sólo se podrá elegir entre hacer que la carga falle o aplicar la opción querepresenta SESplit.

Un ejemplo de una situación que requeriría evolución del esquema se presenta a continuación. Es un ejemploorientativo sobre una pequeña aplicación que sigue el esquema de containers de datos/programa presentado aquí. Lasrespuestas del sistema se presentan en fondo inverso.

cd(/);mkdir(carshop);Barbados> carshop : directory;cd(Carshop);mkdir(data);Barbados> data : directory;mkdir(bin);Barbados> bin : directory;cd(bin);#define MAX 250class car {private:

int year;bool emission_filter;char plate[MAX];

public:int price;car(char * plate, int age, bool emission_filter = true);bool hasEmissionFilter(void) const { return emission_filter; }int getAge(void) { return year; }char * getPlate(void) { return plate; }void Print(ostream &o);

};Barbados>class car {}car::car(char * plate, int age, bool emission_filter = true){

strcpy(this->plate, plate);year = age;this->emission_filter = emission_filter;

}Barbados> car::car: function (ptr to char, int) returning void;void car::Print(ostream &o) {

o << plate << '", years: "<< getAge() << ", price: " << price << ((emission_filter)? "yes":"no") << endl;

}Barbados> car::Print: function (reference to ostream) returning void;cd(../data);/Common/structures/listOfPointers lcars;

Barbados> lcars: list;En el ejemplo, existen dos container, /carshop/data, y /carshop/bin, entre los que existe una

relación TypeClass ya comentada, al encontrarse los objetos en /carshop/data con sus clases en /carshop/bin.

En este escenario, debido a un cambio de legislación acerca de los coches sin filtros de gases, se decide que:

a) Habrá ahora dos campos de precio en la clase 'car'. El precio actualprice, privada y depende delvalor real del coche, y discountprice, que es revisada periódicamente para aplicar todos losposibles descuentos. Además, los precios, debido a la llegada del Euro, deben ser de tipo float, enlugar de tipo int.

b) La informacion acerca de emission_filter, no se necesita más, ya que el vendedor se deshará delos coches sin filtro de gases, o los pondrá a la venta a un precio muy bajo.

c) Así, todos los coches sin filtro de gases deben dividir su precio por dos, mientras que los coches conmás de 7 años y sin filtro deben dividir su previo por tres.

El programador entra en /carshop/bin y modifica la clase de la siguiente forma:cd(/carshop/bin);edit(car);class car {private:

float actualprice;int year;char plate[MAX];

public:float discountprice;car(char * plate, int age);int getAge(void) { return year; }char *getPlate(void) { return plate; }float getActualPrice(void) { return price; }void Print(ostream &o);

};Barbados>class car {}car::car(char * plate, int age, float price){

strcpy(this->plate, plate);year = age;actualprice = price;

}Barbados> car::car: function (ptr to char, int) returning void;void car::Print(ostream &o) {

o << getPlate() << ", years: "<< getAge() << ", price: " << (getActualPrice() – discountprice) << endl; }Barbados> car::Print: function (reference to ostream) returning void;

El sistema está recompilando la clase, hecho que se detecta cuando una clase con el mismo nombre ya existe.La antigua definición de clase se mantiene, y se busca en los containers abiertos en memoria cualquier objeto de esaclase, convirtiéndolo de ser encontrado. Como no se encuentra ninguno, no se toma ninguna acción.

Así, al contrario que en otros sistemas, [7][3], Barbados no ofrece ningún lenguaje especial para especificarcambios en clases. El programador puede cambiar la definición de la clase simplemente volviendo a teclearla oeditándola, como en el ejemplo. Los autores pensamos que la inclusión de un lenguaje auxiliar sería confusa y portanto contraproducente e innecesaria, al menos en nuestro sistema. El proceso que se toma en la evolución delesquema en el mismo container donde la clase existe es el mismo que cuando se detecta entre containers (aunque nohay opción de Split ni de Fail, lógicamente).

El programador entra ahora en el container de datos, donde sí existen objetos que necesitan ser actualizados.cd(/carshop/data);Barbados> class counter doesn’t match previous definition:<C>onvert, <S>plit, <F>ail: Cvoid convertInstance(car$$_old * oldcar, car * newcar){

newcar->year = oldcar->year;strcpy(newcar->plate, oldcar->plate);discountprice = 0;// newcar->actualprice = 0;newcar->actualprice = oldcar->price;if (!(oldcar->emission_filter))

if (newcar->year < 1995)newcar->discountprice = (oldcar->price * 2)/ 3;

else newcar->discountprice = oldcar->price / 2;}Barbados> Conversion finished.

Este proceso ocurre al detectar la asincronía entre los objetos de este container -/carshop/data- con suclase 'car', definidas en /carshop/bin. Al usuario, al ser la primera vez que se realiza una conversión en estaclase, se le presenta una función de conversión por defecto (en fondo inverso en el ejemplo). El usuario puedemodificar esta función según lo considere necesario, incluso eliminando toda la parte aportada por el sistema. Estafunción de conversión será almacenada, para futuros usos (futuras conversiones), en el container que almacena laclase 'car', /carshop/bin.

Los objetos en el container son convertidos creando una nueva copia de los mismos y aplicando a esa copia(junto con la antigua) la función de conversión. Ésto sucede únicamente al ser cargado en memoria, lo que demuestralas ventajas de este sistema: los containers no son convertidos hasta que es realmente necesario, aunque todos susobjetos se convierten inmediatamente, una vez detectada esa necesidad. De ahí que nuestra aproximación sea mixtaentre ambas estrategias. Obviamente, los containers (no todo el sistema) estarán fuera de servicio mientras laconversión es efectuada, pero ésta tiene lugar sobre un conjunto de containers, y no sobre todo el almacenamientopersistente. Lo cuál supone una diferencia considerable, así como una necesidad de tiempo de proceso mucho máspequeña..

2.2. Convirtiendo objetos en un containerUna vez que se detecta la necesidad de evolución del esquema, el proceso a seguir debe intentar poner el

container en modo de lectura y escritura. Si ésto no es posible (debido a un bloqueo de escritura de otro proceso),entonces el proceso de evolución del esquema debe fallar, con un código de error apropiado. Por tanto, una vez queel proceso de conversión comienza, ningún otro proceso puede acceder a ese container.

El proceso crea en su inicio, dos tablas, las tablas de clases afectadas y la tabla de localizaciones. La primerase refiere a las clases que se han visto afectadas por la evolución (lo cuál debe incluir todas sus subclases), mientras lasegunda se utilizará para actualizar todas las referencias a los objetos que sean movidos (por no poder seracomodados con su nuevo tamaño en su antigua posición) en memoria. Entonces comienza la búsqueda de la primerainstancia. Si se encuentra un objeto, se intenta buscar en el directorio .conv_functions del container de la claseuna función de conversión. En el caso de encontrar una, entonces será usada bien como plantilla para ser presentadaal usuario como función de conversión, bien como función de conversión (en el caso de conversiones no interactivas).Si no se encuentra una función de conversión, se crea una por defecto que inicializa todos los nuevos datos miembrosa valor nulo, mientras que asigna los datos miembros compatibles (según la tabla 2) entre sí.

Las funciones de conversión utilizan una nomenclatura especial para los argumentos formales: el nombre dela clase antigua es sustituido por ése mismo nombre más un sufijo '_$$old'. Ésta forma de referirse a los argumentosestá inspirada en el trabajo realizado en PJama por parte de Dmitriev [7][8]. En realidad, éste es el nombre que seasigna a las definiciones de las clases representando a las versiones antiguas, de forma que la función pueda referirse aellas normalmente. Nótese que si la evolución sucede entre containers, entonces se crea la antigua definición de clasea partir de la definición abreviada de clase comentada anteriormente. Si la evolución sucede en un único container,entonces la definición de clase representando la versión antigua ya existe y sólo debe ser renombrada siguiendo elpatrón dado.

Por otra parte, las funciones de conversión deben ser marcadas como funciones amigas1 (friend functions) delas clases que deben ser convertidas, así pueden romper la encapsulación y acceder a los miembros privados de lasclases que se convierten

1Barbados soporta C++, y las funciones “amigas” son un recurso propio de C++. Otros mecanismos similares existenen otros lenguajes. De no existir esta posibilidad de violación de la encapsulación por parte de las funciones deconversión sería necesario introducirla para hacer posible la conversión.

En el proceso de conversión (creando los nuevos objetos y eliminando los antiguos) no se utilizan losconstructores/destructores de los mismos. Hacer esto podría suponer problemas debido a que posiblemente losobjetos liberen (reclamen) algún recurso en su destructor (constructor). Éste problema haría inviable la conversión.

Finalmente, este algoritmo es seguro en términos de confiabilidad. El proceso de conversión volverá a serlanzado de nuevo en caso de que sea interrumpido en su proceso por algún fallo del sistema. Ésto sucederá aldetectarse de nuevo la asincronía entre los objetos y su clase, ya que las modificaciones a un container no se hacenefectivas hasta que dicho container es almacenado correctamente. Ello supone que el la evolución del esquema seejecuta completamente o no se lleva a cabo en absoluto.

3. Trabajo relacionadoDe los sistemas persistentes modernos, PerDis [22] es probablemente el más cercano en arquitectura, al

utilizar un sistema de clusters independientes, similar al de containers, aunque destaca la ausencia de la metáfora desistema de ficheros utilizada en Barbados. Por otra parte, los autores de PerDis lo declaran como un middleware, esdecir, como un conjunto de librerías más un runtime. Que los autores del presente trabajo sepan, PerDis no ofrecesoporte para la evolución del esquema.

JSpin es otro sistema de programación persistente moderno basado en Java [17]. El interés de JSpin radicaen su capacidad de aglutinar distintos lenguajes entorno a un mismo almacenamiento persistente, con el mismo nivelde capacidad de consulta y modificación del almacenamiento. Así, una clase creada en C++ puede ser utilizada porobjetos Java. De JSpin se ofrece un trabajo teórico acerca del impacto de modificación de clases en el lenguaje Java.

PJama es probablemente el sistema de programación persistente ortogonal más avanzado en cuanto aevolución del esquema [7][8]. Soporta tanto evolución del esquema como aplicación de modificaciones a todos losobjetos de una clase (bulk modification), a través de una herramienta de conversión. PJama, al igual que JSpin, noposee entorno de programación integrado.

Otro proyecto relacionado con Java es Persistent Java [21], si bien sólo presenta, por el momento, unestudio teórico sobre la viabilidad de evolución del esquema en sistema.

4. Conclusiones y trabajo futuro

En este artículo, una aproximación a la solución el problema de la evolución del esquema es presentada parael modelo basado en containers, concretamente para Barbados, prototipo que implementa dicho modelo.

Encontramos que el modelo de containers supone una ayuda a la hora de diseñar una solución a dichoproblema, ya que, de una manera natural, lleva a una solución mixta inmediata/tardía muy útil, nóvel hasta ahora eneste campo.

El trabajo futuro conlleva, claro está, la implementación de este modelo de evolución del esquema (hastaeste momento, se encuentra implementado parcialmente, aceptando cambios simples en clases). Otro recursorelacionado con la evolución del esquema es el de migración, que permite trasladar los objetos de una clase a otracompatible (normalmente una subclase o una subclase). La migración todavía no ha sido estudiada en el marco denuestro modelo.

5. Bibliografía

[1] Atkinson M.P., Morrison R. (1986) “Integrated Persistent Programming Systems.” In Proc. 19th InternationalConference on Systems Sciences, Hawaii (1986) pp 842-854.

[2] Atkinson, M.P. & Morrison, R. (1995) “Orthogonally Persistent Object Systems”. VLDB Journal v4, v3 pp 319-401.

[3] Brown, A. W. (1991). “Object Oriented Databases”. McGraw-Hill. Intl. Series in Software Engineering. ISBN 0-07-707247-2.

[4] Cattel, R. (editor) (2000). “The Object Data Standard: ODMG 3.0”, Morgan Kaufman, Menlo Park (Calif.).ISBN 1-55860-647-5.

[5] Cooper, T.B. (1997). “Barbados: an Integrated Persistent Programming Environment". Ph.D. thesis. BasserDept of Computer Science, Sidney University.

[6] Cooper, T.B., Wise M., (1995). "The Case for Segments", Proceedings of Intl Workshop on Object OrientedOperating Systems (IWOOS’95).

[7] Dmitriev, Misha (1999). “The First Experience of Class Evolution Support in PJama”. In Proceedings of the thirdPersistence for Java Workshop.

[8] Dmitriev, M. Atkinson, M. (1999). “Evolutionary Data Conversión in the Pjama Persistent Language”. InProceedings of the Object Oriented Databases Workshop held during the European Conference on ObjectOriented Programming.

[9] Ferrandina, F., Ferran, G. (1995). “Schema and Database Evolution in the O2 Object Database System”.Proceedings of the 21st Very Large Databases in Zürich.

[10] Ferrandina F., Meyer T., Zicari R.(1994). “Correctness of Lazy Database Updates for an Object DatabaseSystem”. In Proc. of the 6th Int'l Workshop on Persistent Object Systems.

[11] García Perez-Schofield, B., Cooper,. T., Roselló, E., Pérez Cota, M. (2001). “Extending Containers to Addressthe Main Problems of Persistent Object-Oriented Operating Systems: Clustering, Memory Protection and SchemaEvolution.”. In proceedings of the Workshop on Object Orientation and Operating Systems held during theECOOP conference in Budapest, June 2001.

[12] García Perez-Schofield, B., Cooper,. T., Roselló, E., Pérez Cota, M. (2001b). “Barbados: Design of thePersistence Mechanisms”. Technical Report in the Department of Informatics.

[13] García Perez-Schofield, B., García Roselló, E., Cooper, T., Cota, M. (2001c). “Swizzling en sistemas basadosen containers: Container-Name Swizzling”. In proceedings of the Octavo Congreso Internacional de CienciasComputacionales (CIIC’01). México.

[14] García Perez-Schofield, B., García Roselló, E., Cooper, T., Cota, M. (2001d). “Rendimiento en sistemasbasados en containers”. en Actas de las Jornadas de Ingeniería del Software y Bases de Datos (JISBS'2001).España (Spain).

[15] García Perez-Schofield, B., Cooper,. T., Roselló, E., Pérez Cota, M. (2002). “First impressions about executingreal applications in Barbados”. In proceedings of the Workshop on Object Orientation and Operating Systemsheld during the Intl. European Conference on Object-Oriented Programming (ECOOP'2002) in Málaga, España(Spain), June 2002.

[16] Jensen C.S., Clifford J., Gadia S.K., Hayes P., Jajodia S. (1998). “The consensus glossary of temporal databaseconcepts”. In O. Etzion, S. Jajodia, S. Sripada (eds.) Temporal databases-Research and practice, pp: 367-405.Springer-Verlag, LNCS nº 1399.

[17] Kaplan A., Ridyway, J.H.G., Schmerl, B.R. (2000). “Toward Polylingual Persistence”. In Proceedings of theNinth International Workshop on Persistent Object Systems. Pp 202-217.

[18] Knasmüller, M. (1997). “Adding Schema Evolution to the Persistent Development Environment Oberon-D”.Technical Report #10, Institute for Computer Science, Johannes Kepler University.

[19] Kirby, G., Morrison, R. (1998). “A Persistent View of Encapsulation”. Chapter in Computer Science 98, a bookedited by Springer-Verlag.

[20] Kim, W., Ballou, N., Chou, H., Garza, J., Eowlk, D. (1991). “Features of the ORION Object Oriented DatabaseSystem”. Chapter 11 in Brown, A. (1991) “Object Oriented Databases” . McGraw-Hill.

[21] Ridgway, J., Wielden, J.C. (1998). “Toward Class Evolution in Persistent Java”. In proceedings of ThirdPersistence and Java Workshop.

[22] Shapiro, M. Ferreira, P., Richer, N. (2000). “Experience with the PerDis large-scale data-sharing middleware.”In proceedings of the Workshop on Persistence Object Systems.

[23] Sousa, P. Alves Marques, J. (1994). “Object Clustering in Persistent and Distributed Systems”. 6th Workshop onPersistent Object Systems, pp 402-414.

[24] Tan L., Katayama T. (1989). “Meta operations for type management in object-oriented databases - a lazymechanism for schema evolution”. In Proc. First International Conference on Deductive and Object-OrientedDatabases, DOOD `89., Kyoto, Japan. W. Kim, J.-M. Nicolas and S. Nishio (eds.). North-Holland. Pp241-258.

[25] Tsangaris, M., Naughton, J. (1992). “On the Performance of Object Clustering Tecniques”. In Proceedings ofthe ACM Sigmod Intl. Conference of Management of Data, in San Diego, USA, June 2-5.