Desarrollando servidores de información con Java

Transcripción

1 Desarrollando servidores de información con Java Mario Muñoz Organero & Norberto Fernández Departamento de Ingeniería Telemática Qué vamos a ver? En una palabra: JEE (antes J2EE) Java Enterprise Edition Y eso qué es? Según SUN: Java Platform, Enterprise Edition (Java EE) is a set of coordinated technologies that significantly reduces the cost and complexity of developing, deploying, and managing multitier, server-centric applications. Building on the Java Platform, Standard Edition (Java SE), Java EE adds the capabilities that provide a complete, stable, secure, and fast Java platform for the enterprise. Fuente: (08/10/2008) Plataforma para el desarrollo de aplicaciones empresariales con Java Alta disponibilidad, seguras, fiables y escalables Actualmente especificación JEE 5.0: JSR 244 Mario Muñoz Organero & Norberto Fernández Servidores de Información 2

2 Qué vamos a ver? Con más detalle: Arquitectura genérica de servidores de información Capas típicas, patrón MVC (Model-View-Controller) Tecnologías Java para la implementación de cada capa Tecnologías que forman parte de JEE: V: Servlet/JSP (Java Server Pages) C: Servlet M: EJB (Enterprise Java Bean) Mario Muñoz Organero & Norberto Fernández Servidores de Información 3 Y por qué vemos esto? Fuente: (08/10/2008) Mario Muñoz Organero & Norberto Fernández Servidores de Información 4

3 Y por qué vemos esto? Fuente: (08/10/2008) Mario Muñoz Organero & Norberto Fernández Servidores de Información 5 Arquitecturas típicas de servidores de información Mario Muñoz Organero & Norberto Fernández Departamento de Ingeniería Telemática

4 Introducción En general una aplicación software: Utiliza datos Que son manipulados por ciertos procedimientos Para producir resultados que hay que comunicar a un usuario (generalmente) humano Tenemos por tanto: datos, procesamiento (lógica), interacción (interfaz) con usuarios En aplicaciones de escritorio, generalmente todos los elementos están en el mismo PC Pero en nuestro caso el escenario es otro Mario Muñoz Organero & Norberto Fernández Servidores de Información 7 Escenario de la asignatura RED Comunicaciones Servidores información Intercambio de datos Clientes Mario Muñoz Organero & Norberto Fernández Servidores de Información 8

5 Arquitecturas Dónde ponemos cada cosa? Arquitecturas Cliente-servidor con cliente pesado (thick o fat client) El programa cliente tiene la lógica de la aplicación y obtiene datos que le resultan necesarios del servidor Cliente ligero (arquitecturas multi-capa o multi-tier ) La lógica de aplicación y control de la presentación se realiza en el servidor Cliente thin-fat? Repartir la lógica entre cliente y servidor AJAX Mario Muñoz Organero & Norberto Fernández Servidores de Información 9 Arquitecturas cliente/servidor Nivel Cliente Nivel Servidor Cliente Servidor Fat client Lógica de negocio Datos Mario Muñoz Organero & Norberto Fernández Servidores de Información 10

6 Distribución de la lógica Un servidor de información puede descomponerse en 3 funciones principales: Control de la presentación de la información que se envía a los clientes Mantenimiento de la lógica de negocio Almacenamiento permanente de la información Dependiendo de cómo se implemente físicamente obtenemos un servidor en: 1 capa o grada o tier 2 capas o gradas o tiers 3 (en general N) capas o gradas o tiers (sistemas multi-tier) Mario Muñoz Organero & Norberto Fernández Servidores de Información 11 Arquitectura de 1 capa Desde los 50s hasta la actualidad Aplicaciones monolíticas ejecutadas en un servidor central (mainframe) Todas las capas en la misma máquina Accedidas desde terminales tontos Sin capacidad de procesamiento, sólo muestran información Hardware potente Alto rendimiento Diseño para alta fiabilidad Mario Muñoz Organero & Norberto Fernández Servidores de Información 12

7 Arquitectura de 1 capa Sin problemas de compatibilidad No hay heterogeneidad Implantación sencilla de clientes Simplemente conectar más terminales Limitaciones: Coste del mainframe Centenares de miles de dólares Mantenimiento caro y costoso Necesidad de técnicos especializados Mario Muñoz Organero & Norberto Fernández Servidores de Información 13 Arquitectura de 2 capas De los 80s a mediados de los 90s Con la aparición de los PCs Capa de presentación en el cliente Capa de datos en el servidor Lógica de aplicación mezclada con las otras capas. Dónde? las opciones varían entre: Cliente pesado/servidor ligero Cliente ligero/servidor pesado y opciones intermedias Distribución de la lógica de negocio entre el cliente y el servidor Mario Muñoz Organero & Norberto Fernández Servidores de Información 14

8 Arquitectura de 2 capas Cliente pesado/servidor ligero Lógica de aplicación en el cliente (integrada con la interfaz, con la capa de presentación) Cambios en lógica cambiar todos los clientes! Acceso a los datos en bruto El cliente conoce la organización de los datos del servidor Menor consumo de recursos en servidor Pero más en el cliente, puede limitar acceso desde ciertos dispositivos Ej.: aplicación que corre en un PC y accede a un SGDB relacional remoto mediante SQL Mario Muñoz Organero & Norberto Fernández Servidores de Información 15 Arquitectura de 2 capas Cliente ligero/servidor pesado Lógica de aplicación en el servidor (integrada con la capa de datos) Usando por ejemplo Procedimientos almacenados en la BD El cliente accede a procedimientos, no a datos Menor carga de red que cliente grueso (una solicitud de procedimiento en lugar de varias consultas a base de datos) Necesarios menos recursos en cliente Clientes pueden ser dispositivos limitados, costes menores Mario Muñoz Organero & Norberto Fernández Servidores de Información 16

9 Arquitectura de 2 capas Administración más sencilla Mayor parte de configuración, monitorización, servidores, que son menos que los clientes Flexibilidad Cambio en lógica de negocio (p. ej.: en la implementación de un procedimiento) puede no afectar al cliente Siempre que no cambie la interfaz de los procedimientos a los que el cliente accede en Mario Muñoz Organero & Norberto Fernández Servidores de Información 17 Arquitectura de 2 capas Ejemplo de procedimiento almacenado en lenguaje PL/pgSQL Fuente: (08/10/2008) Mario Muñoz Organero & Norberto Fernández Servidores de Información 18

10 Arquitectura de 2 capas Limitaciones: Tener en cuenta la heterogeneidad de clientes (distinto hardware/s.o.) Implementación de capas de presentación distintas para distintas necesidades y arquitecturas de cliente Escalabilidad: número reducido de clientes por servidor Cada cliente una sesión con el servidor de BD Si hacemos que el servidor de BD ejecute la lógica de negocio y ésta es compleja, podemos sobrecargarlo Mario Muñoz Organero & Norberto Fernández Servidores de Información 19 Arquitectura de 3 capas Mediados de los 90s: crisis de los sistemas de 2 capas arquitectura de 3 capas Las tres capas están separadas Mayor escalabilidad La capa de lógica de negocio puede implementarse en servidores distintos a los de la capa de datos (se reparte el trabajo) servidores de aplicaciones Cada nivel comunica sólo con los niveles contiguos a través de interfaces claramente definidas Clientes son en general ligeros Mario Muñoz Organero & Norberto Fernández Servidores de Información 20

11 Arquitectura de 3 capas La capa de lógica de negocio coordina e integra los distintos elementos de la capa de datos Cambios en capa de datos transparentes al cliente Ejemplos: SAP R/3 Desventajas: Mayor dificultad para desarrollo que 2 capas Puede aumentar el tiempo de respuesta Comunicación extra de red si servidores de aplicaciones remotos Mario Muñoz Organero & Norberto Fernández Servidores de Información 21 Arquitectura de N capas Evolución de la de 3 capas: la lógica de negocio se subdivide en componentes encargados de funciones de negocio concretas Componentes fácilmente reutilizables y pueden instalarse en servidores de aplicaciones distribuidos Balanceo de carga, tolerancia a fallos, escalabilidad, flexibilidad (añadir nuevos componentes, sustituir unos por otros) Componentes pueden encapsular aplicaciones heredadas Limitación: Puede aumentar el tiempo de respuesta Mario Muñoz Organero & Norberto Fernández Servidores de Información 22

12 Distribución de la lógica Capa de presentación (PL) Capa de lógica de negocio (BLL) Capa de datos (DL) Cliente tier tier tier Mario Muñoz Organero & Norberto Fernández Servidores de Información 23 Contando Tiers Fat Client Fat Server Cliente PL+ BLL+DL Cliente + PL + BLL DL middleware Cliente + PL BLL+DL 1- tier 2 - tier Mario Muñoz Organero & Norberto Fernández Servidores de Información 24

13 3 tiers Client + PL middleware BLL middleware DL Client PL middleware BLL DL HTTP, Servicios Web SQL,... Navegador Servidor Web Servidor de aplicaciones Base de datos Mario Muñoz Organero & Norberto Fernández Servidores de Información 25 Nivel Cliente Ejemplo: arquitectura multi-nivel Thin client Windows Macintosh Unix Java Browser Nivel Medio Presentación Lógica de negocio Componente banco Componente cuenta cliente Componente movimiento Driver base de datos Conector Servicio transacciones Nivel Datos Back End SAP/R3 server DBMS server Servidor Web Servidor Aplicaciones Mario Muñoz Organero & Norberto Fernández Servidores de Información 26

14 Ventajas de las arquitecturas multi-nivel Las partes críticas de la aplicación se encuentran en el nivel medio, más cercanos a nivel de datos acceso más eficiente Sólo los datos necesarios son transferidos al cliente menor carga de red Problema: al aumentar el número de niveles aumenta el número de comunicaciones, aumentando el tiempo de respuesta Mayor flexibilidad, diseño modular y escalabilidad Además: Menores costes de desarrollo (reutilización de componentes) Facilidad en el cambio de la base de datos Aislamiento frente a cambios Seguridad Localización de fallos Mario Muñoz Organero & Norberto Fernández Servidores de Información 27 Tecnologías y formatos XHTML XML HTML SSL/TLS CGI Perl PHP Web Services Servidor info.net Servlets ASP SOAP UDDI J2EE JSP Bases de datos Código en el cliente EJBs JavaScript AJAX Applets Mario Muñoz Organero & Norberto Fernández Servidores de Información 28

15 Objetivo Utilizar la plataforma JEE para el desarrollo de un servidor de información PL JSPs, Servlets CORBA, RMI, Servicios Web BLL EJBs Mario Muñoz Organero & Norberto Fernández Servidores de Información 29 Arquitectura de una aplicación Web JEE Servidor de aplicaciones Cliente Web Web Container Servlets, JSP EJB Container JCA Nivel datos (EIS) HTTP RMI-IIOP JDBC Mario Muñoz Organero & Norberto Fernández Servidores de Información 30

16 Servidor de aplicaciones Es un sistema de soporte para componentes de servidor Proporciona un entorno de desarrollo para los componentes, que a su vez proporcionan la lógica de negocio Los componentes de servidor utilizan los servicios del servidor de aplicaciones Los elementos constitutivos del servidor de aplicaciones se denominan también componentes y pueden instalarse y administrase de forma independiente Tareas de infraestructura: Localización e instanciación de componentes Comunicación Sincronización de accesos concurrentes Preparación de un entorno seguro Disponibilidad Seguridad de transacciones Mario Muñoz Organero & Norberto Fernández Servidores de Información 31 Elementos de un servidor de aplicaciones Servicio de nombres Servicio de directorio Servlets Componentes EJB CORBA COM Web Adapter Conectores Legados Servicio de transacciones Gestión estado Pooling instancias Balanceo carga Pooling conexiones Comunicación Seguridad Cliente/Servidor (HTTP, IIOP, RMI, DCOM) Mensajes (Pub/Sub, colas) Eventos Data streaming Mario Muñoz Organero & Norberto Fernández Servidores de Información 32

17 Arquitectura de aplicación JEE Nivel cliente Nivel(es) servidor de aplicación Nivel EIS Cliente Web Web Container EJB Container Bases de datos Container Cliente Aplicaciones legado Cliente Java Servlets, JSP Enterprise JavaBeans Servicios y APIs JNDI, RMI-IIOP, Servicios y APIs JNDI, JMS, JTA, Servicios y APIs JNDI, JMS, JTA, Sistemas ERP JSE JEE JEE Mario Muñoz Organero & Norberto Fernández Servidores de Información 33 Enterprise JavaBeans Enterprise JavaBeans (EJB) es una especificación de arquitectura para componentes de servicio Permite el desarrollo en Java de aplicaciones multi-nivel, basadas en componentes y orientadas a transacciones, que se apoyan en servidores de aplicación y otros productos middleware Objetivos de la arquitectura de componentes EJB: Facilitar el desarrollo de aplicaciones, concentrándose en la lógica de negocio: desarrollo, aplicación y aspectos de tiempo de ejecución Independencia del proveedor de componentes mediante la especificación de interfaces Independencia de la plataforma gracias al principio: Write Once Run Anywhere (WORA) y a su realización en Java Compatibilidad con Java-APIs existentes, con sistemas de servidor de terceros y con protocolos CORBA Mario Muñoz Organero & Norberto Fernández Servidores de Información 34

18 Contenedores (containers) Ofrecen el entorno de ejecución para todos los componentes de aplicación Proporcionan una vista uniforme de los servicios de la plataforma JEE Herramientas adicionales (Deployment Tools) para la instalación, configuración y monitorización de componentes (también en tiempo de ejecución) Las tareas principales del contenedor son la gestión de recursos y del ciclo de vida de los componentes de la aplicación Servlet / JSP Container JSP Tools Servlet Engine JSP: JSP: JSP: Servicios EJB Container Enterprise JavaBeans Gestión recursos Servicios Mario Muñoz Organero & Norberto Fernández Servidores de Información 35 Patrón MVC Patrón de diseño habitual de aplicaciones JEE Model-View-Controller Model: Datos y lógica de negocio que opera con los datos View: Interfaz de usuario. Presentan información A través de la interfaz el usuario genera eventos Controller: Control del flujo de aplicación Reciben eventos del usuario, invocan servicios ofrecidos por el modelo y seleccionan la vista adecuada para presentar los resultados Mario Muñoz Organero & Norberto Fernández Servidores de Información 36

19 Patrón MVC Fuente: (08/10/2008) Mario Muñoz Organero & Norberto Fernández Servidores de Información 37 Patrón MVC para JEE (2) Model (EJB, POJO) (1) Controller (Servlet) (3) (3 alt) (4) View (JSP) Mario Muñoz Organero & Norberto Fernández Servidores de Información 38

20 Bibliografía Designing Enterprise Applications with the J2EE Platform, 2nd Edition I. Singh, B. Stearns, M. Johnson et al. Addison-Wesley, 2002 ISBN: Disponible en PDF en la web de SUN Especificación JEE 5.0 (JSR 244) (08/10/2008) Mario Muñoz Organero & Norberto Fernández Servidores de Información 39