Arquitectura Web -...

1

ArquitecturaWeb

Introducción

¡ Concepto de Arquitectura en Desarrollo Softwarel Concepción desde RUP

¡ Arquitectura física¡ Distribución de nodos en la red¡ Mapeo componente software – nodo computacional

¡ Concepto de Arquitectura software Modernol Patrones de diseño de arquitectural Separación de responsabilidadesl No existe forma de representar arquitectura

software con las herramientas actuales (RUP-UML)

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

http://www.pdfpdf.com/0.htm

2

Aplicaciones Webcon Java

¡ Fuerte apuesta por parte del sector privado:l Sun Microsystems. Extensiones J2EEl BEA Systems con Weblogicl IBM con WebSpherel Netscape (y Sun) con iPlanetl 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 deaplicaciones basadas en java/J2EE.

l www.jboss.org Desarrollo del contenedor de EJBsJboss. Gratuito y muy efectivo.

Evolución deModelos Arquitectónicos

¡ Modelo 1

¡ Modelo 1.5

¡ Modelo 2

¡ Modelo 2X

Servlets/JSPs

MVC Model

Multicanalidad


http://www.apache.orgDesarrollo

http://www.jboss.orgDesarrollo


3

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 deestado (Transacction Script)

Browser ScriptCGI Database

Modelo de Arquitectura 1.5JSP 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



4

Modelo de Arquitectura 2MVC

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

l Controlador: Navegaciónl Negocio y Datos: Beansl Presentación: JSPs

Modelo de Arquitectura 2MVC con Struts

¡ Struts es la implementación del MVC queaporta Jakarta para aplicaciones web java.

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



http://jakarta.apache.org/struts

5

Modelo de Arquitectura 2XAplicaciones Multicanal

¡ Evolución del modelo2 para construiraplicacionesmulticanal.

¡ Implementación dereferencia STXX(extiende Struts)

¡ http://stxx.sourceforge.net/

¡ Soluciones basadas enXML 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


http://stxx.sourceforg


6

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ónl La adaptabilidad del sistema ante el incremento de

demanda.

¡ Varias opciones:l Escalabilidad Horizontall Escalabilidad Verticall Cluster de servidores

EscalabilidadHorizontal

¡ Clonamos el sistema y balanceamos lacarga.

Sistema

UsuariosInternet

Sistema

Sistema Sistema

Balanceador

PD

F Creator - P

DF4Free v2.0 http://w

ww

.pdf4free.com


7

EscalabilidadHorizontal. Balanceador HW

¡ Distribuye por algoritmos predeterminados (Round Robin,LRU, etc.) las peticiones HTTP entre los distintos clones delsistema

¡ 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 enservidor -> Condiciona el Diseño!.

¡ La sesión la debe mantener el desarrollador por otrosmedios:l Cookiesl En base de datos

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

EscalabilidadHorizontal. Balanceador SW

¡ Examinan el paquete a nivel del protocoloHTTP para garantizar el mantenimiento de lasesión de usuario.

¡ Distintas peticiones del mismo usuario sonservidas por el mismo clon del servidor.

¡ Más lentos que los balanceadores HW¡ Normalmente son soluciones baratas.¡ Ej., módulo mod_jk de apache.



8

EscalabilidadHorizontal. Balanceador HW HTTP

¡ Dispositivos HW que examinan la petición anivel 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 deforma que permita la separación física de lasmismas.

¡ Es necesario un Middleware entre las capas parapermitir la comunicación remota.

Capa 1

Máquina 1

Capa 2

Máquina 1

Capa n

Máquina 1

Sistema completo

Máquina



9

EscalabilidadCusters de Servidores

¡ Habituales en los servidores de aplicacionescomerciales (Weblogic, WebSphere, iPlanet, etc.).

¡ Dependiendo de cómo se aplique puede clasificarsecomo horizontal o vertical.

¡ Distribuye y escala el sistema de modo transparentea usuario y administrador.

¡ Garantiza que sea cual sea la máquina que sirva lapetición http tendrá acceso a la sesión del usuario(Replicación de sesión)

¡ La replicación de sesión es MUY costosa, producebajo rendimiento del sistema.

Entonces…¿Qué hacer con la sesión?

¡ Primeras tendencias eran evitar apoyarse enla sesión (objeto Session): sólo habíabalanceadores hw.

¡ Hoy en día, está aceptado y se fomenta suuso.

¡ OJO! Es MUY delicado. El uso excesivo delobjeto session puede acarrear problemas derendimiento, puesto que los objetos ensesión no se liberan hasta que no caduque lamisma.



10

Separaciónde 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ónl Capa de negociol Capa de persistencia

¡ Independencia de capas

Separaciónde Responsabilidades – Evolución

SERVIDOR

APLICACIÓN

•APLICACIONES MAINFRAME

Única capa física y lógica



11


NEGOCIO YACCESO A DATOS

PRESENTACIÓNY NEGOCIO

Separación Lógica y Física de lainterfaz de usuario

CLIENTE

SERVIDOR

•APLICACIONES CLIENTE - SERVIDOR


Negocio +acceso a datos

Presentación

Arquitectura basada en TransactionScripts (CGIs, Modelo 1)

Interfaz WEB – HTML+ lenguaje de script

•PRIMERAS APLICACIONES WEB



12


Presentación

Negocio

Persistencia

•APLICACIONES 3 CAPAS

JSPs, HTML,lógica depresentación

Lógica denegocio,procesos neg.

Componentes deacceso a datos


•Modelo de Brown ncapas

JSPs, HTML,lógica depresentación

Lógica denegocio,procesos neg.

Componentes deacceso a datos

Presentación

Negocio

Persistencia



13

Separaciónde Responsabilidades – Capa depresentación

¡ Comprende las responsabilidades delógica de presentación:l Navegabilidad del sistemal Validación de datos de entradal Formateo de los datos de salidal Internacionalizaciónl Renderizado de presentaciónl Etc.

Separaciónde Responsabilidades – Capa denegocio

¡ Comprende las responsabilidades delógica de negocio (o dominio) delsistema.

¡ Resultado del análisis funcional:l Conjunto de reglas de negocio que

abstraen el mundo real.

¡ La capa de negocio ha de serindependiente de la capa depresentación y viceversa (en lamedida de lo posible).



14

Separaciónde Responsabilidades – Capa depersistencia

¡ Comprende las responsabilidades de lógicade persistencia de las entidades que manejael sistema en desarrollo.l Inserciónl Eliminaciónl Actualizacionesl Búsquedasl Etc.

¡ No tiene porqué tratarse necesariamente deuna base de datos relacional.

Portabilidad

¡ Una aplicación web debe poderadaptarse a las distintas arquitecturasfísicas posibles en el despliegue.

¡ Las tareas de adaptación a un nuevoentorno deben limitarse al ámbito dela configuración, no del desarrollo.

¡ Supuesto de ejemplo: Cliente reacio alas tecnologías de componentes J2EE(EJBs) por costes, rendimiento osimplemente, moda.



15

Componentización de los servicios deinfraestructura

¡ ¿Servicio de infraestructura?: Componentesindependientes del dominio.

¡ Rompen aparentemente la separación vertical decapas.

¡ Dan lugar a la capa de infraestructura.¡ Ej.:

l Servicio de Logl Pool JDBCl Sistema de configuraciónl Gestor de permisos de accesol Etc.

Gestión de la sesión del usuario

¡ Aspecto muy delicado del sistema¡ Cacheado de entidades en

l Sesión de usuariol Contexto de la aplicación

¡ Caducidad de la información¡ Refresco de datos¡ Rendimiento del sistema. Consumo de

recursos del sistema.



16

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 deentendimiento que facilita la comunicaciónentre analista y desarrollador.

¡ Aceleran el desarrollo de Software¡ Facilitan el mantenimiento¡ En proceso de integración en las

herramientas CASE (Rose, Together, etc.).



Arquitectura Web -...

Documents

Transcript of Arquitectura Web -...