Policy Relevance

close() y isOpen()

El método close() cierra un EntityManager, de modo que ya no podrá volver a utilizarse. Si el correspondiente Persistence Context se encuentra en ese momento dentro de una transacción este se conducirá hasta el final de la transacción. La llamada del método close() a un EntityManager administrado por un servidor de aplicaciones conduce a una IllegalStateException.

El método isOpen() devuelve true, cuando el EntityManager actual está abierto y está a disposición de futuras modificaciones.

2.19.2.6. Administración y Desadministración de Entidades

Los Entity Beans se diferencian entre si dependiendo de si se encuentran o no bajo control de un EntityManager. Un bean se denominará administrado cuando esta siendo supervisado y por lo tanto cada modificación puede conducir a una acción en el banco de datos. Si se crea una instancia de bean a través de la misma llamada del constructor, hablamos por el contrario de un bean desadministrado, porque ningún EntityManager se interesa por él. Para que una instancia de bean normal se convierta en bean administrado, debe transmitirse al EntityManager mediante un método como persist(). Si en el caso de un Persistence Context orientado a transacciones finaliza la transacción, todos los beans administrados se convertirán de nuevo en beans desadministrados, es decir serán de nuevo instancias Java normales. En el caso de un Persistence Context ampliado esto no es así. Los beans se mantienen bajo control del EntityManager. Incluso cuando se modifican fuera de una transacción, estos cambios se sincronizarán con la base de datos, una vez la siguiente transacción iniciada finalice. Esta situación se puede dar cuando un Stateful Session Bean disponga de un Persitence Context ampliado y ofrezce métodos que no soporten ninguna transacción, pero que modifiquen sin embargo los atributos de beans controlados.

2.19.3. Entity Beans

149

Los Entity Beans son el portal a la base de datos o mejor dicho, el paso intermedio al nivel de persistencia, que no siempre debe tratarse de una base de datos relacional. Todos los datos guardados a largo plazo deben subyace como atributos de este tipo de bean u no estar dispersos por toda la aplicación. Este hecho es una característica esencial en la arquitectura de las aplicaciones Java EE, que de este modo prevé una estricta separación entre el nivel de mantenimiento de datos y el nivel lógico.

En sistemas programados de modo clásico aún sucede bastante a menudo que no existe esta separación. Muchos desarrolladores de aplicaciones se concentran a veces demasiado en el problema a resolver y no prestan ninguna atención a cuestiones de arquitectura y diseño. Si se les encarga hacer un programa para la gestión de los datos maestros de productos en venta, en el caso ideal se crea una clase Java que contiene los métodos necesarios para ello como CrearNuevoArticulo o ModificarArticulo. Con una nueva creación se transmiten al método todos los datos relevantes del artículo y se comprueban. Si los datos son correctos, se inscriben simplemente en la base de datos con ayuda de una instrucción SQL. Y justo aquí reside el problema. Tanto el nombre como la estructura de la tabla de base de datos deben conocerse llegados a este punto. Se crea código fuente que solo se ocupa del proceso técnico de guardado, en una clase que debería representar tecnicidad. Si la tarea consiste entonces en modificar un artículo, se escribe otro método al que quizás debe dársele el número de artículo. Uno de los primeros pasos en este método será de nuevo un SQL-Satement, que esta vez leerá los datos desde la tabla. Nuevamente el desarrollador se refuere a una tabla concreta con nombres de columnas concretos y lo que es aún peor, programa la condición a partir de la cual el sistema de base de datos debe encontrar estos datos. Cuando se tiene ante los ojos este panorama en toda su complejidad, enseguida se constata que el nivel de acceso al completo se dispersa entre incontables clase, lo que hace prácticamente imposible cualquier modificación o consolidación. Con razón cualquier inclusión posterior de otra columna en una tabla de base de datos conlleve un esfuerzo inmenso, pues se tienen que comprobar todos los puntos que mantiene alguna relación con la tabla correspondiente. Un bean de entidad es un clase Java normal, que representa con sus atributos las columnas de una tabla de un banco de datos. Un desarrollador EJB no necesita tener ningún contacto directo más con el banco de datos, sino simplemente manejar los datos mediante las instancias de Entity Beans. Si se tiene que archivar un nuevo artículo, se crea tan solo una nueva instancia de bean. Si quiere modificar datos llama el método de búsqueda correspondiente y recibe de vuelta un objeto Java normal, en el que se lleva a cabo su modificación. Tanto el hecho de que aquí debe ser algo guardado, como la manera en la que esto ha ocurrido técnicamente, lo determina el servidor de aplicaciones y de este modo se libera al desarrollador de la necesidad de tener en cuenta una gran cantidad de detalles.

Todas las informaciónes técnicas requeridas subyacen exclusivamente en la clase de los Entity Beans. Ahí y tan solo ahí se describe, por ejemplo, cómo se llama la tabla, qué nombres tienen cada una de las columnas y cómo se debe buscar información en el banco de datos en cada caso. Así todo el nivel de persistencia esta encapsulado en clases determinadas y es independiente de la aplicación misma. Si se añade posterirmente una nueva columna a un sistema de este tipo primero se amplia la lista de atributos del Entity Bean correspondiente, asegurando así que la nueva información estará disponible en

150

todos los puntos relevantes de la aplicación. Si el nuevo valor es relevante en pedidos existentes, estos se pueden modificar centralmente y esto repercutirá inmediatamente en toda la aplicación. Los desarrolladores se pueden concentrar en su propio trabajo, es decir en controlar que la nueva información se maneje técnicamente en forma conrrecta.

La aproximación existente entraña aún otra gran ventaja. En cada acceso a un Entity Bean se implica el servidor de aplicación. Él sabe, con ayuda de sun Entity Manager, dónde se utiliza cada bean y cómo se modifica. Conoce en cada caso ideal todas las rutas de acceso a los datos que existen dentro de la aplicación y así las puede desarrollar eficientemente. Todo servidor de aplicaciones razonable generará con el primer acceso a través de un SQL-Statement un PreparedStatement, con la ayuda del cual tienen lugar simultáneamente un análisis sintáctico de la indicación y una búsqueda de la ruta de acceso. Esto se puede utilizar siempre que sea necesario para realizar el acceso con los parámetros validos en esta ocasión. Después de poco tiempo de duración del servidor a este ya le correponde una reelaboración como en los sistemas estaticos SQL, que técnicamente son de los mas eficientes. La ventaja descrita aquí resulta más efectiva cuantas menos indicaciones SQL propias escriban los desarrolladores en sus programas. Cuanto más consecuentes sea la aproximación del Entity Bean, menos SQL deberán programarse.

Los Entity Beans existen tan solo desde EJB 3.0. en versiones previas del estándar EJB la separación entre la clase bean y sus metainformaciones como nombres de tablas o declaraciones de acceso era mucho más estricta que hoy y por ese motivo para muchos algo muy complicado. Todas estas informaciones se encontraban tan solo en el Deployment Descriptor. En este punto con el nuevo estándar se ha empeorado en lo que se refiere a la arquitectura, para favorecer un manejo más sencillo. Hoy en día el desarrollador EJB trabaja directamente con el EntityManager, para acceder a través de él a las instancias de beans. Desafortunadamente es posible transmitir al EntityManager una declaración SQL como cadena de simbolos para realizar una búsqueda o una actualización masiva. Un uso frecuente de esto puede conducir nuevamente a que el nivel técnico de acceso se disperse en clases. Para seguir trabajando de manera limpia es muy recomendable declarar instrucciones de codificación y controlar también estas. El estándar ofrece de hecho todo lo necesario para concetrar estos detalles técnicos en la clase Entity Bean. Es algo que tan solo depende de uno mismo.

2.19.3.2. Estructura

Los Entity Beans son POJOs. Esta abreviatura significa Plain Old Java Objects, es decir para clases Java normales, convencionales. A diferencia de los Session Beans no implementan ninguna interfaz especial y cuando se renuncia a anotación, nada hace referencia a su significado como Entity Bean. en consecuencia este tipo de instancias de bean pueden utilizarse en cualquier parte, siempre es posible incluso enviarlas al cliente, para que este pueda mostrar sus datos. A menudo los Entity Beans son objetos serializados, de modo que sus referencias pueden ser retenidas por Stateful Session Beans. Cada Entity Bean debe disponer de un constructor estándar porque, entre otros, es tarea del EntityManger crear instancias a partir de esto.

151

Solo después de asociar un Entity Bean con un EntityManager surte efecto su verdadero significado. El EntityManager lee la metainformacion o bien desde la clase bean o desde el Deployment Descriptor y se ocupa de que los datos sean comparados con los de la base de datos. Un EntityManager de este tipo también puede existir sin servidor de aplicaciones. De este modo es posible escribir aplicaciones que también funcionen en un entorno Java SE.

CREATE TABLE ARTICULO {

ARTNR INTEGER NOT CERO PRIMARY KEY, DES VARCHAR(256) NOT CERO,

PRECIO DECIMAL(7, 2) NOT CERO, CANTIDAD INTEGER NOT NULL }