En una aplicación de la plataforma
J2EE, los clientes -- como aplicaciones, páginas JSP, servlets, componentes
JavaBeans, acceden a los beans de entidad mediante sus interfaces remotas. Así,
toda llamada de un cliente potencialmente se enruta a través de los stubs (trozos) y skeletons(esqueletos), incluso si el cliente y el bean enterprise
están en la misma Máquina Virtual Java, en el mismo sistema operativo o en la
misma máquina física.
Cuando los beans enterprise son
objetos específicos, los clientes tienden a invocar los métodos del bean de
forma más individual, resultando en una gran sobrecarga en la red.
Hay varias áreas que se ven
impactadas por la aproximación del diseño del bean de entidad específico:
·
Relaciones de Entidades - Mapear directamente un objeto de
modelo a un modelo EJB no tiene en cuenta el impacto de las relaciones entre
objetos. Las relaciones inter-objetos se transforman directamente en relaciones
inter-beans. Como resultado, un bean de entidad podría contener o almacenar una
referencia remota a otro bean de entidad. Sin embargo, mantener referencias
remotas a objetos distribuidos implica técnicas y semánticas diferentes a la de
mantener referencias a objetos locales. Junto con el incremento de complejidad
del código, se reduce la flexibilidad porque el bean de entidad debe cambiar si
cambia alguna de sus relaciones.
Además, no hay garantías de la validez de las referencias de un bean de entidad
a otro bean de entidad en el tiempo. Dichas referencias se establecen
dinámicamente utilizando el objeto home de
la entidad y la clave primaria para ese ejemplar de bean. Esto implica una alta
sobrecarga de mantenimiento para el chequeo de validez de la referencia por
cada referencia de bean-de-entidad-a-bean-de-entidad.
·
Manejabilidad - Implementar objetos específicos como beans
de entidad resulta en un mayor número de beans de entidad en el sistema, el
desarrollador debe proporcionar clases para el interface home,
el interface remote, la implementación del bean y la clave
primaria.
Además, el contenedor
podría generar clases para soportar la implementación del bean de entidad.
Cuando se crea el bean, estas clases se convierten en objetos reales en el
contenedor. En breve, el contenedor crea varios objetos para soportar cada
ejemplar de bean de entidad. Un mayor número de beans de entidad significa más
clases y código que mantener por el equipo de desarrollo. También resulta en un
mayor número de objetos en el contenedor. Esto puede impactar negativamente en
el rendimiento de la aplicación.
·
Rendimiento de Red -- los beans de entidad específicos,
potencialmente tienen más relaciones inter-beans. Los beans de entidad son
objetos distribuidos. Cuando un bean de entidad invoca un método de otro bean
de entidad, el contenedor trata esa llamada como una llamada remota, incluso si
ambos beans están en el mismo contenedor. Si el número de relaciones
bean-de-entidad-a-bean-de-entidad se incrementa, se reduce la escalabilidad del
sistema debido a la fuerte sobrecarga de la red.
·
Dependencia del Esquema de Base de Datos - Cuando los beans
de entidad son específicos cada ejemplar normalmente representa una sóla fila
de la base de datos. Esto no es una aplicación apropiada del diseño de beans de
entidad, ya que los beans de entidad son más apropiados para componentes
genéricos. La implementación de beans de entidad específicos normalmente es una
representación directa del esquema de la base de datos subyacente en el diseño
del bean de entidad. Cuando los clientes utilizan estos beans de entidad
específicos, están operando esencialmente a nivel de fila en la base de datos,
ya que cada bean de entidad efectivamente es una única fila. Como el bean de
entidad modela directamente una sola fila de la base de datos, los clientes
dependen del esquema de la base de datos. Cuando el esquema cambia, también
deben cambiar las definiciones del bean de entidad. Además, como los clientes
están operando con la misma especificidad, deben observar y reaccionar ante
estos cambios. Esta dependencia del esquema causa una pérdida de flexibilidad e
incrementa la sobrecarga de mentenimiento requerida cuando cambia el esquema.
·
Especificidad del Objeto (Genérico frente a Específico) --
La especificidad del objeto impacta en la transferencia de datos entre el bean
enterprise y el cliente. En muchas aplicaciones, los clientes necesitan un
trozo de datos mayor que una o dos filas de la tabla. En dichos casos, implementar
cada unos de estos objetos específicos como un bean de entidad significa que el
cliente tendría que manejar las relaciones entre todos esos objetos
específicos. Dependiendo de los requerimientos de datos, el cliente podría
tener que realizar muchas búsquedas de varios beans de entidad para obtener la
información necesaria.
Los clientes no necesitan conocer la implementación del
esquema de la base de datos para utilizar y soportar los beans de entidad. Con
beans de entidad específicos, el mapeo se hace normalmente para que cada
ejemplar de bean de entidad corresponda con una sola fila de la base de datos.
Este mapeo específico crea una dependencia entre el cliente y el esquema de la
base de datos subyacente, ya que el cliente trata con beans específicos y éstos
esencialmente son una representación directa del esquema subyacente. Esto
resulta en un fuerte acoplamiento entre el esquema de la base de datos y los
beans de entidad. Un cambio en el esquema causa el cambio correspondiente en el
bean de entidad, y además requiere el cambio correspondiente en los clientes.
Una
solución a los problemas que se presentan es utilizar Composite Entity para
modelar, representar y manejar un conjunto de objetos persistentes relacionados
en vez de representarlos como beans de entidad específicos individuales. Un
bean Composite Entity representa un grupo de objetos.
Para entender esta solución, primero
definamos que significan los objetos persistentes y discutiremos sus
relaciones.
Un objeto persistente es un objeto que
se almacena en algún tipo de almacenamiento. Normalmente múltiples clientes
comparten los objetos persistentes. Los objetos persistentes se pueden
clasificar en dos tipos: objetos genéricos y objetos dependientes.
Un objeto genérico es
autosuficiente. Tiene su propio ciclo de vida y maneja sus relaciones con otros
objetos. Todo objeto genérico podría referenciar o contener uno o más objetos.
El objeto genérico normalmente maneja el ciclo debida de estos objetos. De ahí,
que esos objetos sean conocidos como objetos dependientes. Un objeto
dependiente puede ser un simple objeto auto-contenido o podría a su vez
contener otros objetos dependientes.
Un bean Composite Entity puede
representar un objeto genérico y todos sus objetos dependientes relacionados.
Esta combinación de objetos persistentes relacionados dentro de un sólo bean de
entidad reduce drásticamente el número de beans de entidad requeridos por la
aplicación. Esto genera un bean de entidad altamente genérico que puede obtener
mejor los beneficios de los beans de entidad que un bean de entidad específico.
Sin la aproximación Composite Entity, hay una tendencia a ver todos los objetos
genéricos y dependientes como beans de entidad separados, suponiendo un gran
número de beans de entidad.
·
Estructura (diagrama de clases)
·
Diagrama de flujo de
datos
·
Participantes
-
CompositeEntity
CompositeEntity es un bean de entidad genérico. Podría ser un objeto
genérico, o podría contener una referencia a un objeto genérico.
-
Coarse-Grained Object
Un objeto genérico es un objeto que
tiene su propio ciclo de vida y que maneja sus propias relaciones con otros
objetos. Un objeto genérico puede ser un objeto Java contenido en el CompositeEntity. O, el propio Composite Entity puede ser un objeto genérico que contiene objetos
dependientes.
-
DependentObject1, DependentObject2, y DependentObject3
Un objeto dependiente es un objeto
que depende de un objeto genérico el cual gobierna el ciclo de vida del objeto
dependiente. Un objeto dependiente puede contener otros objetos dependientes;
así podría existir un árbol de objetos dentro del Composite Entity.