PATRONES ARQUITECTURALES PARA APLICACIONES WEB

Ing. de software III

Universidad del CaucaIng. Wilson Ortega

Introducción

Después de un buen análisis de los requerimientos y casos de uso. El arquitecto propone una arquitectura en la forma de un documento de la arquitectura del software. El cual expresa la arquitectura a través de un conjunto de vistas.

Básicamente una aplicación web amplía un sitio web habilitando al usuario a invocar lógica del negocio y como consecuencia cambia el estado del negocio en el servidor. Esto significa que hay tres componentes arquitecturales en una aplicación web: el browser, el servidor web y el servidor.de aplicaciones.

Patrones

Un patrón arquitectural expresa un esquema de estructura de organización fundamental para el sistema software. Este provee un conjunto de subsistemas predefinidos, especifica responsabilidades e incluye reglas y guías para organizar las relaciones entre ellas. Las tres patrones más comunes son:

Thin Web cliente

Thick Web cliente

Web distribuido

Thin Web cliente

Usado en su mayor parte en aplicaciones basadas en Internet, en el cual hay poco control en la configuración del cliente. El cliente requiere solo un browser estándar. Toda la lógica del negocio es ejecutada sobre el servidor.

Aplicabilidad: Esta patrón es el más apropiado para aplicaciones basadas en Internet o para estos ambientes en el cual el cliente tiene mínimo poder de cómputo o no hay control sobre esta configuración.

Casos conocidos: La mayoría de aplicaciones de e-commerce usan este patrón dado que no se pueden perder clientes solo porque no tienen poder de computo.

Thin Web cliente

Estructura: Los mayores componentes de este patrón existen sobre el servidor. Los principales componentes son los siguientes:

Cliente browser Solo tiene la capacidad de aceptar y retornar cookies La aplicación del usuario usa el browser para solicitar

páginas web: cualquier página html o página servidor. La página web retornada contiene todo el formato de

interface (texto, controles) el cual es suministrada por el browser del cliente sobre la pantalla del cliente

Todas las interacciones con el sistema son a través del browser

Thin Web cliente

Servidor Web Todos los accesos al sistema por parte del cliente los

hace a través del servidor Web. El cual acepta solicitudes para páginas Web.

Si la solicitud es hecha para una página script, CGI, módulo ISAPI o NSAPI el servidor delega el proceso al apropiado interpretador de script o módulo ejecutable, en cualquier caso el resultado es una página con formato html, configurable para suministrarla por el browser html.

Conexión http Esta conexión es usada entre el cliente y el servidor para

su comunicación permitiendole enviar y recibir información.

Puede también usar https, más segura.

Thin Web cliente

Página cliente Contiene texto explicativo, tal como información de ayuda

o formas de entradas (html).

Página servidor Estas páginas son ejecutables por módulos del lado del

servidor (NSAPI, ISAPI) estas páginas potencialmente tienen acceso a todas los recursos del lado del servidor incluyendo lógica del negocio, base de datos, sistemas herederos y cuentas del sistema.

Thin Web cliente

Servidor de aplicaciones

Responsable de ejecutar las página del lado del servidor, pueden ser cargadas en la misma máquina como el Web server.

Motor primario para ejecutar lógica del negocio del lado del servidor

Puede estar localizada en la misma máquina del servidor Web

Puede ejecutar en el mismo espacio de procesos del servidor Web.

Thin Web cliente

Lo dinámico

Lo dinámico de este patrón se centra en la lógica del negocio cuando el cliente hace una solicitud al servidor vía http.

Cuando la solicitud es una página html, simplemente el servidor envía la página html, pero si es una página script, el servidor delega esta acción al servidor de aplicaciones. La aplicación server interpreta el script de la página e interactúa con los recursos del servidor (base de datos, servicio de e-mail, sistema herederos y otros). Esta página además incluye formas, valores de campos, parámetros, el resultado es una página html configurable que es enviada al cliente.

La lógica del negocio es invocada solo durante el proceso de solicitud de una página. Una vez la página solicitada es ejecutada el resultado es enviado de vuelta al cliente y la conexión entre el cliente y el servidor es terminada.

Thin Web cliente

Consecuencias Este tipo de arquitecturas conviene para aplicaciones donde

el servidor puede responder dentro del tiempo esperado por el usuario y dentro del tiempo fuera (TimeOut) permitido por los valores de los usuarios (No mayor de unos cuantos segundos).

Otra limitación es la dificultad para mejorar interfaces de usuario, porque solo se limita al uso de html (texto, algunos botones y campos).

Thick web cliente

Extiende el Thin con el uso de scripts del lado del cliente y objetos personalizables tal como controles Activex y JavaApplets. El cliente puede realizar alguna lógica del negocio.

Thick web cliente

Aplicabilidad

Cuando una aplicación Web presenta cierta configuración del cliente y cierta versión del browser es asumida y se desea una buena interface de usuario y alguna lógica del negocio puede ser ejecutada sobre el cliente.

Visualizar y modificar modelos en varias dimensiones o para animar gráficas financieras.

La diferencia con el anterior, es el rol que juega el browser en la lógica del negocio del cliente.

Thick web cliente

Un ejemplo de este, es el monitoreo de los signos vitales de los pacientes, que se encuentran remotamente. Para esto se emplean por ejemplo Controles Activex. Esto se hace para medir la presión arterial, niveles de azucares y otros signos vitales que pueden ser usados por una agencia que necesite monitorear pacientes geográficamente remotos para una asistencia básica, y que sea capaz de reducir las visitas personales.

En algunas situaciones se requiere ejecutar lógica de negocio en el cliente para validar datos de entrada como formatos de fechas, correos, etc..

Thick web cliente

Usos conocidos Scripting del lado del cliente Plug-ins, controles Javascript es a menudo usado en la configuración del

cliente JavaApplets y controles Activex son a menudo usados

para crear sofisticados jerarquías de tres vistas (menús desplegables).

Ejemplo para animaciones tenemos Shockwave Activex control y plug-ins sirven para animaciones. Microsoft agent control, acepta comando de voces para ejecutar acciones en el browser.

Thick web cliente

Estructura La comunicación entre el cliente y el servidor son hechos vía

http

Los objetos controles Activex , JavaApplet están limitados a interactuar con los objetos del cliente.

Los objetos (Activex, Applet) pueden acceder a los recursos del cliente y pueden ser bajados a través de http, por esta razón son típicamente autenticados por terceros.

Thick web cliente

Scripts clientes:

JavaScript o VBScript embebidos en una página html.

Controles Activex: Objetos COM pueden ser referenciados por un script cliente y bajado al client, tiene full acceso a los recursos del cliente. El browser tiene la capacidad de rechazar un Activex o advertir al cliente del control. Se usan autenticaciones y firmas por terceros de los controles, por seguridad.

Java Applet: Contiene y compila componentes que corren en el contexto del browser, por seguridad tienen restricciones al acceso de los recursos de lado del cliente. Sirven para complicadas interfaces y para analizar gramaticalmente documentos XML o para encapsular complicada lógica del negocio.

Thick web cliente

Dinámico Tiene la habilidad de ejecutar lógica del negocio en el

cliente Todas las comunicaciones entre el servidor y el cliente se

da por la solicitud de un página La lógica del negocio puede ejecutarse en el cliente con

scripts, controles o applets Los scripts del cliente son usados para validar datos de

entrada Ejemplo una aplicación de e-commerce emplea javascript

para validar incompatibilidades. Los JavaApplets o Activex tiene funciones asociadas a las

páginas, por ejemplo cuando se mueve el mouse ocurre un evento.

Thick web cliente

Los eventos tiene acceso a la interface DOM del browser. Esta interface es un estándar de la W3C para script, controles y acceso a applet y el contenido de la página html.

El uso de XML como un mecanismo estándar de intercambio de información entre el cliente y el servidor es permitido por el uso de componentes especiales sobre el cliente. controles Activex o JavaApplet están colocados en el cliente para solicitar o enviar un documento XML.

Ejemplo: un Java Applet embebido en una página HTML que podría hacer una solicitud http al servidor web por un documento XML, el servidor encuentra y proceso la información y envía de vuelta un documento formato XML. El applet en el cliente debe aceptar el documento XML parseado, e interactúa con el actual documento HTML en el browser para desplegar el contenido al usuario.

Thick web cliente

Consecuencias

Incompatibilidad con los browser, no todos los browsers soportan javascripts o vbscripts.

Implementación del DOM en algunos casos depende del browser

Es necesario hacer pruebas con todos los posibles escenarios para cada cliente que lo soportará y sobre todo los browsers que soportará la lógica del negocio. (Nunca asuma el comportamiento en un browser).

Web Distribuido

Mecanismo tradicional de distribución de objetos cliente/servidor, visto como una aplicación Web con objetos distribuidos.

Aplicabilidad Apropiado cuando hay un significativo control sobre el cliente y

la configuración de la red. Este patrón es poco usado para aplicaciones basadas en

Internet, o cuando hay poco control sobre la configuración del cliente o las comunicaciones de la red son pocos confiables.

Lo más importante de esta arquitectura es apalancar la existencia de objetos de negocios en el contexto de una aplicación Web con comunicación directa y persistente entre el cliente y el servidor, con esto se superan los problemas mencionados anteriormente.

No debe ser usada sola, sino combinada con las dos anteriores.

Web Distribuido

Usos conocidos

CNN, detrás del sitio Web hay una sofisticada red basada en CORBA, browsers, servidores y objetos distribuidos.

Una aplicación de atención médica, una aplicación Web para el manejo de pacientes, registros médicos y facturación. Es un thick cliente en lo que respecta a clientes y pacientes y manejo de registros médicos, con una aplicación Web distribuida para operaciones de facturación.

Web Distribuido

Estructura

La principal diferencia entre este y los demás es la comunicación entre el cliente y el servidor.

Incluye todos los elementos del thin web cliente y: DCOM: COM distribuidos, es el protocolo de objetos

distribuidos de Microsoft, este permite a los objetos de una máquina interactuar con los objetos de otra máquina.

IIOP: Protocolo Internet Inter-ORB es el protocolo OMGs CORBA para interactuar con objetos distribuidos o cualquier red basada en TCP/IP.

RMI (JMRP): Método de invocación remota, es la vía Java que permite interactuar con otras máquinas. JMRP (Protocolo Java de Método remoto), es el nativo del RMI.

Web Distribuido

Dinámico

El browser es usado para contener una interface de usuario y algunos objetos de negocios para comunicar los objetos del lado del servidor.

Comunicación entre el cliente y los objetos del servidor ocurren con los protocolos IIOP, RMI y DCOM.

Una de las fortalezas es que el browser tiene la capacidad de descargar componentes del servidor. Quiere decir que cualquier computador con un browser puede acceder a la aplicación, sin necesidad de instalar un software especial manualmente. Este componente es bajado guardado en el cliente y se conectan con los objetos del servidor.

Web Distribuido

Consecuencias

Requiere una sólida red

Gastan mucho tiempo las conexiones http entre el cliente y el servidor y esporádicamente se pierde el servidor, lo cual no es problema para los patrones anteriores.