Descripción de Interfaces Internas del Subsistema Servicios de Valor Agregado

Dentro de la plataforma se consideran Servicios de Valor Agregado a todas aquellas aplicaciones que son el resultado de la interacción de los Servicios Habilitadores. Estas interacciones se realizan a través de la composición de servicios Habilitadores que dan como resultado nuevos elementos con diferentes funcionalidades.

La composición de los servicios no se realiza de manera automática, es ejecutada a través de métodos de invocación de Servicios Web a través de interfaces WSDL dentro de la capa de Servicios de Valor Agregado. Estas interacciones son integradas a la capa a través de aplicaciones web que pueden estar localizadas en el mismo servidor que aloja a los Servicios Habilitadores o en diferentes contenedores, lo que permite que la interacción con los componentes de la capa habilitadora sea distribuida y pueda ser efectuada por terceros.

Los servicios de valor agregado pueden ser

• Servicios de alerta, son tareas específicas para informar condiciones anómalas en la información proporcionada por la capa habilitadora.

• Reportes, son servicios encargados de proporcionar la información de la red de estaciones asociadas a la plataforma a través de medios audiovisuales.

• Estadísticos, son aquellos servicios que generan la estadística de toda la información recogida por las estaciones

• Correlación, son tareas que permiten resaltar información concurrente entre diferentes reportes, ya sean de información satelital o de las estaciones.

Una descripción más profunda de los Servicios de Valor Agregado se encontrará en el capítulo 5 de la presente disertación cuando se exponga el modelo de alertas tempranas para la PESMC.

3.4.1.2 Descripción de Interfaces Internas del Subsistema Servicios de Valor Agregado

Figura 3.6 Diagrama de interacción de componentes del subsistema Servicios de Valor Agregado.

A continuación se describe la interacción de los componentes de este subsistema como se ilustra en la figura 3.6:

Para el caso de solicitar datos al repositorio de información (1):

1. La lógica de aplicación invoca a los Servicios de Valor Agregado (VA) para realizar consultas sobre información en la base de datos.

2. El servicio de VA solicita esta información al repositorio a través de interfaces JDBC/ODBC.

3. El repositorio responde exitosamente si existe la información solicitada.

4. La capa de servicios de VA responde a las necesidades de la lógica enviando la información.

¨Para el caso de invocación de servicios habilitadores (2):

1. La lógica de aplicación invoca a los Servicios de Valor Agregado (VA) para conocer información compuesta.

2. La capa de Servicios VA enruta los servicios habilitadores a través del Bus de Servicio.

3. El Bus de Servicios enlaza la solicitud hacia las interfaces de los servicios habilitadores.

5. El Bus de Servicios enruta la respuesta de la capa de habilitación a la capa de servicios de VA, donde posteriormente es procesada para su composición.

6. La capa de servicios de VA almacena la información de la composición en el repositorio.

7. El subsistema de repositorio informa el éxito/fallo del proceso de almacenamiento de información.

8. La capa de Servicios de Valor Agregado responde a la invocación del módulo de Lógica de aplicación.

3.4.2 Subsistema Bus de Servicios

El Bus de Servicios es el encargado de proporcionar a la arquitectura propuesta una comunicación fiable entre los distintos recursos tecnológicos tales como aplicaciones, plataformas y servicios, de forma transparente, evitando cantidades de conexiones punto a punto entre las distintas aplicaciones y/o servicios.

A su vez, este subsistema se encarga del enrutamiento de los mensajes generados a partir de la invocación de servicios de una forma segura, garantizando la correcta comunicación entre el cliente y el proveedor del servicio solicitado. Para el caso de la arquitectura planteada, quienes solicitan los servicios son el módulo Clientes o el subsistema Lógica de Aplicación. El Bus posee la capacidad de proporcionar funcionalidades propias (por ejemplo transformación) y funcionalidades expuestas por proveedores de servicios, que en la arquitectura se encuentran representados por el módulo de Servicios.

Por otro lado, este subsistema provee a la arquitectura presentada en esta tesis de maestría importantes ventajas tales como seguridad, transformación de datos, orquestación de servicios, entre otras, convirtiéndola en una arquitectura más robusta.

3.4.3 Descripción de Componentes del Subsistema Bus de Servicios 3.4.3.1 Orquestación

Es el encargado de establecer el flujo de control y ejecución de los procesos del negocio usando para ello Servicios Web6. Dicho componente utiliza BPEL [43] como lenguaje de orquestación de servicios. BPEL es un formato XML tal y como otros formatos propios de las especificaciones relacionadas a los servicios web. Este lenguaje emplea a su vez especificaciones que ya son un estándar en lo que a Servicios Web se refiere, como lo son SOAP para comunicación y WSDL para la descripción de interfaces.

3.4.3.2 Transformación

Permite el mapeo de datos (transformación) entre distintos modelos utilizando para ello documentos derivados del estándar XML. Para realizar esta labor, este componente 6Estándar de Servicios Web de la W3C

implementa el estándar XSLT [28], el cual, por medio de un conjunto de reglas definidas con el estándar XSL [48], permite convertir el documento fuente a un tipo de documento XML diferente, o incluso a otro tipo no basado en XML, como PDF, por ejemplo.

Este componente requiere un motor de transformación, el cual se encarga de recibir el documento XML que se desea transformar, y el documento que contiene las reglas de transformación (“reglas.xslt”). El motor de transformación aplica y procesa estas reglas al documento XML para generar una respuesta.

El resultado generado por este componente es la presentación de los mismos datos del documento XML en diferentes formatos, adaptados a diversos dispositivos de acuerdo a las reglas de transformación aplicadas.

Por otro lado, mediante la transformación de datos es posible que dos o más aplicaciones puedan interactuar mediante un modelo de datos común, evitando la modificación de la implementación de los sistemas que se van a comunicar.

3.4.3.3 Enrutamiento

Tiene como principal objetivo reducir el acoplamiento entre los componentes del Bus de servicios. Para cumplir esta meta, el componente de enrutamiento se encarga de gestionar el paso de mensajes entre los proveedores y consumidores de servicios llevando la información de un lugar a otro. Todos estos mensajes entrantes, internos y salientes del Bus de Servicios son normalizados y desnormalizados en un formato común. Por tanto, este componente actúa como un mediador que contiene la lógica necesaria para dirigir las peticiones hacia el servicio que implementa la funcionalidad encargada de procesar dicha solicitud y retornar la respuesta de la petición al consumidor que lo solicitó cuando esta haya sido procesada.

Cuando un servicio es invocado por el subsistema Lógica de Aplicación o por una aplicación del módulo Clientes, este componente se encarga de guiar la petición hasta el servicio encargado de procesar la solicitud. De igual manera, una vez procesada la solicitud, el componente se encarga de dirigir la respuesta al cliente que hizo la petición.