Tema 1: Introducción a las Tecnologías Java

Transcripción

1 Tema 1: Introducción a las Tecnologías Java

2 Índice Características de las aplicaciones empresariales Tecnologías Java Alternativas a las tecnologías Java XML Material de clase

3 Características de las aplicaciones empresariales (1) Acceso a bases de datos (BBDD) Normalmente con BBDD 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) Disponibilidad Idealmente no deben dejar de prestar servicio Seguras No todos los usuarios pueden acceder a la misma funcionalidad Integración Es preciso integrar aplicaciones construidas con distintas tecnologías

4 Características de las aplicaciones empresariales (2) Tipo de interfaz De entorno de ventanas (clientes de escritorio) Web Normalmente sólo tiene sentido en intranets En Internet y en intranets Suele ser la opción preferida, dado que no es preciso instalar nada en las máquinas cliente (basta que tengan un navegador) => facilitad de instalación y mantenimiento La interfaz no es tan interactiva como la de las aplicaciones de escritorio

5 Características de las aplicaciones empresariales (y 3) Separación clara entre las capas interfaz gráfica y modelo Capa modelo Conjunto de clases que implementan la lógica de negocio de los casos de uso de la aplicación, normalmente utilizando una BD Independiente de la interfaz gráfica Ejemplo => aplicación bancaria Capa modelo: conjunto de clases que implementan los casos de uso (e.g. crear cuentas, destruirlas, encontrarlas por distintos criterios, etc.) contra la BD Ventajas potenciales de la separación Cada capa puede ser desarrollada por una persona con un perfil distinto Es posible reusar la capa modelo en distintas interfaces gráficas Arquitecturas multi-capa Siguientes transparencias

6 Una aplicación con clientes de escritorio Arquitectura en dos capas (1) Capa 1 Capa 2 Int. gráfica Modelo Base de datos Intranet Int. gráfica Modelo Int. gráfica Modelo

7 Una aplicación con clientes de escritorio Arquitectura en dos capas (y 2) Problema Cambios en la implementación de la capa modelo => recompilación de toda la aplicación y reinstalación en máquinas cliente Solución Cambios de librería de acceso a la BD Cambios en la lógica del modelo Modelo en servidor intermedio Un cambio en la implementación del modelo sólo afecta al servidor Clientes de escritorio Sólo disponen de la interfaz gráfica Acceden al servidor que implementa el modelo

8 Una aplicación con clientes de escritorio Arquitectura en tres capas (1) Capa 1 Capa 2 Capa 3 Int. gráfica Modelo Serv. modelo Base de datos Int. gráfica Intranet Int. gráfica

9 Una aplicación con clientes de escritorio Arquitectura en tres capas (y 2) Problema Cambios en la implementación de la interfaz gráfica => recompilación de la aplicación cliente y reinstalación en máquinas cliente Por este motivo, cuando es posible, es preferible decantarse por una interfaz Web

10 Una aplicación Web Arquitectura en tres capas (1) Capa 1 Capa 2 Capa 3 Navegador Int. Web Modelo Base de datos Serv. ap. Web Navegador Internet/ Itranet Navegador

11 Una aplicación Web Arquitectura en tres capas (y 2) Las aplicaciones Web se instalan en servidores de aplicaciones Cambios en la interfaz gráfica o en la capa modelo, sólo requieren reinstalar la aplicación en el servidor de aplicaciones Los servidores de aplicaciones suelen tener soporte para escalabilidad y disponibilidad Se pueden replicar en varias máquinas ( pool de máquinas ) Se emplea un balanceador de carga Recibe todas las peticiones HTTP Envía cada petición HTTP a uno de los servidores de aplicaciones Escalabilidad Para atender más peticiones => hay que añadir más máquinas al pool Disponibilidad Si una máquina se cae, todavía quedan otras instancias del servidor de aplicaciones en el pool

12 Una aplicación Web Arquitectura en cuatro capas (1) Navegador Capa 1 Capa 2 Capa 3 Capa 4 Int. Web Serv. ap. Web Modelo Serv. modelo Base de datos Navegador Internet/ Intranet Navegador

13 Una aplicación Web Arquitectura en cuatro capas (y 2) Esta arquitectura es muy útil cuando la interfaz gráfica y la capa modelo están construidas con tecnologías diferentes Ejemplo Existe una capa modelo desarrollada en COBOL La capa modelo es grande, funciona correctamente, lleva muchos años funcionando y manteniéndose Se desea construir una aplicación Web para poder invocar casos de uso de la capa modelo desde un navegador Se elige una tecnología moderna para implementar la interfaz Web fácilmente (e.g. Java) No es viable volver a construir la capa modelo en la misma tecnología que la usada en la interfaz Web (tiempo, coste, razones tecnológicas, etc.) Solución: invocar los casos de uso de la capa modelo remotamente (e.g. sockets) desde la interfaz gráfica

14 Tecnologías estándares Java Sun, con la ayuda de otros fabricantes (IBM, Oracle, etc.), estandariza un conjunto de APIs para el desarrollo de aplicaciones Java La mayor parte de las abstracciones de las APIs corresponden a interfaces y clases abstractas Existen múltiples implementaciones de distintos fabricantes, incluso muchas Open Source Una aplicación construida con estas APIs no depende de una implementación particular Java SE (Java Platform, Standard Edition) API básica + herramientas básicas (máquina virtual, compilador, etc.) Anteriormente conocida como J2SE Java ME (Java Platform, Micro Edition) API análoga a Java SE para móviles y otros dispositivos (PDAs, TV set-top boxes, etc.) Anteriormente conocida como J2ME Java EE (Java Platform, Enterprise Edition) Se apoya en Java SE y dispone de APIs para la construcción de aplicaciones empresariales (inclusive aplicaciones Web) Anteriormente conocida como J2EE

15 Acceso a BBDD en Java SE Ámbito: capa modelo API: JDBC (Java DataBase Connectivity) Posibilita el acceso a bases de datos relacionales El programador puede lanzar consultas (lectura, actualización, inserción y borrado), agrupar consultas en transacciones, etc. Estudiaremos sus principios básicos en el apartado 3.1

16 Tecnologías capa modelo en Java EE EJB (Enterprise Java Beans) JPA (Java Persistence API) API estándar para un mapeador objeto-relacional Java Mapeo automático de clases persistentes (llamadas entidades ) a una BD relacional Ejemplo: aplicación bancaria que maneje cuentas y operaciones bancarias Existen dos clases persistentes: Account y AccountOperation Las instancias se mapean automáticamente a filas de las tablas correspondientes (una tabla por cada entidad) Las implementaciones de JPA internamente utilizan JDBC El uso de JDBC es transparente al desarrollador Session Beans Permiten implementar los casos de uso Pueden tener interfaz local y/o remota Permiten especificar declarativamente las políticas de transacciones y seguridad Es posible utilizar JPA al margen del resto de EJB

17 Tecnologías interfaz Web en Java EE API básica: Servlets APIs que funcionan por encima de la API de servlets: JSP (JavaServer Pages) JSTL (JSP Standard Tag Library) JSF (JavaServer Faces) Servidor de Aplicaciones Navegador Aplicación Web (int. gráf. + modelo ) JDBC BD JSP JSTL JSF Servlets

18 Implementaciones de Java EE Existen un gran número de fabricantes que venden servidores de aplicaciones certificados Java EE Lista completa en Algunos ejemplos IBM WebSphere Application Server: Oracle Application Server:

19 Implementaciones de Java EE (y 2) Implementaciones Open Source Jetty: Servidor de aplicaciones Web con soporte sólo para Servlets y JSP Tomcat: Servidor de aplicaciones Web con soporte sólo para Servlets y JSP JBoss Application Server: Servidor de aplicaciones con soporte completo para Java EE GlassFish: Servidor de aplicaciones con soporte completo para Java EE Geronimo: Servidor de aplicaciones con soporte completo para Java EE Portabilidad Si una aplicación usa sólo las APIs estándares => es posible instalarla en cualquier servidor de aplicaciones Java EE No se depende de un fabricante!

20 Tecnologías Java POJO (1) Durante los últimos años, algunas de las APIs de Java EE han sido muy criticadas Especialmente las APIs de más alto nivel, y en particular, EJB (capa modelo) y JSF (interfaz Web) Difíciles de usar No siempre representan las mejores ideas sobre cómo hacer las cosas Las APIs estándares no siempre tienen todo lo que el desarrollador necesita Las mejoras tardan en llegar al desarrollador final Las nuevas versiones de las APIs tardan en estandarizarse Y después hay que esperar a que haya implementaciones robustas

21 Tecnologías Java POJO (2) Durante los últimos años han surgido una gran cantidad de frameworks que siguen el enfoque POJO POJO = Plain Old Java Object El término POJO surgió para hacer referencia a clases Java que no tienen que cumplir unas restricciones tan complejas como las que forzaba EJB 1.x y 2.x Ejemplo: un entity bean (clase persistente) en EJB 1.x/2.x Es preciso escribir dos interfaces y una clase de implementación La clase de implementación no implementa las dos interfaces, sino que tiene que proporcionar unos métodos con una firma parecida a los métodos de esas dos interfaces EJB 3 evolucionó hacia el enfoque POJO, aunque quizás demasiado tarde

22 Tecnologías Java POJO (y 3) Idealmente, una clase POJO no tiene que implementar/usar interfaces/anotaciones específicas al framework En realidad, se dice que un framework sigue el enfoque POJO cuando promueve un enfoque sencillo de desarrollo En los frameworks más conformes al paradigma POJO, es habitual usar convenciones de nombrado y/o anotaciones, e implementar interfaces específicas en pocas ocasiones

23 Frameworks POJO Open Source para capa modelo Hibernate e ibatis Mapeadores objeto-relacional Internamente utilizan JDBC Nosotros utilizaremos Hibernate Spring Implementa JPA, pero también dispone de su API propia (que permite tratar aspectos que no cubre JPA) Soporte para capa modelo e interfaz Web Simplifica el uso de muchas de las APIs de Java EE Dispone de alternativas a algunas de las APIs de Java EE Internamente se apoyan en APIs de Java EE de más bajo nivel Nosotros utilizaremos el soporte de Spring para implementar casos de uso Alternativa al uso de los Session Bean de EJB

24 Frameworks POJO para interfaz Web (1) Orientados a acción Enfoque: procesar cada petición HTTP individualmente Struts Spring Orientados a componentes Enfoque: modelar cada página Web como un componente que puede reaccionar a diversos eventos Tapestry Wicket Seam

25 Frameworks POJO para interfaz Web (y 2) Sólo requieren un servidor de aplicaciones Web Java EE ligero (sólo soporte de Servlets y JSP) Nosotros usaremos Tapestry 5.x Internamente sólo se apoya en la API de Servlets

26 Nuestro entorno de desarrollo (1) Servidor de aplicaciones Aplicación Web Navegador Interfaz Web Capa modelo BD Tapestry Spring Hibernate Servlets JDBC Cualquier SO con soporte para Java (e.g. Windows, Linux, Mac, Solaris, etc.)

27 Nuestro entorno de desarrollo (2) Como servidor de aplicaciones utilizaremos Jetty para desarrollo Tomcat para producción Es posible utilizar cualquier otro servidor de aplicaciones Java Como BD utilizaremos MySQL ( Es posible utilizar cualquier otra BD soportada por Hibernate

28 Nuestro entorno de desarrollo (y 3) Además, usaremos Maven Para automatizar la construcción del software (inclusive la ejecución de pruebas de integración de la capa modelo) Subversion Repositorio de control de versiones Eclipse Es posible utilizar otro IDE Ubuntu en el laboratorio Es posible utilizar cualquier otro sistema operativo con soporte para Java

29 Alternativas a las tecnologías Java (1).NET 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 Lenguajes Visual C#.NET, Visual Basic.NET, etc. Tecnologías ADO.NET: para capa modelo ASP.NET: para interfaz Web

30 Alternativas a las tecnologías Java (y 2) LAMP Linux + Apache + MySQL + Perl/PHP/Python Ruby on Rails Framework Web para el lenguaje Ruby (

31 XML (1) Qué es XML? XML (extensible Markup Language) Lenguaje de tags (similar en sintaxis a HTML) Estandarizado por el W3C ( Es extensible: XML no impone un conjunto de tags, sino sólo unas pocas normas sobre cómo usarlos Permite expresar información estructurada y fácilmente parseable Ejemplo: información metereológica <?xml version= 1.0 > <forecasts> <city name="cor"> </city> <forecast type="sunny" day="1" month="10" year="2008"/> <forecast type="foggy" day="2" month="10" year="2008"/> <city name="lug"> </city>... </forecasts> <forecast type="rainy" day="1" month="10" year="2008"/> <forecast type="rainy" day="2" month="10" year="2008"/>

32 XML (y 2) Campos de aplicación que explotaremos Los dos principales Integración de aplicaciones heterogéneas Ejemplo: en la práctica de la asignatura, la aplicación Web.NET accederá a datos de la aplicación Web Java mediante XML sobre HTTP Petición HTTP Aplicación Web Java Respuesta HTTP con los datos en XML Aplicación Web.NET Configuración de aplicaciones La mayor parte de la configuración de los frameworks y herramientas que usaremos está en formato XML Todas las tecnologías modernas disponen de APIs para el tratamiento de XML En la asignatura ADOO se estudian APIs XML-Java, con énfasis especial en la integración de aplicaciones

33 Material de clase Página Web de la asignatura Sitio Web de apoyo a la parte I de la asignatura (tecnologías Java) Transparencias y código con los ejemplos DVD de IS-Java Contiene todo el software (para Linux, Windows y Mac) necesario para realizar la práctica de la parte I de la asignatura