Composite Entity

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.