Integraci´ on en la arquitectura

Las funciones del componente de acceso al medio est´an claramente divididas. Por un lado, el proceso de acceso f´ısico se encarga de manejar los aspectos relacionados con la localizaci´on de los contenidos f´ısicos. Complementariamente, el proceso de decodificaci´on/demultiplexaci´on se encarga de realizar dichas tareas y de manejar los mecanismos de optimizaci´on mediante el uso de una cachede fotogramas. Esta divisi´on queda patente en la figura 3.17 y motiva la separaci´on de la funcionalidad en dos m´odulos independientes.

La integraci´on de dichos m´odulos en la arquitectura se ilustra en la figura 3.18. Se muestra como la divisi´on funcional exige la distribuci´on del proceso de gesti´on de acceso al contenido en varios componentes independientes (marcados en la figura con color azul): a nivel de framework global, a nivel de cada nodo y a nivel de cada componente. Cada uno cumple con una fracci´on de las responsabilidades conjuntas de la capa de acceso. Las siguientes secciones detallan que funci´on realiza cada uno.

Acceso f´ısico al contenido

La organizaci´on de los contenidos multimedia est´a sujeta a numerosos requisitos, muchos de ellos propios de las normas espec´ıficas de organizaciones y proyectos. En todos los casos, las exigencias de espacio requieren la distribuci´on de los contenidos en varios soportes inter- conectados. La arquitectura requiere la existencia de un paradigma de ´arbol de directorios ´

unico para esta diversidad, cuya creaci´on es posible en la mayor´ıa de los sistemas operativos actuales.

La tecnolog´ıa RAID (Redundant Array of Independent/Inexpensive Disks) [23] permite la uni´on de varios soportes de almacenamiento para formar un ´unico soporte virtual. RAID permite mejorar la paralelizaci´on de lecturas/escrituras, ya que diferentes ´areas del disco virtual pueden utilizarse concurrentemente, y adem´as mejora la fiabilidad, ya que un fallo hardware en uno de los soportes no afecta a los datos de los dem´as. La naturaleza de RAID es puramente local, siendo necesario que los discos se conecten al bus RAID directamente. Diferentes “niveles” se han definido en el est´andar RAID, en funci´on de las necesidades de cada sistema. Cada nivel abarca una franja del espectro que va desde la fiabilidad m´axima (todos los disco se emplean como espejos para garantizar el funcionamiento en presencia de fallos) hasta el rendimiento/capacidad m´axima(ning´un disco act´ua de espejo, sino que todos guardan datos distintos ofreciendo la imagen de un disco virtual mucho m´as grande y r´apido). El uso ´unico de RAID no permite la abstracci´on local de sistemas de ficheros remotos, solo accesible a partir de soluciones de almacenamiento en red. En la actualidad existen

Nodo

Middleware

Framework local

Gestor Contenido LAN

NFS SAMBA .... Gestor Contenido Local Gestor Framework API Decod Componentes API Decod Componentes

Figura 3.18: Distribuci´on de los componentes b´asicos de la capa de acceso.

numerosos sistemas de almacenamiento en red. Los sistemas de ficheros ofrecidos por sistemas operativos de red, como Sprite [145] o AFS [167], son una primera alternativa. En ´esta, el sistema de ficheros est´a distribuido en varios servidores, requiriendo complejos mecanismo de sincronizaci´on entre servidores y clientes que garanticen la integridad del sistema. AFS ha servido como base a otros sistemas de ficheros en red, como DCE [56] o Coda [166], centrados en mejorar las carencias de AFS en cuanto a escalabilidad y disponibilidad cuando los servidores fallan.

Los sistemas de ficheros distribuidos forman parte de sistemas operativos determina- dos, siendo necesario la utilizaci´on de estos en todos los nodos del sistema. La necesidad de heterogeneidad motiva la utilizaci´on de protocolos comunes en la generalidad de siste- mas operativos actuales, como los omnipresentes NFS y SAMBA. Las necesidades de cada aplicaci´on en t´erminos de distribuci´on de datos, necesidades de fiabilidad, heterogeneidad, disponibilidad, . . . determinaran la aproximaci´on m´as adecuada.

El m´odulo de acceso al contenido se implementa como un servicio CORBA del framework global, etiquetado como Gestor Contenido en la figura 3.18. El servicio CORBA de acceso al contenido ofrece metadatos sobre los posibles protocolos de acceso al ´arbol remoto y su consiguiente identificador y otros datos de acceso. Cada nodo debe montar localmente el ´

arbol de directorios para acceder con el paradigma habitual de acceso a fichero. Los siste- mas operativos de ambas m´aquinas se encargan de transportar los contenidos de manera transparente a las aplicaciones que se ejecuten en dicho nodo.

Es importante resaltar el hecho de que las aplicaciones utilizan nombres de fichero relati- vos al directorio ra´ız de este ´arbol. Gracias a ello, las aplicaciones no dependen de la ruta en la que el ´arbol ha sido montado en el sistema local, y que puede variar en funci´on del sistema operativo o de la m´aquina en la que se ejecuta en un momento dado dicha aplicaci´on (y que, gracias a la flexibilidad de la arquitectura, puede cambiar). El nombre relativo utilizado para acceder al contenido es completado por el subproceso deconfiguraci´on de acceso multimedia que se describe en la secci´on 3.5.3.

Demultiplexaci´on y decodificaci´on

La funcionalidad de este m´odulo se divide en funci´on de su car´acter. Por un lado, cada nodo ejecuta un servidor de optimizaci´on local (Gestor Contenido Local en la figura 3.5.3), encargado de gestionar la cache. Por otro lado, cada componente debe ser capaz de acceder al contenido individualmente (API Decod en la figura 3.5.3), ya que la existencia de dicha cache no garantiza la presencia del fotograma requerida dentro de ella. La divisi´on da lugar a dos componentes de la arquitectura separados, que colaboran para facilitar los objetivos de este proceso.

El servidor de optimizaci´on local se implementa como un servicio CORBA asociado al nodo. Este servicio realizar´ıa las funciones de los procesosacceder a fotogramayconfiguraci´on de acceso multimediade la figura 3.17. La aplicaci´on suministra el identificador del contenido al que desea acceder al segundo de estos subprocesos. El identificador debe especificar las regiones temporales a las que se desea el acceso (contemplado en el est´andar URI). Mediante esta llamada, el nombre relativo que maneja la aplicaci´on se convierte en un nombre absoluto, v´alido para el acceso f´ısico al contenido dentro del nodo en el que se est´a ejecutando. La informaci´on del identificador se almacena en un diccionario local, que guarda registro de todos los contenidos (y regiones temporales) a los que todas las aplicaciones locales han pedido acceso. Utilizando esta informaci´on, el subproceso acceder a fotograma realiza la optimizaci´on del proceso. Para ello, cuando una aplicaci´on pide acceso a un fotograma se sigue el siguiente proceso:

pedido por la aplicaci´on, y que viene definido por su timestamp de visualizaci´on (el momento exacto de tiempo en el que debe ser mostrado al usuario).

2. Obtenci´on del fotograma a trav´es del medio: si la b´usqueda en la cache fracasa, se utiliza el subprocesodemultiplexaci´on y decodificaci´on para obtenerlo a partir del contenido original.

3. Actualizaci´on de la cache: Mediante la informaci´on contenida en el diccionario local de accesos, se puede inferir qu´e aplicaciones requieren un determinado fotograma en funci´on de sutimestamp. Una vez un fotograma de la cach´e ha sido entregado a todas las aplicaciones que pidieron su uso, se elimina de la cache. En el caso de que se genere un nuevo fotograma, se comprueba si m´as aplicaciones han pedido su uso, almacen´andose en la cache en caso positivo

El subproceso demultiplexaci´on y decodificaci´on multimedia en cada componente se im- plementa como un API del framework local ofrecido a componentes y aplicaciones. Ante la ausencia del fotograma en la cache el acceso real al contenido se realiza por un complejo m´odulo software encargado de la demultiplexaci´on/decodificaci´on. Las responsabilidades de este m´odulo son completamente independientes de la arquitectura y, por lo tanto, pueden ser aprovechadas en otras aplicaciones. Esta capa de software se convirti´o, finalmente, en el proyecto Fobs, cuyas funciones e implementaci´on se detallan en el cap´ıtulo 4.

3.6.

Gesti´on de anotaciones

La gesti´on de anotaciones permite a las aplicaciones interactuar con los metadatos aso- ciados a los contenidos multimedia existentes en la arquitectura. Los metadatos son el centro del ciclo de vida multimedia; todos los procesos de ´este utilizan y actualizan esta informa- ci´on. En la arquitectura propuesta se ofrece un gestor de anotaciones, representaci´on de ´este concepto abstracto en el modelo software real. Los componentes y aplicaciones integrados en la arquitectura utilizan este servicio para lograr acceso a los metadatos, tanto de lectura como de escritura y actualizaci´on.

Los procesos del ciclo de vida se dividen generalmente en tres etapas funcionales bien definidas y acotadas. En la primera, el proceso accede a los metadatos y busca informaci´on relativa a las caracter´ısticas propias de ´este. En la segunda etapa, el proceso utiliza la in- formaci´on de los metadatos y, opcionalmente, el propio contenido para generar una serie de resultados. En la ´ultima etapa, dichos resultados son incluidos como parte de los metadatos, complementando la descripci´on global del contenido. A pesar de que no todos los procesos siguen este patr´on de manera tan fiel, en la mayor parte de los casos estas tres etapas se realizan complementadas con otras y con posibles variaciones en su orden.

Seg´un este modelo de proceso del ciclo de vida multimedia, el papel de los metadatos es el de elemento de sincronizaci´on. Los procesos son meros consumidores y productores de metadatos y todos sus resultados son almacenados en ´estos. La concurrencia de procesos puede, en definitiva, controlarse al nivel de metadatos por ser el ´unico recurso mutable compartido entre ellos.

Las funciones principales del gestor de anotaciones son, por tanto, dos: facilitaci´on del acceso a los metadatos, con independencia de su localizaci´on y distribuci´on, y sincronizaci´on en el acceso a ´estos por los diferentes componentes funcionales del sistema. En esta secci´on se describen las tecnolog´ıas inform´aticas utilizadas para lograr la creaci´on de este compo- nente, su integraci´on como servicio dentro de la arquitectura y las facilidades ofrecidas a componentes y aplicaciones para el acceso directo a metadatos.

3.6.1.

Acceso a anotaciones

En el cap´ıtulo 1 se define el concepto de metadatos y su funci´on central en el ciclo de vida multimedia. Las aplicaciones de an´alisis y procesamiento toman como entrada metada- tos y contenidos para generar nuevos metadatos ´utiles para el resto de aplicaciones, como distribuci´on, consulta, . . . . En dicho cap´ıtulo se introduce el esfuerzo m´as ambicioso de es- tandarizaci´on de los metadatos, MPEG-7 y su extensi´on MPEG-21, enfocado a permitir la interoperabilidad entre todos los agentes presentes en el contexto multimedia: productores, proveedores y consumidores.

Los est´andares de anotaci´on del grupo MPEG, utilizados en la arquitectura propuesta, est´an implementados sobre el lenguaje XML. Cada descripci´on es, por tanto, un documento XML; su almacenamiento, manejo, b´usqueda y acceso est´an delimitados por ´este hecho. La proliferaci´on de las aplicaciones basadas en documentos XML ha motivado que la industria inform´atica haya creado un paradigma para su manejo en analog´ıa a las bases de datos relacionales cl´asicas: las bases de datos XML nativas.

Caracter´ısticas de las bases de datos XML nativas

Una base de datos XML nativa tiene como unidad fundamental de almacenamiento l´ogico un documento XML, al igual que en una base de datos relacional tiene como unidad funda- mental de almacenamiento l´ogico a cada fila de una tabla. El modelo de almacenamiento f´ısico es independiente de esta vista l´ogica; la pr´actica m´as habitual es aprovechar las facilidades de las bases de datos relacionales existentes o, preferiblemente, utilizar un formato propietario enfocado a mejorar la indexaci´on y compresi´on de los documentos XML que contiene.

Las bases de datos XML nativas est´an especializadas en el almacenamiento de datos XML, y guardan todos los componentes del modelo XML dej´andolo intacto. Sin embargo, no pueden ser considerados sistemas de gesti´on de bases de datos por si mismos, i.e. no est´an pensadas para reemplazar a los sistemas de gesti´on de bases de datos existentes. Son simple- mente herramientas enfocadas a facilitar a los desarrolladores las tareas de almacenamiento y manipulaci´on robusta de documentos XML.

Las bases de datos XML nativas organizan los documentos en colecciones, lo que permite consultar y manipular este conjunto con independencia del resto de documentos del sistema. Es un concepto an´alogo a las tablas en las bases de datos relacionales. El concepto difie- re, no obstante, en que las colecciones no imponen un esquema determinado (una colecci´on de campos en el modelo relacional) en los documentos que almacena. Es decir, se permite almacenar cualquier documento XML en la colecci´on, independientemente de su estructura

interna (que viene definida por un esquema). A pesar de esta heterogeneidad, es posible cons- truir consultas sobre todos los documentos de la colecci´on por las particulares caracter´ısticas del lenguaje XML. La independencia del esquema del documento en las colecciones ofrece una gran flexibilidad para el desarrollo de aplicaciones que trabajan con bases de datos XML nativas.

Las consultas en bases de datos XML nativas se realizan mediante el lenguaje XPath y sus recientes revisiones, que han sido bautizadas con el nombre de XQuery [202]. La es- pecificaci´on XPath se utiliza para la consulta de documentos ´unicos, pero no colecciones, almacenados localmente. Entre las carencias m´as importantes de XPath destacan la ausen- cia de agrupaciones, ordenaciones, uniones entre documentos y soporte para tipos de datos. Las nuevas versiones del est´andar XQuery a˜naden soporte para todas estas carencias, utili- zando como base el est´andar XPath y extendiendo su sintaxis para adaptarlo a las exigencias del acceso a una base de datos.

La actualizaci´on de documentos es, sin lugar a dudas, la mayor debilidad de las bases de datos XML nativas actuales. El m´etodo m´as frecuente ofrecido por ´estas requiere recuperar el documento completo, cambiarlo utilizando un API XML local y, finalmente, devolverlo modificado a la base de datos. Algunas implementaciones permiten realizar actualizaciones mediante lenguajes propietarios o a trav´es del est´andar XML:DB XUpdate [208]. El consorcio W3C trabaja en la extensi´on de XQuery para la actualizaci´on de documentos XML, y algunas implementaciones tienen su propia extensi´on a XQuery para realizarlo.

Implementaciones consideradas Siguiendo la pauta de utilizar proyectos libres en los diferentes componentes del sistema, se localizaron las implementaciones de base de datos XML nativa m´as importantes y utilizadas por la comunidad de c´odigo abierto. ´Estas son dos: Xindice [54] y eXist [131].

Xindice: Xindice es la base de datos XML nativa del grupo Apache [51], creador de m´ultiples proyectos relacionados con est´andares del consorcio W3C muy cercanos al XML, como el servidor HTTP apache, o los proyectos Xerces y Xalan de procesamien- to de documentos XML. Xindice utiliza Xpath como lenguaje de consultas y XML:DB XUpdate como lenguaje de actualizaci´on. El proyecto ofrece un interfaz de programa- ci´on para aplicaciones Java a trav´es de XML:DB API [40]; el acceso a Xindice desde otros lenguajes de programaci´on se realiza a trav´es del XML-RPC API [204]. El proyec- to se encuentra en continua evoluci´on; a medida que los est´andares en el campo de las bases de datos XML maduren, se incluir´a soporte para ellos en las sucesivas revisiones. eXist: eXist es una base de datos XML nativa que ofrece procesamiento eficiente de consultas XQuery basado en ´ındices autom´aticos, extensiones para b´usqueda de tex- to completo, soporte para XUpdate y una gran integraci´on con las herramientas de desarrollo XML existentes. La base de datos implementa las ´ultimas caracter´ısticas del est´andar XQuery 1.0, con excepci´on de las relacionadas con el procesamiento de esquemas. El proyecto eXist utiliza una eficiente estructura de ´ındice basada en un es- quema num´erico de indexaci´on para identificar los nodos XML directamente sobre ´este. La base de datos es ligera, completamente implementada en Java y con la posibilidad

de ser implantada en m´ultiples formas, como un proceso servidor, como un servlet o directamente embebido en una aplicaci´on.

Se puede apreciar una considerable diferencia de madurez entre ambos proyectos. Es el pro- yecto eXist, sin duda, el m´as eficiente y el que mejor soporte ofrece de los nuevos est´andares de acceso a bases de datos XML. Sus caracter´ısticas satisfacen todos los requisitos de alma- cenamiento y actualizaci´on del gestor de anotaciones de la arquitectura propuesta. Adem´as aporta funcionalidad extra, como el interfaz directo con servidores HTTP que permite la programaci´on de aplicaciones WEB en el contexto de la arquitectura.

3.6.2.

Sincronizaci´on de anotaciones

La concurrencia de aplicaciones y componentes en el sistema distribuido requiere un con- trol de acceso eficiente a estos metadatos. La mayor parte de las aplicaciones consultan y actualizan metadatos a lo largo de su proceso. La capa de gesti´on de anotaciones es res- ponsable de que los metadatos sean accedidos apropiadamente para evitar incoherencias y corrupci´on de datos.

La centralizaci´on del recurso de anotaci´on para las aplicaciones ofrece no s´olo problemas, como los mencionados de sincronizaci´on, sino un conjunto de ventajas que permiten facilitar la concurrencia de procesos. La concurrencia se permite a dos niveles diferentes:

Nivel de colecci´on: En la terminolog´ıa de bases de datos XML nativas, una colecci´on es un conjunto de documentos XML. Cada documento de la colecci´on est´a asociado a un contenido multimedia determinado. La concurrencia a nivel de colecci´on permite la ejecuci´on concurrente de tareas de an´alisis sobre diferentes documentos de la colecci´on sin ninguna limitaci´on, como muestra la figura 3.19. Los procesos concurrentes son completamente independientes lo que imposibilita la existencia de secciones cr´ıticas. Nivel de documento: A nivel de documento la concurrencia es mucho m´as compleja, como se muestra en la figura 3.20. Cuando dos o m´as procesos requieren trabajar concurrentemente sobre el mismo documento XML, i.e. sobre los metadatos del mismo contenido, se deben seguir una serie de normas que garanticen la consistencia de los datos. A este nivel, el acceso se puede subdividir en funci´on del tipo de acceso y de la secci´on de datos a acceder:

• Tipo de acceso: el acceso a los metadatos puede ser de solo lectura o de lectu- ra/escritura. La sincronizaci´on seg´un este par´ametro se realiza siguiendo el pa- radigma de los lectores-escritores. Seg´un ´este, se permite el acceso a un lector siempre que el documento no est´e siendo utilizado o bien s´olo lo est´en utilizando otros lectores. En el caso de un escritor, s´olo se permite su acceso si el recurso no est´a siendo utilizado por ning´un otro lector o escritor.

• Secci´on a acceder: esta subdivisi´on tiene especial sentido cuando los procesos con- currentes colaboran para realizar el trabajo de un proceso padre ´unico. En este caso, cada proceso se encarga del an´alisis de una fracci´on del contenido y, conse-