martes, 22 de enero de 2008

EJB3 (JBoss)

JBoss es un servidor de aplicaciones J2EE de código abierto implementado en Java puro. Al estar basado en Java, JBoss puede ser utilizado en cualquier sistema operativo que lo soporte. Los principales desarrolladores trabajan para una empresa de servicios, JBoss Inc., adquirida por Red Hat en Abril del 2006, fundada por Marc Fleury, el creador de la primera versión de JBoss. El proyecto está apoyado por una red mundial de colaboradores. Los ingresos de la empresa están basados en un modelo de negocio de servicios.

JBoss implementa todo el paquete de servicios de J2EE.



Los Enterprise JavaBeans (también conocidos por sus siglas EJB) son una de las API que forman parte del estándar de construcción de aplicaciones empresariales J2EE de Sun Microsystems (ahora JEE 5.0). Su especificación detalla cómo los servidores de aplicaciones proveen objetos desde el lado del servidor que son, precisamente, los EJBs:

  • comunicación remota utilizando CORBA
  • transacciones
  • control de la concurrencia
  • eventos utilizando JMS (Java messaging service)
  • servicios de nombres y de directorio
  • seguridad
  • ubicación de componentes en un servidor de aplicaciones.

La especificación de Enterprise Java Bean define los papeles jugados por el contenedor de EJB y los EJBs, además de disponer los EJBs en un contenedor.

Existen tres tipos de EJBs:

  • EJBs de Entidad (Entity EJBs): su objetivo es encapsular los objetos del lado del servidor que almacena los datos. Los EJBs de entidad presentan la característica fundamental de la persistencia:
    • Persistencia gestionada por el contenedor (CMP): el contenedor se encarga de almacenar y recuperar los datos del objeto de entidad mediante el mapeo de una tabla de la base de datos.
    • Persistencia gestionada por el bean (BMP): el propio objeto entidad se encarga, mediante una base de datos u otro mecanismo, de almacenar y recuperar los datos a los que se refiere, por lo cual, la responsabilidad de implementar los mecanismos de persistencia es del programador.
  • EJBs de Sesión (Session EJBs): gestionan el flujo de la información en el servidor. Generalmente sirven a los clientes como una fachada de los servicios proporcionados por otros componentes disponibles en el servidor. Puede haber dos tipos:
    • con estado (stateful). Los beans de sesión con estado son objetos distribuidos que poseen un estado. El estado no es persistente, pero el acceso al bean se limita a un solo cliente.
    • sin estado (stateless). Los beans de sesión sin estado son objetos distribuidos que carecen de estado asociado permitiendo por tanto que se los acceda concurrentemente. No se garantiza que los contenidos de las variables de instancia se conserven entre llamadas al método.
  • EJBs dirigidos por mensajes (Message-driven EJBs): son los únicos beans con funcionamiento asíncrono. Usando el Java Messaging System (JMS), se suscriben a un tema (topic) o a una cola (queue) y se activan al recibir un mensaje dirigido a dicho tema o cola. No requieren de su instanciación por parte del cliente.

La especificación EJB ha ido evolucionando a la par que lo hacía la propia especificación J2EE. Las diferentes versiones que han existido hasta la fecha son:

  • EJB 1.0: la especificación original
  • EJB 1.1: la primera incluida dentro de J2EE
  • EJB 2.0: incluida en J2EE 1.3, añadía las interfaces Locales y los Message-Driven beans.
  • EJB 2.1: incluida en la última revisión de J2EE, la 1.4.
  • EJB 3.0: Ahora con Cluster y esta incluida en JEE 5.0

Existe una propuesta de una nueva revisión de la especificación de Enterprise JavaBeans, la EJB 3.0, cuyo objetivo es simplificar la implementación de beans sin por ello sacrificar su potencia y flexibilidad.

La nueva especificación de EJB 3.0 simplifica el proceso de creación de EJB y facilita la implementación de persistencia.

Esta especificación estará disponible en la nueva versión de J2EE nombrada JEE 5.0.

1 comentario:

KB dijo...

Interesante documento. Una pregunta, cuando dices "EJB 3.0: Ahora con Cluster" ¿significa esto que ya no vamos a tener que utilizar distintos descriptores de despliegue para una misma aplicación en función de si va a ir o no en cluster?