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

Tema 1: Introducción a las
Tecnologías Java
Í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)


Transaccionales


Idealmente no deben dejar de prestar servicio
Seguras


Deberían poder soportar más carga de trabajo sin necesidad de
modificar el software (sólo añadir más máquinas)
Disponibilidad


Propiedades ACID (Atomicity-Consistency-Isolation-Durability)
Escalables


Normalmente con BBDD relacionales
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



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



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
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 escritorio
Arquitectura en dos capas (1)
Capa 1
Capa 2
Base de
datos
Int.
Modelo
gráfica
Intranet
Int.
Modelo
gráfica
Int.
Modelo
gráfica
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



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 escritorio
Arquitectura en tres capas (1)
Capa 1
Int.
gráfica
Capa 2
Modelo
Serv. modelo
Int.
gráfica
Intranet
Int.
gráfica
Capa 3
Base de
datos
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
Una aplicación Web
Arquitectura en tres capas (1)
Capa 1
Navegador
Capa 2
Int.
Modelo
Web
Serv. ap. Web
Navegador
Navegador
Internet/
Itranet
Capa 3
Base de
datos
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



Escalabilidad


Recibe todas las peticiones HTTP
Envía cada petición HTTP a uno de los servidores de aplicaciones
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 Web
Arquitectura en cuatro capas (1)
Capa 1
Capa 2
Capa 3
Capa 4
Navegador
Int.
Web
Serv. ap. Web
Navegador
Navegador
Internet/
Intranet
Modelo
Serv. modelo
Base de
datos
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
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




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)




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
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




Las implementaciones de JPA internamente utilizan JDBC


El uso de JDBC es transparente al desarrollador
Session Beans




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)
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)
Servidor de
Aplicaciones
Navegador
Aplicación
Web (int. gráf.
+ modelo )
JSP
JSTL
Servlets
JDBC
BD
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


Tomcat: http://tomcat.apache.org


Servidor de aplicaciones con soporte completo para Java EE
Geronimo: http://geronimo.apache.org


Servidor de aplicaciones con soporte completo para Java EE
GlassFish: https://glassfish.dev.java.net


Servidor de aplicaciones Web con soporte sólo para Servlets y JSP
JBoss Application Server: http://www.jboss.org


Servidor de aplicaciones Web con soporte sólo para Servlets y JSP
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


Wicket


http://tapestry.apache.org
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
Aplicación Web
Navegador
Interfaz
Web
Tapestry
Servlets
Capa
modelo
Spring
Hibernate
JDBC
Cualquier SO con soporte para Java
(e.g. Windows, Linux, Mac, Solaris, etc.)
BD
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



Subversion



http://subversion.tigris.org
Repositorio de control de versiones
Eclipse



http://maven.apache.org
Para automatizar la construcción del software (inclusive la
ejecución de pruebas de integración de la capa modelo)
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


Lenguajes


Idea similar a la máquina virtual de Java y a los bytecodes generados
por el compilador de Java, respectivamente
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.rubylang.org)
XML (1)

¿Qué es XML?

XML (eXtensible Markup Language)



Es extensible:



Lenguaje de tags (similar en sintaxis a HTML)
Estandarizado por el W3C (http://www.w3.org)
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"
<forecast type="foggy"
</city>
<city name="LUG">
<forecast type="rainy"
<forecast type="rainy"
</city>
...
</forecasts>
day="1" month="10" year="2008"/>
day="2" month="10" year="2008"/>
day="1" month="10" year="2008"/>
day="2" month="10" year="2008"/>
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

Aplicación Web .NET
Configuración de aplicaciones


Respuesta HTTP
con los datos en XML
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
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