PDF de programación - ¿“To EJB” or not “To EJB”

¿“To EJB” or not “To EJB”?

Marzo de 2005

@author: Jorge Rodríguez

EJB es considerado por la mayoría el núcleo del J2EE, y por mucho tiempo la solución a todos los 
requerimientos de aplicaciones empresariales. Fue centro de atención de muchas empresas vendedoras de 
servidores de aplicación por algunos años, pero hoy el mercado esta consolidado por lo que solo quedan 
algunas empresas lideres. 

En el año 1998 aparece la especificación EJB 1.0 en medio de la moda del dotcom, así las empresas del sector 
no limitaban los gastos en infraestructura, sin importar muchas veces si la inversión significaba beneficios. Era 
una época de un clima económico benigno, que ayudó al surgimiento de tecnologías como el J2EE, costos 
como el hardware, las licencias, e incluso el entrenamiento del personal se contaban dentro de los 
presupuestos. 
Por otra parte, CORBA era la única alternativa abierta frente a COM/DCOM de M$1, pero CORBA es una 
tecnología compleja y que además no abstrae al desarrollador de tener que lidiar con APIs de comunicación 
remota, así, EJB aparece como una solución ideal, simple y abierta.

Mito vs Realidad
EJB fue creado entonces para facilitar nuestra vida, el comité encargado del EJB 1.0 nos promete entre otras 
cosas que:

–

–

“Sería muy fácil escribir aplicaciones usando los Enterprise Java Beans, pues los contenedores de EJB nos 
proveen de servicios que nos permitirían concentrarnos en el negocio de la aplicación”.
“Nuestras aplicaciones se escribirían un sola una vez, y luego se instalarían en cualquier plataforma sin 
tener que modificar el código fuente ni recompilar nuestros EJBs, o sea aplicaciones 100% portables”.

Pero todas estas promesas relacionadas al uso de EJB no se cumplen muy bien, la realidad práctica ha 
mostrado otros resultados con respecto al uso de estos componentes en nuestras aplicaciones J2EE. 
Desarrollar una aplicación usando EJB es costoso tanto del punto de vista económico como desde el 
tecnológico. 

No abundan desarrolladores con buen grado de conocimientos en el área EJB, y de encontrarlos es evidente 
que se tenga que  pagar un precio caro por contratarlos en un proyecto. Por otro lado el esquema para el 
equipo de desarrollo que propone la especificación donde hay roles tales como Proveedor de Beans (Bean 
Provider), Ensamblador de Aplicación (Application Assembler), Instalador de EJB (EJB Deployers) y 
Administrador de Sistemas (System Administrator) solo existe en la mente del comité encargado de mantener la 
especificación.

Del lado tecnológico, lidiar con componentes EJB no es una tarea trivial, a pesar que existen herramientas que 
ayudan en el trabajo de desarrollo, no es transparente el ciclo de crear, deployar y probar un EJB. Mismo en 
ambientes de desarrollo sofisticados como el Workshop de bea o el WSAD de IBM, casi nunca escapamos al 
infierno que significa entender y muchas veces modificar descriptores de instalación estándares como los ejb­
jar.xml, o propietarios como weblogic­ejb­jar.xml.

En fin, el uso de EJBs significa altos costos en los proyectos, y bajas de  la productividad en el desarrollo, y 
como consecuencia demora y falla en el cumplimiento de plazos de entrega establecidos en los proyectos, pero 
hay más.

1 Micro$oft.

Sobre los Stateless Session Beans
Los Stateless Session Beans son muy populares entre arquitectos e ingenieros J2EE, y su fama no está mal 
infundada, ya que en un final proveen a la aplicación servicios necesarios como el manejo de transacciones, 
concurrencia, acceso remoto, soporte a clusters, pool de objetos de negocio, seguridad declarativa y el 
gerenciamiento de los objetos de negocio, abstrayéndonos de su implementación.

No obstante, como veremos más adelante, es posible contar con estos servicios sin depender de un contenedor 
EJB.

Modelo de Componentes y Modelo de Objetos
EJB introduce un modelo de componentes complejo, que incumple la promesa de escribir aplicaciones 
fácilmente, pues además de que tenemos que lidiar con todas las implementaciones de clases e interfaces de la 
API (ver figura 1), a nivel de código debemos hacer “lookup” de todos los EJB, y a pesar de hacer uso de 
patrones de diseño como el ServicesLocator, o el BusinessDelegate para minimizar el dolor, estos introducen 
dependencia de JNDI y las APIs EJB en nuestro código que finalmente queda amarrado al contenedor.

Por otra parte cuando diseñamos teniendo en cuenta que usaremos el modelo EJB, particularmente entity 
beans estamos limitando el diseño de nuestro modelos de objetos, personalmente considero a EJB como una 
tecnología invasiva en la etapa de diseño OO y que va en contra de los conceptos de ADOO, imaginen a la 
clase CuentaCorriente, que es evidentemente una clase de negocios teniendo que implementar la interface 
EntityBean, con esto estamos marcando la clase como persistente, ¿porque habría de saber CuentaCorriente 
que va a ser persistente?. El uso de entity beans introduce lo que Martin Fowler2 describe como modelos 
anémicos, donde un objeto no posse comportamiento, solo estado.

2 http://www.martinfowler.com

Fig1. Fragmento del modelo EJB, los objetos de color gris son implementaciones que debemos proveer al 
container.

1. Crea un objeto

Home

MiEJBHome

EJB Container

ejb-jar.xml
(descriptor)

Cliente

3. Devuelve una

referencia

2. Crea un objeto

EJB

4. Llama lógica de
negocio del bean

MiEJBObject

MiSessionBean

5. Finalmente el EJB

Object delega

Donde están los vendedores de EJB?
Otra especulación de la que alardea el modelo EJB, es la de poder comprar componentes EJB hechos por 
terceros y ensamblarlos para construir una aplicación de forma ágil (recuerden la definición de roles descrita en 
párrafos anteriores). Todo parece indicar que la mala portabilidad de los EJB ligados muchas veces con 
características propietarias de los servidores de aplicación son causa de que este mercado nunca tuviera éxito 
en comparación con el mercado de controles ActiveX o Java Beans3(en sus versiones de tag libs o incluso 
librerías .jar para diversos fines).

Java ya no es el mismo
La especificación EJB 1.0 aparece meses antes que el J2SE saliera en su versión 1.2 con grandes mejoras 
como el framework Collections, o la incorporación de Swing al JRE4, así mismo continua el desarrollo del J2SE 
llegando las versiones 1.3, 1.4 y hace muy poco la 5.0, sin embargo EJB sufre pocos cambios, casi siempre, 
soluciones a problemas de performance o escalabilidad como la inclusión de las interfaces locales en la 
especificación 2.0 o los Web Services en la 2.1.

3 Objeto Java con un constructor vacío (default) e implementaciones de métodos get/set para cada uno de sus 

atributos private, o protected.

4 En versiones anteriores Swing eran librerias aparte.

La versión 1.3 del J2SE introdujo características nuevas como los Proxis Dinámicos, que permiten implementar 
cualquier interface en runtime, lo cual fue incluso usado por las implementaciones EJB 2.0 que permiten la 
generación de las clases (stubs) ahora en la fase de deployment de la aplicación. Por otra parte esta nueva 
funcionalidad acompañada de otras como la mejora en la performance del paquete reflection del nuevo JDK dio 
lugar al nacimiento de una nueva era en la que aparecieron librerías como las CGLIB (Code Generation 
Library), librerías usadas por Hibernate, iBatis, o Spring y que permiten generar código en runtime que 
intercepte llamadas a métodos de cualquier clase java.

Por su parte el J2SE 5.0 incluye el uso de meta­datos a nivel de código fuente (en los .java), conocido como 
“annotations”5 que permiten eliminar el uso de archivos descriptores como los ejb­jar.xml. 

Otro modelo de programación ha surgido con esta ola de nuevas tecnologías y es la AOP6 (Aspect Oriented 
Progamming), que basado en la intercepción, permite ejecutar código antes y después de la llamada de 
cualquier método de cualquier clase, sin tener esta que extender de clase o interface alguna. A diferencia del 
modelo EJB, AOP es un complemento a la programación orientada a objetos, lo cual define en muchos 
aspectos su éxito y uso actual. No obstante el uso de AOP incluye una curva de aprendizaje en los 
desarrolladores, pero hoy es posible el uso de frameworks que nos abstraen de su uso directo, como es el caso 
de Spring (que hace extensivo uso de AOP, por ejemplo para el manejo de transacciones en métodos de 
negocios).

Antipatrones
La aparición en primera instancia de la especificación EJB y luego de las implementaciones reales, obligaron a 
los vendedores de containers EJB a cumplir los estándares, olvidando la experiencia práctica, lo cual provocó la 
aparición de ciertos “Patrones de Diseño”, creados en su mayoría para resolver problemas del modelo EJB 
como la alta dependencia de llamadas JNDI (ServiceLocator), la baja performance provocada por el exceso de 
llamadas remotas (BusinessDelegate), o el transporte de datos entre capas remotas (DTO7), estos patrones 
además introducen nuevas curvas de aprendizaje, no basta con leerse las casi 400 páginas de la 
especificación, debemos aprender también como usar los patrones. Sin embargo muchos de estos forman parte 
de un conjunto de malas prácticas de programación que se ponen de moda entre desarrolladores, un ejemplo 
clásico lo constituye el patrón DTO que introduce duplicación de código, y como consecuencia de esfuerzo a la 
hora de la manutención, imaginen de nuevo a CuentaCorriente, pero además ahora CuentaCorrienteDTO y que 
ahora además implementa la interface Serializable.

Escalabilidad
EJB por su naturaleza remota permite la distribución de componentes dentro de las aplicaciones (separación 
física usando interfaces remotas) y  por mucho tiempo se pensó que escalaban mejor que las aplicaciones web 
co­locadas (separación lógica), pero la práctica ha demostrado lo contrario, tanto Entity Beans como los 
Statefull Session Beans no escalan bien en ambientes clusterizados, sin embargo los Stateless Session Bean