Clase 14  intro ej bs
Upcoming SlideShare
Loading in...5
×
 

Clase 14 intro ej bs

on

  • 634 views

 

Statistics

Views

Total Views
634
Views on SlideShare
634
Embed Views
0

Actions

Likes
1
Downloads
14
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Clase 14  intro ej bs Clase 14 intro ej bs Presentation Transcript

  • Enterprise Java Beans
  • ¿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.
  • ¿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 ).
  • ¿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.
  • 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
  • Los servicios que debe proveer el contenedor de 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 de Oracle  y  WebSphere  de  IBM .
  • Anotaciones
    • Una anotación transforma un simple POJO en un EJB.
  • 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
  • Tipos de EJBs
    • Existen tres tipos de EJBs:
      • Session Beans
      • Message-Driven Beans (MDBs)
      • Entity Beans
  • 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 .
  • 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.
  • 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.
  • ¿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.
  • Session Beans
    • Ciclo de vida de un Stateful Session Bean
  • 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
  • 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.
  • 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.
  • 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 .
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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:
  • ¿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 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 aplicación  desktop  ordinaria. El contenedor maneja los detalles de las sesiones.
  • ¿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á de commitear  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 un rollback  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 .
  • ¿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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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".
  • 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.
  • Ejemplo de anotación de inyección en un servlet
    • public class MiServ extends HttpServlet {
    • @EJB
    • private MiEJB miEJBRef;
    • protected void doGet(…) {
    • m i EJBRef.miMetodo ();
    • … }
    • }
  • Ejemplo de EJB de sesión sin estado
    • package myPack;
    • Import javax.ejb.Stateless;
    • @Stateless
    • public class MyEJB implements MyEJBLocal {
    • public String myMethod(String myName) {
    • return “Hello “ + myName; }
    • }
  • Estructura de una aplicación Enterprise