Los EJB son componentes del contexto de servidor que cubren la necesidad de intermediar entre la capa web y diversos sistemas empresariales. En este sentido conviene releer la arquitectura J2EE para ver el papel de interfaz que juegan estos componentes. Los EJB nacen para encapsular la lógica de negocio de una forma integrada, no quedando dispersa su representación en una pléyade de sistemas empresariales. Los EJB están especialmente pensados para integrar la lógica de la empresa que se encuentra en sistemas distribuidos, de tal forma que el desarrollador no tenga que preocuparse por la programación a nivel de sistema (como control de transsacciones, seguridad, etc.), sino que se centre en la representación de entidades y reglas de negocio.

Un ejemplo, supongamos que necesitamos que nuestra web presente información del producto, tales como características técnicas, precio, productos relacionados, disponibilidad en stock, fecha de entrega estimada por parte del operador logístico, etc. El proceso sería:

• En el formulario HTML el usuario identifica el producto y el navegador llama a un JSP.



• El JSP recupera el código de identificación del producto (por ejemplo, mediante request.getParameter()) y lo envia al EJB.



• El EJB busca la información en bases de datos propias o ajenas (del fabricante, del operador logístico, etc.).

El estándar EJB especifica normas para la gestión de la transacción y para su seguridad, así como procedimientos de persistencia.

La tendencia apunta a que algunos de los EJB que tendremos en nuestras empresas sean componentes producidos por terceros, por ejemplo, componentes de integración de lógica de negocio que proveen los vendedores del ERP, CRM, etc. Incluso ocurre que el proveedor del EJB no sea el que te vende el contenedor de beans. Hay que diferenciar diversos roles que están surgiendo en el mercado:

• La empresa que produce el EJB.



• Los que lo distribuyen o despliegan.



• Aquellos que venden los contenedores y los servidores de EJB.



• Consultoras que integran/personalizan/configuran el componente, etc.

Dicho de forma preliminar y por resumir: un EJB es un conjunto de clases y un archivo XML que describe el despliegue de dichas clases en un contenedor de EJB. Un EJB se ejecuta en un contenedor de EJB y ofrece al desarrollador del bean servicios que no necesita progranar (persistencia, seguridad, etc.).

La especificación J2EE insiste en conseguir la reusabilidad, ya que el programador de EJB debe centrarse en los problemas de representación de entidades y relaciones de negocio, tratando de que los detalles más concretos, más dependientes de la plataforma o del sistema queden para el contenedor EJB.

Del lado servidor hay que distinquir una arquitectura:

El servidor es el recipiente y gestor de los contenedores de EJB. Los contenedores son el contexto donde se ejecutan los beans. El servidor debe ofrecer una serie de servicios:

• Servicio de acceso por nombres.
• Servicio de transacciones con otros servidores.
• Seguridad.
• Persistencia.

Los contenedores son el contexto de ejecución, que sirve de interfaz entre el bean y el servidor:

• Tienen herramientas para la generación y despliegue de los bean.



• Un servidor puede albergar a varios contenedores, pero un EJB sólo puede estar en un contenedor.



• Para los desarrolladores los servicios que ofrece el contenedor son transparentes, no necesita entrar en su modo interno de trabajo. Aparecen como servicios ofrecidos por servidor (transacciones, seguridad, etc.).

J2EE utiliza el API JNDI para acceder genéricamente a servicios de nombrado y directorio utilizando la tecnología Java. El API JNDI reside entre la aplicación y el servicio de nombres y hace que el servicio de nombres subyacente (RMI, CORBA, etc.) sea transparente para los componentes de la aplicación.

• Beans de sesión. Destinado a ser utilizado por un único cliente. Por ejemplo, para mostrar el cálculo consolidado de todas las inversiones realizadas por el cliente durante la sesión, para mantener un carrito de la compra, etc.



• Beans de entidad.
Son el eje central del modelo de datos, ya que se usan para acceder a las bases de datos. El bean de entidad gestiona la integridad de los datos persistentes, es decir, la consistencia entre los datos de memoria y los de la base de datos. Por ejemplo representa a los productos, categorías de productos, cliente, proveedor, cuenta, empleado, etc. Los datos persistentes pueden ser tratados por el propio bean (por medio de JDBC) o por el contenedor (el vendedor del contenedor ofrece este servicio). Mientras que los bean de sesión mueren con la sesión del cliente, los bean de entidad duran tanto como los correspondientes datos de la base de datos.


• Beans orientados al mensaje. Son invocados asíncronamente y utiliza el Java Message Service. Normalmente un cliente envía un mensaje a la cola del servicio JMS y todos los EJB asociados a la cola destino recibirán el mensaje.

Ya hemos dicho que los contenedores son los entornos de ejecución de los EJB. Pero ofrecen bastante más:

• Los contenedores ofrecen a los EJB servicios como los de persistencia (pool de conexiones, gestión de integridad, incluso evitar la codificación de SQL, etc), manejo de errores, seguridad, transacciones, etc. Una de las características más interesantes es que estos servicios se pueden definir de manera declarativa, por medio de su descriptor de despliegue. La idea es que el programador del EJB no tenga que comprometerse en COMO se consiguen estos servicios, sino sólo en QUE son (y como se declaran).



• El contenedor se interpone entre el cliente y el EJB, de tal forma que las llamadas al EJB se hacen por medio del contenedor. Recordando RMI:


• El cliente realiza una llamada que se dirige al Stub RMI



• El stub lee y envía los parámetros hacia la red



• Un skeleton recibe la llamada y decodifica (un-marshallin) los parámetros para enviarlos al contenedor.



• El contenedor controla la seguridad, persistencia (por ejemplo, llamando a la base de datos) y el manejo de transacciones.



• El contenedor invoca al EJB.

A partir de la especificación EJB 2.0 la interfaz remota no precisa de stubs y skeletons RMI.

A la hora de desarrollar un EJB es necesario definir:

• Un interfaz local, que es un conjunto de métodos para la creación, acceso y destrucción de las instancias de los beans (home objects). Este interfaz no está implementado en la propia clase bean, sino en el contenedor. Por ejemplo, define el método create() para instanciar la clase.



• A través del interfaz remoto se accede a los métodos de negocio (business methods), que han sido implementados en el bean.



• La clase bean define la lógica de negocio, a la que se accede a través del interfaz remoto.

Cuando el cliente llama a un método es el contenedor el que recibe la solicitud y la delega (reenvia) a la instancia de la clase.

Los servicios de transacciones, seguridad y persistencia ya dijimos que los gestiona el servidor, pero podría ocurrir que los gestionase el propio bean.

Accede a un ejemplo de EJB de entidad