2.17.2.2. Stateful Session Beans 2.17.2.2.1. Uso
Se tratarán los Stateful Beans. Tanto los Stateless Session Beans como los Stateful Session Beans se parecen mucho, así que su construcción es prácticamente idéntica. También la manera en la que un cliente accede al bean es la misma. Por lo tanto es bastante conveniente leerse primero el apartado sobre los Stateless Session Bean, pues se hará constantemente referencia a él. La diferencia fundamental es que una instancia de un Stateful Session Bean estará siempre firmemente vinculada a un cliente y solo está a su disposición. Ningún otro puede llamar métodos en la instancia de bean concreta, a no ser que se le transmita explícitamente una referencia a este bean.
Esto conlleva algunas consecuencias. Así pues es más que razonable que un Stateful Session Bean disponga de atributos en los que se recuerdan las llamadas de métodos. Es también posible iniciar la instancia del bean individualmente debido a la firme conexión con el cliente. Por otro lado también es necesario que el cliente comunique al servidor cuando deja de requerir la instancia de Bean para que así el servidor pueda desbloquearla. Este a su vez debe tomar las precauciones necesarias para poder administrar tantas instancias de un Stateful Session Bean como quiera. Se ilustraran estos puntos más detalladamente al hablar sobre el método de trabajo.
Los Stateful Session Beans siempre entran en acción cuando un cliente ejecuta una conversación con el servidor durante varias llamadas de método, mientras este debe guardar el estado constantemente cambiante y la gran cantidad de información transmitida. Los métodos individuales de un bean con estado no son por lo tanto servicios simples, que pueden llamarse el uno detrás del otro sin orden ni concierto, carentes de ningún tipo de relación entre ellos, sino mas bien métodos business que se construyen uno a partir del otro y que contribuyen pieza a pieza a ejecutar una tarea mas o menos compleja.
Una tarea de este tipo, que se extiende a lo largo de varias llamadas de métodos, podría ser la recepción de un pedido, para el que el usuario primero debe registrarse y después introducir qué cantidad desea recibir de cada artículo, hasta que finalmente da por aceptado el pedido completo o bien lo rechaza. En cada una de estas acciones la instancia bean del servidor debe controlar con exactitud bajo que nombre se ha registrado cada cliente y que artículos ha escogido. Debe asegurarse de que dos usuarios diferentes que deseen llevar a cabo un pedido al mismo tiempo no se entorpezcan el uno al otro.
Como ya se ha descrito, en una aplicación concreta habrá tanto Stateful como Stateless Session Beans. La idea es que un bean pueda utilizar servicios de otro y funcione
80
entonces como cliente del otro bean. En este caso son posibles todas las combinaciones aunque lo mas probable es que un bean con estado utilice los servicios de un bean sin estado. En el caso contrario el bean sin estado debería resolver el trabajo completo dentro de solo un de sus métodos.
El servidor de aplicaciones debe mantener una instancia propia de un Stateful Session Bean para cada cliente. Ante esta idea, desarrolladores experimentados, que ya han trabajado previamente con tecnologías basadas en servidores como CICS o similar, temen que el servidor justo en pleno funcionamiento pueda no estar en situación de administrar tantas instancias. Podría fallar la memoria principal o algo parecido. De hecho debe comentarse que es principalmente este círculo de persona el que intenta programarlo siempre todo con Stateless Session Beans porque estos no exigen tantos recursos. Pues bien, los diseñadores de JavaEE Standard son plenamente conscientes del reto del pleno rendimiento. Un servidor de aplicaciones tiene medios suficientes para enfrentarse a esto sin problemas. Por un lado, hoy en día cualquier servidor decente está dotado de por lo menos 1 o 2 Gigabytes de memoria principal, por otro lado puede llevar a un estado pasivo las instancias de beans no requeridas en el momento, es decir, se almacenan y se guardan en el disco duro. Por este motivo para un servidor de aplicaciones es importante disponer de discos duros lo más rápidos posibles. Si aun así el hardware no fuera suficiente, se puede dividir el servidor en varias maquinas físicas, creando un cluster. Al programador de una aplicación JavaEE esto no le afecta en absoluto. En ningun punto se verá obligado a escribir un código concreto para capacitar este cluster, a no ser que utilice tecnologías que funcionen en uno.
2.17.2.2.2. Estructura
2.17.2.2.2.1. La clase bean
Un Stateful Session Bean es una clase java normal. La denominación Bean en el nombre de la clase CestaCompraBean hace referencia a su uso como tal. La clase implementa una interfaz con el nombre CestaCompraRemote, en la que se llevan a cabo los métodos business del bean, que en este caso se puede utilizar por un cliente remoto.
package server.sf; import java.util.Vector; import javax.ejb.Stateful; @Stateful
public class CestaCompraBean implements CestaCompraRemote {
protected Vector<Pedido> pedidos = new Vector<Pedido>( ); public void addPedido(Pedido best)
{
best.setCantidadEntrega(best.getCantidad( )); pedidos.add(best);
}
public Vector<Pedido> getPedidos( ) {
return pedidos; }
81