Desarrollo para Entorno Web Unidad 1: Introducción a la Arquitectura Web

Presentación Profesor: Ing. David Rodríguez Condezo Correo: pcsidrod@upc.edu.pe Personal: rcondezo@gmail.com Google Code: http://code.google.com/p/dew-2012a/ Celular: 997391008 Correo grupo: IS150-E41A@upc.edu.pe

Presentación de alumnos Nombres Funciones en tu centro laboral Expectativas del curso

Asistencia y puntualidad Ausencias permitidas según reglamento. La asistencia se registrará a las 8 p.m.

Evaluaciones Tipo de evaluación Peso Recuperable Fecha programada (*) (*) Podría cambiar previa confirmación del profesor Tipo de evaluación Peso Recuperable Fecha programada (*) PC1 15 % Sí 25 de enero TB 20 % No 27 de enero PC2 15 de febrero TF 30 % Por definirse PA A lo largo del curso

Respeto y orden Los celulares deben estar en modo silencio durante la clase. Responder llamadas fuera del aula.

Actividades preliminares Revisión del sílabo Proyecto FulbitoFacil Conformación de equipos (5 integrantes) Nombres de los equipos (una palabra) Scrum Master de cada equipo Documento del proyecto GoogleCode Scrumy Delegado

Agenda Introducción a la arquitectura Web Introducción a la arquitectura JavaEE Comparación de tecnologías Web Servidores de aplicaciones

Introducción a la arquitectura Web

Introducción En la ingeniería de software se denomina aplicación Web a aquellas aplicaciones que los usuarios pueden utilizar accediendo a un servidor Web a través de Internet o de una intranet mediante un navegador.

Paradigma Cliente/Servidor Patrón arquitectónico para el desarrollo de sistemas distribuidos. Distribuye una aplicación entre 2 o más componentes especializados cuya ejecución se distribuye entre 1 o más equipos. Define un modelo de interacción basado en el concepto de servicio implementado sobre un diálogo petición-respuesta. Cliente inicia el diálogo mediante el envío de peticiones. Servidor presta el servicio en que se sincronizan los procesos.

Paradigma Cliente/Servidor Especifica el modo en que se sincronizan los procesos: Cliente (Parte activa) Demanda servicios a los servidores Se asume que cada petición deberá obtener respuesta Diseñado para soportar la interacción con el usuario final Servidor (Parte pasiva) Espera las peticiones de los clientes Procesa esas peticiones y envía una respuesta Diseño orientado a maximizar la eficiencia. Posibilidad de aplicar el patrón cliente – servidor en múltiples niveles de abstracción dentro de un mismo sistema distribuido (arquitecturas multinivel [n-tier] )

Componentes de los Sistemas Cliente / Servidor Características de los clientes Componente del sistema que interactúa con el usuario. No comparte sus recursos con otros clientes. No suelen tener restricciones especiales respecto a rendimiento, fiabilidad y escalabilidad No suele requerir equipos de altas prestaciones Fallo de un cliente no afecta el resto. Debe dar soporte a restricciones relativas a ergonomía (facilidad de uso) y seguridad (evitar comprometer los demás componentes).

Componentes de los Sistemas Cliente / Servidor Características de los servidores: Componente del sistema que presta servicios a los clientes. Gestiona y comparte sus recursos con los clientes y a los que sirve. Suele tener restricciones especiales respecto al rendimiento, fiabilidad, escalabilidad y seguridad. Capacidad suficiente para atender múltiples clientes Fallos en el servidor son críticos e invalidan el sistema El número de clientes (peticiones) puede ser muy variable y aumentar si así se requiere Evitar comprometer la seguridad de los recursos o datos gestionados y de los clientes.

Modelos y tipologías Esquema abstracto de aplicaciones distribuidas genéricas (capas). Se corresponden con las funciones típicas de un sistema. Capa de presentación (interfaz de usuario) Interacciona con el usuario, presenta los datos y recibe las entradas. Capa de aplicación/negocio (lógica de aplicación) Responsable de las tareas propias de la aplicación concreta. Implementa la lógica de la aplicación y aplica las reglas de negocio sobre los datos y las entradas de usuario. Capa de datos (almacenamiento y acceso a datos) Responsable de la gestión y almacenamiento permanente de los datos. Cada tipo de sistema cliente-servidor distribuye esas capas de modo distinto entre los componentes cliente y servidor

Cliente Ligeros versus Pesados Cliente ligero (thin client) No implementa ningún aspecto de la lógica de aplicación. Simplemente actúa como intermediario entre usuario y servidor. Recoge entradas (opcionalmente las valida) y las envía al servidor. Presenta datos y resultados del servidor. Normalmente, requisitos mínimos respecto a recursos de hardware. Aumenta la complejidad del servidor (tendrá mayores responsabilidades) Ejemplo: clientes basados en navegadores Web: Capa de presentación repartida entre servidor (genera HTML en demanda) y cliente (navegador lo presenta). En últimos años surgen clientes ricos (tecnología AJAX, RIA (Rich Internet Application)

Cliente Ligeros versus Pesados Cliente pesado (fat client) Implementa mayor parte de la lógica de aplicación Realiza procesamiento sobre datos de usuario antes de comunicar con el servidor. Requiere equipos con capacidad de proceso y/o almacenamiento de datos. Servidor sencillo (responsabilidades mínimas, gestión de datos) Ejemplo: aplicación cliente contra servidor de base de datos

Arquitecturas 2-tier, 3-tier, n-tier Clasificación en función de la ubicación física de las distintas funcionalidades. Modelo tradicional: 2-tier (cliente-servidor en 2 niveles) Un único servidor atiende a múltiples clientes Problemas Escasa escalabilidad en servidores con lógica de negocios compleja o con grandes bases de datos (difícil replicación) Rigidez: modificaciones en la lógica de aplicación suponen grandes cambios en la totalidad de los clientes. Difícil evolución del servidor. Limitación principal: alto acoplamiento/dependencia del cliente respecto del servidor. Clientes ligeros, pesados o híbridos. Una arquitectura es el conjunto de decisiones significativas sobre la organización de un sistema de software que define los principios que guían el desarrollo, los componentes principales del sistema, sus responsabilidades y la forma en que se interrelacionan.

Arquitecturas 2-tier, 3-tier, n-tier Modelo 3-tier (cliente – servidor en 3 niveles) Extensión del modelo tradicional que pretende aumentar el desacoplamiento entre servidor y clientes. Introduce un nivel intermedio (separa servidor en 2 componentes) Cliente dedicado casi exclusivamente a interfaz de usuario Servidor de datos comparte con servidor del nivel intermedio la lógica de la aplicación. El reparto preciso depende del modelo concreto seguido. Clientes ligeros o híbridos

Arquitecturas 2-tier, 3-tier, n-tier Modelos n-tier o multi-tier (cliente – servidor en n niveles) Generalización del modelo 3-tier (añade nuevas capas) La lógica de aplicación se reparte en diferentes capas/niveles ubicadas entre el cliente y los datos. Las capas intermedias se proporcionan servicios entre si. Cada nivel se comunica sólo con los niveles contiguos a través de interfaces bien definidos. Capa K ofrece servicios a la capa K-1 y demanda servicios de capa K + 1. Estructura típica en sistemas basados en componentes distribuidos (objetos distribuidos). Clientes ligeros o híbridos

Arquitecturas 2-tier, 3-tier, n-tier Beneficios de las arquitecturas multinivel Elementos críticos de la lógica de negocio ubicados en el nivel medio. Más cercanos a la capa de datos: eficiencia de acceso Sólo los datos realmente necesarios acaban llegando al cliente. Mayor flexibilidad y modularidad. Escalabilidad: facilita añadir recursos para soportar mayor número de clientes. Extensibilidad: facilidad para propagar autenticación y permisos a través de las distintas capas. Seguridad: facilidad para propagar autenticación y permisos a través de las distintas capas. Facilidades de desarrollo y administración: Resusabilidad de componentes Aislamiento frente a cambios en otras capas Independencia frente a cambios en base de datos

Arquitecturas 2-tier, 3-tier, n-tier Desventajas de las arquitecturas multinivel Complejidad: mayor número de elementos hardware y software a definir, gestionar y mantener: Interacciones complejas entre componentes Dificultad para detectar, aislar y corregir fallos. Coste de comunicaciones: mayor latencia y consumo de ancho de banda (atravesar capas distribuidas por la red) Coste de mantenimiento: al crecer las capas aumenta el coste y la dificultad de instalación y mantenimiento.

Arquitectura Web

Ventajas de la arquitectura Web Actualización automática Según el paradigma cliente/servidor, la lógica de la aplicación se encuentra centralizada. Los clientes son ligeros. Multiplataforma Diferentes arquitecturas de hardware Diferentes sistemas operativos Diferentes navegadores Web Portable Tecnologías como Java permiten crear aplicaciones Web portables. Clientes ligeros sólo necesitan soportar el estándar HTML. Alta disponibilidad Servidores Web replicados en la misma y/o diferentes ubicaciones geográficas.

Desventajas de la arquitectura Web Menos funcionalidades que aplicaciones Desktop (de escritorio) Tradicionalmente, los navegadores Web presentan funciones limitadas. Tendencia de nuevas formas de crear aplicaciones Web con Ajax, RIA, entre otros. Requiere conexión a Internet Al menos que sea una sistema intranet.

Introducción a la arquitectura JavaEE

JavaEE Java Platform, Enterprise Edition o Java EE (anteriormente conocido como Java 2 Platform, Enterprise Edition o J2EE hasta la versión 1.4), es una plataforma de programación—parte de la Plataforma Java—para desarrollar y ejecutar software de aplicaciones en Lenguaje de programación Java con arquitectura de N niveles distribuida, basándose ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones.

JavaEE: Arquitectura n-tier

JavaEE: API’s y tecnologías

Web Container El contenedor Web implementa el contrato de componentes Web de la arquitectura J2EE. Este contrato especifica un entorno de ejecución para los componentes Web que incluye la seguridad, concurrencia, gestión de ciclo de vida, operación, despliegue y otros servicios. Un contenedor Web maneja la ejecución de las páginas JSP y componentes Servlet para aplicaciones JavaEE.

EJB Container El contenedor de EJB maneja la ejecución de los Enterprise Java Beans (EJB) para aplicaciones JavaEE. Los contenedores de EJB proveen servicios a los EJB, como: Comunicación remota Transacciones Control de concurrencia Eventos utilizando JMS Servicios de nombres y directorios Seguridad Ubicación de componentes. La especificación de EJB define los papeles jugados por el contenedor de EJB y los EJB, además de disponer los EJB en un contenedor.

Comparación de tecnologías Web

Otras tecnologías y lenguajes para Web ASP.NET PHP Perl Ruby Python

Servidores de aplicaciones

Características

Características El Servidor de Aplicaciones se encuentra compuesto por tres componentes: un “servidor de páginas Web”, un “Web Container" y un "EJB Container“. Dentro del “Web Container" se ejecutan exclusivamente las clásicas aplicaciones de basadas en JSP's ("Java Server Pages") y Servlets. Mientras el "EJB Container" es reservado para aplicaciones desarrolladas alrededor de EJB's "Enterprise Java Bean's". Casi todos los servidores de aplicaciones en el mercado hoy en día son conocidos como "Fully JEE Compliant", este termino implica que se cumplen todas las especificaciones JavaEE definidas.

Servidor de aplicaciones Cuando utiliza un servidor de aplicaciones como alguno de los siguientes ("Fully JEE Compliant"): Oracle WebLogic IBM WebSphere Application Server GlassFish , no existe una clara distinción entre el "Web Container" y "EJB Container", es decir, es posible ejecutar tanto JSP/Servlets así como EJB's, sin embargo, el ambiente se encuentra altamente integrado para que sea transparente (al menos para el programador final) la comunicación entre JSP/Servlets y EJB's.

Servidores Open Source Comerciales Tomcat (sólo Web container) GlassFish Jboss Geronimo Comerciales IBM WebSphere Application Server Oracle WebLogic SAP Netweaver

Referencias Hall Marty, Brown Larry (2004). Core Servlets and JavaServer Pages. Hanumant Deshmukh, Jignesh Malavia y Jacquelyn Carter (2005). SCWCD Exam Study Kit - Manning. Sistemas cliente-servidor y procesos cooperativos – Universidad de Vigo Wikipedia http://www.jtech.ua.es/j2ee/2006-2007/jee.html http://java.sun.com/javaee/reference/