PATRÓN COMPOSITE ENTITY

CONTEXTO

Los beans de entidad no se han pensado para representar todos los objetos persistentes del modelo. Los beans de entidad son mejores para objetos de negocio persistentes genéricos.

PROBLEMA

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 remotos. Así, toda llamada de 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.

Los beans de entidad representan objetos persistentes de negocio distribuidos. Los beans de entidad deberían representar objetos de negocio genéricos, como aquellos que proporcionan un comportamiento complejo más allá de simplemente obtener y seleccionar valores de campos. Estos objetos genéricos normalmente tienen objetos dependientes. Un objeto dependiente es un objeto que no tiene un significado real cuando no está asociado con su padre genérico.

Un problema recurrente es el mapeo directo del modelo a un modelo de JavaBeans Enterpise (especificamente beans de entidad). Esto crea una relación entre los objetos beans de entidad en su consideración de genéricos contra objetos específicos (o dependientes).

CAUSAS

• Los beans de entidad son mejores para implementar objetos genéricos debido a la alta sobrecarga asociada con todo bean de entidad.
• Las aplicaciones que mapean directamente un esquema de una base de datos relacional a beans de entidad (donde cada fila de la tabla se representa como un ejemplar de un bean de entidad) tiende a tener un mayor número de beans de entidad específicos.
• Mapear directamente el modelo de objetos al modelo EJB trae beans de entidad específicos.
• Los clientes no necesitan conocer la implementación del esquema de la base de datos para utilizar y soportar los beans de entidad.

SOLUCIÓN

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.

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 de vida 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.

El ciclo de vida de un objeto dependiente está fuertemente acoplado al ciclo de vida del objeto genérico. Un cliente sólo podría acceder al objeto dependiente a través del objeto genérico. Es decir, los objetos dependientes no se exponen directamente a los clientes porque su objeto padre (genérico) los maneja. Los objetos dependientes no pueden existir por sí mismos. En su lugar, siempre necesitan tener su objeto genérico (o padre) para justificar su existencia.

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.

ESTRUCTURA

Aunque hay muchas estrategias para implementar el patrón Composite Entity, la primera que vamos a explicar está representada en el siguiente diagrama de clases. Aquí el Composite Entity contiene el objeto genérico, y éste contiene objetos dependientes:

PARTICIPANTES Y RESPONSABILIDADES

El diagrama de secuencia de la siguiente imagen muestra las interacciones para este patrón:

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.

CONSECUENCIAS

• Elimina las Relaciones Inter-Entidades
• Mejora la Manejabilidad Reduciendo los Beans de Entidad
• Mejora el Rendimiento de Red
• Incrementa la Generalidad del Objeto
• Facilita la Creación de Transfer Object Compuestos
• Sobrecarga de Grupos de Objetos Dependientes Multi-Nivel