Infraestructura, comunicaciones y movilidad

Introducción

Este tema está muy relacionado con el tema dos, en cuanto a que nuestra solución, representada mediante un diagrama lógico, se basará en alguna de las arquitecturas típicas de sistemas de información, que veremos a continuación, en función de los requisitos y condiciones del ejercicio. También veremos los productos o soluciones tecnológicos habituales utilizados para construir y desplegar estos sistemas.

Arquitecturas típicas

Modelo de Servicio

A la hora de implementar un sistema de información, que pudiera dar lugar a su reutilización o utilización de forma compartida con otros organismos, debemos tener en cuenta distintas posibilidades (no excluyentes entre sí), que corresponden con un modelo de servicio de negocio o de prestación de servicio:

• Servicio de modo online: es el modo normal, nuestro servicio se publica y es consumido de forma normal desde donde se centraliza la operativa. Todos los organismos utilizaran nuestro sistema, que deberá tener la posibilidad de tener ‘tenants’ o ‘instancias’ para los distintos organismos: por ejemplo ACCEDA en la nube SGAD.

• Servicio on-premises: cada organismo instala y gestiona su producto de forma autónoma: por ejemplo ACCEDA en modo on premises.

• Servicio federado: en el caso de un servicio que va a ser invocado muchas veces por parte de numerosos centros regionales por toda la península, conviene ponerlo, además de en modo online en el lugar donde este centralizado, también federado en dichos centros regionales. De esta forma, se lo instalan y no tienen que saturar al punto central con sus llamadas si no que las invocan cada uno de ellos de forma local. Importante en este caso es la sincronización de datos y la arquitectura de replica.

• Plataforma de intermediación: si se trata de un servicio que va a ser consumido enormemente por otros organismos, conviene incluirlo en la Plataforma de Intermediación

Arquitecturas centralizadas vs. distribuidas

Los tres modelos de arquitecturas, como ejemplo de cultura general, ya que nuestros sistemas se desarrollarán todos bajo una arquitectura de 3 capas, salvo que en el enunciado se pidiera algo específico.

• Arquitectura centralizada.

  • Ventajas:

    • Disponer y procesar toda la información en el mismo punto, con lo que el software del sistema es mucho más sencillo y fácil de gestionar.

    • Se reduce la probabilidad de que existan inconsistencias en los datos procedentes de diferentes fuentes. O lo que es lo mismo, mayor coherencia de los datos.

    • Mantenimiento más sencillo y transparente a los organismos descentralizados.

    • Políticas de seguridad más sencillas, al estar centralizadas en un único punto.

  • Desventajas:

    • Posible cuello de botella y necesidades mayores de capacidad en cuanto a comunicaciones y almacenamiento.

    • La seguridad y la disponibilidad del sistema es crítica ya que, si se produce un fallo en el punto central, el sistema en su totalidad se venía afectado.

    • En el caso de especificidades en la lógica de negocio dependiendo de la ubicación, se complica la aplicación centralizada.

• Arquitectura descentralizada.

  • Ventajas:

    • Menor riesgo de cuellos de botella, al encontrarse la lógica de negocio distribuida en las distintas unidades.
    • Un fallo en una de las unidades no impedirá al resto continuar con sus operaciones.
    • Si dependiendo de la unidad, la lógica de negocio cambia sustancialmente, esta solución es más adecuada que la centralizada.

  • Desventajas:

    • Al encontrarse la información ubicada en las distintas unidades, existen más posibilidades de que se produzcan inconsistencias en los datos. Necesidad de replicar las medidas de seguridad en cada unidad.

Lo más común: modelo en tres capas: presentación, negocio y datos

Creamos un cliente ligero (navegador) que carece de toda lógica de negocio y se limita básicamente a la visualización y petición de datos.

• Ventajas:
  • Las llamadas desde el cliente ligero a la capa de aplicación son más flexibles que en el diseño de dos capas, ya que la estación solo necesita transferir parámetros a la capa intermedia.
  • Al proporcionar independencia y menor acoplamiento entre la capa de presentación y la capa de datos, dicha estructura de datos puede ser modificada sin cambiar el cliente.
  • Facilita la reutilización, ya que el código de la capa de aplicación puede ser reutilizado por múltiples aplicaciones si está diseñado en formato modular.
  • Mayor facilidad de escalado: la separación de roles en tres capas hace más fácil reemplazar, modificar o ampliar una capa sin afectar a los módulos restantes.
  • Mayor facilidad para la personalización de las Políticas de seguridad en cada capa. Se facilita la dedicación de personal experto en cada una de las capas sin que su trabajo interfiera con el de los expertos en otras capas, debido a la independencia.

DESCRIPCION BREVE DE LAS 3 CAPAS.

Capa de presentación:

• Función: recopilará los datos facilitados por los usuarios, realizará una primera validación de tipos y los adaptarán a lo requerido por las capas inferiores. Asimismo, adoptarán los resultados dados por las capas inferiores y los adaptarán para que sean fácilmente visualizables por el usuario.
• Acceso: los usuarios accederán vía web a esta capa, dada la ubicuidad de los navegadores web y a la escasa carga que producen en los equipos cliente. La capa de cliente se basará en navegadores XHTML estándar (HTML5), compatibles con Javascript y ECMA-262, y con los plugins más habituales, como lectores de formatos PDF. Responderá a los principios del Responsive Web Design.

ANTENCION

Mencionar en el caso del ciudadano que se trata de un acceso a través de la sede electrónica, cuando sea el caso.

• Seguridad: para dotar de seguridad a estos accesos, se utilizará HTTP sobre TLS.
• Accesibilidad: dado que los potenciales usuarios pueden carecer de conocimientos informáticos avanzados o sufrir algún tipo de discapacidad, será necesario que el interfaz web se desarrolle teniendo en cuenta los principios establecidos en los criterios WCAG 2.1 de la W3C en su nivel AA, de acuerdo con la norma UNE 301549:2020 (equivalente a la norma EN 301549:2019).
• Multilingüismo: cuando el sistema se extienda a zonas en régimen de cooficialidad lingüística. Se puede proponer utilizar el servicio de traducción del Ministerio, que incorpora controles de calidad y revisión. A partir de los XML en distintos idiomas, con un XSL se adapta la presentación. También se puede hacer mención al uso de PLATA, para realizar la traducción automática de las páginas WEB.
• Movilidad: Existen tres posibilidades fundamentalmente → nativas, apps web o híbridas

Apps nativas.

• Están escritas y compiladas directamente para la plataforma.
• Su principal ventaja es el rendimiento logrado por la integración con el hardware. Pero esta opción provoca la total dependencia de la plataforma. Por tanto, para más del 95% de los usuarios, tendremos que desarrollar nuestra aplicación en las 3 plataformas más importantes → iOS, Android y Windows.
• Otra ventaja es que se consigue una velocidad de respuesta muy alta, si bien hoy en día la diferencia con las híbridas es mínima.
• Su principal inconveniente es que supone un desarrollo extra importante porque hay que desarrollar todo el sistema para cada una de las plataformas.

Apps webs.

• Son aplicaciones web diseñadas para adaptarse a las pantallas de los dispositivos móviles.
• La mayor ventaja consiste en la independencia de la plataforma.
• El inconveniente principal es que todavía está limitado en el acceso a las características más avanzadas de los dispositivos móviles (funciones propias).

Sus principales ventajas son:

• Las actualizaciones son muy sencillas (cambiando la web la cambias para todo el mundo) por lo que si se van a requerir muchas actualizaciones puede ser útil.
• Requieren poco tiempo de desarrollo.
• Abarcan un amplio abanico de dispositivos (móviles, tablets, TV, ...).

Apps híbridas:

• Son aplicaciones web, generalmente cliente (no requieren de servidor web), diseñadas para pantallas pequeñas, embebidas en un framework que permite acceder a funciones propias del dispositivo. El resultado es una aplicación nativa para cada plataforma, pero el código es único.
• Para hacer una aplicación híbrida tienes que utilizar un framework que empaquete tu código HTML5 y javascript convirtiéndolo en una aplicación nativa. ¿Qué es lo que te aporta ese framework? Que desde tu código javascript puedes acceder a funciones propias del dispositivo (GPS, acelerómetro…) utilizando las funciones del framework
• Al compilar, el framework transforma esas llamadas en las llamadas nativas de la plataforma para la que estás compilando con lo que, mediante un único código, obtienes una aplicación híbrida para las principales plataformas.
• Hay una tarifa aplicada por los portales de distribución de aplicaciones de Google y Apple, para poder distribuir nuestra aplicación.

Frameworks para apps móviles:

• jQuery Mobile
• Ionic
• Framework 7
• Apache Cordova (antes PhoneGap)
• Xamarin 🡨 de Microsoft, multiplataforma (iOS, Android, Win)

Atención

Caso de adaptar una aplicación al iPhone e iPad, los pasos principales a seguir son:

✔ Fase 1: establecer el diseño y la navegación específica para la aplicación iPhone, o darse de alta como desarrollo en Apple.

✔ Fase 2: tras completar el desarrollo, hay que esperar la aprobación interna de Apple para su publicación.

Capa de lógica de negocio:

• Función: procesará los datos facilitados por los usuarios e implementará la inteligencia de los subsistemas para obtener los resultados requeridos.

• Descripción de los principales subsistemas, su funcionalidad, como se implementan y propuesta de productos. Si hay servicios web, serán facilitados por los servidores de aplicaciones y se invocarán a partir de la definición realizada mediante WSDL (si hay muchos participantes que vayan a consumirlos, los WSDL se almacenarán en servidores UDDI), accesibles por todos los participantes. De esta manera, la información se transmitirá en XML sobre el protocolo SOAP. Para garantizar la seguridad de esta información se cifrará a nivel de transporte con HTTP sobre TLS y, a nivel de mensaje, se firmará con WS-Security.

Capa de datos:

• Función: se encarga de dotar de persistencia a aquellos datos del sistema que así lo requieran, en el formato más adecuado para su conservación, recuperación y tratamiento.

Posibilidades a incluir → la capa de datos constará de:

• Una Base de Datos Relacional que dará soporte al resto de capas.
• Un Datawarehouse con arquitectura MOLAP que servirá de apoyo al módulo de análisis y que permitirá el análisis multidimensional de los datos del sistema (cuando haya estadísticas y cuadros de mando).

ENFOQUE PRÁCTICO:

tenemos que saber en donde se despliega cada capa (tipo de servidor), que tipo de contenido tiene cada capa y servidor (estático, negocio…), como se comunican entre ellas, cuales son sus ventajas e inconvenientes (Modularidad, crecimiento horizontal, escalabilidad….). Importante, como encajan las apps moviles en este modelo…

MICROSERVICIOS Y CONTENEDORES

Una arquitectura de microservicios está compuesta por un conjunto de pequeños servicios autónomos y autocontenidos cada uno de los cuales implementa una funcionalidad de negocio. Se trata de una evolución de las arquitecturas orientadas a servicio (SOA), con las siguientes diferencias:

• Los microservicios son pequeños, independientes, y con acoplamiento débil.
• Cada servicio tiene su propio código, que puede ser gestionado por un equipo independiente.
• Los servicios pueden desplegarse de manera independiente, por lo que modificar un servicio no implica rehacer y redesplegar toda una aplicación.
• Los servicios son responsables de la persistencia de sus datos y su estado, no existiendo una capa adicional de persistencia.
• Los servicios se comunican entre sí mediante una API. Los detalles de implementación están ocultos.
• Cada servicio puede estar implementado con una tecnología o framework diferente.

Algunos de los componentes típicos de estas arquitecturas (aparte de los propios microservicios) son:

• Gestión: encargado de publicar los servicios en los nodos, identificar fallos, balancear la carga, etc.
• Descubrimiento de servicios: mantiene actualizada la lista de servicios disponibles y nodos en los que están publicados. Permite obtener los endpoint de los servicios.
• API Gateway: punto de entrada para los clientes. Éstos no llaman directamente a los servicios, sino que el Gateway redirige las llamadas al punto apropiado del backend. También puede agregar respuestas de varios servicios en una sola, realizar funciones comunes a todos los servicios, como la autenticación o terminación de SSL, emplear protocolos diferentes, etc.

Este tipo de arquitectura está orientada a:

• Grandes aplicaciones que requieren un ritmo rápido de lanzamiento de nuevas versiones.
• Aplicaciones complejas que deben poderse escalar fácilmente.
• Organizaciones con pequeños equipos de desarrollo.

Los principales beneficios de su utilización son:

• Despliegues independientes para cada servicio: que implican menos riesgo en cada nueva versión ya que los errores no afectan a toda la aplicación sino únicamente a un servicio.

• Desarrollos independientes: cada servicio puede estar desarrollado y gestionado por un equipo independiente, lo que favorece el lanzamiento rápido de nuevas versiones. Además, cada equipo puede centrarse en un único servicio, aumentando así el rendimiento del equipo.

• Aislamiento frente a fallos: un problema en un servicio no implica la caída de toda la aplicación, sino únicamente de la funcionalidad implementada en dicho servicio.

• Mezcla de tecnologías: cada equipo puede optar por la tecnología que considere más apropiada para la implementación de su servicio.

• Escalabilidad: cada servicio puede escalarse de manera independiente, en función de las necesidades.

Por el contrario, algunas de las desventajas de emplear este tipo de arquitecturas son:

• Complejidad: al haber muchos componentes, la complejidad del sistema es superior, pese a que cada componente individual sea más sencillo.
• Falta de gobernanza: al utilizarse un enfoque descentralizado, donde se pueden juntar diferentes tecnologías y equipos, la gestión del conjunto puede resultar más compleja.
• Integridad de los datos: dado que cada microservicio es responsable de persistir su información, puede haber problemas de consistencia de datos entre los diferentes servicios.
• Versiones: al actualizar un servicio se debe asegurar que los servicios que dependen de éste no se ven afectados y pueden seguir funcionando correctamente.

Cliente servidor, aplicaciones embebidas, dispositivos inteligentes, IoT.

La arquitectura clásica donde el cliente tiene inteligencia de negocio en una aplicación instalable, y los datos en una BBDD.

Por un lado, está el cliente y por otro el servidor, y el cliente puede integrar parte de la funcionalidad del sistema. Ante la arquitectura de tres capas, posee las siguientes desventajas:

• Requiere un control excesivo de las versiones y demandan esfuerzo de distribución de la aplicación cuando se les hacen cambios. Esto se debe al hecho de que la mayoría de la aplicación lógica existe en la estación de trabajo del cliente.
• La seguridad de los datos es compleja, debido al número de dispositivos con acceso directo al ambiente de las bases de datos.
• Se complica la escalabilidad futura del sistema.

hablar un poco de bigadata!

TECNOLOGÍA DE SISTEMAS DE INFORMACIÓN

Para soluciones de Movilidad:

Existen tres posibilidades fundamentalmente → nativas, apps web o híbridas

⇨ Apps nativas.

✔ Están escritas y compiladas directamente para la plataforma.

✔ Su principal ventaja es el rendimiento logrado por la integración con el hardware. Pero esta opción provoca la total dependencia de la plataforma. Por tanto, para más del 95% de los usuarios, tendremos que desarrollar nuestra aplicación en las 3 plataformas más importantes → iOS, Android y Windows.

✔ Otra ventaja es que se consigue una velocidad de respuesta muy alta, si bien hoy en día la diferencia con las híbridas es mínima.

✔ Su principal inconveniente es que supone un desarrollo extra importante porque hay que desarrollar todo el sistema para cada una de las plataformas.

⇨ Apps webs.

✔Son aplicaciones web diseñadas para adaptarse a las pantallas de los dispositivos móviles.

✔La mayor ventaja consiste en la independencia de la plataforma.

✔El inconveniente principal es que todavía está limitado en el acceso a las características más avanzadas de los dispositivos móviles (funciones propias).

Sus principales ventajas son:

✔Las actualizaciones son muy sencillas (cambiando la web la cambias para todo el mundo) por lo que si se van a requerir muchas actualizaciones puede ser útil.

✔Requieren poco tiempo de desarrollo.

✔Abarcan un amplio abanico de dispositivos (móviles, tablets, TV, ...).

⇨ Apps híbridas:

✔Son aplicaciones web, generalmente cliente (no requieren de servidor web), diseñadas para pantallas pequeñas, embebidas en un framework que permite acceder a funciones propias del dispositivo. El resultado es una aplicación nativa para cada plataforma, pero el código es único.

✔Para hacer una aplicación híbrida tienes que utilizar un framework que empaquete tu código HTML5 y javascript convirtiéndolo en una aplicación nativa. ¿Qué es lo que te aporta ese framework? Que desde tu código javascript puedes acceder a funciones propias del dispositivo (GPS, acelerómetro…) utilizando las funciones del framework

✔ Al compilar, el framework transforma esas llamadas en las llamadas nativas de la plataforma para la que estás compilando con lo que, mediante un único código, obtienes una aplicación híbrida para las principales plataformas.

✔Hay una tarifa aplicada por los portales de distribución de aplicaciones de Google y Apple, para poder distribuir nuestra aplicación.

Frameworks para apps móviles:

• jQuery Mobile
• Ionic
• Framework 7
• Apache Cordova (antes PhoneGap)
• Xamarin 🡨 de Microsoft, multiplataforma (iOS, Android, Win)

Productos para la capa de presentación.

Servidor Web.

• Habiendo elegido J2EE en la capa de negocio, una buena opción para la capa de presentación es la representada por el Servidor Web Apache y el contenedor de JSP y Servlets Apache Tomcat.

• Opciones propietarias serían IIS (Microsoft) y Sun One Web Server. A esta capa se accederá mediante navegador web sobre conexiones seguras HTTPS.

Al hablar de la capa de presentación hay que mencionar la Accesibilidad. Dadas las características de los usuarios del sistema será crítico asegurar un correcto nivel de usabilidad y accesibilidad, de acuerdo con lo establecido por los criterios WCAG de la W3C comprobados con el Test de Accesibilidad Web.

Frameworks

• JSF

Productos para la capa de datos.

• Propietarios:

✔ Oracle: robustez, seguridad y amplio soporte.

✔ SQL Server.

• Libres:

✔ MySQL y MariaDB

✔ Postgress SQL: código abierto, estabilidad, seguridad y potencia.

En cuanto a la utilización de Datawarehouse con arquitectura MOLAP, para un cuadro de mandos por ejemplo, habrá que ser coherentes con nuestra solución y con la suposiciones que hagamos:

• Dispone de una solución el organismo-> lo integramos

• Nuestra solución tiene algun Big Data propuesto -> lo meteremos ahí

• Ninguna de las anteriores - > se puede usar la propia BBDD para en datawh sencillo?

Productos para la capa de negocio

Gestor de Portales.

• Liferay: se optará por Liferay considerando su carácter de software de fuentes abiertas, su cumplimiento con el estándar JSR 168 así como la amplia gama de Funcionalidades que incluye, combinando gestión de portales con gestión de contenidos, creación de espacios de trabajo compartidos, gestión de identidades e incluso Funcionalidades 2.0 tales como la creación de redes sociales, que podrían ser explotadas en el futuro.

• Joomla: basado en fuentes abiertas y con licencia GPL. Sin embargo, a diferencia de Liferay, no incluye Funcionalidad de auditoría.

• LocalWEB: a tener en cuenta, es una iniciativa del MITyC (actual MINETAD) enmarcada en el Plan Avanza para generar portales para las Entidades Locales.

• JBoss Portal: plataforma de código abierto para albergar y servir una interfaz de portales Web, publicando y gestionando el contenido, así como adaptando el aspecto de la presentación.

  Gestor de Contenidos.

• OpenCMS: por ser de fuentes abiertas.

• Magnolia: también es de fuentes abiertas.

• Opción reutilizable: LocalWeb del MINETAD.

  Gestor de Formularios.

Su objetivo es la gestión integral del ciclo de vida de un formulario: construcción, conservación, presentación y utilización. Importante considerar el estándar del W3C: XForms.

Tradicionalmente los formularios han sido diseñados utilizando el lenguaje de programación HTML. Sin embargo, recientemente ha aparecido un nuevo estándar definido por el W3C: XForms.

Este estándar ofrece funcionalidades como:

• Validaciones online.

• Integración con servicios Web.

• Guardar el formulario y recuperar sus datos posteriormente.

• Utilizar el resultado de un cuestionario como input de otro distinto.

  ACCEDA → plataforma modular con un completo gestor de sede electrónica y sus expedientes. Incluye un gestor de contenidos de la sede y un editor de formularios propio, así como un gestor de workflow.

Gestor Documental.

• Alfresco: se optará por Alfresco debido que combina las Funcionalidades de gestor documental y motor de workflow, a su facilidad de uso y administración, a su carácter de software de fuentes abiertas y por su elevada extensibilidad y escalabilidad.
• Sharepoint: es la plataforma de gestión documental de Microsoft y, por tanto, es una opción propietaria. Su desventaja es que está limitada a la integración con productos Microsoft.
• Documentum: desarrollado por EMC, dispone de una Funcionalidad potente y completa, sin embargo, es propietario. Motor de Workflow.
• Alfresco: es a la vez gestor documental y motor de workflow de fuentes abiertas.
• JBoss JBPM: motor de workflow escrito en Java y bajo la licencia LGPL que permite ejecutar los procesos que componen un flujo de trabajo especificados en lenguaje BPEL.
• ACCEDA: incluye gestor de wokflow. Servidor de Aplicaciones.
• JBoss: es un servidor de aplicaciones J2EE de código abierto implementado en Java puro. Al estar basado en Java puede utilizarse en cualquier sistema operativo en el que esté disponible Java.
• GlassFish: servidor de aplicaciones, Java EE. De Oracle, pero gratuito, de código libre y se distribuye bajo licencia CDDL y GNU GPL.
• Oracle GlassFish Enterprise Server → versión comercial.
• Websphere (IBM): propietario.