Enterprise Java Beans

Tecnologa Enterprise Java Beans

La

especificacin de Enterprise JavaBeans, define una arquitectura para el

desarrollo y estructuracin de aplicaciones de procesamiento de transacciones,

basados en objetos distribuidos, y componentes de software del lado del servidor.
Estos componentes, son llamados enterprise beans, son objetos distribuidos que
se encuentran en Enterprise JavaBeans Containers y proveen servicios remotos a
clientes distribuidos a travs de la red.
Especificaciones
La especificacin exige un modelo de programacin, constituido por convenciones
o protocolos y un conjunto de clases e interfaces sobre las cuales de apoya el EJB
API.
El modelo de programacin de EJB provee a los desarrolladores y proveedores
de beans,

un conjunto de contratos que definen un estndar comn para el

desarrollo. El principal logro de estos contratos es asegurar la portabilidad entre

distintos proveedores y as soportar un gran conjunto de funcionalidades.
El Contenedor de Java Beans
Enterprise Java Beans son componentes que se ejecutan en un ambiente
especial llamado EJB Container. El container almacena y maneja un enterprise
bean de la misma forma que un Servidor Web Java almacena un servlet, o un
browser HTML almacena un applet. Un enterprise bean no puede funcionar fuera
de un EJB container. El EJB Container maneja cada aspecto de un enterprise
bean

en tiempo de ejecucin incluyendo acceso remoto al bean, seguridad,

persistencia, transacciones, concurrencia y acceso a los recursos.

El container protege al EJB del acceso directo desde las aplicaciones

clientes. Cuando una aplicacin cliente invoca un mtodo remoto en un EJB, el
container primero intercepta

la invocacin para asegurar la persistencia,

transacciones y seguridad que son aplicadas a apropiadamente a cada una de las

operaciones que el cliente desempea en el bean. El container maneja estos
aspectos automticamente

para el bean, as el desarrollador no tiene que

preocuparse por la implementacin de los mismos.

Los containers pueden manejar numerosos beans en la misma forma que
un servidor web puede manejar varios servlets. Para reducir el consumo de
memoria, procesamiento y los recursos del container, este maneja los bean por
ciclos de vida. Cuando un bean no esta en uso, el container lo coloca en una pila
para ser rehusado por otro cliente, o posiblemente lo saca de memoria y solo lo
trae de nuevo cuando es necesario. Como las aplicaciones clientes no tienen
acceso directo a los bean, estas estn completamente ajenas a las actividades de
manejos de recursos. Un bean que no esta en uso, por ejemplo, es sacado de
memoria en el servidor, mientras que su referencia remota permanece intacta en
el cliente. Cuando el cliente invoca un mtodo sobre su referencia remota, el
container reencarna el bean para atender la peticin. El cliente, es ignorante de
todo el proceso. La siguiente figura, resume el comportamiento del EJB Container

Enterprise Beans

Un EJB esta compuesto de 4 partes (con la excepcin de "Messaging

EJB's") las cuales son:
o

"Enterprise Bean Class"

"Home Interface"

"Remote Interface"

"Deployment Descriptor"

Enterprise Bean Class

Esta clase es el componente medular de un EJB, en esta clase se
encuentran definidas todas los funciones utilizadas por un EJB, ya sean
procedimientos rutinarios (operaciones matemticas) o con lgica hacia bases de
datos (con JDBC). En esta clase reside todo el cdigo fuente o funcional que
realiza operaciones en Java, desde la activacin del EJB hasta su destruccin
incluyendo las funciones de negocios para el que ste fue diseado.
Home Interface
Esta interfase solo define un "esqueleto" para funciones utilizadas en el
Enterprise Bean Class. Los mtodos que deben ser declarados en un Home
Interface son aquellos que representan el ciclo de vida del componente (creacinactivacin) algunas son: create, destroy, find.
Cuando un cliente desea interactuar con un EJB ste no se comunica
directamente con el Enterprise Bean Class, sino con el Home Interface del EJB en
cuestin.
Remote Interface

Esta interfase contiene las declaraciones para mtodos de negocios

definidos en el Enterprise Bean Class.
Deployment Descriptor
Un Deployment Descriptor es un archivo en XML que cumple varias
funciones.
La primera es parametrizar el cdigo Java del "Enterprise Bean Class", esto
es, definir parmetros que varan dependiendo del ambiente; por lo general todo
EJB contiene algn tipo de lgica que depender del ambiente de ejecucin como:
nombres de bases de datos, servidores de paginas, usuarios privilegiados, etc... y
es a travs del Deployment Descriptor que estos parmetros pueden ser
modificados sin la necesidad de entrar a todo el cdigo fuente, inclusive para
aquellos EJB adquiridos de 3eros los cuales no distribuyen su cdigo fuente es la
nica manera de personalizar este tipo de parmetros.
Adems de lo anterior, el Deployment Descriptor tambin indica al EJB
Container: el tipo de EJB ("Session, Entity, Messaging"), el esquema de seguridad
que posee el EJB, en caso de ser un "Container Managed Entity EJB" las
funciones para las que se generar lgica, y otras funcionalidades ms.

Tipos de Beans
Beans Entidad
Un bean entidad representa un objeto de negocios en un mecanismo de
almacenamiento persistente.

El mecanismo de almacenamiento persistente,

generalmente, se refiere a una base de datos relacional. Tpicamente, cada bean

entidad implica una tabla en una base de datos relacional, y cada instancia de un
bean corresponde a una fila de la misma.

Existen dos tipos de bean entidad:

oBMP: Bean-Managed Persistence
oCMP: Container-Managed Persistence
BMP
Este tipo de bean requiere que la lgica necesaria para accesar a la base de
datos sea definida manualmente, por lo general esta lgica se encuentra en JDBC
y define: como y cuando debe ser accesada|actualizada|guardada la informacin
entre el EJB y la base de datos
CMP
El temimo container-managed persistence significa que el EJB Container
maneja todos los accesos a la base de datos que requiera el bean entidad. El
cdigo del bean no contiene ningn acceso a la base de datos. Como resultado el
cdigo del bean

es ajeno a una base de datos especifica, debido a

esta

flexibilidad, aun si se necesita re-estructurar el mismo bean entidad en un servidor

que use una base de datos diferente, no se necesitara modificar o recompilar el
cdigo del bean.

Aparentemente un BMP no tiene mucha razn de ser, sin embargo, hay

casos donde es empleada lgica de acceso sumamente compleja la cual no es
posible generar a travs del EJB Container, es por esto que los BMP
permanecern en existencia a pesar de las facilidades ofrecidas por los CMP.

Beans Sesin
Los beans sesin representan un conjunto de procesos o tareas, los cuales
son desempeadas para la aplicacin cliente. No representan datos como los
bean entidad. Los beans sesin, pueden usar otros beans para completar las
tareas o acceder directamente a la base de datos.
Como su nombre sugiere, un bean sesin es similar a una sesin
interactive. Un bean sesin, no es compartido solo tiene un solo cliente, de la
misma forma que una sesin interactiva solo tiene un solo usuario. Una bean
sesin no es persistente. Cuando un cliente termina, el bean sesin finaliza y no
esta mas asociado con el cliente.

Existen dos tipos de beans sesin:

Stateless Session Beans
Este tipo de EJB como su nombre lo indica no mantiene estado("Stateless") en el
"EJB Container", estos EJB's son utilizados para realizar tareas rutinarias que no
requieren identificar o rastrear al cliente, algunos EJB's de este tipo son:
operaciones matemticas complejas, bsquedas generales, etc.
Stateful Session Beans
A diferencia de "Stateless (Session) EJB's" este tipo de EJB's permiten
mantener la sesin del cliente en el "EJB Container", de esta manera el cliente
puede trabajar con cierto juego de datos especifico administrado por el "EJB
Container", la aplicacin ideal para este tipo de EJB es un componente de compra
("Shopping Cart") el cual puede identificar artculos e informacin personal del
cliente a travs de un lapso de tiempo extenso ("Session").

Message-Driven

A muy grandes rasgos un sistema "Messaging" ofrece el funcionamiento de

intermediario para recibir y publicar mensajes, una de las ventajas de un
"Messaging System" es que opera en forma asncrona o non-bloqueante. Los
mensajes pueden ser enviados por cualquier aplicacin cliente, otro enterprise
bean, un componente web, u otra aplicacin basada en JMS (Java Message
Servicie)
Asncrono o no-bloqueante implica que un cliente (emisor) pueda publicar
un mensaje sin la necesidad que el receptor se encuentre activo, esencialmente el
"Messaging System" funciona como un agente ("broker") para facilitar el
intercambio de mensajes. Las aplicaciones clsicas para un "Messaging System"
son aquellas utilizadas por sistemas financieros, en donde la perdida de mensajes
es intolerable o ampliamente distribuida. Cuando ocurre una transaccin financiera
generalmente esta atraviesa por un "Messaging System", lo cual garantiza que
aunque el consumidor final (receptor) este desactivado el cliente(emisor) pueda
continuar con sus acciones sin la necesidad de esperar confirmacin, a esto ltimo
se le llama "non-blocking".
Otra aplicacin financiera que utiliza "messaging" son los denominados
"tickers financieros" donde constantemente aparecen los valores de acciones, en
este tipo de sistema existe un cliente(emisor) que publica el mensaje ("valor de
acciones") al "Messaging system", y cientos o miles de consumidores (receptores)
"tickers financieros" toman este mensaje del "messaging system" para ser
desplegado en pantalla.
Cuando usar beans entidad:

El bean representa una entidad de negocios no un procedimiento. Por ejemplo,

CreditCardEJB puede ser un bean entidad, pero CreditCardVerifierEJB debe ser
un bean ser un bean sesin.
El estado del bean debe ser persistente.
Cuando usar beans sesin:
En general, se deben usar beans sesin cuando:
Solo un cliente tiene acceso a la instancia del bean.
El estado del bean es no persistente, solo existe por un corto periodo de tiempo.
Stateful beans son apropiados cuando
El estado del bean representa la interaccin entre el bean y un cliente en
especifico.
El bean necesita mantener informacin del cliente a lo largo de las invocaciones
a los mtodos.
El bean es un mediador entre el cliente y otros componentes de la aplicacin.
El bean maneja el flujo de trabajo de muchos enterprise beans.
Es recomendable usar beans sesin stateless cuando:
El estado del bean no tiene datos de un cliente especifico
El bean desempea tareas genricas para todos los clientes.
El bean trae de la base de datos un conjunto de datos solo-lectura que son
usados con frecuencia por sus clientes, por ejemplo filas de la tabla que
representan los productos en rebajas este mes.

Creacin de un Enterprise JavaBean en el Servidor:

Una aplicacin cliente contacta al servidor y le pide que genere un EJB para
que procese datos en su nombre. El servidor responde creando un Objeto en l
(la instancia del componente del EJB), y devuelve un objeto proxy (el Objeto EJB)
cuya interfaz es la misma que la del componente del EJB y su implementacin
invoca mtodos remotos a nombre del cliente. El cliente luego utiliza el objeto
como si fuese un objeto local, sin saber que realmente el objeto remoto es el que
esta haciendo todo el trabajo.
La aplicacin cliente al que realmente contacta es al conteiner del servidor y
le pide que genere un objeto en particular, el conteiner responde con el Objeto
EJB que puede ser utilizado para manipular el nuevo componente EJB recin
generado. Como ya se explico anteriormente el ciclo de vida de los beans del
servidor es responsabilidad del conteiner. Cada clase del componente del EJB
tiene un home interface, que define los mtodos para crear, inicializar, destruir y
(en caso de los entity beans) buscar instancias de EJB en el servidor. Los home
interface define uno a mas mtodos create(), que devuelven valores de remote
interface del EJB. Como se explico anteriormente el remoto interface consiste de
los mtodos de negocios que provee el EJB.
Cuando un cliente quiere crear un bean en el servidor, este utiliza el JNDI
(java naming and director interface) para localizar el home interface de la clase de
bean que l desea. El JNDI es una extensin estndar del core de java que provee
un servicio global para cualquier ambiente de java, permitiendo que aplicaciones
en java localicen y utilicen recursos por nombre, obteniendo informacin acerca de
esos recursos, entre otras cosas.

Una vez que el cliente tiene el home interface de la clase del EJB que
quiere generar, se llama a uno de los mtodos create() en el home interface para
crear el objeto en el servidor. El objeto del home interface del lado del cliente hace
una llamada remota al conteiner del EJB, quien luego genera el componente EJB
y devuelve el objeto EJB al cliente. Luego el cliente puede llamar los mtodos del
objeto EJB, estas llamadas son enviadas al conteiner. El conteiner difiere la
implementacin de los mtodos de las llamadas invocadas a los componentes del
EJB.
Ms de los EJB Container
Como se menciono anteriormente, los conteiner aslan a los Enterprise
beans de acceso directo por parte de las aplicaciones de los clientes. Cuando una
aplicacin invoca un mtodo remoto en un Enterprise bean, l

intercepta la

invocacin para asegurar la persistencia, transaccin, y la seguridad es aplicada

adecuadamente a cada operacin que el cliente realice en el bean. De esta forma
el conteiner maneja automticamente por los beans la seguridad, transacciones y
la persistencia, as los desarrolladores de beans no se tienen que preocupar por
escribir este tipo de lgica en los cdigos de los beans. Los desarrolladores de
Enterprise beans se pueden enfocar en encapsular las reglas del negocios,
mientras los conteiner se encargan de todo lo dems. Los conteiner manejan
varios bean simultneamente de la misma manera como los servidores web de
java manejan varios servlets. Para reducir el consumo y procesamiento de
memoria, los conteiner agrupan los recursos y manejan el ciclo de vida de todos
los beans muy cuidadosamente.

Cuando un bean no esta siendo utilizado, el

conteiner lo pondr en un lista para que pueda ser reutilizado por otro cliente, o
posiblemente lo expulse de la memoria y solo lo trae de vuelta cuando sea
necesario. Debido a que las aplicaciones de los clientes no tienen acceso directo a
los bean, las aplicaciones de los clientes estn completamente desprevenidas de
las actividades de direccin que realiza los conteiner. Por ejemplo si un bean no
esta siendo utilizado este puede ser expulsado de la memoria del servidor,
mientras que su referencia remota en el cliente quedan intactas. Cuado el cliente

invoca un mtodo en la referencia remota, el conteiner simplemente reencarna al

bean para servir la solicitud. La aplicacin del cliente desconoce totalmente todo
ese proceso.
Los Enterprise beans dependen de los conteiner para todas las cosas que
necesiten. Si un Enterprise bean necesita acceder a una conexin JDBC o a otro
Enterprise bean, lo hace a travs del conteiner, si un Enterprise bean necesita
acceder la identidad de su llamador, obtener una referencia a s mismo o acceder
a sus propiedades, lo hace a travs del conteiner. Los Enterprise bean interactan
con l por medio de alguno de los siguientes tres mecanismos: metdos callbacks,
el EJBContext interface, o el JNDI.
Callbacks: Todos los bean implementan un subtipo de interfaz EnterpriseBean
que define varios mtodos, llamados los mtodos callback. Cada mtodo callback
avisa al bean sobre diferentes eventos en su ciclo de vida y el conteiner invocara
estos mtodos para notificar al bean cuando esta a punto de activar el bean,
persistir su estado a la bases de datos, terminar una transaccin, mover el bean
de la memoria etc. Los mtodos callback permiten que los beans tengan chance
de realizar algunas actividades inmediatamente antes de un determinado evento
ocurra.
EJBContext: Cada bean obtiene un objeto EJBContext, el cual es una referencia
directa al conteiner. La interfaz EJBContext provee de mtodos para que el bean
pueda solicitar informacin acerca de su ambiente como la identidad de su cliente,
el estado de su transaccin, o para obtener una referencia remota a l mismo.
JNDI: Es una extensin estndar de la plataforma java para acceder a un naming
system como LDAP, NetWare, sistema de archivos, etc. Cada bean tiene acceso a
un

sistema

de

nombramiento

especial

llamado

Environment

Naming

Context(ENC). El ENC es manejado por el conteiner y accedido por los bean

usando JNDI. El JNDI ENC permite a los bean acceder a recursos como

conexiones de JDBC, otros Enterprise beans, y propiedades especificas de esos

beans.
Enterprise beans como objetos distribuidos.
Las interfases remotas y home son tipos de interfases remotas de RMI de
Java. La interfaz java.rmi.Remote es utilizada por objetos remotos para
representar los bean en una direccin de espacio diferente ya sea en un
procesador o maquina diferente. Un Enterprise bean es un objeto distribuido, con
lo que quiere decir que la clase bean es inicializada y vive en el conteiner y puede
ser accedida por aplicaciones que vivan en otro espacio de direccin.
Para hacer que un objeto que esta instanciado en una direccin de espacio
este disponible en otra requiere de un pequeo truco que envuelven network
Socket. Para hacer que el truco funciones se envuelve la instancia en un objeto
especial llamado esqueleto el cual contiene una conexin network con otro objeto
especial llamado stub.

Los stub implementan la interfaz remota por lo que

aparentan ser un objeto de negocios, pero los stub no contienes lgica de

negocios, contiene un conexin network socket al esqueleto. Cada vez que se
invoca un mtodo de negocio en la interfaz remota del stub, el stub enva un
mensaje de red al esqueleto informndole sobre que mtodo esta siendo
invocado. Cuando el esqueleto recibe este mensaje identifica el mtodo invocado
y sus argumentos, y luego invoca el correspondiente mtodo en la instancia
actual. La instancia ejecuta el mtodo y devuelve su resultado al esqueleto, el cual
lo enva de regreso al stub.
El stub devuelve el resultado a la aplicacin que invoco el mtodo de
interfaz remota. Desde la perspectiva de la aplicacin que invoca el mtodo
pareciera que el stub es el que hace todo el trabajo. Cuando en realidad el stub es
como un objeto de red mudo que enva lo solicitado a travs d la red hacia el
esqueleto, el cual enva el mensaje a la instancia que es la que realmente hace

todo el trabajo, los stubs y los esqueletos solo pasan la identidad del mtodo y sus
argumentos a travs de la red.
En EJB los esqueletos son para las interfaces remotas y home estn
implementados por el container y no por las clase bean. Esto es para asegurara
que todo mtodo invocado por las aplicaciones clientes son primeramente
manejados por el container y luego son delegados a la respectiva instancia del
bean.
Los protocolos de objetos distribuidos definen el formato de los mensajes
de red enviados entre los espacios de direcciones. Los protocolos de objetos
distribuidos se pueden poner bastante complicados, pero afortunadamente uno no
ve nada de esto por que es manejado automticamente. La mayora de los
servidores de EJB soportan o el Java Remote Meted Protocol (JRMP) o el
protocolo de CORBA Internet Inter.-ORB Protocol (IIOP). Los programadores de
los bean y de las aplicaciones solo ven las clases bean y su interfaz remota, los
detalles de la comunicacin por la red es escondida.

Con respeto al API del EJB, los programadores no les importa si el servidor
EJB utiliza JRMP o IIAP (el API es el mismo). Las especificaciones del EJB
requieren que se utilicen una versin especializada del API del RMI Java, cuando
se esta trabajando con un bean remotamente. RMI de Java es un API para
acceder objetos distribuidos.

Desventajas de EJB ("Enterprise Java Beans")

Tiempo de Desarrollo
El desarrollar un Sistema con EJB's es sumamente complejo, aunque para
ciertas empresas puede presentar una solucin ideal, debido a la
complejidad-tiempo de ( traducindose en costo) para muchas corporaciones
EJB's resultan una solucin sobrada , denominada en Ingles: "overkill".
Conocimiento exhausto de Java
EJB's es uno de los principales componentes de J2EE por esta razn
tambin depende fuertemente de otras partes de J2EE: Como RMI, JNDI y
JDBC.

EJEMPLO
A continuacin un ejemplo de como una customer bean puede ser accedido desde
una aplicacin de cliente. En este ejemplo la interfaz home es del tipo
CustomerHome la interfaz remota es del tipo Customer.
CustomerHomehome=//...obtainareferencethat
//implementsthehomeinterface.
//Usethehomeinterfacetocreatea
//newinstanceoftheCustomerbean.
Customercustomer=home.create(customerID);
//usingabusinessmethodontheCustomer.
customer.setName(someName);

La interfaz remota define los mtodos de negocios del bean, los mtodos que son
especficos de los conceptos de negocios al cual representa.

A continuacin esta una definicin de una interfaz remota para el bean Customer.
importjavax.ejb.EJBObject;
importjava.rmi.RemoteException;
publicinterfaceCustomerextendsEJBObject{
publicNamegetName()
throwsRemoteException;
publicvoidsetName(Namename)
throwsRemoteException;
publicAddressgetAddress()
throwsRemoteException;
publicvoidsetAddress(Addressaddress)
throwsRemoteException;
}

la interfaz remota define mtodos para acceder y modificar informacin acerca de

los conceptos de negocios. Esto es tpico de un tipo de bean llamado entity bean,
que representa un objeto de negocios persistente. Objetos de negocios que son
almacenados en las bases de datos. Los entity beans representan la informacin
de negocios en la base de datos y aaden comportamientos especficos a esa
informacin.
mtodos de negocios:
Los mtodos de negocios tambin pueden representar tareas que el bean puede
realizar. A pesar que los entity beans puede tener a menudo mtodos orientados a
tareas, este tipo de mtodos son tpicos de los sesin bean. Session bean no
representan informacin como los entity beans. Ellos representan procesamiento
de negocios o agentes que realizan servicios, como hacer una reservacion a un
hotel. A continuacin esta una definicin de la interfaz remota para el bean
HotelClerk, el cual es un bean del tipo session.
importjavax.ejb.EJBObject;
importjava.rmi.RemoteException;

publicinterfaceHotelClerk
extendsEJBObject{

publicvoidreserveRoom(Customercust,
RoomInfori,Datefrom,Dateto)
throwsRemoteException;
publicRoomInfoavailableRooms(
Locationloc,Datefrom,Dateto)
throwsRemoteException;
}

Los mtodos de negocios definidos en la interfaz remota HotelClerk representan

procesamiento en vez de simples mtodos de acceso a informacin. El bean
HotelClerk actua como un agente en el sentido que realiza tareas en nombre del
usuario, pero no es el mismo persistente en la base de datos. No necesitamos
informacin acerca del hotelclerk, se necesita que el hotel clerk realice tareas para
nosotros. Este es el comportamiento tpico de los session bean.
Mientras se va construyendo una aplicacin de EJB se van a ir creando muchos
beans, cada uno simbolizando diferentes conceptos de negocios. Cada concepto
de negocio se manifestara como un entity bean o como un session bean. Uno
decidir que tipo de bean se convertir un concepto de negocios basndose en
como se desee utilizar.
Entity bean:
Para cada interfaz remota existe una clase de implementacin. Un objeto de
negocios que realmente implementa los mtodos de negocios definidos en la
interfaz remota. Esta es como ya hemos dicho la clase bean. A continuacin una
definicin parcial del customer bean class.
importjavax.ejb.EntityBean;
publicclassCustomerBean
implementsEntityBean{

AddressmyAddress;
NamemyName;
CreditCardmyCreditCard;
publicNamegetName(){
returnmyName;
}
publicvoidsetName(Namename){
myName=name;
}
publicAddressgetAddress(){
returnmyAddress;
}
publicvoidsetAddress(Addressaddress){
myAddress=address;
}
...}

CustmerBean es una clase de implementacin, ella contiene informacin y

provee de mtodos de acceso y otros mtodos de negocio. Como los entity bean,
el CustomerBean provee un objeto para ver la infamacin del customer. En vez de
escribir accesos lgicos a la bases de datos en una aplicacin , la aplicacin
puede simplemente utilizar la interfaz remota del CustomerBean para acceder a la
informacin del customer.
Session bean:
El HotelClerk es un session bean , el cual es muy similar en muchos aspectos a un
entity bean. Session bean representa un conjunto de procesamiento de tareas, las
cuales son ejecutadas en nombre de la aplicacin del cliente. Los bean de session
pueden utilizar otros beans para que realicen tareas o para que accedan
directamente a la base de datos. A continuacin un ejemplo que muestra los dos
casos:
importjavax.ejb.SessionBean;
publicclassHotelClerkBean
implementsSessionBean{

publicvoidreserveRoom(
Customercust,RoomInfori,
Datefrom,Dateto){
CreditCardcard=cust.getCreditCard();
RoomHomeroomHome=
//...gethomereference
Roomroom=
roomHome.findByPrimaryKey(ri.getID());
doubleamount=room.getPrice(from,to);
CreditServiceHomecreditHome=
//...gethomereference
CreditServicecreditAgent=
creditHome.create();
creditAgent.verify(card,amount);
ReservationHomeresHome=
//...gethomereference
Reservationreservation=
resHome.create(cust,room,from,to);
}

publicRoomInfo[]availableRooms(
Locationloc,Datefrom,
Dateto){
//MakeanSQLcalltofind
//availablerooms
Connectioncon=//...getdatabase
//connection
Statementstmt=con.createStatement();
ResultSetresults=
stmt.executeQuery("SELECT...");
...
returnroomInfoArray;
}
}

ciclo de vida de los mtodos:

adicionalmente a los remote interface todos los bean tienen un home interface que
provee los mtodos del ciclo de vida para crear, destruir y localizar beans. Estos
comportamiento del ciclo de vida estn separados de la interfaz remota por que
ellos representan comportamiento que no es especifico de una nica instancia de
bean. A continuacin una definicin del home interface de l customer bean.
importjavax.ejb.EJBHome;

importjavax.ejb.CreateException;
importjavax.ejb.FinderException;
importjava.rmi.RemoteException;
publicinterfaceCustomerHome
extendsEJBHome{

publicCustomercreate(Integer
customerNumber)
throwsRemoteException,
CreateException;

publicCustomerfindByPrimaryKey(Integer
customerNumber)
throwsRemoteException,
FinderException;
publicEnumerationfindByZipCode(intzipCode)
throwsRemoteException,
FinderException;
}

El mtodo create() es utilizado para crear una nueva entidad. Esto resultara en un
nuevo registro en la basa de datos. Pueden haber varios mtodos create() en
home. Se diferencia en el tipo y nmero de argumentos, pero lo que devuelven
debe ser del tipo remote interface. En este caso el mtodo create devuelve una
instancia de Customer. mtodos utilizados para ubicar determinadas instancia de
Customer bean.
Devuelta a remote y home interface:
Estas dos interfaces es utilizada por las aplicaciones para acceder a los EB. El
home interface permite que la aplicacin cree y localice el bean, mientras que el
remote interface permite a la aplicacin invocar los mtodos de negocios de los
beans
CustomerHomehome=
//Getareferencetothe
//CustomerHomeobject
Customercustomer=
home.create(newInteger(33));

Namename=newName("Richard",
"Wayne","MonsonHaefel");
customer.setName(name);
EnumerationenumOfCustomers=
home.findByZip(55410);
Customercustomer2=
home.findByPrimaryKey(
newInteger(33));
Namename2=customer2.getName();
//outputis"RichardWayne
//MonsonHaefel"
System.out.println(name);

Referencias:
Enterprise JavaBeansTM(EJB) Technology Fundamentals
http://developer.java.sun.com/developer/onlineTraining/EJBIntro/

Enterprise JavaBeansTM Tutorial:

Building Your First Stateless Session Bean
http://developer.java.sun.com/developer/onlineTraining/Beans/EJBTutorial/index.html
White Papers
http://java.sun.com/j2ee/white/index.html