Arquitectura web

Arquitectura
Web

Introducción
¡ Concepto de Arquitectura en Desarrollo Software
l Concepción desde RUP
¡ Arquitectura física
¡ Distribución de nodos en la red
¡ Mapeo componente software – nodo computacional
¡ Concepto de Arquitectura software Moderno
l Patrones de diseño de arquitectura
l Separación de responsabilidades
l No existe forma de representar arquitectura
software con las herramientas actuales (RUP-UML)

PDF Creator - PDF4Free v2.0 http://www.pdf4free.com
1

Aplicaciones Web
con Java
¡ Fuerte apuesta por parte del sector privado:
l Sun Microsystems. Extensiones J2EE
l BEA Systems con Weblogic
l IBM con WebSphere
l Netscape (y Sun) con iPlanet
l Orión – Oc4J Oracle 9IAS
¡ Fuerte apuesta del mundo opensource!
l www.apache.org Desarrollo del servidor web
apache, el más difundido del mundo.
l Jakarta.apache.org Conjunto de frameworks y
clases de utilidad como apoyo al desarrollo de
aplicaciones basadas en java/J2EE.
l www.jboss.org Desarrollo del contenedor de EJBs
Jboss. Gratuito y muy efectivo.

Evolución de
Modelos Arquitectónicos

¡ Modelo 1
Servlets/JSPs

¡ Modelo 1.5
MVC Model
¡ Modelo 2

Multicanalidad
¡ Modelo 2X

2

Modelo de Arquitectura 1
Aplicaciones CGI

¡ Las más primitivas
¡ Aplicaciones Web CGI
¡ Presentación, negocio y persistencia mezclados
¡ El estado se almacena en el cliente y cada petición
supone una ejecución completa independiente de
estado (Transacction Script)

Browser Script
Database
CGI

Modelo de Arquitectura 1.5
JSP y Servlets

¡ Separación de responsabilidades:
l JSPs llevan la lógica de presentación
(navegabilidad, visualización, etc.)
l Beans incrustados asumen las responsabilidades de
negocio y datos

3

MVC

¡ Evolución del modelo 1.5
¡ Incorporación del patrón de diseño MVC.
l Controlador: Navegación
l Negocio y Datos: Beans
l Presentación: JSPs

MVC con Struts

¡ Struts es la implementación del MVC que
aporta Jakarta para aplicaciones web java.
¡ http://jakarta.apache.org/struts

4

Modelo de Arquitectura 2X
Aplicaciones Multicanal
¡ Evolución del modelo
2 para construir
aplicaciones
multicanal.
¡ Implementación de
referencia STXX
(extiende Struts)
¡ http://stxx.sourceforg
e.net/
¡ Soluciones basadas en
XML y XSLTs.

Aspectos Generales en
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

5

Escalabilidad
¿Importancia?

¡ Característica principal apps WEB:
l Posible incremento vertiginoso del número de usuarios
¡ Es importante:
l El correcto dimensionamiento de la aplicación
l La adaptabilidad del sistema ante el incremento de
demanda.
¡ Varias opciones:
l Escalabilidad Horizontal
l Escalabilidad Vertical
l Cluster de servidores

Escalabilidad
Horizontal

¡ Clonamos el sistema y balanceamos la
carga.
Sistema Sistema
Balanceador

Usuarios
Internet
Sistema Sistema

6
PDF

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:
l Cookies
l En 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.
¡ Ej., módulo mod_jk de apache.

7

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.

Capa 1 Capa 2
Sistema completo Capa n

Máquina 1 MáquinaMáquina
1 Máquina 1

8

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.

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.

9

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:
l Arquitectura n-capas
¡ El modelo más básico es el de tres capas:
l Capa de presentación
l Capa de negocio
l Capa de persistencia

¡ Independencia de capas

Separación
de Responsabilidades – Evolución

•APLICACIONES MAINFRAME

APLICACIÓN

SERVIDOR
Única capa física y lógica

10

Separación

•APLICACIONES CLIENTE - SERVIDOR

PRESENTACIÓN
CLIENTE Y NEGOCIO

NEGOCIO Y
SERVIDOR ACCESO A DATOS

Separación Lógica y Física de la
interfaz de usuario

Separación

•PRIMERAS APLICACIONES WEB
Arquitectura basada en Transaction
Scripts (CGIs, Modelo 1)
Interfaz WEB – HTML
Presentación + lenguaje de script

Negocio +
acceso a datos

11

Separación

•APLICACIONES 3 CAPAS

JSPs, HTML,
lógica de
Presentación presentación

Negocio Lógica de
negocio,
procesos neg.

Persistencia Componentes de
acceso a datos

Separación

•Modelo de Brown ncapas

JSPs, HTML,
lógica de
Presentación presentación

Negocio Lógica de
negocio,
procesos neg.

Persistencia
Componentes de
acceso a datos

12

Separación
de Responsabilidades – Capa de
presentación

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

Separación
negocio

¡ Comprende las responsabilidades de
lógica de negocio (o dominio) del
sistema.
¡ Resultado del análisis funcional:
l 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).

13

Separación
persistencia

¡ Comprende las responsabilidades de lógica
de persistencia de las entidades que maneja
el sistema en desarrollo.
l Inserción
l Eliminación
l Actualizaciones
l Búsquedas
l 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.

14

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.:
l Servicio de Log
l Pool JDBC
l Sistema de configuración
l Gestor de permisos de acceso
l Etc.

Gestión de la sesión del usuario

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

15

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

16

Arquitectura web

Recomendados

Recomendados

Más contenido relacionado

Similar a Arquitectura web

Similar a Arquitectura web (20)

Arquitectura web