3.3 Integración de componentes y dispositivos

1  Introducción

El espectacular auge de los sistemas abiertos y distribuidos, junto con la creciente necesidad de un mercado global de componentes, hacen preciso un cambio en la forma en la que se desarrollan actualmente las aplicaciones. Conceptos como la reutilización, la evolución dinámica o la composición tardía, fundamentales en esos entornos, obligan a una clara separación entre los aspectos computacionales e interoperacionales de los componentes. Debe ser posible por tanto disponer de mecanismos que permitan incorporar de una forma modular a los componentes tanto los requisitos exigidos por el usuario, como aquellos derivados de su ejecución en este tipo tan especial de sistemas

Desde el punto de vista de la arquitectura software estos problemas suelen tratarse mediante la definición de componentes y conectores. Los componentes encapsulan los aspectos computacionales de la aplicación, mientras que los conectores describen los patrones de interacción entre ellos. Sin embargo, este enfoque presenta ciertas limitaciones, puesto que los conectores permiten expresar y gestionar de forma efectiva las interconexiones y sincronización entre los componentes, pero se ha visto que no son suficientes a la hora de abstraer otras propiedades y requisitos específicos, como pueden ser la búsqueda dinámica de recursos, las políticas de distribución de las cargas, o la fiabilidad (Agha, 1998).

Por otro lado, la política que han adoptado los fabricantes y vendedores de plataformas de componentes software (como CORBA, DCOM o JavaBeans) para solucionar estos problemas se basa en la definición e implementación de nuevos servicios y funcionalidades, que extienden los modelos básicos –como son por ejemplo los nuevos servicios de CORBA (Vinoski, 1998), las extensiones Glasgow, Enterprise o Edinburgh de JavaBeans, o los nuevos servicios de la arquitectura de componentes MDCA definida por Microsoft (Sessions, 1998)–. Sin embargo, estas extensiones no son una buena solución a largo plazo, porque comprometen la portabilidad y reutilización potencial de los componentes: por ejemplo, no es fácil migrar un componente que dependa fuertemente de un servicio particular de CORBA a otros entornos; aún peor, aquellos requisitos no ofertados por el sistema han de ser asumidos por los propios componentes, lo que complica innecesariamente su diseño, desarrollo y, de nuevo, dificulta su portabilidad y reutilización; y esto sin contar con que las extensiones pocas veces encajan perfectamente con el modelo de componentes base, que fue diseñado sin tenerlas en cuenta originalmente. Esto suele llevar a soluciones híbridas bastante poco naturales, como pueden ser los mensajes asíncronos de MDCA para componentes COM frente a su tradicional (y natural) mecanismo de comunicación, las llamadas remotas a procedimientos.

2  Bases para un nuevo modelo

Un enfoque más apropiado para solucionar este tipo de problemas se basa en poder diseñar componentes genéricos, que puedan ser especializados más tarde para tener en cuenta las características y requisitos particulares de los sistemas y aplicaciones en donde se integran. Los conectores encapsulan dichas particularizaciones, permitiendo simplificar tanto a los sistemas como a los componentes de todos aquellos requisitos específicos de un sistema, dominio o aplicación concreta. Este es el enfoque utilizado por diversos autores (Agha, 1997; Aksit et al., 1993; Bosch, 1996; Joshi et al., 1997; Minski y Leichter, 1995; Mezini, 1997) que consideran componentes como cajas negras que modifican su comportamiento de forma reflexiva a través de otras entidades, denominadas meta-actores, filtros o capas en sus modelos, y que nosotros hemos llamado controladores.

Nuestra propuesta se basa también en ese modelo, pero trata de solucionar algunos de los grandes inconvenientes que presentan las soluciones existentes, como es que sus meta-componentes:

(a)carecen de estructura uniforme,

(b)se comportan como meros filtros computacionales,

(c) no son reutilizables,

(d)su comportamiento y funcionalidad van excesivamente ligados a los objetos a los que envuelven, y

(e)su composición suele quedar indefinida.

Así, nuestros controladores no son meros filtros que capturan y modifican mensajes, sino que tienen estado y permiten también reordenarlos, contestarlos, o incluso interrogar al sistema y reconfigurarse en consecuencia. Y por otro lado, son entidades reutilizables, todas poseen la misma estructura, y se definen independientemente de los componentes a los que luego se incorporaran (son entidades COTS, commercial off-the-shelf). Por último, es posible componerlos de forma que puedan asociarse varios controladores a un mismo componente, permitiendo así incorporar varios requisitos de forma simultanea.

De esta forma es posible simplificar notablemente los sistemas, que pasan a encargarse únicamente de la integración e interconexión de los componentes, y a los propios componentes, que deben encapsular solamente los aspectos computacionales de las aplicaciones. Por otro lado, los controladores reutilizables proporcionan a los componentes el comportamiento requerido, de una forma modular, independiente y extensible. Además, también se consigue facilitar la portabilidad y reutilización de los componentes, y por tanto su integración en un mercado global de software, donde también tienen cabida y juegan un papel importante los controladores reutilizables.

Para conseguir este mercado potencial hace falta lograr primero varios objetivos. En primer lugar, se ha de disponer de un modelo de componentes para sistemas abiertos y distribuidos que permita la adición modular de controladores y su composición para dotar a un componente de varias propiedades simultáneamente. Por otro lado, es necesario contar con métodos formales que proporcionen consistencia al modelo, y que permitan razonar sobre los componentes, los controladores, y sobre las propiedades de las aplicaciones que se construyen mediante sus combinaciones. Y por último, también es preciso disponer de mecanismos de interconexión del modelo con otros modelos y plataformas existentes, que proporcionen la interoperabilidad de los componentes del modelo con los desarrollados por otros fabricantes, y que permitan la incorporación de aplicaciones heredadas (legacy systems) a la aplicación final.

Nuestra contribución trata de lograr precisamente esos objetivos, y se apoya en un modelo de componentes, SC, específicamente diseñado para sistemas abiertos y distribuidos, que define los conceptos de componentes y controladores reutilizables, su estructura, y la forma en la que se componen para construir aplicaciones distribuidas (Troya y Vallecillo, 1998a). El modelo esta soportado por un marco formal en Object-Z y lógica temporal que permite especificar sus conceptos y mecanismos, razonar sobre su composición, y caracterizar ciertas nociones de especial relevancia para los sistemas abiertos, como son la compatibilidad, la reemplazabilidad o la evolución de sus componentes (Troya y Vallecillo, 1999). Asimismo, se ha definido una metodología para la construcción sistemática de los controladores reutilizables, uno de los conceptos novedosos que se introducen. Al tener todos ellos la misma estructura, es posible diseñar una serie de procesos que guíen su desarrollo a lo largo de todo su ciclo de vida, desde sus especificaciones formales hasta su implementación (Troya y Vallecillo, 1998b).

El presente trabajo se centra en el último de los puntos mencionados anteriormente, la interoperabilidad del modelo con otros modelos y plataformas de componentes para sistemas abiertos y distribuidos. En particular, se estudia la expresividad de los mecanismos de SC frente a los ofrecidos por las plataformas distribuidas existentes de mayor relevancia (CORBA, JavaBeans y (D)COM), y se establecen los escenarios en donde es necesaria y factible la interoperabilidad entre sus componentes. A continuación, se describen los mecanismos utilizados para implementarla.