Supongamos que un cliente llama primero el método setObj() y transmite una instancia cualquiera con la esperanza de recibirla de nuevo al llamar getObj(). Justo aquí reside el problema. El cliente no opera en realidad directamente con la instancia de bean sino solo con una referencia local o remota y es tarea del servidor de aplicaciones con que instancia de bean ejecuta las llamadas. Lo peligroso aquí es que cuando se prueba todo con un solo cliente esto puede incluso llegar a funcionar. ¡Pero cuidado si después entra un segundo o un tercer usuario en juego!
También aquí se recomiendan normas exactas para el equipo desarrollador. Los Stateless Session Bean no tienen ningún atributo, a no ser que deban estar todos a disposición de los clientes simultáneamente. En un caso así también se debería declarara static, y así lo serían tal y como se desprende de su significado. Aparece sin embargo asi de inmediato el problema que en un Cluster de varios servidores todos los atributos estáticos existen independientemente los unos de los otros. La practica ha demostrado que con una
67
programación así se debe procurar, que una aplicación no sea de repente apta para un cluster y se desaproveche así una ventaja fundamental de cualquier aplicación EJB.
Resumiendo, se podría afirmar que una instancia de un Stateless Session Bean no está nunca reservada para un cliente concreto sino para todas las consultas entrantes, para las que esté disponible. Esto subraya de nuevo la afirmación de que en los métodos de un Stateless Bean se trata de funciones que se pueden llamar sin un contexto técnico y que son efectivas tan solo con los parámetros transmitidos.
2.17.2.1.4. Acceso al entorno
Como todos los beans los Stateless Session Beans también se ejecutan por el servidor de aplicaciones dentro un entorno definido. Dentro de este entorno se pueden definir todo tipo de recursos, a los que el bean tiene acceso. Estos recursos pueden tratarse de, por ejemplo, una instancia de la clase javax.sql.DataSource a través de la cual se puede crear una conexión con una base de datos, o también de otros metadatos en forma de Strings normales, a través de los que se puede definir el comportamiento de la clase bean. Como ejemplo para una entrada de entorno así se ampliara la clase bean ServidorTemporalBean con un método getTimeString(), que muestra la fecha y la hora actual como una cadena de símbolos. Todo se lleva a cabo con ayuda de la clase SimpleDateFormat, a la que se le transmite el formato de String correspondiente. Como se puede ver en el fragmento del Código 2.14, es posible obtener acceso a los recursos del entorno a través de la anotación @Resource. Además la anotación debe ser programada justo antes del atributo en el que se va a inyectar el recurso.
@Resource(name=”FormatString”) String formatString; public String getTimeString()
{
SimpleDateFormat sdf = null; if( formatString != null )
sdf = new SimpleDateFormat(formatString); else
sdf = new SimpleDateFormat(); return sdf.format(new Date()); }
Código 2.14: Acceso al entorno
La variable formatString del ejemplo permanece en el valor null, si no puede encontrar ninguna entrado con el nombre FormatString en el entorno. Por eso la consulta diferente de null es absolutamente necesaria si no se quiere correr el riesgo de obtener una NullPointerException. Ahora solo queda pendiente la cuestión de cómo llevar a término una entrada así en el entorno del bean. se trata de un archivo XML con el nombre ejb- jar.xml, que se crea de una norma precisa y que debe ser copiado en el directorio META- INF del archivo JAR. Al contrario que en el estándar EJB previo este Deployment Descriptor es esencialmente más breve. El archivo externo XML, tiene la ventaja que se
68
puede adaptar antes del Deployment, sin que se tengan que traducir nuevamente las clases Java contenidas.
<ejb-jar xmlns=”http://java.sun.com/xml/ns/javaee” xmlsn:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:SchemaLocation=”http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd” versión=”3.1”> <enterprise-beans> <session> <ejb-name>ServidorTemporalBean</ejb-name> <env-entry> <env-entry-name>FormatString</env-entry-name> <env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>E, dd.MM.aaaa HH:mm:ss</env-entry-value> </env-entry>
</session>
</enterprise-beans> </ejb-jar>
Código 2.15: Deployment Descriptor ejb-jar.xml
Cree en su proyecto actual una carpeta de nombre META-INF y en él un archivo con el nombre ejb-jar.xml con el contenido del Código 2.15. Abra el JAR Packager para el archivo jardesc del proyecto e intente que la carpeta META-INF también se vincule. Para que se cree de nuevo el correspondiente archivo JAR basta con ejecutar la opción CREATE JAR también con ayuda del botón derecho del ratón. Si no se encontrara el archivo JAR automáticamente en el directorio correspondiente, debe ser copiado allí. En el Código 2.16 se reproduce la clase bean completa.
import java.text.SimpleDateFormat; import java.util.Date;
import javax.annotation.Resource; import javax.ejb.Stateless; @Stateless
public class ServidorTemporalBean implements ServidorTemporalRemote {
@Resource(name=”FormatString”) String formatString; public long getTime()
{
return new Date().getTime(); }
public String getTimeString() {
SimpleDateFormat sdf = null; if( formatString != null )
sdf = new SimpleDateFormat(formatString); else
sdf = new SimpleDateFormat(); return sdf.format(new Date()); }
}