EJB (II), creacrión de un SLSB
domingo, octubre 5, 2003 at 2:00AM
Enterprise Java Beans (II)
Fecha de creación: 21.07.2003
Revisión 1.0 (21.07.2003)
Enrique Rodriguez Lasterra
lasterra AT javahispano DOT org
|
Introducción
En la primera parte de esta serie de artículos se explicaban los 3 tipos
de EJB existentes en la especificación.
El objetivo de este artículo es profundizar en la arquitectura EJB,
mostrar como se programa un EJB y cuales son los elementos principales
de los descriptores, además del funcionamiento de los SLSB.
Para el ejemplo se ha elegido la implementación de una calculadora y como
servidor de aplicaciones donde realizar las pruebas JBoss 3.x.
Elementos de un EJB
Tal y como se explicó en el anterior artículo, la arquitectura de los EJB cuenta con más de un elemento. El programador de EJB debe programar una clase, dos interfaces y escribir al menos un descriptor XML Este trabajo sería en vano de no ser por el contenedor de EJB que será el encargado de procesar la información y hacer de nuestro trabajo un componente distribuido, transaccional, multihilo, etc.
Para que la relación entre código y contenedor sea posible el programador debe seguir las normas marcadas en la especificación EJB.
La clase Bean
Esta clase es el componente principal de un EJB, sobre todo desde el punto de vista del programador. Se trata de una clase Java que implementa un interfaz definido por la especificación EJB:
En el caso de un EJB de sesión será el interfaz javax.ejb.SessionBean.
En el caso de un EJB de entidad será el interfaz javax.ejb.EntityBean
En el caso de un EJB de mensajería será el interfaz javax.ejb.MessageDrivenBean
Todos estos interfaces heredan de javax.ejb.EnterpriseClass, que es un interfaz sin operaciones que hereda de java.io.Serializable. El objetivo de este es marcar a todas las clases que la implementen como una Clase EJB y además hacer que esta clase se pueda serializar, algo necesario para cualquier Objeto al que se quiera llamar a través de la red.
Ya que este artículo es sobre SLSB, nuestra Clase Bean debe implementar el interfaz SessionBean.
/**
* Ejemplo de EJB de sessión sin estado. Para ello se va a implementar
* una calculadora con sus cuatro operaciones básicas.
*
* @author lasterra AT javahispano DOT org
*/
public class CalculadoraBean implements javax.ejb.SessionBean
Este interfaz tiene operaciones específicas definidas para los EJB de sesión. Si nos fijamos en los JavaDoc de este interfaz [1] se puede ver que consta de 4 métodos que la clase Bean del EJB deberá implementar. Estas operaciones definen el ciclo de vida de los EJB junto con una operación no presente en el interfaz, el ejbCreate.
La operación setSessionContext es llamada por el contenedor después de la creación del EJB y recibe del contenedor la información del contexto. Esta información debe ser almacenada como dato miembro del EJB y a través de ella podemos acceder a información del contenedor.
/**
* El objeto SessionContext es el encargado de interactuar con el
* contenedor de EJB. A traves de él se puede acceder a información
* acerca de si el cliente tiene permisos de ejecución o sobre el
* estado transaccional.
*
* Una referencia a este objeto debe ser guardada como dato miembro
* de los EJB.
*
* La implementación típica suele ser la siguiente
*
* @param sessionContext Contexto del EJB fijado por el contenedor
* @throws EJBException Se lanza para avisar al contenedor que algo
* ha fallado
*/
public void setSessionContext(javax.ejb.SessionContext sessionContext)
throws javax.ejb.EJBException
{
this.sessionContext = sessionContext;
}
Las operaciones ejbActivate y ejbPassivate son invocadas por el contenedor para llevar a cabo el proceso de pasivación del los EJB. Al ser los SLSB EJB sin estado no tienen mucho sentido estas operaciones, ya que como su nombre indica no tienen estado (sesión) y por tanto no tiene sentido que un SLSB almacene información que se pueda considerar interesante de almacenar en el caso de que el servidor necesite efectuar un proceso de pasivación.
La operación ejbRemove indica que no se van a realizar mas operaciones con EJB y por lo tanto que el contenedor puede almacenar la instancia en el pool de EJB. Esta operación puede ser invocada por el cliente o por el contenedor si se da un time out.
La operación ejbCreate es la que crea el EJB, o mejor dicho, es la que cede una instancia del EJB al usuario, ya que la instancia puede haber sido creada con anterioridad y se encuentra esperando en el pool de EJB. No aparece en la interfaz SessionBean ya que es el programador quien decide cuales son los parámetros que le deben llegar al EJB para crearse. Es necesario al menos un ejbCreate y se puede sobrecargar tantas veces como el programador lo desee. Para los SLSB no tiene sentido pasar parámetros a través del ejbCreate ya que al ser sin estado nada garantiza el poder hacer uso de esos parámetros en el futuro.
/**
* Este método es llamado por el contenedor cuando el cliente llama
* al metodo create de la interfaz Home.
*
* Debe existir al menos un ejbCreate y por cada uno de ellos tiene
* que haber una operación create con los mismos parametros en la
* interfaz Home.
*
* Este metodo se puede sobrecargar tantas veces como queramos para
* así poder inicializar el EJB de distintas formas.
*
* En el contexto de un SLSB no tiene mucho sentido pasar
* parametros en el ejbCreate, ya que al no mantenerse un sesión entre
* cliente y EJB, no debemos definir como dato miembro del EJB ninguna
* información relacionada con el cliente.
*
* @throws CreateException Se lanza para avisar al contenedor que algo
* ha fallado al crearse el EJB
*/
public void ejbCreate() throws javax.ejb.CreateException
{
log.debug("Inicializando el Bean");
}
Por ultimo, es en esta clase donde se implementa la lógica de negocio del EJB. En el ejemplo de la calculadora es aquí donde se encuentra los métodos sumar, restar, dividir y multiplicar.
//métodos de negocio /Business Methods
//Todas estas operaciones deben aparecer de la misma forma en el
//InterfazRemoto
/**
* Operación sumar
* @param op1 operando 1
* @param op2 operando 2
* @return Suma de los dos operandos
* @throws EJBException Se lanza para avisar al contenedor que algo
* ha fallado
*/
public int sumar(int op1, int op2) throws javax.ejb.EJBException
{
log.debug("sumar");
return op1+op2;
}
Todos los métodos de la clase Bean deben lanzar la excepción javax.ejb.EJBException. El programador podrá heredar de ella o lanzar otras junto a esta.
La interfaz Remota
Los EJB además de ser componentes distribuidos implementan una serie de facilidades que hacen más simple la labor del programador. Esto es posible gracias a la interfaz remota y al EJB Object.
La interfaz remota es la vista que el cliente tiene del EJB. En ella se encuentran todas las operaciones de la lógica de negocio más las heredadas por la interfaz javax.ejb.EJBObject. [2]
/**
* Interfaz Remoto del EJB calculadora. Es la vista del EJB para el
* cliente. En el aparecen tanto los business methods de la clase
* Bean como las operaciones del interfaz del que hereda, el
* javax.ejb.EJBObject
*
* @author lasterra AT javahispano DOT org
*/
public interface Calculadora extends javax.ejb.EJBObject
El programador debe implementar una interfaz remota por cada clase Bean. Esta interfaz será implementada por el EJB Object, que es un objeto generado e instanciado por el contenedor cuya función es hacer de pasarela entre el cliente y el EJB a través del contenedor.
Al igual que la clase Bean es la parte más importante para el programador, el EJB Object es la parte más importante para el servidor. Si veis los JavaDoc del interfaz javax.ejb.EJBObject se puede observar que:
Extiende de java.rmi.Remote, por lo que nuestro interfaz remoto es también un interfaz Java RMI remoto y permite realizar llamadas a través de la red.
Tiene una operación para obtener el EJBHome: getEJBHome()
Tiene una operación para borrar el EJB, o mejor dicho, para devolverlo al pool de EJB: remove()
Una operación para saber si dos EJB son iguales: isIdentical(EJBObject obj)
Una operación para obtener la clave primaria del EJB: getPrimaryKey() (Solo aplicable a Beans de Entidad)
Una operación para obtener el "handle" del EJB: getHandle(). El javax.ejb.Handle es una referencia persistente a un EJB. Hablaremos más de ella en futuros capítulos.
El contenedor genera el EJB Object, y además de ahorrar el trabajo de la programación de los stub y skeletons RMI al programador, intercepta las llamadas entre cliente y EJB para poder efectuar el control de seguridad, el tratamiento de las transacciones, la gestión del pool de EJB y en general, todas aquellas operaciones que el contenedor quiera llevar a cabo sobre los EJB.
Para implementar la interfaz remota simplemente hay que introducir las operaciones de lógica de negocio del EJB que se encuentran en la clase Bean, con los mismos parámetros, retorno y excepciones. A estas últimas hay que añadir la excepción java.rmi.RemoteException, por ser el EJB Object un objeto de invocación remota.
/** Operación sumar
* @return Suma de los dos operandos
* @param op1 operando 1
* @param op2 operando 2
* @throws RemoteException Necesaria ya que el el objeto del
* contenedor que implementa esta interfaz
* (EJB OBject) es un Objeto Remoto RMI
* @throws EJBException Se lanza para avisar al contenedor que algo
* ha fallado
*/
public int sumar(int op1, int op2)
throws javax.ejb.EJBException, java.rmi.RemoteException;
La interfaz Home
La interfaz Home es la encargada de intermediar entre el cliente y el contenedor para obtener referencias de EJB.
Al igual que el EJB Object era un objeto generado por el contenedor en base a una interfaz de la especificación y a la interfaz remota del EJB, en este caso nos encontramos con el Remote Home Object, generado en este caso en base a la interfaz Home y a la interfaz javax.ejb.EJBHome.
Esta clase implementa principalmente dos patrones de diseño:
Factory y por tanto se limita a operaciones de creación, búsqueda y destrucción de EJB.
Singleton por lo que solo hay un instancia en memoria. Esto hace que las referencias al Remote Home Object sean cacheables por el cliente al menos en entornos no distribuidos, algo muy aconsejable y que puede ahorrar un tiempo considerable.
En la interfaz Home se declaran las operaciones para crear, borrar y buscar EJB. Esta interfaz además hereda de javax.ejb.EJBHome que a su vez hereda de java.rmi.Remote, por lo que el Remote Home Object también es un objeto RMI.
/**
* Interfaz Home del EJB Calculadora, a través de este interfaz
* el Cliente obtiene la referencia a los EJB.
*
*
* @author lasterra AT javahispano DOT org
*/
public interface CalculadoraHome extends javax.ejb.EJBHome
En la interfaz javax.ejb.EJBHome aparecen las operaciones para:
Borrado/liberación de instancias de EJB por parte del cliente, remove()
Captura de meta-información del EJB, getMetaData()
Obtener el "Handle" del objeto Home remote, getHandle()
El trabajo del programador es incluir un método Create con los mismos parámetros y excepciones por cada uno de los ejbCreate que tenga la clase Bean. Además en el caso de los Beans de entidad, hay que incluir los métodos finders, encargados de hacer las busqedas, siendo el findByPrimaryKey obligatorio. Esto lo veremos en futuros capítulos.
/**
* Metodo create en el interfaz Home. Enlaza con el metodo ejbCreate
* del Bean.
* El cliente obtiene a traves de este método la referencia al EJB.
*
* @throws RemoteException Necesaria ya que el el objeto del
* contenedor que implementa esta interfaz
* (Home OBject) es un Objeto Remoto RMI
* @throws CreateException Necesaria para todos los métodos create
* @return Devuelve la referencia al EJB, es decir,
* el Interfaz Remoto
*/
Calculadora create()
throws javax.ejb.CreateException, java.rmi.RemoteException;
Transparencia de la situación física
La especificación EJB define la necesidad de que los EJB sean objetos que puedan residir en máquinas distintas del cliente. Esto es posible gracias a que tanto el interfaz Home como el interfaz Remoto son interfaces RMI pero no hay que olvidar el papel que comple el Java Native and Directory Interface (JNDI).
El JNDI es la interfaz Java de los Servicios de Directorio. Un Servicio de directorio es un repositorio de objetos, con estructura arbórea, a los que se les asocia un nombre clave. Este tipo de estrucuturas ofrece unos índices de rendimiento muy altos en operaciones de lectura. Ejemplos de Servicio de Directorio son Iplanet Directory Server, Micorsoft Active Directory o LDAP. El Interfaz Java permite poner una capa intermedia para acceder a estos servicios de directorio, es decir, cumple un papel similar al JDBC con las Bases de Datos.
El JNDI es necesario por una razon muy simple, la clases que engloban un EJB son instanciadas por el contenerdor y es necesario guardar una referencia a estas en algún lugar accesible por el cliente, para que este las pueda recuperar.
Ya que la especificación EJB indica que los EJB pueden ser accesibles desde maquinas virtuales Java diferentes de la del contenedor, el servicio de directorio también lo debe ser. Es por ello que los servidores de aplicaciones implementan servicios de directorio con interfaz JNDI para guardar referencias de los Home Objects. Algunos servidores de aplicaciones incluso implementan versiones con capacidad de distribución, es decir, que el JNDI puede delegar las peticiones a máquinas diferentes.
El servidor de aplicaciones se encarga de guardar los Home Objects en el JNDI. Una vez el cliente tiene acceso al JNDI, puede recuperarlos a traves de la interfaz Home. Lo vermos mas claro en la sección en la que se explica como programar un cliente java.
Los interfaces locales
Como se ha explicado en los puntos anteriores, tanto el EJB Object como el Home Object son objetos RMI de invocación remota. Estos objetos son accesibles a través de la red pero con el coste de la serialización y envio de los objetos a través de la red. En el caso de que un cliente quisiese acceder a un EJB que se encuentra en la misma maquina virtual antes de la especificación 2.0, era necesario realizar llamadas remotas. A partir de esta nueva especificación aparecieron los interfaces locales, con los que se soluciono este problema.
Las ventajas principales son dos:
Aumento de la velocidad al no ser necesaria la serialización y el uso del protocolo RMI/IIOP
Paso de parámetros por referencia, lo que evita la nueva creación de los objetos.
La principal desventaja es que hay que escribir dos nuevos interfaces, exactamente iguales que los anteriores pero sin que lancen la excepción java.rmi.RemoteException.
Interfaz Remoto Local
/**
* Interfaz Remoto Local del EJB calculadora. A través de este
* interfaz el Cliente obtiene la referencia a los EJB.
*
* La Unica diferencia en "programación" entre interfaces remotos
* y locales es que los locales no lanzan java.rmi.RemoteException
*
* @author lasterra AT javahispano DOT org
*/
public interface CalculadoraLocal extends javax.ejb.EJBLocalObject{
/** Operación sumar
* @return Suma de los dos operandos
* @param op1 operando 1
* @param op2 operando 2
* @throws EJBException Se lanza para avisar al contenedor
* que algo ha fallado
*
*/
public int sumar(int op1, int op2) throws javax.ejb.EJBException;
.
.
.
Interfaz Home Local
/**
* Interfaz Home Local del EJB Calculadora. A través de este interfaz
* el Cliente obtiene la referencia a los EJB.
*
* La Unica diferencia en "programación" entre interfaces remotos y
* locales es que los locales no lanzan java.rmi.RemoteException
*
* @author lasterra AT javahispano DOT org
*/
public interface CalculadoraLocalHome extends javax.ejb.EJBLocalHome{
/**
* Método create en el interfaz Home. Enlaza con el metodo
* ejbCreate del Bean. El cliente obtiene a traves de este
* método la referencia al EJB.
*
* @throws CreateException Necesaria para todos los métodos
* create
* @return Devuelve la referencia al EJB,
* es decir, el Interfaz Remoto
*/
CalculadoraLocal create()
throws javax.ejb.CreateException;
}
Este sería el diagrama completo de todas las clases e interfaces que se han explicado.
 |
Los descriptores
Los descriptores son archivos XML de configuración de los EJB y que el contenedor lee para saber como debe actuar. El estándar EJB solo contempla uno, el archivo ejb-jar.xml aunque los servidores de aplicaciones suelen incluir otro con configuración propia y propietaria. Esta situación hace que se puedan realizar configuraciones muy interesantes en algunos servidores pero hace más difícil la migración de un EJB de un servidor de aplicaciones a otro.
La información que contiene el ejb-jar.xml sobre un EJB se podría dividir en tres grupos:
Información sobre el EJB
El tipo de EJB, si es de sesión, de entidad o de mensajería y de que subtipo, SLSB, SFSB, etc.
El nombre del EJB, este será el nombre con el que el contenedor identifica al EJB
La clase y los interfaces que componen el EJB
El tipo de transacciones que utiliza el EJB, si son transacciones manejadas por el servidor o son gestionadas por el propio usuario.
En caso de ser un Bean de entidad, información sobre los datos miembro del Bean que se guardan en la base de datos.
Gestión de transacciones
Es en el descriptor donde se configuran las transacciones a nivel de método. Es un tema un tanto complejo y lo trataremos en profundidad en futuros capítulos.
Gestión de seguridad
Los EJB tienen un control de seguridad muy completo que permite gestionar que usuarios o roles pueden acceder a un método de un EJB. También se explicará en futuros capítulos.
Este sería un ejemplo básico de un ejb-jar.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN"
"http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<!--
Document : ejb-jar.xml
Created on : 16 de junio de 2003, 0:43
Author : lasterra AT javahispano DOT org
Description:
ejb-jar.xml simple, es lo mínimo que exige JBoss.
Se toman por defecto las transacciones, y no se
especifica ningun control de seguridad
-->
<ejb-jar >
<enterprise-beans>
<session >
<ejb-name>Calculadora</ejb-name>
<home>
org.javahispano.ejemplos.slsb.CalculadoraHome
</home>
<remote>
org.javahispano.ejemplos.slsb.Calculadora
</remote>
<local-home>
org.javahispano.ejemplos.slsb.CalculadoraLocalHome
</local-home>
<local>
org.javahispano.ejemplos.slsb.CalculadoraLocal
</local>
<ejb-class>
org.javahispano.ejemplos.slsb.CalculadoraBean
</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
Descriptores Propietarios:JBoss
Jboss necesita de al menos la información de un descriptor propietario para hacer el deploy de un EJB. En este descriptor, el jboss.xml, es donde informamos al servidor del nombre que van a tener nuestros EJB en el JNDI.
Otras configuraciones que se pueden hacer en este descriptor son: referencias entre EJB, configuracion del EJB para un cluster de JBoss, seguridad, configuración de EJB proxys, etc.
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 3.2//EN"
"http://www.jboss.org/j2ee/dtd/jboss_3_2.dtd">
<jboss>
<enterprise-beans>
<session>
<ejb-name>Calculadora</ejb-name>
<jndi-name>ejb/ejemplos/Calculadora</jndi-name>
<local-jndi-name>ejb/ejemplos/CalculadoraLocal</local-jndi-name>
</session>
</enterprise-beans>
</jboss>
El cliente
Para probar el EJB se ha creado un cliente para el mismo, en forma de una simple Java Main class. El cliente primero debe obtener una referencia del JNDI. Esta es el objeto InitialContext que es el nodo padre de la estructura de directorios. El valor de las propiedades que se pasan al InitialContext son especificas de cada servidor de aplicaciones, se supone el servidor JBoss3.x instalado en la misma máquina y con la configuración por defecto.(Puerto RMI =1099)
Hashtable propiedades = new Hashtable();
propiedades.put("java.naming.factory.initial",
"org.jnp.interfaces.NamingContextFactory");
propiedades.put("java.naming.factory.url.pkgs",
"org.jboss.naming:org.jnp.interfaces");
propiedades.put("java.naming.provider.url",
"localhost");
long tiempoInicio = System.currentTimeMillis();
InitialContext ic = new InitialContext(propiedades);
Una vez echo esto, se obtiene del JNDI con la operacion lookup sobre el objeto InitialContext, el Home Interface a través del nombre fijado en el jboss.xml. Ya que la clase se va a ejecutar en una máquina virtual distinta, la debemos recuperar el Home Interface y no el Local Home Interface.
CalculadoraHome calculadoraHome =
(CalculadoraHome)ic.lookup("ejb/ejemplos/Calculadora");
Con el Home Interface podemos "crear" un EJB y retornar una referencia del mismo al cliente a través del Remote Interface
Calculadora calculadora = calculadoraHome.create();
Con la interfaz remota se puede llamar a los métodos de negocio, por ejemplo, la operación sumar.
int resultado = calculadora.sumar(7, 3);
System.out.println("Resultado de sumar 7+3 = " + resultado);
En el cliente se miden los tiempos de obtener el Contexto del JNDI, los interfaces del EJB y la operación sumar para que podais evaluar la "lentitud" de los EJB.
El ejemplo
Como se ha explicado el ejemplo cuenta con el EJB en la parte servidora y una clase Java como cliente. Para probarlo necesitamos:
- Tener instalado y arrancado JBoss en su version 3.x.
- Tener instalado y configurado Jakarta-ANT
- Configurar el script para nuestro sistema
- Ejecutar el script
- Por ultimo, ejecutar el target cliente del script
Instalar JBoss
El objetivo de este artículo no es explicar la instalación de JBoss. En cualquier caso, por la sencillez de la operación se va a explicar a grandes rasgos lo necesario para instalar JBoss 3.2.x.
- Descargar de la web www.jboss.org la ultima versión de la serie JBoss 3.x. Esta en formato zip y tar.gz, y disponiblo sin y con condigo fuente.
- Descomprimir el archivo
- Es necesario tener la varible de entorno JAVA_HOME. En windows, set JAVA_HOME=C:\j2sdk1.4.2 en consola o boton derecho en Mi PC-->Propiedades del sistema-->Pestaña Opciones Avanzadas y pulsar en Variables de Entorno. En UNIX, export JAVA_HOME=/usr/j2se.
- Para comprobar que JAVA_HOME esta bien ejecutar el programa java en consola
- Para arrancar JBoss, ir al directorio \bin y ejecutar el programa run. De esta forma se ejecuta JBoss con la configuración default.
Instalar Jakarta-ANT
Para instalar ANT,
- Descargar de la web http://ant.apache.org la ultima versión
- Descomprimir el archivo
- Poner la varible de entorno ANT_HOME al directorio donde habeis descomprimido ANT. Añadir a la variable de entorno PATH el directorio bin de ANT. En windows, set PATH=%PATH%;%ANT_HOME%\bin. En UNIX, export PATH=%PATH%:%ANT_HOME%/bin
- Para comprobar que ANT_HOME esta bien ejecutar el programa ant en consola
Si utilizais algun IDE para programar (Netbeans, Eclipse, JBuilde, IDEA, etc.), es bastante común que tenga un plugin de ANT, por lo que su instalación no es necesaria.
Ejecutar el script
El ejemplo cuenta con un script ANT. Es el archivo build.xml. Para ejecutar este script, solo hay que cambiar el valor de la propiedad jboss.dir al directorio donde este instalado JBoss.
<property name="jboss.dir" value="C:\jboss"/>
Los pasos a seguir son:
- Descargar el ejemplo de www.javahispano.org
- Descomprimir el archivo
- Cambiar la propiedad jboss.dir como se ha descrito anteriormente
- Si todavia no teneis JBoss arrancado, este es un buen momento ;-)
- Ir al directorio donde se encuentra el script y ejecutar "ant". Automaticamente lee el archivo build.xml y realiza el deploy del EJB entre otras cosas.
- Se deberian ver las siguientes trazas en la consola y ficheros del log del JBoss
19:44:52,639 INFO [MainDeployer] Starting deployment of package:
file:/C:/java/jboss3/server/pruebas/deploy/org.javahispano.ejempl
os.slsb.Calculadora-1.0.jar
19:44:54,232 INFO [EjbModule] Creating
19:44:54,252 INFO [EjbModule] Deploying Calculadora
19:44:54,292 INFO [StatelessSessionContainer] Creating
19:44:54,302 INFO [StatelessSessionInstancePool] Creating
19:44:54,302 INFO [StatelessSessionInstancePool] Created
19:44:54,302 INFO [StatelessSessionContainer] Created
19:44:54,302 INFO [EjbModule] Created
19:44:54,312 INFO [EjbModule] Starting
19:44:54,312 INFO [StatelessSessionContainer] Starting
19:44:54,492 INFO [StatelessSessionInstancePool] Starting
19:44:54,492 INFO [StatelessSessionInstancePool] Started
19:44:54,492 INFO [StatelessSessionContainer] Started
19:44:54,492 INFO [EjbModule] Started
19:44:54,492 INFO [EJBDeployer] Deployed: file:/C:/java/jboss3/ser
ver/pruebas/deploy/org.javahispano.ejemplos.slsb.Calculadora-1.0.jar
19:44:54,512 INFO [MainDeployer] Deployed package: file:/C:/java/jb
oss3/server/pruebas/deploy/org.javahispano.ejemplos.slsb.Calculadora
-1.0.jar
Una vez aparece "[MainDeployer] Deployed package" podemos decir que el EJB ha sido instalado
Ejecutar el cliente
Para Ejecutar el cliente simplemente hay que ejecutar uno de los target del script ANT, el de nombre ejecutar-cliente. Para ello simplemente ejecutamos en el directorio del script ant ejecutar-cliente
Conclusión
Este artículo muestra como hacer un EJB muy simple. Explica la arquitectura de la especificación junto a su código fuente para así enseñar no solo a hacer EJB sino a entederlos.
El próximo artículo se explicará como herramientas Open Source pueden ayudar a escribir EJB. Como ejemplo, se utilizará otra calculadora, esta vez con interfaz web.
Recursos
[1] JavaDocs EJB,
http://java.sun.com/products/ejb/javadoc-2_1-pfd2/javax/ejb/SessionBean.html
[2] JavaDoc EJBObject,
http://java.sun.com/products/ejb/javadoc-2_1-pfd2/javax/ejb/EJBObject.html
[3]
Código ejemplo calculadora SLSB
Acerca del autor
Enrique Rodriguez Lasterra
Ingeniero Informático por la Universidad de Deusto.Trabaja en la
empresa bilbaína NHT-Norwick.com desde hace ya mas de dos años
donde programa, como no, en Java.
Reader Comments