Arquitectura€¦ · componentes arquitecturales del sistema para la implementación del Registro...
Transcript of 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
Arquitectura -2- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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
Arquitectura -3- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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.
Arquitectura -4- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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
Arquitectura -5- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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
Arquitectura -6- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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.
Arquitectura -7- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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.
Arquitectura -8- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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:
Arquitectura -9- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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.
Arquitectura -10- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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.
Arquitectura -11- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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.
Arquitectura -12- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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.
Arquitectura -13- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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.
Arquitectura -14- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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.
Arquitectura -15- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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 -16- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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:
Arquitectura -17- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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.
Arquitectura -18- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
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.
Arquitectura -19- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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
Arquitectura -20- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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
Arquitectura -21- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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 Application Server 5.1.1.5
IBM WebSphere SDK 1.4.2
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:
IBM WebSphere Application Server Network Deployment
5.1.1.5
IBM WebSphere Application Server 5.1.1.5
IBM WebSphere SDK 1.4.2
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:
IBM WebSphere Application Server Network Deployment
5.1.1.5
IBM WebSphere Application Server 5.1.1.5
IBM WebSphere SDK 1.4.2
IBM WebSphere Business Integration Server Foundation 5.1.1.1
DB2 Administration Client 8.2.4
Arquitectura -22- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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
Arquitectura -23- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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:
IBM WebSphere Application Server Network Deployment
5.1.1.8
IBM WebSphere Business Integration Server Foundation 5.1.1.3
IBM WebSphere SDK 1.4.2
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 5.1.1.8
IBM WebSphere SDK 1.4.2
IBM WebSphere Business Integration Server Foundation 5.1.1.3
DB2 Administration Client 8.2.4
Hardware/Software Maquina Nodo2 Procesador: 2 procesadores dual core (3.2 GHz) Memoria: 4 Gb de RAM
Arquitectura -24- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
Disco: 30 Gb de disco duro (RAID 1) S.O.: RED HAT Enterprise linux AS 3 update 3 Software:
IBM WebSphere Application Server 5.1.1.8
IBM WebSphere SDK 1.4.2
IBM WebSphere Business Integration Server Foundation 5.1.1.3
DB2 Administration Client 8.2.4
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.
Arquitectura -25- RESEVI
DIVISIÓN DE INFORMÁTICA Y TECNOLOGIAS DE LA INFORMACIÓN
MINISTERIO DE JUSTICIA
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.