AsFusion

Durante los últimos días he estado trabajando en un proyecto que debía ser desarrollado usando la arquitectura C2. Lo más seguro es que no sepan lo que es C2, debido a que no creo que haya pasado más allá del círculo académico todavía. Fue desarrollado por el Institute for Software Research de la Universidad de California en Irvine.

Este tipo de estilo de arquitectura esta basado en mensajes y todos los componentes de la aplicación de comunican a través de ellos y no directamente. Lo que me resulto más interesante es que diferencia entre dos tipos de mensajes distintos, algunos son solo "notificaciones", y otros son "pedidos". Las notificaciones se envían a los componentes que están "abajo" y no le importa si hay componentes que estén escuchando esas notificaciones o no y los pedidos se hacen a componentes que están "arriba" y el componente supone que hay alguien arriba que le va a dar el servicio que pide (pero no le importa quien lo hace).

p>Como esta manera de pensar es distinta de lo que yo estaba acostumbrada (programación orientada a objetos), a veces resulta difícil asimilarlo. Una de las cosas que se complican es que los eventos (mensajes) están desincronizados y corren en distintos subprocesos ("threads"), de manera que uno nunca sabe en que momento le va a llegar un mensaje, cual será su contenido ni que en que orden los recibirá. Otro problema es que no esta permitido enviar punteros y luego modificar el objeto desde dos componentes distintos.

Sin embargo, las ventajas son claras cuando uno lo usa: los componentes no están atados entre sí ya que ninguno de ellos da por asumido nada de los servicios que otros componentes brindan y además ninguno ve a quien esta escuchando sus mensajes, solo sabe quien esta por arriba y puede llegar a responder sus pedidos. De esta manera, se pueden intercambiar unos componentes por otros sin tener que cambiar nada por alrededor. Se podría incluso agregar toda una capa nueva de componentes sin que ninguno se entere. Lo único que le veo de malo es que si bien uno da por asumido que alguien va a responder a un pedido, no hay manera de asegurarse en el momento de compilación que eso va a suceder (ni tampoco mientras el programa corre para ese caso). Entonces eso hace que el diseño de la aplicación tiene que estar muy bien pensado para que no nos falte ningún componente y cuando lo implementamos, asegurarnos de no borrar por equivocación ninguno que este dándole servicios a otro.

Para implementar esta arquitectura existe un marco de trabajo ("framework") que provee una forma de definir el mapa de conectadores y componentes usando un archivo XML. También provee las clases abstractas para los componentes.