Parte I: Introducción al Java 2
Enterprise Edition
Ignacio Ramos Zapata
Departamento de Ingeniería Telemática Universidad Carlos III de Madrid
Contenido
Ÿ
Introducción
– Evolución de las aplicaciones Web
– Arquitecturas cliente-servidor y multi-tier
– Integración de aplicaciones corporativas: la
plataforma Java 2, Enterprise Edition
(J2EE)
Requisitos de las aplicaciones empresariales
Ÿ Almacenamiento y acceso de datos (Back-end integration):
empleo de sistemas de bases de datos (DBMS), conexión a la base de datos, representación de los datos en la base de datos
Ÿ Mapping de datos y persistencia: representación de los datos en los programas (clases) y correspondencia (mapping) con su representación en la base de datos, actualización de la base de datos tras cambios por el programa
Ÿ Consistencia de datos: control de acceso concurrente a los datos, monitores de transacción
Ÿ Interacción con el usuario: autentificación, control de acceso, coordinación de accesos concurrentes
Ÿ Acceso a datos comunes: aislamiento de los distintos accesos, cache de datos
Requisitos de las aplicaciones empresariales
Ÿ
Performance
:
tiempo de respuesta, interacción
eficiente entre los distintos componentes
Ÿ
Escalabilidad
:
posibilidad de incorporar nuevos
servidores, distribución de carga
Ÿ
Disponibilidad
:
seguridad frente a caídas de la
aplicación (ideal disponibilidad 24 x 7), sistemas de
tolerancia a fallos, clustering de servidores y datos
Ÿ
Diseño software
:
mantenibilidad y portabilidad ?
modularidad, diseño en niveles, reducción de
dependencias externas (por ejemplo, en la base de
datos)
Evolución de las aplicaciones Web - Contenido estático
Ÿ
Las organizaciones pretenden ofrecer
información a tantos clientes como sea posible
Ÿ
Gracias a la web, se puede mostrar información
en páginas HTML estáticas almacenadas en el
File System
Evolución de las aplicaciones Web - CGIs
Ÿ
Extensiones (plug-ins) a los servidores Web
que invocan aplicaciones de servidor
Ÿ
Scripts CGI-BIN:
– No proporcionan encapsulación estructurada de
los procesos y entidades de negocio
– Difíciles de desarrollar, mantener y gestionar
– Mezclan la lógica de negocio con la lógica de
presentación
– Difícil mantenimiento de las reglas de negocio
(distribuidas por varios cgi-bins en varios
Evolución de las aplicaciones Web - Applets
Ÿ
Usando páginas HTML estáticas, los usuarios
ven páginas pasivas que no cambian
Ÿ
Usando Applets Java u otros programas en el
lado cliente se pueden producir contenidos
dinámicos
Evolución de las aplicaciones Web - Servlets
Ÿ
Los applets no pueden acceder directamente a la
información de los back-end systems
Ÿ
El Web Container puede proporcionar componentes en el
servidor (p.e. Servlets) para generar contenidos
Evolución de las aplicaciones Web - JSPs
Ÿ
Pobre separación entre lógica de negocio y lógica de
presentación
Evolución de las aplicaciones Web - EJBs
Ÿ
EJBs:
– Se puede acceder a ellos remotamente a través de la red
– Encapsulan reglas de negocio, lógica específica de aplicación y acceso a datos
– Pueden ser usados por diferentes aplicaciones de manera concurrente
Evolución de las aplicaciones Web
-Escalabilidad
Ÿ Las aplicaciones empresariales suelen requerir alta disponibilidad
Ÿ Incremento en el rendimiento a medida que crece el negocio
Ÿ Estos dos requerimientos se pueden alcanzar incrementando el nº de
servidores:
– Para proporcionar redundancia en el sistema
El patrón MVC: Model-View-Controller
Ÿ Es un patrón para el diseño de aplicaciones
Ÿ Ampliamente extendido como un concepto clave en el desarrollo de aplicaciones J2EE
Ÿ Aporta grandes beneficios (veremos más adelante)
– Facilita la reutilización de código – Reduce el tiempo de desarrollo
Ÿ The Model
– Representa los datos y la lógica de negocio
– No contiene información acerca de la interfaz de usuario
Ÿ The View
– La interfaz de usuario - aquello que ve el usuario y a lo que puede responder
– Representa una ventana dentro del modelo
Ÿ The Controller
– Conecta el modelo y la vista
– Se usa como comunicación entre el modelo y la vista
Ÿ En ocasiones aparece una cuarta capa de persistencia - que se añade al patrón
MVC - Beneficios
Ÿ
Promueve la reutilización de código
– El propósito del modelo es el de proporcionar la lógica de negocio y de acceso a la información desde un único lugar – Esta lógica puede ser reusada por múltiples aplicaciones al
mismo tiempo sin necesidad de ningún código adicional
Ÿ
Reduce el tiempo de desarrollo
– El Model, el View y el Controller de pueden desarrollar en paralelo
Ÿ
Facilita el mantenimiento
– El View puede cambiar sin afectar al Model
• En una página web se puede poner un gráfico en lugar de una tabla sin que afecte al Model
– El Model puede cambiar sin afectar al View
• La forma de calcular la prima de un seguro podría cambiar manteniendo la interfaz en la lógica de negocio
Arquitecturas para aplicaciones empresariales
Ÿ
Las aplicaciones complejas basadas en
componentes se subdividen en niveles
lógicos
Ÿ
Cada nivel cubre un área de tareas y puede
estar compuesto de una o varias partes
Ÿ
La división en niveles es una abstracción
Arquitecturas cliente/servidor
Ÿ Reparto funcional y físico de la aplicación en dos niveles 1. Parte del cliente, en el ordenador del usuario:
– Elementos de un programa clásico: lógica de ejecución,
preparación y presentación de información, interacción con el usuario
2. Parte del servidor:
• Datos de negocio (en una base de datos o, en general, en el Enterprise Information System (EIS) )
Ÿ Cliente y servidor están débilmente acoplados y se comunican
solamente mediante mensajes
Ÿ La solicitud de servicio (iniciación de la comunicación) proviene siempre del cliente. El servidor reacciona mediante una
respuesta
Ÿ Gran parte de la aplicación corre en el lado del cliente (“Fat Client”) ? modelo descentralizado
Arquitecturas cliente/servidor
Nivel Cliente Nivel Servidor
“Fat client” Cliente Servidor Datos Lógica de negocio
Inconvenientes arquitectura cliente/servidor
Ÿ
En general, falta de escalabilidad
Ÿ
Problemas de integridad en la base de datos
Ÿ
Alta carga en la red:
– Gran número de pasos de comunicación necesarios
– Cantidad de resultados devueltos por la base de datos mayor de lo necesario
Ÿ
Costosa distribución y actualización del software
(cientos o miles de clientes)
Ÿ
El diseñador de la aplicación precisa un conocimiento
profundo de muchas áreas críticas
– Control de transacciones – Modelo de seguridad
Arquitecturas multi-tier (multi-nivel)
Ÿ
En las arquitecturas multi-tier, se añaden
niveles (tiers) software adicionales que se
encargan de realizar ciertas tareas críticas
– Los “Fat client” se convierten en “Thin client”
Ÿ
Los niveles intermedios extienden la
responsabilidad del lado del servidor
– Aunque pueden estar situados en ordenadores o
sistemas independientes
Ÿ
Cada nivel comunica sólo con los niveles
contiguos a través de interfaces claramente
definidas
Ejemplo de distribución básica multi-nivel
Ÿ Nivel cliente (Client tier):
– Interfaz de usuario e interacción con el usuario (aplicaciones o applets Java, o páginas Web)
Ÿ Nivel medio (Middle tier):
– Servidor de aplicaciones: parte principal de la aplicación (lógica de la aplicación y de negocio, preparación de la información para el usuario)
• Procesado de datos basado en transacciones • Acceso seguro
– Middleware: software especializado para la realización de determinadas tareas:
• Monitores, sistemas de nombres, sistemas de colas de mensajes, etc.
– Procesado de la presentación, por ejemplo Web-servers
Ÿ Nivel de datos (Back-end tier):
– Bases de datos o Enterprise Information Systems
Arquitecturas multi-nivel (multi-tier)
Nivel Cliente Nivel EIS
“Thin client” Cliente Servidor Datos Nivel Medio Lógica de negocio Servicios
Arquitectura tradicional en tres niveles
Nivel Cliente Nivel EIS
Lógica de presentación Servidor Datos Nivel Medio Lógica de negocio
Arquitectura tradicional en tres niveles
Ÿ
El mivel medio aumenta la escalabilidad
reutilizando recursos
→
mejora rendimiento
Ÿ
Mejora la seguridad y gestión de aplicación
Ÿ
Problemas:
– Complejidad (distribución, multithreading, seguridad)
– Falta de portabilidad (distintas APIs)
– Soporte limitado (distintos protocolos, herramientas,
vendedores)
Ejemplo: arquitectura multi-nivel
Thin client Lógica de negocio Windows Componente cuenta cliente Nivel Cliente Nivel Medio Macintosh Unix Java Browser Presentación
Servidor Web Servidor Aplicación
Back End Nivel Datos DBMS server SAP/R3 server Componente movimiento Componente banco
Driver base de datos Conector Sevicio transacciones
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 y escalabilidad. Además:
– Menores costes de instalación
– Facilidad en el cambio de la base de datos – Aislamiento frente a cambios
– Seguridad
– Administración central de recursos – Localización de fallos
Java 2 Platform, Enterprise Edition (J2EE)
Ÿ Colección de especificaciones y directivas de programación para
facilitar el desarrollo de aplicaciones de servidor distribuidas multi-nivel, alineada fuertemente con Internet
Un poco de historia…
Ÿ 1996: Java Development Kit (JDK) 1.02: colección ordenada de
bibliotecas de clases y paquetes
Ÿ 1999: JDK 1.2 ? Java 2 Platform: adicional al JDK, paquetes
opcionales para mensajes, generación dinámica de páginas Web o programas de email en Java. Dividida en 3 ediciones:
– Java 2 Platform, Standard Edition (J2SE): contiene el JDK actual y las APIs estándar. Desarrollo de aplicaciones de Desktop y applets – Java 2 Platform, Enterprise Edition (J2EE): basada en J2SE,
extiende el lado del servidor. Version 1.3, 3er Trimestre 2001. – Java 2 Platform, Micro Edition (J2ME): especial para móviles,
Elementos de la especificación J2EE
Ÿ
J2EE Platform: estándar representado por un
conjunto de APIs y directivas, soportadas por un
servidor de aplicación
(
java.sun.com/j2ee/download.html)
Ÿ
J2EE Blueprints: consejos para el desarrollo de
aplicaciones J2EE, patrones de diseño y un ejemplo
de aplicación (
java.sun.com/blueprints/)
Ÿ
J2EE Server: implementación de referencia de un
servidor de aplicaciones para J2EE, incluido en J2EE
SDK (
java.sun.com/j2ee/download.html)
Ÿ
J2EE Testsuite: J2EE Compatibility Testsuite (CTS),
tests de compatibilidad
Componentes J2EE
Ÿ J2EE define cuatro tipos de componentes
Ÿ Tienen que estar soportados por cualquier producto J2EE
Ÿ El despliegue puede ser gestionado usando "deployment
descriptors" (excepto applets)
Ÿ Aplicaciones cliente
– Programas Java que se ejecuten en una máquina cliente desde los que se puede acceder a otros componentes J2EE
Ÿ Applets
– Componentes gráficos que se ejecutan tipicamente en un browser – Pueden proporcionar una avanzada interfaz de usuario para otros
componentes J2EE
Ÿ Componentes Web
– Servlets y JSPs
Ÿ Enterprise Java Beans
– Componenetes distribuidos y transaccionales que comtienen lógica de negocio y de acceso a datos
Containers (contenedores)
Ÿ Ofrecen el entorno de ejecución para todos los componentes de
aplicación
Ÿ Proporcionan una vista uniforme de los servicios solicitados en la especificación
Ÿ Herramientas adicionales (Deployment Tools) para la instalación
y configuración de componentes (también en tiempo de ejecución)
Ÿ Las tareas principales de los componentes del lado del servidor
son la gestión de recursos y del ciclo de vida
Applet Container
Applets
Applic. Client Container (J2SE) Servlet/JSP Container JSP Tools Servlet Engine JSP: JSP: JSP: Servicios Servicios EJB Container Gestión recursos Enterprise JavaBeans
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:
– Instanciación de componentes – Comunicación
– Sincronización de acceso concurrentes – Preparación de un entorno seguro
– Disponibilidad
Enterprise JavaBeans
Ÿ Enterprise JavaBeans (EJB) es una completa 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
Servicios J2EE
Ÿ
Los servicios J2EE estándard incluyen lo siguiente:
– HTTP (Hipertext Transfer Protocol)
– RMI-IIOP (Remote Method Invocation over the Internet Inter-ORB Protocol)
– Java IDL (Java Interface Definition Language) – JTA (Java Transaction API)
– JDBC
– JMS (Java Message Service) – JavaMail
– JAF (JavaBeans Activation Framework)
– JNDI (Java Naming and Directory Interface) – JAXP (Java API for XMl Parsing)
– JCA (J2EE Connector Architecture)
Servicios J2EE
Ÿ Servicio de nombres: acceso a componentes y recursos mediante
nombres lógicos
– portabilidad y mantenibilidad
– Java Naming and Directory Interface (JNDI)
Ÿ Servicio de transacciones: ejecución de una serie de pasos de forma atómica y aislada
– concepto declarativo de límite de transacción mediante descriptores – posibilidad de control de transacción programada mediante un interfaz
de programación
– Java Transaction Service (JTS)
Ÿ Servicio de seguridad: directivas de seguridad para recursos protegidos
– control de acceso en J2EE en dos pasos: autentificación y autorización – realización declarativa o programada
Servicios J2EE
Ÿ Persistencia: almacenamiento persistente de objetos y estados de objetos, normalmente realizado en bases de datos relacionales
– JDBC
Ÿ Comunicación: distintas técnicas de comunicación, proporcionadas por el proveedor de servicio de aplicación o de containers
– Comunicaciones Web: TCP/IP, UDP/IP, HTTP 1.0 y HTTPS (con SSL adicionalmente)
– Procesado de objetos distribuidos: RMI (Remote Method Invocation), basado en Java Remote Method Protocol (JRMP). Extensión a RMI que
soporta además el protocolo CORBA-IIOP para interoperabilidad entre J2EE y sistemas CORBA.
Ÿ Servicios de configuración y administración: empaquetamiento,
instalación y configuración flexible de componentes y la administración de aplicaciones
– descripción mediante esquemas XML de las características de servidores, containers, aplicaciones, componentes y servicios.
Clases en UML
Ventana origen dimensión abre() cierra() mueve() nombre atributos operacionesNombres de clase
Ÿ
Toda clase tiene un nombre que la distingue del resto
de clases en el ámbito del modelo
– Nombre de clase = [paquete::]nombre-simple – Ejemplos: Negocio::Cliente,SensorTemperatura
Ÿ
El nombre de la clase es una cadena de cualquier
longitud que contiene letras y números y signos de
puntuación (salvo ::)
Ÿ
Habitualmente los nombres de clases son sustantivos
o frases con esa función gramatical
Cliente SensorTemperatura
Contrato Libro
Display
Fichero
Atributos de clase
Ÿ Un atributo representa una propiedad característica compartida por
todos los objetos de la clase.
Ÿ Una clase puede tener cualquier número de atributos:
– Atributo = nombre[:tipo][=valorPorDefecto] – Ejemplos: fechaNacimiento, estatura : float
Ÿ El nombre de un atributo es una cadena de cualquier longitud que
contiene letras y números
Ÿ Habitualmente los nombres de atributo son sustantivos o frases con esa
función gramatical
Rectángulo
altura: Float base: Float
Operaciones
Ÿ
Una operación es un servicio básico ofrecido por los objetos
de una clase:
– Operación = nombre([arg:tipo],...)[:tipoRetorno] – Ejemplo = new(), new(origen:Punto)
Ÿ
La implementación concreta que una clase hace de una
operación se llama
método
Ÿ
Con frecuencia la invocación de una operación provoca un
cambio de estado en el objeto
Ÿ
Habitualmente los nombres de operación son verbos o
frases con esa función gramatical
Rectángulo
new()
mueve(destino: Punto) calculaArea(): Float
Responsabilidades
Ÿ Una responsabilidad es un contrato u obligación de una clase en el
contexto de un modelo
Ÿ Atributos y operaciones son las características de la clase a través de las cuales las responsabilidades se llevan a cabo
Ÿ Expresión informal de la semántica mediante texto libre
Ÿ La responsabilidad global del modelo debe repartirse de forma
equilibrada entre sus clases
Ÿ Algunos métodos ayudan a determinar las responsabilidades de las
clases: e.g. CRC Rectángulo Responsabilidades -Representación gráfica de rectángulo a partir de su origen y dimensiones -Cálculo de valores geométricos como área,
Comportamiento extra (adorno). También pueden utilizarse notas de comentario
Relaciones
Ÿ Los sistemas OO se estructuran
en forma de abstracciones (clases) interrelacionadas. En UML hay tres tipos de interrelaciones básicas:
– Dependencia: Expresa una relación de uso entre clases
– Generalización: Relaciona clases generales con clases
especializadas a partir de ellas o, viceversa, clases generalizadas a partir de características comunes de clases más concretas
(herencia)
– Asociación: Relaciones
estructurales genéricas entre clases. Entidades Dependencia Generalización Asociación Realización
Dependencia
Ÿ
Relación de dependencia entre dos elementos
estructurales de UML que establece que un cambio
en uno de ellos (el independiente) puede afectar al
otro (el dependiente) puede afectar al otro (el
dependiente).
Ÿ
La relación suele ser unidireccional.
Ÿ
La interpretación más frecuente es la de relación de
uso entre clases: una clase utiliza a otra como
argumento en la signatura de una operación.
Ÿ
UML distingue otros tipos de dependencia:
– Derivación – Instanciación – Refinamiento, etc. Applet MiApplet paint(g:Graphics) Graphics Dependencia (uso)
Generalización
Ÿ Relación entre una abstracción general (superclase) y una
abstracción más concreta del mismo tipo (subclase).
– Taxonomía ejemplo: empleado, secretario, informático, directivo, ...
Ÿ Una clase puede tener cero, una (herencia simple) o más
superclases (herencia múltiple)
Ÿ Una clase sin superclases es una clase raíz
Ÿ Una clase sin subclases es una clase hoja
Figura paint(g:Graphics) Línea extremos Elipse semiejes area() perímetro() Polígono vértices mueve() perímetro()
Asociación
Ÿ Relación estructural entre abstracciones que implica
interconexión o enlace entre los objetos representados por las abstracciones:
• Una biblioteca almacena libros
Ÿ Es una relación, por lo general, simétrica
Ÿ Las asociaciones más comunes son las binarias, pero las hay
n-arias
Ÿ La representación básica es una línea enlazando las clases,
pero puede incluir otros adornos: nombre, roles, multiplicidad y agregación
Biblioteca Libro
almacena >
Asociación
Ÿ Nombre. Describe la asociación. Normalmente un verbo. Puede
incluir dirección de lectura
Ÿ Rol. Describe el papel específico que una clase juega en una
asociación. Una clase puede jugar distintos roles en diferentes asociaciones
Ÿ Multiplicidad. Especifica por cada clase de la asociación el
número de objetos de la clase opuesta que se relacionan con un solo objeto de dicha clase a través de la asociación:
• Uno (1), cero o uno (0..1), tres (3), muchos (*), al menos uno (1..*), dos, cuatro o cinco (2,4,5), ... Empresa Persona Trabaja para > * 1..* empleado empleador Multiplicidad Roles
Agregación
Ÿ Tipo especial de asociación que representa la relación “es parte de”. Es decir, una de las clases es una abstracción compuesta de otras que son sus diferentes partes (componentes)
Ÿ Si la relación de agregación es fuerte, de tal forma que los componentes no pueden existir independientemente, se
denomina composición
Ÿ La agregación no implica diferencia semántica respecto de una asociación genérica. La composición liga la existencia de los componentes a la de la clase compuesta
Cadena Eslabón Proceso Hilo 1 2..* * 1 Clase componente Clase agregada Clase componente Clase compuesta agregación composición
