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.