Download java.rmi.Remote

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



Redes de PCs



Procesamiento descentralizado
Almacenamiento centralizado
Web, primeros años



Procesamiento centralizado
Terminales bobas
Primero, como mainframes
Luego, aprovechando capacidad de clientes
Hoy: aplicaciones distribuidas
Cambio de paradigma

Aplicaciones distribuidas:



Basadas en Internet:




Corren en varias máquinas tipo servidores.
Esquema cooperativo.
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”


Componentes para páginas web dinámicas




Se comunican con componentes de negocio.
Componentes de negocio


HTML, multimedia, guiones, applets y otros.
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




.NET




Más madura
Soportada por muchos actores
Lenguaje Java y APIs en Java
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



J2EE y .NET





Trabajar con C, PHP, Python, Perl, Delphi...
Todo se puede
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


Lenguajes para páginas del lado del servidor


PHP, JSP, ASP, ASP.NET, SSJS y Java (servlets).
Plataforma para administrar lo anterior




HTML, Javascript, Java (applets) y demás.
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


Bibliotecas para mensajería asincrónica


RMI de Java, Remoting de .NET, CORBA del OMG.
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


Facilidades para el desarrollo de:





Multiempresa, abierto
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)
Equipo cliente pesado
Equipo cliente liviano
Aplicación cliente
Navegador web
Componentes JavaBeans (opcional)
Componentes JavaBeans (opcional)
Servidor J2EE
Capa de interfaz de usuario
Páginas JSP y servlets
Componentes JavaBeans (opcional)
Componentes JavaBeans (opcional)
Capas de modelo de negocio y acceso a datos
Componentes EJB
Base de datos y sistemas antiguos
Arquitectura J2EE (II)
Equipo cliente pesado
Contenedor cliente
Aplicación cliente
Equipo cliente liviano
Navegador web
Páginas HTML y otros
Servidor J2EE
Contenedor web
Páginas JSP y servlets
Contenedor EJB
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:




Especificaciones para componentes
distribuidos:



Servlets
JSP (JavaServer Pages)
JavaServer Faces
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)
«interface»
Servlet
+init()
+destroy()
+service()
+getServletConfig()
+getServletInfo()
«interface»
ServletRequest
+getParameter() : String
+getParameterMap() : Map
1
1
«interface»
ServletConfig
+getServetContext()
+getServletName()
+getInitParameter()
+getInitParameterNames()
GenericServlet
+init()
+destroy()
+service()
+getServletConfig()
+getServletInfo()
«interface»
HttpSession
+getId()
«interface»
11
+getServletContext()
HttpServletRequest
+getSessionContext()
+getCookies()
+setMaxInactiveInterval()
+getSession()
+getMaxInactiveInterval()
+isNew()
+invalidate()
1
1
1
OutputStream
«interface»
ServletResponse
+getOutputStream()
ServletOutputStream
1 1
+print()
+println()
«interface»
HttpServletResponse
+addCookie()
+addHeader()
HttpServlet
1
HttpServlet
maneja el
protocolo
HTTP
ServletConcreta
+service()
+init()
+destroy()
Cookie
*
+getName()
+getValue()
+setMaxAge()
+getMaxAge()
+setValue()
+setSecure()
+getSecure()
*
Servlets (III)
Método
void init (ServletConfig c)
throws ServletException
ServletConfig
getServletConfig()
Funcionalidad
Es llamado cuando arranca el contenedor.
Devuelve parámetros del servlet y aspectos de su
inicialización.
Devuelve información general del servlet, como autor,
String getServletInfo()
versión, etc..
void service (ServletRequest s, Es el método principal del servlet, el que debe
ServletResponse r)
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
llamadas
mantienen
valor

Se pierden al cerrar el contenedor.

Pero tenemos init y destroy.
entre
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
HttpServletRequest:
en
Cookie[ ] cookiesCliente = s.getCookies;
for (i = 0; i < cookiesCliente.length; i++)
valor = cookiesCliente[i].getValue();
// trabajo con el valor
}
la
interfaz
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






<%! o <%@
%>
Controlan la forma en que se traduce y ejecuta la página.
Comentarios

<%= %>
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

%>
Fragmentos de código Java totalmente libre.
Las variables declaradas en una scriptlet se pueden usar
en cualquier parte de la página.
Expresiones

<%
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,
SunOne.

Proyecto Jakarta, del Apache Group:
BEA

Tomcat

ver http://jakarta.apache.org/

Libre
WebLogic,
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
asincrónicos:
enviar

las aplicaciones cliente

los componentes EJB y web
mensajes
JMS
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



Sesiones




Encapsulan una conexión con el proveedor.
Implementan la interfaz Connection.
Se crean a partir de un objeto ConnectionFactory.
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)
Roles
a
blic
pu
()
cio
rvi
se
n_
solicita_servicio()
brinda_servicio()
Cliente
¿Dinámicos? ¡NO!
ió
pc
cri
es
_d
c
en onsu
via lta
_in _s
for obr
ma e_
ció ser
n_ vic
se ios
rvi ()
cio
()
Registro
Proveedor
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 cliente consulte sobre un servicio
en un registro.
Registración con JAXR


Para que un servicio se registre a sí mismo.
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


desarrollemos
Distintos tipos de clientes.


Si lo es, conviene que lo
también utilizando JAX-RPC.
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
invocación dinámica




una
interfaz
de
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
funcionalidad
distinta.
Hay
que
conocer
SOAP.
Mensaje SOAP
Parte de
SOAP
Sobre SOAP
Encabezado
SOAP
Encabezados (0..*)
Cuerpo
SOAP
Contenido XML (0..*)
Errores de SOAP (0..*)
Parte de
adjuntos (0..*)
Encabezados MIME
Contenido (XML o no)
Servicios web asincrónicos (I)

JAX-RPC sólo permite implementar
utilizar servicios web forma sincrónica.




y
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 manejadores 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
componentes del lado del servidor.

Se basa en objetos distribuidos.


construir
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
proveedores.
portabilidad
entre
distintos

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
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.
de
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
Equipo cliente rico
Equipo cliente web
Aplicación cliente
HTML y otros
Servidor J2EE
Capa de interfaz de usuario
Páginas JSP y servlets
Capa lógica de la aplicación
Para
separación en
capas
Session Beans
Capa acceso a datos
Entity Beans
Interfaz sistemas mensajería
Message-Driven Beans
Base de datos y sistemas antiguos
Servidor J2EE remoto
Proveedor JMS externo
Servidor Web XML/SOAP
Servicio Web Externo
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
almacenamientos persistentes.
tipos
de
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



Y relaciones




Identifica unívocamente a cada instancia.
Permite localizarlas.
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.





No son para ser usadas por clientes



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.
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
conservación de estado:
beans
sin

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
Para los clientes
Para el implementador
«interface»
java.rmi.Remote
«interface»
EJBHome
«interface»
java.io.Serializable
«interface»
EJBObject
1
«interface»
EnterpriseBean
1
«interface»
EJBLocalHome
«interface»
EJBLocalObject
1
1
«interface»
EntityBean
«interface»
SessionBean
«interface»
MessageDrivenBean
{ 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
Instancia EJB
Proxy RMI
Protocolo de red
Proxy EJB
Aplicación Cliente
Stub RMI
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
nombres.
de
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
java.rmi.RemoteException.
que
arrojan
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,
MessageDrivenBean.
EntityBean
o
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
desarrollo con herramientas especiales.
También EJBDoclet, de código abierto.
el
Resumen

Prepararse para un cambio de paradigma:


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.


Aplicaciones web distribuidas.
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