Transcript Java2_12 EJB
ACI – 843 JAVA II
Clase 12: Introducción a
Enterprise Java Beans
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 1
Contenidos
• Java Application Servers • EAR's ("Enterprise Archives"), IDE's y Deployment Descriptors. • Enterprise Java Beans: EJB's • Session EJB's (Stateful y Stateless) • Entity EJB's • BMP "Bean Managed Persistence" • CMP "Container Managed Persistence" • Messaging Beans • Otros Conceptos • Patrones de Diseño ("Design Patterns") 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 2
Java Application Servers
• 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.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 3
EAR's ("Enterprise Archives"), IDE's y Deployment Descriptors • EARS, WAR's, EJB-JAR's. • Herramientas e IDE's • Deployment Descriptors
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 4
EARS ("Enterprise Archives")
• Terminología utilizada para describir componentes en Application Servers. • Un EAR es simplemente un EJB junto con el respectivo cliente que interactúa con él.
• La razón de su existencia se debe a la estructura de los diversos Application Servers.
• Como fue mencionado al inicio, no existe una clara distinción entre los componentes de un Application Server: el "EJB Container" y el "Servlet Container“. • Por esta razón se decidió crear el formato EAR ("Enterprise Archive") el cual esta compuesto por un EJB-JAR y un "WAR (Web-Archive)".
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 5
EJB-JAR's
• Un EJB-JAR es la agrupación de las interfases ("Home" y "Remote"), el "EJB Bean" y "Deployment Descriptor“.
• Su estructura es: – / *.class : Bajo este directorio base se encuentran las diversas clases que conforman un EJB. – /META-INF/ejb-jar.xml : Este archivo contiene el denominado Deployment Descriptor utilizado en EJB's.
– /META-INF/* : Este directorio, además del Deployment Descriptor, puede contener otros archivos de configuración utilizados por el Application Server ("EJB Container" para ser exactos).
Estructura de un EJB JAR en NetBeans 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 6
Convenios de denominación
Item
Enterprise bean name (DD 1 )
Syntax
<
name
>Bean
Example
AccountBean EJB JAR display name (DD) <
name
>JAR Enterprise bean class Home interface Remote interface <
name
>Bean <
name
>Home <
name
> AccountJAR AccountBean AccountHome Account Local home interface <
name
>LocalHome AccountLocalHome Local interface Abstract schema (DD) <
name
> <
name
> Local AccountLocal Account 1 DD significa que el ítem es elemento en el descriptor de despliegue. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 7
WAR's
• "WAR (Web-Archive)" es el componente que interactúa con el EJB.
• Como hemos estudiado, un WAR es un grupo de JSP/Servlets.
• La estructura de un WAR es: – / *.html *.jsp *.css : Este directorio base contiene los elementos que comúnmente son utilizados en un sitio: documentos en HTML, JSP's , CSS ("Cascading Style Sheets") u otros elementos. – /WEB-INF/web.xml : Contiene elementos de seguridad de la aplicación así como detalles sobre los Servlets que serán utilizados dentro de la misma.
– /WEB-INF/classes/ : Contiene las clases Java adicionales a las del JDK que son empleadas en los JSP's y Servlets – /WEB-INF/lib/ : Contiene los JAR's que serán utilizados por la aplicación. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 8
EAR's
• Finalmente la estructura de un EAR ("Enterprise Archive") es: • /*.jar : Archivo que conforma el EJB-JAR. • /*.war : Archivo que conforma el "Web-Archive" que contiene los clientes (JSP/Servlets) que interactúan con el EJB-JAR. • /META-INF/application.xml : Este archivo contiene el denominado Deployment Descriptor utilizado en un EAR ("Enterprise Archive") . • /META-INF/* : Este directorio, además del Deployment Descriptor, puede contener otros archivos de configuración utilizados por el Application Server para la ejecución correcta del EAR. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 9
Herramientas e IDE's
• Independientemente del Application Server que se esté utilizando, seguramente existirá una herramienta que automatiza ciertos pasos de la creación de un EJB. • El grado de automatización puede variar desde el "Deployment Descriptor" hasta la creación de WAR's y EAR's.
• Desde luego presentan una gran ventaja. Por ejemplo: un "Deployment Descriptor" puede contener 100 o 200 líneas de código que puede tomar horas en escribir. Esto puede ser reducido con estas herramientas a unos cuantos minutos al contestar una serie de preguntas.
• A pesar de sus ventajas, muchas de estas herramientas ofrecen funcionalidades mínimas, por no llamarlas austeras. • Hoy en día ya existen diversos IDE's ("Integrated Development Environments") que permiten no sólo las tareas anteriores, sino que también agilizan la creación de código fuente para EJB's tales como: creación de Interfases, conexiones hacia Bases de Datos y otras facilidades más.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 10
Algunos IDE's
• • • • • • NetBeans Eclipse Sun Java Studio Creator JBuilder WebSphere Studio JDeveloper Open-Source Open-Source Sun Borland IBM Oracle
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 11
"Deployment Descriptor"
• El "Deployment Descriptor" es la única parte del EJB que puede ser modificada una vez que ha sido compilado.
• Como su nombre lo indica, su uso primordial es al ejecutar ("deploy") del EJB en el Application Server/"EJB Container“, ya que permite ajustar diversos parámetros del EJB según sea requerido.
• Sin duda alguna esta parte del EJB seguirá cobrando mayor importancia conforme vayan surgiendo versiones futuras de "Enterprise Java Beans“.
• Los primeros diseños de EJB's colocaban información mínima en este archivo.
• Hoy en día no sólo ha incrementado el nivel de información colocada en él, sino que los diversos Application Servers/"EJB Containers" han agregado otros archivos de configuración aledaños.
• Algunos de estos archivos son utilizados para alterar el nombre JNDI otorgado al EJB, para configuraciones especificas como "Caches" o "Pooling" del Application Server/"EJB Container", para Mapeo Objeto/Relacional y otras funcionalidades más. • Existen herramientas como Java 5 / JDK 1.5 versiones J2EE-EJB 3.0
Xdoclet , basadas en código abierto, que permiten colocar anotaciones - meta-datos - dentro de las estructuras del EJB para agilizar la creación de Deployment Descriptors. • Esta misma funcionalidad de anotaciones ha pasado a formar parte de y ejercerá su respectiva influencia en las nuevas 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 12
EJB's • Razón de ser. • Java Application Servers. • Tipos de EJB's. • Estructura de un EJB.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 13
Enterprise Java Beans (EJBs)
• Componente principal del grupo de especificaciones J2EE definidas por Sun. • Un Enterprise Bean es una componente escrita en el lenguaje de programación Java y ubicada en un servidor donde se encapsula la lógica de negocios de una aplicación.
• La lógica de negocios es el código que cumple el propósito de la aplicación. Invocando esos métodos, los clientes remotos pueden acceder al inventario de servicios suministrado por la aplicación. • A través de ellos se define una estructura ("Framework") en la cual es posible manipular e interactuar con procesos e información que residen en diversos ambientes computacionales, desde "MainFrames" hasta Bases de Datos. • Estos componentes (EJB's) contemplan diversas características esperadas de una aplicación empresarial como: Control de Transacciones, Seguridad, Threading, Propagación de Transacciones, y otras funcionalidades.
• Dichos componentes son ejecutados dentro de un Application Server.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 14
Beneficios del uso de EJBs
Simplifican el desarrollo de aplicaciones distribuidas grandes: 1. Dado que el contenedor EJB suministra servicios a nivel de sistema a los enterprise beans, el desarrollador puede concentrarse en resolver sólo sus problemas de negocios. El contenedor EJB – y no el programador del bean- es responsable por los servicios a nivel del sistema tales como manejo de transacciones y autorizaciones de seguridad. 2. Dado que los beans, no los clientes, contienen la lógica de negocios de la aplicación, el desarrollador del cliente puede enfocarse en el aspecot de la presentación al cliente. No tiene que programar las rutinas que implementan las reglas del negocio ó los accesos a bases de datos. Como resultado, los clientes son livianos, lo que es un beneficio particularmente importante para aplicaciones cliente que se ejecutan en dispositivos pequeños. 3. Dado que los enterprise beans son componentes portables, el armador de aplicaciones puede desarrollar nuevas aplicaciones empleando beans existentes. Esas aplicaciones pueden ejecutarse sobre cualquier servidor que cumpla las especificaciones J2EE, debido a que se emplean las APIs estandarizadas. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 15
Cuando es apropiado usar EJBs
• Debe considerarse su empleo si la aplicación tiene alguno de los requerimientos siguientes: • Escalabilidad. Para acomodar a un número creciente de usuarios puede ser necesario distribuir los componentes de la aplicación entre varias computadoras. Los EJBs pueden ejecutarse en diferentes equipos de manera que resultará transparente a los clientes.
• Las Transacciones deben garantizar integridad de los datos. Los EJBs soportan transacciones: mecanismos que manejan el acceso concurrente a objetos compartidos.
• La aplicación tendrá variedad de clientes. Los clientes remotos pueden localizar fácilmente EJBs con pocas líneas de código. Dichos clientes pueden ser livianos, variados y numerosos.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 16
Tipos de EJB's.
• Session EJB's: Permite realizar cierta lógica solicitada por un cliente, ya sea un JSP/Servlet, Applet ó inclusive otro EJB. Existen dos tipos: – Stateless (Session) EJB's – Statefull (Session) EJB's • Entity EJB's: Trabaja conjuntamente con un depósito de información (Base de Datos). Manipula información residente en sistemas ajenos. También existen dos tipos: – (Entity) Bean Managed Persistence – (Entity) Container Managed Persistence • Messaging EJB's: Ofrece las funcionalidades de sistemas "Messaging“: intermediario para recibir y publicar mensajes; que opera en forma asincrónica. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 17
Estructura de un EJB
• Un EJB, con la excepción de los Messaging EJB's, está compuesto por cuatro partes: 1. "Enterprise Bean Class“: Clase donde se encuentran definidas toda las funciones utilizadas por el EJB, sean procedimientos rutinarios o con lógica hacia bases de datos. Aquí reside todo el código funcional que realiza operaciones en Java, desde la activación del EJB hasta su destrucción incluyendo las funciones de negocios para las que fue diseñado. 2. "Home Interface“: Define un esqueleto para funciones utilizadas en la "Enterprise Bean Class“. Sólo contiene las declaraciones para funciones necesarias en la creación-activación del EJB's. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 18
Estructura de un EJB (2)
3. "Remote Interface": Contiene las declaraciones para las funciones de negocios definidas en la "Enterprise Bean Class“. Sólo el "esqueleto" de las funciones. El número de declaraciones dependerá de las funciones declaradas en la "Enterprise Bean Class". 4. "Deployment Descriptor“: Archivo en XML que cumple varias funciones: • • Parametrizar el código Java del "Enterprise Bean Class“: definir parámetros que varían dependiendo del ambiente.
Indica al "EJB Container": el tipo de EJB -Session, Entity, Messaging-; el esquema de seguridad que posee; y en caso de ser un "Container Managed Entity EJB“: las funciones para las que se generará lógica; así como otras funcionalidades. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 19
Manejo de excepciones
• Las excepciones lanzadas por los EJBs pueden ser: 1. System exception: indica un problema con los servicios que sustentan la aplicación.
2. Application exception: Señala un error en la lógica de negocio del bean.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 20
Excepciones del paquete javax.ejb
Method Name
ejbCreate ejbFindByPrimaryKey ( y cualquier otro método buscador find* que devuelva un objeto simple.
) ejbRemove ejbLoad ejbStore (todos los métodos )
Exception It Throws Reason for Throwing
CreateException Parámetro de entrada no válido. ObjectNotFoundE xception ( subclase de FinderExcept ion) The database row for the requested entity bean cannot be found. RemoveException The entity bean's row cannot be deleted from the database. NoSuchEntityExc eption The database row to be loaded into the entity bean cannot be found. NoSuchEntityExc eption The database row to be updated cannot be found. EJBException Se encontró un problema en el sistema. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 21
Session EJB's (Stateful y Stateless)
• Ciclo de Ejecución • Estructura y Componentes Adicionales. • Codificación del EJB. • Codificación 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. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 22
Ciclo de Ejecución
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 23
Estructura y Componentes Adicionales • La estructura básica de EJB's es sólo una parte necesaria para la ejecución exitosa de un EJB.
• A continuación se mencionan otros componentes necesarios:
– Stubs y Skeletons – Librerías (JAR's) Propietarias – Codificación de un Session (Stateless) EJB.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 24
Stubs
• La comunicación entre el cliente y el "EJB Container" se lleva a cabo mediante procedimientos remotos (vía RMI/IIOP), lo que implica que tanto el cliente como el "EJB Container" pueden residir en distintos "Hosts“. • De aquí surge una pregunta clásica en ambientes distribuidos: – ¿Cómo sabe el cliente la definición del EJB? – ¿Cómo sabe que métodos llamar? • La manera en que el cliente se entera de esto es a través 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. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 25
Skeletons
• 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 través del "Home Interface" y "Remote Interface".
• Aunque es importante conocer el uso de Stubs y Skeletons en EJB's, generalmente la comunicación entre el Cliente y EJB es llevada automáticamente y sin mayor preocupación 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 crítico tomar en consideración el uso de Stubs y Skeletons es cuando se posee un ambiente de Cluster, lo cual implica que existe comunicación entre diversos Application Servers en diversos "Hosts".
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 26
Librerías (JAR's) Propietarias • Además de estos Stubs y Skeletons, también existen diversas librerías que son proporcionadas en los diferentes Application Servers.
• Estas librerías (Archivos JAR) deben estar accesibles al Cliente o Servidor según lo requiera el servidor.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 27
Codificación de un Session (Stateless) EJB
• "Remote Interface“: Se describen los métodos que serán empleados por el EJB. – Siempre se hereda ("inherit") la implementación de EJBObject.
– Todos los métodos 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 métodos utilizados para la creación/destrucción del mismo: interfase administrativa para el EJB. – Siempre se hereda ("inherit") la implementación de EJBHome. – Todos los métodos 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 método create, que genera la instancia del EJB, debe declarar la posibilidad de la excepción CreateException, la cual le indicaría al cliente la inhabilidad de crear el EJB. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 28
Codificación de un Session (Stateless) EJB (2)
• "Enterprise Bean Class“: Definidas las interfases, es posible implementar el EJB en sí. La implementación utiliza la clase SessionBean. Debido a esto, es necesario implementar todos aquellos métodos definidos en SessionBean: – ejbCreate: Invocado al crearse una instancia del EJB.
– ejbRemove: Llamado para eliminar una instancia del EJB.
– ejbPassivate: Este método 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 método es invocado cuando se desea recuperar la instancia de un EJB de memoria secundaria. – setSessionContext: Método utilizado para mantener cierta información de sesión respecto al EJB.
• "Deployment Descriptor“: Última parte a definir en la generación de un EJB. Se definen los nombres de cada parte del EJB en conjunción con otros parámetros, de especial importancia es el parámetro ejb-name el cual indicará el nombre asociado con este EJB y que eventualmente será publicado por el "Servidor de Nombres" JNDI/LDAP. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 29
Creación del EJB (Archivo JAR) y Ejecución ("Deployment")
• Finalmente es necesario agrupar todos los componentes del EJB en un archivo JAR, al igual que el "Deployment Descriptor“.
• La creación de este archivo EJB-JAR generalmente se lleva acabo mediante herramientas proporcionadas con el Application Server.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 30
Codificación del Cliente para un Session (Stateless) EJB
• Para interactuar con el Session Bean es necesario crear un cliente: aplicación Java de consola, JSP/Servlet o Applet.
Ciclos de vida de los Session (Stateless – Statefull) Beans 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 31
Session (Stateful) EJB
• 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 ningún 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 información acerca del Cliente (JSP/Servlet) que lo ha llamado.
• Aunque este tipo de EJB resulta útil para cierta clase de diseños, en tiempos recientes su uso ha sido criticado por la simple razón de que también es posible mantener este mismo estado ("state") dentro de un JSP o Servlet. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 32
Session (Stateful) EJB (2)
• 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 diseñar é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 interactúa con sistemas de información como Bases de Datos o ERP's.
• Este mecanismo forma el principio de los Entity EJB's que serán descritos a continuación.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 33
When to Use Session Beans
• In general, you should use a session bean if the following circumstances hold: – At any given time, only one client has access to the bean instance.
– The state of the bean is not persistent, existing only for a short period (perhaps a few hours).
– The bean implements a web service. • Stateful session beans are appropriate if any of the following conditions are true: – The bean's state represents the interaction between the bean and a specific client.
– The bean needs to hold information about the client across method invocations.
– The bean mediates between the client and the other components of the application, presenting a simplified view to the client.
• To improve performance, you might choose a stateless session bean if it has any of these traits: – The bean's state has no data for a specific client.
– In a single method invocation, the bean performs a generic task for all clients. For example, you might use a stateless session bean to send an email that confirms an online order.
– The bean fetches from a database a set of read-only data that is often used by clients. Such a bean, for example, could retrieve the table rows that represent the products that are on sale this month.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 34
Entity EJB's • Ciclo de Ejecución • Localización y Sincronización • Tipos de Entity Beans • Mapeo Objeto/Relacional
Ciclo de vida de un Entity Bean 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 35
Ciclo de ejecución
El ciclo de ejecución para un Entity EJB, aunque similar al de un Session EJB, varía en que debe interactuar con un depósito de Información ajeno al Application Server, típicamente una Base de Datos. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 36
Localización
• La primer diferencia de un Entity EJB comparado con un Session EJB es el concepto de búsqueda sobre un posible EJB existente. • La razón de esto es más clara analizando el funcionamiento de ambos tipos de EJB's: • Al utilizar un Session bean en su modalidad de "Stateless“, no existe ningún tipo de estado (como su nombre lo implica) para el cliente que interactúa con el EJB. • Esto es: la interacción entre ambos no requiere de conocimiento previo, se invoca el EJB y la operación se da por terminada y si fuera necesario reinvocar al EJB, las acciones anteriores no son de interés. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 37
Localización (2)
• Cuando se interactúa con depósitos de información mediante EJB's , lo anterior merece varias consideraciones: – Al crearse un EJB para manipular información residente en Bases de Datos, se trae una copia de ésta al EJB. Dicha información puede variar desde datos personales, cuentas bancarias o cualquier otro tipo que sea conveniente persistir a través del tiempo. Es aquí donde se hace más clara la necesidad de localización.
– 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 operación sobre la información de "x" cuenta. Si posteriormente se deseara invocar otra operación sobre estos datos, no sólo sería excesivo volver a extraer la información de la Base de Datos, sino ilógico, puesto que ya están en el Application Server/"EJB Container". 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 38
Localización (3)
• La manera en que son re-localizados EJB's ya creados es a través de métodos de búsqueda, denominados finder methods. • Estos finder methods pueden ser de cualquier tipo imaginable ya que son diseñados por el creador del EJB, dependiendo de la información estos pueden ser: findEnRango, findByPrimaryKey, findPorApellido, etc. • El vocablo find es utilizado como una convención para distinguir su uso. • Estos métodos son declarados en el Home Interface del EJB.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 39
Sincronización
• La sincronización de información entre el EJB y el depósito de información es otra propiedad de un Entity EJB. • Su importancia se debe a las características de los datos residentes en Bases de Datos.
• Regresando al caso de una cuenta bancaria: si esta información es manipulada a través 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 información residente en una Base de Datos sea manipulada por otro sistema (Sucursal o Cajero automático), es conveniente sincronizar de inmediato este tipo de operaciones para asegurarse que el juego de datos en el EJB no ha cambiado respecto al depósito central.
• Este mismo caso se puede suscitar si después de un lapso extenso de tiempo se desea manipular un "Entity EJB“. En este caso, siempre es conveniente re-cargar (sincronizar) la información del EJB con aquella de la Base de Datos para asegurarse que no ha cambiado desde la creación inicial del EJB.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 40
Sincronización (2)
• La sincronización de información se lleva acabo a través de dos métodos que deben ser implementados en todo "Entity EJB": ejbLoad y ejbStore. – ejbLoad es utilizado para traer información del depósito hacia el EJB y – ejbStore es para llevar los datos del EJB hacia la Base de Datos. EJB“ ¿Cuando y quién invoca ejbStore y ejbLoad?
• Las dos situaciones obvias son al crear y al destruir el "Entity • Sin embargo, ambos también pueden ser invocados al realizarse una manipulación crítica como las mencionadas anteriormente.
• En este caso, el llamar estos métodos es un tema fuertemente relacionado con Transacciones en EJB's. • Finalmente cabe mencionar que un cliente (JSP/Servlet) jamás invoca estos métodos directamente, sino que la tarea es delegada al Application Server para ser invocados según se hayan definido las transacciones correspondientes, tema que es descrito posteriormente en esta presentación.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 41
Tipos de Entity Beans
• 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 información residente en la Base de Datos. • En "BMP (Bean Managed Persistence)" es necesario escribir toda la lógica de acceso para la Base de Datos. Esta lógica escrita a través del API JDBC implica contemplar diversos aspectos de codificación como parámetros, variables, algoritmos, y otros detalles. Si el EJB realiza interacciones complejas con la Base de Datos, este código no solo puede ser complejo de escribir sino difícil de mantener actualizado. • En "CMP (Bean Managed Persistence)" la lógica 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 código automático, 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 código es generado automáticamente, no existe la posibilidad de afinarlo. El que sea generado código JDBC no implica que ha sido utilizado el mejor algoritmo para el trabajo. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 42
Mapeo Objeto/Relacional
• Una consideración 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 información es manipulada a través de Objetos: entidades que describen las características 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 décadas en distintas industrias para guardar información, 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.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 43
Mapeo (2)
• Para proyectos pequeños de EJB's, este mapeo es realizado directamente por un programador.
• Para proyectos de gran tamaño, esto puede resultar incosteable e ineficiente.
• Hoy día existen varios productos que realizan este mapeo rápida y eficientemente, además de ofrecer otras funcionalidades como "Cache's", "Pooling" hacia la Base de Datos y otros mecanismos más.
• Actúan 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. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 44
BMP "Bean Managed Persistence" • Definiciones en Bases de Datos. • Creación de Interfases ("Home Interface" y "Remote Interface"). • Creación del EJB. • Deployment Descriptor del EJB. • Creación del Cliente (JSP/Servlet). • Ejemplo: <INSTALL>/j2eetutorial14/ejb/savings account/
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 45
Definiciones en Bases de Datos • El primer paso antes de diseñar un "Entity EJB" es conocer la información con que se va a interactuar en la Base de Datos.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 46
Creación de Interfases ("Home Interface" y "Remote Interface")
• La creación de interfases es el paso a realizar después de haber hecho el respectivo análisis en UML ("Universal Markup Language") • En ciertos diseños se opta por definir ciertas clases auxiliares para ser utilizadas con las interfases.
• Estas clases, por lo general, son empleadas al generarse errores("Exceptions"), con la intención de ofrecer mayor expresividad a posibles errores generados.
Interfases para un EJB con Acceso Remoto.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 47
Creación del EJB
• La estructura del "Entity EJB" en sí (como otro EJB), contiene la implementación de los métodos definidos en las interfases "Home" y "Remote" de éste. • Sin embargo, debido al comportamiento de un "Entity EJB“, se deben implementar varias funciones que no son empleadas en Session Beans: • ejbLoad : Es un método utilizado para extraer información de la Base de Datos y utilizarla en el EJB. Siempre es invocado al generar el EJB así como antes de iniciar algún método que manipule información crítica.
• ejbStore : Este método es utilizado para guardar información del EJB en la Base de Datos. Su principal uso es sincronizar información manipulada en el EJB para que sea reflejada en la Base de Datos.
• find* : Debido al funcionamiento de "Entity EJB's" es posible que éstos -- EJB's - sean reutilizados y es a través de uno o varios métodos de búsqueda que se realiza esta operación.
• ejbPostCreate : Es un método empleado en "Entity EJB's" que es ejecutado inmediatamente después de ser creado el EJB. Generalmente no contiene ningún tipo de lógica, sin embargo, es necesario declararlo debido a que forma parte de un "Entity Bean".
• setEntityContext y unsetEntityContext: Estos dos métodos aunque no exclusivos de un "Entity EJB" presentan un claro beneficio dentro de estos. Mediante lo que es denominado contexto en el mundo Java, es posible compartir varios recursos comunes entre diversas instancias de EJB's.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 48
Deployment Descriptor del EJB
• El Deployment Descriptor de un EJB es la última pieza necesaria para completar el EJB.
• Como se mencionaba en "Session EJB's“, este archivo XML describe diversos parámetros utilizados por el EJB.
• En el caso de Entity EJB's, resulta sumamente extenso, y aunque codificable manualmente, lo típico es que se genere automáticamente por una herramienta proporcionada con el Application Server/"EJB Container" o mediante un "IDE"(Integrated Development Environment).
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 49
Creación del Cliente • Una vez que el EJB se encuentre activado en el "EJB Container“, es necesario crear un Cliente que interactúe con él.
• Este cliente puede ser un JSP/Servlet o un programa en Java
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 50
CMP "Container Managed Persistence"
• Surgimiento y Consideraciones. • SuperClase/SubClase, "Abstract Schema" y EJB-QL. • Creación de Interfases ("Home Interface" y "Remote Interface"). • Creación del EJB. • Deployment Descriptor del EJB. • Creación del Cliente (JSP/Servlet). • Ejemplo: <INSTALL>/j2eetutorial14/examples/ejb/cm proster/ 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 51
Surgimiento y Consideraciones
• El surgimiento de CMP "Entity Beans“, además de la generación del código automático de acceso (JDBC), tiene sus raíces en las diversas empresas que apoyan EJB's, específicamente aquellas que desarrollan EJB's para terceros: "ISV" Independent Software Vendors. • Suponga que su empresa ha desarrollado un "proceso lógico" en "Entity EJB's" lo suficientemente productivo que decide comercializarlo a otras empresas en el ramo. En este caso, la portabilidad de Java hacia diversos Application Servers no es suficiente, por la simple razón de que Usted no sabe como está definido el modelo de datos en otras empresas.
• Una solución a este problema sería distribuir el código fuente de cada "Entity EJB" para ser modificado. Sin embargo, esto no sólo daría acceso total a un proceso que pudo costar miles de dolares en refinar, sino que también haría difícil el actualizar dichos "Entity EJB's" en versiones futuras debido a la falta de control en código fuente.
• A través de CMP "Entity Beans" es posible dividir efectivamente la lógica de negocios del EJB del acceso al depósito de información, ofreciendo la posibilidad de distribuir binarios de EJB's con la facilidad de definir acceso a Bases de Datos transparentemente.
• Sin embargo, esta transparencia no es del todo gratis.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 52
SuperClase/SubClase, "Abstract Schema" y EJB-QL
• La primera distinción entre un BMP y CMP "Entity Bean" es que la clase principal del EJB en sí (aquella que contiene la implementación) esta subdividida en dos: – una SuperClase definida por el programador del EJB y – una SubClase que es generada por el Application Container/"EJB Container“ • La generación de código automático para acceder al deposito de información debe surgir de ciertas definiciones forzosamente, puesto que: ¿cómo sabrá el Application Server/"EJB Container" que la función insertarSaldo es distinta de insertarNombre o que la función cuentaBancaria se refiere a la tabla llamada tarjetahabientes?
• Esta tarea recae sobre lo que es conocido como "Abstract Schema".
• La última diferencia entre "CMP" y "BMP" se debe a una cualidad especifica de un "Entity EJB“: los métodos de búsqueda.
• Al implementarse estos métodos de búsqueda en "BMP" se define la lógica directamente. Sin embargo, surge la misma incógnita mencionada anteriormente: ¿Cómo sabe el Application Server/"EJB Container" que significa findPorApellido o findByPrimaryKey ? • Para esto se utiliza EJB-QL ("Enterprise Java Bean-Query Language").
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 53
"Abstract Schema" visto desde un alto nivel
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 54
Interfases, EJB, Descriptor y Cliente
Creación de Interfases ("Home Interface" y "Remote Interface").
• • • Las interfases utilizadas para CMP EJB's son idénticas a las utilizadas en BMP EJB's. Esto permite alternar entre implementaciones de CMP y BMP, puesto que el cliente (JSP/Servlet/Applet/Programa) interactúa únicamente con dichas interfases. Una variación que puede ser empleada para interfases es utilizar interfases locales ("Local Interfases"). Aunque su uso no es exclusivo de "Entity Beans“, es una buena opción para ciertos diseños.
Creación del EJB ("CuentaBancaria").
La clase que implementa un "CMP Entity EJB“, a diferencia de aquella empleada en un "BMP Entity EJB“, se encuentra prácticamente nula de código. La generación de código es delegada al Application Server/"EJB Container". Como fue mencionado anteriormente, este código es colocado en una SubClase. Sin embargo, para el programador del EJB, el contenido final de esta SubClase no debe influenciar en ningún aspecto.
Deployment Descriptor del EJB.
En "CMP Entity Beans“, el uso del Deployment Descriptor toma mayor importancia, debido a que es aquí donde se define la lógica de acceso hacia la Base de Datos. Dicha lógica es definida a través de lo que es conocido como Abstract Schema, el cual es descrito en el "Deployment Descriptor“.
• Otro detalle relevante es el mapeo Objeto/Relacional que debe ser llevado acabo para el • "CMP EJB“.
Creación del Cliente.
En los Clientes que interactúan con el "CMP EJB", las operaciones que realizan son muy similares a aquellas utilizadas en el "BMP EJB“. Salvo la diferencia de nombre JNDI otorgado al "CMP EJB" la interacción es igual.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 55
Messaging Beans • Sistemas Messaging. • JMS: Integración de "Sistemas Messaging" a Java. • Diferencias entre Session y Entity EJB's, "Point-to-Point" y "Publish/Subscribe". • Diseño de un Messaging EJB. • Ejemplo: <INSTALL>/j2eetutorial14/examples/e jb/simplemessage/
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 56
Sistemas Messaging
• Para entender como es utilizado y porque surgió un "Messaging Bean" es necesario entrar en detalle sobre lo que es un "Messaging System" en sí.
• Un "Messaging System" permite una conexión flexible entre un Cliente y un Servidor en un Sistema.
• Esta flexibilidad denominada en Inglés "Loosley Coupled" permite que la comunicación entre el Cliente y el Servidor sea llevada de una manera asincrónica también llamada "Non-Blocking": 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 57
Comunicación típica
• El diagrama muestra como se lleva a cabo típicamente la comunicación entre un cliente y un servidor.
• Sin embargo, esta comunicación implica que el servidor debe interactuar directamente con el cliente, lo que ocurre en este tipo de circunstancias es que el cliente se bloquea hasta que el servidor envía una respuesta.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 58
Comunicación asincrónica
• La importancia de una comunicación asincrónica o "Non-Blocking" se hace evidente en sistemas de proceso duraderos o distribuidos.
• Tal sería el caso de un sistema de reservaciones o autorización de tarjetas de crédito: – Imagínese que cuando realizara una compra vía Internet tuviera que esperar a que su tarjeta de crédito fuera autorizada por el sistema bancario en ese instante.
– Esto pudiera durar minutos u horas.
• Es aquí donde los "Sistemas Messaging" juegan un papel importante.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 59
Funcionalidades
• Además de esta funcionalidad asincrónica ("Non Blocking") los sistemas "Messaging" ofrecen otras funcionalidades como: • Prioridad de mensajes: Esto permite que la información sea enviada al servidor en base a ciertos lineamientos. • Publicar/Subscribir : Este mecanismo permite que el mensaje enviado por el cliente pueda ser consumido por más de un servidor.
• Existen otros detalles que conciernen a un "Messaging System“. • Algunos "Messaging Systems" (MOM's) del mercado son: Rendezvous de Tibco, MQSeries de IBM , MSMQ de Microsoft, SmartSockets de Talarian, SonicMQ de Progress y FioranoMQ de Fiorano. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 60
JMS: Integración de "Sistemas Messaging" a Java
• Todos los Sistemas "Messaging" mencionados anteriormente emplean diversas metodologías propietarias para establecer la comunicación entre el Cliente y el Servidor.
• Desde luego esto, no es aceptable a la característica Java de "Write Once-Run Everywhere" (Escribalo una vez ejecutelo en todos lados). Debido a esto, surgió JMS ("Java Messaging Service"). Es a través de este API que es posible escribir Clientes y Servidores en Java y que éstos interactúen con cualquier "Sistema Messaging“. • El principio de JMS es el mismo utilizado para JDBC en Bases de Datos: un Driver que permita interoperabilidad Java.
• En su concepción, JMS sólo fue diseñado para integrar a un "Sistema Messaging" el lenguaje Java. Sin embargo, hoy en día ya han sido agregadas las funcionalidades necesarias para integrar JMS a un "Application Server/EJB Container", las cuales son llevadas a través de un "Enterprise Java Bean" denominado "Messaging Bean".
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 61
Aplicación de mensaje simple
Componentes: AppClient: Aplicación cliente que envía varios mensajes a una cola.
MessageMDB: Un Message-Driven Bean (MDB) que asincrónicamente recibe y procesa los mensajes que han sido insertados en la cola.
La aplicación cliente encola mensajes, y el suministrador JMS (Application Server) despacha los mensajes a las instancias del MDB, las que procesan dichos mensajes. 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 62
Diferencias entre Session y Entity EJB's, "Point-to-Point" y "Publish/Subscribe" • La primera y gran diferencia comparado con un "Session y Entity EJB's" es: – Un "Messaging EJB" no utiliza ninguna interfase ("Home" o
"Remote" ).
• La razón por la cual no posee interfases es que un "Messaging Bean" simplemente procesa mensajes, los cuales no solamente pueden provenir de clientes Java (JSP/Servlets/Applet) sino también de un sistema messaging como los mencionados anteriormente.
• La segunda diferencia es: – Un "Messaging Bean" solo contiene un método de negocios
llamado onMessage().
• Esto se debe a que el "Messaging Bean" sólo consume mensajes, no ejecuta ningún tipo de lógica a diferencia de un "Session EJB" o "Entity EJB" que puede ejecutar diversas operaciones sobre determinada información.
• Otra diferencia es: – Un "Messaging Bean" no posee ningún tipo de estado. • Lo anterior es parte central del funcionamiento "Messaging/Non Blocking“. El mismo principio de "No Bloqueo" hace que el "Messaging EJB" no sea capaz de re-establecer comunicación posterior con el cliente, por ende no posee ningún estado.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 63
"Point-to-Point" y "Publish/Subscribe"
• Al igual que otros EJB's, para un "Messaging EJB" existen dos modalidades las cuales están basadas en las mismas facilidades ofrecidas por un "Sistema Messaging“: 1. "Point-to-Point“, como su nombre (punto a punto) implica, ofrece una metodología sencilla para la transmisión de mensajes. Su funcionamiento es similar a los buzones de voz utilizados hoy en día: se envía un mensaje, el cual es recibido independientemente del estado del destinatario final. Posteriormente, el destinatario final consume el mensaje una vez. El lugar donde es colocado el mensaje es llamado queue. Note el énfasis en que el mensaje es consumido una vez.
2. "Publish-Subscribe“, como diferencia, permite que el mensaje sea consumido en diversas ocasiones. Esta metodología puede ser comparada con los sistemas de televisión por cable: existen diversas señales ("mensajes") publicadas, las cuales pueden ser consumidas por diversos subscriptores. La ubicación donde son colocados estos mensajes es denominada tópico.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 64
Diseño de un Messaging EJB
• Ejemplo: Un "Messaging Bean" del tipo "Publish Subscribe", que recibe mensajes de un Cliente Java y los coloca bajo un topic. • Posteriormente un subscriptor, ya sea un EJB("Session","Entity","Messaging") o JSP/Servlet, puede tomar el mensaje del topic.
• Como todo otro "EJB“, es necesario definir su respectivo "Deployment Descriptor".
• Además es necesario definir valores que están directamente relacionados con el ambiente de ejecución, • Una vez activado ("deployed") el "Messaging EJB", es posible enviar mensajes a éste mediante un cliente que realice esta tarea.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 65
Diseño de un Messaging EJB (2)
• En el cliente, al ser definido InitialContext, no se incluyen los parámetros del servidor JNDI, debido a que estos parámetros son ampliamente utilizados en EJB's, y a que es posible definirlos a través de un archivo especial. Lo anterior evita que todo EJB y sus respectivos clientes definan estos valores manualmente.
• Este mecanismo es definido por Java y no depende del "Application Server/EJB Container“. Al no definirse ningún parámetro en InitialContext, se realiza una búsqueda por un archivo llamado jndi.properties que debe encontrarse en la variable CLASSPATH del sistema.
• Una vez ejecutados todos los pasos anteriores, es posible crear subscriptores que consuman el mensaje del EJB. Estos pueden ser diez, cien o mil, y también pueden variar desde paginas Web, equipos inalámbricos, "tickers" en piso de remates, etc.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 66
Otros Conceptos • Transacciones y JTS/JTA. • Interfases Locales . • CORBA/IDL . • Serie "Connector" para acceso a ERP's.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 67
Transacciones y JTS/JTA
• Las transacciones juegan un papel muy importante en cualquier sistema de cómputo y en EJB's no son la excepción.
• A través de transacciones es posible garantizar la integridad de ciertas operaciones llevadas acabo en un sistema.
• Esta integridad es la parte fundamental ofrecida por una base de datos también denominada prueba del "ACIDo" ("Atomicity Consistency-Isolation-Durability").
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 68
Transacciones
• Omitiendo una gran cantidad de detalles, una Transacción es la que permite que:
– No sea enviado un producto hasta que haya sido actualizado el Inventario del mismo. – Al intentarse abonar "x" cantidad de dinero, ésta no sea realizada hasta que se haya realizado la respectiva deducción de otra cuenta.
– Actualizar diversos depósitos de información al mismo tiempo.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 69
Transacciones (2)
• En términos más triviales: una transacción representa un todo o nada, es decir, o se realizan todos los pasos definidos en ella o no se realiza ninguno.
• En un EJB, las transacciones son definidas en el "Deployment Descriptor" para cada método a ser ejecutado.
• Esto permite que si ocurre algún error ("Exception") dentro del método, todas sus acciones sean invalidadas. Esto es conocido como "Rollback".
• Por lo general todas las transacciones en un EJB son definidas a través del parámetro REQUIRED.
• Esto implica que al invocarse el método, se inicie una transacción exclusiva para éste.
• Definir una transacción como REQUIRED es una manera muy segura de mantener la integridad de información.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 70
Otros parámetros para transacciones
• Una transacción puede recibir otros parámetros: – REQUIRESNEW: Este tipo de parámetro permite al método en cuestión crear una transacción exclusiva. Al utilizarse REQUIRED, si ya existe una transacción de por medio y ocurre un error ("Exception") todas las operaciones tanto del método en cuestión así como las del que inicio la transacción serán retractadas ("Rolledbacked"). Al utilizarse REQUIRESNEW se evita este comportamiento "anidado" de transacciones.
– SUPPORTS: Esta transacción permite al método del EJB participar en una transacción siempre y cuando el cliente ( JSP/Servlet/Applet ) la haya iniciado, de otra manera no participa en ninguna transacción.
– MANDATORY: A través de MANDATORY se le indica al método que debe existir transacción en progreso. Si no existe, el "Application Server/EJB Container" genera un error (javax.ejb.TransactionRequiredException) – NOTSUPPORTED: Indica que el método no participará en ninguna transacción. Dado el caso de encontrarse una transacción en progreso, será suspendida y reanudada una vez que el método sea invocado.
– NEVER: Permite que un método jamás participe en una transacción. Inclusive, si el cliente (JSP/Servlet) llama este tipo de métodos cuando esta en proceso una transacción, se genera un error.
• El uso de cualquiera de los parámetros anteriores para Transacciones en EJB's no se recomienda al menos que haya sido realizado un análisis exhausto acerca de sus consecuencias en el EJB.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 71
JTS/JTA
• JTS "Java Transaction Service" y JTA "Java Transaction API" son un juego de librerías ("packages") utilizadas en el lenguaje Java para definir manualmente el uso de transacciones en los programas.
• JTS es el API utilizado por los diversos vendedores. Éste es rara vez utilizado por un programador al diseñar aplicaciones.
• JTA puede ser empleado para definir transacciones en cualquier programa Java. Sin embargo, su uso para aplicaciones de EJB's y sus clientes (JSP/Servlets) es fuertemente desanimado.
• Lo anterior se debe que al ser definida una transacción manualmente se pueden generar resultados inesperados, que varían desde operaciones congeladas ("deadlocks") hasta los efectos de propagación que pueda tener la transacción en todo el sistema.
• Además, se estaría dando un paso atrás en el mundo de EJB's!, puesto que la intención de EJB's es precisamente el ahorro de escribir este tipo de código complejo ("Middleware").
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 72
Interfases Locales
• Una "Interfaz Local" es un concepto nuevo para EJB's 2.0 que ofrece una alternativa a utilizar las clásicas interfases "Home" y "Remote“.
• Para entender interfases locales es necesario recordar como es llevada acabo la comunicación entre un EJB y su Cliente (JSP/ Servlet/ Applet): 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 73
Interfases Locales (2)
• Al observar el ciclo de Ejecución de un "Session EJB" y el ciclo de Ejecución de un "Entity EJB" se puede notar que existe una comunicación remota entre el EJB y su cliente.
• Esta comunicación es llevada acabo a través de RMI ("Remote Method Invocation").
• La interacción ocupa "Stubs" y "Skeletons" (componentes medulares de operaciones remotas), lo cual implica una capa adicional de procesamiento y complejidad.
• Además, se requiere que el cliente (JSP/ Servlet/ Applet) realice una búsqueda remota vía JNDI por el EJB.
• Lo anterior trajo como resultado la creación de "Interfases Locales".
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 74
Interfases locales (3)
• A través de "Interfases Locales“, la comunicación entre el Cliente del EJB y éste es llevada a cabo (como su nombre lo indica) “localmente“.
• Se ahorran las operaciones de búsqueda JNDI remotas, uso de "Stubs" y "Skeletons" (con esto la "Serialización y Deserialización" de objetos) y procesamiento.
• Esta comunicación local implica que todo proceso es llevado acabo en el mismo JVM ("Java Virtual Machine").
• Aunque de momento parece ideal utilizar "Interfases Locales" para todo diseño, no se puede asumir que un "Application Server/EJB Container" utilice un JVM ("Java Virtual Machine").
• Inclusive: ¿Quién puede asegurar que en un futuro no vayan a ser agregados 2 o 5 "Application Server/EJB Containers" para formar un "Cluster“? 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 75
Convivencia de interfases
• Si se toma como ejemplo el caso de la Cuenta Bancaria, es muy probable que los diversos EJB's residan en un "Host" (Computadora Física) de múltiples procesadores y Gigas de Memoria en la matriz bancaria, mientras los diversos Clientes (JSP/Servlets) que interactúan con estos EJB's estén localizados en distintas regiones geográficas en distintos "Hosts" en su propio "Application Server/EJB Container“. Aquí no es posible utilizar "Interfases Locales".
• Afortunadamente, la especificación de EJB's permite que residan en el mismo diseño tanto "Interfases Locales" como las clásicas "Home" y "Remote“, y que puedan ser utilizadas según convenga.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 76
Diseño de interfases locales
• El diseño de las interfases locales en sí es muy similar a las interfases clásicas "Home" y "Remote“.
• Además, es necesario declararlas en el "Deployment Descriptor" del EJB.
• Ambas interfases son declaradas a través de los elementos
• Si el cliente (JSP/ Servlet) llama el EJB con el nombre local, la comunicación será llevada acabo localmente. Si se llamase de otra manera, se utilizarían las interfases clásicas "Home" y "Remote“.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 77
CORBA/IDL
• Recordemos que CORBA ("Common Object Request Broker Architecture") fue uno de los primeros mecanismos utilizados para lograr interoperabilidad entre Sistemas Empresariales.
• A través de CORBA es posible aislar un sistema del lenguaje en el que está diseñado. En otras palabras: la comunicación se lleva acabo a través de objetos CORBA.
• Obviamente, lo anterior implica que un sistema debe ser diseñado con CORBA.
• Como es probable que una empresa posea algún sistema que opere en CORBA, es conveniente saber que un "Application Server/EJB Container" es capaz de comunicarse con éste.
• Una parte medular de CORBA es denominada IDL ("Interface Definition Language").
• A través de este lenguaje neutro se definen interfases utilizadas para generar objetos vía CORBA.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 78
CORBA/IDL (2)
• El funcionamiento de IDL es actuar como un puente entre determinado lenguaje y el mundo CORBA. Esto es: a partir de un mismo IDL es posible generar interfases para otros lenguajes como C++, Smalltalk y Java.
• En Java existen dos distinciones de esta terminología IDL: • IDL-a-Java implica que es posible generar interfases Java a partir de cierto IDL. Suponga que le proporcionan las definiciones IDL de "x" sistema CORBA. A partir de estas definiciones IDL, se generan las respectivas interfases Java, las cuales pueden ser utilizadas en EJB's. Esto permite que sus EJB's interactúen con el sistema CORBA.
• El término Java-a-IDL significa que, partiendo de definiciones Java (EJB's), es posible generar un IDL. Una vez obtenido este IDL, es posible utilizarlo para implementar objetos CORBA en otros lenguajes: C++, Ada, Smalltalk ,etc. Lo anterior permite que una aplicación escrita en estos lenguajes sea capaz de invocar métodos (en efecto actuando como cliente) en un "Enterprise Java Bean“.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 79
Serie "Connector" (JCA)
• La Serie Connector fue un componente incorporado al juego de especificaciones J2EE 1.3
• A través de esta especificación, también denominada JCA ("Java Connector Arquitecture"), se establecen los estándares para lograr la comunicación entre un "Application Server" y un "EIS"("Enterprise Information System"), donde éste último puede incluir sistemas "Mainframes","ERP's", "Base de Datos" y otros sistemas críticos para una empresa.
• Debido a que esta especificación J2EE se encuentra en sus etapas iniciales, muchos vendedores, tanto de "Application Servers" como aquellos de "EIS“, aún no ofrecen soporte para esta interactividad. • Algunas empresas productoras de ERP's como SAP , JDEdwards y PeopleSoft son las que se encuentran más adelantadas en diseños de este tipo.
• La razón es muy sencilla: a través de esta Serie "Connector" será posible que EJB's interactúen uniformemente con información residente en los sistemas ERP's que hoy en día al parecer son imprescindibles para cualquier industria.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 80
Patrones de Diseño ("Design Patterns") • Ventajas y Necesidades • Patrones Generales de Diseño • Patrones de Solicitudes de Acceso (De JSP/Servlets)
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 81
Ventajas y Necesidades
• Los patrones de diseño son empleados en muchos desarrollos de Software ya que ofrecen una mejor práctica entorno al problema que se intenta resolver.
• De alguna manera, son las experiencias continuas que han resultado al enfrentarse a determinado problema.
• En los diseños de EJB's ya se han documentado diversas practicas que eficientizan y agilizan su funcionamiento en "Application Servers/EJB Containers“.
• Estas prácticas son denominadas "Patrones de Diseño" ("Design Patterns"). 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 82
Interfase de Negocios ("Business Interface")
• Un EJB está compuesto por dos interfases: "Home" y "Remote" y su clase de implementación "EJB Class".
• Se recuerda que para esta última clase deben implementarse exactamente los métodos definidos en ambas interfases.
• Este requerimiento ha hecho que surja el patrón de diseño "Interfase de Negocios". • Al realizarse la compilación de la clase EJB, la que contiene la implementación, no existe ningún mecanismo para revisar que los métodos de ésta coincidan con los métodos definidos en el "Remote Interface“.
• Algunos "Application Servers/EJB Containers" ofrecen esta revisión a través de herramientas de post compilación. En otros, este tipo de errores se descubre muy tarde en el desarrollo o inclusive al ser ejecutado ("deployed").
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 83
Interfase de Negocios (2)
• La "Interfase de Negocios“, como cualquier interfase en Java, define un esqueleto que debe cumplir cualquier clase y/o interfase.
• Al implementar esta "Interfase de Negocios“, tanto en el "Remote Interfase" y "EJB Class" se están protegiendo para que ambas cumplan con ciertas definiciones antes de ser compiladas.
• En efecto: asegurándose que contengan las mismas definiciones antes de iniciar cualquier tipo de compilación.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 84
Fachada de Sesión ("Session Façade")
• El patrón de Fachada permite aislar el acceso a otros EJB's mediante un "Session EJB", por eso su nombre Session Façade.
• Otra ventaja que otorga el uso "Fachadas de Sesión" es el número de requisiciones necesarias para ser transferida la información entre el Cliente (JSP/ Servlet/ Applet) y los distintos EJB's.
• Este mismo principio aplica al patrón de diseño "Objeto de Valores".
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 85
Objeto de Valores ("ValueObject")
• La labor principal de los Clientes (JSP /Servlet /Programa) para EJB's es invocar métodos presentes en el EJB.
• Sin embargo, como se observa en Interfases Locales, estos Clientes no necesariamente residen en el mismo "Application Server/EJB Container“.
• Esta posible no residencia trajo como consecuencia el patrón de diseño Value Object.
• El llamado método a método presente en distintos EJB's puede presentar una carga substancial sobre la Red y sobre el "Application Server/EJB Container“.
• El principio de un Objeto de Valores ("Value Object") es sencillo: agrupar los distintos valores utilizados por el Cliente en un único método. Este tipo de métodos también son conocidos como "Coarse Grained“, mientras que el uso de métodos individuales es denominado "Fine Grained".
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 86
Objeto de Valores (2)
• Cada método llamado por el Cliente requiere: – Serializar la información para ser enviada al "EJB Container" – Deserializar la información para ser procesada en el "EJB Container" – Revisar parámetros de Seguridad – Iniciar una Transacción – Serializar respuesta para ser procesada por el Cliente. – Deserializar respuesta para utilizarse en el Cliente. • Imagínese este mismo proceso siendo llevado a cabo 5 o 6 veces consecutivamente.
• A través de un Objeto de Valores ("Value Object") es posible reducir esta carga a una sola llamada.
2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 87
Patrones de Solicitudes de Acceso (De JSP/Servlets)
Fábrica de Interfases ("Home Factory").
• La búsqueda/localización que realiza un Cliente (JSP/Servlet) por un EJB también puede resultar en una carga excesiva para el "Application Server/EJB Container" si no es diseñado un acceso apropiado. La búsqueda realizada mediante JNDI es una operación repetitiva y cara.
• Suponga que ha diseñado acceso "Web" para cierta información residente en EJB's. Cada visitante que acceda al sitio requiere localizar el EJB a través de JNDI. Si espera 1000 o 2000 visitantes, esto implica mil o dos mil búsquedas repetitivas. La situación se agrava aún más si el Cliente (JSP/Servlet) y el EJB residen en diferentes "Application Servers".
• Lo anterior trajo como resultado el surgimiento del patrón de diseño "Fabrica de Interfases" ("Home Factory"), el cual permite al Cliente (JSP/ Servlet) reutilizar el resultado de la búsqueda previamente hecha por el EJB. • En si, el funcionamiento de esta fábrica es como un "Cache" para el Cliente (JSP/ Servlet). 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 88
Ejemplos
• General: – ConverterApp • Session Beans: – CartBean: a stateful session bean that is accessed by a remote client – HelloServiceBean: a stateless session bean that implements a web service – TimerSessionBean: a stateless session bean that sets a timer • Bean-Managed Persistence: – SavingsAccount • Container-Managed Persistence: – Roster – Order • Message-Driven Bean: – SimpleMessage 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 89
Referencias
• •
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, Addison Wesley. (archivo: designing_enterprise_apps-2_0 book.PDF) • • Curso Java EJB's
J2EE™ Connector Architecture Specification, Version
1.5 (Connector specification)
Java™ Message Service Specification, Version 1.0.2
(JMS specification) 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy 90