EJB

Un POJO (acrnimo de Plain Old Java Object) es una sigla creada por Martin Fowler, Rebecca Parsons y Josh MacKenzie en septiembre de 2000 y utilizada por programadores Java para enfatizar el uso de clases simples y que no dependen de un framework en especial. Este acrnimo surge como una reaccin en el mundo Java a los frameworks cada vez ms complejos, y que requieren un complicado andamiaje que esconde el problema que realmente se est modelando. En particular surge en oposicin al modelo planteado por los estndares EJB anteriores al 3.0, en los que los "Enterprise JavaBeans" deban implementar interfaces especiales. POJO es una nueva palabra para designar algo viejo. No existe en Java una nueva tecnologa con ese nombre, sino que el nombre existe en el marco de una revalorizacin de la programacin "simplemente orientada a objetos". Esta revalorizacin tiene que ver tambin con el xito de lenguajes orientados a objetos ms puros[cita requerida] y sencillos, que empezaron a tomar parte del mercado al que Java apunta, como Ruby y Python. Enterprise Java Beans (EJB) es una plataforma para construir aplicaciones de negocio portables, reusables y escalables usando el lenguaje de programacin Java. Desde el punto de vista del desarrollador, un EJB es una porcin de cdigo que se ejecuta en un contenedor EJB, que no es ms que un ambiente especializado (runtime) que povee determinados componentes de servicio. Los EJBs pueden ser vistos como componentes, desde el punto de vista que encapsulan comportamiento y permite reutilizar porciones de cdigo, pero tambin pueden ser vistos como un framework, ya que, desplegados en un contenedor, proveen servicios para el desarrollo de aplicaciones enterprise, servicios que son invisibles para el programador y no ensucian la lgica de negocio con funcionalidades trasversales al modelo de dominio (a menudo requerimientos no funcionales o aspectos). En la especificacin 3.0, los EJB no son ms que POJOs (clases planas comunes y corrientes de Java) con algunos poderes especiales implcitos, que se activan en runtime cuando son ejecutados en un contenedor de EJBs.

Los servicios que debe proveer el contenedor de EJBs deben ser especificados por el programador a travs de metadata de configuracin que puede escribirse como: Anotaciones de Java5 intercaladas en el cdigo de las clases. Descriptores XML (archivos XML separados).

Tipos de EJBs Existen tres tipos de EJBs:

Session Beans: en una aplicacin enterprise tpica, dividida en cuatro grandes capas o layers (presentacin, lgica de negocio (business logic), persistencia y base de datos (DBMS)), los Session Beans viven en la lgica de negocio. Hay dos grandes tipos de Session Beans: Stateless y Stateful, el primero no conserva el estado de ninguno de sus atributos de la invocacin de un mtodo a otro y el segundo conserva el estado a lo largo de toda una sesin. Los Session Beans Stateless son los nicos que pueden exponerse como web services. Message-Driven Beans (MDBs): tambin viven en la lgica de negocio y los servicios que proveen son parecidos a los Session Beans, con la diferencia de que los MDBs son usados para invocar mtodos de forma asincrnica. Cuando se produce la invocacin de un mtodo de un MDB desde un cliente, la llamada no bloquea el cdigo del cliente y el mismo puede seguir con su ejecucin, sin tener que esperar indefinidamente por la respuesta del servidor. Los MDBs encapsulan el popular servicio de mensajera de Java, JMS. Hay una analoga muy interesante en el libro que dice que los MDBs son a JMS lo que JDBC es a SQL. Entities: los entities viven en la capa de persistencia y son los EJBs que manejan la Java Persistence API (JPA), tambin parte de la especificacin de EJB 3.0. Los entities son POJOs con cierta metadata que permite a la capa de persistencia mapear los atributos de la clase a las tablas de la base de datos y sus relaciones.

Los Session Beans son invocados por el cliente con el propsito de ejecutar operaciones de negocio especficas, como por ejemplo podra ser chequear la historia crediticia del cliente de un banco. El nombre sesin implica que la instancia del bean estar disponible durante una unidad de trabajo (unit of work) y no sobrevivir a una cada del servidor. Un bean de sesin sirve para modelar cualquier funcionalidad lgica de una aplicacin. Los MDBs tambin procesan lgica de negocio, pero un cliente nunca invoca a un mtodo de un MDB directamente. El sistema de mensajera asincrnica propone la utilizacin de una capa intermedia en la comunicacin entre el productor y el consumidor del mensaje. En EJB 3, esta capa se llama MOM (Message-oriented middleware). Bsicamente la MOM es un software que permite funcionar como servidor de mensajera, reteniendo los mensajes del productor y envindolos posteriormente al consumidor en el momento en que est disponible para recibirlo. (Es un funcionamiento similar al de un servidor de correo electrnico.) Algunos ejemplos tpicos de servidores de mensajera son WebSphere MQ de IBM, SonicMQ, Advanced Queueing de Oracle y TIBCO. Entities y la Java Persistence API Debido al auge de los frameworks ORM (Hibernate, TopLink, etc), Sun tuvo que replantear su complicada y anti-natural especificacin de persistencia, que tanto dolores de cabeza le daba a los programadores que usaban EJB 2, al extremo que opt por reescribirla casi por completo. As naci JPA. JPA persiste automticamente los objetos Java usando la tcnica de ORM (mapeo objetorelacional). Los ORM del mercado se han adaptado a esta especificacin y, hoy en da, cualquier framework de persistencia ORM soporta JPA. El estndar JPA define: La configuracin ORM mediante metadata que mapea entidades a tablas relacionales. La interface EntityManager, que define una API estndar para realizar las operaciones de persistencia (CRUD) de las entidades. El Java Persistence Query Language (JPQL), para consultas y lecturas de datos de aplicacin persistidos (algo as como un SQL orientado a objetos).

En general, los contenedores proveen su ORM. Por ejemplo, JBoss provee Hibernate, Glassfish provee TopLink. JPA puede funcionar independientemente del resto de los componentes de EJB 3 y hasta puede ser usado en una aplicacin desktop comn y

corriente, una aplicacin Java SE. Los entities son los objetos Java que se persisten en la base de datos. Mientras que los Session Beans son los verbos del sistema, las entidades son los sustantivos. Qu es un contenedor de EJBs? As como cuando compilamos una clase simple de Java, necesitamos una Java Virtual Machine (JVM) para ejecutarla, necesitamos un contenedor de EJBs para ejecutar los Session Beans y los MDBs.

Un contenedor Java EE es un servidor de aplicaciones que es capaz de ejecutar EJBs, puede servir como web container y adems puede incluir otras APIS y servicios, como por ejemplo el de persistencia. Algunos servidores de aplicaciones pueden proveer solamente un contenedor web, como es el caso de Apache Tomcat, o slo proveer servicios de persistencia, como es el caso de Hibernate. Un servidor de aplicaciones como JBoss trae un servidor Apache Tomcat y un servidor Hibernate, que se ejecutan dentro de forma transparente. Qu servicios proveen los EJBs? Integracin: Proveen una forma de acoplar en tiempo de ejecucin diferentes componentes, mediante simple configuracin de anotaciones o XMLs. El acoplamiento se puede hacer mediante Inyeccin de Dependencia (DI) o usando JNDI, como se haca en EJB 2 (explicar el concepto de Inyeccin de Dependencia en detalle en el prximo post). La integracin es un servicio que proveen los beans de sesin y los MDBs. Pooling: El contenedor de EJBs crea para componentes EJB un pool de instancias que es compartido por los diferentes clientes. Aunque cada cliente ve como si recibiera siempre instancias diferentes de los EJB, el contenedor est constantemente reusando objetos para optimizar memoria. El pooling es un servicio que se aplica a los Stateless Session Beans y a los MDBs. Thread-safely: El programador puede escribir componentes del lado del servidor como si estuviera trabajando en una aplicacin sencilla con un solo thread (hilo). El contenedor se encarga de que los EJBs tengan el soporte adecuado para una aplicacin multi-usuario (como son en general las aplicaciones enterprise) de forma transparente, asegurando el acceso seguro, consistente y performante. Aplica a los beans de sesin y a los MDBs. Administracin de Estados: El contenedor de EJBs almacena y maneja el estado de un Stateful Session Bean de forma transparente, lo que significa que el programador puede mantener el estado de los miembros de una clase como si estuviera desarrollando una aplicacin desktop ordinaria. El contenedor maneja los detalles de las sesiones. Mensajera: Mediante los MDBs es posible desacoplar por completo dos componentes para que se comuniquen de forma asincrnica, sin reparar demasiado en los mecanismos de la JMS API que los MDBs encapsulan. Transacciones: EJB soporta el manejo de transacciones declarativas que permiten agregar comportamiento transaccional a un componente simplemente usando anotaciones o XMLs de configuracin. Esto significa que cuando un mtodo de un EJB (Session Bean o MDB) se completa normalmente, el contenedor se encargar de

commitear la transaccin y efectivizar los cambios que se realizaron en los datos de forma permanente. Si algo fallara durante la ejecucin del mtodo (una excepcin o cualquier otro problema), la transaccin hara un rollback y es como si el mtodo jams se hubiera invocado. Seguridad: EJB soporta integracin con la Java Authentication and Authorization Service (JAAS) API, haciendo casi transparente el manejo transversal de la seguridad. Aplica a todos los Session Beans. Interceptors: EJB introduce un framework liviano y simple para AOP (programacin orientada a aspectos). No es tan robusto y completo como otros, pero es lo suficientemente til para que sea utilizado por los dems servicios del contenedor para brindarnos de forma invisible los crosscutting concerns de seguridad, transacciones, thread-safely. Adems, nosotros, como programadores, podemos agregar nuevos aspectos como logging o auditoria y dems de forma configurable. Acceso Remoto: Es posible acceder de forma remota a distintos EJBs de forma sencilla, simplemente mediante la Inyeccin de Dependencia. El procedimiento para inyectar un componente local o uno remoto es exactamente el mismo, abstrayndonos de las complicaciones especificas de RMI o similares. Este servicio aplica nicamente a los Session Beans. Web Services: Un Stateless Session Bean puede publicar sus mtodos como web services mediante una sencilla anotacin. Persistencia: EJB 3 provee la especificacin JPA para el mapeo de objetos (Entities) a tablas. Catching and Performance: JPA provee de forma transparente un importante nmero de servicios que permiten usar un cach de entidades en memoria y una lectura y escritura sobre la base de datos altamente performante.

HelloUser Example Termino este post con el ejemplo provisto por el libro en este captulo. El ejemplo cuenta con una simple interface llamada HelloUser con un nico mtodo sayHello. Luego, se muestra una clase que implementa esa interface, HelloUserBean, y que adems, mediante una simple anotacin, @Stateless, se le indica al contenedor que HelloUserBean es un Stateless Seasion Bean. A continuacin, del lado del cliente, se muestra el cdigo para inyectar el bean en un atributo privado llamado helloUser, del tipo HelloUser. En un mtodo del cliente llamado hello(), se invoca el mtodo sayHello() del bean de sesin (notar que sayHello() es un mtodo que se ejecuta del lado del servidor, por ende la salida no se ver en la consola del cliente, sino en la consola del servidor, que a menudo es un archivo de log del servidor de aplicaciones). Para inyectar de forma transparente el bean de sesin en el objeto del tipo HelloUser, se usa la anotacin @EJB. Otra opcin podra haber sido la nica que haba en EJB 2: localizar el componente mediante JNDI. Cdigo del Lado del Servidor package ejb3inaction.example; public interface HelloUser { ____public void sayHello(String name); } package ejb3inaction.example; import javax.ejb.Stateless; @Stateless public class HelloUserBean implement HelloUser { ____public void sayHello(String name) { ________System.out.println("Hello " + name + " welcome to EJB 3!"); ____} }

Cdigo del Lado del Cliente ... @EJB private HelloUser helloUser; void hello() { ____helloUser.sayHello("Curious George"); }