EJB

EJB

Los Enterprise JavaBeans proporcionan un modelo de componentes distribuido estándar del lado del servidor. El objetivo de los EJB es dotar al programador de un modelo que le permita abstraerse de los problemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia, seguridad, etc.) para centrarse en el desarrollo de la lógica de negocio en sí. El hecho de estar basado en componentes permite que éstos sean flexibles y sobre todo reutilizables.

Requisitos para el funcionamiento de EJB

Para que los EJB puedan ser ejecutados, deben estar en un EJB Container (contenedor).

Desarrollo Basado en Componentes 

En esencia, un componente es una pieza de código preelaborado que encapsula alguna funcionalidad expuesta a través de interfaces estándar. Los componentes son los "ingredientes de las aplicaciones", que se juntan y combinan para llevar a cabo una tarea. 

El desarrollo de software basado en componentes permite reutilizar componentes que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión. 

Servicios de EJB

Los componentes EJB residen en un Contenedor EJB, el cual proporciona una capa de servicios añadidos. Los servicios que este incluye son: 

• Manejo de transacciones: apertura y cierre de transacciones asociadas a las llamadas a los métodos del bean.

• Seguridad: comprobación de permisos de acceso a los métodos del bean.

• Concurrencia: llamada simultánea a un mismo bean desde múltiples clientes.

• Servicios de red: comunicación entre el cliente y el bean en máquinas distintas.

• Gestión de recursos: gestión automática de múltiples recursos, como colas de mensajes, bases de datos o fuentes de datos en aplicaciones heredadas que no han sido traducidas a nuevos lenguajes/entornos y siguen usándose en la empresa.

• Persistencia: sincronización entre los datos del bean y tablas de una base de datos.

• Gestión de mensajes: manejo de Java Message Service (JMS).

• Escalabilidad: posibilidad de constituir clusters de servidores de aplicaciones con múltiples hosts para poder dar respuesta a aumentos repentinos de carga de la aplicación con sólo añadir hosts adicionales.

• Adaptación en tiempo de despliegue: posibilidad de modificación de todas estas características en el momento del despliegue del bean.

Funcionamiento EJB

El funcionamiento de los componentes EJB se basa fundamentalmente en el trabajo del contenedor EJB. El contenedor EJB es un programa Java que corre en el servidor y que contiene todas las clases y objetos necesarios para el correcto funcionamiento de los enterprise beans.

En la figura puedes ver una representación de muy alto nivel del funcionamiento básico de los enterprise beans. En primer lugar, puedes ver que el cliente que realiza peticiones al bean y el servidor que contiene el bean están ejecutándose en máquinas virtuales Java distintas. Incluso pueden estar en distintos hosts. Otra cosa a resaltar es que el cliente nunca se comunica directamente con el enterprise bean, sino que el contenedor EJB proporciona unEJBObject que hace de interfaz. Cualquier petición del cliente (una llamada a un método de negocio del enterprise bean) se debe hacer a través del objeto EJB, el cual solicita al contenedor EJB una serie de servicios y se comunica con el enterprise bean. Por último, el bean realiza las peticiones correspondientes a la base de datos.
El contenedor EJB se preocupa de cuestiones como:

• ¿Tiene el cliente permiso para llamar al método?

• Hay que abrir la transacción al comienzo de la llamada y cerrarla al terminar.

• ¿Es necesario refrescar el bean con los datos de la base de datos?

Tipos de Beans

La tecnología EJB define tres tipos de beans: beans de sesión, beans de entidad y beans dirigidos por mensajes.

• beans de entidad (entity beans) representan un objeto concreto que tiene existencia en alguna base de datos de la empresa. Una instancia de un bean de entidad representa una fila en una tabla de la base de datos. Por ejemplo, podríamos considerar el bean Cliente, con una instancia del bean siendo Eva Martínez (ID# 342) y otra instancia Francisco Gómez (ID# 120).
  
• beans dirigidos por mensajes (message-driven beans) pueden escuchar mensajes de un servicio de mensajes JMS. Los clientes de estos beans nunca los llaman directamente, sino que es necesario enviar un mensaje JMS para comunicarse con ellos. Los beans dirigidos por mensajes no necesitan objetos EJBObject porque los clientes no se comunican nunca con ellos directamente. Un ejemplo de bean dirigido por mensajes podría ser un bean ListenerNuevoCliente que se activara cada vez que se envía un mensaje comunicando que se ha dado de alta a un nuevo cliente.
  
• bean de sesión (session beans) representan un proceso o una acción de negocio. Normalmente, cualquier llamada a un servicio del servidor debería comenzar con una llamada a un bean de sesión. Mientras que un bean de entidad representa una cosa que se puede representar con un nombre, al pensar en un bean de sesión deberías pensar en un verbo.

Desarrollo de Beans

El desarrollo y programación de los beans suele ser un proceso bastante similar sea cual sea el tipo de bean. Consta de los siguientes 5 pasos:

1. Escribe y compila la clase bean que contiene a todos los métodos de negocio.
2. Escribe y compila las dos interfaces del bean: home y componente.
3. Crea un descriptor XML del despliegue en el que se describa qué es el bean y cómo debe manejarse. Este fichero debe llamarse ejb-jar.xml.
4. Pon la clase bean, los interfaces y el descriptor XML del despliegue en un fichero EJB JAR . Podría haber más de un bean el mismo fichero EJB JAR, pero nunca habrá más de un descriptor de despliegue.
5. Despliega el bean en el servidor usando las herramientas proporcionadas por el servidor de aplicaciones.

Clientes de los Beans

Una vez que el bean está desplegado en el contenedor, ya podemos usarlo desde un cliente. El cliente puede ser una clase Java cualquiera, ya sea un cliente aislado o un servlet que se está ejecutando en el contenedor web del servidor de aplicaciones. El código que deben ejecutar los clientes del bean es básicamente el mismo en cualquier caso.

Básicamente, el cliente debe realizar siempre las siguientes tareas:

1. Acceder al servicio JNDI, obteniendo el contexto JNDI inicial. Para ello se llama a la función javax.naming.InitialContext(), pasándole como argumento unas propiedades dependientes del servidor que implementa el JNDI. En este caso estamos asumiendo que el servicio JNDI lo proporciona un servidor de aplicaciones BEA weblogic que está ejecutándose en el localhost.
2. Localizar el bean proporcionando a JNDI su nombre lógico. En este caso, el nombre JNDI del bean es SaludoBean.
3. Hacer un casting del objeto que devuelve JNDI para convertirlo en un objeto. La forma de hacer el casting es especial, ya que antes de hacer el casting hay que obtener un objeto Java llamando al método PotableRemoteObject.narrow() porque estamos recibiendo de JNDI un objeto que ha sido serializado usando el protocolo IIOP.
4. Llamar al método create() del objeto home para crear un objeto de tipo Saludo. Lo que se obtiene es un stub (ya hablaremos más de ello en la siguiente sesión) y hay que llamar otra vez a narrow para asegurarse de que el objeto devuelto satisface
5. Llamar a los métodos de negocio del bean.

Ventajas de EJB

La arquitectura EJB proporciona beneficios a todos los papeles que hemos mencionado previamente (desarrolladores, ensambladores de aplicaciones, administradores, desplegadores, fabricantes de servidores). Vamos en enumerar las ventajas que obtendrán los desarrolladores de aplicaciones y los clientes finales.

Las ventajas que ofrece la arquitectura Enterprise JavaBeans a un desarrollador de aplicaciones se listan a continuación.

• Simplicidad. Debido a que el contenedor de aplicaciones libera al programador de realizar las tareas del nivel del sistema, la escritura de un enterprise bean es casi tan sencilla como la escritura de una clase Java. El desarrollador no tiene que preocuparse de temas de nivel de sistema como la seguridad, transacciones, multi-threading o la programación distribuida. Como resultado, el desarrollador de aplicaciones se concentra en la lógica de negocio y en el dominio específico de la aplicación.

• Portabilidad de la aplicación. Una aplicación EJB puede ser desplegada en cualquier servidor de aplicaciones que soporte J2EE. 

• Reusabilidad de componentes. Una aplicación EJB está formada por componentes enterprise beans. Cada enterprise bean es un bloque de construcción reusable. Hay dos formas esenciales de reusar un enterprise bean a nivel de desarrollo y a nivel de aplicación cliente. Un bean desarrollado puede desplegarse en distintas aplicaciones, adaptando sus características a las necesidades de las mismas. También un bean desplegado puede ser usado por múltiples aplicaciones cliente.

• Posibilidad de construcción de aplicaciones complejas. La arquitectura EJB simplifica la construcción de aplicaciones complejas. Al estar basada en componentes y en un conjunto claro y bien establecido de interfaces, se facilita el desarrollo en equipo de la aplicación.

• Separación de la lógica de presentación de la lógica de negocio. Un enterprise bean encapsula típicamente un proceso o una entidad de negocio. (un objeto que representa datos del negocio), haciéndolo independiente de la lógica de presentación. El programador de gestión no necesita de preocuparse de cómo formatear la salida; será el programador que desarrolle la página Web el que se ocupe de ello usando los datos de salida que proporcionará el bean. Esta separación hace posible desarrollar distintas lógicas de presentación para la misma lógica de negocio o cambiar la lógica de presentación sin modificar el código que implementa el proceso de negocio.

• Despliegue en muchos entornos operativos. Entendemos por entornos operativos el conjunto de aplicaciones y sistemas (bases de datos, sistemas operativos, aplicaciones ya en marcha, etc.) que están instaladas en una empresa. Al detallarse claramente todas las posibilidades de despliegue de las aplicaciones, se facilita el desarrollo de herramientas que asistan y automaticen este proceso. La arquitectura permite que los beans de entidad se conecten a distintos tipos de sistemas de bases de datos.

• Despliegue distribuido. La arquitectura EJB hace posible que las aplicaciones se desplieguen de forma distribuida entre distintos servidores de una red. El desarrollador de beans no necesita considerar la topología del despliegue. Escribe el mismo código independientemente de si el bean se va a desplegar en una máquina o en otra (cuidado: con la especificación 2.0 esto se modifica ligeramente, al introducirse la posibilidad de los interfaces locales).

• Interoperabilidad entre aplicaciones. La arquitectura EJB hace más fácil la integración de múltiples aplicaciones de diferentes vendedores. El interfaz del enterprise bean con el cliente sirve como un punto bien definido de integración entre aplicaciones.

• Integración con sistemas no-Java. Las APIs relacionadas, como las especificaciones Connector y Java Message Service (JMS), así como los beans manejados por mensajes, hacen posible la integración de los enterprise beans con sistemas no Java, como sistemas ERP o aplicaciones mainframes.

• Recursos educativos y herramientas de desarrollo. El hecho de que la especificación EJB sea un estándar hace que exista una creciente oferta de herramientas y formación que facilita el trabajo del desarrollador de aplicaciones EJB.

• Elección del servidor. Debido a que las aplicaciones EJB pueden ser ejecutadas en cualquier servidor J2EE, el cliente no queda ligado a un vendedor de servidores. Antes de que existiera la arquitectura EJB era muy difícil que una aplicación desarrollada para una determinada capa intermedia (Tuxedo, por ejemplo) pudiera portarse a otro servidor. Con la arquitectura EJB, sin embargo, el cliente deja de estar atado a un vendedor y puede cambiar de servidor cuando sus necesidades de escalabilidad, integración, precio, seguridad, etc.lo requieran. 

• Existen en el mercado algunos servidores de aplicaciones gratuitos (JBOSS, el servidor de aplicaciones de Sun, etc.) con los que sería posible hacer unas primeras pruebas del sistema, para después pasar a un servidor de aplicaciones con más funcionalidades.

• Gestión de las aplicaciones. Las aplicaciones son mucho más sencillas de manejar (arrancar, parar, configurar, etc.) debido a que existen herramientas de control más elaboradas.

• Integración con aplicaciones y datos ya existentes. La arquitectura EJB y otras APIs de J2EE simplifican y estandarizan la integración de aplicaciones EJB con aplicaciones no Java y sistemas en el entorno operativo del cliente. Por ejemplo, un cliente no tiene que cambiar un esquema de base de datos para encajar en una aplicación. En lugar de ello, se puede construir una aplicación EJB que encaje en el esquema cuando sea desplegada.

• Seguridad. La arquitectura EJB traslada la mayor parte de la responsabilidad de la seguridad de una aplicación de el desarrollador de aplicaciones al vendedor del servidor, el Administrador de Sistemas y al Desplegador (papeles de la especificación EJB) La gente que ejecuta esos papeles están más cualificados que el desarrollador de aplicaciones para hacer segura la aplicación. Esto lleva a una mejor seguridad en las aplicaciones operacionales.

Entre las ventajas que aporta esta arquitectura al cliente final, destacamos la posibilidad de elección del servidor, la mejora en la gestión de las aplicaciones, la integración con las aplicaciones y datos ya existentes y la seguridad.

Stateful y Stateless Beans 

Un bean de sesión con estado (stateful) puede mantener datos entre las diferentes peticiones de un cliente, pero no ocurre así con un bean de sesión sin estado (stateless).

Se recomienda el uso de stateful cuando se cumpla una de las siguientes situaciones:

• El estado del bean representa la interacción entre el bean y un cliente específico.

• El bean necesita mantener información acerca del cliente a lo largo de varias invocaciones de métodos.

• El bean es mediador entre el cliente y los otros componentes de la aplicación, presentando una vista simplificada para el cliente.

Tras bambalinas, el bean maneja el control de flujo de muchos otros enterprise beans. Para incrementar el rendimiento, se podrían utilizar stateless session bean en alguna de las siguientes situaciones:

• El estado del bean no tiene datos para un cliente en específico.

• En un único método de invocación, el bean realiza una tarea genérica para todos los clientes. Por ejemplo, se podría utilizar un stateless session bean para mandar un email que confirme una compra online.

• El bean implementa un servicio web.

Los singleton session bean son apropiados en las siguientes circunstancias:

• El estado necesita ser compartido a través de la aplicación.

• Un único enterprise bean necesita ser accedido por múltiples hebras concurrentemente.