clase 14- intro ejbs

36
Enterprise Java Beans

Upload: pabloferreira5

Post on 04-Jul-2015

103 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Clase 14- Intro EJBs

Enterprise Java Beans

Page 2: Clase 14- Intro EJBs

¿Qué es un EJB? Enterprise Java Beans (EJB) es una

plataforma para construir aplicaciones de negocio portables, reusables y escalables usando el lenguaje de programación Java. Desde el punto de vista del desarrollador, un EJB es una porción de código que se ejecuta en un contenedor EJB, que no es más que un ambiente especializado (runtime) que povee determinados componentes de servicio.

Page 3: Clase 14- Intro EJBs

¿Qué es un EJB? Los EJBs pueden ser vistos

como componentes, desde el punto de vista que encapsulan comportamiento y permite reutilizar porciones de código, pero también 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 lógica de negocio con funcionalidades trasversales al modelo de dominio (a menudo requerimientos no funcionales o aspectos).

Page 4: Clase 14- Intro EJBs

¿Qué es un EJB?  En la especificación 3.0, los EJB no son

más que POJOs (clases planas comunes y corrientes de Java) con algunos poderes especiales implícitos, que se activan en runtime cuando son ejecutados en un contenedor de EJBs.

Page 5: Clase 14- Intro EJBs

En Resumen Componentes gestionados por un contenedor

del servidor de aplicaciones que permite gestionar el acceso a recursos (bases de datos, colas de mensajes, ficheros, etc) y proporcionar servicios (seguridad, transacciones, mensajería, nombres) de forma sistemática y optimizada

La utilización de EJB simplifica el desarrollo de aplicaciones web y permite construir aplicaciones escalables

Page 6: Clase 14- Intro EJBs

Los servicios que debe proveer el contenedor de EJBs

Page 7: Clase 14- Intro EJBs

Los servicios que debe proveer el contenedor de EJBs Los servicios que debe proveer el contenedor de EJBs

deben ser especificados por el programador a través de metadata de configuración que puede escribirse como: Anotaciones de Java5 intercaladas en el código de las clases. Descriptores XML (archivos XML separados).

A partir de EJB 3 se puede usar cualquiera de estas dos técnicas. Las técnicas no son exclusivas, pueden coexistir anotaciones con descriptores XML y, en el caso de superponerse la metadata, los XML tendrán prioridad y podrán sobreescribir las anotaciones.

Algunos ejemplos de los contenedores más populares que hay actualmente en el mercado son: Glassfish, de Sun Microsystem, JBoss Application Server, de Red Hat, BEA Weblogic Server y Oracle Application Server, ambos deOracle y WebSphere de IBM.

Page 8: Clase 14- Intro EJBs

Anotaciones Una anotación transforma un simple

POJO en un EJB.

Page 9: Clase 14- Intro EJBs

Especificación de EJBs Las EJBs se pueden inyectar en otros objetos

gestionados por el servidor, como los servlets, utilizando la anotación @EJB

El objeto en el que se inyecta la EJB se llama cliente

Las EJBs pueden ejecutarse en el módulo del cliente o en módulos específicos, que pueden incluso estar en ordenadores diferentes del del cliente

Page 10: Clase 14- Intro EJBs

Tipos de EJBs Existen tres tipos de EJBs:

Session Beans

Message-Driven Beans (MDBs)

Entity Beans

Page 11: Clase 14- Intro EJBs

Tipos de EJBs Session Beans: en una aplicación enterprise

típica, dividida en cuatro grandes capas o layers (presentación, lógica de negocio (business logic), persistencia y base de datos (DBMS)), los Session Beans viven en la lógica 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 invocación de un método a otro y el segundo conserva el estado a lo largo de toda una sesión. Los Session Beans Stateless son los únicos que pueden exponerse como web services.

Page 12: Clase 14- Intro EJBs

Session Beans Los Session Beans son invocados por el

cliente con el propósito de ejecutar operaciones de negocio específicas, como por ejemplo podría ser chequear la historia crediticia del cliente de un banco. El nombre sesión implica que la instancia del bean estará disponible durante una unidad de trabajo (unit of work) y no sobrevivirá a una caída del servidor. 

Un bean de sesión sirve para modelar cualquier funcionalidad lógica de una aplicación.

Page 13: Clase 14- Intro EJBs

Session Beans

EJB 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). En un bean de sesión con estado, las variables

de instancia del bean almacenan datos específicos obtenidos durante la conexión con el cliente. Cada bean de sesión con estado, por tanto, almacena el estado conversacional de un cliente que interactúa con el bean. Este estado conversacional se modifica conforme el cliente va realizando llamadas a los métodos de negocio del bean. El estado conversacional no se guarda cuando el cliente termina la sesión.

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.

Page 14: Clase 14- Intro EJBs

¿Cuando usar un session bean? En general, se debería usar un session bean cuando:

En un momento determinado, sólo un cliente tiene acceso a la instancia del bean.

El estado del bean no es persistente, existiendo solamente por un período corto de tiempo (tal vez un par de horas)

El bean implementa un web service. Los Stateful Session Beans son apropiados si se cumple alguna

de las siguientes condiciones: 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 través de

varias invocaciones a varios métodos. El bean intermedia entre el cliente y otro componente de la aplicación,

presentando al cliente una vista simplificada. El bean maneja el workflow de varias aplicaciones. Para mejorar la performance, se debe escoger stateless session bean

si se cumple alguna de las siguientes condiciones: El estado del bean no tiene datos específicos del cliente En una invocación a un método, el bean ejecuta tareas específicas

para todos los clientes.

Page 15: Clase 14- Intro EJBs

Session Beans Ciclo de vida de un Stateful Session Bean

Page 16: Clase 14- Intro EJBs

Ciclo de vida de un Stateful Session Bean Mientras este en la etapa “ready”, el contenedor EJB puede decidir

pasivar el bean, moviendo de la memoria al almacenamiento secundario (usualmente, el disco rígido). El contenedor EJB invoca el método anotado con @PrePassivate, si existe, inmediatamente antes de pasivarlo. Si el cliente invoca un método business mientras el EJB esta en el estado pasivado, el contenedor ejecutara el método anotado con @PostActivate, si existe, y luego mueve al bean al estado “ready”.

Hay tres maneras de que termine el ciclo de vida de un stateful session bean: Que se llame a un método anotado con la anotación @Remove, lo que determina

que si se llama a dicho método, al terminar la ejecución del mismo se destruye el bean. NOTA: la anotación @Remove no garantiza que el método sea llamado, sólo determina que si se lo llama, una vez terminada su ejecución se destruya el bean.

Que se llame al método remove() en un EJBObject creado a partir de la interfaz Adapted Home del bean.

Que un método de negocios del bean lance una RuntimeException. Al final del ciclo de vida, es decir, al darse cualquiera de estas tres

condiciones, el contenedor EJB ejecuta el método anotado con @PreDestroy, si existe. Luego de esto, el bean esta listo para ser recolectado por el GC y no puede volver a llamarse salvo que se cree una nueva instancia del mismo

Page 17: Clase 14- Intro EJBs

Session Bean Ciclo de vida de un Stateless Session

Bean: Debido a que un bean stateless nunca es pasivado, su ciclo de vida tiene solo dos etapas: “nonexistent” y “ready”. La figura a continuación muestra las etapas de un session bean stateless.

Page 18: Clase 14- Intro EJBs

Ciclo de vida de un Stateless Session Bean El cliente inicia el ciclo de vida cuando obtiene

una referencia al bean stateless. El contenedor “inyecta” las dependencias y luego invoca al método anotado con @PostConstruct, si existe. Al final del ciclo de vida, el contenedor EJB llama al método anotado con @PreDestroy, si existe. Luego de esto, la instancia del bean esta lista para ser recolectada por el GC.

Page 19: Clase 14- Intro EJBs

Tipos de EJBs Message-Driven Beans (MDBs): también viven

en la lógica de negocio y los servicios que proveen son parecidos a los Session Beans, con la diferencia de que los MDBs son usados para invocar métodos de forma asincrónica. Cuando se produce la invocación de un método de un MDB desde un cliente, la llamada no bloquea el código del cliente y el mismo puede seguir con su ejecución, sin tener que esperar indefinidamente por la respuesta del servidor. Los MDBs encapsulan el popular servicio de mensajería de Java, JMS. Hay una analogía muy interesante en el libro que dice que los MDBs son a JMS lo que JDBC es a SQL.

Page 20: Clase 14- Intro EJBs

Message-Driven Beans (MDBs) Los MDBs también procesan lógica de negocio, pero

un cliente nunca invoca a un método de un MDB directamente. El sistema de mensajería asincrónica propone la utilización de una capa intermedia en la comunicación entre el productor y el consumidor del mensaje. En EJB 3, esta capa se llama MOM (Message-oriented middleware).

Básicamente la MOM es un software que permite funcionar como servidor de mensajería, reteniendo los mensajes del productor y enviándolos posteriormente al consumidor en el momento en que esté disponible para recibirlo. (Es un funcionamiento similar al de un servidor de correo electrónico.) Algunos ejemplos típicos de servidores de mensajería son WebSphere MQ de IBM,SonicMQ, Advanced Queueing de Oracle y TIBCO.

Page 21: Clase 14- Intro EJBs

Message-Driven Beans (MDBs) Diferencias con los Session Beans ¿Que hace Diferente a un Message con respecto un

Session? La mayor de las diferencias es que el cliente no accede a los message beans a través de interfaces. A diferencia de un session bean, los message beans solamente tienen una clase bean.

Igualmente, en muchas maneras, un message bean se asemeja a un stateless session bean: Un message bean no mantiene estado conversacional Todas las instancias de un message bean son

equivalentes. Un único message bean puede procesar múltiples clientes.

Una variable de instancia de un message bean puede contener estados que sean únicos entre los clientes.

El componente clientes no invoca directamente a los message beans, sino que lo hacen enviando un mensaje JMS.

Page 22: Clase 14- Intro EJBs

Message-Driven Beans (MDBs) Un message bean tiene las siguientes características:

Se ejecutan con la recepción de un mensaje de un cliente. Son invocados asincrónicamente Su duración es relativamente corta. No representan datos. Pueden ser transaccionales. Son stateless.

Cuando se recibe un mensaje, el contenedor llama el método onMessage para procesar el mensaje. El método onMessage normalmente castea el mensaje a alguno de los 5 tipos de mensajes JMS y procesa el mismo. El método onMessage puede llamar a métodos helpers, o puede invocar un session bean para procesar la información del mensaje o guardarlo en la base de datos.

Un mensaje puede ser entregado a un message bean dentro de una transacción, en ese caso, todas las operaciones del método onMessage son parte de una única transacción.

Page 23: Clase 14- Intro EJBs

Message-Driven Beans (MDBs)¿Cuando se usan? Los session beans permiten enviar mensajes

JMS y recibirlos sincrónicamente, pero no asincrónicamente. Para evitar atar los recursos del servidor, no se debe usar recepciones sincrónicas (las cuales son bloqueantes) cuando se utilizan mensaje JMS. Para recibir mensajes asincrónicamente, se debe utilizar message Beans.

Page 24: Clase 14- Intro EJBs

Naming Conventions Debido a que un enterprise bean esta

compuesto de muchas partes, es útil (incluso necesario) seguir una nomenclatura de nombres para la aplicación. La tabla a que se muestra a continuación define la convención establecida por Sun:

Page 25: Clase 14- Intro EJBs

¿Qué servicios proveen los EJBs? Integración: Proveen una forma de acoplar en tiempo de ejecución

diferentes componentes, mediante simple configuración de anotaciones o XMLs. El acoplamiento se puede hacer mediante Inyección de Dependencia(DI) o usando JNDI, como se hacía en EJB 2 (explicaré el concepto de Inyección de Dependencia en detalle en el próximo post). La integración es un servicio que proveen los beans de sesión 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 aplicación sencilla con un solo thread (hilo). El contenedor se encarga de que los EJBs tengan el soporte adecuado para una aplicación multi-usuario (como son en general las aplicaciones enterprise) de forma transparente, asegurando el acceso seguro, consistente y performante. Aplica a los beans de sesión y a los MDBs.

Administración de Estados: El contenedor de EJBs almacena y maneja el estado de un Stateful Session Beande forma transparente, lo que significa que el programador puede mantener el estado de los miembros de una clase como si estuviera desarrollando una aplicación desktop ordinaria. El contenedor maneja los detalles de las sesiones.

Page 26: Clase 14- Intro EJBs

¿Qué servicios proveen los EJBs? Mensajería: Mediante los MDBs es posible desacoplar por completo

dos componentes para que se comuniquen de forma asincrónica, 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 configuración. Esto significa que cuando un método de un EJB (Session Bean o MDB) se completa normalmente, el contenedor se encargará decommitear la transacción y efectivizar los cambios que se realizaron en los datos de forma permanente. Si algo fallara durante la ejecución del método (una excepción o cualquier otro problema), la transacción haría unrollback y es como si el método jamás se hubiera invocado.

Seguridad: EJB soporta integración con la Java Authentication and Authorization Service (JAAS) API, haciendo casi transparente el

manejo transversal de la seguridad. Aplica a todos los Session Beans.

Page 27: Clase 14- Intro EJBs

¿Qué servicios proveen los EJBs? Interceptors: EJB introduce un framework liviano y simple

para AOP (programación orientada a aspectos). No es tan robusto y completo como otros, pero es lo suficientemente útil para que sea utilizado por los demás servicios del contenedor para brindarnos de forma invisible los crosscutting concerns de seguridad, transacciones, thread-safely. Además, nosotros, como programadores, podemos agregar nuevos aspectos como logging o auditoria y demás de forma configurable.

Acceso Remoto: Es posible acceder de forma remota a distintos EJBs de forma sencilla, simplemente mediante la Inyección de Dependencia. El procedimiento para inyectar un componente local o uno remoto es exactamente el mismo, abstrayéndonos 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 métodos como web services mediante una sencilla anotación.

Persistencia: EJB 3 provee la especificación JPA para el mapeo de objetos (Entities) a tablas.

Catching and Performance: JPA provee de forma transparente un importante número de servicios que permiten usar un caché de entidades en memoria y una lectura y escritura sobre la base de datos altamente performante.

Page 28: Clase 14- Intro EJBs

Funcionamiento de un Enterprise JavaBean Los EJB se disponen en un contenedor EJB dentro del

servidor de aplicaciones. La especificación describe cómo el EJB interactúa con su contenedor y cómo el código cliente interactúa con la combinación del EJB y el contenedor.

Cada EJB debe facilitar una clase de implementación Java y dos interfaces Java. El contenedor EJB creará instancias de la clase de implementación Java para facilitar la implementación EJB. Las interfaces Java son utilizadas por el código cliente del EJB. Las dos interfaces, conocidas como interfaz "home" e interfaz remota, especifican las firmas de los métodos remotos del EJB. Los métodos remotos se dividen en dos grupos: métodos que no están ligados a una instancia específica, por

ejemplo aquellos utilizados para crear una instancia EJB o para encontrar una entidad EJB existente. Estos métodos se declaran en la interfaz "home".

métodos ligados a una instancia específica. Se ubican en la interfaz remota.

Page 29: Clase 14- Intro EJBs

Funcionamiento de un Enterprise JavaBean Dado que se trata simplemente de interfaces

Java y no de clases concretas, el contenedor EJB genera clases para esas interfaces que actuarán como un proxy en el cliente. El cliente invoca un método en los proxies generados que a su vez sitúa los argumentos método en un mensaje y envía dicho mensaje al servidor EJB. Los proxies usan RMI-IIOP para comunicarse con el servidor EJB.

El servidor llamará a un método correspondiente a una instancia de la clase de implementación Java para manejar la llamada del método remoto.

Page 30: Clase 14- Intro EJBs

Interfaz "Home" La interfaz "Home" permite al código cliente

manipular métodos de clase del EJB que no están asociados a ninguna instancia particular. La Interface "Home" permite crear las instancias de EJB de entidad o sesión a través del método create que puede ser sobrecargado.

La especificación EJB 1.1 establece el tipo de métodos de clase que se pueden definir como métodos que crean un EJB o para encontrar un EJB existente si es un "bean" de entidad.

La especificación EJB 2.0 permite a los desarrolladores de aplicaciones definir nuevos métodos de clase sin limitarse a su sola creación o borrado.

Page 31: Clase 14- Intro EJBs

Interfaz remota La interfaz remota especifica los métodos de

instancia públicos encargados de realizar las operaciones.

Una sesión bean puede implementar múltiples interfaces, con cada interfaz apuntada por un tipo de cliente diferente. La interfaz local es para aquellos clientes que corren en la misma máquina virtual que el contenedor EJB. La interfaz remota es para clientes remotos. Frente a una consulta del cliente, el contenedor retorna un stub serializado del objeto que implementa la interfaz remota. El stub conoce cómo pasar llamadas a procedimientos remotos (RPCs) al servidor. Este tipo de interfaz es también un POJO.

Page 32: Clase 14- Intro EJBs

Clase de implementación EJB Las clases de implementación EJB las

suministran los desarrolladores de aplicaciones, que facilitan la lógica de negocio ("business logic") o mantienen los datos ("business data") de la interfaz de objeto, esto es, implementan todos los métodos especificados por la interfaz remota y, posiblemente, algunos de los especificados por la interfaz "home".

Page 33: Clase 14- Intro EJBs

Correspondencia entre métodos de interfaz y métodos de implementación Las llamadas al método en la interfaz "home"

se remiten al método correspondiente de la clase de implementación del bean con el prefijo 'ejb' añadido y con la primera letra de la interfaz "home" convertida en mayúscula y manteniendo exactamente el mismo tipo de argumentos. Por ejemplo:

create ---> ejbCreate. Las llamadas a métodos en la interfaz remota

se remiten al método de implementación correspondiente del mismo nombre y argumentos en la clase del bean.

Page 34: Clase 14- Intro EJBs

Ejemplo de anotación de inyección en un servlet

public class MiServ extends HttpServlet {@EJBprivate MiEJB miEJBRef;protected void doGet(…) {

…miEJBRef.miMetodo();… }

}

Page 35: Clase 14- Intro EJBs

Ejemplo de EJB de sesiónsin estado

package myPack;Import javax.ejb.Stateless;@Statelesspublic class MyEJB implements MyEJBLocal {

public String myMethod(String myName) {return “Hello “ + myName; }

}

Page 36: Clase 14- Intro EJBs

Estructura de unaaplicación Enterprise