tema 1: introducción a las tecnologías java · arquitectura en dos capas (1) intranet int....

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

Upload: truongdiep

Post on 11-Feb-2019

220 views

Category:

Documents


0 download

TRANSCRIPT

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)

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