Business Delegate

La descripción del patron es la siguiente

Contexto

Un sistema multi-capa distribuido requiere invocación remota de métodos para enviar y recibir datos entre las capas. Los clientes están expuestos a la complejidad de tratar con componentes distribuidos.

Problema

Los componentes de la capa de presentación interactúan directamente con servicios de negocio. Esta interacción directa expone los detalles de la implementación del API del servicio de negocio a la capa de presentación. Como resultado, los componentes de la capa de presentación son vulnerables a los cambios en la implementación de los servicios de negocio: cuando cambia la implementación del servicio de negocio, la implementación del código expuesto en la capa de presentación también debe cambiar.

Además, podría haber una reducción de rendimiento en la red porque los componentes de la capa de presentación que utilizan el API de servicio de negocio hacen demasiadas invocaciones sobre la red. Esto sucede cuando los componentes de la capa de presentación usan directamente el API subyacente, sin cambiar el mecanismo del lado del cliente o agregar servicios.

Por último, exponer directamente los APIs de servicios al cliente fuerza a éste a tratar con los problemas de red asociados con la naturaleza distribuida de la tecnología Enterprise JavaBeans (EJB).

Los principales motivos

• Los clientes de la capa de presentación necesitan acceder a servicios de negocio.
• Diferentes clientes, dispositivos, clientes Web, y programas, necesitan acceder a los servicios de negocio.
• Los APIs de los servicios de negocio podrían cambiar según evolucionan los requerimientos del negocio.

Es deseable miniminar el acoplamiento entre los clientes de la capa de presentación y los servicios de negocio, y así ocultar los detalles de la implementación del servicio.

• Los clientes podrían necesitar implementar mecanismos de caché para la información del servicio de negocio.
• Es deseable reducir el tráfico de red entre el cliente y los servicios de negocio.

Solución

Utilizamos un Business Delegate para reducir el acoplamiento entre los clientes de la capa de presentación y los servicios de negocio. El Business Delegate oculta los detalles de la implementación del servicio de negocio, como los detalles de búsqueda y acceso de la arquitectura EJB.

El Business Delegate actúa como una abstracción de negocio del lado del cliente; proporciona una abstracción para la implementación de los servicios del negocio. Utilizando Business Delegate se reduce el acoplamiento entre los clientes de la capa de presentación y los servicios de negocio del sistema. Dependiendo de la estrategia de implementación, Business Delegate podría aislar a los clientes de la posible volatilidad en la implementación del API de los servicios de negocio. Potencialmente, esto reduce el número de cambios que se deben hacer en el código de cliente de la capa de presentación cuando cambie el API del servicio de negocio o su implementación subyacente.

Sin embargo, los métodos de interface en el Business Delegate aún podría requerir modificaciones si cambia el API del servicio de negocio. Si bien es cierto, que los cambios se harán con más probabilidad en el servicio de negocio que en el Business Delegate.

El Business Delegate también maneja las excepciones de los servicios de negocio, como excepciones java.rmi.Remote, excepciones Java Messages Service (JMS), etc. El Business Delegate podría interceptar dichas excepciones a nivel de servicio y generar en su lugar excepciones a nivel de aplicación. Las excepciones de nivel de aplicacion son fáciles de manejar por los clientes, y pueden ser amigables para el usuario.

El Business Delegate también podría realizar de forma transparene cualquier operación de reintento o de recuperación necesaria en el caso de un fallo en el servicio no exponer el cliente al problema hasta que se haya determinado que el problema no es solucionable. Estas ganancias representan una razón competitiva para utilizar el patrón.

Otro beneficio es que el delegado podría almacenar resultados y referencias a servicios de negocio remotos. El Caché puede mejorar el rendimiento de forma significativa, porque limita los innecesarios y potencialmente costosos viajes por la red.

Implementación y Participantes

A continuación el diagrama de secuencia

SecuenciaBusinessDelegate.jpg

• BusinessDelegate: El rol de BusinessDelegate es proporcionar control y protección para el servicio de negocio. BusinessDelegate puede exponer dos tipos de constructores al cliente. Un tipo de petición ejemplariza el BusinessDelegate sin una ID, mientras que el otro lo inicializa con un ID, donde ID es una versión String de la referencia al objeto remoto como un EJBHome o un EJBObject. Cuando se inicializa sin una ID, el BusinessDelegate solicita el servicio al Lookup Service, normalmente implementado como un Service Locator, que devuelve el Service Factory, como un EJBHome. El BusinessDelegate pide que el Service Factory localice, cree o elimine un BusinessService, como un bean enterprise. Cuando se inicializa con un ID, el BusinessDelegate usa el ID para reconectar con el BusinessService. Así, el BusinessDelegate aisla al cliente de los detalles de la implementación del BusinessService de nombrado y búsqueda. Además, el cliente de la capa de presentación nunca hace llamadas remotas directas sobre un BusinessSession; en su lugar, el cliente utiliza el BusinessDelegate.
• LookupService: BusinessDelegate utiliza el objeto LookupService para localizar a BusinessService. LookupService encapsula los detalles de la implementación de la búsqueda de BusinessService.
• BusinessService: BusinessService es un componente de la capa de negocio, como un bean enterprise o un componente JMS, que proprociona el servicio requerido por el cliente