Tras crear el proyecto Java™ o EJB, puede crear beans de sesión, beans de entidad y beans gestionados por mensajes para añadirlos al proyecto.
Enterprise beans
Un enterprise bean es un componente Java que se puede combinar con otros recursos para crear aplicaciones Java. Existen tres tipos de enterprise
beans: beans de entidad, beans de sesión y beans controlados por
mensaje. Todos los beans residen en contenedores EJB (Enterprise Java beans JavaBeans), que proporcionan una interfaz entre los beans y el servidor de aplicaciones en el que se encuentran.
La especificación EJB 3.1 deja en desuso los beans de entidad de estilo EJB 1.1.
La especificación JPA (Java Persistence API) pretende sustituir a los enterprise beans en desuso.
Mientras que la sustitución de JPA se denomina una clase de entidad, no se debe confundir con los enterprise beans de entidad. Una entidad JPA no es un enterprise bean ni es necesario que se ejecute
en un contenedor EJB.
También puede crear beans de la versión 3.0 y 3.1 de EJB en proyectos Web 3.0.
Anotaciones que definen el componente
Con la utilización de anotaciones de definición de componente, puede crear los tipos de enterprise bean siguientes: beans de sesión, beans controlado por mensajes y entidades JPA. La inclusión de la anotación de definición de componente @Stateful, @Stateless indica que la clase es una clase de bean de sesión;
la inclusión de la anotación de definición de componente @Singleton indica que la clase es una clase
singleton; y la inclusión de la anotación de definición de componente @MessageDriven indica que la clase es una clase bean controlado por mensaje; y la inclusión de la anotación de definición de componente @Entity indica que la clase es una entidad JPA.
- Beans de sesión: Como mínimo, un bean de sesión desarrollado con la especificación EJB 3.1 requiere una clase de bean.
- Con estado: un bean de sesión con estado mantiene información de sesión específica del cliente o estado conversacional a través de varias llamadas a método y transacciones.
Una instancia de bean de sesión con estado tiene una identidad exclusiva que el
contenedor asigna durante la creación.
- Sin estado: un bean de sesión sin estado no mantiene estado conversacional.
Instancias de bean de sesión sin estado no tienen estado conversacional.
Dado que un EJB de sesión sin estado no mantiene un estado conversacional, todos los datos intercambiados entre el cliente y el EJB deben pasarse como parámetros de entrada, o bien como valor de retorno, declarados en la interfaz de método empresarial EJB.
Todas las instancias de un bean de sesión sin estado tienen el mismo identificador de
objeto, que el contenedor asigna.
- Singleton: Los beans de sesión singleton, nuevos en EJB 3.1, son un nuevo tipo de bean de sesión que tiene garantizada una creación de instancias para una aplicación en una Java Virtual Machine (JVM) concreta. Los singletons ofrecen una funcionalidad
similar a los beans de sesión sin estado pero difieren de ellos en que solamente hay un bean de sesión sin estado por aplicación, contrariamente a una agrupación de beans de sesión sin estado, ninguno de los cuales puede responder a una solicitud de cliente. Al igual que los beans de sesión sin estado, los beans de sesión de singleton pueden implementar puntos finales de servicio web. Los beans de sesión singleton mantienen su estado entre invocaciones de cliente, pero no es necesario que mantengan su estado cuando el servidor se cuelga o se cierra.
- Beans controlados por mensajes: los Beans controlados por mensajes se introdujeron en la versión 2.0 de
EJB para dar soporte al proceso de mensajes asíncronos desde un JMS (Java Message Service). La especificación EJB 2.1 amplía la definición del bean controlador por mensajes de forma que pueda dar soporte a cualquier sistema de mensajería, no sólo a JMS.
En términos más simples, un bean gestionado por mensajes es un consumidor de mensajes al que se puede llamar desde su contenedor. Los invoca el contenedor cuando llega un mensaje. Los beans gestionados por mensajes constituyen otro mecanismo de interacción para invocar beans EJB, pero a diferencia de los beans de sesión, el contenedor es el responsable de invocarlos cuando se recibe un mensaje, no un cliente (u otro bean).
- Entidades que utiliza Java Persistence API (JPA): Entidades que utilizas la nueva
Java Persistence API que forma parte de la plataforma Java EE
5. Al contrario que los componentes EJB que utilizan la persistencia gestionada por contenedor (CMP), los objetos de entidad que utilizan las API nuevas ya no son componentes sino simples objetos Java.
Esto hace que las entidades sean más ligeras y que el modelo de programación sea más fácil de utilizar. Para obtener más información sobre JPA, consulte Documentación JPA.
Directrices para desarrollar beans EJB
Mientras que la versión 3.1 de EJB proporciona un modelo de programación flexible y simple, aquí encontrará algunas de las normas sugeridas para desarrollar los EJB:
- Cada entidad debe ser un POJO y la clase debe ser concreta (por tanto, ni abstracta ni final).
- La clase debe tener un constructor sin argumentos; si no hay ninguno, el compilador añade un constructor predeterminado
- POJO debe implementar al menos una POJI (interfaz Java de formato antiguo); no es necesario que incluya ninguna interfaz, pero puede incluir diversas interfaces para los clientes locales y remotos.
- Si la interfaz de empresa incluye una anotación @Remote, todos los parámetros declarados en la interfaz deben implementar
java.io.Serializable.
- Un EJB de sesión puede tener un POJO como subclase, pero no puede tener otro bean de sesión como subclase.
Puede crear enterprise beans de las siguientes formas:
- Creando enterprise beans con asistentes.
- Creando enterprise beans con anotaciones Java EE.
- Importando enterprise beans desde archivos JAR EJB.