domingo, 7 de julio de 2013

PATRÓN SESSION FACADE

CONTEXTO
Los Beans Enterprise encapsulan lógica y datos de negocio y exponen sus interfaces, y con ellos la complejidad de los servicios distribuidos, a la capa de cliente.

PROBLEMA
En un entorno de las aplicaciones multicapa de la Plataforma Java 2, se pueden encontrar los siguientes problemas:
Acoplamiento fuerte, que provoca la dependencia directa entre los clientes y los objetos de negocio.
Demasiadas llamadas a métodos entre el cliente y el servidor, abocando a problemas de rendimiento de la red.
Falta de una estrategia de acceso uniforme de los clientes, exponiendo los objetos de negocio a una mala utilización.
Una aplicación J2EE multicapa tiene numerosos objetos del lado del servidor que se implementan como beans enterprise. Además, otros objetos arbitrarios podrían proporcionar servicios, datos o las dos cosas. A estos objetos los conocemos colectivamente como objetos de negocio, ya que encapsulan datos y lógica de negocio.
Las aplicaciones J2EE implementan objetos de negocio que proporcionan servicios de procesamiento como beans de sesión. Los objetos de negocio genéricos que representan una vista de un objeto de almacenamiento persistente y que es compartido por varios usuarios, normalmente se implementan como beans de entidad.
El acoplamiento fuerte entre objetos también se obtiene cuando los objetos manejan sus relaciones entre ellos mismos. Frecuentemente, no está claro donde se manejan las relaciones. Esto provoca la complejidad de las relaciones entre los objetos de negocio y la rigidez en la aplicación. Esta falta de flexibilidad hace las aplicaciones menos manejables cuando se necesita hacer cambios.
Aparece otro problema cuando un cliente interactúa directamente con los objetos de negocio. Como los objetos de negocio se exponen directamente a los clientes, no hay una estrategia unificada para acceder a ellos. Sin dicha estrategia uniforme de acceso por parte del cliente, los objetos de negocio se ven expuestos a los clientes y se podría reducir su utilización consistente.

CAUSAS

  • Proporcionar a los clientes un interface sencillo que oculte todas interacciones complejas entre los componentes de negocio.
  • Reducir el número de objetos de negocio que se exponen al cliente a través de la capa de servicio sobre la red.
  • Ocultar al cliente las interacciones y las interdependencias entre los componentes de negocio. Esto proporciona una mejor manejabilidad, centralización de interacciones (responsabilidades), mayor flexibilidad, y mayor habilidad para soportar los cambios.
  • Proporcionar una capa de servicio uniforme para separar la implementación de los objetos de negocio de la abstracción del servicio de negocio.
  • Evitar la exposición directa de los objetos de negocio a los clientes para mantener el acoplamiento entre las dos capas al mínimo.


SOLUCIÓN
Usar un bean de sesión como una fachada (facade) para encapsular la complejidad de las interacciones entre los objetos de negocio participantes en un flujo de trabajo. El Session Facade maneja los objetos de negocio y proporciona un servicio de acceso uniforme a los clientes.
Session Facade abstrae las interacciones de los objetos de negocio y proporciona una capa de servicio que expone sólo los interfaces requeridos. Así, oculta a la vista de los clientes las interacciones complejas entre los participantes. El Session Facade controla las interacciones entre los datos de negocio y los objetos de servicio de negocio que participan en el flujo de trabajo, y encapsula la lógica de negocio asociada con los requerimientos, Así, el bean de sesión (representando al Session Facade) maneja las relaciones entre los objetos de negocio. El bean de sesión también maneja el ciclo de vida de los participantes creando, localizando (buscando), modificando, y borrándolos según lo requiera el flujo de trabajo. En una aplicación compleja, el Session Facade podría delegar este control del estilo de vida en un objeto separado. Por ejemplo, para controlar el estilo de vida de los beans de sesión e identidad participantes, Session Facade podría delegar este trabajo a un objeto Service Locator.

ESTRUCTURA
La siguiente figura representa el diagrama de clases del patrón Session Facade.



PARTICIPANTES Y COLABORACIONES
La siguiente figura contiene el diagrama de secuencia que muestra las interacciones de un Session Facade con dos beans de entidad, un bean de sesión y un DAO, todos actuando como participantes en el cumplimiento de la petición del cliente.



Client- Representa al cliente del Session Facade, que necesita acceder al servicio de negocio. Este cliente puede ser otro bean de sesión (Session Facade) en la misma capa de negocio o un Business Delegate en otra capa.

SessionFacade- El SessionFacade se implementa como un bean de sesión. Maneja la relaciones entre varios objetos de negocio y proporciona una abstracción de alto nivel para el cliente. El SessionFacade ofrece acceso genérico a los BusinessObject participantes representados por la llamada Invoke en el bean de sesión.

BusinessObject- BusinessObject es un objeto de rol que facilita la aplicación de diferentes estraegias, como beans de sesión, de entidad o DAO. Un BusinessObject proporciona datos y/o algún servicio del diagrama de clases. El SessionFacade interactúa con varios ejemplares de BusinessObject para proporcionar el servicio.

CONSECUENCIAS

  • Introduce la Capa Controladora para la Capa de Negocio 
  • Expone un Interface Uniforme 
  • Reduce el Acoplamiento, Incrementa la Manejabilidad 
  • Mejora el Rendimiento, Reduce los Métodos Específicos 
  • Proporciona Acceso Genérico 
  • Centraliza el Control de Seguridad 
  • Centraliza el Control de Transacciones 
  • Expone Menos Interfaces Remotos a los Clientes


No hay comentarios:

Publicar un comentario