1 2006 universidad de las américas - escuela de ingeniería - java ii - dr. juan josé aranda aboy...

1 2006 Universidad de Las Américas - Escuela de Ingeniería - Java II - Dr. Juan José Aranda Aboy

ACI – 843ACI – 843JAVA IIJAVA II

Clase 12:Introducción a

Enterprise Java Beans


ContenidosContenidos

• 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")


Java Application ServersJava 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.


EAR's ("Enterprise Archives"), EAR's ("Enterprise Archives"), IDE's y Deployment DescriptorsIDE's y Deployment Descriptors

• EARS, WAR's, EJB-JAR's. • Herramientas e IDE's • Deployment Descriptors


EARS ("Enterprise Archives")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)".


EJB-JAR'sEJB-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


Convenios de denominaciónConvenios de denominación

Item Syntax Example

Enterprise bean name (DD1) <name>Bean AccountBean

EJB JAR display name (DD) <name>JAR AccountJAR

Enterprise bean class <name>Bean AccountBean

Home interface <name>Home AccountHome

Remote interface <name> Account

Local home interface <name>LocalHome AccountLocalHome

Local interface <name>Local AccountLocal

Abstract schema (DD) <name> Account

1DD significa que el ítem es elemento en el descriptor de despliegue.


WAR'sWAR'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.


EAR'sEAR'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.


Herramientas e IDE's 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.


Algunos IDE'sAlgunos IDE's

• NetBeans Open-Source • Eclipse Open-Source • Sun Java Studio Creator Sun• JBuilder Borland • WebSphere Studio IBM • JDeveloper Oracle


"Deployment Descriptor""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 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 Java 5 / JDK 1.5 y ejercerá su respectiva influencia en las nuevas versiones J2EE-EJB 3.0


EJB'sEJB's

• Razón de ser. • Java Application Servers. • Tipos de EJB's. • Estructura de un EJB.


Enterprise Java BeansEnterprise Java Beans (EJBs) (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.


Beneficios del uso de EJBs 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.


Cuando es apropiado usar EJBsCuando 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.


Tipos de EJB's. 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.


Estructura de un EJBEstructura 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.


Estructura de un EJB (2)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.


Manejo de excepcionesManejo 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.


Excepciones del paquete Excepciones del paquete javax.ejbjavax.ejb

Method Name Exception It Throws Reason for Throwing

ejbCreate CreateException Parámetro de entrada no válido.

ejbFindByPrimaryKey (y cualquier otro método buscador find* que devuelva un objeto simple.)

ObjectNotFoundException

(subclase de FinderException)

The database row for the requested entity bean cannot be found.

ejbRemove RemoveException The entity bean's row cannot be deleted from the database.

ejbLoad NoSuchEntityExc

eption The database row to be loaded into the entity bean cannot be found.

ejbStore NoSuchEntityExc

eption The database row to be updated cannot be found.

(todos los métodos) EJBException Se encontró un problema en el sistema.


Session EJB's Session EJB's (Stateful y Stateless)(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.


Ciclo de EjecuciónCiclo de Ejecución


Estructura y Componentes Estructura y Componentes AdicionalesAdicionales

• 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.


StubsStubs

• 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.


SkeletonsSkeletons

• 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".


Librerías (JAR's) PropietariasLibrerí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.


Codificación de un Session Codificación de un Session (Stateless) EJB(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.


Codificación de un Session Codificación de un Session (Stateless) EJB (2)(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.


Creación del EJB (Archivo JAR) Creación del EJB (Archivo JAR) y Ejecución ("Deployment")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.


Codificación del Cliente para Codificación del Cliente para un Session (Stateless) EJBun 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


Session (Stateful) EJBSession (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.


Session (Stateful) EJB (2)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.


When to Use Session BeansWhen 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.


Entity EJB'sEntity 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


Ciclo de ejecuciónCiclo 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.


LocalizaciónLocalizació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.


Localización (2)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".


Localización (3)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.


SincronizaciónSincronizació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.


Sincronización (2)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.

¿Cuando y quién invoca ejbStore y ejbLoad?• Las dos situaciones obvias son al crear y al destruir el "Entity

EJB“• 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.


Tipos de Entity BeansTipos 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.


Mapeo Objeto/RelacionalMapeo 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.


Mapeo (2)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.


BMP "Bean Managed Persistence"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/savingsaccount/


Definiciones en Bases de DatosDefiniciones 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.


Creación de Interfases ("Home Creación de Interfases ("Home Interface" y "Remote Interface")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.


Creación del EJBCreació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.


Deployment Descriptor del EJBDeployment 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).


Creación del ClienteCreació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


CMP "Container Managed CMP "Container Managed Persistence"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/cmproster/


Surgimiento y ConsideracionesSurgimiento 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.


SuperClase/SubClase, "Abstract SuperClase/SubClase, "Abstract Schema" y EJB-QLSchema" 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").


"Abstract Schema" visto desde un "Abstract Schema" visto desde un alto nivelalto nivel


Interfases, EJB, Descriptor y Interfases, EJB, Descriptor y ClienteClienteCreació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.


Messaging BeansMessaging 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/ejb/simplemessage/


Sistemas MessagingSistemas 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":


Comunicación típicaComunicació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.


Comunicación asincrónicaComunicació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.


FuncionalidadesFuncionalidades

• 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.


JMS: Integración de "Sistemas JMS: Integración de "Sistemas Messaging" a JavaMessaging" 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".


Aplicación de mensaje simpleAplicació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.


Diferencias entre Session y Entity EJB's, Diferencias entre Session y Entity EJB's, "Point-to-Point" y "Publish/Subscribe""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.


"Point-to-Point" y "Point-to-Point" y "Publish/Subscribe""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.


Diseño de un Messaging EJBDiseñ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.


Diseño de un Messaging EJB (2)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.


Otros ConceptosOtros Conceptos

• Transacciones y JTS/JTA. • Interfases Locales . • CORBA/IDL . • Serie "Connector" para acceso a ERP's.


Transacciones y JTS/JTATransacciones 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").


TransaccionesTransacciones

• 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.


Transacciones (2)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.


Otros parámetros para Otros parámetros para transaccionestransacciones• 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.


JTS/JTAJTS/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").


Interfases LocalesInterfases 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):


Interfases Locales (2)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".


Interfases locales (3)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“?


Convivencia de interfasesConvivencia 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.


Diseño de interfases localesDiseñ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 <home> y <local-home>.

• Para que el cliente (JSP/Servlet) interactúe con el EJB a través de interfases locales, basta que se llame al EJB por el nombre JNDI asociado con estas interfases.

• El archivo .xml para el "Entity CMP EJB" define el elemento <local-jndi-name> para estas interfases.

• 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“.


CORBA/IDLCORBA/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.


CORBA/IDL (2)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“.


Serie "Connector" (JCA)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.


Patrones de Diseño ("Design Patrones de Diseño ("Design Patterns") Patterns")

• Ventajas y Necesidades • Patrones Generales de Diseño • Patrones de Solicitudes de Acceso (De

JSP/Servlets)


Ventajas y NecesidadesVentajas 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").


Interfase de Negocios ("Interfase de Negocios ("Business Business InterfaceInterface")")

• 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").


Interfase de Negocios (2)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.


Fachada de Sesión ("Fachada de Sesión ("Session Session FaçadeFaç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".


Objeto de Valores ("Objeto de Valores ("ValueObjectValueObject")")

• 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".


Objeto de Valores (2)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.


Patrones de Solicitudes de Acceso Patrones de Solicitudes de Acceso (De JSP/Servlets)(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).


EjemplosEjemplos

• 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


ReferenciasReferencias

• 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, Addison-Wesley. (archivo: designing_enterprise_apps-2_0-book.PDF)

• J2EE™ Connector Architecture Specification, Version 1.5 (Connector specification)

• Java™ Message Service Specification, Version 1.0.2 (JMS specification)

1 2006 universidad de las américas - escuela de ingeniería - java ii - dr. juan josé aranda aboy...

Documents