Enterprise JavaBeans (EJB) es una plataforma para construir aplicaciones empresariales portables, reusables y escalables, utilizando el lenguaje de programación java. EJB permite a los desarrolladores de aplicaciones enfocarse en construir la lógica de negocio sin la necesidad de gastar tiempo en la construcción de código de infraestructura.
Desde el punto de vista del desarrollador, EJB es una pieza de código java que se ejecuta en un ambiente de ejecución (runtime enviroment) denominado contenedor EJB.
Estándar Java EE
EJB es una parte muy importante del estándar Java EE. EJB 3 es una especificación de una API abierta y publica, la cual es utilizada por diversas organizaciones para crear una implementación de un contenedor (container) o un proveedor de persistencia (JPA). El estándar EJB 3 es desarrollado por la Java Community Process (JCP), la cual está constituida por un grupo no exclusivo de individuos que guían los estándares Java.
Por este motivo, EJB es soportado por un gran número de organizaciones independientes. Esto incluye tanto a las grandes corporaciones como Oracle e IBM, como también a los grandes grupos open source como JBoss y Geronimo.
El alto grado y variedad de soporte de esta especificación se traduce en tres importantes ventajas para el desarrollador y compañías que trabajan con esta tecnología:
- No se encuentran a merced de los altos y bajos de una compañía o grupo de usuarios en particular.
- Un gran número de personas tienen el interés (a corto, mediano y largo plazo) de mantener esta tecnología lo más competitiva posible.
- Todos los proveedores de la especificación históricamente han competido agregando nuevas características (no estándar) a sus implementaciones.
Todos estos factores mantienen la especificación EJB en el camino de la evolución constante.
El proveedor de persistencia está completamente separado del contenedor EJB 3.0, por este motivo, es abstraído a través de la Java Persistence API (JPA). Esto permite, en un proyecto, intercambiar la implementación del mismo sin cambiar ninguna línea de código. Existen organizaciones que brindan implementaciones de la JPA, para que el mismo pueda ser utilizado dentro de un contenedor completo Java EE, con contenedores web livianos (como Tomcat), o para utilizarlas dentro de aplicaciones Java SE. JDO, OpenJPA, Hibernate (de JBoss) y TopLink (de Oracle) son algunas de las implementaciones más utilizadas.
EJB como un componente
En el mundo de EJB 3, un componente no es más que un POJO (Plain Old Java Object) con cierta funcionalidad especial. La idea real detrás de los componentes es que permiten encapsular el comportamiento de la aplicación.
Existen tres tipos de componentes EJB:
- Beans de sesión (session beans)
- Beans manejados por mensajes (message-driven beans)
- Entidades (entities)
Los session beans y message-driven bean (MDB) son utilizados para implementar la lógica de negocio en una aplicación EJB, y los entities son utilizados para la persistencia. Estos componentes pueden ser reutilizados en diferentes aplicaciones, lo que obliga a construirlos de una manera cuidadosa y planificada para permitir reutilizarlos.
EJB como un framework
Como ya se menciono, los componentes EJB están alojados en un contenedor. Ambos, los componentes (o EJB’s) junto con el contenedor, pueden ser vistos como un framework que provee servicios para el desarrollo de aplicaciones empresariales.
El contenedor EJB provee servicios comunes a la mayoría de las aplicaciones del lado del servidor, como el manejo de estados de una aplicación, almacenamiento y obtención de la información desde una base de datos, manejo de transacciones, implementación de seguridad, procesamiento asincrónico, integración de sistemas, etc. Estos servicios están disponibles para los componentes EJB cuando los mismos son desplegados (deployed) en un contenedor EJB. De esta manera se permiten desarrollar aplicaciones profesionales en menor tiempo y enfocarse solo en la lógica de negocio.
El contenedor provee los servicios a los componentes EJB a través de las anotaciones metadata (metadata annotations), estas son utilizadas para preconfigurar los componentes EJB especificando los tipos de servicios, los cuales son agregados cuando el contenedor despliega los mismos.
Las metadata annotations (introducidas en Java 5), son seteos de propiedades que se aplican a una pieza de código, como un método o una clase. Este es un tipo de programación declarativa, en donde el desarrollador especifica que debe ser realizado y el sistema agrega el código necesario para realizarlo. Estas anotaciones permiten no depender de un archivo XML de configuración externo. De esta manera, los desarrolladores agregan los servicios declarativamente a los componentes EJB, es decir, las anotaciones transforman un simple POJO en un EJB.
El framework EJB es un estándar de la tecnología java, el cual tiene una especificación abierta (administrada por la Java Community Process). EJB es soportado por un gran número de compañías y grupos de open source que proveen implementaciones de la especificación. Dichas implementaciones deben cumplir con la especificación, lo cual facilita la portabilidad de las aplicaciones a través de diferentes contenedores EJB.
Arquitecturas de capas y EJB
La mayoría de las aplicaciones empresariales contienen un gran número de componentes. Para desarrollar este tipo de aplicaciones se puede seguir una arquitectura común o un principio de diseño (patrones). En una arquitectura con capas, los componentes son agrupados dentro de diferentes capas, cada una de estas delega trabajo a su capa por debajo.
EJB permite construir aplicaciones utilizando dos arquitecturas de capas diferentes: la arquitectura tradicional de cuatro capas y el diseño manejado por el dominio (domain-driven design).
Arquitectura de cuatro capas
En esta arquitectura, la capa de presentación es responsable de renderizar la interfaz grafica del usuario (GUI) y manejar la entrada del usuario. La capa de lógica de negocio es el corazón de la aplicación y contiene flujo de trabajo (workflow) y lógica de procesamiento. La capa de persistencia provee una abstracción orientada a objetos (OO) de alto nivel de la capa de base de datos. La capa de base de datos consiste típicamente en un sistema de administración de bases de datos relacionales (RDBMS).
EJB da soporte para la capa de lógica de negocio y la capa de persistencia. Los session beans y MDB residen y utilizan los servicios de la capa de lógica de negocio. Por otro lado, los entities residen y utilizan los servicios de la capa de persistencia.Domain-driven design
El termino domain-driven design (DDD) enfatiza que los objetos de dominio deben contener lógica de negocios y no deberían ser solo una réplica (sin lógica) de las tablas de la base de datos. En EJB, los objetos de dominio son denominados entities (entidades).
En versiones anteriores de EJB (como EJB 2), era casi imposible implementar un modelo de dominio real debido a que los beans no eran POJO’s y no soportaban muchas características OO, como la herencia y el polimorfismo. EJB 3 permite implementar la arquitectura DDD, debido a que las entidades son definidas a través de JPA (EJB 3 Java Persistence API), la cual soporta todas las características OO dado a que son POJO’s con simples anotaciones.
Session Beans
Un session bean es invocado por un cliente con el propósito de realizar una operación específica de negocio. Es decir, puede ser utilizado para crear cualquier funcionalidad lógica de la aplicación. Existen dos tipos de session beans: stateful y stateless.
Un stateful session bean almacena automáticamente el estado del bean entre diversas invocaciones de un cliente sin la necesidad de que el desarrollador deba escribir código adicional.
Un stateless session bean no mantiene ningún estado y permite modelar servicios de aplicación que pueden ser completados en una sola invocación del cliente.
Un session bean puede ser invocado tanto local como remotamente utilizando Java RMI (Remote Method Invocation). Un stateless session bean puede ser publicado como un web service.
Message-driven beans (MDB)
Del mismo modo que los session beans, los MDB’s procesan lógica de negocio. Pero con la diferencia que los métodos de los mismos nunca son invocados directamente por un cliente. Los MDB’s son desencadenados por mensajes enviados a un servidor de mensajes, el cual activa el envío de mensajes asincrónicos entre componentes del sistema. MDB’s son utilizados típicamente para sistemas robustos de integración o procesamientos asincrónicos. IBM WebSphere MQ, SonicMQ, Oracle Advanced Queueing y TIBCO son algunos de los servidores de mensajes más utilizados.
Java Persistence API (JPA)
La persistencia dentro de EJB 3 es administrada por JPA. JPA permite persistir automáticamente los objetos Java utilizando una técnica denominada object-relational mapping (ORM). ORM es esencialmente el proceso de mapear la información contenida en los objetos Java hacia las tablas de base de datos utilizando una configuración.
JPA define un estándar para:
- La creación de configuración metadata del ORM para mapear entidades hacia tablas relacionales.
- La EntityManager API, una API estándar para realizar las operaciones CRUD (create, read, update y delete) de las entidades.
- El lenguaje Java Persistence Query Language (JPQL), para realizar búsquedas y obtener información persistida de la aplicación.
Como se ha mencionado anteriormente, desde que JPA estandariza los frameworks ORM para la plataforma Java, se pueden utilizar productos como Hibernate ó TopLink como la implementación del proveedor de persistencia de una aplicación. Como JPA está completamente separado del resto del contenedor EJB 3, y en definitiva todas las operaciones se traducen a operaciones JDBC, esta tecnología de abstracción de ORM puede ser utilizada en ambientes Java SE.
Entities
Las entidades son objetos Java que son persistidos dentro una base de datos. Es decir, son las representaciones OO de la información de la aplicación almacenada en la base de datos. La magia de las entidades se basa en las anotaciones metadata ORM, las cuales especifican la información de cómo las mismas deben ser mapeadas a la base de datos. Las entidades JPA soportan todos los tipos de relaciones y capacidades OO, incluyendo relaciones entre entidades, herencia y polimorfismo.
EntityManager
La interface EntityManager administra entidades en términos de proveer servicios de persistencia. Dicha interface, lee las anotaciones metadata de una entidad y realiza las operaciones de persistencia. Es decir, conoce el modo de agregar, actualizar, eliminar y obtener entidades de la base de datos (CRUD).
Contenedores completos Java EE
Un contenedor Java EE es un servidor de aplicaciones el cuál contiene un contenedor EJB 3, un contenedor web y otras API’s y servicios Java EE. Algunos ejemplos de contenedores Java EE completos son: WebLogic Server (BEA), GlassFish (Sun Microsystems), IBM WebSphere, JBoss Application Server y Oracle Application Server.
Algunos proveedores pueden ofrecer solo un contenedor web (como Tomcat) o proveedor de persistencia (como Hibernate).
Otros beneficios de EJB 3
Además de los beneficios expuestos anteriormente, EJB 3 ofrece:
- Utilización de servicios EJB: Integration, Pooling, Thread-safety, State managment, Messaging, Transactions, Security, Interceptors, Remote Access, Web services, Persistence, Caching y performance.
- Modelo de programación simplificado, a través de la utilización de POJO’s (Plain Old Java Objects) y POJI’s (Plain Old Java Interfaces), a los cuales luego se le aplican configuraciones a través de las anotaciones para agregar servicios de la plataforma.
- Anotaciones en cambio de descriptores de despliegue (archivos XML).
- Inyección de dependencia en vez de JNDI lookups. Esto permite desacoplar el código de la aplicación del servidor, los lookups se convierten en una simple configuración a través de anotaciones.
- Estandarización de frameworks de persistencia (JPA).
- Componentes POJO más fáciles de testear a través de frameworks de testeo como JUnit o TestNG.
- Integración de EJB 3 con Spring, Spring con EJB 3 y Spring con JPA.
Entradas
