Programa de Actualización Profesional Ingeniería de Sistemas - EPE Desarrollo para Entorno Web...

Post on 24-Jan-2016

227 views 0 download

Transcript of Programa de Actualización Profesional Ingeniería de Sistemas - EPE Desarrollo para Entorno Web...

Programa de Actualización Programa de Actualización ProfesionalProfesionalIngeniería de Sistemas - EPEIngeniería de Sistemas - EPE

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

PresentaciónPresentació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 alumnosPresentación de alumnos

Nombres

Funciones en tu centro laboral

Expectativas del curso

Asistencia y puntualidadAsistencia y puntualidad

Ausencias permitidas según reglamento.

La asistencia se registrará a las 8 p.m.

EvaluacionesEvaluaciones

(*) 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 % Sí 15 de febrero

TF 30 % No Por definirse

PA 20 % No A lo largo del curso

Respeto y ordenRespeto y orden

Los celulares deben estar en modo silencio durante la clase.

Responder llamadas fuera del aula.

Actividades preliminaresActividades preliminares

Revisión del sílabo

Proyecto FulbitoFacilConformación de equipos (5 integrantes)

Nombres de los equipos (una palabra)

Scrum Master de cada equipo

Documento del proyecto

GoogleCode

Scrumy

Delegado

AgendaAgenda

Introducción a la arquitectura Web

Introducción a la arquitectura JavaEE

Comparación de tecnologías Web

Servidores de aplicaciones

Programa de Actualización Programa de Actualización ProfesionalProfesionalIngeniería de Sistemas - EPEIngeniería de Sistemas - EPE

Introducción a la Introducción a la arquitectura Webarquitectura Web

IntroducciónIntroducció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/ServidorParadigma 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/ServidorParadigma 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 Componentes de los Sistemas Cliente / ServidorCliente / 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 Componentes de los Sistemas Cliente / ServidorCliente / 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íasModelos 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 Cliente Ligeros versus PesadosPesados• 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 Cliente Ligeros versus PesadosPesados• 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-Arquitecturas 2-tier, 3-tier, n-tiertier• 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.

Arquitecturas 2-tier, 3-tier, n-Arquitecturas 2-tier, 3-tier, n-tiertier• 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-Arquitecturas 2-tier, 3-tier, n-tiertier• 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-Arquitecturas 2-tier, 3-tier, n-tiertier• 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-Arquitecturas 2-tier, 3-tier, n-tiertier• 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 WebArquitectura Web

Ventajas de la arquitectura Ventajas de la arquitectura WebWeb• 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 Desventajas de la arquitectura Webarquitectura 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 InternetAl menos que sea una sistema intranet.

Programa de Actualización Programa de Actualización ProfesionalProfesionalIngeniería de Sistemas - EPEIngeniería de Sistemas - EPE

Introducción a la Introducción a la arquitectura JavaEEarquitectura JavaEE

JavaEEJavaEE

• 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-tierJavaEE: Arquitectura n-tier

JavaEE: API’s y tecnologíasJavaEE: API’s y tecnologías

Web ContainerWeb 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 ContainerEJB 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.

Programa de Actualización Programa de Actualización ProfesionalProfesionalIngeniería de Sistemas - EPEIngeniería de Sistemas - EPE

Comparación de Comparación de tecnologías Webtecnologías Web

Otras tecnologías y lenguajes Otras tecnologías y lenguajes para Webpara Web

ASP.NET

PHP

Perl

Ruby

Python

Programa de Actualización Programa de Actualización ProfesionalProfesionalIngeniería de Sistemas - EPEIngeniería de Sistemas - EPE

Servidores de Servidores de aplicacionesaplicaciones

CaracterísticasCaracterísticas

CaracterísticasCaracterí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 aplicacionesServidor 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 Servidores

• Open Source– Tomcat (sólo Web container)– GlassFish– Jboss– Geronimo

• Comerciales– IBM WebSphere Application Server– Oracle WebLogic– SAP Netweaver

ReferenciasReferencias

• 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/