PATRONES DE ARQUITECTURA WEB

Jair A Monsalve Martínez

Neider Tavera Puerta
 PATRONES DE ARQUITECTURA WEB
 Los patrones de arquitectura Web representan una aplicación, o
una pieza de la interfaz de una aplicación, como patrones comunes
que pueden ser reutilizados.
 ASPECTOS GENERALES EN LA ARQUITECTURA
WEB

 Escalabilidad

 Separación de responsabilidades

 Portabilidad

 Componentización de los servicios de

 infraestructura

 Gestión de la sesión del usuario, cacheado

 de entidades

 Aplicación de patrones de diseño

 ESCALABILIDAD
 Característica principal de las apps WEB:
Posible incremento vertiginoso del número de usuarios

 Es importante:
 El correcto dimensionamiento de la aplicación
 La adaptabilidad del sistema ante el incremento de demanda.

 Varias opciones:
 Escalabilidad Horizontal
 Escalabilidad Vertical
 Cluster de servidores
 ESCALABILIDAD HORIZONTAL
Se clona el sistema y se balancea la carga

sistema sistema

Usuarios Balanceador
de Internet

sistema sistema
 ESCALABILIDAD
HORIZONTAL. BALANCEADOR HW
 Distribuye por algoritmos predeterminados (Round Robin,LRU, etc.) las
peticiones HTTP entre los distintos clones del sistema

 La selección del clon es por tanto aleatoria

 Problema: No garantiza que diferentes peticiones de un mismo usuario sean

servidas por el mismo clon del sistema (No hay mantenimiento de la sesión del
usuario en Servidor) (Condiciona el Diseño).

 La sesión la debe mantener el desarrollador por otros medios (Cookies, base de

datos)

 Al ser un proceso HW, es MUY rápido

 ESCALABILIDAD
HORIZONTAL. 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. Por ejemplo (módulo

mod_jk de apache)
 ESCALABILIDAD
HORIZONTAL. 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.

 ESCALABILIDAD
VERTICAL

 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.
 ESCALABILIDAD
CUSTERS 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.
¿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
 APLICACIONES MAINFRAME

APLICACIÓN

SERVIDOR

ÚNICA CAPA FISICA Y LOGICA

 SEPARACIÓN
DE RESPONSABILIDADES – EVOLUCIÓN
 APLICACIONES CLIENTE - SERVIDOR

CLIENTE PRESENTACIÓN Y
NEGOCIO

SERVIDOR
NEGOCIO Y ACCESO A
DATOS

SEPARACION LÓGICA Y FISICA DE LA INTERFAZ DE USUARIO

 SEPARACIÓN
DE RESPONSABILIDADES – EVOLUCIÓN
 PRIMERAS APLICACIONES WEB
( Arquitectura basada en Transaction Scripts)

INTERFAZ WEB – HTML +

PRESENTACIÒN LENGUAJE DE SCRIPT

NEGOCIO + ACCESO
A DATOS
 SEPARACIÓN
DE RESPONSABILIDADES – EVOLUCIÓN
 APLICACIONES 3 CAPAS

JSP, HTML, LÓGICA

DE PRESENTACIÓN
PRESENTACIÓN

LÓGICA DE NEGOCIO,
NEGOCIO PROCESOS DE NEGOCIO

COMPONENETES DE
PERSISTENCIA
ACCESO A DATOS
 SEPARACIÓN
DE RESPONSABILIDADES – EVOLUCIÓN
 Modelo de Brown n capas

JSP, HTML, LÓGICA

DE PRESENTACIÓN
PRESENTACIÓN

LÓGICA DE NEGOCIO,
NEGOCIO PROCESOS DE NEGOCIO

COMPONENETES DE
PERSISTENCIA
ACCESO A DATOS
 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.)
 PATRONES DE ARQUITECTURA WEB
 Los tres patrones más comunes:

 Thin ClientWeb

 Thick Web Client

 Web Delibery
 THIN WEB CLIENT
 El patrón arquitectural ThinWeb Client es útil para
aplicaciones basadas en Internet, en donde se garantice una
configuración mínima del lado del cliente. Toda la lógica de
negocio se ejecuta en el servidor durante el cumplimiento a
las solicitudes de página que realiza el navegador del cliente.
 APLICABILIDAD

 Este patrón es el más apropiado para las aplicaciones Web

basados en Internet o para aquellos entornos en donde los
clientes tenga una configuración mínima o ningún control
sobre su configuración.
 USOS CONOCIDOS
 La mayoría de las aplicaciones de comercio electrónico de
Internet utilizan este patrón, puesto que, empresarialmente,
no tiene sentido eliminar ningún sector de clientes
simplemente porque no tenga las suficientes capacidades de
cliente. Una aplicación de comercio electrónico típica intenta
llegar al mayor número de clientes posible; después de todo,
el dinero de un usuario de Commodore Amiga es tan bueno
como el de un usuario de Windows NT.
 ESTRUCTURA

 Browser del cliente

 Servidor Web
 Conexión HTTP
 Página HTML
 Página del servidor
 Servidor de aplicaciones
VISTA LÓGICA DE LA ARQUITECTURA DE CLIENTE
WEB FINO
VISTA LÓGICA DEL PATRÓN DE ARQUITECTURA
DEL CLIENTE WEB FINO COMPLETA
 DINÁMICA
 El punto clave del comportamiento dinámico de este patrón
es que la lógica empresarial sólo se invoca durante el proceso
de una solicitud de página. Una vez que se ha completado la
solicitud de página, el resultado se devuelve al cliente que la
solicita y se finaliza la conexión entre el cliente y el servidor.
Un proceso empresarial puede perdurar después de que se
haya completado la solicitud, pero no es la norma.
 CONSECUENCIAS
 Este tipo de arquitectura se adapta mejor a las aplicaciones con
respuestas de servidor que se pueden completar en el tiempo de
respuesta aceptable para el usuario (y en el valor de tiempo de
espera excedido que permite el navegador del cliente). Esto suele
no suele tardar más que unos cuantos segundos. Puede que este no
sea el patrón de arquitectura más apropiado si la aplicación debe
permitir al usuario iniciar y supervisar un proceso empresarial que
dure mucho tiempo. No obstante, las tecnologías push se pueden
utilizar para permitir al cliente supervisar los procesos que llevan
tiempo ejecutándose. Por lo general, las tecnologías push sólo
utilizan sondeos periódicos del servidor.
 THICK WEB CLIENT
 El patrón de arquitectura Thick Web Client extiende el
modelo ThinWeb Client con el uso de secuencias de
comandos (scripts) del lado del cliente y los objetos
personalizados, como los controles ActiveX y Applets de Java.
El patrón Thick Web Client recibe el nombre de que el
cliente puede ejecutar alguna lógica de negocio del sistema y
por lo tanto se convierte en algo más que una interfaz de
usuario contenedor generalizado.
 APLICABILIDAD
 El patrón de arquitectura Thick Web Client es el más
apropiado para aplicaciones Web en donde una cierta
configuración del cliente y versión del navegador pueda ser
asumida, si se desea una sofisticada interfaz de usuario, y/o
cierta cantidad de lógica de negocio puede ser ejecutado en
el cliente. Gran parte de la distinción entre los patrones Thin
Web Client y Thick Web Client se encuentra en el papel del
navegador juega en la ejecución de lógica de negocio del
sistema.
 USOS CONOCIDOS
 Los usos más obvios de los scripts del lado del cliente,
applets, controles y complementos de ActiveX está en
Internet en forma de interfaces de usuario mejoradas. Los
scripts de Java se utilizan a menudo para cambiar el color o la
imagen de un botón o elemento de menú en las páginas
HTML. Las Applets Java y los controles ActiveX se usan a
menudo para crear sofisticados controles jerárquicos,
árboles.
 ESTRUCTURA

 Script de cliente
 Documento XML
 Control ActiveX
 Applet de Java
 Java Bean
VISTA LÓGICA DE LA ARQUITECTURA THICK WEB
CLIENT.
 DINÁMICA
 Las dinámicas principales del patrón Thick Web Client
incluyen a los de ThinWeb Client más la capacidad de
ejecutar la lógica de negocio en el cliente. Al igual que con el
patrón Thin Web Client, todas las comunicaciones entre el
cliente y el servidor se realizan en las solicitudes de página.
La lógica de negocio sin embargo, puede ser parcialmente
ejecutada en el cliente con scripts, controles o applets.
 CONSECUENCIAS
 Como mucho, la mayor consecuencia de este patrón es la
portabilidad a través de implementaciones de navegador. No
todos los navegadores HTML soporte Java Script o Virtual
Basic. Además sólo los clientes de Microsoft basados en
Windows puede utilizar los controles ActiveX. Incluso
cuando una determinada marca de navegador del cliente se
utiliza exclusivamente existen diferencias sutiles en las
implementaciones del Document Object Model.
 WEB DELIVERY
 se llama así porque la Web se utiliza principalmente como un
mecanismo de entrega de otro modo tradicional de objetos
distribuidos sistema cliente-servidor. Desde un punto de vista este
tipo de aplicación es en realidad un objeto distribuido cliente-
servidor de aplicaciones que incluye un servidor Web y el
navegador cliente como importantes elementos arquitectónicos. Si
este sistema es una aplicación Web con objetos distribuidos o un
sistema de objetos distribuidos con elementos Web el último
sistema es el mismo.
 APLICABILIDAD
 El patrón de arquitectura Web Delivery es el más apropiado
cuando hay un control significativo sobre el cliente y
configuraciones de red. Este patrón no es especialmente
adecuado para aplicaciones basadas en Internet, donde no hay,
o muy poco control sobre las configuraciones de cliente, o
cuando las comunicaciones de red no son confiables.
 USOS CONOCIDOS
 El sitio Web de CNN Interactive es uno de los sitios más
concurridos de noticias en la red. La mayor parte de su
acceso al público se realiza con los navegadores
convencionales y recta HTML 3.2, sin embargo detrás del
sitio Web hay una sofisticada red basada en CORBA de los
navegadores, servidores, y los objetos distribuidos. Un caso
de estudio de este sistema publicó la computación
distribuida.
 ESTRUCTURA

 DCOM
 RMI (JRMP)
VISTA LÓGICA DEL PATRÓN DE ARQUITECTURA DE
DISTRIBUCIÓN WEB.
 DINÁMICA
 Las principales dinámicas del modelo arquitectónico Web
Delivery son el uso del navegador para ofrecer un sistema de
objetos distribuidos. El navegador se utiliza para contener
una interfaz de usuario y algunos objetos de negocio que se
comunican, independientemente del navegador para los
objetos en el niverl del servidor. Las comunicaciones entre el
cliente y el servidor se realizan los objetos con los protocolos
IIOP, RMI y DCOM.
 CONSECUENCIAS
 Como mucho, la mayor consecuencia de este patrón es la
portabilidad a través de implementaciones de navegador. El
uso de este patrón requiere una red sólida. Las conexiones
entre el cliente y el servidor duran mucho más que las
conexiones HTTP.
MUCHAS GRACIAS