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.
No hay comentarios:
Publicar un comentario