COMPOSITE ENTITY

Una entidad compuesta puede estar compuesta de muchos niveles de objetos dependientes en su árbol de objetos. Carga todos los objetos dependientes cuando la Entidad Compuesta ejbLoad () método es llamado por el contenedor EJB puede tomar mucho tiempo y recursos. Una forma de optimizar esto es mediante el uso de una estrategia de carga lenta para cargar los objetos dependientes. Cuando el ejbLoad () se llama al método, al principio sólo carga los objetos dependientes que son más cruciales para los clientes entidad compuesta. Posteriormente, cuando los clientes acceder a un objeto dependiente que aún no ha sido cargado desde la base de datos, la entidad compuesta puede realizar una carga en la demanda. Por lo tanto, si no se utilizan algunos objetos dependientes, no están cargados en la inicialización. Sin embargo, cuando los clientes necesitan posteriormente los objetos dependientes, que se cargan en ese momento. Una vez que se carga un objeto dependiente, contenedor posterior llama a laejbLoad () método debe incluir los objetos dependientes de recarga para sincronizar los cambios con el almacén persistente.

CONTEXTO

Los beans de entidad no pretenden representar todos los objetos persistentes en el modelo de objetos. Los beans de entidad son más adecuados para los objetos de negocio persistentes de grano grueso.

PROBLEMA

En la plataforma Java 2, la aplicación Enterprise Edition (J2EE), los clientes - tales como aplicaciones, JavaServer Pages (JSP) páginas, Servlets, JavaBeans componentes - Acceso entidades judías a través de sus interfaces remotas. Por lo tanto, cada invocación de cliente potencialmente rutas a través de los talones de la red y esqueletos, incluso si el cliente y el bean enterprise están en la misma JVM, sistema operativo, o de la máquina. Cuando los beans de entidad son objetos específicos, los clientes tienden a invocar los métodos más individuales de beans de entidad, lo que sobrecarga de red alta.

Los beans de entidad representan objetos de negocio persistentes distribuidos. Ya sea en desarrollo o la migración de una aplicación para la plataforma J2EE, granularidad objeto es muy importante al momento de decidir lo que debe implementar como un bean de entidad. Los beans de entidad deben representar los objetos de negocio de grano grueso, como los que proporcionan un comportamiento complejo más allá de simplemente obtener y establecer los valores de campo. Estos objetos genéricos suelen tener objetos dependientes. Un objeto dependiente es un objeto que no tiene dominio verdadero significado cuando no se asocia con su matriz de grano grueso.

Un problema recurrente es la aplicación directa del modelo de objetos a un modelo de Enterprise JavaBeans (EJB) (específicamente beans de entidad). Esto crea una relación entre los objetos bean de entidad sin consideración de los objetos de grano grueso frente de grano fino (o dependiente). La determinación de qué hacer con grano grueso en comparación con grano fino suele ser difícil y se puede hacer mejor a través de las relaciones de modelado en los modelos de Lenguaje Unificado de Modelado (UML).

Hay un número de áreas afectadas por la entidad enfoque de diseño de frijol de grano fino:

·         Relaciones Entidad - Directamente cartografía un modelo de objetos a un modelo EJB no tiene en cuenta el impacto de las relaciones entre los objetos. Las relaciones entre los objetos se transforman directamente en las relaciones entre las entidades de frijol. Como resultado, un bean de entidad puede contener o sostener una referencia remota a otro bean de entidad. Sin embargo, el mantenimiento de referencias remotas a objetos distribuidos implica diferentes técnicas y semánticas que mantiene las referencias a objetos locales.Además de aumentar la complejidad del código, se reduce la flexibilidad, ya que el bean de entidad debe cambiar si se produce algún cambio en sus relaciones.

Además, no hay ninguna garantía en cuanto a la validez de las referencias de beans de entidad a otros beans de entidad en el tiempo. Dichas referencias se establecen dinámicamente usando el objeto home de la entidad y la clave principal para esa instancia bean de entidad. Esto implica una sobrecarga de alto mantenimiento de validez verificación de referencias de cada uno de dichos referencia de entidad-bean-de-entidad-bean.

·         Manejabilidad - Implementar objetos de grano fino como entidad frijoles resulta en un gran número de beans de entidad en el sistema. Un bean de entidad se define utilizando varias clases. Para cada componente bean de entidad, el desarrollador debe proporcionar clases para la interfaz de inicio, la interfaz remota, la implementación del bean, y la clave principal.

Además, el recipiente puede generar clases para apoyar la implementación del bean entidad. Cuando se crea el bean, estas clases se realizan como objetos reales en el recipiente. En resumen, el contenedor crea una serie de objetos para apoyar a cada instancia del bean entidad. Un gran número de beans de entidad como resultado más clases y el código para mantener el equipo de desarrollo. También da lugar a un gran número de objetos en el recipiente. Esto puede afectar negativamente al rendimiento de la aplicación.

·         Rendimiento de la red - beans de entidad potencialmente tienen más relaciones de frijol entre las entidades. Los beans de entidad son objetos distribuidos. Cuando un bean de entidad invoca un método en otro bean de entidad, la llamada es potencialmente tratado como una llamada remota por el contenedor, incluso si ambos son beans de entidad en el mismo contenedor o JVM. Si el número de relaciones entidad-bean-de-entidad-frijol aumenta, esto disminuye la escalabilidad del sistema debido a la sobrecarga de la red pesada.

·         Base de datos de dependencia de esquemas - Cuando los beans de entidad son de grano fino, cada instancia del bean de entidad generalmente representa una única fila de una base de datos. Esto no es una aplicación adecuada del diseño bean de entidad, desde beans de entidad son más adecuados para los componentes de grano grueso. De grano fino implementación del bean entidad normalmente es una representación directa del esquema de base de datos subyacente en el diseño bean de entidad. Cuando los clientes utilizan estos beans de entidad de grano fino, que son esencialmente operan en el nivel de fila en la base de datos, ya que cada bean de entidad es en realidad una sola fila. Debido a que el bean de entidad modela directamente una sola fila de base de datos, los clientes se vuelven dependientes del esquema de base de datos. Cuando los cambios de esquema, las definiciones de beans de entidad deben cambiar también. Además, dado que los clientes están operando a la misma granularidad, deben observar y reaccionar a este cambio. Esta dependencia de esquema provoca una pérdida de flexibilidad y aumenta la sobrecarga de mantenimiento siempre que se requieran cambios de esquema.

·         Granularidad de objetos (de grano grueso en comparación con grano fino) - Objeto granularidad impactos transferencia de datos entre el bean enterprise y el cliente. En la mayoría de las aplicaciones, los clientes suelen necesitar un pedazo más grande de los datos de una o dos filas de una tabla. En tal caso, la aplicación de cada uno de estos objetos de grano fino como un bean de entidad significa que el cliente tendría que administrar las relaciones entre todos estos objetos de grano fino. Dependiendo de los requisitos de datos, el cliente podría tener que realizar muchas búsquedas de un número de beans de entidad para obtener la información requerida.

BENEFICIOS

·         Los beans de entidad son mejor implementados como objetos genéricos, debido a los altos costos asociados a cada bean de entidad. Cada bean de entidad se implementa utilizando varios objetos, como EJB objeto de origen, objeto remoto, la aplicación de frijol, y la clave primaria, y cada uno es dirigido por los servicios de contenedores.

·         Las aplicaciones que se asignan directamente esquema de base de datos relacionales para beans de entidad (donde cada fila de una tabla se representa mediante una instancia del bean entidad) tienden a tener un gran número de beans de entidad. Es deseable mantener los beans de entidad de grano grueso y reducir el número de beans de entidad en la aplicación.

·         Asignación directa de modelo de objetos de modelo EJB proporciona beans de entidad.Beans de entidad, por lo general se asignan a el esquema de base de datos. Este mapeo fila entidad a la base de datos hace que los problemas relacionados con el rendimiento, manejabilidad, seguridad y gestión de transacciones. Las relaciones entre las tablas se implementan como las relaciones entre beans de entidad, lo que significa que los beans de entidad contienen referencias a otros beans de entidad para poner en práctica las relaciones de grano fino. Es muy caro para gestionar las relaciones entre las entidades de frijol, debido a que estas relaciones se deben establecer de forma dinámica, utilizando los objetos de origen de entidad y las claves principales de los beans enterprise.

·         Los clientes no necesitan conocer la implementación del esquema de base de datos a utilizar y apoyar los beans de entidad. Con beans de entidad, la asignación se realiza generalmente de manera que cada entidad bean de instancia se asigna a una sola fila en la base de datos. Esta asignación de grano fino crea una dependencia entre el cliente y el esquema de base de datos subyacente, ya que los clientes tratan con los granos de grano fino y son esencialmente una representación directa del esquema subyacente. Esto se traduce en estrecho acoplamiento entre el esquema de base de datos y beans de entidad.Un cambio en el esquema provoca un cambio correspondiente en el bean de entidad, y además requiere un cambio correspondiente a los clientes.

·         Hay un aumento en chattiness de las aplicaciones debido a la intercomunicación entre los beans de entidad. La comunicación entre las entidades de frijol excesiva conduce a menudo a un cuello de botella. Cada llamada a un método para el bean de entidad se hace a través de la capa de red, incluso si la persona que llama está en el mismo espacio de direcciones como el llamado grano (es decir, tanto en el cliente, o la persona que llama bean de entidad, y la llamada bean de entidad están en el mismo recipiente). Mientras que algunos fabricantes de contenedores optimizan para este escenario, el desarrollador no puede depender de esta optimización en todos los recipientes.

·         Chattiness adicional puede ser observada entre el cliente y los beans de entidad ya que el cliente puede tener que comunicarse con muchos granos de entidad específicos para cumplir con un requisito. Es deseable reducir la comunicación entre dos o más beans de entidad y para reducir el chattiness entre el cliente y la capa bean de entidad.

SOLUCIÓN

Utilice Entidad Compuesta para modelar, representar y gestionar un conjunto de objetos persistentes relacionados entre sí en lugar de presentarlos como beans de entidad de grano fino individuales. Un bean Composite Entity representa un gráfico de objetos.

Para entender esta solución, primero vamos a definir lo que se entiende por objetos persistentes y discutir sus relaciones.

Un objeto persistente es un objeto que se almacena en algún tipo de almacén de datos. Varios clientes suelen compartir objetos persistentes. Objetos persistentes se pueden clasificar en dos tipos: los objetos de grano grueso y objetos dependientes.

Un objeto genérico es autosuficiente. Tiene su propio ciclo de vida y la gestión de sus relaciones con otros objetos. Cada objeto de grano grueso puede hacer referencia o contener uno o más de otros objetos. El objeto genérico generalmente administra el ciclo de vida de estos objetos. Por lo tanto, estos objetos se denominan objetos dependientes. Un objeto dependiente puede ser un simple objeto autónomo o puede a su vez contener otros objetos dependientes.

El ciclo de vida de un objeto dependiente está estrechamente ligado al ciclo de vida del objeto genérico. Un cliente sólo puede acceder indirectamente a un objeto dependiente a través del objeto genérico. Es decir, los objetos dependientes no están expuestos directamente a los clientes, ya que su objeto principal (grano grueso) los gestiona. Los objetos dependientes no pueden existir por sí mismos. En su lugar, ellos siempre tienen que tener su objeto genérico (o el padre) para justificar su existencia.

Por lo general, se puede ver la relación entre un objeto genérico y sus objetos dependientes como un árbol. El objeto de grano grueso es la raíz del árbol (el nodo raíz). Cada objeto dependiente puede ser un objeto dependiente independiente (un nodo de hoja), que es un elemento secundario del objeto genérico. O bien, el objeto dependiente puede tener relaciones padre-hijo con otros objetos dependientes, en cuyo caso se considera un nodo rama.

Un bean Composite Entity puede representar un objeto genérico y todos sus objetos dependientes relacionados. Agregación combina objetos persistentes relacionados entre sí en un solo bean de entidad, lo que reduce drásticamente el número de beans de entidad que requiere la aplicación. Esto lleva a un bean de entidad altamente genérico que puede aprovechar mejor los beneficios de los beans de entidad que puede beans de entidad.

Sin el enfoque Composite Entity, hay una tendencia a ver cada objeto de grano grueso y dependiente como un bean de entidad separada, que conduce a un gran número de beans de entidad.

ESTRUCTURA

 

Aquí el Composite Entity contiene el objeto genérico y el objeto genérico contiene los objetos dependientes.

 
Diagrama de clase Composite Entity.

Muestra las interacciones de este patrón.

PARTICIPANTES Y RESPONSABILIDADES

CompositeEntity es el bean de entidad genérico. El CompositeEntity puede ser el objeto genérico, o puede contener una referencia al objeto de grano grueso. La sección "Estrategias", explica las diferentes estrategias de aplicación de una entidad compuesta.

Objeto genérico

Un objeto genérico es un objeto que tiene su propio ciclo de vida y la gestión de sus propias relaciones con otros objetos. Un objeto genérico puede ser un objeto Java que figura en la entidad compuesta. O bien, el propio Composite Entity puede ser el objeto genérico que contiene los objetos dependientes. Estas estrategias se explican en la sección "Estrategias".Un objeto dependiente es un objeto que depende del objeto genérico y tiene su ciclo de vida gestionado por el objeto genérico. Un objeto dependiente puede contener otros objetos dependientes, por lo que puede haber un árbol de objetos dentro de la entidad compuesta.

 

 

ESTRATEGIAS

Esta sección explica las diferentes estrategias para la implementación de una entidad compuesta. Las estrategias tienen en cuenta las posibles alternativas y opciones para los objetos persistentes (grano grueso y dependientes) y el uso de objetos de transferencia.

Composite Entity Contiene Estrategia objeto genérico

En esta estrategia, el Composite Entity tiene o contiene el objeto genérico. El objeto genérico sigue teniendo relaciones con sus objetos dependientes. La sección de la estructura de este patrón lo describe como la principal estrategia.

Entidad Compuesta impulsa estrategia objeto genérico

En esta estrategia, el propio Composite Entity es el objeto genérico y tiene atributos y métodos del objeto de grano grueso. Los objetos dependientes son atributos de la entidad compuesta. Desde el Composite Entity es el objeto genérico, el bean de entidad expresa y maneja todas las relaciones entre el objeto genérico y los objetos dependientes.

CONCLUSIÓN

Este patrón mejora el rendimiento de la red y aumenta la capacidad de mantenimiento.