PDF de programación - Composición y Coordinación de Componentes mediante Conectores y WebServices

Composición y Coordinación de Componentes mediante Conectores y

WebServices

M. Katrib

Facultad de Matemática y

Computación.

Universidad de la Habana

[email protected]



J.L. Pastrana

E.T.S.I. Informática.
Universidad de Málaga
[email protected]

E. Pimentel

E.T.S.I. Informática.

Universidad de Málaga

[email protected]



Resumen

forma de contratos (precondiciones, postcondiciones e

La reutilización de componentes es uno de los principales objetivos que se plantean en la ingeniería del
software actual. El siguiente trabajo, que continúa la línea emprendida en trabajos anteriores, muestra cómo
una extensión de la metáfora del "Diseño por Contrato" puede ser usada como herramienta simple y elegante
para la composición, coordinación y reutilización de componentes software previamente existentes. Para ello
se definen conectores en
invariantes) y
comportamientos impuestos al servidor (en caso de incumplimiento de los mismos) entre componentes
mediante la extensión del interfaz del componente servidor (en el que se expresan sus características
funcionales) con los requisitos no funcionales que el componente cliente desea. Un conector será, por tanto,
un componente, cuya implementación es generada de forma automática a partir de su definición, y será el
encargado de conectar, coordinar, sincronizar y modelar el comportamiento en caso de fallo del componente
remoto que queremos usar desde uno o varios componentes. De esta forma, el uso de estos conectores nos
permitirá tener un software, basado en la composición de componentes previos ya existentes, que sea de
calidad, tolerante a fallos y conceptualmente distribuido

A nivel de implementación, se propone una herramienta que genera automáticamente dichos conectores a
partir de descripción funcional extendida (IDL + Contratos) con lo que separa los detalles semánticos y de
comportamiento de los de los detalles funcionales y de implementación. Versiones anteriores de la
herramienta se basan en Java usando AspectJ y bajo el estándar CORBA de OMG y en C# usando .NET. En
este trabajo se propone también una herramienta que utiliza WebServices y tecnología XML para la
implementación de los conectores.

La posibilidad de definir uno o más conectores diferentes para un mismo componente remoto y el hecho de
ser el cliente quién imponga el comportamiento que desea del componente remoto que actúa de servidor hace
que se pueda tener más de un comportamiento diferente de un mismo componente remoto en función de quién
lo use. Esto posibilita una mayor reutilización de componentes en lo que podríamos llamar "Software
Orientado al Cliente".


1. Introducción
Trabajos precedentes, [5, 6, 7, 8], presentan un modelo para el desarrollo de software basando en la
composición de componentes a los que se le establece como necesaria una clara separación entre los aspectos
computacionales de los componentes respecto a otros requisitos no funcionales que son susceptibles de
cambiar durante su ciclo de vida. Entre estos requisitos podemos citar: sincronización, coordinación,
persistencia, replicación, distribución, tiempo real, etc.

Recordemos qué entendemos por componente y las características que debe tener un componente para
permitir el desarrollo de software mediante composición de los mismos:



Componentes son unidades Software binarias que pueden ser insertados en un sistema y puestos a trabajar.
Se entiende por binario el que sea ejecutable por una máquina (mas o menos directamente, i.e. no
necesariamente código nativo para un CPU concreto sino incluso un código virtual) y no que sea el código

máquina para un procesador dado o que no sea legible por un humano, para que puedan ser usadas como
unidades de desarrollo.

Siete Criterios para Componentes:

Incluyen una especificación de todas las dependencias.
Incluyen una precisa especificación de la funcionalidad que ofrece.

1. Pueden ser usados por otros elementos Software (Clientes).
2. Pueden ser usados por clientes sin la intervención de sus desarrolladores.
3.
4.
5. Sólo pueden ser usados basándose en su especificación.
6. Es componible con otros componentes.
7. Pueden ser integrados rápida y suavemente en un sistema



Para poder expresar los requisitos no funcionales de un componente, sus interfaces deberían ser enriquecidas
con definiciones semánticas, requerimientos de sincronización y de comportamiento ante fallos para poder
asegurar un correcto comportamiento de los mismos, de modo que, la composición de componentes alcance a
realizar el objetivo deseado del sistema software.

Nuestra propuesta se basa en la definición de conectores entre componentes. Dichos conectores, no son
simples adaptadores de interfaces que sólo adapten el nombre de las operaciones o el tipo de los parámetros.
Son componentes activos que permiten la definición de requisitos vía asertos, así como la definición del
comportamiento ante el incumplimiento de los mismos. La posibilidad de definir más de un conector (con
requisitos y comportamientos diferentes) sobre un mismo componente remoto permite una mayor
reutilización de un componente, ya que un mismo componente servidor puede ser usado con diferentes
comportamientos por varios componentes clientes.

Considérese el siguiente ejemplo: un componente productor y otro consumidor se sincronizan a través de un
componente buffer acotado. La circunstancia de que el productor intente colocar un elemento sobre un buffer
lleno o que el consumidor intente extraer un elemento sobre un buffer vacío no debe considerarse un error,
sino una simple sincronización entre componentes. Sin embargo, supongamos que el productor, por ejemplo,
usa un buffer acotado en el proceso de producción (además del que ya usa para comunicarse y sincronizarse
con el consumidor) que podría ser una instancia diferente de la misma clase de componente buffer. En este
caso, si podríamos considerar como un error el intentar extraer elementos sobre el buffer vacío o insertar
sobre el buffer lleno. ¿Significa esto que el funcionamiento de ambos buffer es diferente? La respuesta es NO
(de hecho podrían ser instancias diferentes de la misma clase de componente buffer). La diferencia radica en
los requisitos no funcionales y/o en el comportamiento del mismo ante el incumplimiento de los mismos, que
es precisamente lo que modela el conector.

La solución a problemas de cambios de requisitos o de escalabilidad es simple, sencilla y conocida desde hace
años. Al igual que cualquier producto hardware está compuesto por un conjunto de componentes
interconectados, los productos software deben seguir la misma filosofía y estar formados por un conjunto de
componentes software conectables, de manera que pueda ser sustituido un componente, si es necesario, o
cambiar la conexión o tipo de ésta. Esta filosofía o arquitectura software de composición, además de permitir
el desarrollo de un software más flexible y escalable, permite no hacer diferencias entre sistemas distribuidos
y no distribuidos, ya que la localización de los componentes no afecta a la funcionalidad del sistema (aunque
como es obvio puede afectar a la eficiencia del mismo).

En la presente propuesta, se extiende la semántica del contrato (precondiciones, postcondiciones e
invariantes) [12] de manera que pueda ser usada para garantizar la coordinación de componentes. Esta
coordinación se realizará a través de las cláusulas de comportamiento ante fallo que permitirán la suspensión
de la llamada hasta que se verifique la condición, el fallo de la llamada (excepción) o el reintento de la misma.
Todos los conectores de comp onentes del sistema tendrán, también, la posibilidad del uso de un predicado
especial timeout con un parámetro real para especificar los requerimientos temporales de cualquier
servicio. Es importante notar que, a diferencia del modelo original propuesto por Meyer [12] en el que los
asertos se verifican en el componente servidor, en este modelo, es el conector el encargado de verificar los
asertos que el cliente exige para un servicio (precondición) o propone como invariante o postcondición. Esto
significa que no es el componente que ofrece el servicio quién asegura el funcionamiento, sino que es el

cliente quien impone las condiciones de funcionamiento particulares para él. Es decir, es el cliente quien
decide en qué condiciones quiere que se ejecuten sus peticiones.


2. Ejemplo: Una Biblioteca Virtual.
Supongamos que se tiene una biblioteca virtual donde se pueden leer diferentes revistas o libros. Para ello
tenemos un servidor que puede ser accedido por diferentes navegadores. Dicho servidor, también debe ser
actualizado, modificando la información que él contenga. Esta aplicación, por tanto, tendría un número
indeterminado de componentes (instancias reales), pero que corresponden a 3 clases de componentes:
navegadores, administradores y servidor. El interfaz (IDL) del servidor podría ser como el siguiente:


interface ServidorBiblio
{ String Consultar();
void Administrar();
void establecer_deseo_administrar(boolean deseo);
boolean esta_siendo_administrado();
boolean desea_ser_administrado();
};

Código Fuente 1. Interfaz del Servidor de la Biblioteca


Veamos cómo a partir de esa interfaz, se puede diseñar los conectores para que puedan interaccionar con él,
tanto los navegadores como los administradores. Un navegador, podrá consulta