PATRÓN VIEW HANDLER

CONTEXTO

Un sistema de software que provee vistas múltiples de aplicaciones de datos específicos, o que soporta el trabajo con múltiples documentos.

PROBLEMA

Los sistemas de software que soportan vistas múltiples necesitan  funcionalidad adicional para su manejo. Los usuarios desean poder abrir, manipular y disponer de vistas como ventanas y otros contenidos a su conveniencia. Las vistas deben ser coordinadas, para que la actualización de una de ellas sea propagada automáticamente a las vistas de relación.  Distintas fuerzas manejan la solución a este problema:

El manejo de vistas múltiples debe ser fácil desde la perspectiva del usuario, y también para los componentes del cliente sin el sistema.

Las implementaciones de vistas individuales no deben depender las unas de las otras o ser mezcladas con el código usado para el manejo de vistas.

La implementación de las vistas puede variar y tipos adicionales de vistas pueden ser agregados durante el tiempo de vida del sistema.

SOLUCIÓN

Un componente VH maneja todas las vistas que el sistema de software provee. Ofrece la funcionalidad necesaria para abrir, coordinar y cerrar vistas específicas, también para manejarlas; un comando para “tile” las vistas, esto es ordenarlas en un patrón ordenado.

ESTRUCTURA

El VH es el componente central de este patrón. Es responsable de abrir vistas nuevas y los clientes pueden especificar la vista que desean. El VH inicia instantáneamente los correspondientes componentes de vista, cuida su correcta inicialización y pide a la nueva vista que se despliegue.

También ofrece funciones para cerrar vistas, individualmente abiertas, tal como se necesitan al cerrar la aplicación. La principal responsabilidad del VH es, sin embargo ofrecer servicios de manejo de vistas. Una responsabilidad adicional del VH es la coordinación.

Un componente de vista abstracto define una interfaz que es común para todas las vistas. El VH usa esta interfaz para crear, coordinar y cerrar vistas. La plataforma subyacente al sistema usa la interfaz para ejecutar eventos de usuario; el cambio de tamaño de una ventana. La interfaz de la vista abstracta debe ofrecer una función correspondiente para todas las operaciones posibles que se pueden ejecutar en una vista.
Los componentes de vista específicos se derivan de la vista abstracta e implementan su interfaz además, cada vista implementa su propia función de desplegado.

Creación de una vista nueva

Organiza el apilamiento de vistas

CONSECUENCIAS

Beneficios

• Manejo uniforme de las vistas.
• Extensibilidad y cambiabilidad de las vistas.
• Coordinación de vistas de aplicación especifica.

El patrón VH tiene desventajas

• Aplicabilidad restringida.
• Eficiencia.

PATRÓN VALUE LIST HANDLER

CONTEXTO

El cliente le pide al servicio una lista de ítems para su presentación. El número de ítems de la lista no se conoce y puede ser muy grande en muchas circunstancias.

PROBLEMA

La mayoría de las aplicaciones de la plataforma J2EE tienen un requerimiento de búsqueda y consulta para buscar y listar ciertos datos. En algunos casos, dichas operaciones de búsqueda y consulta podrían traer resultados que pueden ser bastante grandes. No es práctico devolver toda la hoja de resultados cuando los requerimientos del cliente son moverse por los resultados, en vez de procesar el conjunto completo. Normalmente, un cliente usa los resultados de una consulta para propósitos de sólo-lectura, como mostrar una lista de resultados. Muchas veces el cliente sólo ve los primeros registros que devuelve la búsqueda, y podría descargar los registros restantes e intentar otra nueva consulta. La práctica de obtener uns lista de valores representados en un bean de entidad llamando al método ejbFind(), que devuelve una collection de objetos remotos, y luego llamar a cada bean de entidad para obtener el valor, consume muchos recursos de red y se considera una mala práctica.

Hay algunas consecuencias asociadas con el uso de los métodos búscadores de EJB que resultan en grandes conjuntos de datos. Cada implementación de contenedor tiene una cierta cantidad de métodos búscadores para crear una colección de referencias EJBObject. El rendimiento del método de búsqueda varía, dependiendo de la implementación del contenedor. De acuerdo a la especificación EJB, un contenedor podría invocar a métodos ejbActivate() sobre entidades encontradas con los métodos de búsqueda. Como mínimo, un método de búsqueda devuelve las claves primarias de las entidades encontradas, que el contenedor devuelve al cliente como una colección de referencias EJBObject. Este comportamiento se aplica para todas las implementaciones de contenedores. Algunas implementaciones podrían introducir una sobrecarga de métodos de búsqueda asociando los ejemplares de beans de entidad a esos ejemplares EJBObject para darle acceso al cliente a esos beans de entidad. Sin embargo, este es un uso pobre de los recursos si el cliente no está interesado en acceder al bean o en invocar sus métodos. Esta sobrecarga puede impedir el rendimiento de la aplicación si ésta incluye consultas que producen muchos resultados.

CAUSAS

• La aplicación cliente necesita una facilidad de consulta eficiente para evitar tener que llamar al método ejbFind() de cada bean e invocar a cada objeto remoto devuelto.
• Se necesita una mecanismo de caché en la capa-servidor para servir a los clientes que no pueden recibir y procesar el cojunto de resultados completo.
• Se puede optimizar una consulta que se ejecuta repetidamente sobre unos datos razonablemente estáticos para proporcionar resultados más rápidos. 
• Los métodos de búsqueda EJB no son apropiados para navegar por tablas enteras en la bases de datos o para buscar grandes conjuntos de resultados en una tabla.
• Los métodos de búsqueda se podrían considerar sobrecargados cuando se utilizan para encontrar grandes cantidades de resultados. 
• Los métodos de búsqueda EJB no sin apropiados para realizar caché de resultados. El cliente podría no ser capaz de manejar el conjunto completo de resultados en una sóla llamada. 
• Los métodos de búsqueda EJB tiene consultas predeterminadas y ofrecen una flexibilidad mínima. 
• El cliente quiere moverse hacia adelante o hacia atrás dentro de la hoja de resultados.

SOLUCIÓN

Utilizar un Value List Handler para controlar la búsqueda, hacer un caché con los resultados, y proporcionar los resultados al cliente en una hoja de resultados cuyo tamaño y desplazamiento cumpla los requerimientos del cliente.

Este patrón crea un ValueListHandler para controlar la funcionalidad de la ejecución de la consulta y el caché de resultados. El ValueListHandler accede directamente a un DAO que puede ejecutar la consulta requerida. El ValueListHandler almacena los resultados obtenidos del DAO como una colección de Transfer Objects. El cliente le pide al ValueListHandler que proporcione resultados de la consulta según los necesite. El ValueListHandler implementa un patrón Iterator [GoF] para proporcionar la solución.

ESTRUCTURA

La siguiente figura muestra el diagrama de clases para el patrón Value List Handler:

PARTICIPANTES Y COLABORACIONES
La siguiente figura muestra el diagrama de secuencia del patrón Value List Handler:

ValueListIterator- Este interface podría proporcionar la facilidad de iteración con los siguientes métodos de ejemplo:

• getSize() obtiene el tamaño de la hoja de resultados.
• getCurrentElement() obtiene el Transfer Object actual de la lista.
• getPreviousElements(int howMany) obtiene una colección de Transfer Objects que son anteriores en la lista al elemento actual.
• getNextElements(int howMany) obtiene una colección de Transfer Objects que son posteriores en la lista al elemento actual.
• resetIndex() reinicia el índice para ir al inicio de la lista.

Dependiendo de las necesidades, se pueden incluir otros métodos de conveniencia en el interface ValueListIterator.

ValueListHandler- Este es el objeto que implementa el interface ValueListIterator. ValueListHandler ejecuta la consulta requerida cuando se lo solicita el cliente. Obtiene los resultados de la consulta, que maneja en una colección privada representada por el objeto ValueList. ValueListHandler crea y manipula la colección ValueList.

DataAccessObject- ValueListHandler puede hacer uso de un DataAccessObject para mantener separada la implementación del acceso a la base de datos. DataAccessObject proporciona un API sencillo para acceder a la base de datos (o cualquier otro almacenamiento persistente), ejecuta consultas y recupera resultados.

ValueList- ValueList es una colección (una lista) que contiene los resultados de la consulta. Los resultados se almacenan como objetos Transfer Objects. Si falla la consulta y no se devuelven resultados, entonces esta lista está vacía. El bean de sesión ValueListHandler puede almacenar ValueList para evitar repeticiones innecesarias de la consulta.

TransferObject- TransferObject representa una vista de un registro individual de los resultados de la consulta. Es un objeto serializable no modificable que proporciona un espacio para los datos de los atributos de cada registro.

CONSECUENCIAS

• Proporciona Alternativas a los métodos find() de EJB para Grandes Consultas 
• Crea un Caché de Resultados de la Consulta en el Lado del Servidor 
• Proporciona una Mayor Flexibilidad de Consulta 
• Mejora el Rendimiento de Red 
• Permite Atrasar las Transacciones del Bean de Entidad 

PATRÓN TRANSFER OBJECT

CONTEXTO

Las aplicaciones cliente necesitan intercambiar datos con Beans Enterprise.

PROBLEMA

Las aplicaciones de la plataforma J2EE implementan componentes de negocio del lado del servidor como beans de sesión y de entidad. Algunos métodos expuestos por los componentes de negocio devuelven datos al cliente. Algunas veces, el cliente invoca a los métodos get de un objeto de negocio varias veces para obtener todos los valores de los atributos.

Los beans de sesión representan los servicios de negocio y no se comparten entre usuarios. Un bean de sesión proporciona métodos de servicios genéricos cuando se implementan para el patrón Session Facade.

Por otro lado, los beans de entidad, son objetos transaccionales, multiusuario que representan datos persistentes. Un bean de entidad expone los valores de los atributos proporcionando un método accesor (también referidos como métodos get) por cada atributo que desea exponer.

CAUSAS

• Todos los accesos a un bean enterprise se realizan mediante interfaces remotos. 
• Normalmente, las aplicaciones tienen transacciones de lectura con mayor frecuencia que las de actualización. 
• El cliente normalmente solicita valores que son algo más que un atributo o que son dependientes del objeto de un bean enterprise. 
• El número de llamadas que un cliente hace al bean enterprise impactan en el rendimiento de la red. 

SOLUCIÓN

Utilizar un Transfer Object para encapsular los datos de negocio. Se utiliza una única llamada a un método para envíar y recuperar el Transfer Object. Cuando el cliente solicita los datos de negocio al bean enterprise, éste puede construir el Transfer Object, rellenarlo con sus valores de atributos y pasarlo por valor al cliente.

Los clientes normalmente solicitan más de un valor a un bean enterprise. Para reducir el número de llamadas remotas y evitar la sobrecarga asociada, es mejor el Transfer Objects para transportar los datos desde el bean enteprise al cliente.

Cuando un bean enterprise utiliza un Transfer Object, el cliente hace una sola llamada a un método remoto del bean enterprise para solicitar el Transfer Object en vez de numerosas llamadas remotas para obtener valores de atributos individuales. Entonces el bean enterprise construye un nuevo ejemplar Transfer Object, copia dentro los valores del objeto y lo devuelve al cliente. El cliente recibe el Transfer Object y puede entonces invocar los métodos accesores (o get) del Transfer Object para obtener los valores de atributos individuales del objeto Transfer Object.

ESTRUCTURA
La siguiente figura muestra el diagrama de clases que representa el patrón Transfer Object en su forma más simple:

Como se ve en este diagrama de clases, el Transfer Object lo construye bajo pedido el bean enterprise y lo devuelve al cliente remoto. Sin embargo, el patrón Transfer Object puede adoptar varias estrategias, dependiendo de los requerimientos.

PARTICIPANTES Y RESPONSABILIDADES
La siguiente figura contiene el diagrama de secuencia que muestra las interacciones del patrón Transfer Object:

 

Client- Representa al cliente del bean enterprise. El cliente puede ser una aplicación final de usuario, como es el caso de una aplicación que ha sido diseñada para acceder directamente a beans enterprise. El cliente puede utilizar Business Delegate u otro BusinessObject diferente.

BusinessObject- Representa un rol en este patrón que puede cumplir un bean de sesión, un bean de entidad, o un Data Access Object (DAO). BusinessObject es el responsable de crear el Transfer Object y devolverlo al cliente bajo pedido. El BusinessObject también podría recibir datos desde el cliente en la forma de un Transfer Object y utilizar esos datos para realizar una actualización.

TransferObject- TransferObject es un objeto Java serializable referenciado como un Transfer Object. Una clase Transfer Object podría proporcionar un constructor que acepte todos los atributos requeridos para crear el Transfer Object.

CONSECUENCIAS

• Simplifica el Bean de Entidad y el Interface Remoto 
• Transfiere Más Datos en Menos Llamadas Remotas 
• Reduce el Tráfico de Red 
• Reduce la Duplicación de Código
• Podría Introducir Transfer Objects Obsoletos 
• Podría Incrementar la Complejidad Debido a la Sincronización y el Control de Versión 
• Accesos y Transacciones Concurrentes 

PATRÓN SERVICE LOCATOR

CONTEXTO

La búsqueda y creación de servicios implican interfaces complejos y operaciones de red.

PROBLEMA

Los clientes J2EE interactúan con componentes de servicio, como componentes JavaBeans Enterprise (EJB) y Java Message Service (JMS), que proporcionan servicios de negocio y capacidades de persistencia. Para interactúar con estos componentes, los clientes deben o lcalizar el componente de servicio (referido como una operación de búsqueda) o crear un nuevo componente. Por ejemplo, un cliente EJB debe localizar el objeto home del bean enterprise, que el cliente puede utilizar para encontrar un objeto o para crear uno o más beans enterprise. De forma similar, un cliente JMS primero debe localizar la Factoría de Conexiones JMS para obtener una Conexión JMS o una Sesión JMS.

Todos los clientes de aplicaciones J2EE utilizan la facilidad JNDI para buscar y crear componentes EJB o JMS. El API JNDI permite a los clientes obtener un objeto Contexto Inicial que contiene el nombre del componente a uniones de objetos. El cliente empieza obteniendo el contexto inicial para un objeto home de un bean. El contexto inicial permanece válido mientras sea válida la sesión del cliente. El cliente proporciona el nombre registrado en JNDI del objeto requerido para obtener una referencia a un objeto administrado. En el contexto de una aplicación EJB, un objeto administrado típico es un objeto home de un bean enterprise. Para aplicaciones JMS, el objeto administrado puede ser una Factoría de Conexiones JMS (para un Topic o una Queue) o un Destino JMS (un Topic o una Queue).

CAUSAS

• Los clientes EJB necesitan utilizar el API JNDI para buscar objetos EJBHome utilizando el nombre registrado del bean enterprise.
• Los clientes JMS necesitan utilizar el API JNDI para buscar componentes JMS utilizando los nombres registrados en JDNI para esos componentes JMS.
• La factoría de contextos utilizada para la creación del contexto inicial JNDI la proporciona el vendedor del proveedor del servicio y por lo tanto es dependiente del vendedor. 
• La búsqueda y creación de componentes de servicio podría ser compleja y se podría utilizar repetidamente en múltiples clientes en la aplicación.
• La creación del contexto inicial y el servicio de búsqueda de objetos, si se utiliza frecuentemente, puede consumir muchos recursos e impactar en el rendimiento de la aplicación. 
• Los clientes EJB podrían necesitar reestablecer conexiones a un ejemplar de bean enterprise al que se ha accedido préviamente, teniendo solamente su objeto Handle.

SOLUCIÓN

Utilizar un objeto Service Locator para abstraer toda la utilización JNDI y para ocultar las complejidades de la creación del contexto inicial, de busqueda de objetos home EJB y de re-creación de objetos EJB. Varios clientes pueden reutilizar el objeto Service Locator para reducir la complejidad del código, proporcionando un punto de control, y mejorando el rendimiento proporcionando facilidades de caché.

Este patrón reduce la complejidad del cliente que resulta de las dependencias del cliente y de la necesidad de realizar los procesos de búsqueda y creación, que consumen muchos recursos. Para eliminar estos problemas, este patrón proporciona un mecanismo para abstraer todas las dependencias y detalles de red dentro del Service Locator.

ESTRUCTURA

La siguiente figura muestra el diagrama de clases que representa las relaciones para el patrón Service Locator.

PARTICIPANTES Y RESPONSABILIDADES
La siguiente figura contiene el diagrama de secuencia que muestra la interacción entre los distintos participantes en el patrón Service Locator.

Client- Este es el cliente del Service Locator. El cliente es un objeto que normalmente requiere acceder a objetos de negocio como un Business Delegate.

Service Locator- El Service Locator abstrae el API de los servicios de búsqueda (nombrado), las dependencias del vendedor, las complejidades de la búsqueda, y la creación de objetos de negocio, y proporciona un interface simple para los clientes. Esto reduce la complejidad del cliente. Además, el mismo cliente y otros clientes pueden reutilizar el Service Locator.

InitialContext- El objeto InitialContext es el punto de inicio para los procesos de búsqueda y creación. Los proveedores de servicio proporcionan el objeto context, que varía dependiendeo del tipo de objetos de negocio proporcionados por el servicio de búsqueda y creación del Service Locator.

ServiceFactory- El objeto ServiceFactory representa un objeto que proporciona control del ciclo de vida para objetos BusinessService. El objeto ServiceFactory para beans enterprise es un objeto EJBHome. El ServiceFactory para componentes JMS puede ser un objeto ConnectionFactory, como un TopicConnectionFactory o un QueueConnectionFactory.

BusinessService- BusinessService es un rol que cumple el servicio que el cliente ha solicitado. El objeto BusinessService se crea, se busca o se elimina mediante el objeto ServiceFactory. El objeto BusinessService en el contexto de una aplicación EJB es un bean enterprise. El objeto BusinessService en el contexto de una aplicación JMS puede ser un TopicConnection o un QueueConnection. TopicConnection y QueueConnection se pueden entonces utilizar para producir un objeto JMSSession, como un TopicSession o un QueueSession respectivamente.

CONSECUENCIAS

• Abstrae la Complejidad 
• Proporciona a los Clientes un Acceso Uniforme a los Servicios 
• Facilita la Adicción de Nuevos Componentes de Negocio 
• Mejora el Rendimiento de la Red 
• Mejora el Rendimiento del Cliente mediante el Caché 

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

PATRÓN MODEL VIEW CONTROLLER (MVC)

Es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos.

El patrón de llamada y retorno MVC (según CMU), se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista.

DESCRIPCIÓN DEL PATRÓN MVC

• Modelo: Esta es la representación específica de la información con la cual el sistema opera. En resumen, el modelo se limita a lo relativo de la vista y su controlador facilitando las presentaciones visuales complejas. El sistema también puede operar con más datos no relativos a la presentación, haciendo uso integrado de otras lógicas de negocio y de datos afines con el sistema modelado.

• Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario.

• Controlador: Este responde a eventos, usualmente acciones del usuario, e invoca peticiones al modelo y, probablemente, a la vista.

Muchos de los sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos: en líneas generales del MVC corresponde al modelo. La unión entre capa de presentación y capa de negocio conocido en el paradigma de la Programación por capas representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio y capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí.

PATRÓN INTERCEPTING FILTER

CONTEXTO

El mecanismo de manejo de peticiones de la capa de presentación recibe muchos tipos diferentes de peticiones, cada uno de los cuales requiere varios tipos de procesamiento. Algunas peticiones simplemente requieren su reenvio al componente manejador apropiado, mientras que otras peticiones deben ser modificadas, auditadas, o descomprimidas antes de su procesamiento posterior.

PROBLEMA

Se requiere un pre-procesamiento y un post-procesamiento de unas peticiones o respuestas de un cliente Web.

Cuando una petición entra a una aplicación Web, normalmente debe pasar varios test de entrada antes del estado de procesamiento principal. Por ejemplo,

¿Se ha autentificado el cliente?

¿Tiene el cliente una sesión válida?

¿La dirección IP del cliente es de una red conocida?

¿Viola alguna restricción el path de la petición?

¿Qué codificación usa el cliente para enviar los datos?

¿Soportamos el tipo de navegador del cliente?

Algunos de estos chequeos son tests, que resultan en una respuesta de si o no que determina si continuará el procesamiento. Otros chequeos manipulan el stream de datos entrantes a una forma aceptable para el procesamiento.

La solución básica consiste en un serie de chequeos condicionales, si cualquiera de ellos falla la petición se aborta. Las sentencias if/else anidadas son una estrategia estándar, pero esta solución tiene fragilidad de código y un estilo de programación de copiar-y-pegar, porque el flujo del filtrado y la acción de los filtros se compila dentro de la aplicación.

La clave para solventar este problema de una forma flexible y no obstrusiva es tener un mecanismo simple para añadir y eliminar componentes de procesamiento, en el que cada componente completa una acción de filtrado específica.

CAUSAS

• Procesamiento común, como un chequeo del esquema de codificación de datos o la información de login de cada petición, completo por cada petición.
• Se desea la centralización de la lógica común.
• Se debería facilitar la adición o eliminación de sevicios sin afectar a los componentes existentes, para que se puedan utilizar en gran variedad de combinaciones, como
• Logging y autentificación.
• Depuración y transformación de la salida para un cliente específico
• Descomprensión y conversión del esquema de codificación de la entrada.

SOLUCIÓN
Crear filtros conectables para procesar servicios comunes de una forma estándar sin requerir cambios en el código principal del procesamiento de la petición. Los filtros interceptan las peticiones entrantes y las respuestas salientes, permitiendo un pre y post-procesamiento. Podemos añadir y eliminar estos filtros a discreción, sin necesitar cambios en nuestro código existente.
Podemos, en efecto, decorar nuestro procesamiento principal con una variedad de servicios comunes, como la seguridad, el logging, el depurado, etc. Estos filtros son componentes independientes del código de la aplicación principal, y pueden añadirse o eliminarse de forma declarativa. Por ejemplo, se podría modificar un fichero de configuración de despliegue para configurar una cadena de filtros. Cuando un cliente pide un recurso que corresponde con este mapeo de URL configurado, se procesa cada filtro de la cadena antes de poder invocar el recurso objetivo.

ESTRUCTURA
La siguiente figura representa el diagrama de clases del patrón Intercepting Filter.

PARTICIPANTES Y RESPONSABILIDADES
La siguiente figura representa el diagrama de la secuencia del patrón Intercepting Filter.

FilterManager- El FilterManager maneja el procesamiento de filtros. Crea el FilterChain con los filtros apropiados, en el orden correcto e inicia el procesamiento.

FilterChain- El FilterChain es una collection ordenada de filtros independientes.

FilterOne, FilterTwo, FilterThree- Estos son los filtros individuales que son mapeados a un objetivo. El FilterChain coordina su procesamiento.

Target- El Target es el recurso que el cliente ha solicitado.

CONSECUENCIAS

• Centraliza el Control con Controladores de Acoplamiento Ligero 
• Mejora la Reutilización 
• Configuración Declarativa y Flexible 
• La Compartición Información es Ineficiente 

PATRÓN FRONT CONTROLLER

CONTEXTO

El mecanismo de manejo de peticiones de la capa de presentación debe controlar y coordinar el procesamiento de todos los usuarios a través de varias peticiones. Dichos mecanismos de control se pueden manejar de una forma centralizada o descentralizada.

PROBLEMA

El sistema requiere un punto de acceso centralizado para que el manejo de peticiones de la capa de presentación soporte la integración de los servicios del sistema, recuperación de contenidos, control de vistas, y navegación. Cuando el usuario accede a la vista directamente sin pasar un mecanismo centralizado, podrían ocurrir dos problemas:

Se requiere que cada vista proporcione sus propios servicios del sistema, lo que normalmente resulta en duplicación de código.

La vista de navegación se deja a los visores. Esto podría resultar en una mezcla de contenidos y navegación.

Además, el control distribuido es más difícil de mantener, ya que los cambios se tienen que realizar en numerosos lugares.

CAUSAS

• El procesamiento de servicios del sistema comunes se completa por cada petición. Por ejemplo, el servicio de seguridad completa los chequeos de autentificación y autorización.
• La lógica se maneja mejor en una localización central en lugar de estar replicada dentro de varias vistas.
• Existen puntos de decisión con respecto a la recuperación y manipulación de los datos.
• Se utilizan varias vistas para responder a peticiones de negocio similares.
• Puede ser muy útil un punto de contacto centralizado para manejar una petición, por ejemplo, para controlar y grabar el camino de un usuario por la site.
• Los servicios del sistema y la lógica de control de vistas son relativamente sofisticados.

SOLUCIÓN

Usar un controlador como el punto inicial de contacto para manejar las peticiones. El controlador maneja el control de peticiones, incluyendo la invocación de los servicios de seguridad como la autentificación y autorización, delegar el procesamiento de negocio, controlar la elección de una vista apropiada, el manejo de errores, y el control de la selección de estrategias de creación de contenido.

El controlador proporciona un punto de entrada centralizado que controla y maneja las peticiones Web. Centralizando los puntos de decisión y control, el controlador también ayuda a reducir la cantidad de código Java, llamadas a scriptles, embebidos en la página JavaServer Pages (JSP).

Centralizar el control en el controlador y reduciendo la lógica de negocios en la vista permite reutilizar el código entre peticiones. Es una aproximación preferible a la alternativa de embeber código en varias vistas porque esta aproximación trata con entornos más propensos a errores, y de reutilización del tipo copiar-y-pegar.

Aunque el patrón Front Controller sugiere la centralización del manejo de peticiones, no limita el número de manejadores en el sistema, como lo hace Singleton. Una aplicación podría utilizar varios controladores en un sistema, cada uno mapeado a un conjunto de servicios distintos.

ESTRUCTURA

La siguiente figura representa el diagrama de clases del patrón Front Controller.

PARTICIPANTES Y RESPONSABILIDADES
La siguiente figura representa el diagrama de la secuencia del patrón Front Controller. Muestra como el controlador maneja una petición:

Controller- El controlador es el punto de contacto inicial para manejar todas las peticiones en el sistema. El controlador podría delegar a un helper para completar la autentificación y la autorización de un usuario o para iniciar la recuperación de un contacto.

Dispatcher- Un dispatcher es el responsable del manejo de la vista y de la navegación, controlando la elección de la siguiente vista que se le presentará al usuario, y proporcionando el mecanismo para dirigir el control a ese recurso.

Un dispatcher se puede encapsular dentro de un controlador o se puede separar en otro componente que trabaja de forma coordinada. El dispatcher puede proporcionar un re-envío estático de la vista o un mecanismo de re-envío más sofisticado.

El dispatcher utiliza un objeto RequestDispatcher (soportado en la especificación Servlet) y encapsula algún procesamiento adicional.

Helper- Un helper es el responsable de ayudar a la vista o al controlador a completar su procesamiento. Así, los helpers tienen muchas responsabilidades, incluyendo la recopilación de los datos requeridos por la vista y el almacenamiento en el modelo intermedio, en cuyo caso algunas veces nos podemos referir al helper como un bean de valor. Además, los helpers pueden adaptar este modelo de datos para usarlo en la vista.

Una vista podría trabajar con cualquier número de helpers, que normalmente son componentes JavaBeans (JSP 1.0+) y etiquetas personalizadas (JSP 1.1+). Además, un helper podría representar un objeto Command o un Transformador XSL, que se utiliza en combinación con una hoja de estilos para adaptar y convertir el modelo a la forma apropiada.

View- Una Vista representa y muestra información al cliente. La vista recupera información desde el modelo. Los helpers soportan las diferentes vistas encapsulando y adaptanto el modelo de datos subyacente para usarlo en el display.

CONSECUENCIAS

• Centraliza el Control 
• Mejora la Manejabilidad de la Seguridad 
• Mejora la Reutilizabilidad

PATRÓN FAST-LANE RADER

CONTEXTO

Implementar eficientemente casos de uso que corresponden a  búsquedas que devuelven una colección de objetos. También conocido como JDBC for Reading

ESTRUCTURA

PARTICIPANTES

Business Delegate- Delega las operaciones de búsqueda múltiple en un Session Facade (que usa un DAO) o directamente en un DAO.

SessionFacade- Un Session Bean que implementa las operaciones de búsqueda múltiple delegando en un DAO.

DAO- Proporciona las operaciones de búsqueda accediendo directamente a la BD

CONSECUENCIAS

• Beneficios- Alternativa más eficientes que operaciones findXXX en interfaces. Home que devuelven múltiples Entity Beans
• Riesgos- Información obsoleta (Idem Value Object)

PATRÓN DATA ACCESS OBJECT

CONTEXTO

El acceso a los datos varía dependiendo de la fuente de los datos. El acceso al almacenamiento persistente, como una base de datos, varía en gran medida dependiendo del tipo de almacenamiento (bases de datos relacionales, bases de datos orientadas a objetos, ficheros planos, etc.) y de la implementación del vendedor.

PROBLEMA

Muchas aplicaciones de la plataforma J2EE en el mundo real necesitan utilizar datos persistentes en algún momento. Para muchas de ellas, este almacenamiento persistente se implementa utilizando diferentes mecanismos, y hay marcadas diferencias en los APIS utilizados para acceder a esos mecanismos de almacenamiento diferentes. Otras aplicaciones podrían necesitar acceder a datos que residen en sistemas diferentes. Por ejemplo, los datos podrían residir en sitemas mainframe, repositorios LDAP, etc. Otro ejemplo es donde los datos los proporcionan servicios a través de sistemas externos como los sistemas de integración negocio-a-negocio (B2B), servicios de tarjetas de crédito, etc.

Normalmente, las aplicaciones utilizan componentes distribuidos y compartidos como los beans de entidad para representar los datos persistentes. Se considera que una aplicación emplea consistencia manejada por el bean (BMP) cuando sus beans de entidad acceden explícitamente al almacenamiento persistente -- el bean de entidad incluye código para hacer esto. Una aplicación con requerimientos sencillos podría por lo tanto utilizar beans de entidad en lugar de beans de sesión o servlets para acceder al almacenamiento persistente y recuperar o modificar los datos. O, la aplicación podría usar beans de entidad con persistencia manejada por el contenedor, y así dejar que el contenedor maneje los detalles de las transacciones y de la persistencia.

Las aplicaciones pueden utilizar el API JDBC para acceder a los datos en un sistema de control de bases de datos relacionales (RDBMS). Este API permite una forma estándar de acceder y manipular datos en un almacenamiento persistente, como una base de datos relacional. El API JDBC permite a las aplicaciones J2EE utilizar sentencias SQL, que son el método estándar para acceder a tablas RDBMS. Sin embargo, incluso dentro de un entorno RDBMS, la sintaxis y formatos actuales de las sentencias SQL podrían variar dependiendo de la propia base de datos en particular.

CAUSAS

• Los componentes como los beans de entidad controlados por el bean, los beans de sesión, los servlets, y otros objetos como beans de apoyo para páginas JSP necesitan recuperar y almacenar información desde almacenamientos persistentes y otras fuentes de datos como sistemas legales, B2B, LDAP, etc.
• Los APIs para almacenamiento persistente varían dependiendo del vendedor del producto.
• Los componentes normalmente utilizan APIs propietarios para acceder a sistemas externos y/o legales para recuperar y almacenar datos.
• La portabilidad de los componentes se ve afectada directamente cuando se incluyen APIs y mecanismos de acceso específicos.
• Los componentes necesitan ser transparentes al almacenamiento persistente real o la implementación de la fuente de datos para proporcionar una migración sencilla a diferentes productos, diferentes tipos de almacenamiento y diferentes tipos de fuentes de datos.

SOLUCIÓN

Utilizar un Data Access Object (DAO) para abstraer y encapsular todos los accesos a la fuente de datos. El DAO maneja la conexión con la fuente de datos para obtener y almacenar datos.

El DAO implementa el mecanismo de acceso requerido para trabajar con la fuente de datos. Esta fuente de datos puede ser un almacenamiento persistente como una RDMBS, un servicio externo como un intercambio B2B, un repositorio LDAP, o un servicio de negocios al que se accede mediante CORBA Internet Inter-ORB Protocol (IIOP) o sockets de bajo nivel. Los componentes de negocio que tratan con el DAO utilizan un interface simple expuesto por el DAO para sus clientes. El DAO oculta completamente los detalles de implementación de la fuente de datos a sus clientes. Como el interface expuesto por el DAO no cambia cuando cambia la implementación de la fuente de datos subyacente, este patrón permite al DAO adaptarse a diferentes esquemas de almacenamiento sin que esto afecte a sus clientes o componentes de engocio. Esencialmente, el DAO actúa como un adaptador entre el componente y la fuente de datos.

ESTRUCTURA

La siguiente figura muestra el diagrama de clases que representa las relaciones para el patrón DAO:

PARTICIPANTES Y RESPONSABILIDADES

La siguiente figura muestra el diagrama de secuencia de la interacción entre los distintos participantes en este patrón:

BusinessObject- BusinessObject representa los datos del cliente. Es el objeto que requiere el acceso a la fuente de datos para obtener y almacenar datos. Podríamos implementar un BusinessObject como un bean de sesión, un bean de entidad o cualquier otro objeto Java, además de como un Servlet o como un bean de apoyo.

DataAccessObject- DataAccessObject es el objeto principal de este patrón. DataAccessObject abstrae la implementación del acceso a datos subyacente al BusinessObject para permitirle un acceso transparente a la fuente de datos. El BusinessObject también delega las operaciones de carga y almacenamiento en el DataAccessObject.

DataSource- Representa la implementación de la fuente de datos. Una fuente de datos podría ser una base de datos como un RDBMS, un OODBMS, un repositorio XML, un fichero plano, etc. También lo pueden ser otros sitemas (mainframes/legales), servicios (servicio B2B u oficina de tarjetas de crédito), o algún tipo de repositorio (LDAP).

TransferObject- Representa un Transfer Object utilizado para el transporte de datos. DataAccessObject podría utilizar un Transfer Object para devolver los datos al cliente. El DataAccessObject también podría recibir datos desde el cliente en un Transfer Object para actualizar los datos en la fuente de datos.

CONSECUENCIAS

• Permite la Transparencia Permite una Migración más Fácil
• Reduce la Complejidad del Código de los Objetos de Negocio
• Centraliza Todos los Accesos a Datos en un Capa Independiente
• No es útil para Persistencia Manejada por el Contenedor
• Añade una Capa Extra
• Necesita Diseñar un Árbol de Clases

PATRÓN COMPOSITE VIEW

CONTEXTO

Las páginas Web sofisticadas presentan contenido de varias fuentes de datos, utilizando varias sub-vistas que completan una sola página. Además, varios individuos con diferentes habilidades contribuyen al desarrollo y mantenimiento de esas páginas Web.

PROBLEMA

En lugar de proporcionar un mecanismo para combinar modularmente, en el que porciones atómicas de una vista componen un página completa, las páginas se construyen embebiendo código de formateo directamente dentro de cada vista.

La modificación de la distribución de múltiples vistas es difícil y propensa a errores, debido a la duplicación de código.

CAUSAS

• Las porciones atómicas del contenido de la vista cambian con frecuencia.
• Varias vistas compuestas utilizan sub-vistas similares, como una tabla de inventario de clientes. 
• Los cambios de distribución son más difíciles de manejar y el código más difícil de mantener cuando las sub-vistas se embeben directamente y se duplican en varias vistas.
• Frecuentemente, embeber las porciones cambiantes de la plantilla de texto directamente dentro de las vistas también afecta potencialmente a la disponibilidad y administración del sistema. 

SOLUCIÓN

Utilizar vistas compuestas que se componen de varias sub-vistas atómicas. Cada componente de la plantilla se podría incluir dinámicamente dentro del total y la distribución de la página se maneja independientemente del contenido.

Esta solución promueve la creación de una vista compuesta basada en la inclusión y sustitución de fragmentos de plantilla modulares tanto estáticos como dinámicos. También promueve la reutilización de porciones atómicas de la vista asegurando un diseño modular. Es apropiado utilizar este patrón para generar páginas que muestran componentes que podrían combinarse en una gran variedad de formas. Este escenario ocurre, por ejemplo, con sites de portal que incluyen numerosas sub-vistas independientes, como noticias, información del tiempo, y valores de stocks en una sóla página. La distribución de la página se maneja y modifica de forma independiente al contenido de las sub-vistas.

Otro beneficio de este patrón es que los diseñadores Web pueden hacer un prototipo de la distribución de la site, conectando contenido estático en todas las regiones de la plantilla. Según va progresando el desarrollo de la site, ese contenido estático se puede sustituir por el contenido dinámico.

Este patrón también tiene inconvenientes. Provoca una sobrecarga en el entorno de ejecución, un precio que hay que pagar por el incremento de flexibilidad que proporciona. La utilización de un mecanismo de distribución más sofisticado también trae consigo algunos problemas de manejabilidad y desarrollo, ya que hay más artefactos que mantener y un cierto nivel indirecto de implementación que entender.

ESTRUCTURA

La siguiente figura representa el diagrama de clases del patrón Composite View.

PARTICIPANTES Y RESPONSABILIDADES

La siguiente figura representa el diagrama de secuencia del patrón Composite View.

Composite View- Una vista compuesta es una vista a la que se le han agregado varias sub-vistas.

View Manager- El Controlador de Vista maneja la inclusión de porciones de fragmentos de plantilla en la vista compuesta. El Controlador de Vista podría ser parte de un motor de ejecución estándar de páginas JSP, en la forma de la etiqueta <jsp:include> de JSP, o podría encapsularse dentro de un helper JavaBean (JSP 1.0+) o una etiqueta personalizada (JSP 1.1+) para proporcionar una funcionalidad más robusta.

Included View- Una Vista Incluida es una sub-vista que es una pieza atómica de un vista completa mayor. Esta vista incluida potencialmente también podría ser una vista compuesta, incluyeno ella misma varias sub-vistas.

CONSECUENCIAS

• Mejora la Modularidad y la Reutilización 
• Mejora la Flexibilidad 
• Mejora el Mantenimiento y la Manejabilidad 
• Reduce la Manejabilidad 
• Impacto en el Rendimiento 

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

PATRÓN BUSISNESS DELEGATE

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).

CAUSAS

• 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 minimizar 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

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, y por lo tanto oculta, 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ían 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 principal beneficio es ocultar los detalles del servicio. Por ejemplo, el cliente puede ser transparente para los servicios de búsqueda y nombrado. El Business Delegate también maneja las excepciones de los servicios de negocio, como excepciones java.rmi.Remote, excepciones Java Messages Service (JMS), etc. ElBusiness 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.

Un Business Delegate utiliza un componente llamado Lookup Service. Este componente es el responsable de ocultar los detalles de implementación de código de búsqueda del servicio de negocio. El Lookup Service podría estar escrito como parte del Delegate.

Finalmente, se debería tener en cuenta que este patrón se podría utilizar para reducir el acoplamiento entre otra capas, no simplemente entre las capas de presentación y de negocio.

ESTRUCTURA

La siguiente figura muestra el diagrama de clases que representa al patrón Business Delegate.

PARTICIPANTES Y RESPONSABILIDADES

La siguiente figura muestra el diagrama de secuencia que ilustra las interacciones típicas para este patrón:

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 aísla 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 proporciona el servicio requerido por el cliente.

CONSECUENCIAS

• Reduce el Acoplamiento, Mejora la Manejabilidad
• Traduce las Excepciones del Servicio de Negocio
• Implementa Recuperación de Fallos y Sincronización de Threads
• Expone un Interface Simple y Uniforme a la Capa de Negocio
• Impacto en el Rendimiento
• Presenta una Capa Adicional
• Oculta los elementos Remotos

Clasificación de los Patrones de Diseño

-Según su propósito:

• Patrones de creación. Se refieren a la creación de instancias.
• Patrones estructurales. Se refieren a las relaciones entre clases y/u objetos.
• Patrones de comportamiento. Caracterizan la forma en que las clases u objetos interactúan y distribuyen sus responsabilidades (servicios).

-Según su ámbito:

• Patrones de clases. Tratan con relaciones de herencia (estática) entre clases.
• Patrones de objetos. Se refieren a relaciones de composición entre objetos, que pueden cambiar en tiempo de ejecución y son más dinámicas.

CATÁLOGO DE GAMMA

¿Qué es un patrón de diseño?

Según Christopher  Alexander, “Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, así como la solución del problema, de tal modo que se pueda aplicar esta solución un millón de veces.”

Gamma, “Un patrón de diseño es una descripción de clases y objetos comunicándose entre sí, adaptada para resolver un problema de diseño general en un contexto particular.”

En general un patrón tiene cuatro elementos esenciales:

• El nombre del patrón: permite describir, en una o dos palabras, un problema de diseño con sus soluciones y consecuencias.
• El problema: describe cuando aplicar el patrón. Explica el problema y su contexto.
• La solución: describe los elementos que constituyen el diseño, sus relaciones, responsabilidades y colaboraciones. La solución no describe un diseño o una implementación en concreto, sino que un patrón es más bien como una plantilla que puede aplicarse en muchas situaciones diferentes.
• Las consecuencias: son los resultados así como las ventajas e inconvenientes de aplicar el patrón.