Introducción A RMS

Introducción a RMS
El RMS (Record Management System o Sistema de

Gestión de Registros) es un mecanismo que proporciona
la especificación MIDP para conseguir que los MIDlet
almacenen información de forma persistente entre
distintas ejecuciones. La información será guardada en
una zona de memoria del dispositivo dedicada para este
propósito. La cantidad de memoria, así como la zona
asignada para ello dependerán de cada dispositivo. RMS
se diseñó pensando en la importancia de un sistema de
almacenamiento para los MIDlet, pero teniendo en
cuenta las limitaciones propias de un MID.
El concepto fundamental en RMS es el de RecordStore, que puede interpretarse como un

almacén de registros de información. Haciendo una analogía con las bases de datos, un
RecordStore equivale a una tabla dentro de un modelo de datos. Algunas de sus
características principales son:
1. Persistencia entre ejecuciones: Un RecordStore le proporciona a los MIDlet la

posibilidad de almacenar información persistente entre diferentes ejecuciones. Es
responsabilidad del MID guardar la información y mantener su integridad durante
las operaciones de uso normales (arranque, llamadas, descarga de batería,...), así
como proporcionar el lugar de almacenamiento, que debe ser transparente para
las aplicaciones.
2. Asociados a suites del MIDlet: Una suite de MIDlet puede tener asociados varios
RecordStore (varias tablas) que sean compartidos por todos los MIDlet incluidos en
ella. Al eliminar una suite se produce el borrado de los RecordStore asociados (ya
que no tiene sentido mantenerlos cuando no son accesibles desde ninguna otra
suite). De cierta forma, el conjunto de RecordStore de una suite es equivalente a
su modelo de datos.
3. Identificador único y control de versiones: Cada RecordStore posee un nombre
único dentro de la suite (aunque diferentes suites pueden utilizar el mismo
nombre de RecordStore). Además, un RecordStore tiene asociado un campo de
fecha y hora de la última actualización (conocido como marca temporal o time
stamp), y otro de número de versión, actualizado con cada cambio que se efectúa.
Esta información permite la correcta gestión de la información almacenada tanto
por los MIDlet como por la implementación.
4. El otro concepto clave al hablar de RMS es el de registro. Un registro en RMS es
un vector de bytes de longitud variable, asociado con un identificador numérico,
que se almacena en un RecordStore. Si comparamos con una base de datos, un
registro RMS equivaldría a un registro dentro de una tabla, con una estructura
bastante sencilla: un campo identificador y un campo de información con formato
de vector de bytes.
Las propiedades de estos almacenes de registros son:
1. Cada RecordStore puede estár compuesto por ningún, uno o más registros.
2. Los nombres de RecordStore son sensibles a mayúsculas y minúsculas y están
formado por un máximo de 32 caracteres con codificación Unicode.
3. Dentro de una suite no puede existir más de un RecordStore con el mismo
nombre.
4. Si una suite de MIDlets es borrada del dispositivo MID, se borrarán todos los
RecordStore pertenecientes a esa suite.
5. Un MIDlet puede acceder a un RecordStore creado por otra suite, siempre que
ésta de permiso para ello.
Estructura de la API de RMS
La API de RMS cuenta tan solo con apenas diez componentes, incluyendo clases e
interfaces, que se agrupan en el paquete javax.microedition.rms.
Pueden distinguirse tres tipos de clases dentro de RMS:
1. La clase RecordStore: Es la más importante del paquete y proporciona todos los

métodos necesarios para manejar un RecordStore y sus registros asociados.
2. Interfaces de soporte: RecordEnumeration, RecordComparator, RecordFilter y
RecordListener son interfaces que definen métodos que ayudan a manejar el
RecordStore. Los tres primeros facilitan la navegación por los registros,
permitiendo ordenar y filtrar la selección entre ellos. Por otra parte,
RecordListener permite crear manejadores de eventos, asociados a las
modificaciones realizadas en un RecordStore.
3. Excepciones: RMS proporciona también un conjunto de excepciones específicas
para tratar las situaciones anómalas que puedan presentarse durante la ejecución
de un programa, tratando desde el acceso a un RecordStore que está cerrado
hasta la falta de espacio de almacenamiento.
Métodos generales de la RecordStore
La clase RecordStore representa un conjunto de

registros de información, que los MIDlet usan como
mecanismo de almacenamiento persistente entre
distintas ejecuciones. La clase RecordStore
proporciona diversos métodos para facilitar el acceso y
la gestión de toda esta información, permitiendo
desde la creación de registros hasta su eliminación,
pasando por operaciones de lectura y modificación.
Los métodos pueden dividirse en cuatro grupos:
métodos generales, operaciones básicas con registros, desplazamiento entre registros y
gestión de eventos.
Los métodos generales nos permiten crear, cerrar y obtener información de un

RecordStore. Además, están incluidos métodos de clase (no asociados a ningún objeto)
para obtener una lista de los RecordStore existentes en el MID y permitir el borrado de
estos almacenes de información.
No existe un método constructor para la clase RecordStore, sino que se proporciona un

método de clase openRecordStore(), que abre un RecordStore o lo crea en caso de que no
exista. Una vez que se ha abierto un RecordStore, pueden realizarse sobre él varias
operaciones relacionadas con registros (operaciones básicas con registros) finalizando
mediante una llamada a closeRecordStore(), que lo cierra.
Hay métodos que devuelven información sobre el RecordStore. Las siguientes

propiedades tienen métodos proporcionados por la API:
1. Nombre: El nombre único que los RecordStore tienen asociados dentro de cada
suite puede obtenerse con el método getName().
2. Versión: El número de versión (un entero positivo) que tiene asociado un
RecordStore, se actualiza con cada operación de modificación realizada sobre él.
Este valor cobra una importancia especial en entornos donde varios MIDlet de la
misma suite accedan a un mismo RecordStore, y tengan que saber si se han
producido o no modificaciones. El acceso al número de versión se realiza con el
método getVersion().
3. Fecha y hora de la última modificación: La propiedad que almacena la fecha y
hora de la última modificación del RecordStore, está en formato de entero largo
(milisegundos transcurridos desde el 1 de enero de 1970) y es accesible mediante
el método getLastModified().
4. Tamaño: El número de bytes del espacio de almacenamiento ocupados por el
RecordStore incluye tanto el espacio ocupado por los registros como por las
estructuras de datos asociadas, y se obtiene mediante el método getSize().
5. Espacio libre: El espacio libre disponible en bytes para añadir más registros al
RecordStore se obtiene mediante una llamada a getSizeAvailable().
Operaciones básicas con registros
La utilidad principal de un
RecordStore consiste en las posibilidades que ofrece para almacenar y gestionar registros
de información. Las operaciones que proporciona incluyen la inserción y eliminación de
registros, su modificación y su lectura.
Hay que tener en cuenta las siguientes observaciones al trabajar con registros:
Al añadir un registro a un RecordStore, este recibe un identificador único (un entero

positivo), que es devuelto por el método addRecord(). El primer registro recibe como
identificador el valor 1, y los sucesivos registros al insertarse van aumentando dicho valor
en una unidad, no pudiendose reutilizar cuando se producen operaciones de borrado. Con
este identificador, es posible acceder de forma directa a cualquier registro.
No existe ningún mecanismo de bloqueo del acceso a los registros proporcionado por los
RecordStore. La especificación tan solo asegura que las operaciones se realizan de forma
secuencial, síncrona y atómica. El programador tiene la responsabilidad de establecer los
mecanismos de bloqueo necesarios para mantener la consistencia de datos cuando varios
threads acceden simultáneamente al mismo RecordStore.
Los métodos más importantes son los que permiten manejar los registros directamente,
usando vectores de bytes para almacenar información.
Resulta más conveniente trabajar con la clase Stream en lugar de usar vectores de bytes.
Esta clase se encarga de la conversión de los formatos, permitiendo al programador
trabajar directamente con los tipos de datos utilizados originalmente por el programa
(string, int, long...).
Desplazamiento entre registros de un RecordStore
Esta es la más potente de las funcionalidades que proporciona el RMS. Para ello, la
especificación tiene definida la interfaz RecordEnumeration cuyos métodos proporcionan
facilidades para moverse por los registros de un RecordStore.
Para poder usar los métodos de RecordEnumeration necesitamos obtener previamente un

objeto que implemente esta interfaz. La clase RecordStore nos ofrece un método
específico (enumerateRecord) para devolver objetos de este tipo. Un objeto
RecordEnumeration obtenido así mantiene internamente una lista de identificadores de
los registros del RecordStore, incluyendo un puntero que permite un desplazamiento
bidireccional rápido.
Puede decidirse que registros del RecordStore aparecen en RecordEnumeration utilizando

la interfaz de RecordFilter, filtrando así los registros no deseados. Por otra parte, es
ordenar los registros del RecordStore que aparecen en RecordEnumeration según ciertos
criterios. Para esto se hace uso de la interfaz RecordComparator.
Gestión de eventos de un RecordStore
En ocasiones interesa realizar acciones asociadas a los cambios producidos en un

RecordStore. Para esto RMS proporciona una interfaz, RecordListener, que permite crear
manejadores de eventos asociados a un RecordStore. Se pueden añadir y eliminar
manejadores del RecordStore. Los manejadores asociados a un RecordStore permiten un
mantenimiento de la consistencia de la información entre distintas operaciones. Estos son
los elementos que ofrece el paquete javax.microedition.rms para la gestión de la
información persistente de un MIDlet.
ACTIVIDAD:
Utilizando la interfaz de alto nivel, crea una suite con 2 MIDlets, de forma que una de ellas
solicite ciertos datos (por ejemplo el nombre) al usuario y los guarde en un RecordSet,
mientras que la otra MIDLET busca esos datos y los muestra en pantalla si existen. Haz el
ejercicio en pareja de forma que cada persona se encargue de hacer una MIDlet de forma
independiente, y al final corregir juntos si surge algún problema de compatibilidad.
Publicad el resultado final de la actividad en gplanet y compartidlo en vuestra zona de
gplanet.
Acceso a redes desde MIDP
Un dispositivo que ocupa poco espacio y permite además comunicarse en cualquier

momento y lugar abre un abanico de posibles aplicaciones que no se pueden disfrutar en
un PC de sobremesa, ni siquiera en un ordenador portátil.
El enorme potencial de los dispositivos MID es la posibilidad de conectarse en cualquier

momento y transferir cualquier tipo de información mientras dure la conexión.
Ge
neric Connection Framework
Hay que destacar dos problemas que hacen dificil la tarea de proporcionar conectividad
en un entorno de recursos tan limitados como son los dispositivos con configuración
CLDC:
1. La API de conectividad de J2SE (java.io.* y java.net.*): tiene un tamaño demasiado

grande para ajustarse a las limitaciones de memoria de los dispositivos contenidos
en la especificación CLDC.
2. Existe una gran variedad de dispositivos móviles con capacidades y protocolos de
conectividad diferentes, dependiendo en gran medida de las infraestructuras
inalámbricas disponibles, y este número no deja de aumentar.
A esto hay que añadir además ciertas restricciones propias de la filosofía de diseño de
J2ME, como son la definición de interfaces de programación sencillas y estables y la
supresión de ambigüedades que abran la puerta a incompatibilidades entre programas. El
resultado final fue la definición de una nueva API, el Marco Genérico de Conexión,
también conocido como Generic Connection Framework (GCF), basado en:
1. Una abstracción del concepto de conexión, que oculta al programador los detalles
concretos de los distintos protocolos, en lugar de múltiples clases adaptadas a
diferentes protocolos y mecanismos de comunicación.
2. Localización del núcleo del GCF en la capa de configuración y su composición de
elementos genéricos, sin sugerir ni proporcionar protocolos de comunicación
específicos. Los perfiles son quienes extienden el GCF con interfaces adicionales y
proporcionan implementaciones concretas de protocolos.
Estructura de la Generic Conection Framework
El GCF se basa en el concepto de conexión, que se puede definir como un canal de

comunicación, con independencia del protocolo de bajo nivel usado. Las conexiones se
crean mediante una única llamada al método estático open() de la clase Connector.
Esta llamada hace que la clase Connector devuelva un objeto que implementa una de las
interfaces genéricas de conexión definidas en el GCF, con capacidad de manejar el
protocolo seleccionado.
En la imagen superior se muestra la jerarquía de las interfaces de conexión del GCF

incluidas en el CLDC.

Introducción A RMS

Cargado por

Copyright:

Formatos disponibles

Introducción A RMS

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Introducción A RMS

Cargado por

Copyright:

Formatos disponibles

Introducción a RMS

El RMS (Record Management System o Sistema de

El concepto fundamental en RMS es el de RecordStore, que puede interpretarse como un

1. Persistencia entre ejecuciones: Un RecordStore le proporciona a los MIDlet la

Estructura de la API de RMS

Pueden distinguirse tres tipos de clases dentro de RMS:

1. La clase RecordStore: Es la más importante del paquete y proporciona todos los

Métodos generales de la RecordStore

La clase RecordStore representa un conjunto de

Los métodos generales nos permiten crear, cerrar y obtener información de un

No existe un método constructor para la clase RecordStore, sino que se proporciona un

Hay métodos que devuelven información sobre el RecordStore. Las siguientes

Operaciones básicas con registros

Al añadir un registro a un RecordStore, este recibe un identificador único (un entero

Desplazamiento entre registros de un RecordStore

Para poder usar los métodos de RecordEnumeration necesitamos obtener previamente un

Puede decidirse que registros del RecordStore aparecen en RecordEnumeration utilizando

Gestión de eventos de un RecordStore

En ocasiones interesa realizar acciones asociadas a los cambios producidos en un

Acceso a redes desde MIDP

Un dispositivo que ocupa poco espacio y permite además comunicarse en cualquier

El enorme potencial de los dispositivos MID es la posibilidad de conectarse en cualquier

1. La API de conectividad de J2SE (java.io.* y java.net.*): tiene un tamaño demasiado

Estructura de la Generic Conection Framework

El GCF se basa en el concepto de conexión, que se puede definir como un canal de

En la imagen superior se muestra la jerarquía de las interfaces de conexión del GCF

También podría gustarte