Agrega

Si realizásemos una inmersión en el entramado lógico de la plataforma Agrega nos encontraríamos con un grupo de módulos especializados que interoperan unos con otros.
La arquitectura de Agrega sigue la filosofía del modelo Service-Oriented Architecture (SOA) donde los dos grandes bloques de elementos lógicos, el nodo de objetos digitales educativos y las aplicaciones clientes se integran utilizando como interfaz un conjunto de servicios.

Este modelo se sustenta sobre tres pilares:
- Interoperabilidad: Comunicación entre los distintos recursos del nodo
- Especialización: Cada componente está especializado en las funciones asignadas
- Evolución: Posibilidad de crecimiento mediante agregación de nuevos módulos

Diagrama:

La división inicialmente se realiza por capas horizontales: capa de presentación, capa de negocio y capa de datos. Cada capa mencionada interactúa entre ella y con la inmediata inferior pero no al contrario.

Para el entendimiento del diagrama de arquitectura que acompaña a esta descripción, se deben tener en cuenta lo siguiente:
• Se ha realizado una división en función de los diversos estratos especificados en SOA, así en azul, se muestra el estrato de presentación, en amarillo el estrato de organización u orquestación de servicios y finalmente en naranja el estrato de servicios lógicos que contiene su propio modelo de datos, entendiendo como tal, cualquier modo de serializar información ya sea base de datos, XML o sistema de ficheros.
• El estrato de presentación se ha dividido con el objetivo de mostrar con qué componentes tiene más relación, y aunque desde el punto de vista de usuario lo notará como uno único, desde el punto de vista de arquitectura se ven como módulos separados que interaccionan con sus “propios” servicios.
• Con el mismo objetivo de facilitar el entendimiento y la visualización del diagrama de arquitectura por parte del usuario, todas las operaciones que tienen relación con la autorización, como por ejemplo, si un usuario está o no autorizado a ver un objeto o a realizar una determinada operación sobre él o incluso a acceder a una determinada herramienta o funcionalidad de la misma y que por tanto, deberían tener relación con el subsistema de seguridad no se han dibujado.
• Los idiomas se encuentran localizados en el modulo del indexador/ buscador ya que este módulo es el que controla en qué idioma se indexará y se realizará la búsqueda, es por ello que todos los módulos tendrán acceso a este modulo para mostrar los distintos desplegables de idiomas. Todas estas relaciones entre los módulos y el buscador no se muestran en el diagrama aunque también existen.
• Todos los subsistemas exponen sus interfaces a través de un puerto y los subsistemas que se relacionan con él lo consumen.

Capa de presentación:

Esta capa de arquitectura lógica se corresponde en la arquitectura software a la proporcionada por el framework de desarrollo struts seleccionado para dar soporte a la generación de la presentación y que implemente el patrón arquitectónico MVC en Java.

Capa de negocio:

Esta capa de arquitectura lógica se corresponde en la arquitectura software a la proporcionada por el framework de spring utilizado para la implementación de la coordinación de la lógica de negocio, se integra perfectamente con otros componentes seleccionados en la arquitectura software y permite que el producto desarrollado sea fácilmente escalable, tenga un alto rendimiento y facilidad de mantenimiento.

Capa de datos:

Para acceder a la información persistente residente en la base de datos, se utilizará un framework de mapeo relacional (ORM), aunque para casos excepcionales pueda necesitarse el uso de DAOs de acceso directo vía JDBC (consultas de alta complejidad, operaciones de actualización masiva, etc).
Cada subsistema será el único capaz de acceder y modificar sus entidades de dominio, ofreciendo el oportuno acceso a dichos datos mediante sus interfaces de servicio expuestos en dicha capa. Esta particularidad viene dada por el uso de una arquitectura SOA en la que cada servicio es independiente y único responsable de mantenimiento de su dominio, habilitando así un acoplamiento débil entre subsistemas fácilmente reemplazables.