Arquitectura de Aplicaciones Web Equipo #2 Marco Antonio Pérez Solano Ernesto León Solache Aarón Francisco Montes Álvarez

Introducción La arquitectura Web, es la disciplina encargada de estructurar, organizar y etiquetar el contenido como también establecer los puntos de acceso, sistemas de búsqueda y recuperación de información de cualquier aplicación soportada en la Web, con el fin de que el usuario cumpla con los objetivos y su experiencia sea optima. Los Arquitectos Web diseñan y coordinan el desarrollo de sitios Web

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

CGI CGI: Common Gateway Interface Protocolo para ejecutar programas en el servidor vía HTTP. Permite hacer disponible en el servidor HTTP: programas escritas en cualquier lenguaje interpretado o compilado. (C, Perl y Bourne Shell) Normalmente, las aplicaciones exportadas residen en directorio particular (usualmente cgi-bin) Se puede configurar el servidor para utilizar otros directorios.

Parte Servidora Recibe los datos, los procesa y devuelve otros Toma los datos por la entrada estándar (teclado) y envía los datos de salida por la salida estándar (pantalla). Cualquier programa capaz de leer por entrada estándar y escribir en salida estándar puede actuar como CGI El usuario no puede interacturar directamente con el programa CGI. (salvo llamadas a varios cgis)

CGI hace que clientes Web puedan actualizar BBDD.

Arquitectura a 2 capas

Definición Es conocida también como la arquitectura tradicional de cliente/servidor. Requiere una interfaz de usuario que se instala y corre en una PC o estación de trabajo y envía solicitudes a un servidor para ejecutar operaciones complejas. Por ejemplo, una estación de trabajo utilizada como cliente puede correr una aplicación de interfaz de usuario que interroga a un servidor central de bases de datos.

Ventajas del Sistema de Dos Capas: El desarrollo de aplicaciones en un ambiente de dos capas funciona adecuadamente, pero no es necesariamente lo más eficiente. Las herramientas para el desarrollo con dos capas son robustas y ampliamente evaluadas. Las técnicas de ingeniería de software de prototipo se emplean fácilmente. Las soluciones de dos capas trabajan bien en ambientes no dinámicos estables, pero no se ejecutan bien en organizaciones rápidamente cambiantes.

Desventajas del sistema de dos capas: Los ambientes de dos capas requieren control excesivo de las versiones y demandan esfuerzo de distribución de la aplicación cuando se les hacen cambios. Esto se debe al hecho de que la mayoría de la aplicación lógica existe en la estación de trabajo del cliente. La seguridad del sistema en un diseño de dos capas es compleja y a menudo requiere administración de las bases de datos; esto es debido al número de dispositivos con acceso directo al ambiente de esas bases de datos. Las herramientas del cliente y de la base de datos, utilizadas en diseños de dos capas, constantemente están cambiando. La dependencia a largo plazo de cualquier herramienta, puede complicar el escalamiento futuro o las implementaciones.

Arquitectura de 3 capas

Definición En la arquitectura en tres niveles existe un nivel intermedio. Esto significa que la arquitectura generalmente está compartida por: Un cliente, es decir, el equipo que solicita los recursos, equipado con una interfaz de usuario (generalmente un navegador web) para la presentación. El servidor de aplicaciones (también denominado software intermedio), cuya tarea es proporcionar los recursos solicitados, pero que requiere de otro servidor para hacerlo. El servidor de datos, que proporciona al servidor de aplicaciones los datos que éste le solicitó. El uso masivo del término arquitectura en tres niveles también denota las siguientes arquitecturas: Aplicación compartida entre un cliente, un software intermedio y un servidor empresarial. Aplicación compartida entre un cliente, un servidor de aplicaciones y un servidor de base de datos empresarial

Diseño

Modelo Vista Controlador

Definición Es un patrón de arquitectura de software que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario. Este patrón de arquitectura de software se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento

Descripción del Patrón MVC De manera genérica, los componentes de MVC se podrían definir como sigue: El Modelo: Es la representación de la información con la cual el sistema opera, por lo tanto gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de acceso que se hayan descrito en las especificaciones de la aplicación (lógica de negocio). Envía a la 'vista' aquella parte de la información que en cada momento se le solicita para que sea mostrada (típicamente a un usuario). Las peticiones de acceso o manipulación de información llegan al 'modelo' a través del 'controlador'. El Controlador: Responde a eventos (usualmente acciones del usuario) e invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento o un registro en una base de datos). También puede enviar comandos a su 'vista' asociada si se solicita un cambio en la forma en que se presenta de 'modelo' (por ejemplo, desplazamiento o scroll por un documento o por los diferentes registros de una base de datos), por tanto se podría decir que el 'controlador' hace de intermediario entre la 'vista' y el 'modelo' La Vista: Presenta el 'modelo' (información y lógica de negocio) en un formato adecuado para interactuar (usualmente la interfaz de usuario) por tanto requiere de dicho 'modelo' la información que debe representar como salida.

Interacción de los Componentes Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo de control que se sigue generalmente es el siguiente: El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.) El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se reflejan los cambios en el modelo La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente....