PATRONES DE DISEÑO

DAO (DATA ACCESS OBJECT)

Es utilizado para crear una capa de persistencia. DAO encapsula el acceso a la base de datos. Por lo que cuando la capa de lógica de negocio necesite interactuar con la base de datos, va a hacerlo a través de la API que le ofrece DAO. Generalmente esta API consiste en métodos CRUD (Créate, Read, Update y Delete).

Entonces por ejemplo cuando la capa de lógica de negocio necesite guardar un dato en la base de datos, va a llamar a un método créate (). Lo que haga este método, es problema de DAO y depende de cómo DAO implemente el método créate (), puede que lo implemente de manera que los datos se almacenen en una base de datos relacional como puede que lo implemente de manera que los datos se almacenen en ficheros de texto. Lo importante es que la capa de lógica de negocio no tiene porque saberlo, lo único que sabe es que el método créate () va a guardar los datos, así como el método delete () va a eliminarlos, el método update() actualizarlos, etc. Pero no tiene idea de cómo interactúa DAO con la base de datos.

Los DTO (Data Transfer Object) o también denominados VO (Value Object). Son utilizados por DAO para transportar los datos desde la base de datos hacia la capa de lógica de negocio y viceversa. Por ejemplo, cuando la capa de lógica de negocio llama al método créate (), ¿qué es lo que hace DAO? inserta un nuevo dato ¿pero qué dato? el que la capa de lógica de negocio le pase como parámetro ¿y cómo se lo pasa este dato? bueno, a través de un DTO.

DAO oculta completamente los detalles del origen de datos de la aplicación hacia sus clientes. Debido a que la interfaz expuesta por el DAO a los clientes no cambia cuando los datos subyacentes cambian su implementación de código, este modelo permite al DAO adaptarse a los sistemas de almacenamiento sin que ello afecte a sus clientes o componentes de negocio. Esencialmente, DAO actúa como un adaptador entre el componente y la fuente de datos.

  

·         BusinessObject: Es el objeto que quiere acceder a la fuente de datos para poder almacenar o consultar datos.

·         DataAccessObject: Abstrae al BusinessObject de los detalles del acceso a la fuente de datos.

·         DataSource: Representa la implementación de la fuente de datos en sí.

·         TransferObject: Es un objeto intermedio entre el BussinessObject y el DataAccessObject.

En resumen objetos de acceso a datos o patrón de diseño DAO es una manera de reducir el acoplamiento entre la lógica de negocio y la lógica de persistencia. La lógica de negocio de aplicaciones a menudo necesita objetos de dominio, que se conserva en cualquier base de datos, sistema de archivos o cualquier otro medio de almacenamiento de persistencia. Patrón DAO permite encapsular código para realizar CRUD operación contra la persistencia del resto de la aplicación. Lo que significa que cualquier cambio en la lógica de persistencia no afectará a otras capas de la aplicación que ya está a prueba. Patrón DAO permite la aplicación para hacer frente a cualquier cambio en la base de datos o proveedor de tecnología de persistencia.

COMPOSITE VIEW

Componer objetos dentro de estructuras de árbol para representar jerarquías parte-todo. Composite permite a los clientes tratar objetos individuales y composiciones de objetos de manera uniforme.

En aplicaciones gráficas, como editores de dibujo, herramientas case, etc. se permite a los usuarios construir diagramas complejos a partir de componentes simples. El usuario puede agrupar componentes para formar componentes mayores, que a su vez pueden ser agrupados para formar componentes todavía más complejos. Una implementación sencilla podría definir clases para primitivas gráficas como Texto y Líneas, más otras clases que actúen como contenedores para estas primitivas.

Pero hay un problema con este enfoque: el código que usa estas clases debe tratar los objetos primitivos y controladores de forma diferente, aunque el usuario los trate de igual manera todo el tiempo. El tener que distinguir estos objetos hace la aplicación mucho más compleja. El patrón Composite describe cómo usar composición recursiva para que los clientes no necesiten establecer esta distinción.

Se usará el patrón Composite cuando:

- Se quieran representar jerarquías de objetos parte-todo.

- Se quieran clientes capaces de ignorar la diferencia entre composiciones de objetos y objetos individuales. Clientes que puedan tratar todos los objetos de la estructura compuesta de forma uniforme.

Estructura:

El patrón Composite pertenece a la categoría de patrones con propósito estructural y alcance de objeto. Es decir, propone una manera de componer a sus participantes, en este caso objetos, mediante relaciones determinadas dinámicamente en tiempo de ejecución

El patrón Composite:

- Define jerarquías de clases consistentes en objetos primitivos y objetos compuestos. Con los objetos primitivos se pueden formar por composición objetos más complejos, que a su vez se pueden componer con otros y así continuar de forma recursiva. Siempre que el código del cliente espere un objeto primitivo podrá recibir un objeto compuesto.

- Hace el cliente sencillo. Los clientes pueden tratar las estructuras compuestas y objetos individuales de forma uniforme. Los clientes normalmente no saben (y no les debe importar) si están trabajando con una hoja o con un componente compuesto. Esto simplifica el código del cliente, porque evita tener que programar funciones de comprobación, llenas de sentencias del tipo switch-case, para todas las clases del árbol de compuestos.

- Facilita el añadir nuevos tipos de componentes. Las últimas subclases Hoja o Compuesto que se definan funcionarán automáticamente con las estructuras ya existentes y el código del cliente. Los clientes no tienen que modificarse para las nuevas clases Componente.

- Puede hacer que el diseño sea demasiado general. La desventaja de hacer más fácil el añadir nuevos componentes es que dificulta la tarea de restringir los componentes de un compuesto. A veces interesa que un compuesto tenga sólo ciertos componentes. Con este patrón no se puede confiar en el sistema de tipos para forzar esas limitaciones por sí solo. Se deberán usar comprobaciones en tiempo de ejecución para ello.

Implementación:

u  Un Composite View se puede implementar siguiendo la estrategia JSP page View o bien la estrategia Servlet View. [Alur]

u  - El control de la vista se puede implementar de diferentes formas: utilizando etiquetas jsp estándar, como <jsp:include>, utilizando componentes JavaBeans, y también mediante etiquetas personalizadas (JSP ).

.

FAST-LANE READER

Este patrón propone un mecanismo para obtener grandes cantidades de información utilizando un acceso directo sobre la base de datos.

Implementación:

- casos de uso que corresponden a búsquedas que devuelven una colección de objetos.

- cuando se tienen casos de uso que corresponden a búsquedas múltiples y la eficiencia es un factor importante.

FRONT CONTROLLER

Es un patrón de diseño que se basa en usar un controlador como punto inicial para la gestión de las peticiones. El controlador gestiona estas peticiones, y realiza algunas funciones como: comprobación de restricciones de seguridad, manejo de errores, mapear y delegación de las peticiones a otros componentes de la aplicación que se encargarán de generar la vista adecuada para el usuario.

Controladores frontales son de uso frecuente en las aplicaciones web para implementar flujos de trabajo. Aunque no es estrictamente necesario, es mucho más fácil de controlar la navegación a través de un conjunto de páginas relacionadas (por ejemplo, varias páginas pueden ser utilizados en una compra en línea) de un controlador frontal de lo que es hacer que las páginas individuales responsables de la navegación.

El controlador frontal puede ser implementado como un objeto Java, o como una secuencia de comandos en un lenguaje de script como PHP, ASP, JSP CFML o lo que se llama en cada solicitud de una sesión web. Esta secuencia de comandos, por ejemplo un index.php, se ocuparía de todas las tareas que son comunes a la aplicación o el marco, como el manejo de sesiones, el almacenamiento en caché, y el filtrado de entrada. En base a la petición específica que sería entonces una instancia de otros objetos y llamar a los métodos para manejar la tarea en particular que se requieren.

La alternativa a un controlador frontal sería scripts individuales como login.php y order.php eso cada uno entonces satisfacer el tipo de solicitud. Cada secuencia de comandos tendría que duplicar el código o los objetos que son comunes a todas las tareas. Pero cada script también podría tener mayor flexibilidad para implementar la tarea específica que se requiere.

En un sitio Web complejo, hay muchas cosas similares que hay que hacer al manejar la petición. Estas cosas son la seguridad, la internacionalización y proporcionar puntos de vista particulares para determinados usuarios. Si el comportamiento del controlador de entrada está dispersa en varios objetos, gran parte de este comportamiento puede llegar a duplicarse. Además, es difícil cambiar el comportamiento en tiempo de ejecución.

El Controlador Frontal consolida toda solicitud de manipulación por canalizar a través de un único objeto de controlador. Este objeto se puede llevar a cabo un comportamiento común, que se puede modificar en tiempo de ejecución con los decoradores. El controlador entonces envíos a objetos de comando para el comportamiento en particular a una solicitud.

Ventajas:

·         Tenemos centralizado en un único punto la gestión de las peticiones.

·         Aumentamos la reusabilidad de código.

·         Mejoramos la gestión de la seguridad.

Diagrama de secuencia Front Controller

Controlador

El controlador es el punto de contacto inicial para manejar todos los pedidos en el sistema. El controlador puede delegar a un asistente para completar la autenticación y autorización de un usuario o para iniciar la recuperación de contacto.

Dispatcher

Un despachador es responsable de la gestión de vista y la navegación, controlando la elección de la siguiente vista a presentar al usuario, y proporcionar el mecanismo para el control a este recurso.

Un dispatcher se puede encapsular dentro de un controlador o puede ser un componente separado de trabajo en coordinación. El operador ofrece ya sea una estática despachar a la vista o un mecanismo de reenvío dinámico más sofisticado.

El operador utiliza el objeto RequestDispatcher (apoyado en la especificación de servlet) y encapsula algún procesamiento adicional.

Ayudante

Un ayudante se encarga de ayudar a la vista o al controlador a completar su procesamiento. Por lo tanto, los ayudantes tienen numerosas responsabilidades, incluyendo la recopilación de datos requeridos por la vista y el almacenamiento en el modelo intermedio, en cuyo caso la ayuda se conoce como un value bean. Además, los asistentes podrán adaptar este modelo de datos para el uso de la vista. Los helpers pueden servir peticiones de datos desde la vista simplemente proporcionando acceso a los datos en bruto o formato a los datos como el contenido Web.

Una vista podría trabajar con cualquier número de helpers, que normalmente están implementados como componentes JavaBeans (JSP 1.0 +) y etiquetas personalizadas (JSP 1.1 +). Además, un ayudante puede representar un objeto Command, un delegado (ver "Business Delegate" en la página 248), o un transformador XSL, que se utiliza en combinación con una hoja de estilos para adaptarse y convertir el modelo en la forma apropiada.

Ver

Una vista representa y muestra información al cliente. La vista recupera la información a partir de un modelo. Los helpers soportan vistas encapsulando y adaptando el modelo de datos subyacente para su uso en la pantalla.

COMPOSITE ENTITY

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.

Patrón de diseño ofrece una solución para modelar una red de entidades empresariales interrelacionados. La interfaz de la entidad compuesta es de grano grueso, y gestiona las interacciones entre objetos específicos internos. Este patrón de diseño es especialmente útil para la gestión eficiente de las relaciones con los objetos dependientes.

Entidad Compuesta - Es bean.It entidad principal puede ser de grano grueso o puede contener un objeto de grano grueso para ser utilizado para el propósito de persistencia.

Objeto: Este grano grueso objeto contiene objetos dependientes. Tiene su propio ciclo de vida y también gestiona el ciclo de vida de los objetos dependientes.

Objeto Dependiente - Los objetos dependientes es un objeto que depende de objeto genérico de su ciclo de vida persistencia.

Estrategias - Estrategias representa cómo implementar un Composite Entity.

Implementación:

Vamos a crear CompositeEntity objeto actuar como CompositeEntity. CoarseGrainedObject será una clase que contiene los objetos dependientes. CompositeEntityPatternDemo , nuestra clase de demostración utilizará cliente de clase para demostrar el uso del patrón Composite Entity.

En esta estrategia, el propio Composite Entity es el objeto genérico y tiene atributos y métodos de objeto genérico. Los objetos dependientes son atributos del Composite Entity. Como 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. La siguiente figura muestra el diagrama de clases de esta estrategia:

BUSINESS DELEGATE

El Business Delégate expone un interface que proporciona a los clientes acceso a los métodos subyacentes del API de servicios de negocio. En esta estrategia, un Business Delégate proporciona la función de proxy para pasar los métodos del cliente al bean de sesión que encapsula.

Business Delégate 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 Delégate 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 Delégate 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 Delégate 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 Delégate.

Con frecuencia, los desarrolladores son excépticos cuando un objetivo de diseño como la abstracción de la capa de negocio provoca un trabajo adicional como pago por futuras ganancias. Sin embargo, utilizando este patrón o esta estrategia resulta sólo en una pequeña cantidad de trabajo extra y proporciona unos beneficios considerables. El principal beneficio es ocultar los detalles del servicio. Por ejemplo, el cliente puede ser transparente para los servicios de búsqueda y nombrado. 

Utilizar un Business Delégate para reducir el acoplamiento entre los clientes de la capa de presentación y los servicios de negocio.

Es un patrón que reduce 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.

Los principales motivos para aplicar este patrón son los siguientes:

·         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 ocultar así 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.

Aplicabilidad

Cuando se quiere proporcionar una capa de acceso al modelo que oculta la tecnología usada en su implementación

Estructura

La siguiente figura muestra el diagrama de clases que representa al patrón Business Delégate. El cliente solicita al BusinessDelegate que le proporcione acceso al servicio de negocio subyacente. El BusinessDelegate utiliza un LookupService para localizar el componente BusinessService requerido.

Diagrama de secuencia

Colaboraciones

El BusinessDelegate utiliza un LookupService para localizar el servicio de negocio. El servicio de negocio se utiliza para invocar a los métodos de negocio por cuenta del cliente. El métodoGet_ID muestra que el BusinessDelegate puede obtener una versión String del handle(como un objeto EJBHandle) para el servicio de negocio y devolverlo al cliente como unString. El cliente puede utilizar la versión String del handle más tarde para reconectar con el servicio de negocio que estaba utilizando cuando obtuvo el handle. Esta técnica evitará nuevas búsquedas, ya que el handle es capáz de reconectar con su ejemplar del servicio de negocio. Se debería observar que los objetos handle los implementa el contenedor y podrían no ser portables entre contenedores de diferentes vendedores.

Beneficios

·         Mejora el mantenimiento.

·         Permite separación de roles: desarrolladores de la capa cliente y desarrolladores de la capa EJB.

·         Puede proporcionar caché para mejorar la eficiencia.

SESSION FACADE

Nos permite dar una fachada de acceso a la parte central de la aplicación hecha en EJBs.

De este modo, utilizamos una arquitectura de 4 capas (similar a la arquitectura Modelo Vista Controlador(tecnología pero añadiendo la capa de acceso a la base de datos y sin permitir comunicación entre la vista y el modelo). A la hora de detallar esta arquitectura utilizamos Session y Entity Beans para la capa de datos (modelo) y de infraestructura (acceso a la base de datos).Para la capa de control utilizamos Session Beans que nos sirven a modo de fachada para utilizar la aplicación. Por último para la capa de Vista utilizamos JSPs (para las interfaces de usuario) y Web Services (para permitir acceso a nuestro sistema desde otras aplicaciones).

 Esto se corresponde con un session facade, ya que los session bean de la capa de control solamente hacen de fachada para que los JSPs de la interfaz accedan a los session y entity beans del modelo de datos.

Una de las ventajas de utilizar este patrón es a la hora de controlar los permisos de los usuarios. Cada usuario tiene un rol (administrador, invitado, usuario registrado, etc.) y, para controlar los permisos de cada rol, lo único que tenemos que hacer es definir las operaciones de cada rol en distintos session beans de la capa de control y después, desde el deployment descriptor de los EJBs, mapear nuestros roles con dichos session beans. La autenticación se realiza en la capa de interfaz.

Conoce qué clases del subsistema son responsables de una determinada petición, y delega esas peticiones de los clientes a los objetos apropiados del subsistema.

Subclases (ModuleA, ModuleB, ModuleC...): implementan la funcionalidad del subsistema. Realizan el trabajo solicitado por la fachada. No conocen la existencia de la fachada.

Colaboraciones:

Los clientes que se comunican con el subsistema enviando peticiones al objeto Fachada, el cual las reenvía a los objetos apropiados del subsistema.

Los objetos del subsistema realizan el trabajo final ,y la fachada hace algo de trabajo para pasar de su interfaz a las del subsistema.

Los clientes que usan la fachada no tienen que acceder directamente a los objetos del subsistema.

La principal ventaja del patrón fachada consiste en que para modificar las clases de los subsistemas, sólo hay que realizar cambios en la interfaz/fachada, y los clientes pueden permanecer ajenos a ello. Además, y como se mencionó anteriormente, los clientes no necesitan conocer las clases que hay tras dicha interfaz.

Como inconveniente, si se considera el caso de que varios clientes necesiten acceder a subconjuntos diferentes de la funcionalidad que provee el sistema, podrían acabar usando sólo una pequeña parte de la fachada, por lo que sería conveniente utilizar varias fachadas más específicas en lugar de una única global.

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.

Los clientes de la aplicación necesitan acceder a los objetos de negocio para cumplir sus responsabilidades y para cumplir los requerimientos del usuario. Los clientes pueden interactuar directamente con estos objetos de negocio porque éstos exponen sus interfaces. Cuando exponemos nuestros objetos de negocio al cliente, el cliente debe entender y ser responsable de las relaciones con los objetos de datos de negocio, y debe poder manejar el flujo del proceso de negocio.

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.

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 Delégate en otra capa.

SessionFacade: se implementa como un bean de sesión. Maneja las 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: es un objeto de rol que facilita la aplicación de diferentes estrategias, 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:
Los Session Facades pueden representar una capa controladora entre los clientes y la capa de negocios, identificado en el análisis del modelo. 

·         Expone un Interface Uniforme:
Las interacciones entre los componentes de negocio pueden ser muy complejas. Un patrón Session Facade abstrae esta complejidad y le presenta al cliente un interface sencillo que es fácil de entender y de utilizar. 

·         Reduce el Acoplamiento, Incrementa la Manejabilidad
Utilizar un Session Facade desacopla los objetos de negocio de los clientes, y así reduce el fuerte acoplamiento y la dependencia de los clientes de los objetos de negocio. 

·         Mejora el Rendimiento, Reduce los Métodos Específicos
Session Facade también impacta en el rendimiento. Reduce la sobrecarga de la red entre el cliente y el servidor porque su uso elimina la interacción directa entre el cliente y los datos y objetos de negocio.

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 interactuar con estos componentes, los clientes deben o localizar 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.

Solución

Utilizar un objeto ServiceLocator para abstraer toda la utilización JNDI y para ocultar las complejidades de la creación del contexto inicial, de búsqueda de objetos home EJB y de re-creación de objetos EJB. Varios clientes pueden reutilizar el objeto ServiceLocator 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 ServiceLocator.

Estructura

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

Participantes y Responsabilidades

La siguiente figura contiene el diagrama de secuencia que muestra la interacción entre los distintos participantes en el patrón ServiceLocator.

Client:

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

ServiceLocator:

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

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 dependiendo del tipo de objetos de negocio proporcionados por el servicio de búsqueda y creación del ServiceLocator. Un ServiceLocator que proporciona los servicios para varios tipos de objetos de negocio (como beans Enterprise, componentes JMS, etc.) utiliza varios tipos de objetoscontext, cada uno obtenido de un proveedor diferente (por ejemplo, el proveedor de contexto para un servidor de aplicaciones EJB podría ser diferente del proveedor de contexto para un servicio JMS).

 

ServiceFactory:

El objeto ServiceFactory representa un objeto que proporciona control del ciclo de vida para objetos BusinessService.

 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.

Consecuencias

·         Abstrae la Complejidad 
El patrón ServiceLocator encapsula la complejidad de este proceso de búsqueda y creación (descrito en el problema) y lo mantiene oculto del cliente. El cliente no necesita tratar con la búsqueda de componentes ni factorías de objetos porque se ha delegado esta responsabilidad en el ServiceLocator.

·         Proporciona a los Clientes un Acceso Uniforme a los Servicios 
El patrón ServiceLocator abstrae todas las complejidades, como acabamos de ver. Haciendo esto, proporciona un interface muy útil y preciso que todos los clientes pueden utilizar. Este interface asegura que todos los tipos de clientes de la aplicación acceden de forma uniforme a los objetos de negocio, en términos de búsqueda y creación. Esta uniformidad reduce la sobrecarga de desarrollo y mantenimiento.

·         Facilita la Adicción de Nuevos Componentes de Negocio 
Como los clientes de beans enterprise no se preocupan de los objetos EJBHome, es posible añadir nuevos objetos EJBHome para beans enterprise y desplegarlos posteriormente sin impactar en los clientes. Los clientes JMS no se preocupan directamente de las factorías de conexiones JMS, por eso se pueden añadir nuevas factorías sin impactar en los clientes.

·         Mejora el Rendimiento de la Red 
Los clientes no están implicados en la búsqueda JNDI y la creación de objetos (factory/home). Como el ServiceLocator realiza este trabajo, puede asumir las llamadas de red requeridas para buscar y crear objetos de negocio.

·         Mejora el Rendimiento del Cliente mediante el Caché 
El ServiceLocator puede poner en un caché los objetos y referencias a objetos del contexto inicial para eliminar actividad JNDI innecesaria que ocurre cuando se obtiene el contexto inicial u otro objetos. Esto mejora el rendimiento de la aplicación.

INTERCEPTING FILTER

El patrón de diseño de filtros interceptación se utiliza cuando queremos hacer algo de post-procesamiento de pre-procesamiento / con la petición o la respuesta de la aplicación. Los filtros se definen y aplican en la solicitud antes de pasar la solicitud a la aplicación de destino real. Los filtros pueden hacer la autenticación / autorización / registro o el seguimiento de la solicitud y luego pasar a las peticiones de los controladores correspondientes. A continuación se presentan las entidades de este tipo de patrón de diseño.

·         Filtro - Filtro que llevará a cabo determinada tarea antes o después de la ejecución de la solicitud por el controlador de solicitudes.

·         Cadena Filter - Filtro Cadena lleva varios filtros y ayuda a ejecutar con el fin definido en el blanco.

·         Target - Objeto de destino es el controlador de solicitudes

·         Administrador de filtros - Administrador de filtros gestiona los filtros y cadena de filtros.

·         Client - Cliente es el objeto que se envía la solicitud al objeto de destino.

Implementación

Vamos a crear un FilterChain , FilterManager , Target , Client como diversos objetos que representan nuestras entidades. AuthenticationFilter y DebugFilter representa filtros concretos.

InterceptingFilterDemo , nuestra clase de demostración utilizará cliente para demostrar Interceptar patrón de diseño de filtros.

•      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 coleccion ordenada de filtros indenpendientes.

•       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 imprecisa 
filtros proporcionan un lugar central para manejar el procesamiento a través de múltiples peticiones, al igual que un controlador. Los filtros se adaptan mejor a masajear solicitudes y respuestas para la manipulación último por un recurso de destino, tal como un controlador.Además, un controlador de frecuencia une la gestión de numerosos servicios comunes no relacionados, tales como la autenticación, el registro, el cifrado, y así sucesivamente, mientras que permite a los manipuladores de filtrado acoplados mucho más débilmente, que se pueden combinar en varias combinaciones.

·         Mejora Reutilización
Filtros promover limpiador partición de aplicación y alienta la reutilización

·         Configuración declarativa y flexible 
Numerosos servicios se combinan en diferentes permutaciones sin un solo recompilar el código base del núcleo.

·         Compartir información es ineficiente 
Compartir información entre los filtros pueden ser ineficaces, ya que, por definición, cada filtro está débilmente acoplado. Si se deben compartir grandes cantidades de información entre los filtros, a continuación, este enfoque puede resultar costosa.

MODELO VISTA CONTROLADOR

El Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario. Este patrón de diseño se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento.

De manera genérica, los componentes de MVC se podrían definir como sigue:

·         El Modelo: Es la representación de la información con la cual el sistema opera, por lo tanto gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de acceso que se hayan descrito en las especificaciones de la aplicación (lógica de negocio). Envía a la 'vista' aquella parte de la información que en cada momento se le solicita para que sea mostrada (típicamente a un usuario). Las peticiones de acceso o manipulación de información llegan al 'modelo' a través del 'controlador.

·         El Controlador: Responde a eventos (usualmente acciones del usuario) e invoca peticiones al 'modelo' cuando se hace alguna solicitud sobre la información (por ejemplo, editar un documento o un registro en una base de datos). También puede enviar comandos a su 'vista' asociada si se solicita un cambio en la forma en que se presenta de 'modelo' (por ejemplo, desplazamiento o scroll por un documento o por los diferentes registros de una base de datos), por tanto se podría decir que el 'controlador' hace de intermediario entre la 'vista' y el 'modelo'.

·         La Vista: Presenta el 'modelo' (información y lógica de negocio) en un formato adecuado para interactuar (usualmente la interfaz de usuario) por tanto requiere de dicho 'modelo' la información que debe representar como salida.

Interacción de los componentes:

Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo de control que se sigue generalmente es el siguiente:

1.   El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.)

2.   El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.

3.   El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.

4.   El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se reflejan los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. Este uso del patrón Observador no es posible en las aplicaciones Web puesto que las clases de la vista están desconectadas del modelo y del controlador. En general el controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista. Por ejemplo en el MVC usado por Apple en su framework Cocoa. Suele citarse como Modelo-Interface-Control, una variación del MVC más puro

5.   La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente

TRANSFER OBJECT

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

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, dependendiendo de los requerimientos.

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. El constructor podría aceptar todos los valores de atributos del bean de entidad para el que se ha diseñado el Transfer Object

Consecuencias:

*        Transfiere Más Datos en Menos Llamadas Remotas
En lugar de realizar múltiples llamadas sobre la red al BusinessObject para obtener los valores de los atributos, esta solución proporciona una sola llamada a un método.

*        Reduce el Tráfico de Red
Un Transfer Object transfiere los valores desde el bean de entidad al cliente en una llamada a un método remoto. El Transfer Object actúa como un transportista de datos y reduce el número de llamadas remotas requeridas para obtener los valores de los atributos del bean; y esto significa un mejor rendimiento de la red.

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.

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. Esto depende de la aplicación y de la implementación de este patrón.

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

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. Esto depende de la aplicación y de la implementación de este patrón.

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.

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.

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

Consecuencias

·         Proporciona Alternativas a los métodos find() de EJB para Grandes Consultas 
Normalmente, un método de búsqueda EJB es una forma cara de obtener una lista de ítems, ya que implica un número de referencias EJBObject.

·         Crea un Caché de Resultados de la Consulta en el Lado del Servidor
Se necesita cachear los resultados obtenidos de la ejecución de la consulta cuando un cliente debe mostrarlos en pequeñas partes en vez de una gran lista. 

·         Proporciona una Mayor Flexibilidad de Consulta
Añadir una nueva consulta podría requerir la creación de un nuevo método finder o modificar uno existente, especialmente cuando se utilizan beans de entidad manejados por el bean (con beans de entidad manejados por el bean, el desarrollador implementa los métodos de búsqueda en la implementación del bean).

·         Mejora el Rendimiento de Red
El rendimiento de la red se ve mejorado porque sólo los datos solicitados, en vez de todos los datos, se envían (serializados) al cliente sobre unas necesidades básicas.