Arquitectura web (página 2)

Partes: 1, 2

EscalabilidadHorizontal. Balanceador SW
Examinan el paquete a nivel del protocolo HTTP para garantizar el mantenimiento de la sesión de usuario.
Distintas peticiones del mismo usuario son servidas por el mismo clon del servidor.
Más lentos que los balanceadores HW
Normalmente son soluciones baratas.
Ej., módulo mod_jk de apache.

EscalabilidadHorizontal. Balanceador HW HTTP
Dispositivos HW que examinan la petición a nivel de paquete HTTP.
Término medio entre las dos anteriores.
Garantizan el mantenimiento de sesión.
Más rápidos que los SW pero menos que los HW.

EscalabilidadVertical
La separación lógica entre capas se implementar de forma que permita la separación física de las mismas.
Es necesario un Middleware entre las capas para permitir la comunicación remota.

(Gp:) Capa 1
(Gp:) Máquina 1
(Gp:) Capa 2
(Gp:) Máquina 1
(Gp:) Capa n
(Gp:) Máquina 1

(Gp:) Sistema completo
(Gp:) Máquina

EscalabilidadCusters de Servidores
Habituales en los servidores de aplicaciones comerciales (Weblogic, WebSphere, iPlanet, etc.).
Dependiendo de cómo se aplique puede clasificarse como horizontal o vertical.
Distribuye y escala el sistema de modo transparente a usuario y administrador.
Garantiza que sea cual sea la máquina que sirva la petición http tendrá acceso a la sesión del usuario (Replicación de sesión)
La replicación de sesión es MUY costosa, produce bajo rendimiento del sistema.

Entonces…¿Qué hacer con la sesión?
Primeras tendencias eran evitar apoyarse en la sesión (objeto Session): sólo había balanceadores hw.
Hoy en día, está aceptado y se fomenta su uso.
OJO! Es MUY delicado. El uso excesivo del objeto session puede acarrear problemas de rendimiento, puesto que los objetos en sesión no se liberan hasta que no caduque la misma.

Separación de Responsabilidades
Premisa base para la separación de capas
Distintas Responsabilidades no deben ser delegadas en la misma clase (separación de incumbencias)
Tendencia actual en aplicaciones WEB:
Arquitectura n-capas
El modelo más básico es el de tres capas:
Capa de presentación
Capa de negocio
Capa de persistencia
Independencia de capas

Separación de Responsabilidades – Evolución
(Gp:)

SERVIDOR
(Gp:) APLICACIÓN

APLICACIONES MAINFRAME
Única capa física y lógica

Separación de Responsabilidades – Evolución
(Gp:)

(Gp:) NEGOCIO Y
ACCESO A DATOS
(Gp:)

(Gp:) PRESENTACIÓN
Y NEGOCIO

Separación Lógica y Física de la interfaz de usuario
CLIENTE
SERVIDOR
APLICACIONES CLIENTE – SERVIDOR

Separación de Responsabilidades – Evolución
(Gp:)

(Gp:)

Negocio +
acceso a datos

(Gp:)

(Gp:)
Presentación

(Gp:) Arquitectura basada en Transaction Scripts (CGIs, Modelo 1)
(Gp:) Interfaz WEB – HTML + lenguaje de script
(Gp:) PRIMERAS APLICACIONES WEB

Separación de Responsabilidades – Evolución
(Gp:)

(Gp:)

(Gp:)

(Gp:) Presentación
(Gp:) Negocio
(Gp:) Persistencia

APLICACIONES 3 CAPAS
(Gp:) JSPs, HTML, lógica de presentación
(Gp:) Lógica de negocio, procesos neg.
(Gp:) Componentes de acceso a datos

Separación de Responsabilidades – Evolución
Modelo de Brown ncapas
(Gp:) JSPs, HTML, lógica de presentación
(Gp:) Lógica de negocio, procesos neg.
(Gp:) Componentes de acceso a datos

(Gp:)

(Gp:)

(Gp:)

(Gp:) Presentación
(Gp:) Negocio
(Gp:) Persistencia

Separación de Responsabilidades – Capa de presentación
Comprende las responsabilidades de lógica de presentación:
Navegabilidad del sistema
Validación de datos de entrada
Formateo de los datos de salida
Internacionalización
Renderizado de presentación
Etc.

Separación de Responsabilidades – Capa de negocio
Comprende las responsabilidades de lógica de negocio (o dominio) del sistema.
Resultado del análisis funcional:
Conjunto de reglas de negocio que abstraen el mundo real.
La capa de negocio ha de ser independiente de la capa de presentación y viceversa (en la medida de lo posible).

Separación de Responsabilidades – Capa de persistencia
Comprende las responsabilidades de lógica de persistencia de las entidades que maneja el sistema en desarrollo.
Inserción
Eliminación
Actualizaciones
Búsquedas
Etc.
No tiene porqué tratarse necesariamente de una base de datos relacional.

Portabilidad
Una aplicación web debe poder adaptarse a las distintas arquitecturas físicas posibles en el despliegue.
Las tareas de adaptación a un nuevo entorno deben limitarse al ámbito de la configuración, no del desarrollo.
Supuesto de ejemplo: Cliente reacio a las tecnologías de componentes J2EE (EJBs) por costes, rendimiento o simplemente, moda.

Componentización de los servicios de infraestructura
¿Servicio de infraestructura?: Componentes independientes del dominio.
Rompen aparentemente la separación vertical de capas.
Dan lugar a la capa de infraestructura.
Ej.:
Servicio de Log
Pool JDBC
Sistema de configuración
Gestor de permisos de acceso
Etc.

Gestión de la sesión del usuario
Aspecto muy delicado del sistema
Cacheado de entidades en
Sesión de usuario
Contexto de la aplicación
Caducidad de la información
Refresco de datos
Rendimiento del sistema. Consumo de recursos del sistema.

Aplicación de patrones de Diseño
Definición de patrón de diseño
GOF 94 Design Patterns
Además de una solución válida para problemas habituales, son un medio de entendimiento que facilita la comunicación entre analista y desarrollador.
Aceleran el desarrollo de Software
Facilitan el mantenimiento
En proceso de integración en las herramientas CASE (Rose, Together, etc.).