MINISTERIO DE JUSTICIA DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN RESEVI. Arquitectura. Arquitectura -1- RESEVI

Transcripción

1 RESEVI Arquitectura Arquitectura -1- RESEVI

2 INDICE 1 OBJETIVO ARQUITECTURA DE LA SOLUCIÓN DIAGRAMA GENERAL DE ARQUITECTURA Arquitectura Seguridad y Servicio de Directorio Estructura de la aplicación Servicio de Mensajería JMS Almacenamiento de Datos Intercambio de Datos Trazabilidad Impresión de Certificados XML - FOP Canales de Acceso Multiidioma Histórico de Datos Sistema de Backup Disponibilidad Componentes de la Aplicación MODELO OPERACIONAL Servidor de Aplicaciones Servidor de LDAP Servidor de Base de datos Servidor de http ENTORNO DE DESARROLLO ENTORNO DE PRE-PRODUCCIÓN ENTORNO DE PRODUCCIÓN DECISIONES ARQUITECTURALES PATRONES DE DISEÑO SEGURIDAD DE LOS WEB SERVICES ROLES DE LA APLICACIÓN MANIPULACIÓN DE DATOS XML...25 Arquitectura -2- RESEVI

3 1 OBJETIVO El objetivo de este documento es la descripción de cada uno los componentes arquitecturales del sistema para la implementación del Registro de Seguros de Vida. A continuación presentamos los objetivos del proyecto. o o o o o o El objetivo del proyecto es la implementación de la LEY 20/2005, de 14 de Noviembre, sobre la creación del Registro de Contratos de Seguros de cobertura de fallecimiento. Se deberá implantar tanto la infraestructura de software de servidor, así como los desarrollos necesarios para que todos los afectados por la implantación de la misma la puedan llevar a cabo. Para el cumplimiento de la ley se deberá tener un sistema de almacenamiento de los datos con todos los contratos de seguros con cobertura de fallecimiento de todos los ciudadanos. Un componente de recepción de los datos de los contratos que serán enviados por las Aseguradoras. Un componente de solicitudes de certificados para que una vez fallecida una persona se pueda consultar si tenía contratados seguros de vida y con que compañía los tenía. Los solicitantes podrán ser cualquier ciudadano a través de un Notario o a través de una oficina de Registro General de Actos de Últimas Voluntades. Un componente de informes que se usará para generar y enviar informes a la Dirección General de Seguros y Fondos de Pensiones, dan información estadística así como de incidencias de los envíos que realizarán de forma periódica las Aseguradoras. Arquitectura -3- RESEVI

4 2 ARQUITECTURA DE LA SOLUCIÓN 2.1. Diagrama general de Arquitectura En este apartado se muestra un diagrama general de la arquitectura del sistema de Registro General de Seguros con cobertura de fallecimiento. Por un lado tendremos las Aseguradoras que serán las encargadas de alimentar la base de datos del Registro con los contratos. Los Notarios y Registradores (Funcionarios del Registro) serán los posibles solicitantes directos de certificados al Registro bajo petición de los ciudadanos. La Dirección General de Seguros y Fondos de Pensiones recibirá los informes de envíos e incidencias producidas por la carga de contratos de las Aseguradoras. En todos estos procesos se usarán firmas y certificaodos que serán validados con la Registro Seguros Vida Notarios Aseguradoras Registro General de Actos de Ultima Voluntad Dirección General de Seguros y Fondos de Pensiones Ciudadanos Arquitectura -4- RESEVI

5 2.1.1 Arquitectura La arquitectura de la aplicación va a estar basada en la arquitectura J2EE y en patrones de diseño ampliamente usados, así como estándares abiertos. Esta arquitectura implementa el patrón de diseño MVC (Model-View- Controller) que nos permite separar en capas la aplicación dividiendo responsabilidades por funcionalidad. Esto proporciona un alto grado de flexibilidad ya que se consigue que al hacer modificaciones en unas capas, no afecten al resto. Model (Modelo): Encapsula los datos y las funcionalidades, siendo independiente del comportamiento de entrada y de la representación de salida. View (Vista): Muestra la información al usuario, recogiendo los datos del modelo. Controller (Controlador): Reciben las entradas, normalmente como eventos de pulsaciones de teclas, ratón, etc Los eventos son traducidos a solicitudes para el modelo o la vista. El usuario interactúa con el sistema a través del controlador. Para implementar la arquitectura J2EE se usará el servidor IBM WebSphere Application Server con soporte para J2EE 1.3. Para implementar la parte del View-Controller del patrón MVC se usará el framework open source Apache Struts ( proyecto perteneciente a The Apache Software Foundation ( Para la implementación de la parte del Modelo, se usará una combinación de EJBs de sesión sin estado (Session Stateless EJB) usando Arquitectura -5- RESEVI

6 para la persistencia clases DAO (Data Acces Object) que mediante JDBC manipulen la información. Para la planificiación de procesos se usará Quartz ( ), un proyecto open source que nos permitirá de una forma fácil planficiar tareas en el servidor de aplicaciones. Se implementarán patrones tipo Service Locator así como el Bussiness Delegate para reducir el grado de dependencia entre las diferentes capas Seguridad y Servicio de Directorio Se tendrá un servicio de directorio LDAP donde se tendrán que dar de alta todos los usuarios que interaccionan con el sistema. También se darán e alta los grupos que luego se asociarán a los roles que se definan. Se usará como servidor de directorio LDAP el Tivoli Directory Server 5.2 de IBM. La autentificación a la aplicación se realizará de varias formas: Aseguradoras: mediante el uso de certificados X.509 expedidos por alguna de las Autoridades de Certificación soportadas por la Esta autenticación será tanto si se accede programáticamente usando los Web Services o bien accediendo al interface Web. Notarios: sólo habrá un usuario que interconectará directamente con el sistema mediante Web Services y será mediante un certificado X.509. Funcionarios del Registro: mediante la introducción de un usuario y contraseña previamente dado de alta en el directorio. Arquitectura -6- RESEVI

7 Funcionario con Firma para los Notarios: mediante la introducción de un usuario y contraseña previamente dado de alta en el directorio. Funcionario con Administrador: mediante la introducción de un usuario y contraseña previamente dado de alta en el directorio. Se generarán varios Módulos Web diferentes ya que a cada uno se le asignará un tipo de autentificación diferente. Todas las comunicaciones entre los usuarios y el sistema se realizarán usando el protocolo SSL. Esto significa que será necesario tener para el servidor un certificado X.509, así como incorporar los CA (Certificate Authority) que se vayan a soportar. Todos los usuarios serán dados de alta en el directorio LDAP, de forma que habrá usuarios que tendrán definida contraseña y otros que mediante un mapeo entre un dato del certificado (Subject) serán asociados a un usuario del directorio. Este proceso de mapeo entre la identidad del certificado X.509 se realizará mediante un proceso (Trusted Interceptor) que se encargará de enviar el certificado para que lo valide, y en caso afirmativo lo buscaremos en el LDAP y le asignaremos el usuario correspondiente. También se darán de alta en el directorio LDAP los usuarios que aunque no tengan acceso al sistema si que van firmar envios desde las aseguradoras. Es decir, las aseguradoras tendran dados de alta usuarios para acceso (envio de movientos), para firma de los envíos o para las dos. Se usará la seguridad J2EE, de forma que se puedan definir los roles que representan la aplicación para poder saber que van a poder ejecutar cada usuario en función del rol asignado. Arquitectura -7- RESEVI

8 Desde la programación de la aplicación se podrá consultar en cualquier momento el rol que tiene un usuario para tomar decisiones de que es lo que se le permite realizar Estructura de la aplicación La aplicación será construida como un J2EE Enterprise Application, siendo empaquetada en un fichero.ear para ser desplegada en el servidor de WAS. Esta aplicación contendrá 3 Módulos Web, que nos permitirá tener un diferente diseño y funcionalidad para cada uno de los actores que intervienen y un Módulo de EJBs donde estará la mayor parte de la lógica de negocio que gestionan el sistema. Modulos Web: RESEVINotarios Interface Web Service para la petición de solicitudes por parte del sistema corporativo de los Notarios. RESEVIRegistro Interface Web para los Funcionarios, para la generación de certificados, así como para los usuarios con firma de las solicitudes de los Notarios, y los usuarios que sean Administradores de la aplicación. Arranque del Planificador con todos los procesos programados. RESEVIAseguradoras Interface Web Service para las Aseguradoras, para el envío de movimientos de contratos. Interface Web para las Aseguradoras, para el envío de movimientos de contratos. Interface Web de consulta de envíos e incidencias. Modulos EJB: RESEVINegocio EJBs de Sesión sin estado: Arquitectura -8- RESEVI

9 AseguradoraEJB SolicitanteEJB AdministracionEJB CertificadoEJB EJBs controlados por mensajes: MDBProcessFile MDBProcessCertificate Modulos JAR de Utilidades RESEVIFirma.jar Clases para la integración que permiten hacer las llamadas a la plataforma para realizar la validación de los certificados, así como la clase que implementa el TrustedInterceptor para interceptar el evento de login en los usuarios que se conectan con certificado X.509 y validarlo en la RESEVINegocioClient.jar Clases cliente que permite el acceso a los EJBs Servicio de Mensajería JMS Hay dos procesos que necesitan trabajar de forma asíncrona dentro de la aplicación, El procesamiento de ficheros grandes y El procesamiento de envio de certificados a Notarios. Para realizar este trabajo de forma asíncrona, se ha usado el servicio JMS, definido en J2EE e implementado en el servidor WebSphere Application Server. Se han construido dos EJBs del tipo MDB (Message Driven Bean) para capturar los mensajes que llegan hasta las colas definidas y realizar el trabajo de forma asíncrona. Arquitectura -9- RESEVI

10 2.1.5 Almacenamiento de Datos Toda la información relativa a la aseguradoras, los contratos, las solicitudes, etc son almacenadas en una base de datos relacional. El servidor de base de datos que se va a utilizar es el IBM DB2 Express- C, este es un servidor de base de datos gratuito. Está basado en la tecnología DB2 Universal Database (UDB) Express Edition Pueden desarrollarse aplicaciones desde diferentes entornos: Java, C/C++,.NET, PHP entre otros. El modelo de datos que representa la información que se guarda en la base de datos está definido en el documento de Modelo de Datos Intercambio de Datos La información que nos envían las Aseguradoras, así como los informes enviados a DGSFP será en formato XML. Para ello se han definido una serie de Esquemas XML que representan el formato de la información que se va a compartir. Para el manejo de la información de los ficheros XML se usará la herramienta XMLBeans 2.0 ( procedente del Apache Software Foundation ( Con esta herramienta nos va a permitir manejar una forma sencilla los ficheros XML que cumplan con los esquemas que hemos definido. Con XMLBeans se parte de un fichero de esquema XML y se construye un fichero.jar donde crea automáticamente una serie de clases que mapean los objetos XML del esquemas con clases Java, para un fácil manejo del fichero XML. Arquitectura -10- RESEVI

11 2.1.7 Trazabilidad Para la generación de los logs de la aplicación se va a utilizar una herramienta open source llamada Log4j ( Este proyecto viene del Apache Software Foundation ( y nos permitirá definir una configuración para la salida del log, así como usar los diferentes niveles Impresión de Certificados XML - FOP Para la generación de los certifcados que se van a imprimir para los solicitantes se generará un fichero en formato PDF (Portable Document Format) que será impreso por el solicitante. Para la generación del pdf se va a utilizar una herramienta open source llamada Apache FOP ( Este proyecto viene del Apache Software Foundation ( y nos permitirá generar los pdfs que se van a imprimir a partir de una plantilla en formato XML-FO a la que modificaremos los datos referentes a la solicitud que se haga para luego aplicarle la conversión a pdf. De esta forma tendremos una plantilla con el diseño y datos estáticos a los que les añadiremos los datos dinámicos para esa solicitud y usando las herramientas de FOP lo convertiremos a pdf. Arquitectura -11- RESEVI

12 2.1.9 Canales de Acceso El acceso al sistema de Registro de Seguros será multicanal. Inicialmente se implementarán dos canales para interactuar con el sistema: Interface Web Este canal será usado por los solicitantes de certificados, así como por las aseguradoras para el envío de contratos. Este canal será de acceso seguro usando SSL y protegido el acceso o bien con certificados de cliente X.509 (Aseguradoras) o bien por validación de usuario y contraseña (Funcionarios del Registro). Interface Web Services Este canal será usado por las aseguradoras para el envío de contratos y por los notarios para el envío de las solicitudes de certificados. Este canal será de acceso seguro usando SSL para acceder a los Web Services, en el caso de las aseguradoras se usará un certificado X.509 para validar la identidad del usuario en el transporte. En un futuro se podrán añadir nuevos canales de acceso para dar servicio a otros dispositivos o formas de acceso al sistema Multiidioma Los certificados expedidos podrán ser pedidos en cualquier de los idiomas oficiales del Estado Español. Desde el interface de solicitud se podrá elegir el idioma en el que quiere que aparezca el texto del certificado. El Ministerio de Justicia proporcionara los textos traducidos a los diferentes idiomas a partir del texto en Español. Arquitectura -12- RESEVI

13 Histórico de Datos Dado el gran volumen de datos que se va a manejar será importante descargar al sistema de todos aquellos datos que no sean necesarios. Dentro del modelo de datos hay 3 tipos de datos que van a tener un gran volumen de información: Solicitudes, Contratos y Personas. Las solicitudes podrán ser susceptibles de ser borradas pasado cierto tiempo ya que una vez hecha una solicitud, habrá que esperar un tiempo por si hubiera un certificado correctivo. Pero una vez transcurrido ese tiempo se podrá borrar el registro. Tantos los contratos como las personas son datos que deberán permanecer en el sistema y aunque se hayan dado de baja o caducado deberán permanecer por si hiciera falta auditar esa información. Para que el tener almacenada toda esta información no impacte en el rendimiento del sistema se pasarán a tablas auxiliares para poder ser usadas en cualquier momento Sistema de Backup Será necesario definir una política de backup del sistema del Registro de Seguros. El backup habrá que realizarlo de todos los elementos que componen el sistema para poder recuperar el sistema de cualquier problema conocido. Los elementos a realizar copias de seguriad son: Base de datos: necesitaremos realizar un backup de los datos almacenados para poder recuperarlos en caso de algún problema. Los backups se podrán realizar con las propias herramientas de DB2 o utilizar cualquier otra herramienta de backup compatible con DB2. LDAP: necesitaremos realizar un backup del directorio LDAP, tanto de la parte de configuración como de los datos introducidos. Los datos introducidos están dentro de una base de datos DB2. La política de backup de este componente no será muy frecuente ya que una vez realizada la primera carga de usuarios (Notarios, Funcionarios y Aseguradoras) serán muy pocos los cambios que habrá que realizar. Arquitectura -13- RESEVI

14 WebSphere Application Server: necesitaremos realizar un backup de la configuración del servidor de WAS, así como de la aplicación (el.ear) para que n cualquier momento poder reconstruir el sistema. La política de backup de este componente no será muy frecuente ya que una vez realizada la configuración del WAS y la instalación de la aplicación no se debería tener que hacer copias de seguridad. IHS: necesitaremos realizar backup de la configuración del IHS, tanto del httpd.conf así como del plugin-cfg.xml (aunque este estará tambien en el servidor WAS) Disponibilidad La aplicación del Registro General de Seguros estará en alta disponibilidad. Inicialmente no se estima demasiada carga de trabajo ya que el trabajo más duro, serán las cargas iniciales de los contratos por parte de las Aseguradoras que será bajo control especial. Y en cuanto a las peticiones de solicitudes habrá alrededor de potenciales usuarios que podrán realizar peticiones y con un bajo nivel de concurrencia inicialmente. Aunque las peticiones originadas por los Notarios (3.000 usuarios) vendrán centrales por un único punto a través de un Web Service que comunica con RENO (Red Notarial) Componentes de la Aplicación En este apartado se describen los componentes que forman parte del sistema de Registro de Seguros y que en el documento de Análisis Funcional están explicados en detalle. Estos componentes están repartidos entre los diferentes Modulos Web y Modulo de EJB de la aplicación que se despliegue. Autenticación y Directorio Controla el acceso a la aplicación haciendo la autenticación así como el mapeo de certificados Gestión de envío de datos. Gestiona el envío de los contratos que realizan las aseguradoras, tanto con el interface Web, así como a través del interface Web Services. Arquitectura -14- RESEVI

15 Gestión de solicitudes. Gestiona el flujo de petición de certificados tanto para Notarios como para los Funcionarios del Registro. Gestión de informes. Gestiona la generación de informes que se envían a la DGSFP. Gestión de estadísticas. Gestiona la generación de las estadísticas que tanto los administradores así como las aseguradoras podrán visualizar. Gestión de usuarios y Aseguradoras/Oficinas Gestiona el alta, baja y modiciación de la información de usuarios tanto de Aseguradoras como del Registro, gestionando a su vez las Aseguradoras definidas, así como las oficinas del Registro. Procesos automáticos del sistema. Habrá una serie de tareas que se realizarán de forma planificada dentro del sistema. Estas tareas son: Envío de informes Borrado de solicitudes expiradas. Borrado de informes expirados. Histórico de personas, contratos. Certificados correctivos. Carga de usuarios. Listas de revocación de certificados 2.2. Modelo Operacional En este apartado describiremos como los componentes se ajustan dentro del entorno operativo para llevar a cabo la ejecución del sistema, así como describiendo como los usuarios van a acceder e interactuar con la aplicación Para la puesta en marcha de la aplicación de Registro General de Seguros se montaran varios entornos: Desarrollo (Herramientas), Pre- Producción y Producción. Antes de pasar a describir los diferentes entornos veamos un acercamiento al uso del sistema, viendo como los diferentes actores interactúan con él. Arquitectura -15- RESEVI

16 Los usuarios que interactúan con la aplicación estarán situados bien desde Internet (Aseguradoras, DGSFP), bien desde RENO (Red Notarial), o bien desde la propia red del Ministerio de Justicia (Funcionarios Registro). Esto significa que accederán de una forma claramente diferenciada al sistema. INTERNET RENO Aseguradoras DGSFP SSL SSL SSL Red Interna Ministerio de Justicia SSL Registro General de Seguros de Vida SSL Registradores Para la puesta en marcha de la aplicación de Registro de Seguros será necesarios implantar una serie de componentes de software: Arquitectura -16- RESEVI

17 2.2.1 Servidor de Aplicaciones Será el servidor WAS, donde se instalará la aplicación con los diferentes módulos Web, así como EJBs. Este servidor deberá tener instalado la parte de mensajería Servidor de LDAP Será el servidor Tivoli Directory Server 5.2, se darán de alta todos los usuarios y grupos que accederán al sistema Servidor de Base de datos Será el servidor DB2 Express-C, y se usará para almacenar toda la información relativa a los contratos, personas, solicitudes, así como los ficheros xml que se intercambian con las aseguradoras o la DGSFP Servidor de http Será el servidor IHS (IBM HTTP Server) 2.0, y se usará como el HTTP Front-End. Deberá haber un servidor IHS en la DMZ (Zona Desmilitarizada del Firewall) para todos los accesos desde INTERNET y otro IHS para los accesos desde dentro de la red interna del Ministerio de Justicia. Arquitectura -17- RESEVI

18 Aseguradoras SSL DMZ RENO Notarios INTERNET Servidor HTTP Fron-End Red Interna SSL Servidor WebSphere Application Server 5.1 Servidor DB2 Servidor HTTP Fron-End SSL Servidor LDAP Registradores 2.3. Entorno de Desarrollo El entorno de desarrollo deberá proporcionar todos los elementos para poder hacer el desarrollo y posterior mantenimiento de la aplicación. Herramientas de Desarrollo Se usarán las siguientes herramientas para el diseño y desarrollo de la aplicación: Rational Application Developer (RAD), Rational Software Modeler (RSM), Rational Software Architect (RSA), Rational ClearCase LT. También será necesario un servidor en el que pondremos todos los componentes software citados anteriormente. Arquitectura -18- RESEVI

19 Desarrollo IHS Red Interna Server1 (aplicaciones y jms) WAS DB2 TDS (LDAP) (Tivoli Directory Server) Hardware/Software Procesador: 1 procesador (3.2 GHz) Memoria: 2 Gb de RAM Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 6 Software: IBM IHS IBM Directory Server DB2 Enterprise Server IBM WebSphere Application Server IBM WebSphere SDK IBM WebSphere Business Integration Server Arquitectura -19- RESEVI

20 2.4. Entorno de Pre-Producción El entorno de pre-producción deberá ser lo más parecido posible al entorno de producción ya que aquí se deberán realizar las pruebas funcionales para validar el correcto funcionamiento de la aplicación, así como pruebas de carga para ver la capacidad y estabilidad del sistema. Pre-Producción IHS DMZ IHS Red Interna Deployment Manager Cluster WAS Nodo1 JMS1 Nodo2 JMS2 WAS WAS DB2 TDS (LDAP) (Tivoli Directory Server) Hardware/Software Maquina IHS DMZ Procesador: 1 procesador dual core (3.2 GHz) Memoria: 2 Gb de RAM Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 6 Software: IBM IHS Hardware/Software Maquina Deployment Manager/IHS Interno Arquitectura -20- RESEVI

21 Procesador: 1 procesador dual core (3.2 GHz) Memoria: 2 Gb de RAM Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 3 Software: IBM IHS IBM WebSphere Application Server Network Deployment IBM WebSphere Application Server IBM WebSphere SDK IBM WebSphere Business Integration Server Foundation IBM WebSphere Business Integration Server Hardware/Software Maquina Nodo1 Procesador: 1 procesador dual core (3.2 GHz) Memoria: 2 Gb de RAM Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 3 Software: IBM WebSphere Application Server Network Deployment IBM WebSphere Application Server IBM WebSphere SDK IBM WebSphere Business Integration Server Foundation DB2 Administration Client Hardware/Software Maquina Nodo2 Procesador: 1 procesador dual core (3.2 GHz) Memoria: 2 Gb de RAM Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 3 Software: IBM WebSphere Application Server Network Deployment IBM WebSphere Application Server IBM WebSphere SDK IBM WebSphere Business Integration Server Foundation DB2 Administration Client Arquitectura -21- RESEVI

22 Hardware/Software Maquina DB2/LDAP Procesador: 1 procesador dual core (3.2 GHz) Memoria: 2 Gb de RAM Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 3 Software: IBM Directory Server 5.2 DB2 Enterprise Server Entorno de Producción El entorno de producción será el que de servicio a la aplicación. En este entorno interviene un servidor en la DMZ, donde estará situado el IHS (IBM HTTP Server) que hará de intermediario entre las peticiones que vienen de Internet y el servidor de WAS dentro de la Red del Ministerio de Justicia. Producción IHS DMZ Red Interna IHS Cluster WAS Nodo1 JMS1 Nodo2 JMS2 WAS WAS Deployment Manager DB2 TDS (LDAP) (Tivoli Directory Server) Arquitectura -22- RESEVI

23 Hardware/Software Maquina IHS DMZ Procesador: 1 procesador dual core (3.2 GHz) Memoria: 2 Gb de RAM Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 6 Software: IBM IHS Hardware/Software IHS Interno Procesador: 1 procesador dual core (3.2 GHz) Memoria: 2 Gb de RAM Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 4 update 4 Software: IBM IHS Hardware/Software Maquina Deployment Manager Procesador: 1 procesador dual core (3.2 GHz) Memoria: 2 Gb de RAM Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 3 Software: IBM WebSphere Application Server Network Deployment IBM WebSphere Business Integration Server Foundation IBM WebSphere SDK Hardware/Software Maquina Nodo1 Procesador: 2 procesadores dual core (3.2 GHz) Memoria: 4 Gb de RAM Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 6 Software: IBM WebSphere Application Server IBM WebSphere SDK IBM WebSphere Business Integration Server Foundation DB2 Administration Client Hardware/Software Maquina Nodo2 Procesador: 2 procesadores dual core (3.2 GHz) Memoria: 4 Gb de RAM Arquitectura -23- RESEVI

24 Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 3 Software: IBM WebSphere Application Server IBM WebSphere SDK IBM WebSphere Business Integration Server Foundation DB2 Administration Client Hardware/Software Maquina DB2/LDAP Procesador: 2 procesador dual core (3.2 GHz) Memoria: 4 Gb de RAM Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 6 Software: IBM Directory Server 5.2 DB2 Enterprise Server DECISIONES ARQUITECTURALES 3.1. Patrones de diseño Se han decido usar una serie patrones de diseño para facilitar la separación en las diferentes capas, así como el desacoplamiento de las mismas y el desarrollo más sencillo. Los patrones son: MVC (Model View Controller), usando Apache Struts para la implementación del View y Controller. Service Locator Bussiness Delegate EJB de sesión sin estado Persistencia mediante DAO (Data Access Object) 3.2. Seguridad de los Web Services Se ha decido usar como sistema de seguridad para los Web Services implementar el transporte con HTTPS ( HTTP con SSL). De esta forma se podrá construir de forma simple los clientes de Web Services que usando este transporte y el certificado X.509 puedan acceder a la aplicación. Arquitectura -24- RESEVI

25 En el caso de las Aseguradoras la autenciación se hace en el transporte usando certificado X.509, además de ir el fichero XML con los movimientos firmado Roles de la aplicación La implementación de los roles de la aplicación se realizará usando la seguriad J2EE, de forma que se definirán roles a nivel del descriptor de despliegue de la aplicación y posteriormente serán mapeados en grupos del directorio LDAP Manipulación de datos XML Para la manipulación de la información en formato XML se ha elegido la herramienta XMLBeans que permite hacer un mapeo del esquema XML en clases Java, para su directa utilización. Arquitectura -25- RESEVI