Los Enterprise Java Beans Son trozos de cdigo
Los Enterprise Java Beans • Son trozos de código que extienden un servidor • “Viven” en un contenedor apropiado • Son altamente eficientes en el uso de recursos del servidor • No son contactados directamente por el browser sino por un trozo de código java • No reemplazan a los Servlets sino que los complementan
Como funcionan • El cliente debe obtener una referencia remota a ellos “preguntando” por ellos a un servicio especial • Una vez obtenida la referencia se invoca alguno de los métodos • Los métodos que tiene un ejb son definidos por el programador
Qué va dónde Cliente: Browser web Servidor de aplicaciones Servidor de BD Servidor web y de aplicaciones Páginas HTML -Java Script -JSP EJB Comunicación por medio de JDBC
Existen 3 Clases principales • Session Beans: – Implementan procesos, orientados a acciones (cálculo de un valor) • Entity Beans: (reemplazados en la version 3. 0) – Están asociados a datos persistentes. Representan una instancia de un dato almacenado • Message Driven Beans: – Parecidos a Session beans pero son “despertados” o contactados por mensajes que pueden incluso ser asíncronos
Refinando la clasificación • Session Beans: – Sin estado: son contactados una vez por los clientes, ejecutan una acción y no queda traza de lo que se hizo – Con estado: en una “sesión” pueden ser contactados varias veces por el mismo cliente para desarrollar una “conversación”. Será necesario mantener algún tipo de información para recordar lo que va haciendo el cliente • Entity Beans: – Persistencia controlada por el Bean: el programador debe incluir código de modo de asegurarse que el enttity bean represente a un dato en una tabla – Persistencia controlada por el container: el container se preocupa de asociar el bean a un dato de una tabla
Qué se necesita escribir para implementar un bean • Los Archivos Java (programados por el desarrollador de la aplicación) – El archivo Interfaz : en esta interfaz se especifican los business methods que implementa el bean, es decir, todos aquellos métodos que no tienen que ver con crear, recuperar, destruir o localizar un bean. Típicamente los que diseña el programador • Existen Interfaz local y remota, dependiendo de si el EJB será contactado por un trozo de código que vive en el servidor o no. No hay diferencia en los métodos que tiene que declarar – El archivo Bean: este archivo implementa todos los métodos del bean declarados por la interfaz y puede sobrescribir algunos que métodos propios de la clase (para los session bean con estado.
Un bean sin estado: implementación package ejb; import javax. ejb. Stateless; @Stateless public class Session 1 Bean implements Session 1 Local { public Session 1 Bean() { } public String hola(String nombre) { return "hola "+nombre; } }
Un bean sin estado: interfaz package ejb; import javax. ejb. Local; @Local public interface Session 1 Local { String hola(String nombre); }
Servlet que llama al EJB import ejb. Session 1 Local; import java. io. *; import java. net. *; import javax. ejb. EJB; import javax. servlet. *; import javax. servlet. http. *; public class Servlet. EJB extends Http. Servlet { @EJB private Session 1 Local bean 1; protected void process. Request(Http. Servlet. Request request, Http. Servlet. Response response) throws Servlet. Exception, IOException { response. set. Content. Type("text/html; charset=UTF-8"); Print. Writer out = response. get. Writer(); out. println("<h 1>Mensaje del bean " + bean 1. hola(request. get. Parameter("nombre")) + "</h 1>"); out. close(); }
Cliclo de vida de los Stateless Session Beans • Los beans son creados y destruidos por el container. Cuando un bean se levanta con el container (el bean debe estar ahí cuando se echa a andar el server) se crean instancias del bean (bean pool) las cuales son “asignadas” a los clientes. Qué bean es entregado a qué cliente lo decide el container • Si se necesitan más beans estos son creados por el container • Si hay demasiados estos son destruidos
El papel de cada uno de las 3 clases de objetos Bean Pool 3 invoca método cliente Interfaz 5 - retorna resultado 4 contacta bean 1 -ubicar 2 retorna referencia 0 se registra Naming EJB
Un Session Servlet con Estado • Cuando un cliente contacta a un stateful servlet no es tan conveniente que el container los destruya cuando estime conveniente ya que el mismo servlet tiene que estar al servicio del mismo cliente, y el container no puede saber cuando termina el cliente de contactar al servlet sino hasta que lo destruye explicitamente. • Tampoco puede mantenerlos indefinidamente en el container ya que consumen recursos • La solución pasa por “pasivarlos” y “activarlos” • Pasivarlos: pasan de emoria principal a secundaria • Activarlos: pasan de memoria secundaria a principal (swapping)
Un Session Servlet con Estado • El container implementa una “política” de pasivacionactivación por ejemplo, Least Used reciently • Un bean involucrado en una transaccón o sirviendo a un cliente no puede ser pasivado • Se usa serialización • el método Passivate es llamado antes de copiar el bean al disco • el método Activate es llamado cuando se activa • En cada método se liberan/recuperan recursos que no se pueden serializar por ej. conexiones a bases de datos, archivos abiertos (que pasa si esta leyendo en medio del archivo), conexiones a sockets
El Count Bean package pack 1; import javax. ejb. Stateful; @Stateful public class Count. Bean implements Count. Bean. Local { int i = 0; public New. Session. Bean() { } public int count() { i++; return i; } }
El Count Bean (interfaz) package pack 1; import javax. ejb. Local; @Local public interface Count. Bean. Local { int count(); }
Estados de un Bean con estado Cliente llama a remove() en el ejb. Object o se le da un timeout al cliente No existe El container llega a un límite de su capacidad: swapping Remove() Timeout del cleinte Activate() Activo Passivate() cliente llama a un método del Bean pasivado
Los Entity beans • Un bean representa a un dato (fila) en una base de datos • Hay que pensar en ellos como si fueran uno solo con el dato en memoria secundaria • Debe existir un mecanismo para automáticamente transferir los datos de la memoria secundaria al EJB y vice-versa • Esto se hace a través de llamadas a los métodos ejb. Load() y ejb. Store() • Estos métodos son llamados por el container cuando estima que es necesario • distintos beans pueden representar al mismo dato en disco • ejb. Activate() y ejb. Passivate() se llaman cuando un entity bean es puesto/sacado de un pool de beans, por lo que hay que programas la adquisición y liberación de reucursos • Como además se debe guardar el estado del bean en memoria secundaria, por lo cual se llama siempre a ejb. Store abtes de pasivar y a ejb. Load antes de activar
Las 2 maneras de lograr persistencia de los beans • En un bean-manajed persistence entity bean el programador debe escribir las instrucciones para que las variables del entity bean sean las correspondientes a un dato en una base de datos (saving, loading, and finding) • Estas instrucciones van en los métodos de creación (ejb. Create(. . . )), destrucción (ejb. Remove()), localización (ejb. Find(. . . )), carga (ejbload()) y almacenamiento (ejb. Store()) • Esto generalmente se hace via instrucciones JDBC • En los container-managed persistence beans de esto se encarga el container, sólo basta dar algunas directrices para la localización de los datos en un archivo especial (según yo, esto sería una de las gracias más grandes de j 2 ee)
Creación y destrucción de Beans • Cuando un entity bean es creado por una llamada al método ejb. Create se debe crear también este dato en la base de datos, si se trata de un bean-managed persistence bean, aquí se deben programar las instruccónes SQL para insertar una fila en una tabla • De la misma manera, cuando un entity bean es removido, se llama a ejb. Remove y aquí se debe programas la instrucción SQL que borre la fila correspondiente • A cada clase de entity bean que se crea hay que asociarle un objeto que represente la clave primaria de ese tipo de objeto (por ejemplo un string. Por convención se usa el nombre del bean terminado en PK (por ejemplo Cuenta. PK) • El método ejb. Create de un entity bean debe devolver un siempre un objeto de este tipo luego de haber creado el dato
Esquema de creación de un entity bean 1 - create() cliente 2 - ejb. Create() Home 4 - retorna una referencia al EJB object 5 - creación del objeto EJB 4 - retorna un objeto que representa la clave primaria del ejb creado EJB Object EJB CONTAINER Bean 3 - se crea el dato en la base de datos Base de Datos
Creación y destrucción de Beans • Si, por ejemplo, tenemos un Bean que se llamará Account, el home object será de la clase Account. Home, el EJB Object se llamará Account y el EJBean se llamará Account. Bean y el objeto que representa a la clave primaria se llamará Account. PK • Para un un método de creación en el Account. Home de la siguiente forma: – public Account create(String id, String nomb). . . • le corresponderá un método en el Account. Bean de las siguiente forma: – public Account. PK ejb. Create(String id, String nomb). . • El método remove() se puede aplicar tanto al EJB object como al home object, en ambos casos se terminará llamando a ejb. Remove() que debe hacerse cargo de borrar el dato de la base de datos
- Slides: 21