Servidor de aplicaciones

Contenedor de la lógica de negocio, accesible de formas distintas:

• Servicios web con protocolo XML-RPC: o Lógica de negocio implementada en Powerbuilder o Lógica de negocio implementada en Java y ejecutada en Tomcat (RPC2).
• Nuevos servicios accesibles mediante REST (peticiones HTTP) e implementados en Java, mediante framework Spring y ejecutándose bajo Tomcat.

Contenedor de distintos repositorios de datos:

• Base de datos relacional (SQL) que contiene datos de negocio con soporte para: o SQL Server o Oracle o Postgre SQL.
• Base de datos no relacional para soporte del nuevo framework (cache de datos, configuración, auditoría…). La Base de Datos escogida es Redis.

Contenedor para servicios de mensajería entre servicios. Para esta funcionalidad se ha optado por el protocolo MQTT (Message Queue Telemetry Transport) y permite disponer de funcionalidad de push (notificaciones iniciadas por el servidor hacia el cliente).

Servidor web

Basado en NodeJS es el servidor de elementos estáticos (elementos HTML, imágenes, etc) y actúa como proxy para las peticiones REST de negocio del cliente al servidor.

Servidor cliente

El framework dispone de una API formada por los servicios (ya sean los XML-RPC o los REST) y accesible:

• Directamente desde cualquier cliente que permita hacer llamadas HTTP.
• Por aplicaciones creadas a partir de la API. Para ello se ha optado por Angular2 por la flexibilidad a la hora de crear aplicaciones ejecutables desde navegador web y como un ejecutable, ya sea en entorno Windows, Linux o iOS.

Nuevas funcionalidades

• Posibilidad de definición dinámica de seguridad por servicio, a nivel de rol de usuario, en varios niveles:
  • Definición de lista de servicios sin restricción de acceso.
  • Definición de lista de servicios accesibles por determinados roles.
  • Definición de lista de servicios restringidos a determinados roles.
  • Servicios accesibles por cualquier rol de usuario (usuario logueado).
• Para el acceso a servicios con definición de control de acceso, se debe realizar la llamada proveyendo al servicio con un token de acceso que se obtiene al realizar un login.
• Caché de datos basada en Redis que permite una mejora de tiempos de ejecución.
• Aplicaciones multi-idioma.
• Posibilidad de auditoría dinámica de eventos.
• Posibilidad de configuración dinámica de seguridad de peticiones de login fallidos, posibilitando el bloqueo de peticiones para evitar ataques de tipo DoS (Denial of Service).
• Funcionalidades más dinámicas gracias a la posibilidad de realizar notificaciones desde servidor hacia el cliente (notificaciones push).

La estructura de la arquitectura futura

El nuevo paradigma está basado en SERVICIOS. Un servicio es una pieza del programa que cumple ciertos requisitos:

• Abstracción y reusabilidad: hacen lo mismo independientemente de “quién” lo llame.
• Autonomía de ejecución.
• Flexibilidad para ejecutar el servicio desde cualquier sitio.
• No habrá programas.

Un trabajo se ejecutan a partir de:

• Un flujo de servicios.
• Una agrupación de servicios simples en servicios compuestos.
• Una nueva casuística.

Ventajas de la Arquitectura 2.0

• 
  Mayor flexibilidad y adaptación
• 
  Basado en estándares
• 
  Incrementa la velocidad y agilidad
• 
  Autonomía de ejecución
• 
  Independencia de la plataforma
• 
  Interoperabilidad