Código de la Aplicación Casa de Subastas
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
Tutoriales
