ArquitecturaWeb

Introducción

� Concepto de Arquitectura en Desarrollo Software

� Concepción desde RUP

� Arquitectura física

� Distribución de nodos en la red

� Mapeo componente software – nodo computacional

� Concepto de Arquitectura software Moderno

� Patrones de diseño de arquitectura

� Separación de responsabilidades

� No existe forma de representar arquitectura software con las herramientas actuales (RUP-UML)

Aplicaciones Web � Fuerte apuesta por parte del sector privado:

� Sun Microsystems. Extensiones J2EE

� BEA Systems con Weblogic

� IBM con WebSphere

� Netscape (y Sun) con iPlanet

� Orión – Oc4J Oracle 9IAS

� Mircrosoft IIS

� ColdFusion MX(Macromedia)

� Fuerte apuesta del mundo opensource!

� www.apache.org Desarrollo del servidor web apache, el más difundido del mundo.

� apache.org Conjunto de frameworks y clases de utilidad como apoyo al desarrollo de aplicaciones empresariales

� Etc.

Evolución de Modelos Arquitectónicos

� Modelo 1

� Modelo 1.5

� Modelo 2

� Modelo 2X

PHP/Servlets/JSPs/ASPs

MVC Model

Multicanalidad

Modelo de Arquitectura 1Aplicaciones 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)

BrowserScript

CGIDatabase

Modelo de Arquitectura 1.5Páginas Dinámicas + Clases

� Separación de responsabilidades:� Páginas dinámicas llevan la lógica de presentación (navegabilidad, visualización, etc.)

� Clases incrustadas asumen las responsabilidades de negocio y datos

Modelo de Arquitectura 2MVC

� Evolución del modelo 1.5� Incorporación del patrón de diseño MVC.

� Controlador: Navegación� Negocio y Datos: Clases� Presentación: Páginas

Modelo de Arquitectura 2MVC con Struts

� Struts es la implementación del MVC que aporta Jakarta para aplicaciones web java.

� http://jakarta.apache.org/struts

Modelo de Arquitectura 2XAplicaciones Multicanal

� Evolución del modelo 2 para construir aplicaciones multicanal.

� Implementación de referencia STXX (extiende Struts)

� http://stxx.sourceforge.net/

� Soluciones basadas en XML y XSLTs.

Aspectos Generales enArquitectura 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¿Importancia?

� Característica principal 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

EscalabilidadHorizontal

� Clonamos el sistema y balanceamos la carga.

Sistema

Usuarios Internet

Sistema

Sistema Sistema

Balanceador

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

� En base de datos

� Al ser un proceso HW, es MUY rápido.

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.

Capa 1

Máquina 1

Capa 2

Máquina 1

Capa n

Máquina 1

Sistema completo

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

SERVIDOR

APLICACIÓN

•APLICACIONES MAINFRAMEAPLICACIONES MAINFRAMEAPLICACIONES MAINFRAMEAPLICACIONES MAINFRAME

ÚÚÚÚnica capa fnica capa fnica capa fnica capa fíííísica y lsica y lsica y lsica y lóóóógicagicagicagica

Separación de Responsabilidades – Evolución

NEGOCIO Y ACCESO A DATOS

PRESENTACIÓN Y NEGOCIO

SeparaciSeparaciSeparaciSeparacióóóón Ln Ln Ln Lóóóógica y Fgica y Fgica y Fgica y Fíííísica de la sica de la sica de la sica de la interfaz de usuariointerfaz de usuariointerfaz de usuariointerfaz de usuario

CLIENTECLIENTECLIENTECLIENTE

SERVIDORSERVIDORSERVIDORSERVIDOR

•APLICACIONES CLIENTE APLICACIONES CLIENTE APLICACIONES CLIENTE APLICACIONES CLIENTE ---- SERVIDORSERVIDORSERVIDORSERVIDOR

Separación de Responsabilidades – Evolución

Negocio +acceso a datos

Presentación

Arquitectura basada en Transaction Scripts (CGIs, Modelo 1)

Interfaz WEB – HTML + lenguaje de script

•PRIMERAS APLICACIONES WEBPRIMERAS APLICACIONES WEBPRIMERAS APLICACIONES WEBPRIMERAS APLICACIONES WEB

Separación de Responsabilidades – Evolución

Presentación

Negocio

Persistencia

•APLICACIONES 3 CAPASAPLICACIONES 3 CAPASAPLICACIONES 3 CAPASAPLICACIONES 3 CAPAS

JSPs, HTML, lógica de presentación

Lógica de negocio, procesos neg.

Componentes de acceso a datos

Separación de Responsabilidades – Evolución

•Modelo de Modelo de Modelo de Modelo de BrownBrownBrownBrown ncapasncapasncapasncapas

JSPs, HTML, lógica de presentación

Lógica de negocio, procesos neg.

Componentes de acceso a datos

Presentación

Negocio

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.

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

Taller práctico

� Desarrollo de un contador de visitas. Empleo de los objetos de sesión y contexto.� Descargarse de la web el entorno de trabajo 0.5 (Contador de visitas de cada usuario!).

� Descomprimir en el directorio del curso, compilar y desplegar.

� Probar contador accediendo mediante el navegador a:

http://localhost:8080/arqui-java

� Abrir el fichero index.jsp y examinar el código

Taller práctico

� Modificar el contador de visitas para que cuente las de TODOS los usuarios que accedan a la página� Editar el fichero index.jsp.� En Lugar de colocar y recuperar el atributo contador de la sesión, hacerlo del contexto.

� Ej. Sustituir� session.getAttribute("contador")Por � session.getServletContext().getAttribute("contador")

� Compilar y desplegar con Ant, y probar la aplicación en…

http://localhost:8080/arqui-java