En esta página:
¿Qué hay de Nuevo en EJB 2.1?
El primer borrador público de la especificación Enterprise JavaBeans 2.1 se liberó el 19 de Junio de 2002. La especificación es sólo un borrador, y no es final, por eso debes recordar: la especificación seguro que va a cambiar!. Aquí, lo digo: puede que todo el contenido de estas páginas sea correcto cuando la especificación sea final, o puede que algo sea diference. Es difícil decirlo en este momento.
Los cambios en EJB 2.1 se enfocan principalmente en los Servicios Web basados en SOAP y WSDL. Incluye dos nuevos APIs de Servicios Web (JAX-RPC y JAXM) que se pueden usar para comunicarse con otros Servicios Web y permite a los beans sin estado y a los beans dirigidos por mensaje actuar como Servicios Web. La línea base es que EJB se ha convertido en una plataforma de Servicios Web.
Además de su soporte de Servicios Web. EJB 2.1 mejora EJB-QL, corrige muchas de sus debilidades y también ha mejorado los beans dirigidos por mensaje (MDB). El modelo de programación MDB se ha ampliado más allá del Java Message Service para soportar casi cualquier sistema de mensajería. Además, se ha añadido un nuevo servicio de temporizadores, que permite a los beans enterprise registrarse para eventos basados en el tiempo, así como una facilidad de enlazado-de-mensajes, que permite a los desarrolladores manejar el flujo de mensajes entre componentes.
Soporte para Servicios Web
La principal fuerza que hay detrás de EJB 2.1 es el soporte para Servicios Web. EJB 2.1 permite a los desarrolladores exponer beans de sesión sin estado y beans dirigidos por mensaje (MDBs) como Servicios Web basados en SOAP, haciéndolos disponibles ara cualquier cliente compatible con SOAP 1.1. Por ejemplo, es posible usar SOAP para llamar a métodos de un bean de sesión sin estado desde otras plataformas de Servicios Web como .NET de Microsoft, Axis de Apache, y muchas otras plataformas y lenguajes. Las nuevas facilidades de Servicios Web de EJB 2.1 porporcionan un nivel de interoperabilidad multi-plataforma que anteriormente simplemente no estaba disponible.
Las nuevas facilidades de Servicios Web de EJB 2.1 están basadas en dos nuevos kits de herramientas SOAP de J2EE definidos por el Java Community Process (JCP), JAX-RPC y JAXM.
JAX-RPC y EJB
JAX-RPC (el API Java para XML-RPC) esencialmente es RMI Java sobre SOAP. Es similar al RMI Java "nativo" (Java RMI-JRMP) y Java RMI-IIOP, pero usa SOAP como protocolo. Una implementación de JAX-RPC debe, como mínimo, soportar codificación RPC de SOAP sobre HTTP, pero los vendedores también podrían soportar otros estilos de codificación, de mensajería, y protocolos de Internet. JAX-RPC se puede utilizar para beans de sesión, de entidad y dirigidos por mensaje para invocar operaciones de Servicios Web. Por ejemplo, un bean de sesión sin estado podría usar JAX-RPC para llamar a un método de un Servicio Web .NET.
JAX-RPC también es la base para un nuevo componente de interface llamado endpoint, que permite a los beans de sesión sin estado actúar como un Servicio Web. Un interface endpoint simplemente implementar el interface javax.rmi.Remote (no es un tipo de objeto EJB) y cumple las reglas establecidas en la especificación JAX-RPC. Desplegar un bean de sesión sin estado como un Servicio Web es muy sencillo: sólo definimos la clase bean y un interface remoto, luego usamos las herramientas del vendedor para desplegarlo. Una vez que se ha desplegado el Servicio Web, se puede llamar a sus métodos desde calquier herramienta compatible con SOAP desde cualquier lenguaje o plataforma: .NET, Perl, Axis, C, C++ y otros.
JAXM y EJB
JAXM (Java API for XML Messaging) es un API de mensajería SOAP análogo a JMS (Java Message Service). Al igual que JMS es un API para enviar y recibir mensajes mediante una capa media orientada a mensajes, JAXM es un API para enviar y recibir mensajes mediante Servicios Web.
JAXM está orientado al documento; intercambia mensajes SOAP como documentos XML. Los clientes JAXM ensamblan, reciben y manipulan mensajes SOAP usando SAAJ (SOAP with Attachments API for Java), que modela la estructua XML real para un mensaje SOAP. Este mecanismo es muy diferente del de JAX-RPC, que usa semánticas de llamada a métodos y oculta la mensajería SOAP detrás de un proxy RMI Java. Con JAX-RPC vemos un interface remoto que sólo consta de métodos, parámetros y valores de retorno. Con JAXM, tratamos directamente con el protocolo SOAP y ensamblamos nuestros propios mensajes. Al igual que JAX-RPC, JAXM se puede utilizar para intercambiar mensajes SOAP coand cualquier Servicio Web compatible con SOAP. Por ejemplo, un bean enterprise podría usar JAXM para intercambiar mensajes SOAP con un Servicio Web escrito en Perl.
Los vendedores de EJB 2.1 pueden usar JAXM como la base para un nuevo tipo de bean dirigido a mensaje, el bean dirigido a mensaje basado en JAXM (JAXM-MDB). El JAXM-MDB consume mensajes SOAP y actúa como un Servicio Web. Un JAXM-MDB puede implementar un interface de una vía, lo que lo hace asíncrono, al igual que un bean dirigido a mensaje basado en JMS, o puede implementar un interface solicitud/respuesta, que lo hace como un Servicio Web síncrono. El nuevo JAXM-MDB es posible porque el componente bean dirigido a mensaje se ha generalizado para soportar cualquier clase de sistema de mensajes, no sólo JMS. Las poderosas capacidades que resultan son el objeto de la siguiente sección.
JAX-RPC y JAXM permiten a los beans enterprise acceder a Servicios Web sobre otras plataformas y sirve como base para los Servicios Web construidos con bean sin estado y dirigidos a mensaje. Estos API son flexibles y y bien diseñados para extender EJB dentro del paradigma de los Servicios Web.
Extender los Beans Dirigidos a Mensaje
EJB 2.0 presentó los beans dirigidos a mensajes, que podían procesar concurrente mensajes asíncronos desde proveedores de JMS (Java Message Service). En su diseño, los bean dirigidos a mensaje son, en mi opinión, los componentes más elegantes y poderosos. MDBs introdujo la comunidad EJB en la potencia de la mensajería asíncrona y cambió la forma en que la gente pensaba sobre la programación del lado del servidor.
EJB 2.1 extiende el modelo de programación elegante de los beans dirigidos a mensajes más allá de JMS a cualquier sistema de mensajería. Aunque los vendedores todavía deben soportat beans dirigidos a mensaje basados en JMS (JMS-MDBs), también están permitidos otros tipos de sistemas de mensajería. Por ejemplo, la mayoría de los vendedores, si no todos, soportará el bean dirigido a mensaje basado en JAXM. Puedo imaginar el soporte para otros tipos de protocolos de mensajería como SMTP para correo, SNMP para control de dispoisitivos, para protocolos peer-to-peer, mensajería instantánea, y otros muchos sistemas propietarios. Además, el bean dirigido a mensaje se ha convertido en una opción elegante para servir conexiones sistemas OLTP legales como CICS, IMS openUTM y otros.
Lo que es realmente excitante del nuevo componente bean dirigido a mensaje es que un componente de cualquier sistema de mensajería puede ser portable entre vendedores de EJB si está basado en la nueva arquitectura J2EE Connector Architecture (JCA 1.5), que define un modelo de programación portable para soportar sistemas de información empresariales. Por ejemplo, si un vendedor crea un nuevo componente bean dirigido a mensaje para SMTP que esté basado enJCA 1.5, este componente será portable a través de todos los servidores compatibles con EJB 2.1.
Enlace de Destinos
Una nueva característica interesante de EJB 2.1 que podría no captar el foco de atención es el enlace de destinos (destination linking). Hablando con simpleza, el enlace de destinos permite al contenedor EJB dirigir la salida de un servicio de mensajería (por ejemplo JMS o JAXM) a un destino que es la entrada de otro servicio o bean dirigido a mensaje. Como ejemplo, consideremos un bean de sesión sin estado que ya JMS para enviar un mensaje asíncrono a alguún destino. En tiempo de despliegue, el desarrollador puede enlazar ese destino a un bean dirigido a mensaje basado en JMS desplegado en el mismo sistema contenedor. Los enlaces de destinos permiten a los desarrolladores definir el fujo de mensajes durante el desplieguue, y así modelar un flujo de trabajo dentro de una plataforma empresarial.
El Servicio Timer
El servicio Timer es un sistema programador de tareas que se construye dentro del contenedor EJB. Un bean de sesión sin estado o un bean de entidad se pueden registrar dentro del Servicio Timer, y solicitar una notificación particular en un momento determinado o cuando haya expirado un periodo especificado.
Este servicio usa un modelo de programación muy sencillo. El bean debe implementar el interface TimedObject:
public interface javax.ejb.TimedObject {
public void ejbTimeout(Timer timer);
}
Cuando se acaba el tiempo del bean, el contenedor llamará a su método ejbTimeout(). Podemos poner cualquier tipo de lógica de negocio que queramos dentro del método ejbTimeout(). Por ejemplo, un bean de entidad que representa una factura podría tener un timer que se active después de 45 días. Cuando se pase este tiempo, el contenedor llamará al método ejbTimeout(). El bean de entidad de la factura podría enviar un mensaje JMA para alertar a una aplicación encargada de los cobros de que se ha pasado la fecha del pago, o envar al cliente un e-mail solicitándole el pago.
El objeto Timer que se ha pasado a ejbTimeout() incluye características que nos permiten cancelar un temporizador, encontrar el tiempo que nos queda antes de que se acabe, u obtener un manejador para hacerlo persistente. Ademas, cuando establecemos un objeto Timer podemos asociarlo con cualquier objeto serializable, y así almacenar información específica de la aplicación con él. Luego cuando se acabe el temporizador podremos acceder a esa información y utilizarla para determinar como procesar el evento disparado.
Al servicio Timer del contenedor EJB pueden acceder beans enterprise mediante el interface TimerService. Los beans de sesión sin estado deben utilizarlo para seleccionar sus propios temporizadores, primero obteniendo el acceso a él llamando al método EJBContext.getTimerService():
public interface
javax.ejb.TimerService {
public Timer createTimer(long duration,
java.io.Serializable info);
public Timer createTimer(long initialDuration,
long intervalDuration,
java.io.Serializable info);
public Timer createTimer(java.util.Date expiration,
java.io.Serializable info);
public Timer createTimer(java.util.Date initialExpiration,
long intervalDuration,
java.io.Serializable info);
public Collection getTimers();
}
Ya sabemos que podemos seleccionar un temporizador que se dispare una vez, después de cierta cantidad de tiempo o en una fecha especificada. También podemos hacer que se dispare más de una vez, a intervalor regulares. Por ejemplo, una método ejbCreate() de un bean de entidad de Facturas podría seleccionar un temporizador que se dispare cada 30 días. Un bean sin estado o de entiraad pueden configurar varios temporizadores, pero todos ellos serán procesados por el mismo método ejbTimeout( ). El método puede usar el objeto de información serializable para distinguir entre diferentes temporizadores.
Mejoras a EJB QL
EJB 2.1 presenta dos mejoras a EJB QL, principalmente la adición de la clausula ORDER BY y algunas nuevas funciones, que son mejoras bienvenidas.
La clausula ORDER BY
EJB QL ahora permite al desarrollador especificar un clausula ORDER BY en consultas EJB QL. Por ejemplo, para una aplicación A/R podemos crear una consulta que buque todos los beans Factura, y ordenarlos en primer lugar por la fecha en orde descendente y luego por el número de factura:
SELECT OBJECT( I )
FROM Invoice as I
ORDER BY I.date DESC, I.number
Este tipo de consultas se puede utilizar con cualquier método de búsqueda o selección del bean Factura (remoto o local). Observa que los dos identificadores de la clausula ORDER BY son expresiones de path, que termina en campos persistentes manejador por el contenedor (cmp-fields). Es importante entender que la causula ORDER BY sólo se puede aplicar a campos cmp-fields del EJB que ha sido seleccionado. Podemos uar DESC o ASC para especificar orden descendente o ascendente (por defecto utiliza el orden ascendente).
También podemos usar la clausula ORDER BY cuando buscamos cmp-fields en métodos select. Por ejemplo, esta consulta busca los nombre de los clientes que tienen facturas pendientes, ordenadas por el nombre:
SELECT DISTINCT I.customer.name
FROM Invoice as I
WHERE I.paid = FALSE
ORDER BY I.customer.name
Cuando una consulta EJB QL selecciona un cmp-field (en oposición a un bean de entirad) la clausula ORDER BY sólo se podría aplicar al campo cmp-field que aparece en la clausula SELECT. Por ejemplo, no podríamos seleccionar el nombre del cliente, como en el ejemplo anterior, y luego ordenar los resultados por fecha de creación de la factura.
Nuevas Funciones
EJB QL añade una nueva función a la clausula WHERE y cinco nuevas funciones a la clausula SELECT.
Además de las funciones CONCAT, SUBSTRING, LOCATE, LENGTH, ABS, y SQRT qe definió EJB 2.0 para la clausula WHERE, EJB 2.1 añade una función MOD.
EJB 2.1 tambien agrega cinco nuevas funciones a la clausual SELECT: AVG, COUNT, MAX, MIN, y SUM. Esta funcionan como las correspondientes funciones de SQL-92. Mientras que AVG y SUM sólo se pueden aplicar a campos números, las funciones COUNT, MAX, y MIN se pueden aplicar cualqueir campo cmp-field inclueyndo aquellos del tipo Date o String. COUNT también se puede aplicar a un campo cmr-field o a un identificador de EJB.
Por ejemplo, podemos definir una consulta que obtenga el número de facturas sin pagar. Observa que la función COUNT se refeire directamente al identificador, no usa la operación OBJECT( ):
SELECT COUNT( I )
FROM Invoice as I
WHERE I.paid = FALSE
También podemos obtener la SUM de EJBs Factura impagados:
SELECT SUM(I.total )
FROM Invoice as I
WHERE I.paid = FALSE