Algoritmos y Programación III

9. Aplicaciones distribuidas

Carlos Fontela, 2005

Temario

Aplicaciones distribuidas y J2EE Componentes web

Servlets Páginas JSP

Mensajería con JMS Servicios web con JAX-RPC y JAXR Componentes EJB ¡Todo a nivel introductorio!

Definiciones

Internet Red global TCP/IP

World Wide Web (“la web”) Aplicación s/ Internet (otras: mail, FTP) Protocolo HTTP Páginas vinculadas HTML Multiplataforma No hay mantenimiento de estado entre

llamadas

Computación distribuida

Caso extremo de concurrencia Aplicación corriendo sobre varias

máquinas Mayor complejidad

Comunicaciones Seguridad Recuperación por fallos Plataformas

Evolución

Grandes máquinas aisladas Mainframes

Procesamiento centralizado Terminales bobas

Redes de PCs Procesamiento descentralizado Almacenamiento centralizado

Web, primeros años Primero, como mainframes Luego, aprovechando capacidad de clientes

Hoy: aplicaciones distribuidas

Cambio de paradigma

Aplicaciones distribuidas: Corren en varias máquinas tipo servidores. Esquema cooperativo.

Basadas en Internet: Red global. Conjunto de protocolos. Ancho de banda barato.

Sobre la Web: Multiplataforma. Actualización automática. Interfaz conocida.

Clientes y servidores

Clientes finales Ricos Pobres o Web

Clientes que son servidores Servidores que son clientes

Siempre hay un cliente y un servidor

Elementos (lado del servidor)

Páginas web “estáticas” HTML, multimedia, guiones, applets y otros.

Componentes para páginas web dinámicas Se comunican con componentes de negocio.

Componentes de negocio Dan servicio a componentes web, a otros

componentes de negocio y utilizan componentes de acceso a datos

Componentes de acceso a datos Sistemas de mensajería Servicios web

Cambios en lenguajes

Más fácil desarrollo: Bibliotecas provistas. “Administradores” que se ocupan se servicios

de sistema. Portabilidad.

Especificaciones J2EE (Sun y JCP)

• Implementada por IBM, BEA, Apache Jakarta, etc. .Net (MS)

• Implementada por MS, proyecto Mono Otras menos elaboradas

J2EE vs. .NET

J2EE Más madura Soportada por muchos actores Lenguaje Java y APIs en Java

.NET Mayor comodidad Varios lenguajes basados en CLR: C#, VB.NET, J#,

Delphi.NET, C++ Managed Extensions, etc. Fuertemente basado en XML y Web Services

Evitar fundamentalismos Malo vs. bueno, 100% Ganadores y perdedores, 100%

J2EE o .NET vs. el resto

Resto Trabajar con C, PHP, Python, Perl, Delphi... Todo se puede

J2EE y .NET Mayor facilidad de desarrollo Componentes administrados Detalles a cargo de la implementación Se programa funcionalidad de negocio

Hay software libre Mono, Tomcat, Jboss...

Herramientas (I)

Lenguajes para generación de páginas web HTML, Javascript, Java (applets) y demás.

Lenguajes para páginas del lado del servidor PHP, JSP, ASP, ASP.NET, SSJS y Java (servlets).

Plataforma para administrar lo anterior Servidores web: Apache, MS IIS, etc. Contenedor web de J2EE. Servidor de aplicaciones .NET.

Componentes de negocio y de acceso a datos Con su plataforma de servicios básicos. EJB de J2EE, componentes de Microsoft.

Herramientas (II)

Bibliotecas para hacer llamadas de métodos sobre objetos distantes RMI de Java, Remoting de .NET, CORBA del OMG.

Bibliotecas para mensajería asincrónica JMS de J2EE, MS Message Queue, IBM MQ .

Facilidades para la construcción de servicios web Plataformas .NET y J2EE. Bibliotecas de manejo y rastreo de documentos XML.

J2EE (I)

Es una especificación Desarrollada por el JCP

Multiempresa, abierto Facilidades para el desarrollo de:

Aplicaciones distribuidas Basadas en componentes Arquitectura multicapa

Asiste en el diseño, programación, ensamblado y despliegue

Garantiza interoperabilidad de componentes

J2EE (II)

Aplicación J2EE distribuida incluye: Aplicaciones cliente Componentes web, en el servidor:

• Interfaz entre los usuarios web externos y el modelo de la aplicación.

• Tipos: servlets y páginas JSP. Componentes EJB, también en el servidor

• Lógica de la aplicación y acceso a datos. Se programa en Java, más bibliotecas y

extensiones.

J2EE (III)

Condiciones de los componentes: Ensamblados en una aplicación J2EE Desplegados en un servidor J2EE, dentro de

contenedores J2EE Respetar la especificación J2EE

¿Contenedores? Aplicaciones que corren en el servidor J2EE Brindan servicios a los componentes

Cada implementación debe proveer: Servidor de aplicaciones Contenedor web Contenedor EJB

Arquitectura J2EE (I)

Servidor J2EE

Capas de modelo de negocio y acceso a datos

Capa de interfaz de usuario

Equipo cliente pesado Equipo cliente liviano

Navegador webAplicación cliente

Páginas JSP y servlets

Componentes JavaBeans (opcional) Componentes JavaBeans (opcional)

Componentes EJB

Componentes JavaBeans (opcional) Componentes JavaBeans (opcional)

Base de datos y sistemas antiguos

Arquitectura J2EE (II)Equipo cliente liviano

Navegador web

Equipo cliente pesado

Contenedor cliente

Servidor J2EE

Contenedor EJB

Contenedor web

Páginas HTML y otrosAplicación cliente

Páginas JSP y servlets

Componentes EJB

Base de datos y sistemas antiguos

¿Jini?

Arquitectura dinámica orientada a servicios Conjunto de bibliotecas y protocolos de red

Dispositivos ofrecen servicios Se comunican automáticamente Servicios “confederados” Basado en la red Fracaso:

Lanzado prematuramente No bien soportado por Sun

RMI (Remote Method Invocation)

J2SE: paquete java.rmi y dependientes. Invocación directa de métodos remotos:

Llamar a un método sobre un objeto en otra máquina y ver los resultados en la nuestra.

Posiblemente modificando un objeto local. Históricamente siempre ha sido difícil.

Forma de trabajo totalmente orientada a objetos.

Mantiene el encapsulamiento al máximo.

RMI: interfaz remota (I)

Interfaz “remota”: No se obtienen referencias a los objetos. Sí a una interfaz del espacio de cómputo local. Copia de la interfaz que implementa el objeto

remoto. Código local que se comunica a través de la

red con el objeto verdadero y remoto. Todo lo maneja la JVM

El cliente sólo utiliza la referencia a la interfaz como si fuera un objeto local.

El proveedor sólo se encargará de implementar la interfaz definida como contrato.

RMI: interfaz remota (II)

Condiciones: Debe ser pública. Debe extender la interfaz java.rmi.Remote. Cada método de la misma debe declarar que

arroja la excepción java.rmi.RemoteException. Cualquier objeto remoto pasado como

argumento o utilizado como valor devuelto de un método, incluso si está contenido en otro, debe estar declarado como instancia de la interfaz remota, no de la clase que la implementa.

RMI: una interfaz remota

// archivo Libreria.java

import java.rmi.*;

import com.libreria.paquetes.*;

// aquí está definida la clase Libro

public interface Libreria extends Remote {

int stock (Libro l) throws RemoteException;

double precio (Libro l)

throws RemoteException;

}

RMI: un cliente

import java.rmi.*;

import java.rmi.registry.*;

import com.libreria.paquetes.*;

public class ConsultaLibreria {

public static void main(String[ ] p) throws Exception {

System.setSecurityManager(new RMISecurityManager());

Libreria lr =

(Libreria)Naming.lookup("//servidor_libreria/ConsultasLibreria");

Libro libro = new Libro(”La Celestina");

System.out.println("Stock de La Celestina " + lr.stock(libro));

}

}

RMI: clase servidora

Aspectos de bajo nivel: Instalar un administrador de seguridad que

soporte RMI Crear una o más instancias del objeto remoto. Arrancar el servicio de registro de RMI Registrar por lo menos uno de los objetos

remotos con el registro de objetos de RMI Establecer el nombre del servicio Al mismo tiempo, se debe proporcionar el

nombre del servidor y el puerto del servicio Correr generadores de stubs y skeletons (rmic)

Hay funcionalidades superiores en J2EE.

J2EE y tecnologías (I)

JNDI (Java Naming and Directory Interface) Especificaciones para componentes web:

Servlets JSP (JavaServer Pages) JavaServer Faces

Especificaciones para componentes distribuidos: EJB (Enterprise JavaBeans)

JMS (Java Message Service) JAX-RPC (XML Remote Procedure Call)

J2EE y tecnologías (II)

Java API for XML Registries (JAXR) JDBC (extensiones sobre JDBC de J2SE) Java Transaction API y Java Transaction

Service (JTA/JTS) JavaMail API JavaBeans Activation Framework (JAF) SOAP with Attachments for Java (SAAJ) J2EE Connector Architecture Java Authentication and Authorization

Service (JAAS)

Servlets (I)

Clases que sirven para actuar en el típico esquema de solicitud y respuesta que utiliza el protocolo HTTP.

Se comportan como programas que reciben una solicitud, arman la respuesta y se la mandan al cliente.

Reemplazan los antiguos guiones CGI con una solución usando Java.

Todo esto se maneja dentro del servidor web mediante el contenedor web.

Servlets (II)

+init()+destroy()+service()+getServletConfig()+getServletInfo()

«interface»Servlet

+getServetContext()+getServletName()+getInitParameter()+getInitParameterNames()

«interface»ServletConfig

+init()+destroy()+service()+getServletConfig()+getServletInfo()

GenericServlet

HttpServlet

+getOutputStream()

«interface»ServletResponse

+addCookie()+addHeader()

«interface»HttpServletResponse

+getParameter() : String+getParameterMap() : Map

«interface»ServletRequest

+getCookies()+getSession()

«interface»HttpServletRequest

+getName()+getValue()+setMaxAge()+getMaxAge()+setValue()+setSecure()+getSecure()

Cookie

OutputStream

+print()+println()

ServletOutputStream

1 1

11

1 1

1

*

1

*

+getId()+getServletContext()+getSessionContext()+setMaxInactiveInterval()+getMaxInactiveInterval()+isNew()+invalidate()

«interface»HttpSession

11

+service()+init()+destroy()

ServletConcreta

HttpServlet maneja el protocolo HTTP

Servlets (III)

Método Funcionalidadvoid init (ServletConfig c) throws ServletException Es llamado cuando arranca el contenedor.ServletConfig getServletConfig()

Devuelve parámetros del servlet y aspectos de su inicialización.

String getServletInfo()Devuelve información general del servlet, como autor, versión, etc..

void service (ServletRequest s, ServletResponse r)

Es el método principal del servlet, el que debe convertir las solicitudes en respuestas.

void destroy() Es llamado cuando se cierra el contenedor.

Servlets: funcionamiento (I)

Cuando llega una solicitud HTTP: El contenedor la intercepta. La envía al método service.

• Hay también métodos doGet y doPost.

service elabora la respuesta y la escribe en un OutputStream.

El OutputStream viaja hasta el cliente.

Las variables mantienen valor entre llamadas Se pierden al cerrar el contenedor. Pero tenemos init y destroy.

Servlets: funcionamiento (II)

El contenedor controla el ciclo de vida: Si no hay una instancia existente de la servlet

cuando llega una solicitud, el contenedor carga la clase, crea una instancia y llama al método init, y luego a service; cuando se cierra el contenedor, se llama a destroy.

Una servlet sencilla: Crear una clase que herede de HttpServlet. Redefinir service para que convierta solicitudes

en respuestas. Eventualmente redefinir init y destroy de modo

de persistir datos entre arranques del servidor.

Servlets: ejemplo

import javax.servlet.*; import javax.servlet.http.*;

import java.io.*; import libreria.*;

public class ServletLibreria extends HttpServlet {

private int visitas = 0; // se mantiene entre llamadas

public void synchronized service(HttpServletRequest s, HttpServletResponse r) throws IOException {

visitas++; s.setContentType("text/html");

Libro libro = new Libro(s.getParameter("Libro"));

PrintWriter out = s.getWriter();

out.print("<h1>Precio y stock de libros:</h1>");

out.print("<p>Precio: $" + precio(libro) + "</p>");

out.print("<p>Visitada Nº" + visitas + " </p><br>");

out.close(); } }

Servlets: sesiones y cookies (I)

HTTP no maneja sesiones. Solución más conocida: cookies.

Par de valores: clave - valor asociado. Por ejemplo, ("nombre", "Carlos Fontela"). Se guarda en el equipo del cliente y permite

reconocerlo entre solicitudes sucesivas. Se puede guardar cualquier tipo de

información y hacer que ésta viaje con cada solicitud y respuesta.

Servlets: sesiones y cookies (II)

Java cuenta con una clase Cookie. Cada vez que se quiera enviar una cookie a un

cliente se la agrega al objeto HttpServletResponse:

respuesta.addCookie(new Cookie("libro consultado",s)); Método getCookies en la interfaz HttpServletRequest:

Cookie[ ] cookiesCliente = s.getCookies;

for (i = 0; i < cookiesCliente.length; i++)

valor = cookiesCliente[i].getValue();

// trabajo con el valor

}

Servlets: sesiones y cookies (III)

Interfaz HttpSession. Para manejar datos de sesiones de clientes

almacenados del lado del servidor. Información sobre lo que se hace en el sitio. Se va a desechar cuando deje el sitio. Desde el método service se llama a getSession.

• devuelve un objeto Session. getAttribute y setAttribute permiten consultar

y establecer el valor de un objeto de sesión• No es más que otro par (nombre, valor), pero

almacenado del lado del servidor.

Páginas JSP (I)

Extensión de servlets para creación y manejo de páginas web dinámicas. Más orientadas a mostrar también las partes

estáticas de una página web. Sintaxis más parecida al HTML que usualmente

utilizan los programadores web. La tecnología JSP incluye:

Un lenguaje para generar páginas dinámicas. Construcciones para acceder a objetos en el

servidor. Mecanismos para definir extensiones al propio

lenguaje JSP.

Páginas JSP (II)

Son páginas HTML con código Java para generar contenido en forma dinámica del lado del servidor.

Este código se indica al navegador rodeándolo de etiquetas especiales, entre <% y %>.

El contenedor web: Busca las etiquetas en el texto HTML. Genera servlets utilizando el código allí escrito. Las ejecuta.

Páginas JSP (III)

La primera vez que algún cliente pide una página JSP al servidor web: Se deriva al contenedor. Éste verifica si ya se han generado y

compilado las servlets que la soportan. Si así fuera, se ejecutan las servlets, se genera

la página HTML de resultado y se le envía al cliente.

Si las servlets no estuvieran generadas o fueran antiguas, se generan y se compilan antes de ejecutarlas.

Todo lo administra el contenedor web.

Páginas JSP (IV) - elementos Scriptlets <% %>

Fragmentos de código Java totalmente libre. Las variables declaradas en una scriptlet se pueden usar

en cualquier parte de la página. Expresiones <%= %>

Una porción de código que tiene como resultado un String y que se enviará directamente al cliente.

Las expresiones se vuelcan a un objeto PrintWriter predefinido que se llama out.

Directivas y declaraciones <%! o <%@%> Controlan la forma en que se traduce y ejecuta la página.

Comentarios <%-- --%> No se envían al cliente.

JSP: ejemplo 1

<%-- Este comentario no aparece en el HTML del cliente --%>

<%@ page import="java.util.*" %>

<%!

Date fecha = new Date(); int cuentaClics = 0;

%>

<html><body>

<H1>Esta página se cargó a las <%= hora %> </H1>

<H1>¡Hola! Hoy es <%= new Date() %></H1>

<H3>La página ha sido accedida <%= ++cuentaClics %>

veces desde el <%= fecha %></H3>

<% System.out.println("Adiós"); out.println("Adiós"); %>

</body></html>

JSP: ejemplo 2

<%@ page import="libreria.*" %>

<% int visitas = 0; %>

<html><body>

<H1>Precio de libros</H1>

<%

String s = solicitud.getParameter("Libro");

Libro libro = new Libro(s); visitas++;

%>

<p>Precio: $ <%= precio(libro) %> </p>

<p>Esta página fue visitada <%= visitas %> veces</p>

<% response.addCookie(new Cookie("libro consultado",s)); %>

</body></html>

JSP: otros elementos

Varios objetos y métodos predefinidos: jspInit y jspDestroy, equivalentes a init y

destroy de servlets session, la sesión activa application out page

Inclusión de archivos <jsp:include page = "paginaIncluida.jsp" %>

Extensiones a JSP

Un lenguaje de expresiones<c:if condicion="${sesion.carro.cantItems > 0}">

...

</c:if>

Etiquetas definidas por el programador “Custom Tags” Struts, del proyecto Jakarta

Etiquetas en bibliotecas estándar. JSTL paquetes core, xml, sql, fmt

Contenedores web comerciales

Incluyen servlets y servidores de páginas JSP.

IBM WebSphere, BEA WebLogic, SunOne.

Proyecto Jakarta, del Apache Group: Tomcat ver http://jakarta.apache.org/ Libre

Mensaje

Paquete de información que un sistema provee y otro está interesado en recibir, y que se envía asincrónicamente. Email es asincrónico pero al menos un extremo

es una persona. RMI es entre sistemas, pero es sincrónico. La comunicación es débilmente acoplada. El receptor y el emisor de los mensajes son

pares, sin una relación jerárquica, y ambos son servidores de aplicaciones.

Asincronismo significa que los mensajes se envían sin importar que haya quien los reciba.

Mensajería

Un software o biblioteca que provee la funcionalidad necesaria para enviar y recibir mensajes.

Permite asegurar al remitente que un mensaje enviado se recibió correctamente. Por su naturaleza asincrónica, no se puede chequear

la recepción en el momento en que se envía. El acuse de recibo llega mediante otro mensaje.

En J2EE, JMS.

Tipos de mensajería (I)

Punto a punto Trabaja con colas de mensajes. Emisor envía un mensaje a la cola que le

corresponde según alguna regla. Receptores retiran mensajes de las colas a las cuales

deben atender. Los mensajes tienen un único consumidor, y una vez

atendidos nadie más los recibe. En algunos casos, se definen tiempos de expiración. El receptor debe avisar que recibió el mensaje y lo

está procesando, todo en forma asincrónica.

Tipos de mensajería (II)

Publicación-suscripción Emisores y receptores son anónimos, en el sentido

de que no necesariamente se conocen. Receptores se subscriben por temas de interés. Emisores envían los mensajes, también por tema, a

los receptores que están en línea para recibirlos. Cada mensaje puede tener muchos consumidores. Puede ser recibido por ninguno, uno o muchos. La recepción debe ser sincrónica, pues el receptor

tiene que estar en línea para recibir el mensaje. Responde al patrón de diseño Observador.

JMS (I)

Con J2EE pueden enviar mensajes JMS asincrónicos: las aplicaciones cliente los componentes EJB y web

Pero recibir mensajes asincrónicos, sólo: aplicaciones cliente EJB dirigidos por mensajes (message-driven beans) todo otro componente sólo puede recibir mensajes

síncronos

JMS (II)

JMS permite realizar mensajería con sistemas heredados de otras tecnologías: Se pueden definir eventos de aviso de llegada de

mensajes en componentes EJB. Los contenedores pueden soportar transacciones y

consumo concurrente de mensajes. Aun cuando las transacciones se hubieran iniciado en

sistemas no J2EE. La tecnología que ayuda a soportar todo esto es

Connector.

JMS (III)

Soporta mensajes punto a punto y por publicación-suscripción. Permite definir suscripciones durables, de modo tal

que un mensaje pueda quedar en el buzón de un receptor si éste no está en línea.

Proveedor de mensajería Realiza tareas administrativas relacionadas con el

control de mensajes y define las interfaces que permiten las comunicaciones.

Emisores y receptores de mensajes JMS se denominan clientes JMS.

JMS (IV) Otras funcionalidades:

control del acuse de recibo persistencia del mensaje

• para casos de falla del proveedor del servicio prioridades de mensajes mensajes que expiran luego de un tiempo destinos temporales suscripciones durables transacciones locales

• para agrupar una serie de envíos y recepciones, que se confirman o se vuelven atrás todas juntas

Excepciones Todas las derivadas de JMSException.

JMS - objetos y clases (I)

Conexiones Encapsulan una conexión con el proveedor.

Implementan la interfaz Connection. Se crean a partir de un objeto ConnectionFactory.

Sesiones Para producir y consumir mensajes. Proveen contextos transaccionales para agrupar

conjuntos de envíos y recepciones. Implementan la interfaz Session.

Generadores de mensajes. Para enviar mensajes a un destino. Implementan la interfaz MessageProducer.

JMS - objetos y clases (II)

Consumidores de mensajes Para recibir los mensajes enviados a un destino. Implementan la interfaz MessageConsumer.

Observadores de mensajes Manejadores de eventos asíncronos para mensajes. Implementan la interfaz MessageListener, con su

método onMessage. Se registran para un consumidor de mensajes

mediante el método setMessageListener.

Servicios web (I)

Conjunto de funciones.

Se las accede en forma remota.

Desde cualquier plataforma.

Utilizando el protocolo HTTP.

La implementación más exitosa de las arquitecturas orientadas a servicios.

B2B.

Servicios web (II) Cajas negras

Encapsulan su funcionalidad. Proveen interfaces para acceder. Las interfaces deben ser “bien conocidas”. Deben estar publicadas en algún lado para que

se sepa cómo utilizarlas. Registro

Se ocupa de publicar servicios web. Hace de catálogo de los servicios existentes,

proveyendo este servicio a clientes y proveedores.

ebXML, UDDI, etc.

Servicios web (III)

Registro

Cliente Proveedor

publica_descripción_servicio()

cons

ulta

_sob

re_s

ervi

cios

()

envi

a_in

form

ació

n_se

rvic

io()

solicita_servicio()brinda_servicio()

Roles

¿Dinámicos? ¡NO!

Servicios web (IV)

Arquitectura estática Tiene que ver con la naturaleza de los

registros. Y con las plataformas CORBA, .NET o J2EE.

Y sincrónica Se están haciendo esfuerzos para facilitar el

desarrollo de servicios web asincrónicos. Microsoft, IBM, Apache Group, etc. Requiere hacer un uso poco natural de SOAP y

montarlos sobre sistemas de mensajería o protocolos como SMTP.

Servicios web y XML (I)

Solicitudes y respuestas se deben enviar en XML. Para garantizar portabilidad. Un servicio web desarrollado en Java y

corriendo en una máquina Linux, se va a poder acceder desde una aplicación desarrollada en cualquier lenguaje y plataforma.

SOAP El formato de los mensajes debe utilizar un

protocolo estándar y no sólo XML. En general se utiliza el protocolo SOAP sobre

HTTP.

Servicios web y XML (II)

WSDL Lenguaje basado en XML. Para definir la interfaz de un servicio web. Para que los clientes sepan cómo invocarlos y

cómo interpretar sus resultados. Un documento WSDL especifica:

• nombre• operaciones• parámetros• ubicación del servicio.

WSDL + SOAP = interoperabilidad.

Servicios web y J2EE

2 formas de construirlos: Utilizando la biblioteca JAX-RPC. Accediendo a “stateless session beans” a

través del terminal de servicio. En ambos casos los clientes pueden acceder

desde cualquier plataforma y lenguaje. En la medida de que usen SOAP, HTTP y WSDL.

En general se utiliza JAX-RPC. Un mensaje SOAP, con el esquema de solicitud

y respuesta de HTTP.

Servicios web y JAX-RPC (I)

Relación con el servidor J2EE Los métodos que pueden ser invocados suelen

estar basados en EJB. Se encapsulan en un contenedor de servlets

del lado del servidor que brinda el servicio. Esta presencia de los contenedores hace que

nos tengamos que ocupar sólo de programar la lógica y realizar llamadas a métodos en Java.

JAX-RPC sirve tanto para crear servicios web como para programar clientes de servicios web.

Servicios web y JAX-RPC (II)

JAX-RPC oculta la complejidad de SOAP Del lado del proveedor sólo se especifican

métodos en una interfaz que va a ser la que van a poder usar los clientes.

Y luego se implementa esa interfaz en una o más clases.

Del lado del cliente, sólo se debe crear un proxy, un objeto local que representa el servicio.

E invocar los métodos en el proxy. No es necesario generar ni rastrear mensajes

SOAP.

Servicios web y JAX-RPC (III)

Convierte llamadas y retornos de métodos en Java en mensajes SOAP sobre HTTP. Tanto del lado del cliente como del servidor. Cuando un cliente llama al método remoto,

JAX-RPC lo convierte a SOAP y lo envía. El servidor recibe un mensaje SOAP, lo rastrea,

lo convierte en llamadas a método, lo invoca, arma la respuesta sobre SOAP y la envía.

Debe ser capaz de convertir los tipos de los parámetros, y los resultados de los métodos, a tipos XML.

Servicios web y JAX-RPC (IV)

Tipos permitidos: boolean, byte, double, float, int, long y short. De java.lang: Boolean, Byte, Double, Float,

Integer, Long, Short y String. De java.math: BigDecimal y BigInteger. De java.util: Calendar, Date, ArrayList,

LinkedList, Stack, Vector, HashMap, Hashtable, Properties, TreeMap, HashSet y TreeSet.

La clase java.net.URI. Arreglos primitivos de cualquier dimensión

cuyos elementos sean de los tipos anteriores.

Servicios web y JAX-RPC (IV)

Tipos permitidos (sigue): Clases con atributos de los tipos anteriores, sin

modificadores final o transient, además de un constructor público sin parámetros. No pueden implementar directa ni indirectamente la interfaz java.rmi.Remote. Los atributos no públicos deben tener métodos "get" y "set" para consulta y modificación de estado.

Componentes JavaBeans, con propiedades cuyo tipo sea uno de los permitidos.

Servicios web y JAXR

Se utiliza para acceder a registros. Para que un servicio se registre a sí mismo. Para que un cliente consulte sobre un servicio

en un registro.

Registración con JAXR Informar un nombre, una descripción y algunos

criterios de clasificación que permitan buscar el servicio.

Búsquedas con JAXR Con un lenguaje similar a SQL.

Construcción de servicios web (I)

Primero: definir la interfaz que expone los métodos que podrá invocar un cliente.

Las reglas son las mismas de RMI:// archivo InterfazWSLibreria.java

package carlosfontela.ws.libreria;

import java.rmi.*; import com.libreria.paquetes.*;

public interface InterfazWSLibreria extends Remote {

int stock (Libro l) throws RemoteException;

double precio (Libro l) throws RemoteException; }

Por ser un servicio web, el cliente no necesariamente utilizará esta interfaz.

Construcción de servicios web (II)

Para construir el servicio: Compilar todo. Generar el archivo WSDL. Hacer la transformación entre los nombres

definidos en el paquete de clases del servicio y una dirección web.

Mucho se hace en forma automática en base a un archivo XML de configuración y programas utilitarios.

Luego se compacta todo en un WAR (un JAR para aplicaciones web).

Clientes de servicios web (I)

No tiene por qué ser una aplicación Java Si lo es, conviene que lo desarrollemos

también utilizando JAX-RPC.

Distintos tipos de clientes. Los más simples de construir son los más

limitados en cuanto al uso.

Una posibilidad es acceder desde una aplicación J2EE, localizándolo mediante el método lookup de JNDI.

Clientes de servicios web (II)

Cliente de stub estático Aplicación aislada que invoca a los métodos

del servicio web mediante un objeto local que hace de proxy para el servicio remoto.

El stub es generado manualmente antes de correr el programa.

Cliente proxy dinámico Creado en tiempo de ejecución. No se necesita codificar nada que sea

dependiente de la implementación. El proxy se obtiene de una fábrica llamada Service.

Clientes de servicios web (III)

Cliente que utiliza una interfaz de invocación dinámica El programa cliente desconoce incluso el

nombre del servicio y las signaturas de los métodos, hasta el tiempo de ejecución.

Se basa en el documento WSDL. Hay que tratar el documento WSDL desde el

programa cliente. Mayor complejidad: el WSDL debe tratarse con

JAXP.

Un cliente de stub estático (I)package cliente.accesoLibreria;

import javax.xml.rpc.Stub; import com.libreria.paquetes.*;

public class ClienteLibreria {

private String direccionWS;

public static void main (String [ ] p) {

try { Stub stub = createProxy();

// la dirección del servicio se pasó como parámetro:

stub._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY, p[0]);

InterfazWSLibreria servicio = (InterfazWSLibreria)stub;

Libro libro = new Libro(”La Celestina");

System.out.println("Stock de La Celestina " + servicio.stock(libro));

} catch (Exception e) {} }

private static Stub createProxy() { // dependiente de la implementación:

return (Stub)(new ClienteWSLibreria().getPuertoInterfazWSLibreria());} }

Un cliente de stub estático (II)

Necesitamos generar una clase En nuestro caso, ClienteWSLibreria Se genera en el proceso de construcción, que

incluye:• generación de stubs

• compilación del cliente

• empaquetado del cliente

• todo en base a un archivo XML que se le suministra al programa que construye la aplicación: asant

Servicios web SOAP sin JAX-RPC

SAAJ Para

obtener una funcio-nalidad distinta.

Hay que conocer SOAP.

Encabezados (0..*) Contenido XML (0..*)

Errores de SOAP (0..*)

Encabezados MIME Contenido (XML o no)

EncabezadoSOAP

CuerpoSOAP

Sobre SOAP

Parte deSOAP

Parte deadjuntos (0..*)

Mensaje SOAP

Servicios web asincrónicos (I)

JAX-RPC sólo permite implementar y utilizar servicios web forma sincrónica. Ni siquiera soporta transacciones como RMI. El protocolo SOAP se pensó inicialmente para

usar llamadas a métodos remotos sobre HTTP en forma sincrónica.

En realidad, el propio HTTP es sincrónico. Para lograr servicios web asincrónicos, deben

montarse sobre un sistema de mensajería, como JMS, enviando mensajes XML.

Servicios web asincrónicos (II)

3 direcciones posibles: Extensiones de WSDL para vinculación con un

transporte asincrónico: no estándares. Marco, como Apache Axis, colocando manejado-res

de transporte entre cliente y servidor.• Tampoco hay interoperabilidad.

Adaptadores del programador para convertir de HTTP a un sistema de mensajería.

• Permite mejores soluciones, pero con mucha programación. Las soluciones utilizando HTTP son eficientes y

escalables, pero menos confiables.• Escasas garantías para verificar tiempos de caducidad,

retransmisiones y detección de duplicados.

Componentes EJB

La base de J2EE. Tecnología para estandarizar y simplificar el

desarrollo de aplicaciones distribuidas de envergadura y escalables.

Especificación sobre cómo construir componentes del lado del servidor.

Se basa en objetos distribuidos. La funcionalidad de los mismos está en parte del lado

del servidor y en parte del cliente.

Basado en JNDI y JTA/JTS

Contenedor y servidor EJB

Entorno de ejecución que permite desplegar y administrar componentes EJB.

Provee servicios de sistema. Neutral respecto del proveedor.

Puede correr lo de cualquier proveedor y generar componentes para cualquier plataforma.

Asegura la portabilidad entre distintos proveedores.

Servidor EJB: un servidor de aplicaciones que contiene y corre uno o más contenedores EJB.

Características EJB

Componentes

Administrados

Del lado del servidor

Componentes

Clases y conjuntos de clases que se distribuyen en su forma compilada. Son JavaBeans. Pero asociados a servicios.

Configurables El cliente los puede adaptar para incluirlos en su

aplicación.

Un EJB es una clase Una “instancia EJB” es el objeto concreto.

Del lado del servidor

Allí se alojan clases e instancias.

A veces ofrecen una vista remota, lo que implica

que un cliente puede ver parte de una instancia,

con RMI. La parte visible mediante esta vista.

Otras veces sólo se ofrecen vistas locales Incluso los clientes tienen que correr del lado del

servidor.

Administrados (I)

Un desarrollador sólo debe proveer la lógica. Del resto (los servicios administrativos) se ocupan los

servidores y contenedores EJB.

Contenedor Se ocupa de tareas complejas, tediosas y que llevan

a cometer errores. Almacena y administra un EJB. Cuando un cliente invoca un método remoto en un

EJB, el contenedor intercepta la invocación para asegurar persistencia, transacciones, seguridad, etc.

Administrados (II)

Tareas del contenedor: Persistencia. Control de seguridad declarativo. Control de transacciones distribuidas declarativo. Administración de concurrencia. Administración de escalabilidad. Sesiones. Caché. Ciclo de vida. RMI cuando sea necesario.

Persistencia

Estado de una instancia de EJB puede ser

almacenado en algún medio externo.

Podrá ser o no una base de datos relacional.

Contenedor se va a ocupar de mantener el

sincronismo entre el objeto en memoria y el

almacenado, aun en contextos concurrentes.

Seguridad declarativa

Basta definir roles de seguridad. Y especificarle al contenedor qué roles pueden

acceder a qué métodos. Contenedor se va a ocupar del resto y lanzará

las excepciones que correspondan. Cuando haya cambios, se cambian las

especificaciones sin necesidad de recompilar. Facilita cambios por los clientes.

Transacciones declarativas

Manejadas por el contenedor. Con sólo definirle los demarcadores de

comienzo y fin de transacción. Vuelta atrás de todos los métodos de una

transacción en forma automática. Cambios no implican recompilaciones.

Concurrencia

Se ocupa de que no haya problemas si varios clientes remotos tratan de usar la misma instancia de un EJB.

Escalabilidad

Cada recurso no necesariamente se cree cada vez que se necesite. Mantiene un uso mínimo de los recursos. Conexiones de bases de datos, objetos EJB, hilos,

sockets y demás se suelen obtener de pools y se devuelven al mismo en vez de destruirlos.

Contenedor controla todos los conflictos. Si una instancia no se está usando, el contenedor

puede usarla para otra cosa. El cliente mantiene la referencia. Cuando el cliente pide un servicio, reencarna al bean.

Tipos EJB

Servidor Web XML/SOAP

Servidor J2EE remoto

Servidor J2EE

Capa acceso a datos

Capa de interfaz de usuario

Equipo cliente rico Equipo cliente web

HTML y otrosAplicación cliente

Páginas JSP y servlets

Entity Beans

Base de datos y sistemas antiguos

Capa lógica de la aplicación

Session Beans

Interfaz sistemas mensajería

Message-Driven Beans

Servicio Web Externo

Proveedor JMS externo

Para separación en capas

Entity beans (I)

Componentes que representan objetos persistentes y el comportamiento de esos datos. En general, cada entity bean implica una tabla en una

BDR. Y cada instancia de un entity bean una fila.

Pueden ser compartidos por muchos clientes. Persistencia administrada por:

Contenedor: CMP. Componente: BMP.

Entity beans (II)

CMP No hay ni una línea de código en el componente que

acceda a la base de datos. Más portable entre distintos tipos de

almacenamientos persistentes.

BMP El componente debe contener el código JDBC, etc.,

para ocuparse de la persistencia. Usar para persistir sobre alguna base de datos no

soportada por el contenedor usado.

Entity beans (III)

Tienen una clave primaria Identifica unívocamente a cada instancia. Permite localizarlas.

Y relaciones En el mismo sentido de las que existen entre tablas

de bases de datos. Si es BMP hay que implementar las relaciones. En el descriptor de despliegue se pueden definir las

relaciones y los atributos persistentes.

Prestar atención a la integridad referencial. Evitar que BD borre un objeto que está referenciado.

Session beans (I)

Representan casos de uso, lógica del modelo. TarjetaCredito puede ser un entity bean, pero

Verificador TarjetaCredito debe ser un session bean.

Viven mientas dure una sesión con un cliente, y todos sus datos se pierden junto con la sesión.

Cuando quieren acceder a datos persistentes se comunican con entity beans.

Para delegar, se comunican con otros session beans.

Se usan para hacer de fachadas distribuidas.

Session beans (II)

Pueden ser con o sin conservación de estado: “Stateful” o “stateless”.

Sin conservación de estado No mantienen estado entre invocaciones. Para cuando no se necesita identificar o mantener

rastro de un cliente. Sencillas, pueden ser cacheadas del lado del

servidor, escalan bien. Se adaptan mejor a los procesos vinculados a HTTP. Siempre que se pueda, hacerla sin conservación.

Session beans (III)

Con conservación de estado Mantienen información de sesión. Deben mantener un mapeo uno a uno con el cliente. Como no son persistentes, pues la información se

guarda en la memoria del servidor, una caída del contenedor EJB provoca la pérdida de datos de sesión.

Para usar el mecanismo de pool y asignar recursos a otros objetos, el contenedor debe antes persistir los datos de una forma transparente al cliente.

Eligiendo el tipo de EJB

Session Si el componente no es persistente. Si sólo un cliente debe tener acceso a una instancia del bean.

Stateful Si el bean se refiere a la interacción entre el mismo y un cliente

específico. Si necesitamos mantener información del cliente. Si hay que manejar el flujo de trabajo de varios EJB.

Stateless Si son tareas genéricas para todos los clientes. Si se refiere a un conjunto de de datos de sólo lectura que son

utilizados por todos los clientes.

Message-driven beans (I)

Trabajan con JMS. Para especificar la acción a seguir cuando se recibe

un determinado mensaje. J2EE puede enviar mensajes desde cualquier EJB. Puede recibir en forma sincrónica en cualquier EJB. Pero para recibir en forma asincrónica se necesita

una message-driven bean.

No son para ser usadas por clientes Ni locales ni remotos. No exponen vistas.

Sólo los usan otros componentes.

Message-driven beans (II)

Observador de mensajes que vengan de cualquier componente J2EE. Contiene un método onMessage. Debe implementar además las interfaces

javax.jms.MessageListener, javax.ejb.MessageDrivenBean y los métodos ejbCreate, ejbRemove y setMessageDrivenContext.

O de otra plataforma. Connector: para que reciban mensajes desde

cualquier sistema de información.

Message-driven beans (III)

Manejan transacciones. Se parecen a los session beans sin

conservación de estado: No mantienen estado. Todas las instancias son equivalentes y se pueden

colocar en un pool sin problema. Pueden procesar mensajes provenientes de varios

clientes.

Biblioteca EJB

«interface»java.rmi.Remote

«interface»EJBHome

«interface»EJBObject

«interface»EJBLocalHome

«interface»EJBLocalObject

«interface»java.io.Serializable

«interface»EnterpriseBean

«interface»EntityBean

«interface»SessionBean

«interface»MessageDrivenBean1 1

1 1

Para los clientes Para el implementador

{ Cuando no se indica paquete, es java.ejb }

Interfaces para los clientes (I)

Tipos: Home: funciones del ciclo de vida del componente. Object: declaraciones de los métodos de negocio.

Categorías de vistas: Remota: cliente remoto corre en una máquina distinta

usando una JVM distinta.• Incluir las interfaces Home y Object para clientes remotos.

Local: cliente local corre en la misma JVM que el componente al cual accede.

• Incluir las interfaces Home y Object para clientes locales.

Interfaces para los clientes (II)

Se pueden usar hasta cuatro interfaces: Home para vista local. Home para vista remota. Object para vista local. Object para vista remota. Y por lo menos una Home y una Object.

Los message-driven sólo tienen vistas locales.

A veces a la Object la llaman “remota” (bastante equívoco).

Interfaces para los clientes (III)

Diseño de las interfaces (1) Para manejar modificaciones futuras y escalabilidad. Un buen diseño no debiera afectar a los clientes en

casos de cambios. Si un entity bean es parte de una relación manejada

por el contenedor, debe tener una vista local. Los componentes muy acoplados son candidatos

para acceso local entre ellos. Si un componente debe ser accedido desde otras

aplicaciones J2EE, debe tener vista remota.

Interfaces para los clientes (IV)

Diseño de las interfaces (2) Si deseamos que una aplicación esté distribuida entre

muchas máquinas, debemos tener interfaces remotas.

• Esto también aumenta la escalabilidad.

En interfaces remotas, conviene que los métodos sean de granularidad gruesa.

Elementos de un EJB

Clase que implementa el componente. Clases de soporte (invisibles). Interfaz Home (session y entity). Interfaz Object (session y entity). Descriptor de despliegue.

Se usa para parametrizar el componente. Establecer relaciones entre entity beans y su

cardinalidad, nombre y nombres de roles.

Antes de distribuir un componente hay que empaquetarlo en un único archivo JAR.

Arquitectura EJB

Cliente Servidor de aplicaciones

Aplicación Cliente

Proxy RMI

Instancia EJB

Proxy EJB

Stub RMI

Protocolo de red

Construcción de EJB (I)

Lo mínimo que debemos hacer es: Definir la clase de implementación. Escribir el descriptor de despliegue. Salvo en el caso de los message-driven beans,

codificar las interfaces Home y Object, que opcionalmente podrían ser hasta cuatro.

El contenedor deberá usar las interfaces para construir los objetos mediadores. Usa reflexión sobre las interfaces. Importante respetar las convenciones de

nombres.

Construcción de EJB (II)

Interfaz Home Métodos asociados al ciclo de vida. Debe tener métodos de creación de

componentes Y, en el caso de un entity bean, de búsqueda. Valores de retorno de los de creación deben

ser de tipo EJBHome, EJBLocalHome. Métodos de creación deben declarar la

excepción javax.ejb.CreateException. Métodos de búsqueda podrán devolver interfaz

o colección de tipo Enumeration o Collection. Pública. Derivada de EJBHome o EJBLocalHome.

Construcción de EJB (III)

Interfaz Object Métodos de la lógica de la aplicación. Pública. Derivada de EJBObject o EJBLocalObject.

Para interfaces EJBObject y EJBHome: Métodos deben declarar que arrojan java.rmi.RemoteException.

Cada objeto usado como parámetro o valor de retorno debe ser de un tipo válido RMI.

Construcción de EJB (IV)

Clase de implementación Pública. No debe implementar ninguna de las interfaces

que definimos. SessionBean, EntityBean o MessageDrivenBean.

No es una clase concreta. La clase concreta la va a generar el contenedor

a partir de la que le defina el programador, que es abstracta.

Construcción de EJB (IV)

Objetos mediadores basados en RMI Generados automáticamente por algunos

contenedores cuando se hace el despliegue. Otros lo hacen en tiempo de ejecución.

Hay que generar una gran cantidad de archivos y mantenerlos siempre sincronizados. Difícil de mantener. Muchos productos comerciales facilitan el

desarrollo con herramientas especiales. También EJBDoclet, de código abierto.

Resumen Prepararse para un cambio de paradigma:

Aplicaciones web distribuidas. J2EE es una especificación.

Para aplicaciones distribuidas. Para aplicaciones escalables. Concentrarse en la lógica de la aplicación.

EJB es el núcleo de J2EE. Componentes administrados del lado del servidor.

Servicios web son multiplataforma. Gracias a XML, WSDL y SOAP. Pero son sincrónicos.

Bibliografía y otras fuentes

Buenos tutoriales en http://java.sun.com/.

“Thinking in Enterprise Java”, de Eckel.

“Orientación a objetos con Java y UML”.

Web.

No en POO Fontela.

Muchas Gracias.

Carlos Fontela, 2005