La aplicaci�n de ejemplo es una casa de subastas basada en el Web y escrita para la plataforma Enterprise JavaBeans. El interface de usuario es un conjunto de p�ginas HTML que obtienen la entrada del usuario y le muestran la informaci�n. Detr�s de las p�ginas HTML hay un servelt que pasa datos entre el navegador y el servidor Enterprise JavaBeans. Este servidor maneja la lectura y escritura de la base de datos.
Este cap�tulo describe el c�digo de la aplicaci�n, c�mo funciona con el servidor Enterprise JavaBeans, y d�nde obtener este servidor para ejecutar el ejemplo. O, si lo prefieres, aqu� hay una maqueta de la aplicaci�n subasta.
�Un Aplicaci�n Multi-Fila con Beans de Enterprise
La proliferaci�n de aplicaciones basadas en internet - e intranet - ha creado una gran necesidad de aplicaciones transacionales distribuidas que aumenten la velocidad, seguridad y rendimiento de la tecnolog�a del lado del servidor. Una forma de conseguir estas necesidades es usar un modelo multi-fila donde una peque�a aplicaci�n cliente invoca l�gica de negocio que se ejecuta en el servidor.
Normalmente, las peque�as aplicaciones clientes multi-hilo son dificiles de escribir porque se involucran muchas l�neas de c�digo intrincado para manejar la transaci�n, el control de estados, multithreads, solape de recursos y otros detalles complejos de bajo nivel. Y para rematar estas dificultades, tenemos que retrabajar este c�digo cada vez que escribamos una aplicaci�n porque es tan de bajo nivel que no es reutilizable.
Si pudieramos usar un c�digo de manejo de transaciones preconstruido por alguien o incluso si puedieramos reutilizar algo de nuestro propio c�digo, ahorrariamos mucho tiempo y energ�a que podr�amos utilizar para resolver otros problemas. Bien, la tecnolog�a Enterprise JavaBeans puede darnos la ayuda necesaria. Esta tecnolog�a hace sencillas de escribir las aplicaciones transacionales distribuidas porque separa los detalles de bajo nivel de la l�gica del negocio. Nos concentramos en crear la mejor soluci�n para nuestro negocio y dejamos el resto a la arquitectura oculta.
Este cap�tulo describe c�mo crear la aplicaci�n de subastas del ejemplo usando los servicios proporcionados por la plataforma Enterprise JavaBeans. En las siguientes secciones veremos como podemos personalizar estos servicios e integrar estas caracter�sticas en aplicaciones existentes no EJB.
�Enterprise Beans Definidos
Un Bean Enterprise es una clase que proporciona dos tipos de m�todos: l�gica de negocio y ciclo de vida. Un programa cliente llama a los m�todos de la l�gica de negocio para interactuar con los datos contenidos en el servidor. El contenedor llama a los m�todos de ciclo de vida para manejar el Bean en el servidor. Adem�s de estos dos tipos de m�todos, un Bean Enterprise tiene un fichero de configuraci�n asociado, llamado un descriptor de desarrollo, se usa para configurar el Bean en el momento del desarrollo.
As� como es el responsable de la creacci�n y borrado de Beans, el servidor de JavaBeans de Enterprise tambi�n maneja las transaciones, la concurrencia, la seguridad y la persistencia de datos. Incluso las conexiones entre el cliente y el servidor se proporcionan usando los APIs de RMI y JNDI y opcionalmente los servidores pueden proporcionar escalabilidad a trav�s del manejo de threads.
El ejemplo de la casa de subastas implementa una completa soluci�n de JavaBeans de Enterprise que s�lo proporcionan la l�gica de negocio y usa los servicios ocultos proporcionados por la arquitectura. Sin embargo, podr�amos encontrar que el servicio de contenedores controladores, aunque proporcionando una m�xima portabilidad, no consigue todos los requerimientos de nuestra aplicaci�n. En los pr�ximos cap�tulos veremos c�mo proporcionar estos servicios a nuestro Bean y tambi�n como usar estos servicios en aplicaciones que no usen Beans de Enterprise.
�Peque�o Programas Cliente
Un peque�o cliente es un programa cliente que invoca a la l�gica de negocio que se ejecuta en el servidor. Se llama "peque�o" porque la mayor�a del proceso sucede en el servidor. En la siguiente figura, el servlet es el cliente. Invoca a los Beans Enterprise que se ejecutan sobre un servidor de JavaBeans Enterprise. Tambi�n ejecuta la l�gica que crea las p�ginas web que aparecen en el navegador.
�Arquitectura Multi-Fila
La arquitectura multi-fila o arquitectura de tres filas desciende del modelo est�ndard de dos filas de cliente y servidor situando una aplicaci�n multi-fila entre el cliente y la base de datos.
Los programas clientes se comunican con la base de datos a trav�s de la aplicaci�n del servidor usando llamadas de alto nivel e independientes de la plataforma. La aplicaci�n servidor responde a las peticiones del cliente, hace las llamadas necesarias a la base de datos dentro de la base de datos oculta, y responde al programa cliente de la forma apropiada.
El ejemplo de casa de subastas basado en web de tres filas consiste en el servlet cliente, el servidor Enterprise JavaBeans (la aplicaci�n servidor), y el servidor de la base de datos como se ve en la figura.
�Beans de Entidad y de Sesi�n
Existen dos tipos de Beans Enterprise: Beans de entidad y de sesi�n. Un Bean Enterprise que implementa una entidad de negocio es un Bean de Entidad, y un Bean Enterprise que implementa una tarea de negocio es un Bean de Sesi�n.
T�picamente, un Bean de entidad representa una fila de datos persistentes almacenados en una tabla de la base de datos. En el ejemplo de la casa de subastas, RegistrationBean es un Bean de entidad que representa los datos de un usuario registrado, y AuctionItemBean es un Bean de entidad que represena los datos de un �tem de la subasta. Los Beans de entidad son transacionales y de larga vida. Mientras que los datos permanezcan, el Bean de entidad puede acceder y actualizarlos. Esto no significa que tengamos un Bean ejecut�ndose por cada fila de la tabla. Si no que los Beans Enterprise se cargan y graban cuando es necesario.
Un Bean de sesi�n podr�a ejecutar una lectura o escritura en la base de datos, pero no es necesario. Un Bean de sesi�n podr�a invocar llamadas al JDBC por s� mismo o podr�a usar un Bean de entidad para hacer la llamada, en cuyo caso el Bean de sesi�n es un cliente del Bean de entidad. Un campo de Bean contiene el estado de la conversaci�n y son temporales. Si el servidor o el cliente se bloquean, el Bean de sesi�n se v�. Frecuentemente se usan los Beans de sesi�n con uno o m�s Beans de entidad y para operaciones complejas con datos.
| Beans de Sesi�n | Beans de Entidad |
|---|---|
| Campos que contienen el estado de la conversaci�n | Representan datos de la base de datos |
| Manejan accesos a la base de datos por parte del cliente | Comparten accesos entre m�ltiples usuarios |
| La vida del cliente es la vida del Bean | Pesiste mientras existan los datos |
| Pueden perderse con la transaci�n | Transacional |
| No sobrevive a las ca�das del servidor | Sobrevive a las ca�das del servidor |
| No maneja los datos de forma fina | Manejo de datos de forma delicada |
�La Casa de Subastas Funciona
El diagrama muestra los Beans de Enterprise para la aplicaci�n de la casa de subastas y su relaci�n con el servidor de JavaBeans de Enterprise. El cliente invoca la l�gica de negocio en cuatro Beans de Enterprise a trav�s de sus interfaces home y remoto. El servidor JavaBeans de este ejemplo maneja los detalles de bajo nivel incluyendo las operaciones de lectura y escritura en la base de datos.
Los cuatro Beans del ejemplo son:
- AuctionItemBean un Bean de entidad que mantiene informaci�n sobre el �tem de la subasta.
- RegistrationBean un Bean de entidad que almacena informaci�n de registro de los usuarios.
- BidderBean un Bean de sesi�n que usa AuctionItemBean para recuperar una listra de los �tems de la subastas, s�lo los nuevos �tems, �tems cerca del cierre, e �tems cuyo sumario corresponde con una cadena de busqueda en la base de datos. Tambi�n comprueba la identidad del usuario y la password cuando alguien hace una puja, y almacena las nuevas pujas en la base de datos.
- SellerBean es un Bean de sesi�n que usa RegistrationBean para comprobar la identidad del usuario y la password cuando alguien postea un �tem para su subasta, y AuctionItemBean para a�adir nuevos �tems a la base de datos de la subasta.
Como se ve en la figura superior, un Bean de entidad o de sesi�n realmente es una colecci�n de clases e interfaces. Todos los Beans de entidad y de sesi�n consisten en un interfae remoto, un interface home, y la clase del Bean. El servidor busca el interface home del Bean que est� ejecut�ndose en el servidor JavaBeans de Enterprise, lo usa para crear el interface remoto, e invoca a los m�todos del Bean a trav�s del interface remoto.
- Un Interface remoto de un Bean Enterprise decribe los m�todos del Bean, o qu� hace el Bean. Un programa cliente u otro Bean Enterprise llama a los m�todos definidos en el interface remoto para invocar la l�gica de negocios implementada por el Bean.
- Un interface home de un Bean de Enterprise describe c�mo un programa cliente u otro Bean Enterprise crea, encuentra (s�lo los Beans de entidad), y elimina ese Bean de Enterpise de su contenedor.
- El contenedor, mostrado en cyan en el gr�fico, proporciona el interface entre el Bean Interface y las funcionalidades de bajo nivel espec�ficas de la plataforma que soporta el Bean.
�Desplegar y Ejecutar Aplicaciones
Las herramientas de desarrollo y un servidor de JavaBeans Enterprise es esencial para ejecutar aplicaciones con JavaBeans Enterprise. Las herramientas de desarrollo generan contenedores, que son clases que proporcionan un interface de implementaciones de bajo nivel en un servidor JavaBeans Enterprise dado. El servidor proporcionado puede incluir contenedores y herramientas de desarrollo para sus servidores y normalmente publicar� los interfaces de bajo nivel para que otros vendedores pueden desarrollar contenedores y herramientas de desarrollo para sus servidores.
El ejemplo de casa de subastas usa el servidor JavaBeans y las herramientas de desarrollo creadas por BEA Weblogic. Visita su site para obtener una demo de 30 d�as.
Como todo est� sujeto a las especificaciones, todos los Beans Enterprise son intercambiables con contenedores, herramientas de desarrollo, y servidores creados por otros vendedores. De hecho, podriamos escribir nuestro propio Bean Enterprise porque es posible, y algunas veces deseable, usar Beans Enterprise escritos por uno o m�s proveedores que ensamblaremos dentro de una aplicaci�n de JavaBeans Enterprise.
�C�mo Funcionan las Aplicaciones Multi-Fila
El objetivo de una aplicaci�n multi-fila es que el cliente pueda trabajar con los datos de una aplicaci�n sin conocer en el momento de la construcci�n d�nde se encuentran los datos. Para hacer posible este nivel de transparencia, los servicios ocultos en una arquitectura multi-fila usan servicios de b�squeda para localizar los objetos del servidor remoto (el objeto interface del Bean remoto), y los servicios de comunicaci�n de datos para mover los datos desde el cliente, a trav�s del objeto servidor remoto, hasta su destino final en el medio de almacenaje.
�Servicio de B�squeda
Para encontrar los objetos del servidor remoto en el momento de la ejecuci�n, el programa cliente necesita una forma de buscarlos. Una de estas formas es usar el API Java Naming y Directory Interface (JNDI). JNDI es un interface com�n para interfaces existentes de nombres y directorios. Los contenedores de los JavaBeans de Enterprise usan JNDI como interface para el servicio de nombres del Remote Method Invocation (RMI).
Durante el desarrollo, el servicio JNDI registra el interface remoto con un nombre. Siempre que el programa cliente use el mismo servicio de nombres y pregunte por el interface remoto con su nombre registrado, podr� encontrarlo. El programa cliente llama al m�todo lookup sobre un objeto javax.naming.Context para preguntar por el interface remoto con su nombre registrado. El objeto javax.naming.Context es donde se almacenan las uniones y es un objeto diferente del contexto del JavaBean de Enterprise, que se cubre m�s adelante..
�Comunicaci�n de Datos
Una vez que el programa cliente obtiene una referencia al objeto servidor remoto, hace llamadas a los m�todos de este objeto. Como el programa cliente tiene una referencia al objeto servidor remoto, se usa una t�cnica llamada "envolver datos" para hacer que parezca que el objeto servidor remoto es local para el programa cliente.
La "ordenaci�n de datos" es donde las llamadas a m�todos del objeto servidor remoto se empaquetan con sus datos y se env�an al objeto servidor remoto. El objeto servidor remoto desempaqueta (desordena) los m�todos y los datos, y llama al Bean Enterprise. El resultado de la llamda al Bean es empaquetado de nuevo y pasado de vuelta al cliente a trav�s del objeto servidor remoto, y son desempaquetados.
Los contenedores de JavaBeans Enterprise usan servicios RMI para ordenar los datos. Cuando se compila un Bean, se crean unos ficheros stub (tal�n) y skeleton (esqueleto). El fichero tal�n proporciona la configuraci�n del empaquetado y desempaquetado de datos en el cliente, y el esqueleto proporciona la misma informaci�n para el servidor.
Los datos se pasan entre el programa cliente y el servidor usando serializaci�n. La serializaci�n es una forma de representar objetos Java como bytes que pueden ser enviados a trav�s de la red como un stream y pueden ser reconstuidos en el mismo estado en el que fueron enviados originalmente.
�Beans de Entidad y de Sesi�n
El ejemplo usa dos Beans de entidad y dos de sesi�n. Los Beans de entidad, AuctionItemBean y RegistrationBean, representan �tems persistentes que podr�an estar almacenados en un base de datos, y los Beans de sesi�n, SellerBean y BidderBean, representan operaciones de vida corta con el cliente y los datos.
Los Beans de sesi�n son el interface del cliente hacia los beans de entidad. El SellerBean procesa peticiones para a�adir nuevos �tems para la subasta. El BidderBean procesa peticiones para recuperar �tems de la subasta y situar las pujas por esos �tems. El cambio o adici�n de datos a la base de datos en un Bean controlado por contenedor se le deja a los Beans de entidad:
�AuctionServlet
El AuctionServlet es esencialmente la segunda fila en la aplicaci�n y el punto focal para las actividades de la subasta. Acepta entradas finales del usuario desde el navegador mediante el protocolo de transferencia de hypertexto (HTTP), pasa la entrada al Bean Enterprise apropiado para su proceso, y muestra el resultado del proceso al usuario final en el navegador.
Aqu� hay un diagrama del tipo Unified Modeling Language (UML) para la clase AuctionServlet.
Los m�todos de AuctionServlet mostrados arriba invocan a la l�gica del negocio que se ejecuta en el servidor buscando un Bean Enterprise y llamando a uno o m�s de sus m�todos. Cuando el servelt a�ade c�digo HTML a una p�gina para mostrarsela al usuario, la l�gica se ejecuta en el cliente.
Por ejemplo, el m�todo listAllItems(out) ejecuta c�digo en el cliente para generar din�micamente una p�gina HTML para que la vea el cliente en un navegador. La p�gina HTML se rellena con los resultados de una llamada a BidderBean que ejecuta la l�gica en el servidor para generar una lista de todos los �tems de la subasta.
private void listAllItems(ServletOutputStream out)
throws IOException{
//Put text on HTML page
setTitle(out, "Auction results");
String text = "Click Item number for description
and to place bid.";
try{
addLine("<BR>"+text, out);
//Look up Bidder bean home interface.
BidderHome bhome=(BidderHome) ctx.lookup("bidder");
//Create Bidder bean remote interface.
Bidder bid=bhome.create();
//Call Bidder bean method through remote interface.
Enumeration enum=(Enumeration)bid.getItemList();
if(enum != null) {
//Put retrieved items on servlet page.
displayitems(enum, out);
addLine("", out);
}
} catch (Exception e) {
//Pring error on servlet page.
addLine("AuctionServlet List All Items error",out);
System.out.println("AuctionServlet <list>:"+e);
}
out.flush();
}
�Beans de Entidad
AuctionItemBean y RegistrationBean son Beans de entidad. AuctionItemBean a�ade nuevos �tems de subasta a la base de datos y actualiza la cantidad pujada por los usuarios cuando �stos pujan por el �tem. RegistrationBean a�ade informaci�n a la base de datos sobre usuarios registrados. Ambos Beans consisten en las clases descritas aqu�.
�AuctionItem Entity Bean
Aqu� est�n las clase de AuctionItemBean. Recuerda que estos Beans de Enterprise son objetos distribuidos que usan el API RMI (Invocaci�n Remota de M�todos), por eso, cuando ocurre un error se lanza una excepci�n RMI remota.
AuctionItem es un interface remoto. Describe qu� hace el Bean declarando los m�todos definidos por el usuario que proporcionan la l�gica de negocio para este Bean. Estos m�todos son usados por el cliente para interactuar con el Bean sobre la conexi�n remota. Su nombre se mapea a la tabla AUCTIONITEMS que puedes ver abajo.
AuctionItemHome es el interface home. Describe c�mo se crea el Bean, como encontrarlo, y eliminarlo de su contenedor. Las herramientas de desarrollo del servidor de Beans de Enterprise proporcionar�n la implementaci�n para este interface.
AuctionItemBean es el Bean de Enterprise. Implementa EntityBean, proporciona la l�gica de negocio para los m�todos definidos por el desarrollador, e implementa los m�todos de EntityBean para crear el Bean y seleccionar el contexto de sesi�n. Esta es una clase que necesita implementar el desarrollador del Bean. Sus campos variables mapean a los campos de la tabla AUCTIONITEMS que puedes ver abajo.
AuctionItemPK es la clase clave primaria. El servidor de Beans Enterprise requiere que un Bean de Entidad Manejado por Contenedor tenga una clase clave primaria con un campo p�blico primario (o campos, si se usan claves primarias compuestas). El desarrollador del Bean implementa esta clase. El campo ID es la clave primaria en la tabla AUCTIONITEMS que puedes ver m�s abajo, por eso el campo id es un campo p�blico de esta clase. Al campo id se le asigna un valor cuando se construye la clase de la clave primaria.
Podemos pedirle al contenedor que maneje la persistencia de la base de datos de un Bean Enterprise o escribir el c�digo para manejar la persistencia por nosotros mismos. En este cap�tulo, todos los beans son manejados por el contenedor. Con esto nosotros s�lo decimos qu� campos son manejados por el contenedor y le dejamos al servidor de JavaBeans de Enterprise que haga el resto. Esto es fenomenal para las aplicaciones sencillas, pero si tuvieramos que codificar algo m�s complejo, necesitar�amos m�s control.
C�mo escribir los servicios ocultos de los JavaBeans Enterprise para ganar m�s control o proporcionar servicios similares para las aplicaciones que no usen JavaBeans de Enterprise se cubre en el cap�tulo 3.
�Tabla Auction Items
Aqu� est� la tabla AUCTIONITEMS.
create table AUCTIONITEMS (SUMMARY VARCHAR(80) , ID INT , COUNTER INT , DESCRIPTION VARCHAR(1000) , STARTDATE DATE , ENDDATE DATE , STARTPRICE DOUBLE PRECISION , INCREMENT DOUBLE PRECISION , SELLER VARCHAR(30) , MAXBID DOUBLE PRECISION, BIDCOUNT INT, HIGHBIDDER VARCHAR(30) )
�Registration Entity Bean
RegistrationBean consta de las mismas clases y tablas de base de datos que el Bean AuctionItem, excepto que la l�gica de negocio real, los campos de la tabla de la base de datos, y la clave primaria son de alguna forma diferentes. En vez de describir las clases, podemos navegar por ellas y luego volver a la descripci�n de las clases de AuctionItem si tenemos alguna pregunta.
�Tabla Registration
Aqu� est� la tabla REGISTRATION.
create table REGISTRATION (THEUSER VARCHAR(40) , PASSWORD VARCHAR(40) , EMAILADDRESS VARCHAR(80) , CREDITCARD VARCHAR(40) , BALANCE DOUBLE PRECISION )
�Beans de Sesi�n
BidderBean y SellerBean son los Beans de sesi�n. BidderBean recupera una lista de los �tems de la subasta, busca �tems, chuequea el ID y la password del usuario cuando alguien hace una puja, y almacena las nuevas pujas en la base de datos. SellerBean chequea el ID y la password del usuario cuando alguien postea un �tem para su subasta, y a�ade nuevos �tems para subasta a la base de datos.
Ambos Beans de sesi�n est�n desarrollados inicialmente como Beans sin estado. Un Bean sin estado no mantiene un registro de lo que hizo el cliente en una llamada anterior; mientras que un Bean con estado completo si lo hace. Los Beans con estado completo son muy �tiles si la operaci�n es algo m�s que una simple b�squeda y la operaci�n del cliente depende de algo que ha sucedido en una llamada anterior.
�Bean de sesi�n Bidder
Aqu� est�n las clase de BidderBean. Recuerda que estos Beans de Enterprise son objetos distribuidos que usan el API RMI (Invocaci�n Remota de M�todos), por eso, cuando ocurre un error se lanza una excepci�n RMI remota.
No exiten claves primarias porque estos Beans son temporales y no hay accesos a la base de datos. Para recuperar �tems de la base de datos, BidderBean crea un ejemplar de AuctionItemBean, y para procesar las pujas, crea un ejemplar de RegistrationBean.
Bidder es un interface remoto. Describe lo que hace el Bean declarando los m�todos definidos por el desarrollador que proporcionan la l�gica de negocio para este Bean. Esto son los que que el cliente llama de forma remota.
BidderHome es el interface home. Descibe c�mo se crear el Bean, como se busca y como se elimina de su contenedor.
BidderBean es el Bean de Enterprise. Implementa SessionBean, proporciona la l�gica de negocio para los m�todos definidos por el desarrollador, e implementa los m�todos de SessionBean para crear el Bean y seleccionar el contexto de sesi�n.
�Bean de sesion Seller
SellerBean consta de los mismos tipos de clase que un BidderBean, excepto que la l�gica de negocio es diferente. En vez de describir las clases, puedes navegar por ellas y luego volver a la explicaci�n de BidderBean si tienes alguna duda.
�Clases Contenedor
Las clases que necesita el contenedor para desarrollar un Bean Enterprise dentro de un servidor de JavaBeans Enterprise particular se generan con una herramienta de desarrollo. Las clases incluyen _Stub.class y _Skel.class que proporcionan el RMI en el cliente y el servidor respectivamente.
Estas clases se utilizan para mover datos entre el programa cliente y el servidor de JavaBeans de Enterprise. Adem�s, la implementaci�n de las clases se crea para los interfaces y las reglas de desarrollo definidas para nuestro Bean.
El objeto Stub se instala o se descarga en el sistema cliente y proporciona un objeto proxy local para el cliente. Implementa los interfaces remotos y delega de forma transparente todas las llamadas a m�todos a trav�s de la red al objeto remoto.
El objeto Skel se instala o se descarga en el sistema servidor y proporciona un objeto proxy local para el servidor. Despempaqueta los datos recibidos a trav�s de la red desde el objeto Stub para procesarlos en el servidor.
�Examinar un Bean Controlado por Contenedor
Esta secci�n pasea a trav�s del c�digo de RegistrationBean.java para ver lo f�cil que es hacer que el contenedor maneje la persistencia del almacenamiento de datos en un medio oculto como una base de datos (por defecto).
�Variables Miembro
Un entorno de contenedor controlador necesita saber qu� variables son para almacenamiento persistente y cuales no. En el lenguaje Java, la palabra clave transient indica variables que no son incluidas cuando los datos de un objeto se serializan y escriben en un almacenamiento permanente. En la clase RegistrationBean.java, la variable EntityContext est� marcada como transient para indicar que su dato no ser� escrito en ning�n medio de almacenamiento.
El dato de EntityContext no se escribe en el almacenamiento permanente porque su prop�sito es proporcionar informaci�n sobre el contexto en el momento de ejecuci�n del contenedor. Por lo tanto, no contiene datos sobre el usuario registrado y no deber�a grabarse en un medio de almacenamiento. Las otras variables est�n declaradas como public, por lo que el contenedor de este ejemplo puede descubrirlas usando el API Reflection.
protected transient EntityContext ctx;
public String theuser, password, creditcard,
emailaddress;
public double balance;
�M�todo Create
El m�todo ejbCreate del Bean es llamado por el contenedor despu�s de que el programa cliente llame al m�todo create sobre el interface remoto y pase los datos de registro. Este m�todo asigna los valores de entrada a las variables miembro que representan los datos del usuario. El contenedor maneja el almacenamiento y carga de los datos, y crea nuevas entradas en el medio de almacenamiento oculto.
public RegistrationPK ejbCreate(String theuser,
String password,
String emailaddress,
String creditcard)
throws CreateException, RemoteException {
this.theuser=theuser;
this.password=password;
this.emailaddress=emailaddress;
this.creditcard=creditcard;
this.balance=0;
�M�todos de Contexto de Entidad
Un Bean de entidad tiene un ejemplar de EntityContext asociado que ofrece al Bean acceso a la informaci�n del contenedor controlador en el momento de la ejecuci�n, como el contexto de la transaci�n.
public void setEntityContext(
javax.ejb.EntityContext ctx)
throws RemoteException {
this.ctx = ctx;
}
public void unsetEntityContext()
throws RemoteException{
ctx = null;
}
�M�todo Load
El m�todo ejbLoad del Bean es llamado por el contenedor para cargar los datos desde el medio de almacenamiento oculto. Esto ser�a necesario cuando BidderBean o SellerBean necesiten chequear la ID y password del usuario.
Nota: No todos los objetos Beans est�n vivos en un momento dato. El servidor de JavaBeans Enterprise podr�a tener un n�mero configurable de Beans que puede mantener en memoria.
Este m�todo no est� implementado porque el contenedor de los JavaBeans de Enterprise carga los datos por nosotros.
public void ejbLoad() throws RemoteException {}
�M�todo Store
El m�todo ejbStore del Bean es llamado por el contenedor para grabar los datos del usuario. Este m�todo no est� implementado porque el contenedor de los JavaBeans de Enterprise graba los datos por nosotros.
public void ejbStore() throws RemoteException {}
�Connection Pooling
La carga y almacenamiento de datos en la base de datos puede tardar mucho tiempo y reducir el rendimiento general de la aplicaci�n. Para reducir el tiempo de conexi�n, el servidor de Weblogic BEA usa una cola de conexiones JDBC para hacer un cache con las conexiones con la base de datos, por eso las conexiones est�n siempre disponibles cuando la aplicaci�n las necesita.
Sin embargo, no estamos limitados a la cola de conexiones JDBC. Podemos sobreescribir el comportamiento de la cola de conexiones del Bean y sustituirla nosotros mismos.
�Descriptor de Desarrollo
La configuraci�n restante para un Brans persistente controlado por contenedor ocurre en el momento del desarrollo. Lo que ves abajo es un Descriptor de Desarrollo basado en texto usado en un servidor de BEA Weblogic Enterprise JavaBeans.
�Texto del Descriptor de Desarrollo
(environmentProperties
(persistentStoreProperties
persistentStoreType jdbc
(jdbc
tableName registration
dbIsShared false
poolName ejbPool
(attributeMap
creditcard creditcard
emailaddress emailaddress
balance balance
password password
theuser theuser
); end attributeMap
); end jdbc
); end persistentStoreProperties
); end environmentProperties
El descriptor de desarrollo indica que el almacenamiento es una base de datos cuya conexi�n est� contenida en una cola de conexiones JDBC llamada ejbPool. El attributeMap contiene la variable del Bean Enterprise a la izquierda y su campo asociado de la base de datos a la derecha.
�Descriptor de Desarrollo XML
En Enterprise JavaBeans 1.1, el descriptor de desarrollo usa XML. Aqu� est� la configuraci�n equivalente en XML:
<persistence-type>Container</persistence-type>
<cmp-field><field-name>creditcard
</field-name></cmp-field>
<cmp-field><field-name>emailaddress
</field-name></cmp-field>
<cmp-field><field-name>balance
</field-name></cmp-field>
<cmp-field><field-name>password
</field-name></cmp-field>
<cmp-field><field-name>theuser
</field-name></cmp-field>
<resource-ref>
<res-ref-name>registration</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
Los campos del contenedor controlador se mapean directamente a su nombre contraparte en la tabla de la base de datos. El recurso de autorizaci�n del contenedor (res-auth) significa que el contenedor maneja el login a la tabla REGISTRATION.
�M�todos de B�squeda del Contenedor Controlador
La facilidad de b�squeda de la casa de subastas est� implementada como un m�todo finder del contenedor. Arranca cuando el usuario escribe una cadena de b�squeda y pulsa el bot�n Submit en la p�gina principal para localizar un �tem de la subasta. Como se muestra en el diagrama, el navegador pasa la cadena de b�squeda al m�todo AuctionServlet.searchItem, que luego la pasa al m�todo BidderBean.getMatchingItemsList.
En este punto, BidderBean.getMatchingItemsList pasa la cadena de b�squeda al m�todo findAllMatchingItems declarado en el interface AuctionItemHome. Este m�todo es un m�todo buscador, y la implementaci�n del contenedor var�a la forma en que maneja las llamadas a los m�todos finder. Los contenedores BEA Weblogic buscan en el descriptor de desarrollo del Bean la informaci�n sobre los m�todos finder.
En el caso de la busqueda, el descriptor de desarrollo mapea la cadena de b�squeda pasada a AuctionItemHome.findAllMatchingItems al campo summary en la tabla AuctionItems de la base de datos. Este le dice al servidor Enterprise JavaBeans que recupere datos de todos los campos que en el campo summary contengan el texto de la cadena de b�squeda.
Esta secci�n pasea a trav�s de las diferentes partes del c�digo de b�squeda finder.
�AuctionServlet.searchItems
El m�todo searchItems recupera el texto de la cadena del navegador, crea una p�gina HTML para mostar el resultado de la b�squeda, y le pasa la cadena de b�squeda al m�todo BidderBean.getMatchingItemsList. BidderBean es un Bean de sesi�n que recupera una lista de �tems de la subasta y chequea la ID y la password del usuario para los usuarios que quieren pujar por alg�n articulo.
Los resultados de la b�squeda se devuelven a este m�todo en una variable Enumeration.
private void searchItems(ServletOutputStream out,
HttpServletRequest request)
throws IOException {
//Retrieve search string
String searchString=request.getParameter(
"searchString");
//Create HTML page
String text = "Click Item number for description
and to place bid.";
setTitle(out, "Search Results");
try {
addLine("<BR>"+text, out);
//Look up home interface for BidderBean
BidderHome bhome=(BidderHome) ctx.lookup(
"bidder");
//Create remote interface for BidderBean
Bidder bid=bhome.create();
//Pass search string to BidderBean method
Enumeration enum=(Enumeration)
bid.getMatchingItemsList(searchString);
if(enum != null) {
displayitems(enum, out);
addLine("", out);
}
} catch (Exception e) {
addLine("AuctionServlet Search Items error",
out);
System.out.println("AuctionServlet <newlist>:
"+e);
}
out.flush();
}
�BidderBean.getMatchingItemsList
El m�todo BidderBean.getMatchingItemsList llama al m�todo AuctionItemHome.findAllMatchingItems y le pasa la cadena de b�squeda. AuctionItemBean es un bean de entidad que maneja actualizaciones y recuperaciones de �tems de la subasta.
El resultado de la b�squeda es devuelto a este m�todo en una variableEnumeration.
public Enumeration getMatchingItemsList(
String searchString)
throws RemoteException {
Enumeration enum=null;
try{
//Create Home interface for AuctionItemBean
AuctionItemHome home = (AuctionItemHome)
ctx.lookup("auctionitems");
//Pass search string to Home interface method
enum=(Enumeration)home.findAllMatchingItems(
searchString);
}catch (Exception e) {
System.out.println("getMatchingItemList: "+e);
return null;
}
return enum;
}
�AuctionItemHome.findAllMatchingItems
El m�todo AuctionItemHome.findAllMatchingItems no est� implementado por AuctionItemBean. Las implementaciones del m�todo AuctionItemBean finder est�n definidas en el descriptor de desarrollo de AuctionItemBean cuando se usan contenedores de BEA Weblogic.
Cuando se usan estos contenedores, incluso si el Bean tiene implementaciones del m�todo finder, son ignorados y en su lugar se consultan las selecciones en el descriptor de desarrollo.
//Declare method in Home interface public Enumeration findAllMatchingItems( String searchString) throws FinderException, RemoteException;
�Descriptor de Desarrollo de AuctionItemBean
Cuando se llama a un m�todo finder de un Bean, el contenedor consulta el descriptor de desarrollo para ese Bean para encontrar qu� datos necesita recuperar el m�todo finder de la tabla de la base de datos. El contenedor pasa esta informaci�n al servidor Enterprise JavaBeans, que hace la recuperaci�n real.
El descriptor de desarrollo para AuctionItemBean proporciona finderDescriptors para todos los m�todos finder declarados en el interface AuctionItemHome. El finderDescriptor para el m�todo findAllMatchingItems mapea la cadena de b�squeda al campo summary de la tabla AuctionItems de la base de datos. Esto le dice al servidor Enterprise JavaBeans que recupere los datos de todas las filas de la tabla en las que el contenido del campo summary corresponda con el texto de la cadena de b�squeda.
(finderDescriptors "findAllItems()" "(= 1 1)" "findAllNewItems(java.sql.Date newtoday)" "(= startdate $newtoday)" "findAllClosedItems(java.sql.Date closedtoday)" "(= enddate $closedtoday)" "findAllMatchingItems(String searchString)" "(like summary $searchString)" ); end finderDescriptors