Modelo de programaci´ on de la arquitectura

El modelo de programaci´on de la arquitectura define el paradigma de desarrollo y la abstracci´on ofrecidas a los desarrolladores. El modelo consta de un framework en el que las

aplicaciones embeben sus componentes de procesamiento, y en el que delegan las responsa- bilidades de su ejecuci´on. Los componentes se definen conforme a unos tipos prefijados, de manera que el framework los gestione eficientemente para la consecuci´on de la tarea. Tanto aplicaciones como componentes tienen un conjunto de servicios funcionales disponibles que facilitan el proceso de codificaci´on. En esta secci´on se describen todas las caracter´ısticas del modelo, que resumen la informaci´on base que el desarrollador debe conocer acerca de la arquitectura.

El proceso de ejecuci´on

Se comienza la descripci´on del modelo de programaci´on de la arquitectura ofreciendo un caso de uso general. En este ejemplo se introducen los conceptos sobre los que se asienta el modelo, y que se describen en profundidad en los siguientes apartados.

El caso de uso representa la ejecuci´on de una aplicaci´on multimedia de an´alisis de conteni- do. El objetivo de esta aplicaci´on es realizar una selecci´on de escenas a partir de informaci´on de color. El algoritmo de selecci´on no es relevante para la comprensi´on del ejemplo. S´ı lo es la necesidad de partir de informaci´on almacenada en las anotaciones del contenido, en este caso informaci´on de color. Se supondr´a en este ejemplo que se parte de un documento de anotaciones vac´ıo, por lo que el proceso deber´a comenzar con el an´alisis previo de color de las tomas. Este an´alisis se realiza utilizando los servicios b´asicos de an´alisis embebidos en la arquitectura y disponibles para todas las aplicaciones. Terminado el an´alisis de color, se dar´a comienzo a la ejecuci´on de la aplicaci´on.

Las funciones de una aplicaci´on se dividen siempre en dos partes: las relacionadas con el proceso de an´alisis de contenido y metadatos y las relacionadas con aspectos formales, como el manejo del interfaz de usuario, la definici´on del m´etodo principal, . . . . Las funciones del primer grupo deben ser incluidas en el contexto de un componente. Seg´un la definici´on de esta arquitectura, un componente es un objeto funcional capaz de ser manejado por el framework a trav´es de un interfaz sencillo. Estos componentes deben cumplir una serie de requisitos para permitir al framework ejecutarlos de manera remota y concurrente en el entorno din´amico de la arquitectura.

La aplicaci´on se encarga de inicializar estos componentes y registrarlos en el framework. Los componentes pasar´an a formar parte del conjunto funcional del framework, en el que convivir´an con otros, bien propios del framework o bien procedentes de otras aplicaciones. Su ejecuci´on se realizar´a de manera indirecta; una vez registrados todos los componentes, la aplicaci´on invocar´a los servicios del framework para que se lleve a cabo la tarea de an´alisis encomendada. Este proceso se ilustra en la figura 3.5. Conviene resaltar el hecho de que la figura omite los detalles relativos a la localizaci´on real de cada componente del framework y de la aplicaci´on. En realidad, la distribuci´on de los componentes en los diferentes nodos f´ısicos queda oculta por el n´ucleo middleware CORBA, por lo que no afecta directamente al modelo de programaci´on. Sin embargo, la distribuci´on adecuada de componentes permite la ejecuci´on concurrente de tareas, como se describe en la siguientes secciones.

A partir de este momento, el framework pasa a controlar la ejecuci´on de los componentes necesarios para realizar la tarea configurada por la aplicaci´on. En primer lugar, localiza los

necesarios para la ejecuci´on; esta b´usqueda devuelve referencias a todos los componentes encontrados, incluyendo aquellos que sean redundantes. En funci´on del tipo de tarea, se confecciona la lista final de componentes que se encargar´an de la ejecuci´on. Este proceso se ilustra en la figura 3.6.

Cada componente es configurado para realizar su parte del trabajo. Esta configuraci´on incluye valores globales a todos ellos, como el identificador del contenido a analizar, y tambi´en incluye valores propios de cada tipo de componente, e.g. umbrales de detecci´on, factores de peso, . . . . Este proceso de configuraci´on es especialmente importante en el caso de utilizarse componentes redundantes para la ejecuci´on paralela. En este caso, se debe incluir informaci´on sobre el alcance temporal dentro del v´ıdeo completo que se debe analizar. En el proceso de configuraci´on, el framework tambi´en realiza los bloqueos de recursos asociados a la tarea para evitar condiciones de competencia.

Con esta configuraci´on, el framework realiza la llamada indirecta de ejecuci´on a cada componente involucrado en ´esta, siguiendo el orden de tareas definido por la aplicaci´on. De esta manera, la ejecuci´on de componentes que requieran el uso de resultados de la ejecu- ci´on de otros componentes, ser´a demorada. Cuando esta limitaci´on no existe, el framework ejecutar´a concurrentemente los componentes compatibles. En la figura 3.7 se muestra la pla- nificaci´on de ejecuci´on en el ejemplo tratado. La primera tarea debe ejecutarse por completo para generar los resultados que servir´an de entrada a la segunda. La segunda tarea se ejecuta a continuaci´on; dado que existe redundancia de componentes se divide el v´ıdeo de entrada en varios segmentos para su an´alisis concurrente por todos los componentes disponibles.

La comunicaci´on entre componentes se realiza tambi´en de manera indirecta, a trav´es de los recursos compartidos ofrecidos por el framework. La comunicaci´on directa entre componentes conlleva unas restricciones de dise˜no para ´estos que merman su flexibilidad; la utilizaci´on din´amica de componentes desconocidos se ve seriamente limitada. La utilizaci´on de recursos de comunicaci´on intermedios permite dotar de capacidad din´amica al sistema sin disminuir, de forma considerable, su facilidad de uso. El recurso de comunicaci´on m´as com´un son las anotaciones asociadas al contenido. La comunicaci´on de resultados intermedios cuya inclusi´on en los metadatos sea innecesaria se puede realizar por m´etodos an´alogos que no tengan car´acter persistente.

Tras la finalizaci´on en la ejecuci´on de todos los componentes, el framework se encargar´a de dejar el sistema en un estado consistente, desbloqueando los recursos que fueron usados y liberando a los componentes afectados de la configuraci´on previa. El control pasar´a de nuevo a la aplicaci´on.

Componentes

Los principales elementos del sistema son los componentes. Ellos condensan toda la fun- cionalidad de an´alisis y procesamiento y son, por tanto, los responsables ´ultimos de que las tareas se ejecuten. En la arquitectura propuesta, los componentes se encuentran unidos de manera l´ogica mediante un framework en el que se integran y al que ofrecen sus capacida- des funcionales. A m´as bajo nivel, cada componente es un objeto CORBA, registrado en el middleware y accesible de manera local y remota para su utilizaci´on en la ejecuci´on de

Framework Componente Componente Componente Componente Componente Aplicación Aplicación Registro Componente Aplicación Registro Componente Aplicación Registro Ejecución Config

Figura 3.5: Inicializaci´on y registro de componentes en el framework desde la aplicaci´on.

Framework Componente Componente Componente Componente Componente Aplicación Componente Aplicación Componente Aplicación Tarea 1 Tarea 2

Figura 3.6: El framework selecciona los componentes necesarios para realizar la tarea confi- gurada por la aplicaci´on.

aplicaciones.

El modelo de programaci´on ofrecido trata de minimizar el aspecto CORBA de bajo nivel de los componentes. El objetivo es abstraer al desarrollador de esta vista CORBA del sistema. Sin embargo, los requisitos de dinamismo en la detecci´on y utilizaci´on de nuevos componentes en el sistema genera un serie de limitaciones a esta abstracci´on. El manejo de componentes desconocidos por el sistema se posibilita mediante los mecanismos de invocaci´on din´amica. El uso de estos mecanismos requiere conocimientos avanzados de CORBA, por lo que se pretende que est´e restringido a las propias clases de la arquitectura.

Por tanto, la recepci´on de estas invocaciones din´amicas en el componente servidor se limita a ser est´atica; la creaci´on de servidores mediante esqueletos din´amicos complicar´ıa el desarrollo e imposibilitar´ıa la abstracci´on de la capa CORBA al desarrollador. Esta limitaci´on obliga a acompa˜nar a cada componente de la definici´on de su interfaz en lenguaje IDL. De esta manera, las invocaciones din´amicas del gestor del framework son manejadas apropiadamente por el adaptador de objetos del ORB en la parte servidor, donde el interfaz est´atico si es conocido, como se ilustra en la figura 3.8.

Las capacidades din´amicas del sistema son, por consiguiente, la raz´on de que se deba de- finir el interfaz de cada componente en IDL. La arquitectura proporciona una estructura de clases que permite minimizar el resto de la interacci´on con CORBA a una sencilla herencia, como se muestra en la figura 3.9. En esta figura se aprecia claramente la divisi´on entre el trabajo del desarrollador, los bloques marcados en azul, y el trabajo realizado por la arqui- tectura, los bloques marcados en gris. La clase Component es la base abstracta de todos los componentes del sistema. El desarrollador crea un nuevo componente,UserComponent en la figura, definiendo su interfaz IDL y ofreciendo la implementaci´on de los m´etodos declarados. La definici´on IDL debe heredar obligatoriamente de la claseComponent.

La clase baseComponent define e implementa una serie de servicios para todos los com- ponentes, de manera que el desarrollador se beneficia autom´aticamente de ellos mediante la relaci´on de herencia. La siguiente lista recoge un resumen de la funcionalidad m´as destacada que los componentes heredan de su clase base:

Inicializaci´on de framework local: El constructor de la clase Component realiza una primera consulta al gestor del framework para averiguar el estado de inicializaci´on del nodo en el que se ejecutar´a el nuevo componente. Algunos servicios, como el acceso al contenido, requieren la presencia de gestores de ´ambito local al nodo de ejecuci´on. En el caso de que estos servicios no se encuentren activos, se generan los gestores locales adecuados para que el nuevo componente encuentre un entorno consistente al comenzar su ejecuci´on.

Asignaci´on de identificador en el servicio de nombres CORBA: El constructor tambi´en se responsabiliza de registrar el nuevo objeto CORBA en el servicio de nombres, re- quisito imprescindible para su correcta localizaci´on por el resto de componentes del framework. La generaci´on del identificador se basa en el propio nombre del componen- te, la direcci´on de red del nodo de ejecuci´on y del n´umero de componentes iguales que est´en ejecut´andose en el mismo nodo.

Tarea 1 Tarea 2_1 Tarea 2_2 Tarea 2_3 t Framework Componente _Componente AplicaciónComponente AplicaciónComponente Aplicación Base de metadatos MPEG-7/21 Gestor Contenido Gestor Anotaciones

Figura 3.7: El framework planifica la ejecuci´on seg´un las dependencia de datos entre compo- nentes y las posibilidades de concurrencia.

Gestor Framework Middleware Componente Aplicación IDL Esqueleto Skeleton Implemen tación Invocación Dinámica Invocación estática

Figura 3.8: El gestor maneja din´amicamente componentes desconocidos. La invocaci´on din´amica se maneja est´aticamente en el lado servidor, donde su definici´on s´ı es conocida.

Component IDL Component UserComponent Component .h Component SK.cpp Component impl.h Component impl.cpp User Component IDL User Component .h User Component SK.cpp User Component impl.h User Component impl.cpp User Component implementación

Figura 3.9: Los componentes del sistema heredan de la clase abstracta Component, que les otorga funcionalidad para integrarse en el framework de manera autom´atica.

Registro del componente en el framework: La ´ultima tarea importante del constructor es registrar el componente en el framework. Para ello localiza al gestor del framework y utiliza el API de registro para habilitar el uso del componente dentro del sistema. Eliminaci´on del framework: En el proceso de borrado del componente, el destructor se encarga de utilizar el API del gestor del framework para eliminar el componente del sistema.

ponent ofrecida por el sistema. El desarrollador se abstrae, de esta manera, de muchos de los detalles de la infraestructura subyacente, cuya complejidad podr´ıa significar un importante gasto de recursos.

Tipos de componentes

La vista final ofrecida a los desarrolladores les abstrae de la mayor parte de la capa CORBA sobre la que se ejecutan los componentes. Esta vista de alto nivel esta basada en las caracter´ısticas del framework en el que los componentes residen. Como se expone en el caso de uso, la ejecuci´on de componentes se realiza de manera indirecta, siendo el gestor del framework el responsable de la planificaci´on y la invocaci´on a los m´etodos de ejecuci´on apropiados. La necesidad de manejar componentes de manera din´amica obliga a definir un interfaz com´un y una sem´antica apropiada para aprovechar el polimorfismo ofrecido por el paradigma orientado a objetos de CORBA.

La definici´on de este interfaz debe tener en cuenta dos aspectos fundamentales: la necesi- dad de ejecuci´on din´amica de componentes y la posibilidad de distribuir el proceso en varios componentes iguales que colaboren para realizarlo. La orientaci´on de la arquitectura al domi- nio del an´alisis y procesamiento de v´ıdeo digital permite reducir fuertemente la generalidad de la soluci´on. Este hecho ha sido explotado para conseguir un modelo de programaci´on de componentes sencillo e intuitivo, basado en conceptos del dominio del v´ıdeo digital, y con posibilidades de ejecuci´on concurrente en presencia de componentes redundantes del mismo tipo.

El modelo se basa en los conceptos estructurales b´asicos del v´ıdeo digital, introducidos en la secci´on 1.2.3: fotograma, toma y v´ıdeo completo. Los componentes se clasifican en funci´on de generar resultados a partir de un ´unico fotograma, una ´unica toma o del v´ıdeo completo. La extracci´on de bordes, por ejemplo, es una operaci´on que puede llevarse a cabo con un ´

unico fotograma, i.e. los bordes de un fotograma son independientes de los fotogramas que est´an alrededor de ´este en el v´ıdeo. El c´alculo de la actividad de movimiento es una operaci´on ligada por completo al concepto de toma (secci´on 5.3.2); su c´alculo requiere acceso a todos los fotogramas de la toma dada y es independiente de las tomas colindantes. Por ´ultimo, la segmentaci´on de un v´ıdeo completo en tomas est´a normalmente basada en el an´alisis de cambios entre fotogramas consecutivo. Tampoco se puede reducir a nivel de toma, ya que estas todav´ıa no han sido identificadas. Por este motivo, la operaci´on s´olo puede llevarse a cabo en el contexto del v´ıdeo completo.

Seg´un las caracter´ısticas de las operaciones de cada componente, el desarrollador le asig- nar´a un determinado tipo. Dicha asignaci´on conlleva la implementaci´on de un API distinto, apropiado a los conceptos sobre los que se basa. La implementaci´on de varios de estos APIs est´a permitida. En este caso, el componente pasa a tener varios tipos. La utilizaci´on de uno u otro de esos tipos es responsabilidad del gestor del framework, estando basada en el estado din´amico del framework.

El gestor del framework

En el caso de uso presentado se ilustra como la gesti´on de la infraestructura necesaria para ejecutar el proceso se realiza de manera autom´atica dentro del framework. El m´odulo

software encargado de manejar este mecanismo se denomina “Gestor del Framework”. Es la pieza software m´as importante de la arquitectura, ya que se encarga de ocultar las funciones estructurales encargadas de ofrecer la sencilla abstracci´on con que cuentan los desarrolladores de aplicaciones. En esta secci´on se detallan las funciones delegadas al gestor del framework. El gestor del framework es el interfaz software entre los componentes y aplicaciones del sistema con el propio framework. Su misi´on es manejar los componentes presentes en el siste- ma, permitiendo a˜nadirlos, eliminarlos, localizarlos y ejecutarlos. Tiene el papel, por tanto, de un almac´en distribuido de m´odulos software con capacidades de planificaci´on y ejecuci´on. Se encuentra implementado como un servicio CORBA ´unico en el sistema. Las aplicaciones y componentes determinan su localizaci´on a partir del servicio de nombres ofrecido por el middleware.

En su papel de almac´en, el gestor del framework guarda un registro actualizado de los componentes disponibles en el sistema, tanto los propios de la arquitectura como los a˜nadidos por las aplicaciones en ejecuci´on, como ilustra la figura 3.10. El registro incluye informaci´on acerca de caracter´ısticas de los componentes. La m´as relevante es la concerniente a su nom- bre, que indica las operaciones que puede realizar, y a su tipo, que indica las posibilidades de paralelizar su ejecuci´on con otros componentes. Cada componente tiene adem´as un iden- tificador ´unico, asignado por el gestor, que permite diferenciar componentes redundantes con el mismo nombre y tipo. El gestor del framework genera una estructura para almacenar informaci´on din´amica del estado de cada componente, con datos sobre su disponibilidad y recursos bloqueados.

Este registro de componentes constituye el enlace l´ogico de alto nivel que permite ocultar la mayor parte de los detalles de la capa middleware subyacente. La figura 3.11 muestra cla- ramente la dualidad existente en la arquitectura. A bajo nivel, los componentes son objetos CORBA enlazados mediante los servicios ofrecidos por middleware. El enlace con el middle- ware se realiza autom´aticamente a partir de la funcionalidad heredada de la claseComponent. Las aplicaciones, adem´as, utilizan la funcionalidad del gestor del framework para registrar los componentes en ´este. A partir de ese momento, los objetos CORBA pasan a formar parte de la vista de alto nivel del sistema.

Esta vista de alto nivel es la abstracci´on ofrecida a los desarrolladores. A pesar de su inherente naturaleza CORBA, los componentes se enlazan y estructuran en este segundo nivel de manera independiente. Es una estructura l´ogica, que realmente se sostiene sobre el middleware. Sin embargo, permite ocultar la gran complejidad de la capa middleware a la vez que centraliza informaci´on extendida sobre las caracter´ısticas de los componentes en realizaci´on con los conceptos claves de la arquitectura. Como resultado se obtiene un middleware de m´as alto nivel, adaptado a los conceptos y requisitos propios del sistema de desarrollo multimedia que se ofrece a las aplicaciones.

En su faceta de elemento de planificaci´on y ejecuci´on, el gestor del framework recibe peticiones de ejecuci´on de tareas por parte de las aplicaciones. Una tarea se define, en este contexto, como la ejecuci´on secuencial de un conjunto de componentes del framework para la