Introduccrión a Enterprise Java Beans

Java 2 Enterprise Edition

Sun define J2EE como "La plataforma para Soluciones de la Empresa".
J2EE simplifica las aplicaciones basándose en componentes estandarizados,
modulares, pero proporcionando un juego completo de servicios y gestionando
automáticamente detalles de comportamiento de las aplicaciones.

J2EE potencia ideas de la plataforma estándar, J2SE, como por ejemplo
"Write One, Run Anyware", la conectividad a base de datos a través
del API JDBC, interacción con CORBA y el modelo de seguridad JAAS y añade,
entre otros a los EJB, los Java Servlet y las Java Server Pages (JSP) y como
no la tecnología XML, aunque en la ultima versión de la plataforma
estándar viene integrada con el JAXP, Java API for XML Processing. Tampoco
hay que olvidar otras tecnologías como RMI y RMI-IIOP, JNDI, JTA, JMS,
JCA, JAAS, JWSDK, etc, etc, etc.

Enterprise Java Beans

Enterprise Java Beans es una arquitectura que define la forma de construir componentes
distribuidos del lado del servidor. Esta tecnología garantiza que los
componentes programados sean escalables, eficaces y seguros a pesar de lo sencillo
de su desarrollo, pero sin duda, aúnan una gran cantidad de conceptos
que conviene aclarar antes de proseguir. Estas son las principales características
de los EJB:

• Los EJB son componentes distribuidos, esto quiere decir que podemos hablar
  de componentes que se ejecutan en diferentes servidores, contra diferentes
  bases de datos, o no, es una decisión del analista-desarrollador.



• Los EJB se ejecutan dentro de un servidor de aplicaciones, estos servidores
  deben cumplir el estándar fijado por SUN Microsystem INC., y se encargan
  de gestionar recursos como red, los pool de conexiones, o la gestión
  de la seguridad. El desarrollador construye los EJB y los servidores de aplicaciones
  los gestionan.


• Los EJB favorecen la programación modular, la idea de la programación
  en base a componentes es el sueño de muchos y los EJB lo hacen posible
  de una manera sencilla. Puedes programar tu componente o puedes comprarlo
  a un tercero, pero siempre existirá división e independencia
  entre los diferentes componentes de un sistema. Dentro de un sistema se hace
  posible añadir o quitar un componente sin que el resto note la diferencia.


• La especificación que define los EJB es pública y en ella
  trabajan varias empresas. Cualquiera puede bajarse de Internet ese estándar
  y programar su propio servidor de aplicaciones. Si ese servidor implementa
  correctamente las interfaces públicas, y cumple la especificación
  en el se podrá ejecutar correctamente un EJB.


• EJB son Java. Para programar componentes se necesita una clara separación
  entre interfaces e implementación y Java lo soporta. Java es estable,
  seguro y multi-hilo, rara vez nos encontramos ante un bloqueo y tiene una
  de las APIs más ricas en contenido. Java es multiplataforma, esto permite
  que nuestros componentes se reutilicen en diferentes proyectos independientemente
  de la plataforma en la que vayan a ejecutarse.


• Los EJB solucionan los problemas de la vida diaria, pueden comunicarse entre
  ellos y resolver la lógica de negocio, pueden acceder a cualquier base
  de datos que tenga implementado un driver JDBC, o acceder a terceros sistemas
  a través de una interfaz SOAP o un servicio web.

La Arquitectura EJB

Componentes Distribuidos

Los EJB son componentes software que se ejecutan en la parte servidora de una
aplicación y pueden ser ejecutados en un entorno multi-capa distribuido.
Si bien podríamos definir componente como pieza de software accesible
a través de un interfaz publico, en el caso de los EJB, tanto el software
como esta interfaz (en realidad dos) deben cumplir el estándar e implementar
obligatoriamente ciertos métodos que dicha especificación define,
de esta forma los contenedores de EJB pueden gestionar el ciclo de vida de forma
uniforme siendo independiente el contenedor que lleve a cabo dicha tarea.

Los EJB son componentes que pueden estar físicamente alejados del cliente
por ello se dice que su interfaz publica es remota, Remote Interface. La especificación
EJB hace uso de RMI/IIOP para ofrecer esta característica. En RMI/IIOP
todo objeto remoto dispone de un interfaz accesible a los clientes, el cliente
puede hacer uso de esta interfaz a través del "stub" que es
un proxy enviado al cliente.

Cuando el cliente invoca al"stub" este se comunica con el "skeleton",
que es le proxy situado en el lado del servidor. Una vez recibido el mensaje
por el "skeleton" este es el encargado de comunicárselo al
objeto distribuido, el cual resolverá la operación y dará
la respuesta al cliente a través del "skeleton" primero y el
"stub" después.

Tanto el "stub" como el "skeleton" son transparentes para
el cliente y este siempre tiene la sensación de estar invocando al objeto
distribuido directamente.

La pega esta en que este tipo de operaciones es bastante pesada, requiere abrir
sockets, transferir objetos a través de la red y transformar estos objetos
en datos binarios según el protocolo (en este caso IIOP)

Middleware Implícito o Declarativo

La verdadera clave de los componentes distribuidos modernos es que su middleware
es implícito, es decir, el código de nuestro software no llama
directamente a este software integrado en la parte servidora, sino que define
en el descriptor de cada componente, se como queremos que sea el contexto en
el que se va a ejecutar.

Por ejemplo, un EJB no tiene la necesidad de llamar de forma explícita,
en el código, al API de transacciones para comenzar una transacción,
sino que podemos definir en un fichero distinto, como queremos que se comporte
el EJB.

Para ello aparte de dicho fichero donde se define el comportamiento del EJB,
se necesita uno que capture la llamada a los componentes distribuidos y configure
la forma en la que estos van a trabajar. En el caso de los EJB el EJB Object.


El EJB Object es generado por el propio contenedor y es el encargado de interactuar
con el contenedor para ofrecer sus servicios. Entre otros ofrece la gestión
de transacciones distribuidas, seguridad, gestión del ciclo de vida,
persistencia, etc.

Las ventajas, componentes más sencillos, el código se centra
en resolver la lógica no en la forma de hacerlo. Además se puede
cambiar el comportamiento de los EJB sin tocar su código, sólo
modificando el fichero que especifica como debe funcionar, el descriptor.

Transparencia de situación física

La especificación dice que puede variar el lugar donde se encuentran
los EJB, pero de alguna forma se necesita saber como podemos acceder a ellos,
esta es la labor del Home Object. El Home Object es el encargado de crear y
destruir los EJB Object. Es un objeto generado por el contenedor, de tipo "Factory",
que implementa el segundo de los interfaces públicos de un EJB, el Home
Interface. De esta forma el contenedor conoce cual es el tipo de EJB, que parámetros
debe pasar al EJB Object para crear un nuevo componente o que tipo de búsquedas
a definido un usuario para obtener la referencia a varios componentes.

Es importante señalar que existe un y sólo un EJBHome implementando
su correspondiente Home Interface para cada tipo de EJB en cada contenedor.
Esto hace posible cachear la referencia en algunos casos.

Interfaces Locales

En la especificación EJB 1.1 no existía este concepto pero muchos
servidores de aplicaciones empezaron a implementar mejoras para llamadas dentro
de una misma maquina virtual, de esta forma se eliminaba la necesidad de traducir
los datos a RMI para hacer una llamada no remota. Las personas que llevan a
cabo la especificación se dieron cuenta de esta "necesidad"
y crearon los interfaces locales en la versión 2.0, que sólo permiten
recibir llamadas de clientes de la misma maquina virtual. Estas llamadas son
mucho más rápidas y además los parámetros son pasados
por referencia no por valor, con lo que desminuye el consumo de memoria.

Tipos de Componentes

Actualmente el estándar EJB define tres tipos de EJB:

Session Beans (SB)

Los EJB de sesión se encargan de resolver la lógica de negocio
de la aplicación. Se puede decir que cada método contenido en
un SB resuelve un caso de uso de la aplicación, ejemplos pueden ser Control
de Usuarios, Gestor de Precios o Control de Procesos.

Dentro de la especificación podemos encontrar dos tipos de Sessions
Beans, State Less (SLSB) y State Full (SFSB).

State Less Session Beans

Los SLSB son componentes sin estado, es decir, no guardan ninguna relación
entre diferentes llamadas de un mismo cliente. Es mas, entre dos llamadas a
un mismo tipo de SLSB es posible que el contenedor direccione al cliente a diferentes
instancias del componente. Otro dato esclarecedor de cómo se comportan
este tipo de componentes es su relación con el número de usuarios.
Para N usuarios hay M instancias siendo M < N en la mayoría de los
casos. El valor máximo y mínimo de M es configurable en la mayoría
de los servidores. Con estos dos valores se define el tamaño del "pool".

Los pools de objetos han sido utilizados desde los inicios de Java. Se trata
de definir un espacio en memoria para varios objetos, de tal forma que en vez
de tener que instanciar un objeto cada vez, podemos reutilizar las instancias
existentes en el pool. Esto conlleva un consumo de memoria pero ofrece una mayor
velocidad. Además hace trabajar menos al recolector de basura, con lo
que la mejora de resultados es bastante notable.

Ese es el objetivo de los pools de EJB que utilizan los contenedores, reutilizar
las instancias de los EJB en memoria.

El contenedor garantiza que a una instancia de un EJB sólo puede acceder
un hilo, con lo cual nunca dentro de un EJB tendremos un problema de concurrencia,
el contenedor lo soluciona por nosotros.

State Full Session Beans

Los SFSB son lo contrario a los SLSB, mantienen el estado, es decir, tienen
una conversación "uno a uno" con cada cliente que los invoca.
Para mantener esta conversación es necesario hacer uso del objeto Handle.

El objeto Handle es una referencia serializable a un objeto EJB. Guardando
esta referencia se puede acceder posteriormente al EJB con el que el cliente
había establecido una relación.

Con los SFSB cada cliente tiene asociado un objeto EJB durante una conversación.
En caso de que esta referencia se pierda, se puede recuperar gracias al Objeto
Handle. Por eso es el cliente quien se tiene que encargar de preservar la instancia
de estos objetos si quiere volver a llamar a "su" SFSB.

Para muchos, este tipo de EJB es tachado como verdadera "maquina pesada"
y se desaconseja su uso en la mayoría de los casos. Otros mantienen su
utilidad por la posibilidad de mantener una sesión distribuida entre
varios servidores. En cualquiera de los casos se debe evitar la pasivación
de los mismos.

La pasivación es el proceso de serialización a disco de aquellas
instancias menos recientemente usadas (LRU, aunque es posible especificar otro
política de liberación dependiendo del Servidor de Aplicaciones)
cuando el número de instancias requeridas por los clientes es mayor de
las que puede soportar el pool de SFSB. Este proceso se puede dar, bien porque
se acaba la memoria o porque se ha llegado al límite de instancias máximas
configurado en el descriptor.

Al proceso contrario se le llama activación, y se produce cuando un
cliente llama a un método de su SFSB asociado y este se encuentra pasivado.

Si se prevé que con asiduidad van a ocurrir estos procesos es conveniente
intentar buscar otra alternativa, como por ejemplo manteniendo la sesión
en el servidor de Servlets-JSP.

Entity Beans

Los EJB de entidad están directamente relacionados con los datos de
la aplicación, son objetos que mantienen en memoria los datos que maneja
la aplicación, ejemplos, Noticia, Foro, Usuario.

Los Entity Beans normalmente mapean las tablas de una base de datos relacional,
aunque también es posible que mantengan la persistencia de los datos
en ficheros, por ejemplo un XML, o en LDAP. En cualquiera de los casos el objetivo
de un Entity Bean es cachear los datos en memoria desde una fuente persistente
y mantener una sincronización total entre el estado de los datos en memoria
y la fuente de datos.

Por esta razón se dice que los Entity Bean son los EJB que sobreviven
a caídas del sistema, ya que en caso de un fallo del sistema, los datos
que hay en memoria están guardados en el dispositivo persistente, con
lo cual, cuando se reinicie el servidor se recuperaran sin ningún problema.

Este tipo de EJB abstrae totalmente la capa de persistencia del sistema y funciona
como una herramienta de traducción de base de datos relacional a objeto,
por ejemplo, se podría cambiar el nombre de una columna de una tabla
y el resto de capas no se daría cuenta, ya que a esa columna se accedería
a través de un método get/set del Entity Bean.

Quizás las criticas de este tipo de componentes vienen por la lentitud
en las funciones de búsqueda, los llamados "finders". Estos
métodos devuelven una colección de interfaces remotos que cumplen
una serie de condiciones, similares a las instrucciones SQL. Si bien es cierto
que es más lento que una simple llamada SQL, no suele ser mucho mayor
que estas si se hace un correcto uso de las transacciones y se minimiza el número
de llamadas a través de la red. En cualquiera de los casos, no suele
ser recomendable hacer este tipo de llamas si sólo se va ha hacer una
lectura

Como se ha explicado antes, los EJB se mantienen dentro de un pool en memoria.
En caso de los Entity Beans esto significa que tenemos varias filas de la base
de datos en memoria, por lo que podemos conseguir accesos muy rápidos
a esas filas, por lo tanto es interesante mantener aquellos registros en memoria
que creamos que se van a volver a utilizar.

Dentro de los Entity Beans hay dos formas de manejar la persistencia, se puede
dejar en manos del programador o en manos del contenedor.

Bean Managed Persistence

Los BMP son los Entity Bean que soportan la persistencia gracias a las instrucciones
explicitas del programador, por lo que este deberá introducir las instrucciones
necesarias en los métodos definidos por la interfaz EntityBean, ejbLoad,
ejbRemove, ejbCreate, etc.

Cada vez se usan menos este tipo de Entity Beans, pero todavía hay algunas
operaciones que sólo se pueden realizar gracias a las habilidades de
los programadores. En cualquiera de los casos siguen siendo imprescindibles
cuando la persistencia no se consigue a través de una base de datos relacional.

Container Managed Persistence

Los CMP soportan la persistencia de forma declarativa o implícita gracias
al contenedor, es decir, no es necesario implementar los métodos de la
interfaz EntityBean, sólo hay que definir de forma correcta el descriptor
para que así el contenedor tenga la información necesaria para
gestionar la persistencia contra una base de datos relacional.

A pesar de que en los principios de los EJB, este tipo de Entity Bean no era
muy usado, ya que los programadores no se fiaban mucho de los contenedores,
actualmente son las más usados e incluso están recomendados por
causas de eficiencia con respecto a los BMP.

Crear un CMP es realmente sencillo y la cantidad de funciones que lleva a cabo
es realmente impresionante, muchos programadores, la primera vez que ven lo
fácil y lo completo de un Entity Bean se quedan boquiabiertos.

Message-Driven Beans

Son muy parecidos a los beans de sesión pero estos reciben mensajes
y no ofrecen respuesta al cliente, son asíncronos. Autorización
de compra, Chequeo de tarjeta de créditoson ejemplos de ellos. Nuevos
en EJB 2.0

Su único método, onMessage, recibe el tipo de mensaje y con él
realiza una serie de operaciones de las cuales el usuario no obtendrá
respuesta directa. Cuando este tipo de operaciones se van a realizar en un tiempo
indeterminado y no es necesaria la respuesta inmediata al cliente, es donde
toman fuerza este tipo de EJB.

Otras posibilidades

Dentro del mercado de componentes distribuidos los EJB no se encuentran solos,
sus más fieles competidores son los objetos COM + de Microsoft y CORBA.


CORBA ha perdido mucho tirón en los últimos años ya que
este tipo de componentes son bastante complejos de programar y no acababan de
ser portables entre las diferentes versiones comerciales que soportaban el estándar.

Las discusiones entre los tipos de objetos EJB y COM + ha proliferado desde
la aparición de plataforma .NET, y dependiendo de las fuentes que se
consulten se obtienen respuestas totalmente diferentes. A modo de esquema la
siguiente tabla define bastante bien cuáles son las diferencias entre
los dos tipos de objetos.

Característica	EJB	COM +
Lenguaje	Sólo Java	Todos
Plataformas (SO)	Todos	Windows 2000
Servidores (Productos Middleware)	30 +	Microsoft
Integración con otros sistemas	RMI/JNI, CORBA, JCA COM TI,	MSMQ, OLE DB
Protocolo	Cualquiera (IIOP)	DCOM
Componentes sin Sesión	Sí	Sí
Componentes con Sesión	Sí	No
Componentes persistentes	Sí	No
Transacciones por método	Sí	No
Equilibrio de carga (Load Balancing)	La mayor parte de vendedores	Sí
Cache de datos (Pools)	Algunos vendedores	No
Componentes de mensajes	Sí	Sí
Precio bajo por transacción	No (Open Source Si)	Sí
Middleware viene con SO	No	Sí
Procesadores por máquina	256 +	16 (32 vía OEMS)
Numero de servidores en un cluster	Teóricamente ilimitado	Teóricamente ilimitado
Herramientas de desarrollo	Varias Opciones	Microsoft .NET Estudio

En cualquiera de los casos, la elección de un tipo de componente u otro
al final se basa en la siguiente pregunta ¿SUN o Microsoft?

Mientras SUN intenta defender su plataforma buscando la colaboración
de personas de otras empresas (HP, IBM, SAP entre otras 400) para conseguir
así que las especificaciones se conviertan en verdaderos estándares
de facto, Microsoft apuesta por el marketing como principal defensora de su
estrategia junto a la integración de su plataforma dentro de su conocido
sistema operativo. Pero es esta razón la que hace ganar la batalla a
SUN en lo que a soluciones empresariales se refiere.

No hay que olvidar que hoy en día el dinero en internet los mueven las
grandes empresas y estás cada vez apuesta menos por las soluciones Microsoft.
Un dato bastante claro es la dificultad de encontrar un banco on-line implementado
con algún producto Microsoft. Seguramente la imposibilidad de utilizar
la plataforma .NET y el resto de productos Microsoft en estaciones de trabajo
UNIX hace que los grandes proyectos sean solamente implementados con J2EE u
otras soluciones multiplataforma.

Otro punto a favor de Java y J2EE es la estabilidad contrastada a lo largo
de los últimos años de las APIS implementadas por SUN e IBM. Estás
han evolucionado progresivamente en la ultima década mientras la plataforma
.NET intenta conseguir una arquitectura similar en un espacio mucho más
corto de tiempo.

También hay que destacar que Java esta siendo utilizado en la mayoría
de los centros de investigación y formación en todo el mundo y
que los programadores Java son los más numerosos. Hacer cambiar a todos
ellos de plataforma, sin que aparentemente este cambio vaya a ofrecer unas mejoras
espectaculares, en lo que ha estabilidad, reusabilidad y tiempo de desarrollo
se refiere, hace que muchas empresas decidan continuar sus desarrollos en Java.

Enrique Rodriguez Lasterra. Para cualquier duda o tirón de orejas, e-mail a: lasterra_ARROBA_javahispano.org