PATRONES ARQUITECTURALES PARA APLICACIONES WEB

1. PATRONES ARQUITECTURALES PARA APLICACIONES WEB Ing. de software III Universidad del Cauca Ing. Wilson Ortega

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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