Tema 1: Introducción a J2EE

Transcripción

1 Tema 1: Introducción a J2EE

2 Índice 1.1 Características de las aplicaciones empresariales 1.2 Visión general de la plataforma J2EE 1.3 Patrones arquitectónicos Model-View-Controller y Layers

3 Características de las aplicaciones empresariales (1) Acceso a bases de datos (BD) Normalmente con BD relacionales Transaccionales Propiedades ACID (Atomicity-Consistency-Isolation- Durability) Escalables Deberían poder soportar más carga de trabajo sin necesidad de modificar el software (sólo añadir más máquinas) Seguras No todos los usuarios pueden acceder a la misma funcionalidad Tipo de interfaz De entorno de ventanas: normalmente sólo tiene sentido en intranets Web: en intranets, y desde luego en Internet

4 Características de las aplicaciones empresariales (y 2) Separación clara entre vista y modelo Vista: aspecto gráfico Modelo: encapsula la lógica de negocio Ejemplo => aplicación bancaria Modelo: conjunto de clases que nos permiten: crear cuentas, destruirlas, encontrarlas por distintos criterios, hacer transferencias bancarias, etc. Vista: el interfaz gráfico que permite a los empleados del banco realizar las anteriores operaciones El modelo debería ser reusable con distintas vistas 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 Arquitecturas multi-capa Vamos a ver los ejemplos más usuales...

5 Ejemplo: Una aplicación bancaria en dos capas Capa 1 Capa 2 Vista ap. Modelo Aplicación Intranet Base de datos Vista ap. Modelo Vista ap. Modelo Aplicación Aplicación

6 Ejemplo : Una aplicación bancaria en dos capas - Problemas Problemas de modificación de la versión del modelo Cambios de drivers de acceso a la BD Cambios de esquemas Cambio de tipo de BD Cambios en la lógica del modelo No optimiza las conexiones a la BD No es posible tener un pool de conexiones global No optimiza los accesos a la red 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)

7 Ejemplo: Una aplicación bancaria en tres capas Capa 1 Capa 2 Capa 3 Vista ap. Modelo Vista ap. Intranet Base de datos Vista ap.

8 Ejemplo: Una aplicación Internet típica en dos capas Capa 1 Capa 2 Navegador Vista web Modelo Navegador Internet Navegador Servidor aplicaciones web Base de datos

9 Ejemplo: Una aplicación Internet típica en dos capas - Problemas Problema 1 Nuestra aplicación web tiene éxito (es decir, muchos accesos) La solución no es escalable Problema 2 Y si queremos tener otra vista, por ejemplo, una aplicación de administración con interfaz gráfico de ventanas (dentro de la intranet)? Problemas de actualización de la versión del modelo

10 Ejemplo: Una aplicación Internet típica en dos capas Una primera solución al problema 1 Capa 1 Capa 2 Navegador Vista web Modelo Navegador Internet Navegador Servidor aplicaciones web Base de datos

11 Ejemplo: Una aplicación Internet típica en tres capas Máxima escalabilidad (problema 1) y solución al problema 2 Navegador Capa 1 Capa 2 Capa 3 Vista web Modelo Navegador Internet Navegador Base de datos Vista aplicación admin.

12 Conclusiones sobre arquitecturas multi-capa Arquitectura en dos capas En general, mala arquitectura cuando hay clientes con interfaz de entorno de ventanas En muchos casos es una solución perfectamente válida para aplicaciones con interfaz web 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 la capa web) Arquitectura en tres capas Buena arquitectura para aplicaciones con interfaz de entorno de ventanas Con replicación en las tres capas => máxima escalabilidad y tolerancia a fallos para aplicaciones de Internet e intranets

13 Un comentario acerca de las interfaces gráficas Aplicaciones cliente con interfaces gráficas de entorno de ventanas 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 Aplicaciones con interfaz web Las máquinas cliente sólo necesitan un navegador Las modificaciones al interfaz se realizan en el lado servidor => facilidad de administración No es sólo una solución para Internet, sino también para las aplicaciones de una intranet (que se benefician de lo anterior)

14 Visión general de la plataforma J2EE J2SE (Java 2 Platform Standard Edition) Conjunto de especificaciones: lenguaje, máquina virtual, paquetes básicos (java.util, java.io, java.sql, etc.) Sun realiza las especificaciones, pero existen implementaciones de múltiples fabricantes J2EE (Java 2 Platform Enterprise Edition) Conjunto de especificaciones de APIs para facilitar la construcción de aplicaciones empresariales (se apoya en J2SE) Todas las APIs se corresponden con paquetes javax.* (ej.: javax.servlet, javax.jsp, javax.ejb, etc.) javax significa Java extension Casi todos las abstracciones proporcionadas por los paquetes son interfaces Existen algunos javax en J2SE (ej.: javax.swing, javax.naming, etc.), y cada vez se incorporan más Sun realiza las especificaciones, pero existen implementaciones de múltiples fabricantes

15 Principales APIs que usaremos Entre otras, usaremos las siguientes APIs JDBC JAXP Servles y páginas JSP Enterprise JavaBeans

16 JDBC JDBC => Java DataBase Connectivity Permite acceder a bases de datos relacionales El programador puede lanzar queries (consulta, actualización, inserción y borrado), agrupar queries en transacciones, etc. Lo proporciona J2SE (paquete java.sql) 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

17 XML (extensible Markup Language) XML (1) Lenguaje de tags (similar en sintaxis a HTML) Estandarizado por Es extensible: 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.) Permite escribir documentos de texto que expresan datos y no aspecto visual (a diferencia de HTML) Un campo de aplicación típico es el intercambio de datos entre aplicaciones u organizaciones heterogéneas, manteniéndolas desacopladas. Ejemplo: Queremos realizar una aplicación web que muestra las previsiones meteorológicas para un conjunto de ciudades en los próximos días Contratamos a una empresa de contenidos que nos pase las previsiones (ej.: el Instituto Nacional de Meteorología). 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 Parseamos el fichero e insertamos los datos en nuestra base de datos Nuestra aplicación web lee los datos de la base de datos

18 XML (2) 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> El pequeño conjunto de normas que define XML y la posibilidad de definir 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 Los parsers ya están hechos! (SAX y DOM) Esto no significa que no haya que programar nada...

19 XML (y 3) Existen implementaciones de parsers XML para los lenguajes más usuales (ej.: Java, C++,..) JAXP (Java APIs for XML Processing) Permite procesamiento de documentos XML mediante parsers SAX y DOM Formará parte de J2SE 1.4 También está disponible para versiones anteriores (vía fichero.jar) Familia de paquetes javax.xml y paquete org.w3c.dom

20 Servlets y páginas JSP Servlets y páginas JSP (Java Server Pages) Tecnologías para construir la capa vista de aplicaciones web Permiten recibir peticiones (normalmente HTTP) y devolver una respuesta (normalmente HTML o WML) Forma parte de J2EE Familia de paquetes javax.servlet y javax.servlet.jsp

21 EJB EJB (Enterprise JavaBean) Son componentes distribuidos que encapsulan el modelo (lógica de negocio) Los métodos de un EJB Se pueden invocar remotamente Pueden ser transaccionales Pueden tener restricciones de seguridad Soportan la construcción de aplicaciones transaccionales, seguras y escalables en 3 capas Facilidad de desarrollo Normalmente, el programador no necesita usar ningún API para manejar transacciones y seguridad (simplemente necesita especificarlo en un fichero de configuración)

22 Arquitectura multi-capa de una aplicación J2EE (1) Capa cliente Capa Web Capa EJB Capa de información empresarial Browser HTTP SSL Contenedor Web Contenedor Contenedor Contenedor EJB EJB Applet JSPs Servlets EJBs J2EE J2EE Aplicación J2EE J2EE Base de datos RMI-IIOP

23 Arquitectura multi-capa de una aplicación J2EE (y 2) Algunos comentarios acerca la arquitectura multicapa El contenedor (servidor de aplicaciones) web y EJB puede ser el mismo No siempre es necesario/posible usar todos los componentes (ej.: EJB) Aprenderemos a desarrollar con menos y más infraestructura Los applets no están teniendo mucho éxito Aplicaciones cliente stand-alone (no web) Si están escritas en Java, normalmente acceden a EJB (caso de usarse) directamente 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

24 Implementaciones de J2EE (1) Existen un gran número de fabricantes que venden servidores de aplicaciones certificados J2EE Lista completa en Algunos ejemplos BEA WebLogic Server: Inprise/Borland AppServer: IBM WebSphere ApplicationServer: IONA iportal Application Server: iplanet Application Server: Macromedia JRun Server: Oracle Application Server: Sun Java 2 SDK Enterprise Edition: Es la implementación de referencia y no es eficiente! De utilidad para los fabricantes de servidores J2EE Bueno para aprender J2EE y/o las últimas versiones de las APIs

25 Implementaciones de J2EE (y 2) Implementaciones parciales gratuitas y OpenSource JSP y servlets Tomcat (subproyecto de Jarka): EJB (y APIs relacionadas) JBoss: Evidan JOnAS: Portabilidad Si nuestra aplicación sólo usa las APIs estándar => podemos instalarla sobre cualquier servidor de aplicaciones conforme a J2EE No dependemos de un fabricante!

26 .NET: La alternativa a J2EE.NET ( Alternativa de Microsoft a J2EE, y similar a él en concepto Define un Common Language Runtime (CLR) y un IL (Intermediate Language) al que todos los lenguajes conformes a.net compilan Idea similar a la máquina virtual de Java y a los bytecodes generados por el compilador de Java, respectivamente El Visual Studio.NET ofrecerá managed Visual C++, VB.NET, C# y JScript, y generará código a IL conforme al CLR Otros fabricantes de compiladores de otros lenguajes pueden hacer lo mismo Una aplicación puede usar componentes.net de distintos lenguajes Proporciona, entre otros, ADO.NET, ASP.NET y COM+ Similares en concepto a JDBC, JSP y EJB, respectivamente Son una mejora de sus versiones anteriores (ADO, ASP, etc.) Por supuesto, XML es una parte integral de.net Desventajas Está en versión beta (J2EE lleva ya algunos años funcionando) 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)

27 Alternativas parciales a J2EE (2) CORBA y los servicios CORBA ( 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 Servicios CORBA: nombrado, seguridad, transacciones, etc. No es una tecnología rival de J2EE, de hecho, los servidores de EJB usan CORBA transparentemente al desarrollador de EJBs Un cliente CORBA puede invocar los métodos de un componentes EJB Las implementaciones de muchos servidores J2EE hacen uso de los servicios CORBA Dentro de poco (quizás un año) se estandarizarán los Componentes CORBA (CCM: CORBA Component Model) Son muy similares a los componentes EJB e interoperables con estos Como todo en CORBA, estarán disponibles no sólo para Java, sino para muchos otros lenguajes (ej.: C++)

28 Alternativas parciales a J2EE (y 2) PHP ( Proyecto de Apache ( Es una alternativa a JSP Lenguaje script para procesar peticiones HTTP y generar respuestas (HTML) Tiene soporte para generación de imágenes, PDFs, acceso a a ficheros, bases de datos, etc. 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écnicos Aplicaciones más complejas requieren mejores tecnologías (ej.: J2EE)

29 Patrones arquitectónicos Model-View-Controller y Layers (1) 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? Debería estar diseñadas siguiendo la arquitectura que fijan los patrones arquitectónicos Model-View-Controller (MVC) y Layers F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal, Pattern-Oriented Software Architecture: A System Of Patterns, John Wiley and Sons, Un patrón arquitectónico es un patrón de alto nivel que fija la arquitectura global de una aplicación Posteriormente, el diseño hará uso de patrones de diseño para resolver problemas específicos

30 Patrones arquitectónicos Model-View-Controller y Layers (2) Patrón arquitectónico MVC Separación clara entre el modelo (lógica de negocio) y la vista (interfaz gráfica), gracias a un controlador que los mantiene desacoplados Ventajas: El modelo es reusable con distintas vistas (ej.: una vista web y una con interfaz de ventanas) División clara de trabajo entre los miembros de un equipo, que estará formado por personas con distintos niveles de especialización Patrón arquitectónico Layers El software está estructurado en capas Permite ocultar las tecnologías que usa nuestro software 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 División clara de trabajo entre los miembros de un equipo Dará soporte a la arquitectura MVC Ej.: tanto la vista como el controlador nunca conocerán las tecnologías que usa la implementación del modelo

31 Patrones arquitectónicos Model-View-Controller y Layers (y 3) En esta asignatura nos concentraremos en J2EE y aprenderemos a diseñar aplicaciones empresariales con Arquitectura {MVC + Layers} + múltiples patrones de diseño Fuentes J2EE BluePrints Sun Java Center J2EE The ServerSide.com La descripción de los anteriores patrones usa EJB, sin embargo gran parte de ellos son aplicables cuando no se usa EJB Dos grandes ejemplos: MiniBank y MiniPortal, Iremos viendo el diseño del modelo, vista y controlador a medida que avancemos Ambos ejemplos pueden funcionar con y sin EJB (la capa de acceso al modelo es pluggable )