Tema 1: Introducción a J2EE

Índice

n 1.1 Características de las aplicaciones empresariales

n 1.2 Visión general de la plataforma J2EE

n 1.3 Patrones arquitectónicos Model-View-Controller y Layers

Características de las aplicaciones empresariales (1)

n Acceso a bases de datos (BD)n Normalmente con BD relacionales

n Transaccionalesn Propiedades ACID (Atomicity-Consistency-Isolation-

Durability)

n Escalablesn Deberían poder soportar más carga de trabajo sin necesidad

de modificar el software (sólo añadir más máquinas)

n Segurasn No todos los usuarios pueden acceder a la misma

funcionalidad

n Tipo de interfazn De entorno de ventanas: normalmente sólo tiene sentido en

intranetsn Web: en intranets, y desde luego en Internet

Características de las aplicaciones empresariales (y 2)

n Separación clara entre vista y modelon Vista: aspecto gráficon Modelo: encapsula la lógica de negocion Ejemplo => aplicación bancaria

n Modelo: conjunto de clases que nos permiten: crear cuentas, destruirlas, encontrarlas por distintos criterios, hacer transferencias bancarias, etc.

n Vista: el interfaz gráfico que permite a los empleados del bancorealizar las anteriores operaciones

n El modelo debería ser reusable con distintas vistasn En el ejemplo de la aplicación bancaria podría haber dos vistas:

una interfaz web (aunque sea una aplicación para uso en una intranet) o un interfaz gráfico con ventanas

n Arquitecturas multi-capan Vamos a ver los ejemplos más usuales ...

Ejemplo: Una aplicación bancaria en dos capas

Intranet

Base de datos

Vistaap. Modelo

Aplicación

Aplicación Aplicación

Capa 1 Capa 2

Vistaap. Modelo Vista

ap. Modelo

Ejemplo : Una aplicación bancaria en dos capas - Problemas

n Problemas de modificación de la versión del modelon Cambios de drivers de acceso a la BDn Cambios de esquemasn Cambio de tipo de BDn Cambios en la lógica del modelo

n No optimiza las conexiones a la BDn No es posible tener un pool de conexiones global

n No optimiza los accesos a la redn Cada vez que el modelo lanza una consulta/actualización a

la BD, se envía un mensaje a la BD (quizás atravesando varios routers)

Ejemplo: Una aplicación bancaria en tres capas

Intranet

Base de datos

Capa 2 Capa 3Capa 1Vistaap.

Vistaap.

Vistaap.

Modelo

Ejemplo: Una aplicación Internet típica en dos capas

Internet

Base de datosServidor aplicaciones

web

Capa 1 Capa 2

NavegadorVistaweb

Modelo

Navegador

Navegador

Ejemplo: Una aplicación Internet típica en dos capas - Problemas

n Problema 1n Nuestra aplicación web tiene “éxito” (es decir, muchos

accesos)n La solución no es escalable

n Problema 2n ¿ Y si queremos tener otra vista , por ejemplo, una

aplicación de administración con interfaz gráfico de ventanas (dentro de la intranet) ?

n Problemas de actualización de la versión del modelo

Ejemplo: Una aplicación Internet típica en dos capasUna primera solución al problema 1

Internet

Capa 1 Capa 2

Servidor aplicaciones

web

Base de datos

Vista web Modelo

Navegador

Navegador

Navegador

Ejemplo: Una aplicación Internet típica en tres capasMáxima escalabilidad (problema 1) y solución al problema 2

Internet

Base de datos

Capa 1 Capa 2 Capa 3

Vistaaplicación

admin.

Vista web Modelo

Navegador

Navegador

Navegador

Conclusiones sobre arquitecturas multi-capa

n Arquitectura en dos capasn En general, mala arquitectura cuando hay clientes con

interfaz de entorno de ventanasn En muchos casos es una solución perfectamente válida para

aplicaciones con interfaz webn De hecho, es la arquitectura más extendida hoy en día en

Internet (que muchas veces sólo replica la capa web y usa una máquina más potente para la BD) y en las aplicaciones con clientes web en las intranets (que muchas veces no replica ni lacapa web)

n Arquitectura en tres capasn Buena arquitectura para aplicaciones con interfaz de entorno

de ventanasn Con replicación en las tres capas => máxima escalabilidad y

tolerancia a fallos para aplicaciones de Internet e intranets

Un comentario acerca de las interfaces gráficas

n Aplicaciones cliente con interfaces gráficas de entorno de ventanasn Problema de actualización de software: cada vez que se

modifica la versión del interfaz gráfico, es preciso actualizar las máquinas cliente

n Aplicaciones con interfaz webn Las máquinas cliente sólo necesitan un navegadorn Las modificaciones al interfaz se realizan en el lado servidor

=> facilidad de administraciónn No es sólo una solución para Internet, sino también para las

aplicaciones de una intranet (que se benefician de lo anterior)

Visión general de la plataforma J2EE

n J2SE (Java 2 Platform Standard Edition)n Conjunto de especificaciones: lenguaje, máquina virtual, paquetes

básicos (java.util, java.io, java.sql, etc.)

n Sun realiza las especificaciones, pero existen implementaciones de múltiples fabricantes

n J2EE (Java 2 Platform Enterprise Edition)n Conjunto de especificaciones de APIs para facilitar la construcción

de aplicaciones empresariales (se apoya en J2SE)n Todas las APIs se corresponden con paquetes javax.* (ej.:

javax.servlet, javax.jsp, javax.ejb, etc.)n javax significa “Java eXtension”

n Casi todos las abstracciones proporcionadas por los paquetes soninterfaces

n Existen algunos javax en J2SE (ej.: javax.swing, javax.naming, etc.), y cada vez se incorporan más

n Sun realiza las especificaciones, pero existen implementaciones de múltiples fabricantes

Principales APIs que usaremos

n Entre otras, usaremos las siguientes APIsn JDBCn JAXPn Servles y páginas JSPn Enterprise JavaBeans

JDBC

n JDBC => Java DataBase Connectivityn Permite acceder a bases de datos relacionales

n El programador puede lanzar queries (consulta, actualización, inserción y borrado), agrupar queries en transacciones, etc.

n Lo proporciona J2SE (paquete java.sql)n Existe una pequeña parte (paquete javax.sql) que

formaba parte de J2EE, pero que a partir de J2SE 1.4 formará parte de este último

XML (1)n XML (eXtensible Markup Language)

n Lenguaje de tags (similar en sintaxis a HTML)n Estandarizado por http://www.w3.org

n Es extensible:n XML no impone un conjunto de tags, sino sólo unas pocas normas de cómo

usarlos (los tags se abren y se cierran y en medio puede tener otros tags anidados, todos los documentos tienen un tag raíz, los tags pueden tener atributos, etc.)

n Permite escribir documentos de texto que expresan datos y no aspecto visual (a diferencia de HTML)

n Un campo de aplicación típico es el intercambio de datos entre aplicaciones u organizaciones heterogéneas, manteniéndolas desacopladas. Ejemplo:n Queremos realizar una aplicación web que muestra las previsiones

meteorológicas para un conjunto de ciudades en los próximos díasn Contratamos a una empresa de contenidos que nos pase las previsiones

(ej.: el Instituto Nacional de Meteorología).n La empresa en cuestión nos pasa las previsiones en un fichero XML cada “x”

días (empleando unos tags que hemos definido para tal propósito), en vez de en el formato en el que las tenga almacenadas (ej.: el de la base de datos que usen) o el que usemos nosotros

n Parseamos el fichero e insertamos los datos en nuestra base de datosn Nuestra aplicación web lee los datos de la base de datos

XML (2)

n Continuación del ejemplo

<?xml version=“1.0”><forecasts>

<city name="COR"><forecast type="sunny" day="1” month=“10” year=“2001"/><forecast type="foggy" day="2” month=“10” year=“2001"/>

</city><city name="LUG">

<forecast type="rainy" day="1” month=“10” year=“2001"/><forecast type="rainy" day="2” month=“10” year=“2001"/>

</city>...

</forecasts>

n El pequeño conjunto de normas que define XML y la posibilidad dedefinir reglas (ej.: vía DTDs) para especificar qué tags son válidos (y qué sintaxis admiten), permite construir parsers genéricos que son capaces de comprobar que el documento XML está “bien formado” y es “válido”n ¡ Los parsers ya están hechos ! (SAX y DOM)n Esto no significa que no haya que programar nada ...

XML (y 3)

n Existen implementaciones de parsers XML para los lenguajes más usuales (ej.: Java, C++, ..)

n JAXP (Java APIs for XML Processing)n Permite procesamiento de documentos XML mediante

parsers SAX y DOMn Formará parte de J2SE 1.4

n También está disponible para versiones anteriores (vía fichero .jar)

n Familia de paquetes javax.xml y paquete org.w3c.dom

Servlets y páginas JSP

n Servlets y páginas JSP (Java Server Pages)n Tecnologías para construir la capa vista de aplicaciones web

n Permiten recibir peticiones (normalmente HTTP) y devolver una respuesta (normalmente HTML o WML)

n Forma parte de J2EEn Familia de paquetes javax.servlet y javax.servlet.jsp

EJB

n EJB (Enterprise JavaBean)n Son componentes distribuidos que encapsulan el modelo

(lógica de negocio)

n Los métodos de un EJBn Se pueden invocar remotamenten Pueden ser transaccionalesn Pueden tener restricciones de seguridad

n Soportan la construcción de aplicaciones transaccionales, seguras y escalables en 3 capas

n Facilidad de desarrollon Normalmente, el programador no necesita usar ningún API

para manejar transacciones y seguridad (simplemente necesita especificarlo en un fichero de configuración)

Arquitectura multi-capa de una aplicación J2EE (1)

ContenedorEJB

J2EE

HTTPSSL

RMI-IIOP

ContenedorEJB

J2EE

Browser

Applet

ContenedorWeb

J2EE

Servlets

ContenedorEJB

J2EE

EJBs

Capa cliente Capa Web Capa EJB Capa de informaciónempresarial

Base de datos

JSPs

Aplicación

Arquitectura multi-capa de una aplicación J2EE (y 2)

n Algunos comentarios acerca la arquitectura multi-capan El contenedor (servidor de aplicaciones) web y EJB puede

ser el mismon No siempre es necesario/posible usar todos los componentes

(ej.: EJB)n Aprenderemos a desarrollar con menos y más infraestructura

n Los applets no están teniendo mucho éxiton Aplicaciones cliente stand-alone (no web)

n Si están escritas en Java, normalmente acceden a EJB (caso de usarse) directamente

n En otro caso (ej.: Delphi), pueden acceder vía un servlet (simplemente es invocar una URL y leer su respuesta), o idealmente vía CORBA

Implementaciones de J2EE (1)

n Existen un gran número de fabricantes que venden servidores de aplicaciones certificados J2EEn Lista completa en

http://java.sun.com/j2ee/compatibility.htmln Algunos ejemplos

n BEA WebLogic Server: http://www.bea.comn Inprise/Borland AppServer: http://www.inprise.comn IBM WebSphere ApplicationServer:

http://www.ibm.com/software/webserversn IONA iPortal Application Server: http://www.iona.comn iPlanet Application Server: http://www.iplanet.comn Macromedia JRun Server: http://www.allaire.comn Oracle Application Server: http://www.oracle.comn Sun Java 2 SDK Enterprise Edition:

http://java.sun.com/j2ee/j2sdkeen ¡ Es la implementación de referencia y no es eficiente !n De utilidad para los fabricantes de servidores J2EEn Bueno para aprender J2EE y/o las últimas versiones de las APIs

Implementaciones de J2EE (y 2)

n Implementaciones parciales gratuitas y OpenSourcen JSP y servlets

n Tomcat (subproyecto de Jarka): http://jakarta.apache.org/tomcat

n EJB (y APIs relacionadas)n JBoss: http://www.jboss.orgn Evidan JOnAS: http://www.evidian.com/jonas

n Portabilidadn Si nuestra aplicación sólo usa las APIs estándar => podemos

instalarla sobre cualquier servidor de aplicaciones conforme a J2EE

n ¡ No dependemos de un fabricante !

.NET: La alternativa a J2EEn .NET (http://www.microsoft.com/net)n Alternativa de Microsoft a J2EE, y similar a él en concepton Define un Common Language Runtime (CLR) y un IL (Intermediate

Language) al que todos los lenguajes conformes a .NET compilann Idea similar a la máquina virtual de Java y a los bytecodes generados por el

compilador de Java, respectivamenten El Visual Studio .NET ofrecerá “managed Visual C++”, VB.NET, C# y

JScript, y generará código a IL conforme al CLRn Otros fabricantes de compiladores de otros lenguajes pueden hacer lo

mismon Una aplicación puede usar componentes .NET de distintos lenguajes

n Proporciona, entre otros, ADO.NET, ASP.NET y COM+n Similares en concepto a JDBC, JSP y EJB, respectivamenten Son una mejora de sus versiones anteriores (ADO, ASP, etc.)n Por supuesto, XML es una parte integral de .NET

n Desventajasn Está en versión beta (J2EE lleva ya algunos años funcionando)n Aunque podría extenderse a otras plataformas, seguramente será sólo una

realidad en los sistemas operativos de Microsoft (J2EE es una solución Java, y en consecuencia hay implementaciones para los sistemas operativos más usuales)

Alternativas parciales a J2EE (2)

n CORBA y los servicios CORBA (http://www.omg.org)n CORBA: Permite invocación remota de métodos de objetos,

sin que importe el lenguaje y plataforma en el que están escritos cliente y servidor

n Servicios CORBA: nombrado, seguridad, transacciones, etc.n No es una tecnología rival de J2EE, de hecho, los

servidores de EJB usan CORBA transparentemente al desarrollador de EJBsn Un cliente CORBA puede invocar los métodos de un

componentes EJBn Las implementaciones de muchos servidores J2EE hacen uso

de los servicios CORBAn Dentro de poco (quizás un año) se estandarizarán los

Componentes CORBA (CCM: CORBA Component Model)n Son muy similares a los componentes EJB e interoperables con

estosn Como todo en CORBA, estarán disponibles no sólo para Java,

sino para muchos otros lenguajes (ej.: C++)

Alternativas parciales a J2EE (y 2)

n PHP (http://www.php.net)n Proyecto de Apache (http://www.apache.org)n Es una alternativa a JSPn Lenguaje script para procesar peticiones HTTP y generar

respuestas (HTML)n Tiene soporte para generación de imágenes, PDFs, acceso a

a ficheros, bases de datos, etc.n Puede ser una solución aceptable para aplicaciones

relativamente sencillas que se tienen que desarrollar rápidamente con un equipo de personas con pocos conocimientos técnicosn Aplicaciones más complejas requieren mejores tecnologías (ej.:

J2EE)

Patrones arquitectónicos Model-View-Controller y Layers (1)

n Hasta ahora hemos hablado de tecnologías, pero ¿ cómo se debe diseñar una aplicación empresarial para que sea mantenible y contenga partes reusables ?n Debería estar diseñadas siguiendo la arquitectura que fijan

los patrones arquitectónicos Model-View-Controller (MVC) y Layersn F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal,

Pattern-Oriented Software Architecture: A System Of Patterns, John Wiley and Sons, 1996.

n Un patrón arquitectónico es un patrón de alto nivel que fija la arquitectura global de una aplicación

n Posteriormente, el diseño hará uso de patrones de diseño para resolver problemas específicos

Patrones arquitectónicos Model-View-Controller y Layers (2)

n Patrón arquitectónico MVCn Separación clara entre el modelo (lógica de negocio) y la vista

(interfaz gráfica), gracias a un controlador que los mantiene desacoplados

n Ventajas: n El modelo es reusable con distintas vistas (ej.: una vista web y una con

interfaz de ventanas)n División clara de trabajo entre los miembros de un equipo, que estará

formado por personas con distintos niveles de especialización

n Patrón arquitectónico Layersn El software está estructurado en capasn Permite ocultar las tecnologías que usa nuestro software

n Cuando hay un cambio de versión en una de ellas (o incluso se reemplaza por otra distinta), no tiene impacto sobre las capas superiores

n División clara de trabajo entre los miembros de un equipon Dará soporte a la arquitectura MVC

n Ej.: tanto la vista como el controlador nunca conocerán las tecnologías que usa la implementación del modelo

Patrones arquitectónicos Model-View-Controller y Layers (y 3)

n En esta asignatura nos concentraremos en J2EE y aprenderemos a diseñar aplicaciones empresariales conn Arquitectura {MVC + Layers} + múltiples patrones de diseño

n Fuentesn J2EE BluePrintsn Sun Java Center J2EEn The ServerSide.com

n La descripción de los anteriores patrones usa EJB, sin embargo gran parte de ellos son aplicables cuando no se usa EJB

n Dos grandes ejemplos: MiniBank y MiniPortal, n Iremos viendo el diseño del modelo, vista y controlador a

medida que avancemosn Ambos ejemplos pueden funcionar con y sin EJB (la capa de

acceso al modelo es “pluggable”)