Post on 24-Jan-2016
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
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.
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.
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>
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.
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) Otras funcionalidades:
mensajería con sistemas heredados de otras tecnologías
• Usando Connector 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
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 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.
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
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.
Tareas del contenedor (I) 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.
Control de seguridad declarativo Basta definir roles de seguridad.
• qué roles pueden acceder a qué métodos.
Contenedor se va a ocupar del resto y lanzará las excepciones que correspondan.
Tareas del contenedor (II)
Control de transacciones distribuidas declarativo 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.
Administración de concurrencia Se ocupa de que no haya problemas si varios clientes
remotos tratan de usar la misma instancia de un EJB.
Tareas del contenedor (III) Administración de escalabilidad
Cada recurso no se cree cada vez que se necesite.• Mantiene un uso mínimo de los recursos.
• Conexiones de bases de datos, objetos EJB, hilos, sockets.• Se obtienen de pools y se devuelven en vez de destruirlos.
Contenedor controla todos los conflictos.• Si una instancia no se está usando, puede usarla.• El cliente mantiene la referencia.• Cuando el cliente pide un servicio, reencarna al bean.
Sesiones. Caché. Ciclo de vida. RMI cuando sea necesario.
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.
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.
Message-driven beans
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.
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.
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 (hasta 4). El contenedor deberá usar las interfaces para
construir los objetos mediadores. Usa reflexión sobre las interfaces. Importante respetar convenciones.
Hay que generar una gran cantidad de archivos y mantenerlos sincronizados. Difícil de mantener. Muchos productos facilitan el desarrollo con herramientas
especiales.
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