EJBS PERSISTENCIA MAPEO OBJETO RELACIONAL

Los componentes principales de un Application Server son:

"Servlet Engine" (Web-Container), donde residen y se ejecutan JSP's y Servlet's; y "Enterprise Bean Engine" (Bean-Container), donde se ejecutan EJB's.

Ciclo de Ejecucin Estructura y Componentes Adicionales. Codificacin del EJB. Codificacin del Cliente para EJB. Ejemplos:
TimerSessionBean: Stateless session bean que establece un timer. HelloServiceBean: Stateless session bean que implementa un servicio Web. CartBean: Stateful session bean que es accedido por un cliente remoto.

La estructura bsica de EJB's es slo una parte necesaria para la ejecucin exitosa de un EJB. A continuacin se mencionan otros componentes necesarios:
Stubs y Skeletons Libreras (JAR's) Propietarias Codificacin de un Session (Stateless) EJB.

La comunicacin entre el cliente y el "EJB Container" se lleva a cabo mediante procedimientos remotos (va RMI/IIOP), lo que implica que tanto el cliente como el "EJB Container" pueden residir en distintos "Hosts. De aqu surge una pregunta clsica en ambientes distribuidos:
La manera en que el cliente se entera de esto es a travs de un Stub. Un Stub proporciona una estructura al cliente que describe los elementos definidos en Servidor, en este caso el EJB. Este Stub es generado por una herramienta proporcionada por el Application Server quien debe estar accesible al Cliente que intenta comunicarse con el "EJB"/Application Server.
Cmo sabe el cliente la definicin del EJB? Cmo sabe que mtodos llamar?

El Skeleton es la contra parte del Stub que reside en el Servidor. Para efectos de EJB's, este componente es llevado a cabo a travs del "Home Interface" y "Remote Interface". Aunque es importante conocer el uso de Stubs y Skeletons en EJB's, generalmente la comunicacin entre el Cliente y EJB es llevada automticamente y sin mayor preocupacin debido a que tanto el "EJB Container" y "Servlet Container" se encuentran en la misma estructura del Application Server y por ende en el mismo "Host". Uno de los casos donde resulta crtico tomar en consideracin el uso de Stubs y Skeletons es cuando se posee un ambiente de Cluster, lo cual implica que existe comunicacin entre diversos Application Servers en diversos "Hosts".

Adems de estos Stubs y Skeletons, tambin existen diversas libreras que son proporcionadas en los diferentes Application Servers. Estas libreras (Archivos JAR) deben estar accesibles al Cliente o Servidor segn lo requiera el servidor.

"Remote Interface: Se describen los mtodos que sern empleados por el EJB.
Siempre se hereda ("inherit") la implementacin de EJBObject. Todos los mtodos definidos deben declarar la posibilidad de generar el error ("exception") RemoteException, la cual puede ser invocada al ocurrir un error al nivel de Red.

"Home Interface: Define los mtodos utilizados para la creacin/destruccin del mismo: interfase administrativa para el EJB.

Siempre se hereda ("inherit") la implementacin de EJBHome. Todos los mtodos definidos deben declarar la posibilidad de generar el error ("exception") RemoteException, la cual puede ser invocada al ocurrir un error al nivel de Red. El mtodo create, que genera la instancia del EJB, debe declarar la posibilidad de la excepcin CreateException, la cual le indicara al cliente la inhabilidad de crear el EJB.

"Enterprise Bean Class: Definidas las interfases, es posible implementar el EJB en s. La implementacin utiliza la clase SessionBean. Debido a esto, es necesario implementar todos aquellos mtodos definidos en SessionBean:

ejbCreate: Invocado al crearse una instancia del EJB. ejbRemove: Llamado para eliminar una instancia del EJB. ejbPassivate: Este mtodo es utilizado para guardar "x" instancia de un EJB a memoria secundaria ("Disco Duro/Swap"). Esto puede ocurrir cuando los recursos del Application Server/"EJB Container" sean excedidos y sea necesario reubicar (pasivar) ciertos elementos fuera de ste. ejbActivate: Este mtodo es invocado cuando se desea recuperar la instancia de un EJB de memoria secundaria. setSessionContext: Mtodo utilizado para mantener cierta informacin de sesin respecto al EJB.

"Deployment Descriptor: ltima parte a definir en la generacin de un EJB. Se definen los nombres de cada parte del EJB en conjuncin con otros parmetros, de especial importancia es el parmetro ejbname el cual indicar el nombre asociado con este EJB y que eventualmente ser publicado por el "Servidor de Nombres" JNDI/LDAP.

Finalmente es necesario agrupar todos los componentes del EJB en un archivo JAR, al igual que el "Deployment Descriptor. La creacin de este archivo EJB-JAR generalmente se lleva acabo mediante herramientas proporcionadas con el Application Server.

Para interactuar con el Session Bean es necesario crear un cliente: aplicacin Java de consola, JSP/Servlet o Applet.

Ciclos de vida de los Session (Stateless Statefull) Beans

A diferencia del Session EJB, existe otro tipo de Session EJB sub-clasificado Stateful. Como su nombre lo indica, este tipo de EJB mantiene un estado ("state") para el cliente (JSP/Servlet). Al utilizar un Stateless EJB, el Cliente lo invoca una sola vez y posteriormente no mantiene ningn tipo de estado conversacional entre ste. Esto implica que el EJB no mantiene registro alguno del Cliente. En un Stateful EJB, el EJB como tal mantiene informacin acerca del Cliente (JSP/Servlet) que lo ha llamado. Aunque este tipo de EJB resulta til para cierta clase de diseos, en tiempos recientes su uso ha sido criticado por la simple razn de que tambin es posible mantener este mismo estado ("state") dentro de un JSP o Servlet.

Una de las razones por las que se opta por mantener estado ("state") dentro de un JSP/Servlet en lugar de en un EJB es debido al nivel de complejidad que conlleva disear ste ltimo. Aunque es recomendable evitar el uso Session Stateful EJB's, existen casos en los que es ideal mantener estado ("state") del cliente dentro del EJB. Este caso resulta cuando el EJB interacta con sistemas de informacin como Bases de Datos o ERP's. Este mecanismo forma el principio de los Entity EJB's que sern descritos a continuacin.

En general, se debe utilizar un Bean de Sesin, si las circunstancias siguientes se cumplen:

En cualquier momento dado, un solo cliente tiene acceso a la instancia del bean. El estado del bean no es persistente, que existe slo durante un corto perodo de tiempo (tal vez un par de horas). El bean implementa un servicio web.

Los Beans de Sesin con Estado (Stateful) son apropiados si alguna de las condiciones siguientes:

El estado de los beans representa la interaccin entre el bean y un cliente especfico. El bean debe contener informacin sobre el cliente a travs de llamadas a mtodos. Los bean son intermediarios entre el cliente y los otros componentes de la aplicacin, que presenta una vista simplificada para el cliente.

Para mejorar el rendimiento, puede optar por un Bean de sesin sin estado (Stateless) si tiene alguno de estas situaciones:
El estado del bean no tiene datos para un cliente especfico. En una sola invocacin de mtodo, el bean realiza una tarea genrica para todos los clientes. Por ejemplo, podra utilizar se un bean de sesin sin estado para enviar un correo electrnico que confirma un pedido en lnea. El Bean obtiene a partir de una base de datos un conjunto de datos de slo lectura que se utiliza a menudo por los clientes. Tal como un bean, por ejemplo, que pudiera recuperar las filas de la tabla que representan los productos que estn a la venta este mes.

Ciclo de Ejecucin Localizacin y Sincronizacin Tipos de Entity Beans Mapeo Objeto/Relacional

Ciclo de vida de un Entity Bean

El ciclo de ejecucin para un Entity EJB, aunque similar al de un Session EJB, vara en que debe interactuar con un depsito de Informacin ajeno al Application Server, tpicamente una Base de Datos.

La primer diferencia de un Entity EJB comparado con un Session EJB es el concepto de bsqueda sobre un posible EJB existente. La razn de esto es ms clara analizando el funcionamiento de ambos tipos de EJB's: Al utilizar un Session bean en su modalidad de "Stateless, no existe ningn tipo de estado (como su nombre lo implica) para el cliente que interacta con el EJB. Esto es: la interaccin entre ambos no requiere de conocimiento previo, se invoca el EJB y la operacin se da por terminada y si fuera necesario reinvocar al EJB, las acciones anteriores no son de inters.

Cuando se interacta con depsitos de informacin mediante EJB's , lo anterior merece varias consideraciones:

Al crearse un EJB para manipular informacin residente en Bases de Datos, se trae una copia de sta al EJB. Dicha informacin puede variar desde datos personales, cuentas bancarias o cualquier otro tipo que sea conveniente persistir a travs del tiempo. Es aqu donde se hace ms clara la necesidad de localizacin.

 Cuando el cliente (JSP/Servlet) genera un "Entity EJB, ste seguramente volver hacer uso del EJB. Tomando el caso de una cuenta bancaria, el cliente puede invocar una operacin sobre la informacin de "x" cuenta. Si posteriormente se deseara invocar otra operacin sobre estos datos, no slo sera excesivo volver a extraer la informacin de la Base de Datos, sino ilgico, puesto que ya estn en el Application Server/"EJB Container".

La manera en que son re-localizados EJB's ya creados es a travs de mtodos de bsqueda, denominados finder methods. Estos finder methods pueden ser de cualquier tipo imaginable ya que son diseados por el creador del EJB, dependiendo de la informacin estos pueden ser: findEnRango, findByPrimaryKey, findPorApellido, etc. El vocablo find es utilizado como una convencin para distinguir su uso. Estos mtodos son declarados en el Home Interface del EJB.

La sincronizacin de informacin entre el EJB y el depsito de informacin es otra propiedad de un Entity EJB. Su importancia se debe a las caractersticas de los datos residentes en Bases de Datos. En el caso de una cuenta bancaria: si esta informacin es manipulada a travs de un EJB, es de suma importancia que sea sincronizada con aquella de la Base de Datos. Suponga que el EJB deduce "x" cantidad de dinero a una cuenta, debido a que es posible que la informacin residente en una Base de Datos sea manipulada por otro sistema (Sucursal o Cajero automtico), es conveniente sincronizar de inmediato este tipo de operaciones para asegurarse que el juego de datos en el EJB no ha cambiado respecto al depsito central.

Este mismo caso se puede suscitar si despus de un lapso extenso de tiempo se desea manipular un "Entity EJB. En este caso, siempre es conveniente re-cargar (sincronizar) la informacin del EJB con aquella de la Base de Datos para asegurarse que no ha cambiado desde la creacin inicial del EJB. La sincronizacin de informacin se lleva acabo a travs de dos mtodos que deben ser implementados en todo "Entity EJB": ejbLoad y ejbStore. ejbLoad es utilizado para traer informacin del depsito hacia el EJB y ejbStore es para llevar los datos del EJB hacia la Base de Datos. Cuando y quin invoca ejbStore y ejbLoad? Las dos situaciones son al crear y al destruir el "Entity EJB

Sin embargo, ambos tambin pueden ser invocados al realizarse una manipulacin crtica como las mencionadas anteriormente. En este caso, el llamar estos mtodos es un tema fuertemente relacionado con Transacciones en EJB's. Finalmente cabe mencionar que un cliente (JSP/Servlet) jams invoca estos mtodos directamente, sino que la tarea es delegada al Application Server para ser invocados segn se hayan definido las transacciones correspondientes, tema que es descrito posteriormente en esta presentacin.

Existen dos tipos de "Entity EJB's" denominados "CMP (Container Managed Persistence)" y "BMP (Bean Managed Persistence) La diferencia entre ambos estriba en la manera en que se accede a la informacin residente en la Base de Datos. En "BMP (Bean Managed Persistence)" es necesario escribir toda la lgica de acceso para la Base de Datos. Esta lgica escrita a travs del API JDBC implica contemplar diversos aspectos de codificacin como parmetros, variables, algoritmos, y otros detalles. Si el EJB realiza interacciones complejas con la Base de Datos, este cdigo no solo puede ser complejo de escribir sino difcil de mantener actualizado.

En "CMP (Bean Managed Persistence)" la lgica de acceso hacia la Base de Datos es generada por el Application Server/"EJB Container. Si bien suena como una maravilla, este mecanismo tiene sus desventajas comparado con un "BMP:
El primer aspecto, que es la ventaja de generar cdigo automtico, es balanceado por la necesidad de contemplar y conocer a detalle configuraciones del Application Server requeridas para emplear "CMP. La otra desventaja es que como el cdigo es generado automticamente, no existe la posibilidad de afinarlo. El que sea generado cdigo JDBC no implica que ha sido utilizado el mejor algoritmo para el trabajo.

Una consideracin muy importante y en ocasiones no contemplada lo suficiente en desarrollos de "Entity EJB's", es la discrepancia que existe del mundo Java (Objetos) al mundo de Base de Datos (Relacional). En Java la informacin es manipulada a travs de Objetos: entidades que describen las caractersticas y el comportamiento de determinada fuente, sean: personas, productos, cuentas bancarias u otro ente. En el mundo de Bases de Datos (Relacionales) empleadas desde hace dcadas en distintas industrias para guardar informacin, los datos no residen en objetos, sino en Tablas conformadas por Columnas y Renglones. El problema que surge al interactuar Objetos (Java) con Bases de Datos (Relacionales) es que no existe un mapeo directo entre ambos: es posible que un Objeto compuesto por diversos valores requiera interactuar con dos o tres tablas relacionales para lograr el comportamiento deseado. Esta discrepancia entre el mundo de Objetos (Java) y el relacional (SQL) es conocida como Impedance Mismatch.

Para proyectos pequeos de EJB's, este mapeo es realizado directamente por un programador. Para proyectos de gran tamao, esto puede resultar incosteable e ineficiente. Hoy da existen varios productos que realizan este mapeo rpida y eficientemente, adems de ofrecer otras funcionalidades como "Cache's", "Pooling" hacia la Base de Datos y otros mecanismos ms. Actan como una capa adicional entre el Application Server/"EJB Container" y la Base de Datos. Dos productos son:
Hibernate: un proyecto basado en Software libre CocoBase de Thought Inc.

El mapeo Objeto/Relacional es la persistencia automatizada y transparente de las tablas en una Base de Datos relacional, usando metadatos que definen el mapeo entre los objetos y la Base de Datos"

Entre las estrategias posibles para mapear las relaciones de herencia encontramos: Mapear la jerarqua de clases a una sola tabla. Mapear cada clase concreta a su propia tabla. Mapear cada clase a su propia tabla.

Ahora, que sucede con la evolucin del modelo. Al agregar la clase Ejecutivo es necesario agregar el campo "bonificacion: decimal" a la tabla. Y definirlo como nullable!! porque los registros correspondientes a Cliente o Empleado no definen un valor para la bonificacin

Ventajas - Es un enfoque simple que permite agregar nuevas clases de forma sencilla (solo agregar columnas). - Soporta polimorfismo mediante inspeccin del valor del campo discriminador. - Provee acceso muy eficiente a los datos (Sin JOINS). Desventajas - Alto acoplamiento con la jerarqua de clases ya que todas se persisten en la misma tabla. Un cambio en la jerarqua afecta a todas. - Potencial desperdicio de espacio en la base de datos, por campos irrelevantes a la clase. Por ejemplo al tener que grabar un valor por defecto para la bonificacin al grabar un Cliente. - Impide la definicin de restricciones dado que hay campos que deben quedar en null o en un valor por defecto si no corresponden a la clase de la instancia que se est grabando. - Si la jerarqua es muy grande obtengo tablas muy grandes (con muchos campos).

Cundo usar? Buena estrategia para clases simples o jerarquas poco profundas, dnde los tipos de la jerarqua no se solapan.

A simple vista podemos observar que un Empleado ascendido a Ejecutivo requerir copiar sus datos de la tabla Empleado a la tabla Ejecutivo, incluso es posible que sea necesario mantener la informacin redundante en las dos tablas para no afectar los procesos de negocios que manipulan Empleado.

Ventajas - Reportes fciles de obtener ya que todos los datos necesarios sobre una clase particular se encuentran almacenados en una sola tabla. - Buena performance para acceder a datos de un objeto simple (sin asociaciones no es necesario el JOIN). Desventajas - Poco escalable, si se modifica la clase base se debe modificar en todas las tablas de las clases derivadas para reflejar ese cambio (Ej. Agregar una columna direccin en la Persona implica modificar todas las tablas). - Actualizacin compleja, si un objeto cambia su rol (se contrata un Cliente como Empleado) se le asigna un nuevo OID9 y es necesario copiar todos sus datos a la tabla apropiada. - Dificultad para soportar mltiples roles y mantener integridad de datos.

Cundo usar? - Cuando la jerarqua de clases es muy estable (las clases raramente cambian). - Cuando no existe solapamiento de tipos.

En este caso para recuperar los datos de un Ejecutivo es necesario realizar el JOIN entre Persona, Empleado y Ejecutivo.

Ventajas - Fcil de entender, porque es un mapeo uno a uno. - Soporta muy bien el polimorfismo, ya que tiene almacenado los registros en la tabla correspondiente. - Fcil de modificar superclases y agregar nuevas subclases (implica modificar o agregar una sola tabla). - Modelo muy normalizado en el cual el tamao de los datos crece en proporcin directa al nmero de objetos (instancias) persistidos. Desventajas - Muchas tablas en la base de datos (una por clase + tablas de relacin). - Menor perfomance, pues se necesita leer y escribir sobre varias tablas. - Reportes rpidos difciles de armar, debido a la necesidad de JOINS, a menos que se agreguen vistas para simular las tablas deseadas.

Cundo usar? - Cuando hay solapamiento de tipos. - Cuando las modificaciones a las clases son frecuentes. - Cuando se quiere evitar la redundancia de datos.

Curso Java EJB's

Enterprise JavaBeans Specification, Version 2.1 (EJB

specification) The J2EE 1.4 Tutorial for NetBeans IDE 4.1

Designing Enterprise Applications with the J2EE Platform, Second Edition. I. Singh, B. Stearns, M.

Johnson, Enterprise Team. Copyright 2002, AddisonWesley. (archivo: designing_enterprise_apps-2_0book.PDF)

J2EE Connector Architecture Specification, Version 1.5 (Connector specification) Java Message Service Specification, Version 1.0.2
(JMS specification)