1. DISEÑO DE ARQUITECTURA LOGICA Y FÍSICA
PARA APLICACIONES EMPRESARIALES
Caché
Nodo 1
Nodo 2
Firewall
Servidor de recursos
estáticos
Servidores
de bases de
datos
Nube
Router balanceador
de carga
Nodo 3
Caché
Cluster
Replicación
HTTP, Https, RPC request
Historia:
Conexion
Servidores CDN
Servidor JMS
Servidor de
Documentos Respaldo JMS
Caché
Cliente
Respaldo BD
Balanceador de
carga
Balanceador de
carga
Respaldo de router
1 OBJETIVOS
Proponer una plataforma tecnológica escalable, confiable, segura y de alta
disponibilidad de forma que pueda atender eficiente y eficazmente las
necesidades de los ciudadanos, instituciones públicas y privadas, y
expectativas de modernización institucional.

2. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
2 ARQUITECTURA DE HARDWARE
La arquitectura de hardware comprende principalmente a servidores, routers y
switches a cuales conocemos como equipos, además al medio de
comunicación entre estos (la red). Las capacidades de cada equipo, el número
de equipos, las configuraciones y distribución de los mismos impactan
directamente en el rendimiento y la disponibilidad del servicio. La adquisición
de nuevos equipos de última generación (que normalmente son muy caros) no
necesariamente va a mejorar esos dos aspectos.
La arquitectura propuesta se ilustra en el diagrama Nº1 “Arquitectura para la
alta disponibilidad de los servicios”, cuyos componentes detallamos a
continuación.

3. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
Esquema Nº 1 “Arquitectura para la alta disponibilidad de los servicios-Esquema General”
Caché
Nodo 1
Nodo 2
Firewall
Servidor de recursos
estáticos
Servidores
de bases de
datos
Nube
Router balanceador
de carga
Nodo 3
Caché
Cluster
Replicación
HTTP, Https, RPC request
Historia:
Conexion
Servidores CDN
Servidor JMS
Servidor de
Documentos Respaldo JMS
Caché
Cliente
Respaldo BD
Balanceador de
carga
Balanceador de
carga
Respaldo de router

4. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
Esquema Nº 2 “Arquitectura para la alta disponibilidad de los servicios”
LANInternet
Firewall
Servidor de
recursos estáticos
Router Activo
Servidores
CDN
Servidores de
bases de datos
Servidor JMSServidor de
Documentos
Respaldo JMS
Cliente
Router Backup
Clúster SIO
Familias de Clúster
Bases de datos
Clúster RRCC
Clúster certificación
digital
Clúster AFIS
Clúster PVM y servicios
en línea
Respaldo DB

5. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
Esquema Nº 3 “Configuración típica de un Clúster”
Respaldo balanceador
de carga
Balanceador
de carga
Nodo 1
cache
Nodo 2
cache
Nodo 3
cache
Cluster
Bases de datos
3.1. Nodos
Para nuestro caso, son los servidores de aplicaciones Java EE sobre los
cuales se ejecutan las aplicaciones Java que son accedidos por los
usuarios a través de protocolos HTTP o HTTPs. Son servidores que
implementan estándares de JEE y físicamente están instalados en una
computadora con capacidades de servidor (por ejemplo de tipo blade).
Los nodos deben tener características similares en hardware y deben
proporcionar los mismos servicios.
3.2. Clúster de servidores
Es una configuración de un conjunto de servidores interrelacionados que
se comportan como si fuera uno solo, orquestados por uno o varios
servidores balanceadores de carga, cuya finalidad es de proporcionar

6. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
servicios de: Alto rendimiento, alta disponibilidad, balanceo de carga y
escalabilidad.
Ésta configuración permite fácilmente agregar nuevos servidores cuando
se requiera mayores capacidades del servicio, bajar un servidor para su
mantenimiento o repotenciación, todo esto sin afectar la continuidad del
servicio.
Para lo cual, las sesiones deben ser replicadas entre todos los nodos del
clúster, de modo que si uno de ellos deja de estar disponible, otro nodo
comenzará inmediatamente a proporcionar los servicios sin perder la
sesión del usuario. Esta característica se conoce como replicación de
sesiones, es parte de las especificaciones del estándar JEE y que los
servidores de aplicaciones más populares como Glassfish, OAS, WebLogic
y Jboos lo implementan.
Se debe configurar varios clúster de servidores, cada clúster destinado a
un conjunto de aplicaciones que guarden relación
3.3. Balanceadores de carga
Los balanceadores de carga son servidores web convencionales pero con
una configuración particular que le permite distribuir la carga de número de
peticiones HTTP entre los nodos que conforman el clúster.
El balanceador de carga es un elemento muy importante y crítico en este
esquema de alta disponibilidad, en el sentido de que cualquier caída del
mismo puede afectar la disponibilidad del servicio, por ello se requiere que
tenga un servidor de contingencia.
3.4. Servidor JMS:
El uso de este servidor estaría destinado para servicios de mensajería,
ejecutar proceso por lotes (batch), servicios de consulta, para evitar la
complejidad del acceso y transferencia de datos desde un servidor de
aplicaciones vía protocolo HTTP y HTTPs.

7. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
Un servidor de mensajería por sus propias características de conexión y
protocolos de transmisión de datos, ofrece tiempos de respuesta más
rápidos que un servidor de aplicaciones.
3.5. Servidor de recursos estáticos
Los servidores de recursos estáticos son servidores web convencionales,
no ejecutan sobre algún JVM, cuya finalidad principal es de distribuir los
archivos estáticos como de los tipos: css, js, imágenes, flash y videos que
no cambian con frecuencia.
La estrategia de implementar un servidor para todos los recursos estáticos
de todas las aplicaciones, corresponde a liberar carga a los servidores de
aplicaciones que debieran dedicarse solo a tender peticiones
transaccionales, asimismo se puede aprovechar la reutilización de los
recursos existentes en caché del browser entre distintas aplicaciones ya
que todas invocarán al mismo dominio.
Este tipo de servidores no requiere utilizar cookies, por lo que
recomendamos su desactivación.
3.6. Bases de datos
Los servidores de bases de datos son recursos extremadamente críticos,
debido a que una caída de cualquiera de ellos ocasionará la caída o la
interrupción de servicio de todos los aplicativos que conectan a ella; por lo
tanto, se debe implementar servidores de contingencia sincronizados para
las bases de datos y distribuidos en diferentes locales.
3.7. Router
El router es un recurso crítico, necesariamente debe contar con un
mecanismo de redundancia que se acople a toda la infraestructura
planteada y asegure la alta disponibilidad de los servicios.

8. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
3 ARQUITECTURA DE SOFTWARE
No es posible definir una única arquitectura de software para las aplicaciones,
ya que dependiendo de los requisitos no funcionales del mismo, la arquitectura
y sus componentes pueden variar. Sin embargo podemos recomendar de que
el desarrollo de nuevas aplicaciones siga plenamente los estándares y
patrones de diseño JEE y aproveche los frameworks que implementan dichos
patrones, además de seguir la guía que se menciona en el documento
“Estándar de arquitectura para el desarrollo y mantenimiento de aplicaciones
web” de la Sub Gerencia de Ingeniería de Software.
La arquitectura de software propuesta es presentada en el esquema Nº 3
“Arquitectura de software para aplicaciones empresariales web”, el cual
propone un cambio muy importante en el JVM, se trata de no usar el JDK
habitual de Oracle y remplazarlo por JRockit, que es un JVM mucho más
eficiente en ambientes de producción de alto rendimiento, muestra un
excelente manejo de recursos como CPU y Memoria, Pool de conexiones, etc.
Una arquitectura de software va de la mano con la arquitectura de hardware
descrita en el apartado anterior, al combinar ambos y no descuidar detalles de
ninguno podemos obtener aplicativos de muy alto rendimiento. No diseñar una
buena arquitectura de software puede poner en riesgo todo un esquema físico
por más eficiente que fuera.
El rendimiento de los aplicativos es un tema complejo que lamentablemente no
se trata de un solo aspecto a solucionar, hay diversas consideraciones que en
ocasiones no le damos importancia pero al final suman como parte del
problema o la solución.
Los errores comunes que se cometen en la parte de software son en primer
lugar no seguir estándares y patrones, desarrollar sobre frameworks que no se
dominan o desarrollar con JDK antiguo.

9. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
Esquema Nº 4 “Arquitectura de software para aplicaciones empresariales web”
Servidor de aplicaciones
Sistema Operativo
JROCKIT 1.6 (JVM)
Patrones de diseño Estándares JEE
Aplicaciones empresariales de Reniec
Servidor
Cache
Pool de
Conexiones
Herramientas
de monitoreo
Sesiones
Full Cache
Sistema Operativo
BrowserJVM
JavaScript
Librerías js
imágenes
Peticiones HTTP, HTTPS
Optimización de vistas
Compresión de datos
Servidor de AplicacionesCliente Comunicación
css

10. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
4.1. Servidor de Aplicaciones:
4.3.1. JRockit (Java Virtual Machine)
JRockit es una máquina virtual. Es lo que ejecuta los programas
basados en Java. Está orientado principalmente a servidores de alto
desempeño y rendimiento. Originalmente propiedad de Bea Systems,
quien la desarrolló como el core dentro de la plataforma WebLogic y
liberada en la actualidad con una licencia libre para desarrollo y uso en
producción interno (la licencia es la misma que Sun JDK ha tenido
durante varios años).
JRockit es muy eficiente en el manejo y administración de los recursos
como la Memoria y el CPU, asimismo ofrece un conjunto de
herramientas de diagnóstico como Oracle JRockit Real Time, Oracle
JRockit misión control.
JRockit es un JVM dinámicamente optimizado, por lo que tiene su rendimiento en tiempo
de ejecución basado en algoritmos de muestreo y heurística avanzada. Las herramientas
de JRockit toman ventaja de esta rica información y la proveen al usuario con muy poco
impacto en la aplicación que está corriendo. (http://www.a2econ.com/jsite)
4.3.2. Servidor Caché
El servidor cache guarda los objetos y archivos frecuentemente usados
por el servidor de aplicaciones, ayuda en la rapidez de la ejecución de
un proceso, y por ende mejora el tiempo respuesta al cliente.
4.3.3. Pool de conexiones
El pool de conexiones es un conjunto de conexiones a la base de datos
administrados por el servidor de aplicaciones, permite la reutilización de
las conexiones que requiere un determinado aplicativo.
Todos los aplicativos deben configurar un pool de conexiones, con
parámetros adecuados y de acuerdo a su necesidad, los cuales deben
ser ajustados mediante un procedimiento de test de carga del sistema,

11. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
utilizado herramientas de stress como JMeter y JConsole monitoreando
los parámetros del servidor.
No se recomienda un número mayor a 15 de conexiones abiertas del
pool, ya que cada conexión significa consumo de recursos (memoria) en
el servidor de base de datos.
4.3.4. Memoria
Algunos aplicativos han experimentado problemas con la memoria
dinámica del JVM. La causa puede deberse a diversos aspectos una de
ellas la arquitectura lógica propio del aplicativo, el uso de algún
framework pesado o el no uso de ninguno.
Los frameworks más difundidos en si ya optimizan el uso de la memoria,
es cierto que unos requieren algo más de memoria que otros, pero
normalmente eso no significa un problema. No usar ningún framework y
no desarrollar bajo estándares y patrones de diseño es un verdadero
problema, a parte de hacer difícil el mantenimiento y evolución del
aplicativo, ocasiona problemas de copamiento de memoria.
Por defecto los servidores aplicaciones configuran la memoria dinámica
a 64Mb(PermGen), este parámetro se puede incrementar y se
recomienda que se realice mediante una prueba de sobre carga.
4.3.5. Sesiones
Minimizar el uso de sesiones, por que los servidores de aplicaciones
que pertenecen a un clúster, van a compartir los objetos de sus
sesiones, este proceso puede afectar al rendimiento si la cantidad de
memoria que ocupa cada sesión es muy grande, aproximadamente
encima de los 10Kb.
El uso de sesiones debe realizarse para guardar solamente datos
básicos de la conexión del usuario, como identificación de sesión, login
y algunos parámetros adicionales.

12. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
4.2. Comunicación
4.2.1. Peticiones HTTP, HTTPs
Para cada petición, se debe tener en cuenta la latencia de comunicación
sobre la red, que se evidencia en conexiones satelitales o cuando la pc
cliente se encuentra a mucha distancia de los servidores (caso
consulados de Perú en otros continentes), haciendo mas lenta la
respuesta.
La solución corresponde a aspectos de tecnología de comunicación que
debe ser mejorado, en caso de que no se pueda, las aplicaciones
deberían evitar realizar muchas peticiones HTTP, mientras se haga más
peticiones, el usuario puede percibir lentitud del sistema.
4.3.6. Compresión de datos
Los servidores de aplicaciones tienen la capacidad de comprimir la data
que será devuelta al browser, esta característica no esta configurada
por defecto, aprovechar esta configuración aumentaría la velocidad de
carga de una página.
4.3.7. Optimización de las páginas
Los JSPs se deben optimizar al máximo, en el sentido de aprovechar
los archivos css para decorar la estructura de una página web, los
archivos js para los JavaScripts y éstos no deben contener scriplets.
En muchas ocasiones, los jsps contienen más decoración que
información, se definen funciones JavaScript dentro de una página jsp,
lo cual hace que la trama de respuesta sea considerable y más lenta.
Las páginas que no muestren datos dinámicos, deben ser configuradas
para que permanezcan en el cache del browser, por un año.

13. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
4.3. Cliente
4.3.1. Caché del browser
Se debe aprovechar al máximo el cache del browser para hacer
persistente los archivos estáticos como: css, js, imágenes (jpg, bmp,
png, etc), flash y applets; de modo que el browser no requiera re-cargar
todas las veces que requiera los recursos, no realizará la peticion HTTP
y no se transmitirá ninguna información a través de la red sino será
recuperada del cache.
Esta característica, se puede aprovechar también para páginas jsp que
no muestran datos dinámicos, por lo menos al momento de su carga en
la pantalla.
4.3.2. Memoria de JVM cliente
No es recomendable el uso de applets, el uso de los mismos debe
pasar por una exhaustiva evaluación de alternativas como el uso de
webservice local.
En caso de requerir necesariamente applets, se debe configurar la
memoria dinámica del JVM del cliente, y los permisos necesarios
adecuadamente.
4.3.3. Servicio CDN
Es un esquema conformado de múltiples servidores distribuidos en
diversos puntos a nivel mundial, sirven básicamente para distribuir
recursos estáticos. Se puede aprovechar este esquema para hacer que
la latencia en las conexiones sea menor, ya que el browser descargará
los recursos desde el servidor más cercano a su ubicación gracias al
DNS.

14. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
4 SEGURIDAD
Según el sistema (internet o intranet) se deben tomar medidas adecuadas de
seguridad para garantizar la protección contra vulnerabilidades del sistema,
dependiendo de los requerimientos del aplicativo se debe estudiar la posibilidad
de implementar la transmisión por canal seguro (HTTPS). En algunas
ocasiones será necesario el uso de certificados digitales y/o validación con
huella digital.
El sistema debe ser confiable y seguro al cumplir su propósito sin descuidar el
registro de transacciones (logs) y envíos de alertas o avisos (emails) de
preferencia usando herramientas de mensajería asíncrona que delegan dicha
responsabilidad a servidores especializados en procesos que pueden tomar
tiempos largos, ahorrándole tiempo al servidor de aplicación en su propósito
principal
5 CARACTERISTICAS DE LA INFRAESTRUCTURA
6.1. Viabilidad
La infraestructura propuesta es viable por:
- La arquitectura de hardware no requiere la adquisición de servidores de
última generación. Por el contrario, la infraestructura fue diseñada para
construir un sistema de alto rendimiento, alta disponibilidad y
escalabilidad a bajo costo con servidores normales como por ejemplo del
tipo Blade.
- La arquitectura de software, considerando los altos costos de
licenciamiento de software, puede ser implementada con herramientas
Open Source o haciendo una combinación con el software comercial
producto de un estudio de alternativas y de ventajas que brindan.
- La nueva infraestructura no requiere de un conocimiento especializado
más allá de las propias capacidades exigidas a los actores como los
administradores, arquitectos y programadores.
- En cuanto a la capacitación se puede aprovechar la amplia gama de
información que está disponible en la Internet.

15. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
6.2. Flexibilidad
La infraestructura propuesta es flexible, su implementación no obliga la
utilización de herramientas software y hardware de un determinado
fabricante. Haciendo posible por ejemplo la migración de un determinado
servidor de aplicaciones hacia otro sin ocasionar impacto negativo en las
aplicaciones.
Asimismo, debemos tener en cuenta algunos aspectos que reforzarán la
flexibilidad de la infraestructura:
- Se requiere definir herramientas de desarrollo, producción y monitoreo
que estén de acuerdo con los aspectos más importantes como sencillez,
ligereza, integralidad y rendimiento.
- Los desarrollos de las aplicaciones web, deben estar gestionadas y
construidas de manera simple, en red y estándar, utilizando un servidor
de librerías, simplificando el uso y reusó de librerías, que permita a las
aplicaciones ser migradas de un servidor a otro sin problemas de
dependencias incorrectas, así mismo se agiliza el pase a producción ya
que también se cuenta con un servidor de librerías para el ambiente de
producción.
- Se debe definir procedimientos como estándares para el control de
rendimiento y uso de recursos de aplicaciones web empresariales. Que
permitan controlar la memoria, la rapidez de conexión y la carga de la
aplicación en el navegador.
- Asimismo, considerar el uso de servidores de versionamiento para
dinamizar y organizar los archivos fuente en el desarrollo de los
proyectos. El cual debe contar con su respectivo servidor de
contingencia.
6 ESTRATEGIA DE MIGRACION
Las aplicaciones con nueva implementación y las que recientemente se
pasaron a producción deben migrar a esta nueva infraestructura (caso de SIO,
certificación digital, erep). Para el resto de aplicaciones y según su
característica de ser crítica o no crítica, se debe formar una comisión integrada

16. Diseño de Arquitectura Lógica y Física para Aplicaciones Empresariales
por los Arquitectos de software, Programadores y Administradores de
servidores para evaluar el cumplimiento de recomendaciones mínimas de
arquitectura de software propuesta.