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 JavaBeansTM 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 los siguientes capítulos veremos como podemos personalizar estos servicios e integrar estas características en aplicaciones existentes no EJB.
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.
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.
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 |
Los cuatro Beans del ejemplo son:
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.
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.
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..
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 JavaTM 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.