JavaBeans Enterprise

La especificación Enterprise JavaBeans define una arquitectura para un sistema de objetos transaccionales distribuidos basado en componentes. La especificación obliga a un modelo de programación; es decir, convenciones o protocolos y un conjunto de clases e interfaces que componen el API EJB. El modelo de programación EJB proporciona a los desarrolladores y a los vendedores de servidores EJB con un conjunto de contratos que definen una plataforma común para el desarrollo. El objetivo de estos contratos es asegurarse la portabilidad entre vendedores mientras soporta un rico conjunto de funcionalidades.

El Contenedor EJB

Los beans Enterprise son componentes software que se ejecutan en un entorno especial llamado contenedor EJB. El contenedor hospeda y maneja un bean enterprise de la misma forma en un servidor de aplicaciones Java hospeda un servlet o un servidor HTML hospeda una applet Java. Un bean enterprise no puede funcionar fuera de un contenedor EJB. El contenedor EJB maneja todos los aspectos de un bean enterprise en tiempo de ejecución incluyendo los accesos remotos al bean, la seguridad, la persistencia, las transacciones, la concurrencia y el acceso y almacenamiento de recursos.

El contenedor aísla el bean enterprise del acceso directo desde las aplicaciones clientes. Cuando una aplicación cliente llama a un método remoto de un bean enterprise, el contenedor primero intercepta la llamada para asegurarse de que la persistencia, las transacciones, y la seguridad se aplican apropiadamente para cada operación que realice el cliente sobre el bean. El contenedor maneja todo esto automáticamente por el bean, para que el desarrollador de beans no tenga que escribir este tipo de lógica en el propio código del bean. El desarrollador de beans enterprise se puede enfocar en la encapsulación de las reglas de negocio, mientras el contenedor tiene cuidado de todo lo demás.

Los contenedores manejaran muchos bean simultáneamente de la misma forma que Tomcat maneja muchos servlets. Para reducir el consumo de memoria y de procesador, los contenedores almacenan recursos y manejan el ciclo de vida de todos los beans muy cuidadosamente. Cuando un bean no está siendo utilizado, un contenedor lo situará en un almacén para que sea reutilizado por otros clientes, o posiblemente lo sacará de la memoria y sólo lo traerá de vuelta si es necesario. Como las aplicaciones clientes no tienen acceso directo al bean--el contenedor trata entre el cliente y el bean-- la aplicación cliente está completamente despreocupada de las actividades de control de recurso de los contenedores. Un bean que no está en uso, por ejemplo, podría ser sacado de la memoria del servidor, aunque su referencia remota en el cliente permanezca intacta. Cuando el cliente llama una método del interface remoto, el contenedor simplemente re-encarna el bean para servir la petición. Las aplicaciones cliente se despreocupan de todo el proceso.

Un bean enterprise depende del contenedor para todo lo que necesita. Si un bean enterprise necesita acceder a una conexión JDBC o a otro bean enterprise, lo hace a través del contenedor; si un bean enterprise necesita acceder a la identidad de su llamador, obtener una referencia a sí mismo, o acceder a las propiedades lo hace a través del contenedor. El bean enterprise interactúa con su contenedor a través de tres mecanismos: métodos de retrollamadas, el interface EJBContext,y el Interface de Nombres y Directorio Java (JNDI).

• Métodos de retrollamada (callbacks)
  
  

Todo bean implementa un subtipo del interface EnterpriseBean que define varios métodos, llamados métodos de retrollamada. Cada uno de estos métodos alerta al bean SOBRE un evento diferente en su ciclo de vida y el contenedor llamará a estos métodos para notificar al bean cuando va a ser activado, cuando va a persistir su estado en la base de datos, finalizar una transacción, eliminar el bean de la memoria, etc. Los métodos de retrollamada le dan al bean una oportunidad para hacer algún trabajo casero inmediatamente antes o después de algún evento.

• EJBContext
  
  

Todo bean obtiene un objeto EJBContext, que es una referencia directa a su contenedor. El interface EJBContext proporciona métodos para interactuar directamente con el contenedor para que el bean pueda solicitar información sobre su estado como la identidad de sus clientes, el estado de una transacción, u obtener referencias remotas a sí mismo.

• Java Naming and Directory Interface (JNDI)
  
  

Es una extensión estándar de la plataforma Java para acceder a sistemas de nombres como LDAP, NetWare, sistemas de ficheros, etc. Todo bean tiene acceso automático a un sistema de nombres especial llamado Environment Naming Context (ENC). El ENC es manejado por el contenedor y es accedido por los beans usando JNDI. El JNDI ENC permite a un bean acceder a recursos como conexiones JDBC, otros beans enterprise, y a propiedades específicas de ese bean. 

La especificación EJB define un contrato bean-contenedor, que incluye los mecanismos (callbacks, EJBContext, JNDI ENC) descritos arriba, así como un estricto conjunto de reglas que describen cómo se comportan en tiempo de ejecución los beans enterprise y sus contenedores, cómo se chequean los accesos de seguridad, cómo se manejan las transacciones, y cómo se aplica la persistencia, etc. Este contrato está diseñado para hacer que los beans enterprise sean portables entre contenedores EJB.

La portabilidad es el valor principal que ponen los EJB encima de la mesa. La portabilidad asegura que un bean desarrollado para un contenedor podrá migrarse a otro si éste último ofrece más rendimiento, más características o un menor coste.

Además de la portabilidad, la simplicidad de los modelos de programación EJB los hace muy valiosos. Como el contenedor realiza todas la tareas complejas como la seguridad, las transacciones, las persistencia, la concurrencia y el control de recursos, el desarrollador del bean está liberado para enfocar su atención en la reglas de negocio y en un modelo de programación muy sencillo.

Para crear un componente EJB del lado del servidor, un desarrollador de beans proporciona dos interfaces que definen los métodos de negocio, además de la implementación real de la clase bean. Entonces el cliente usa un interface público del bean para crear, manipular o eliminar bean del servidor EJB. La implementación de la clase, para ser llamada la clase bean, es ejemplarizada en tiempo de ejecución y se convierte en un objeto distribuido.

Los beans enterprise viven en un contenedor EJB y son accedidos por aplicaciones clientes sobre la red a través de sus interfaces remote y home. Estos interfaces exponen las capacidades del bean y proporcionan todos los métodos necesarios para crear, actualizar, interactuar y borrar el bean. Un bean es un componente del lado del servidor que representa conceptos de negocio como un Cliente o un Cajero de Hotel.

Los interfaces Remote y Home

Los interfaces remote y home representan el bean, pero el contenedor aísla los beans de los acceso directos desde las aplicaciones cliente. Cada vez que se solicita, se crea o se borra un bean, el contenedor maneja todo el proceso.

El interface home representa los métodos del ciclo de vida del componente (create, destroy, find) mientras que el interface remote representa los métodos de negocio del bean. Los interfaces remote y home extienden los interfacesjavax.ejb.EJBObject y javax.ejb.EJBHome respectivamente. Estos tipos de interfaces EJB definen un conjunto de métodos de utilidad estándares y proporcionan tipos básicos comunes para todos los interfaces remote y home.

Los clientes usan el interface home para obtener referencias al interface remote del bean. El interface remote define los métodos de negocios como métodos de acceso o método mutadores para cambiar el nombre de un cliente, o método de negocio que realizan tareas como usar el bean CajeroDeHotel para reservar una habitación en un hotel. Aquí tenemos un ejemplo de cómo un bean Cliente podría ser accedido desde una aplicación cliente. En este caso el interface home es del tipo ClienteHome y el interface remoto es el tipo Cliente:

El interface remoto define los métodos de negocio de un bean; los métodos que son específicos para el concepto de negocio que representa. Los interfaces remotos son subclases de javax.ejb.EJBObject que es una subclase del interface java.rmi.Remote. La importancia de la herencia de los interfaces remotos se explicará más tarde. Por ahora nos enfocaremos en los métodos de negocio y sus significados. Aquí tenemos una definición del interface remoto para un bean Cliente:

El interface remoto define los métodos para acceder y métodos para leer y actualizar información sobre un concepto del negocio. Este un típico tipo de bean llamado bean de entidad, que representa un objeto de negocio persistente; objetos de negocio cuyos datos se almacenan en una base de datos. Los beans de entidad representan datos del negocio en la base de datos y añaden comportamiento específico para esos datos.

Métodos de Negocio

Los métodos de negocio también pueden representar tareas que un bean realiza. Aunque un bean de entidad normalmente tiene métodos orientados a tareas, las tareas son más típicas de un tipo de bean llamado bean de sesión. Los beans de sesión no representan datos como los beans de entidad. Representan procesos del negocio o agentes que realizan un servicio, como hacer una reserva en un Hotel. Aquí tenemos la definición del interface remoto de un bean CajeroDeHotel, que es un tipo de bean de sesión:

Los métodos de negocio definidos en el interface remoto de CajeroDeHotel representan proceso en vez de simples métodos de acceso. El bean CajeroDeHotel actúa como un agente en el sentido en que realiza tareas por cuenta del usuario, pero él mismo no persiste en la base de datos. No necesitamos información sobre el CajeroDeHotel, sólo necesitamos que haga las tareas que queremos que haga. Este es el comportamiento típico de un bean de sesión.

Hay dos tipos básicos de beans enterprise: beans de entidad, que representan datos en una base de datos, y beans de sesión, que representan procesos o actúan como agentes que realizan tareas. Cuando construyamos aplicaciones EJB crearemos muchos beans enterprise, cada uno representando un concepto de negocio diferente. Cada concepto de negocio se manifestará como un bean de entidad o como un bean de sesión. Elegiremos el tipo de bean adecuado dependiendo de lo que queramos que haga.

Beans de Entidad

Por cada interface remoto hay una clase que lo implementa; un objeto de negocio que realmente implementa los métodos de negocio definidos en el interface remoto. Esta es la clase bean; el elemento clave del bean. Aquí tenemos una definición parcial de la clase del bean Cliente:

ClienteBean es la clase de implementación. Contiene los datos y proporciona los métodos de acceso y otros métodos de negocio. Como es un bean de entidad, el ClienteBean proporciona una vista de los datos del cliente. En lugar de escribir lógica de acceso a la base de datos en la aplicación, la aplicación simplemente puede usar el interface remoto del bean Cliente para acceder a los datos del cliente. Los beans de entidad implementan el tipo javax.ejb.EntityBean que se define como un conjunto de método de notificación que el bean usa para interactuar con su contenedor. Estos métodos de notificación se examinarán más adelante en este curso:

Beans de Sesión

El bean CajeroDeHotel es un bean de sesión, que es similar en muchos aspectos a un bean de entidad. Los beans de sesión representan un conjunto de proceso o tareas, que son realizadas por cuenta de la aplicación cliente. Los beans de sesión podrían usar otros beans para usar tareas o acceder directamente a bases de datos. Un poco más de código muestra un bean de sesión haciendo ambas cosas. El método reservaHabitacon() usa otros beans para realizar una tareas, mientras que HabitacionDisponible() usa JDBC para acceder directamente a la base de datos.

Podrías observar que las clases bean definidas arriba no implementan interfaces home o remote. EJB no requiere que la clase bean implemente estos interfaces; de hecho está desaconsejado porque el tipo base de los interface remote y home (EJBObject y EJBHome) definen muchos otros métodos que son implementados automáticamente por el contenedor. Sin embargo, la clase bean debe proporcionar implementaciones para todos los métodos de negocio definidos en el interface remoto.

Métodos del Ciclo de Vida

Además de un interface remoto, todos los beans tienen un interface Home. El interface Home proporciona los métodos de ciclo de vida para crear, destruir y localizar beans. Estos comportamientos de ciclo de vida están separados del interface remoto porque representan comportamientos que no son específicos de un sólo ejemplar del bean. Aquí tenemos la definición del interface home del bean Cliente. Observa que extiende el interface javax.ejb.EJBHome que a su vez extiende el interface java.rmi.Remote:

El método create() se usa para crear una nueva entidad. Esto resultará en un nuevo registro de la base de datos. Un home podría tener muchos métodos create(). El número y tipo de datos de los argumentos de cada método create() se dejan para el desarrollador del bean, pero el tipo de retorno debe ser el tipo de dato del interface remoto. En este caso, llamar a create() sobre el interface ClienteHome devolverá un ejemplar de Customer. Los métodos findByPrimaryKey() y findByZipCode() se usan para localizar un ejemplar específico del bean Cliente. De nuevo, podríamos definir tantos métodos de búsqueda como sean necesarios.

De vuelta a los Interface Remote y Home

Los interfaces remote y home los usan las aplicaciones para acceder a beans enterprise en tiempo de ejecución. El interface home permite a la aplicación crear o localizar un bean, mientras que el interface remote permite a la aplicación llamara a los métodos de negocio del bean:

El interface javax.ejb.EJBHome también define otros métodos que hereda automáticamente el bean ClienteBean, incluyendo un conjunto de métodos remove() que permiten a la aplicación destruir ejemplares del bean.

Los interfaces remote y home son tipos de interfaces Java RMI Remote. El Interface java.rmi.Remote es utilizado por objetos distribuidos para representar el bean en un espacio de direccionamiento diferente (proceso o máquina). Un bean enterprise es un objeto distribuido. Lo que significa que la clase bean es ejemplarizada y vive en el contenedor pero puede ser accedida por aplicaciones que viven en otros espacios de direccionamiento.

Para hacer que un ejemplar de un objeto de un espacio de direccionamiento esté disponible en otro espacio se requiere un pequeño truco que implica sockets de red. Para hacer que el truco funcione, envolvemos el ejemplar en un objeto espacial llamado un esqueleto que es una conexión de red a otro objeto especial llamado stub. El stub implementa el interface remoto por lo que parece un objeto de negocio. Pero el stub no contiene lógica de negocio; contiene una conexión de red socket al esqueleto. Cada vez que se llama a un método de negocio sobre el interface remoto del stub, éste envía un mensaje de red al esqueleto diciendo el método que fue invocado. Cuando el esqueleto recibe un mensaje de red desde el stub, identifica el método invocado y los argumentos, y luego llama al método correspondiente del ejemplar real. El ejemplar ejecuta el método de negocios y devuelve el resultado al esqueleto, que lo envía al stub.

El stub devuelve el resultado a la aplicación que invocó su método del interface remoto. Desde la perspectiva la aplicación que usa el stub, parece como si el stub no funcionará localmente. Realmente, el stub es sólo un objeto volcado en la red que envía peticiones a través de la red al esqueleto, que a su vez llama al método del ejemplar real. El ejemplar hace todo el trabajo, el stub y el esqueleto sólo pasan la identidad del método y los argumentos a través de la red.

En EJB, el esqueleto para los interfaces home y remote están implementados por el contenedor, no por la clase bean. Esto es para asegurar que todo método llamado sobre estos tipos de referencia por una aplicación cliente primero es manejado por el contenedor y luego delegado al ejemplar del bean. El contenedor debe interceptar esas peticiones hacia el bean para poder aplicar automáticamente la persistencia (beans de entidad), las transacciones, y el control de acceso.

Los protocolos de objetos distribuidos definen el formato de los mensajes de red enviados entre espacios de direcciones. Los protocolos de objetos distribuidos son bastantes complicados, pero afortunadamente no los vemos porque son manejados automáticamente. La mayoría de los servidores EJB soportan Java Remote Method Protocol (JRMP) o Internet Inter-ORB Protocol (IIOP) de CORBA. El programador del bean y el de la aplicación sólo ven la clase bean y su interface remoto, los detalles de la comunicación en red permanecen ocultos.

Con respecto al API EJB, el programador no debe preocuparse de si el EJB usa JRMP o IIOP--el API es el mismo. La especificación EJB requiere que usemos una versión especializada del API Java RMI, cuando trabajamos con un bean de forma remota. Java RMI es un API para acceder a objetos distribuidos y de alguna forma es un protocolo agnóstico--de la misma forma que JDBC es una base de datos agnóstica. Por eso, un servidor EJB, puede soportar JRMP o IIOP, pero el desarrollador del bean y de la aplicación siempre usa el mismo API Java RMI. Para que el servidor EJB tenga la opción de soportar IIOP, se ha desarrollado una versión especializada de Java RMI, llamada Java RMI-IIOP. Java RMIO-IIOP usa IIOP como protocolo y el API Java RMI. Los servidores EJB no tienen que usar IIOP. pero tienen respetar las restricciones Java RMI-IIOP, porque EJB 1.1 usa las convenciones Java RMI-IIOP especializado, pero el protocolo subyacente puede ser cualquiera.