arquitectura€¦ · componentes arquitecturales del sistema para la implementación del registro...

Arquitectura -1- RESEVI

DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN

MINISTERIO DE JUSTICIA

RESEVI

Arquitectura




INDICE

1 OBJETIVO ..........................................................................................................................................3

2 ARQUITECTURA DE LA SOLUCIÓN ..........................................................................................4 2.1. DIAGRAMA GENERAL DE ARQUITECTURA ...........................................................................................4

2.1.1 Arquitectura ...............................................................................................................................5 2.1.2 Seguridad y Servicio de Directorio........................................................................................6 2.1.3 Estructura de la aplicación ......................................................................................................8 2.1.4 Servicio de Mensajería JMS ....................................................................................................9 2.1.5 Almacenamiento de Datos ....................................................................................................10 2.1.6 Intercambio de Datos.............................................................................................................10 2.1.7 Trazabilidad ..............................................................................................................................11 2.1.8 Impresión de Certificados XML - FOP .................................................................................11 2.1.9 Canales de Acceso ..................................................................................................................12 2.1.10 Multiidioma ...............................................................................................................................12 2.1.11 Histórico de Datos...................................................................................................................13 2.1.12 Sistema de Backup .................................................................................................................13 2.1.13 Disponibilidad...........................................................................................................................14 2.1.14 Componentes de la Aplicación .............................................................................................14

2.2. MODELO OPERACIONAL........................................................................................................................15 2.2.1 Servidor de Aplicaciones .......................................................................................................17 2.2.2 Servidor de LDAP ....................................................................................................................17 2.2.3 Servidor de Base de datos ....................................................................................................17 2.2.4 Servidor de http ......................................................................................................................17

2.3. ENTORNO DE DESARROLLO ...............................................................................................................18 2.4. ENTORNO DE PRE-PRODUCCIÓN ......................................................................................................20 2.5. ENTORNO DE PRODUCCIÓN ...............................................................................................................22 3 DECISIONES ARQUITECTURALES ..........................................................................................24 3.1. PATRONES DE DISEÑO .......................................................................................................................24 3.2. SEGURIDAD DE LOS WEB SERVICES.................................................................................................24 3.3. ROLES DE LA APLICACIÓN .................................................................................................................25 3.4. MANIPULACIÓN DE DATOS XML.......................................................................................................25




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 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.

o 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.

o 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.

o Un componente de recepción de los datos de los contratos

que serán enviados por las Aseguradoras.

o 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.

o 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.




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 plataforma @Firma.

RegistroSeguros

Vida

AseguradorasNotarios

Ciudadanos

Registro Generalde Actos de

Ultima VoluntadDirección General

de Seguros y Fondosde Pensiones

Plataforma@Firma




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 5.1.1 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 (http://struts.apache.org),

proyecto perteneciente a The Apache Software Foundation

(http://www.apache.org).

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




para la persistencia clases DAO (Data Acces Object) que mediante JDBC

manipulen la información.

Para la planificiación de procesos se usará Quartz (

http://www.opensymphony.com ), 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.

2.1.2 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

Plataforma @Firma. 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.




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 a @Firma 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.




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.

2.1.3 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:




AseguradoraEJB

SolicitanteEJB

AdministracionEJB

CertificadoEJB

EJBs controlados por mensajes:

MDBProcessFile

MDBProcessCertificate

Modulos JAR de Utilidades

RESEVIFirma.jar

Clases para la integración con @Firma, 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 plataforma @Firma.

RESEVINegocioClient.jar

Clases cliente que permite el acceso a los EJBs.

2.1.4 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.




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 8.2.2.

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.

2.1.6 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 (http://xmlbeans.apache.org)

procedente del Apache Software Foundation

(http://www.apache.org). 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.




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

(http://logging.apache.org/log4j). Este proyecto viene del Apache

Software Foundation (http://www.apache.org), y nos permitirá

definir una configuración para la salida del log, así como usar los

diferentes niveles.

2.1.8 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 (http://xmlgraphics.apache.org/fop). Este

proyecto viene del Apache Software Foundation

(http://www.apache.org), 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.




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.

2.1.10 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.




2.1.11 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.

2.1.12 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.




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). 2.1.13 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 3.100

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)

2.1.14 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.




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.




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.

Registro General deSeguros de Vida

AseguradorasNotarios

Registradores

INTERNET

Red InternaMinisterio de Justicia

SSLSSL

SSL

DGSFP

RENO

SSL

@Firma SSL

Para la puesta en marcha de la aplicación de Registro de Seguros

será necesarios implantar una serie de componentes de software:




2.2.1 Servidor de Aplicaciones Será el servidor WAS, 5.1.1 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.

2.2.2 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.

2.2.3 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.

2.2.4 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.




ServidorWebSphere Application

Server 5.1

ServidorLDAP

ServidorDB2

ServidorHTTP Fron-End

ServidorHTTP Fron-End

DMZ

Red Interna

Aseguradoras

Registradores

INTERNET

SSL

SSL

NotariosRENO

SSL

@Firma

SSL

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.




WAS 5.1.1

TDS (LDAP)(Tivoli Directory Server)DB2

IHSRed Interna

Desarrollo

Server1 (aplicaciones y jms)

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 2.0.47 IBM Directory Server 5.2.4 DB2 Enterprise Server 8.2.4

IBM WebSphere Application Server 5.1.1.5

IBM WebSphere SDK 1.4.2

IBM WebSphere Business Integration Server




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.

WAS 5.1.1

TDS (LDAP)(Tivoli Directory Server)

DB2

IHS

Red Interna

Pre-Producción

WAS 5.1.1

IHS

DMZ

DeploymentManager

Nodo1 Nodo2JMS1 JMS2

Cluster WAS

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 2.0.47

Hardware/Software Maquina Deployment Manager/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 3 update 3 Software: IBM IHS 2.0.47

IBM WebSphere Application Server Network Deployment

5.1.1.5



IBM WebSphere Business Integration Server Foundation 5.1.1.1 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:


5.1.1.5



IBM WebSphere Business Integration Server Foundation 5.1.1.1

DB2 Administration Client 8.2.4

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:


5.1.1.5








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 8.2.4

2.5. 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.

WAS 5.1.1

TDS (LDAP)(Tivoli Directory Server)

DB2

IHSRed Interna

Producción

WAS 5.1.1

IHS

DMZ

DeploymentManager

Nodo1 Nodo2JMS1 JMS2

Cluster WAS




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 2.0.47

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 2.0.47

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:


5.1.1.8



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:





Hardware/Software Maquina Nodo2 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 3 Software:





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 8.2.4

3 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.




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.

3.3. 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.

3.4. 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€¦ · componentes arquitecturales del sistema para la implementación del registro...

Documents