tema 1: introducción a las tecnologías java · arquitectura en dos capas (1) intranet int....
TRANSCRIPT
Índice
Características de las aplicaciones empresariales
Tecnologías Java
Alternativas a las tecnologías Java
XML
Material de clase
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
Características de las aplicaciones empresariales (2)
Tipo de interfaz
De entorno de ventanas (clientes de escritorio)
Normalmente sólo tiene sentido en intranets
Web
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
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
Una aplicación con clientes de escritorioArquitectura en dos capas (1)
Intranet
Int.gráfica
Modelo
Capa 1 Capa 2
Int.gráfica
ModeloInt.
gráficaModelo
Base de datos
Una aplicación con clientes de escritorioArquitectura 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
Cambios de librería de acceso a la BD
Cambios en la lógica del modelo
Solución
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
Una aplicación con clientes de escritorioArquitectura en tres capas (1)
Intranet
Capa 2 Capa 3Capa 1
Int.gráfica
Int.gráfica
Int.gráfica
Modelo
Serv. modelo
Base de datos
Una aplicación con clientes de escritorioArquitectura 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
Una aplicación WebArquitectura en tres capas (1)
Internet/Itranet
Capa 2 Capa 3
NavegadorInt.Web
Modelo
Navegador
Capa 1
Navegador
Base de datos
Serv. ap. Web
Una aplicación WebArquitectura 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
Una aplicación WebArquitectura en cuatro capas (1)
Internet/Intranet
Capa 2 Capa 3 Capa 4
Int.Web
Modelo
Navegador
Navegador
Capa 1
Base de datos
Serv. ap. Web Serv. modelo
Navegador
Una aplicación WebArquitectura 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
Tecnologías estándares Java
Sun, con la ayuda de otros fabricantes (IBM, Oracle, etc.), estandarizaun 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 http://java.sun.com/javase
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 http://java.sun.com/javame
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 http://java.sun.com/javaee
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
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
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)
BD
Aplicación Web (int. gráf.
+ modelo )
Servidor de Aplicaciones
Navegador
JDBC
Servlets
JSP JSTL JSF
Implementaciones de Java EE
Existen un gran número de fabricantes que venden servidores de aplicaciones certificados Java EE
Lista completa en http://java.sun.com/javaee/overview/compatibility.jsp
Algunos ejemplos
IBM WebSphere Application Server: http://www.ibm.com
Oracle Application Server: http://www.oracle.com
Implementaciones de Java EE (y 2)
Implementaciones Open Source Jetty: http://www.mortbay.org/jetty
Servidor de aplicaciones Web con soporte sólo para Servlets y JSP
Tomcat: http://tomcat.apache.org Servidor de aplicaciones Web con soporte sólo para Servlets y JSP
JBoss Application Server: http://www.jboss.org Servidor de aplicaciones con soporte completo para Java EE
GlassFish: https://glassfish.dev.java.net Servidor de aplicaciones con soporte completo para Java EE
Geronimo: http://geronimo.apache.org 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!
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
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
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
Frameworks POJO Open Source para capa modelo
Hibernate e iBatis
http://www.hibernate.org
http://ibatis.apache.org
Mapeadores objeto-relacional
Internamente utilizan JDBC
Nosotros utilizaremos Hibernate
Implementa JPA, pero también dispone de su API propia (que permite tratar aspectos que no cubre JPA)
Spring
http://www.springframework.org
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
Frameworks POJO para interfaz Web (1)
Orientados a acción
Enfoque: procesar cada petición HTTP individualmente
Struts
http://struts.apache.org
Spring
Orientados a componentes
Enfoque: modelar cada página Web como un componente que puede reaccionar a diversos eventos
Tapestry
http://tapestry.apache.org
Wicket
http://wicket.apache.org
Seam
http://seamframework.org
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
Nuestro entorno de desarrollo (1)
Servidor de aplicaciones
NavegadorBD
Servlets
Cualquier SO con soporte para Java(e.g. Windows, Linux, Mac, Solaris, etc.)
Tapestry
JDBC
HibernateSpring
Interfaz Web
Capamodelo
Aplicación Web
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 (http://mysql.com)
Es posible utilizar cualquier otra BD soportada por Hibernate
Nuestro entorno de desarrollo (y 3)
Además, usaremos
Maven
http://maven.apache.org
Para automatizar la construcción del software (inclusive la ejecución de pruebas de integración de la capa modelo)
Subversion
http://subversion.tigris.org
Repositorio de control de versiones
Eclipse
http://www.eclipse.org
Es posible utilizar otro IDE
Ubuntu en el laboratorio
Es posible utilizar cualquier otro sistema operativo con soporte para Java
Alternativas a las tecnologías Java (1)
.NET
http://www.microsoft.com/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
Alternativas a las tecnologías Java (y 2)
LAMP http://www.onlamp.com
Linux + Apache + MySQL + Perl/PHP/Python
Ruby on Rails http://www.rubyonrails.org
Framework Web para el lenguaje Ruby (http://www.ruby-lang.org)
XML (1) ¿Qué es XML?
XML (eXtensible Markup Language) Lenguaje de tags (similar en sintaxis a HTML)
Estandarizado por el W3C (http://www.w3.org)
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">
<forecast type="sunny" day="1" month="10" year="2008"/>
<forecast type="foggy" day="2" month="10" year="2008"/>
</city>
<city name="LUG">
<forecast type="rainy" day="1" month="10" year="2008"/>
<forecast type="rainy" day="2" month="10" year="2008"/>
</city>
...
</forecasts>
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
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
Aplicación Web Java Aplicación Web .NET
Petición HTTP
Respuesta HTTPcon los datos en XML
Material de clase
Página Web de la asignatura
http://www.tic.udc.es/is-java
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