Patrones de Diseo de J2EE

Para explicar el funcionamiento de cada uno de los patrones de diseo que se mencionarn a continuacin, nos basaremos en el Catlogo de Patrones de J2EE presentado en el Sitio Web Oficial de Sun Microsystems [1]. Los patrones de diseo de J2EE presentados por Sun Microsystems, han sido divididos en capas (presentacin, negocios, integracin) segn su funcionalidad. Los patrones de la capa de presentacin contienen toda la informacin relacionada con los servlets y tecnologa JSP [1]. Los patrones de la capa de Lgica de Negocios, contienen toda la informacin relacionada con los Enterprise Java Beans. Por ultimo, los patrones de la capa de Integracin contienen toda la informacin relacionada con el Java Message Service [1] y la tecnologa para conexin con base de datos de java JDBC. En la figura 3.1 se muestra con un poco mas de detalle la organizacin en capas mencionada anteriormente

Figura 3.1.- Divisin en capas de una Aplicacin El catlogo de patrones de J2EE, esta basado en las capas numeradas 1, 2, 3, que se muestran en la figura 3.1, esta separacin permite que los patrones diseados para cada componente puedan enfocarse en aspectos especficos del desarrollo de la aplicacin, adems de proveer una mayor modularidad y la posibilidad de realizar cambios en un componente determinado sin afectar a los otros componentes.

A continuacin se describir el funcionamiento de cada uno de los patrones y posteriormente se plantear una posible adaptacin de los que mas se adecuen a la aplicacin que se pretende desarrollar.

Patrones de la Capa de Presentacin

1.- Patrn Decorating Filter

Contexto La mayora de los sistemas existentes en Internet manejan solicitudes web. El procesamiento de dichas solicitudes involucra un nmero variable de servicios en el sistema. Problema El problema central en el cual se enfoca este patrn es el pre-procesamiento y post-procesamiento de peticiones, por lo cual se debe proveer un mecanismo que permita aadir y remover componentes que sirvan para realizar el procesamiento de las peticiones que llegan al sistema. Fortalezas Centralizacin de la lgica de servicios comunes. Facilidad al momento de aadir o remover servicios al sistema lo cual permite que estos puedan ser usados en una gran variedad de combinaciones de forma tal que no afecten a otros componentes como el de autenticacin o registro de actividades (logging). Procesamiento completo por solicitudes, por ejemplo, el servicio de seguridad del sistema debe chequear todo lo relacionado con la autenticacin del sistema cada vez que esto sea necesario.

Una vez mencionados los puntos centrales que deben ser cubiertos por el patrn se proceder a describir la solucin que propone el patrn. La idea principal de esta solucin es la de crear una serie de filtros que se conecten entre s para realizar el procesamiento de servicios comunes del sistema en una forma estndar sin la necesidad de cambiar el cdigo que se encuentra en el ncleo de la aplicacin para el procesamiento de solicitudes, con esto se pretende decorar el procesamiento principal con una variedad de servicios comunes, tales como seguridad, registro de logs, depuracin, etc. Estos filtros son componentes independientes del cdigo central de la aplicacin, lo cual permite que puedan ser removidos o aadidos fcilmente. Por ejemplo, un archivo de configuracin de despliegue o publicacin puede ser modificado con la finalidad de configurar una serie de filtros. El mismo archivo de configuracin podra incluir un mapeo de URLs especficos para el conjunto de filtros mencionados anteriormente. Cuando un cliente solicita un recurso que coincide con los URLs que se han configurado, cada uno de los filtros es procesado antes que se retorne el recurso solicitado. El siguiente diagrama de clases ilustra el funcionamiento del patrn Decorating Filter:

Figura 3.2.- Diagrama de clases del Patrn Decorating Filter Consecuencias Control Centralizado

Este patrn provee un lugar central para manejar los servicios y lgica de negocios a lo largo de mltiples solicitudes. Existe otro patrn denominado Front Controller 3 que tambin permite obtener un control centralizado pero tiene la desventaja de no permitir la separacin de servicios comunes no relacionados entre s, tales como autenticacin, registro de logs, cifrado de datos, etc. Mayor Reusabilidad

Aumenta la facilidad de particionar aplicaciones e incrementa la reusabilidad. Los filtros decoradores son fciles de aadir o remover del cdigo de manejo de solicitudes existente. Pueden ser usados en cualquier combinacin y fcilmente reutilizados para mltiples presentaciones. Flexibilidad de Configuracin

Numerosos servicios pueden ser combinados de muchas maneras sin necesidad de cambiar el cdigo principal de la aplicacin. Aumento de la cohesin y disminucin de la dependencia entre componentes

Esto es debido a que cada componente es escrito independientemente uno del otro. Problemas con la informacin compartida

La informacin compartida entre filtros puede ser ineficiente, debido a que cada filtro es independiente uno del otro. Si grandes cantidades de informacin deben ser compartidas entre filtros puede resultar muy costoso el uso de este esquema.

En secciones posteriores se describir con mayor detalle el funcionamiento de este patrn.

2.- Patrn Front Controller

Contexto Este patrn surge con la finalidad de proveer un mecanismo que permita a la capa de presentacin controlar y coordinar el procesamiento de cada usuario a lo largo de mltiples solicitudes, adems debe permitir administrar dichos mecanismos de una forma centralizada o distribuida. Problema El problema principal que debe resolver este patrn es que el sistema requiere un punto de acceso centralizado para el manejo de solicitudes de la capa de presentacin para con ello, ayudar a la integracin de los servicios del sistema, recuperacin de contenido, manejo de vistas y navegacin. Cuando el usuario accede a una vista directamente sin pasar a travs de un mecanismo centralizado, pueden ocurrir dos tipos de problemas: a.- Cada vista es requerida para proveer sus propios servicios de sistema, lo cual termina resultando a menudo en duplicacin de cdigo. b.- La navegacin visual es delegada a las vistas. Adicionalmente, el control distribuido es ms difcil de mantener que el centralizado, ya que por lo general es necesario realizar cambios en mltiples lugares con el control distribuido. Fortalezas Las fortalezas que contempla este patrn son las siguientes: La lgica es manejada de una mejor manera en un mdulo central en lugar de replicar el cdigo de lgica de negocios en cada vista. Los puntos de decisin funcionan de acuerdo a la frecuencia de recuperacin y manipulacin de los datos. Se utilizan mltiples vistas para responder a solicitudes similares. Un punto de contacto centralizado para el manejo de una solicitud permite mejorar la facilidad de controlar procesos tales como el control y registro del progreso de un usuario en un site. Los servicios del sistema y la lgica de manejo de vistas son relativamente sofisticados. Solucin La solucin propuesta es la de usar un controlador como el punto inicial de contacto para el manejo de una solicitud. El controlador administra el manejo de una solicitud, incluyendo los servicios de seguridad tales como autenticacin y autorizacin, delega procesos de lgica de negocios as como tambin la seleccin de una vista apropiada, manejo de errores y estrategias de creacin de contenidos. El controlador provee un punto de entrada centralizado que controla y administra el manejo de solicitudes Web, por medio de controles y puntos de decisin centralizados, el controlador adems ayuda a reducir la cantidad de cdigo Java, que se encuentra contenido dentro de una pgina JSP.

La centralizacin del control proveda por el controlador y la reduccin de la lgica de negocios en las vistas incrementa la reusabilidad de cdigo a lo largo de las solicitudes, lo cual es una aproximacin preferible a la alternativa de la inclusin de cdigo en mltiples vistas debido a que esto puede ocasionar que la aplicacin este mas propensa a errores. Tpicamente, un controlador se coordina con un componente despachador. Los despachadores son responsables del manejo de las vistas y de la navegacin. As, un despachador escoge la prxima vista para el usuario y los vectores de control para el recurso. Los despachadores pueden estar encapsulados dentro del controlado directamente o pueden ser colocados en un componente diferente. Aunque el patrn Front Controller propone la centralizacin del manejo de todas las solicitudes, esto no limita el nmero de manejadores en el sistema, tal y como lo hara un patrn de tipo Singleton 4 . Una aplicacin puede usar mltiples controladores en un sistema, cada unos de estos mapea un conjunto de servicios diferentes. El siguiente diagrama de clases ilustra la estructura del patrn Front Controller:

Figura 3.3.- Diagrama de clases del Patrn Front Controller

Consecuencias Control Centralizado

Un controlador provee un lugar central para manejar los servicios del sistema y la lgica de negocios a lo largo de mltiples solicitudes. El acceso centralizado a una aplicacin implica el hecho de que las solicitudes sean fcilmente seguidas y registradas. La desventaja principal del esquema centralizado es la poca tolerancia a fallos que posee.

Un patrn de tipo Singleton es aquel que permite que exista solo una instancia nica de un ejemplar.

3.- Patrn Helper View

Contexto Los Sistemas manejan solicitudes Web. Los procesos de la capa de presentacin requieren la generacin de una vista basada en una plantilla y un modelo dinmico. Problema Los cambios de la capa de presentacin ocurren a menudo y son difciles de desarrollar y mantener, debido a la combinacin de la lgica de negocio para el acceso a los datos y la lgica de formateo de la presentacin, esto hace que el sistema sea menos flexible, menos reutilizable, y menos adaptable a los cambios. Mezclar la lgica de negocio con el procesamiento de las vistas tambin reduce la modularidad y disminuye la separacin de roles a la hora de asignar tareas a los miembros de un equipo de desarrollo de software o de aplicaciones web. Fortalezas Incluir lgica de negocio en las vistas promueve el tipo de reuso estilo copiar y pegar. Esto puede ocasionar problemas y errores debido a que un trozo de la lgica de negocios es reutilizado en la misma o en diferentes vistas simplemente colocando al cdigo duplicado en lugares diferentes. Es deseable incrementar una separacin transparente para que cada individuo del equipo de desarrollo pueda cumplir a cabalidad las labores relacionadas con su rol dentro del equipo de trabajo. Una vista es comnmente usada para responder a una solicitud particular.

Solucin Las vistas delegan el manejo de contenido a sus ayudantes (helpers), los cuales sirve como modelo de datos y adaptadores para los datos. La lgica de presentacin es encapsulada en el ayudante y se sita entre la vista y la capa de negocios. Existen mltiples estrategias para la implementacin del componente de vistas. Una de las estrategias ms comunes es la de usar una pgina JSP como el componente de vistas. Otra estrategia muy utilizada es la denominada ServletViewStrategy, la cual utiliza un servlet como vista. La encapsulacin de la lgica de negocios en un ayudante en lugar de en una vista hace que las aplicaciones sean mas modulares y facilita la reutilizacin de componentes. Mltiples clientes, tales como controladores y vistas, pueden apoyarse en el mismo ayudante para recuperar y adaptar un modelo de estado similar para realizar presentaciones de distintas formas. Una seal que puede indicar la necesidad de usar de este patrn con el cdigo existente, es que un scriplet sobrecargue o desordene una vista JSP. El objetivo principal de aplicar este patrn es realizar la particin de la lgica de negocios fuera de la vista. Aunque algo del cdigo de la lgica de negocios puede

ser ms til si se encuentra encapsulado dentro de ayudantes, pueden existir porciones de cdigo que deben estar en un componente centralizado que los situ en frente de las vistas y los ayudantes (tales como chequeos de autenticacin o servicios de registro de actividades logging). 5 Este patrn se enfoca en la recomendacin de mltiples formas de particionar las responsabilidades en una aplicacin. Estructura El siguiente diagrama de clases representa al patrn Helper View

Figura 3.4.- Diagrama de clases del Patrn Helper View

Vista Una vista representa y muestra informacin al cliente. La informacin que es usada en un display es obtenida de un modelo. Los ayudantes dan soporte a las vistas por medio de la encapsulacin y adaptacin de un modelo para su uso en un display. Ayudante Un ayudante es responsable de contribuir a completar el procesamiento que realiza una vista o un Controlador. As, los ayudantes tienen numerosas responsabilidades, incluyendo la recoleccin de datos requeridos por una vista y adaptarlos al modelo de datos usado por la vista. Los ayudantes pueden atender las solicitudes de datos de una vista con el simple hecho de proveerle a la misma acceso a los metadatos o formateando los datos como contenido Web. Una vista puede trabajar con cualquier nmero de ayudantes, los cuales son implementados tpicamente como JavaBeans y etiquetas personalizadas. Adicionalmente, un ayudante puede representar un objeto de tipo Command, Delegate o tambin un objeto de tipo XSLT, el cual es usado en combinacin con una hoja de estilo para adaptar y convertir el modelo a una forma apropiada. Consecuencias Mejoras en el particionamiento de aplicaciones

El uso de ayudantes proporciona una separacin clara de las vistas con respecto a la lgica de procesamiento de la aplicacin. Los ayudantes, en la

Para resolver este problema se deben emplear los patrones Decorating filter y Front Controller explicados anteriormente.

forma de JavaBeans y Etiquetas Personalizadas, proveen un lugar para colocar la lgica de procesamiento fuera de las pginas JSP. Separacin de Roles

Separando la lgica de formateo de la lgica de negocios de la aplicacin, reduce las dependencias que pueden llegar a tener los diferentes roles en los mismos recursos. Reusabilidad

La lgica de negocios que se encuentra fuera de un JSP y dentro de JavaBeans o Etiquetas personalizadas puede ser reutilizada a lo largo de mltiples JSPs. El cdigo no es duplicado en varios JSPs, lo cual hace que la aplicacin sea ms fcil de mantener y depurar. Adicionalmente, debido a que la lgica de negocios se ha removido de las vistas, la misma lgica de negocios puede ser reutilizada, sin modificacin potencial, y ser utilizada en otro tipo de interfaz totalmente diferente tal como Swing.

4.- Patrn Composite View

Contexto Las pginas Web sofisticadas presentan contenidos de numerosas Fuentes de datos, usando varias sub-vistas que se encuentran contenidas dentro de una pgina. Adicionalmente, una variedad de individuos con diferentes habilidades contribuyen al desarrollo y mantenimiento de estas pginas web. Problema En lugar de proveer un mecanismo para combinar mdulos o porciones atmicas de una vista para generar una composicin completa, las pginas son construidas al incrustar cdigo de formateo directamente dentro de cada vista. La Modificacin de la disposicin de mltiples vistas es difcil y propensa a errores, debido a la duplicacin de cdigo. Fortalezas Porciones atmicas del contenido de una vista pueden cambiar frecuentemente. Mltiples vistas compuestas utilizan sub-vistas similares, tales como una tabla de inventarios. Estas porciones atmicas son decoradas con diferentes plantillas de texto, o aparecen en un lugar diferente dentro de la pgina. La disposicin de los elementos es ms difcil de manejar y el cdigo es mas difcil de mantener cuando las sub-vistas estn incluidas directamente o duplicadas en diferentes vistas La inclusin frecuente de nuevos elementos cambiando porciones de las plantillas de texto directamente a vistas puede afectar potencialmente la disponibilidad y administracin del sistema.

Solucin Usar vistas compuestas que a su vez se encuentren compuestas de subvistas atmicas. Cada componente de la plantilla puede ser incluido dinmicamente en un todo y la apariencia de la pgina puede ser manejada independientemente del contenido. Esta solucin facilita la creacin de vistas compuestas basada en la inclusin y sustitucin de mdulos y fragmentos de plantillas dinmicamente. Esto promueve la reutilizacin de porciones atmicas de las vistas al facilitar el diseo modular. Las vistas compuestas pueden ser usadas para generar pginas que contienen componentes de visualizacin que pueden ser combinados en una gran variedad de formas, un ejemplo de esto puede ser, un portal web que incluye un gran nmero de sub-vistas independientes, tales como recepcin de nuevas noticias, informacin del clima, e informacin de inventario todo en una pgina simple, para este caso la apariencia de la pgina es manejada y modificada independientemente del contenido de las sub-vistas. Otro beneficio de este patrn es que los diseadores Web pueden hacer prototipos de la apariencia de un site, colocando contenido esttico en cada una de las regiones de las plantillas. A medida que el desarrollo del site avanza, el contenido puede ser modificado por sus elaboradores. La figura 3.5 muestra una toma del sitio oficial de Java, en ella se pueden observar las 4 regiones que conforman el site, y aunque el contenido de cada regin puede provenir de fuentes de datos distintas, al ser colocadas todas sobre una misma regin conforman una vista compuesta.

Figura 3.5 Vista de una pgina modular que incluye 4 regiones denominadas, Search, Navigation, Feature Story, y Headlines

Por supuesto, este patrn posee desventajas, y una de las mas evidentes es la de la posible sobrecarga de ejecucin producida por el incremento de flexibilidad que este patrn provee. Adems, el uso de una distribucin de elementos sofisticada puede generar problemas de desarrollo, debido al gran nmero de artefactos que se deben mantener. Estructura La figura 3.6 muestra el diagrama de clases representa al patrn Composite

View:

Figura 3.6 Diagrama de clases del patrn Composite View

Consecuencias Mejora la Modularidad y la Reutilizacin

Este patrn mejora el diseo modular. Esto hace posible que se puedan reutilizar porciones atmicas de una plantilla, tal como una tabla de inventario, en numerosas vistas, adicionalmente estas vistas pueden ser rellenadas con informacin diferente. Este patrn permite que una tabla sea movida a su propio mdulo y que sea usada solo cuando sea necesario. Este tipo de distribucin dinmica de elementos reduce la duplicacin innecesaria de cdigo y mejora la facilidad de mantenimiento de la aplicacin. Flexibilidad mejorada

Una implementacin sofisticada puede incluir fragmentos de una plantilla basndose en decisiones tomadas en tiempo de ejecucin tales como el rol de un usuario o una poltica de seguridad. Impacto en el Rendimiento

Generar una pgina que contenga numerosas sub-vistas puede disminuir el rendimiento de una aplicacin. La inclusin de sub-vistas en tiempo de ejecucin puede convertirse en un retraso que se produce cada vez que la pgina es solicitada por el cliente, lo cual podra afectar drsticamente el desempeo de la aplicacin en ambientes con Niveles de Servicio muy estrictos. Una alternativa es que la inclusin de la sub-vistas se realice en el momento en el que el motor JSP se encuentra procesando una pgina, aunque esto limita a que los cambios que se

realicen sobre una sub-vista solo se muestren cuando esta sea nuevamente procesada.

5.- Patrn Service to Worker

Contexto Los Sistemas manejan solicitudes Web. Los procesos de la capa de presentacin requieren la generacin de una vista basada en una plantilla y un modelo dinmico. Problema Los cambios de la capa de Presentacin ocurren a menudo y son difciles de desarrollar y mantener, debido a la combinacin de la lgica de negocio para el acceso a los datos y la lgica de formateo de la presentacin, esto hace que el sistema sea menos flexible, menos reutilizable, y menos adaptable a los cambios. Las porciones de lgica de negocio que son mezcladas con las vistas deben ser adaptadas a un modelo intermedio para su visualizacin. Mezclar la lgica de negocio con el procesamiento de las vistas tambin reduce la modularidad y disminuye la separacin de roles a la hora de asignar tareas a los miembros de un equipo de desarrollo de software o de aplicaciones web. Fortalezas Necesidad de generacin dinmica de contenido El contenido requiere que los datos de negocio sean extrados dinmicamente. Los servicios de procesamiento comunes del sistema, tales como autenticacin y chequeo de permisologas deben realizarse por cada solicitud entrante. Crear puntos de decisin para la recuperacin y manipulacin de contenido Usar mltiples vistas para responder a solicitudes similares. Encapsular la lgica de negocio en otros componentes distintos de las Vistas.

Solucin Combinar un despachador con vistas y ayudantes para manejar las solicitudes de los clientes y preparar una presentacin dinmica como respuesta. Un despachador es responsable por el manejo de vistas y la navegacin, y puede ser o no encapsulado dentro de un controlador, o puede ser un componente independiente que trabaje de forma sincronizada con los componentes internos. Este patrn y el Dispatcher View poseen una estructura similar, pero an as, cada patrn sugiere una divisin diferente de las labores que debe realizar cada componente. En este patrn, el Controlador y el Despachador poseen mayores responsabilidades Los patrones Service to Worker y Dispatcher View representan una combinacin comn de otros patrones, por lo cual cada uno garantiza a su propia manera una forma mas eficiente de comunicacin entre desarrolladores.

En el patrn Dispatcher View, el Despachador posee un rol limitado en cuanto al manejo de Vistas. En el patrn Service to Worker, el Despachador posee un rol mucho mas relevante en cuanto al manejo de vistas. Un rol limitado para el Despachador ocurre cuando no se utilizan recursos externos para seleccionar una vista. La informacin encapsulada en la solicitud es suficiente para determinar las Vistas a utilizar para resolver una peticin. Por ejemplo en este caso: http://some.server.com/servlet/Controller?next=login.jsp La responsabilidad del Despachador es la de proporcionar acceso a la vista login.jsp Un ejemplo del Despachador con rol moderado es el caso en el cual el cliente enva una peticin directamente a un Controlador con un parmetro de una consulta que describe una accin que debe ser completada: http://some.server.com/servlet/Controller?action=login La responsabilidad del Despachador en este caso es la de traducir el nombre lgico login en el nombre de un recurso de una vista apropiada tal como lo es login.jsp y as proveer el acceso a dicha vista. Para llevar a cabo su traduccin, el Despachador puede acceder a recursos como un archivo XML de configuracin que especifique la vista que debe mostrarse. Por otro lado, en el patrn Service to Worker, el Despachador debe ser ms sofisticado, ya que este debe invocar las funciones de negocio necesarias para determinar las vistas que se van a mostrar. La estructura compartida anteriormente esta conformada Despachador, Vistas y Ayudantes. Estructura La figura 3.7 muestra el diagrama de clases representa al patrn Service to Worker: de estos dos patrones que se mencion por un Controlador que trabaja con un

Figura 3.7.- Diagrama de clases del Patrn Service to Worker

Los componentes del diagrama de clases se especifican a continuacin: Controlador El Controlador es el punto de contacto inicial para el manejo de una solicitud. Este trabaja con un Despachador para completar el manejo de vistas y la navegacin. Despachador Un Despachador es responsable del manejo de Vistas y navegacin, ya que este se encarga de seleccionar la prxima vista a ser presentada al Usuario, adems de proveer un mecanismo para el control vectorizado de un recurso. Vista Una vista representa y visualiza informacin para los clientes. La informacin que es usada en una vista es tomada de un modelo. Ayudante Un ayudante es responsable de contribuir a completar el procesamiento que realiza una vista o un Controlador. As, los ayudantes tienen numerosas responsabilidades, incluyendo la recoleccin de datos requeridos por una vista y adaptarlos al modelo de datos usado por la vista. Los ayudantes pueden atender las solicitudes de datos de una vista con el simple hecho de proveerle a la misma acceso a los metadatos o formateando los datos como contenido Web. Una vista puede trabajar con cualquier nmero de ayudantes, los cuales son implementados tpicamente como JavaBeans y etiquetas personalizadas. Adicionalmente, un ayudante puede representar un objeto de tipo Command, Delegate o tambin un objeto de tipo XSLT, el cual es usado en combinacin con una hoja de estilo para adaptar y convertir el modelo a una forma apropiada. Consecuencias Reusabilidad

La lgica de negocios que se encuentra fuera de un JSP y dentro de JavaBeans o Etiquetas personalizadas puede ser reutilizada a lo largo de mltiples JSPs. El cdigo no es duplicado en varios JSPs, lo cual hace que la aplicacin sea ms fcil de mantener y depurar. Adicionalmente, debido a que la lgica de negocios se ha removido de las vistas, la misma lgica de negocios puede ser reutilizada, sin modificacin potencial, y ser utilizada en otro tipo de interfaz totalmente diferente tal como Swing. Seguimiento de Usuarios y Registro de Sucesos

Permite el seguimiento de un usuario particular y el registro de sucesos relacionados con una actividad.

Validacin y Manejo de Errores

El controlador es capaz de manejar la validacin de datos y el Manejo de Errores, ya que estas operaciones deben ser realizadas por solicitud. Mejoras en el particionamiento de aplicaciones

El uso de ayudantes proporciona una separacin clara de las vistas con respecto a la lgica de procesamiento de la aplicacin. Los ayudantes, en la forma de JavaBeans y Etiquetas Personalizadas, proveen un lugar para colocar la lgica de procesamiento fuera de las pginas JSP.

6.- Patrn Dispatcher View

Contexto Los Sistemas manejan solicitudes Web. Los procesos de la capa de presentacin requieren la generacin de una vista basada en una plantilla y un modelo dinmico. Problema Los cambios de la capa de Presentacin ocurren a menudo y son difciles de desarrollar y mantener, debido a la combinacin de la lgica de negocio para el acceso a los datos y la lgica de formateo de la presentacin, esto hace que el sistema sea menos flexible, menos reutilizable, y menos adaptable a los cambios. Las porciones de lgica de negocio que son mezcladas con las vistas deben ser adaptadas al modelo intermedio para su visualizacin. Mezclar la lgica de negocio con el procesamiento de las vistas tambin reduce la modularidad y disminuye la separacin de roles a la hora de asignar tareas a los miembros de un equipo de desarrollo de software o de aplicaciones web. Fortalezas Necesidad de generacin dinmica de contenido El contenido requiere que los datos de negocio sean extrados dinmicamente. Los servicios de procesamiento comunes del sistema, tales como autenticacin y chequeo de permisologas deben realizarse por cada solicitud entrante. Encapsular la lgica de negocio en otros componentes distintos de las Vistas. Las Decisiones que afectan la recuperacin de contenido y la adaptacin de stos a un modelo para ser mostrados en las vistas son a menudo retrasadas hasta el momento en el que las vistas son procesadas. Los servicios del sistema y la lgica de manejo de vistas son bsicos y limitados en complejidad. El nmero de vistas que puede ser mapeado a una solicitud particular es reducido.

Solucin Combinar un Despachador con Vistas y Ayudantes para manejar las solicitudes de los clientes y preparar una presentacin dinmica como respuesta. Un despachador es responsable por el manejo de vistas y la navegacin, y puede ser o no encapsulado dentro de un controlador, o puede ser un componente independiente que trabaje de forma sincronizada con los componentes internos. Este patrn y el Service to Worker poseen una estructura similar, aunque cada patrn sugiere una divisin diferente de las labores que debe realizar cada componente. El Controlador y el Despachador tienen responsabilidades limitadas (como se mencion en el patrn anterior), debido a que el procesamiento principal y el manejo de vistas es muy bsico. Mas an, si el control centralizado de los recursos subyacentes es considerado innecesario, entonces el Controlador es removido y el Despachador puede ser movido a una Vista. Los patrones Service to Worker y Dispatcher View representan una combinacin comn de otros patrones, por lo cual cada uno garantiza a su propia manera una forma mas eficiente de comunicacin entre desarrolladores. En el patrn Dispatcher View, el Despachador posee un rol limitado en cuanto al manejo de Vistas. En el patrn Service to Worker, el Despachador posee un rol mucho mas relevante en cuanto al manejo de vistas. Un rol limitado para el Despachador ocurre cuando no se utilizan recursos externos para seleccionar una vista. La informacin encapsulada en la solicitud es suficiente para determinar las Vistas a utilizar para resolver una peticin. Por ejemplo en este caso: http://some.server.com/servlet/Controller?next=login.jsp La responsabilidad del Despachador es la de proporcionar acceso a la vista login.jsp Un ejemplo del Despachador con rol moderado es el caso en el cual el cliente enva una peticin directamente a un Controlador con un parmetro de una consulta que describe una accin que debe ser completada: http://some.server.com/servlet/Controller?action=login La responsabilidad del Despachador en este caso es la de traducir el nombre lgico login en el nombre de un recurso de una vista apropiada tal como lo es login.jsp y as proveer el acceso a dicha vista. Para llevar a cabo su traduccin, el Despachador puede acceder a recursos como un archivo XML de configuracin que especifique la vista que debe mostrarse. Por otro lado, en el patrn Service to Worker, el Despachador debe ser ms sofisticado, ya que este debe invocar las funciones de negocio necesarias para determinar las vistas que se van a mostrar. La estructura compartida anteriormente esta conformada Despachador, Vistas y Ayudantes. de estos dos patrones que se mencion por un Controlador que trabaja con un

Estructura La figura 3.8 muestra el diagrama de clases representa al patrn Dispatcher View:

Figura 3.8.- Diagrama de clases del Patrn Dispatcher View

Los componentes del diagrama de clases se especifican a continuacin: Controlador El Controlador es el punto de contacto inicial para el manejo de una solicitud. Este trabaja con un Despachador para completar el manejo de vistas y la navegacin. Despachador Un Despachador es responsable del manejo de Vistas y navegacin, ya que este se encarga de seleccionar la prxima vista a ser presentada al Usuario, adems de proveer un mecanismo para el control vectorizado de un recurso. Vista Una vista representa y visualiza informacin para los clientes. La informacin que es usada en una vista es tomada de un modelo. Ayudante Un ayudante es responsable de contribuir a completar el procesamiento que realiza una vista o un Controlador. As, los ayudantes tienen numerosas responsabilidades, incluyendo la recoleccin de datos requeridos por una vista y adaptarlos al modelo de datos usado por la vista. Los ayudantes pueden atender las solicitudes de datos de una vista con el simple hecho de proveerle a la misma acceso a los metadatos o formateando los datos como contenido Web. Una vista puede trabajar con cualquier nmero de ayudantes, los cuales son implementados tpicamente como JavaBeans y etiquetas personalizadas. Adicionalmente, un ayudante puede representar un objeto de tipo Command, Delegate o tambin un objeto de tipo XSLT, el cual es usado en combinacin con una hoja de estilo para adaptar y convertir el modelo a una forma apropiada.

Aunque las responsabilidades del Controlador estn limitadas a los servicios que posee el sistema, tales como autenticacin y autorizacin, a menudo resulta beneficioso centralizar estos aspectos del sistema. A diferencia del patrn Service to Worker, el Despachador no realiza invocaciones a mtodos de negocio para llevar a cabo su procesamiento y manejo de las vistas. Las funcionalidades del Despachador pueden ser encapsuladas dentro de su propio componente. Al mismo tiempo, cuando las responsabilidades del Despachador son limitadas, pueden ser almacenadas en otro componente De hecho, las funcionalidades del Despachador podran ser incluso realizadas por el contenedor, en el caso de que no se necesite lgica extra a nivel de aplicacin. Un ejemplo de esto, es una vista llamada main.jsp la cual tiene como alias el nombre first. El contenedor puede procesar esta peticin, traducir el alias al nombre fisico del recurso y entregar directamente dicho recurso: http://some.server.com/first De esta manera, el patrn Dispatcher View describe una serie de escenarios relacionados, movindose desde un escenario que es muy similar estructuralmente al patrn Service to Worker , hasta un escenario que es similar al patrn View Helper Consecuencias Control Centralizado

El control centralizado provee un lugar central para manejar los servicios del sistema a los largo de mltiples solicitudes. Aunque decisiones tales como seleccionar que JSP debe mostrarse se encuentran incluidas dentro de la peticin, el control centralizado permite al controlador mejorar el manejo de los servicios de seguridad y despacho. Reusabilidad

La lgica de negocios que se encuentra fuera de un JSP y dentro de JavaBeans o Etiquetas personalizadas puede ser reutilizada a lo largo de mltiples JSPs. El cdigo no es duplicado en varios JSPs, lo cual hace que la aplicacin sea ms fcil de mantener y depurar. Adicionalmente, debido a que la lgica de negocios se ha removido de las vistas, la misma lgica de negocios puede ser reutilizada, sin modificacin potencial, y ser utilizada en otro tipo de interfaz totalmente diferente tal como Swing. Seguimiento de Usuarios y Registro de Sucesos

Permite el seguimiento de un usuario particular y el registro de sucesos relacionados con una actividad. Validacin y Manejo de Errores

El controlador es capaz de manejar la validacin de datos y el Manejo de Errores, ya que estas operaciones deben ser realizadas por solicitud.

Mejoras en el particionamiento de aplicaciones

El uso de ayudantes proporciona una separacin clara de las vistas con respecto a la lgica de procesamiento de la aplicacin. Los ayudantes, en la forma de JavaBeans y Etiquetas Personalizadas, proveen un lugar para colocar la lgica de procesamiento fuera de las pginas JSP.

Patrones de la Capa de la Lgica de Negocios

1. Patrn Value Object

Contexto La aplicacin cliente necesita intercambiar datos con algn Enterprise Java Bean (EJB). Problema Los aplicaciones J2EE implementan componentes de negocios del lado de servidor como beans de sesin (session beans) y beans de entidad (entity beans). Los beans de sesin representan los servicio de la lgica de negocios y permiten mantener una relacin uno a uno con el cliente. Los beans de entidad, por su parte, son multiusuarios y representan la data persistente. Un bean de sesin provee mtodos de servicio de grano grueso cuando es implementado por medio del patrn Session Facade66 . Algunos de stos mtodos pueden retornar datos al cliente que realiza alguna invocacin a los mismos. Un bean de entidad implementa los componentes de negocio persistente. Permite exponer los valores de sus atributos mediante los mtodos de acceso (mtodos get) para cada atributo. Cuando un cliente necesita obtener mltiples valores de un entity bean, debe invocar a lo mtodos get respectivos hasta obtener la data correspondiente a cada atributo que requiera. Fortalezas Las aplicaciones J2EE implementan componentes de negocio como beans de entidad. Todos los accesos hacia un bean de entidad se realizan por medio de las interfaces remotas que provee el bean. Cada llamada a un enterprise bean es potencialmente una llamada a un mtodo remoto, lo cual recae en una sobrecarga para la red. Por lo general, las aplicaciones utilizan con mayor frecuencia de operaciones de lectura que de actualizacin. La data se transfiere desde la lgica de negocio hacia la capa presentacin, despliegue y posteriormente al cliente. El nmero de llamadas que realiza el cliente hacia los EJB tiene un gran impacto sobre el rendimiento de la red, debido a la sobrecarga que se genera por cada peticin. Solucin Se puede utilizar un Value Object para encapsular la data del negocio. La llamada a un mtodo sencillo puede ser utilizado para enviar y recibir el Value
6

En secciones posteriores se describir con mayor detalle el funcionamiento de este patrn.

Object. Cuando el cliente le solicita al enterprise bean los datos de negocio, el bean puede construir el Value Object, rellenarlo con los valores de los atributos, y retornarlo al cliente. Los clientes por lo general requieren ms de un valor de un enterprise bean. Para reducir el numero de llamadas remotas y evitar por consiguiente la sobrecarga asociada, resulta ms conveniente utilizar el Value Object para transportar la data desde el enterprise bean hacia el cliente. Cuando el enterprise bean utiliza un value object, el cliente realiza una sola invocacin al bean obteniendo como resultado el value object en lugar de realizar mltiples llamadas para obtener cada uno de los atributos. Luego el bean instancia un value object y copia los valores de sus atributos en la instancia del objeto que acaba de crear. Finalmente retorna el value object al cliente. Estructura La figura 3.9 muestra el diagrama de clases representa al patrn Value Object:

Fig.3.9 Diagrama de clases para el patrn Value Object Consecuencias Simplifica al Entity Bean y a su interfaz remota

El entity bean provee un mtodo getData() para obtener el value object que contiene los valores de los atributos deseados. Esto elimina la necesidad de tener multiples metodos get, as como su respectiva implementacin en el bean y su definicin en la interfaz remota. Similarmente, si el entity bean provee un mtodo SetData(), se podran eliminar tambin los mtodos set del bean en la implementacin y de igual forma en la interfaz remota. Reduce el trfico de la red. Propagacin de la actualizacin

Si se adopta la estrategia del patrn value object los clientes pueden realizar modificaciones en la copia local, es decir, el objeto value object. Una vez que se realizan dichas modificaciones, el cliente puede invocar al mtodo setData() y actualizar los valores en el objeto entidad. Aunque esto puede traer problemas ya que otros clientes pueden haber realizado el mismo procedimiento, ya que no es posible determinar en primera instancia si ya se han modificado otros valores por parte de los clientes.

Sincronizacin y control de versiones

Cuando se reciben mltiples actualizaciones de dos o ms clientes de manera simultnea el bean de entidad debe estar en capacidad de manejar dicha situacin. El control de versiones es una manera de prevenir los conflictos que se puedan presentar. bean de entidad puede incluir como uno de sus atributos el nmero de la versin y la ultima estampa de tiempo (timestamp) relativa a su modificacin; ya que as, dicho atributo puede ser utilizado a la hora de resolver conflictos de versiones. Se reduce la duplicacin de cdigo

Es posible reducir o eliminar la duplicacin de cdigo entre la entidad y su value object correspondiente. Sin embargo, al realizar la implementacin de algunas estrategias para este patrn pueden incrementar la complejidad a la hora de realizar la implementacin del diseo. Nmero de llamadas Vs. cantidad de datos enviados

En lugar de realizar mltiples llamadas para obtener los valores de los atributos, sta solucin provee un mtodo nico para realizar la llamada. Aunque muchas veces la llamada a dicho mtodo puede retornar gran cantidad de datos. Por lo cual se debe considerar la relacin entre el nmero de llamadas que se deben realizar al bean versus la cantidad de datos obtenidos por llamada.

2. Patrn Business Delegate

Contexto El sistema expone sus servicios de negocio por medio de un API a sus clientes, a travs de una red.

Problema Los componentes de la capa de presentacin interactan directamente con los servicios de la lgica de negocios. Esta interaccin expone los detalles de implementacin del API de la capa de lgica de negocios hacia la capa de presentacin. Como resultado de esto, los componentes de la capa de presentacin son vulnerables a los cambios de implementacin que se realicen en la capa de lgica de negocios. Adicionalmente, podra existir un detrimento serio en el rendimiento de la red, debido a que los componentes de la capa de presentacin que utilizan el API de la capa de lgica de negocios, podran realizar mltiples invocaciones a travs de la red. Esto ocurre cuando los componentes de la capa de presentacin no poseen mecanismos de cach o servicios agregados. Finalmente, la exposicin directa del API a los clientes, el mismo, se va obligado a lidiar con la nter conectividad a la cual esta asociada la tecnologa de los EJB.

Fortalezas Los clientes de la capa de presentacin necesitan acceder a los servicios de negocio. Los dispositivos clientes (incluyendo clientes ricos) necesitan acceder a los servicios de la lgica de negocios. El API de los servicios de la lgica de negocios puede cambiar al igual que los requerimientos del negocio. La meta debe ser minimizar el acoplamiento entre la capa de presentacin y el API de los servicios de la lgica de negocios. As se ocultan detalles de implementacin de los servicios, como la bsqueda y el acceso. Sera deseable implementar mecanismos de cach para la informacin de los servicios de la lgica de negocio. Sera deseable reducir el trfico de red entre el cliente y los servicios de la lgica de negocios. El Business Delegate podra ser visto como una capa innecesaria entre el cliente y los servicios. Por otra parte introduce complejidad y decrementa la flexibilidad.

Solucin Se puede utilizar el patrn Business Delegate para reducir el acoplamiento entre la capa de presentacin y los servicios de la lgica de negocios. El Business Delegate esconde los detalles de implementacin de la lgica de negocios, como por ejemplo bsqueda (lookup) y los detalles de acceso a la arquitectura de los EJB. El Business Delegate se podra pensar como una abstraccin de la lgica de negocios de lado del cliente. El mismo, tambin puede manejar las excepciones que se generen desde la lgica de negocios como por ejemplo las excepciones de los EJB, as como tambin de alguno de los componentes de JMS, entre otras. Con lo cual es posible interceptar dichas excepciones y generar excepciones a nivel de aplicacin que busquen explicar con mayor exactitud la falla o el error suscitado en un momento determinado. Otro beneficio es que dicho patrn puede manejar una cach de resultados, con lo cual aumenta significativamente el rendimiento, debido a que evita el consumo de recursos innecesarios debido a mltiples peticiones viajando por la red. El Business Delegate utiliza un componente llamado Lookup Service. El Lookup Service es el responsable de ocultar los detalles de implementacin del cdigo de bsqueda dentro de la lgica de negocios. El Lookup Service pueden ser escrito como parte del Business Delegate, aunque es recomendable utilizarlo de forma autnoma. Finalmente, hay que destacar que este patrn puede reducir la complejidad entre otras capas y no slo entre la capa de presentacin y la de lgica de negocios.

Estructura La figura 3.10 muestra el diagrama de clases representa al patrn Business Delegate:

Fig.3.10 Diagrama de clases para el patrn Business Delegate Consecuencias Reduce el acoplamiento, mejora la gestin:

Reduce el acoplamiento entre la capa de presentacin y la capa de lgica de negocios, ocultando todos los detalles de implementacin. Tambin facilita la gestin a la hora de realizar cambios, ya que todo se encuentra centralizado en un solo lugar, el BusinessDelegate. Traduccin de excepciones especficas:

El BusinessDelegate es el responsable de traducir cualquier excepcin de la red u otras que se puedan presentar en excepciones del negocio, abstrayendo al cliente de los detalles especficos de la implementacin. Impacto en el rendimiento:

El BusinessDelegate puede proveer mecanismos de cach (con lo cual mejora el rendimiento) a la capa de presentacin para los servicios que realicen peticiones frecuentes.

3. Patrn Aggregate Entity

Contexto Los beans de entidad no estn concebidos para representar cada uno de los objetos persistentes dentro del modelo de objetos. Los beans de entidad se ajustan mejor para representar los objetos del negocio persistentes de grano grueso. Problema En una aplicacin J2EE, los clientes (aplicaciones, Java Server Pages, Servlets y Java Beans), acceden los beans de entidad por medio de sus interfaces remotas. As, cada invocacin potencial, realiza un direccionamiento a travs de stubs y skeletons, incluso si el cliente y el enterprise bean se encuentran en la misma mquina virtual de Java, bajo el mismo sistema operativo o en la misma mquina. Cuando se utilizan beans de entidad de grano fino, lo clientes tienden a invocar a mltiples mtodos de un bean de entidad, lo cual resulta en una sobrecarga de la red. Los beans de entidad representan los objetos persistentes del negocio. Cuando se desarrollan o se migran aplicaciones a la plataforma J2EE, la granularidad de los objetos es un factor muy importante a la hora de decidir que se debe implementar como un bean de entidad y que no. Los beans de entidad deben representar los objetos del negocio de grano grueso, es decir, aquellos que posean un comportamiento complejo ms all de simplemente obtener y actualizar campos de datos. Estos objetos de grano grueso por lo general poseen objetos dependientes, los cuales no tienen significado alguno dentro del dominio de la aplicacin sino se asocian a algn objeto de grano grueso. Un problema recurrente es la correspondencia entre el modelo objeto y el modelo de los EJB (especficamente los beans de entidad). Esto crea una relacin entre los beans de entidad sin considerar la granularidad de los objetos, es decir, si son de grano grueso o no (o dependientes). Determinar la granularidad no es sencillo y por lo general se realiza a partir de las relaciones establecidas en los diagramas de UML. El inconveniente que se genera cuando se establecen mltiples beans de entidad de grano fino y sus relaciones, es que sin importar si dichos beans residen o no en el mismo contenedor, las llamadas entre los mismos son tratadas como llamadas remotas que atraviesan la capa de red y estn sujetos a la misma sobrecarga que se genera cuando un cliente realiza mltiples llamadas remotas a un bean de entidad. Fortalezas Los beans de entidad se implementan por lo general como objetos de grano grueso debido a la alta sobrecarga que generan los mismos. Cada bean de entidad esta asociado a un EJB home, un objeto remoto, as, como a su implementacin como tal, y cada uno de ellos es manejado por los servicios del contenedor. Las aplicaciones que realizan una correspondencia directa entre el esquema de una base de datos relacional y los beans de entidad (donde cada fila esta representada por una instancia de un bean de entidad), tienden a poseer una gran cantidad de beans de entidad de grano fino. Sera deseable mantener beans de entidad de grano grueso y as reducir el nmero de beans de entidad dentro de la aplicacin.

Adems, la correspondencia directa entre el bean de entidad y la base de datos trae como consecuencias problemas que afectan el rendimiento, la gestin, la seguridad y el manejo de transacciones. Por otra parte, los clientes no necesitan conocer detalles de la implementacin de la base de datos o la forma en la cual los beans de entidad interactan con la misma. Aunque si esta correspondencia se realiza utilizando beans de entidad de grano fino, el cliente va a interactuar directamente con dichos componentes, que es esencialmente una representacin del esquema de la base de datos relacional. Esto trae como consecuencia que exista un acoplamiento estrecho entre el cliente, los beans de entidad y la base de datos. Por consiguiente cualquier cambio en el diseo de la base de datos, afecta directamente tanto a los beans de entidad, como al cliente. Esto incrementa el intercambio entre aplicaciones debido a la intercomunicacin que existe entre los beans de entidad de grano fino, lo cual conlleva a una baja considerable en el rendimiento de la red y de la aplicacin. Sera deseable reducir el intercambio de datos entre el cliente y los beans de entidad. Solucin El bean de Aggregate entity se utiliza para modelar, representar y realizar la gestin de un conjunto de objetos persistentes inter-relacionados, en lugar de representarlo como beans de entidad de grano fino. Tambin se puede visualizar como la representacin de un rbol de objetos. Para entender la agregacin en el contexto de este patrn, primero se debe entender en que consisten los objetos persistentes y sus relaciones en la aplicacin. Un objeto persistente es un objeto que se encuentra almacenado en algn medio. Por lo general, los clientes pueden compartir objetos persistentes. Un objeto de grano grueso es auto suficiente. Es decir, posee su propio ciclo de vida y gestiona sus relaciones con otros objetos. Cada uno de ellos puede referenciar o contener uno o ms objetos. Por esta razn, el objeto de grano grueso tambin gestiona los ciclos de vida de los objetos que contiene. Dichos objetos se conocen con el nombre de objetos dependientes. Los objetos dependientes a su vez, pueden contener otros objetos dependientes. Una bean de aggregate entity puede representar a un objeto de grano grueso y a todos sus objetos dependientes. La agregacin combina los objetos persistentes interrelacionados en un nico bean de entidad, lo cual reduce drsticamente el nmero de beans de entidad requeridos por la aplicacin. Esto conlleva a que con el uso de beans de entidad de grano grueso se obtengan mayores beneficios que si se utilizaran beans de grano fino. Ya que sin este enfoque, la tendencia natural llevara a tener una gran cantidad de beans de entidad. Estructura Existen muchas estrategias para implementar el patrn Aggregate Entity. A continuacin la figura 3.11 presenta la ms genrica, la cual contiene objetos componentes de grano grueso.

Fig 3.11 Diagrama de clases para el patrn Aggregate Entity. Consecuencias Relaciones

Si se utiliza el patrn Agreggate Entity, los objetos dependientes son agregados como un bean de entidad nico, eliminando as todas las relaciones inter beans de entidad. Este patrn provee una forma centralizada de gestin tanto para las relaciones como para la jerarqua de objetos. Gestin eficiente

La implementacin de objetos persistentes como beans de entidad de grano fino, trae como consecuencia que se deban desarrollar y mantener una gran cantidad de clases. Utilizando este patrn se reduce el nmero de clases EJB, as como tambin el cdigo, flexibilizando de esta forma la gestin en componentes de grano grueso, en lugar de los de grano fino.

Rendimiento de Red

Debido a la agregacin de los objetos dependientes, se elimina la comunicacin entre los componentes de grano fino, as como tambin la dependencia de los objetos a travs de la red. Si cada objeto se designara como un bean de entidad de grano fino, la sobrecarga de la red debido a la comunicacin intercomponentes sera grande.

Dependencia del esquema de la base de datos

Los resultados de aplicar este patrn generan beans de entidad de grano grueso en su implementacin. El esquema de la base de datos es transparente para el cliente, ya que la correspondencia se realiza con los beans de entidad de grano grueso. Sin embargo, si ocurren cambios en el esquema de la base de datos, se deben realizar cambios en los beans de aggregate entity. Sin embargo, los clientes no se vern afectados.

Granularidad de los objetos (grano grueso vs. grano fino)

Como resultado de aplicar este patrn, el cliente por lo general busca sobre un bean de entidad particular, en lugar de una cantidad numerosa de ellos de granularidad fina. El cliente solicita al Agreggate entity los datos, l mismo puede crear un objeto compuesto que contenga los valores necesarios desde el bean de entidad y retornar el objeto correspondiente al cliente, en una sola llamada. Esto reduce el intercambio entre el cliente y los EJB.

4. Patrn Value Object Assembler

Contexto En las aplicaciones J2EE, los componentes del negocio del lado del servidor se implementan utilizando los beans de sesin, los beans de entidad, entre otros. Los clientes de la aplicacin necesitan con frecuencia datos compuestos a partir de mltiples objetos. Problema Los clientes de la aplicacin, por lo general requieren de un modelo o de parte del mismo, para presentar al usuario como se realiza el procesamiento intermedio antes de que se presenten los servicios. Este modelo es una abstraccin de la lgica de negocios implementada del lado del servidor y puede ser expresado como una coleccin de objetos estructurados en forma de rbol o expresados a travs de un grafo. Para que un cliente pueda obtener los datos que requiere siguiendo este modelo debe acceder individualmente a cada uno de los objetos que se definen en l mismo y obtener la informacin. Este enfoque posee varias desventajas: 1. Debido a que el cliente debe acceder individualmente a cada componente distribuido, existe un acoplamiento entre el cliente y los dichos componentes del modelo a travs de la red. 2. El cliente accede a los componentes distribuidos por medio de la capa de red, esto puede traer como consecuencia que si se crea un modelo de gran complejidad con mltiples componentes, el rendimiento de la red se vea seriamente afectado, por la cantidad de accesos que se realizan. 3. El cliente debe reconstruir el modelo una vez que obtiene la parte del mismo que viene del componente distribuido. Por lo cual, el cliente necesita tener la informacin necesaria de la lgica de negocios para construir el modelo. Si la construccin de dicho modelo involucra numerosos objetos en su definicin y una gran complejidad, entonces se presenta una sobrecarga adicional sobre del lado del cliente debido a ste procesamiento. 4. Debido a que el cliente se encuentra fuertemente acoplado a este modelo, los cambios que se realicen sobre el modelo, recaen directamente en modificaciones sobre el cliente. Si existe ms de un tipo de cliente, cada vez se hace ms difcil manejar los cambios del modelo.

Fortalezas Se requiere la separacin de la lgica de negocios entre el cliente y los componentes del lado del servidor. Debido a que modelo est conformado por componentes distribuidos, el acceso a los mismos est asociado a una posible sobrecarga de la red. Sera deseable minimizar el numero de llamadas a los mtodos remotos a travs de la red. Por lo general el cliente necesita obtener el modelo slo para presentrselo al usuario. Si el cliente debe interactuar con mltiples componentes para construir dicho modelo justo en ese momento, el intercambio de informacin y datos se incrementa notablemente entre el cliente y la aplicacin. Esto puede contribuir a que se vea afectado el rendimiento de la red. Si el cliente requiere realizar una actualizacin, usualmente solo puede actualizar parte del modelo y la totalidad del mismo. El cliente no necesita estar al tanto de las dependencias y los asuntos intrnsicos referente a la implementacin del modelo. Sera deseable eliminar el acoplamiento que existe entre los clientes y los componentes de la lgica de negocios que se implementan dentro del modelo de la aplicacin. Los clientes no necesitan tener una lgica de negocios adicional para construir el modelo a partir de diversos componentes de negocios.

Solucin

Se debe utilizar el patrn Value Object Assemble para construir el modelo requerido o un sub-modelo. El Value Object Assembler utiliza value objects para obtener los datos de mltiples objetos de la lgica de negocios y de otros objetos que definen el modelo o parte del mismo. El Value Object representa la data de los diversos componentes del negocio. La intencin de utilizar el ValueObject es llevar toda la data necesaria del modelo hacia el cliente en una sola llamada. Cuando el cliente necesita obtener el modelo de datos, y el modelo esta reprensentado por componentes de grano grueso (como por ejemplo una entidad agregada), el proceso para obtenerlo es sencillo. El cliente simplemente solicita el componente de grano grueso por su value object correspondiente y obtiene la informacin. Sin embargo, la mayora de las aplicaciones poseen modelos que son una combinacin de componentes de grano grueso y otros de grano fino. En este caso, el cliente debe interactuar con numerosos componentes del negocio para obtener toda la data necesaria para representar el modelo. Una consecuencia inmediata de este enfoque es que el cliente se vuelve dependiente del modelo de implementacin y ste tiende a realizar mltiples llamadas a los mtodos remotos para obtener la data de cada componente de manera individual. En algunos casos, un componente de grano grueso, provee el modelo o parte de l como un value object (simple o compuesto). Sin embargo, cuando el modelo est representado a travs de mltiples componentes, un value object (simple o compuesto) no especifica el modelo entero. Para representar este modelo, es necesario obtener el value object correspondiente a cada uno de los componentes involucrados y ensamblarlos en un objeto compuesto value object nuevo. El servidor debe ser el encargado de realizar esta tarea y no el cliente.

Estructura La figura 3.12 muestra el diagrama de clases representa al patrn Value Object Assembler:

Fig 3.12 Diagrama de clases del patrn Value Object Assembler. Consecuencias

Separacin de la lgica de negocios

Cuando el cliente utiliza la lgica de negocios para gestionar las interacciones con los componentes distribuidos, se dificulta mucho separar de manera clara la lgica de negocios de la capa del cliente. Con el Value Object Assembler el cliente no necesita conocer como est construido el modelo o los diversos componentes que proveen la data necesaria para ensamblar el modelo. Prdida del acoplamiento entre los clientes y el modelo de la aplicacin El Value Object Assembler esconde la complejidad de la construccin del modelo de datos de sus clientes y elimina el acoplamiento entre los clientes y el modelo. Con esta perdida del acoplamiento, si el modelo cambia, los cambios no se veran reflejados directamente en el cliente, sino en el ValueObjectAssembler. Rendimiento de la red

Se reduce drsticamente la sobrecarga de la red debido a llamadas a mtodos remotos y otra operaciones inherentes a la aplicacin. El cliente puede solicitar la data de la aplicacin mediante una invocacin a un solo mtodo remoto. El ensamblador construye y retorna el objeto compuesto para el modelo. Cabe destacar que siempre es importante tomar en cuenta la relacin cantidad de llamadas realizadas vs. cantidad de datos enviados si se considera el uso de este patrn. Rendimiento del cliente

El Value Object Assembler permite construir el modelo como una composicin de value objects sin utilizar ningn recurso del lado del cliente. El cliente no consume tiempo y recursos en esta operacin.

5. Value List Handler

Contexto El cliente requiere una lista de items de un servicio para su presentacin. El nmero de items en esta lista es desconocido y puede llegar a ser muy grande en algunas ocasiones. Problema La mayora de las aplicaciones poseen J2EE requieren de operaciones de bsqueda para obtener y listar cierta cantidad de datos. En algunos casos, como en las consultas a bases de datos, los resultados obtenidos pueden ser de una gran dimensin. Sera poco prctico retornar esta cantidad de datos como un solo conjunto de resultados, en vez de que el mismo puede recorrer de manera gradual los datos obtenidos. Otro problema surge cuando se utilizan los mtodos ejbFind de los beans de entidad para obtener una lista de valores. Estos retornan una coleccin de objetos remotos y posteriormente se llaman a los respectivos mtodos uno a uno para obtener los valores deseados, esto se considera como una mala prctica y adems representa un gran consumo de recursos de red. Esta sobrecarga puede impactar significativamente en el rendimiento de la aplicacin que incluyen bsquedas o consultas que retornar una gran cantidad de datos. Fortalezas La aplicacin cliente necesita realizar una bsqueda eficiente, para evitar mltiples llamadas a los mtodos de bsqueda de los beans de entidad. El mecanismo de cach del lado del servidor que se necesita para servir a los clientes, no puede recibir y procesar el conjunto de datos por completo. Una sentencia que se ejecute repetidamente sobre una data razonablemente esttica puede ser optimizada para obtener mejores resultados. Esto depende de la aplicacin y de la implementacin utilizada de este patrn. Los mtodos de bsqueda de los EJB no son apropiados para la exploracin de tablas enteras en la base de datos o para realizar la bsqueda de un conjunto de datos de tamao considerable de una tabla. Los mtodos de bsqueda pueden generar una sobrecarga considerable cuando se utiliza para obtener una gran cantidad de objetos, debido a que el contenedor de beans puede crear una gran cantidad de objetos de infraestructura para facilitar este proceso. Los mtodos de bsqueda de los EJB no son apropiados para realizar la cach de resultados. El cliente puede no estar en capacidad de manejar todo el conjunto de resultados obtenidos en una sola llamada. Si es necesario, el cliente puede requerir de mecanismos de cach del lado del servidor, as, como tambin. Los mtodos de bsquedas de los EJB ofrecen poca flexibilidad. La especificacin EJB 2.0 permite el uso de el lenguaje de consulta EJB QL para los beans con persistencia manejada por el contenedor. El

EJB QL facilita la construccin de mtodos de bsqueda, as como tambin ofrece gran flexibilidad a la hora de realizar consultas. El cliente desea recorrer los datos hacia atrs o adelante, segn sea el caso, dentro del conjunto de datos.

Solucin Se debe utilizar el patrn Value List Handler para controlar la bsqueda, mantener una cach de resultados y proveer los resultados al cliente en un espacio de resultados, el cual satisfaga las necesidades del mismo. Este patrn crea un ValueListHandler para proveer la funcionalidad de ejecucin de querys y del cach de resultados. El ValueListHandler accede directamente al objeto de Acceso a Datos (Data Access Object) que es el que puede ejecutar el query requerido. El ValueListHandler almacena el resultado obtenido desde el Data Access object como una coleccin de value objects. El cliente es el que le pide al ValueHandlerList que le provea de los resultados que necesita. El ValueListHandler implementa el patrn Iterator(2) para proveer esta solucin. Estructura La figura 3.13 ilustra el diagrama de clases del patrn Value List Handler.

Fig. 3.13 Diagrama de clases para el patrn Value List Handler.

Consecuencias. Reduce la sobrecarga de recursos generada por los mtodos de los EJB.

El mtodo find del EJB por lo general es un recurso de uso intensivo y una manera muy costosa de obtener una lista de valores, ya que involucra numerosas referencias a objetos EJB. El patrn Value List Handler implementa un bean de sesin que utiliza un objeto de acceso a los datos (DataAccessObject) para realizar las consultas respectivas y crear una coleccin de value objects que cumplan con los criterios de la bsqueda. Dado que estos value objects poseen una sobrecarga mucho menor si se comparan con los objetos EJB, este patrn provee beneficios cuando la aplicacin cliente requiere consultar una gran cantidad de datos. Mecanismos de cach de los resultados de las consultas del lado del servidor y despacho de resultados controlado del lado del cliente. Este patrn permite que el conjunto de datos obtenidos al realizar una bsqueda sean manejados por mecanismos de cach del lado del servidor mediante un bean de sesin. Cuando el cliente solicita el conjunto de datos o un subconjunto de datos, el bean manejador retorna los resultados como una coleccin de objetos serializados. El cliente recibe esta coleccin y la puede procesar o mostrar. Cuando el cliente necesite otro conjunto de datos, le solicita al manejador otra coleccin serializada de objetos que proveen los resultados que se requieran y as sucesivamente. El bean manejador tambin debe proveer al cliente facilidades de navegacin (atrs o adelante) al cliente y que le permitan realizar recorridos sobre el conjunto de datos obtenido. Flexibilidad de consultas

Cuando se aade una nueva consulta, por lo general se requiere un nuevo mtodo find o la modificacin de uno ya existente, especialmente cuando se utiliza la persistencia manejada por el bean (con la persistencia manejada por el bean, el desarrollador implementa los mtodos de bsqueda en conjunto con la implementacin del bean). Cuando la persistencia es manejada por el contenedor, el desarrollados especifica los mtodos de bsqueda del bean de entidad en el descriptor de despliegue del bean. Los cambios que se realicen bajo el esquema de la persistencia manejada por el contenedor requieren cambios en el descriptor de despliegue. Se podria realizar una implementacin del patrn Value List Handler que permita hacer ms flexible los mtodos de bsqueda y que provea facilidades para consultas adhoc, construccin de consultas en tiempo de ejecucin usando mtodos como templates, y as sucesivamente. En otras palabras, este patrn puede implementar bsquedas inteligentes y algoritmos de almacenamiento sin estar limitado slo a los mtodos de bsqueda de los beans. Rendimiento de la red

Mejora el rendimiento de la red debido a que los datos requerido son enviados (de manera serializada) al cliente a medida que se necesiten, en lugar de enviarlos todos al mismo tiempo. As, si el cliente muestra solo los primeros resultados y posteriormente decide abandonar la consulta, el ancho de banda de la red no es subutilizado, dado que los datos no fueron enviados en su totalidad al cliente, aunque ste no hiciera uso de los mismos. Sin embargo, si el cliente sabe que el conjunto de datos va a ser procesado en su totalidad, esto recae

sobre mltiples llamadas al servidor. Por lo cual en este caso se puede proveer un mtodo que enva al cliente el conjunto de datos en una sola llamada, y el mecanismo de cach que provee el patrn no se utilizara para esa caso en particular.

6. Patrn Service Locator

Contexto Bsqueda y creacin de algn servicio que involucre interfases complejas y operaciones de red. Problema Los clientes J2EE interactan con los componentes del servicio como los EJB y los componentes de JMS, los cuales proveen los servicios de negocios y la persistencia. Para realizar la interaccin con dichos componentes, los clientes deben localizar el componente del servicio (esto se conoce tambin como operacin de bsqueda) o crear un nuevo componente. Por ejemplo, un cliente EJB debe localizar el objeto home del enteprise bean, que posteriormente utilizar para localizar un objeto, o bien crear o remover alguno de los ya existentes. De manera similar, un cliente JMS debe localizar en primera instancia la Factora de conexiones JMS (JMS Connection Factory) para obtener una conexin JMS o una sesin JMS. As, localizar un objeto de servicio administrado por JNDI es una situacin comn con la cual el cliente debe lidiar. Si este es el caso, por lo general son mltiples los tipos de clientes que utilizan los servicios JNDI, por lo cual la mayora de las veces el cdigo de utilizacin de estos servicios aparecen duplicados. Esto resulta en una duplicacin innecesaria de cdigo para realizar estas operaciones. Tambin, la creacin del contexto inicial de los objetos de JNDI y la realizacin de bsquedas sobre el objeto EJB home tiene un alto consumo de recursos. Si mltiples clientes requieren en reiteradas oportunidades el mismo objeto EJB Home, el esfuerzo por duplicar dichos objetos tendra un impacto negativo sobre el rendimiento de la aplicacin. Finalmente, el proceso de bsqueda y creacin de componentes por lo general depende de la implementacin que haya realizado el fabricante del contexto de la factora. Esto introduce una dependencia del cliente hacia el fabricante cada vez que necesite utilizar algunos de los servicios que provee JNDI para localizar enterprise beans y componentes JMS como colas, tpicos y factoras de objetos de conexin. Fortalezas Los clientes de los EJB necesitan utilizar el API de JNDI para buscar los objetos EJBHome por medio del nombre registrado en el servicio de JNDI. Los clientes de JMS necesitan utilizar el API de JNDI para buscar los componentes de JMS por medio de los nombres registrados para los componentes de JMS, como por ejemplo las factoras de conexin, las colas y los tpicos. La factora del contexto se utiliza para la creacin del contexto inicial de JNDI, el cual es realizado por el tambin depende del tipo de objeto que se necesite buscar, por ejemplo, el contexto para JMS es

diferente al contexto para los EJB, de los distintos proveedores. proveedor del servicio y posteriormente por el vendedor especfico. La bsqueda y creacin de los componentes del servicio puede ser complejo y se puede utilizar repetidamente en mltiples clientes dentro de la aplicacin. La creacin del contexto inicial y la bsquedas del objeto de servicio, son operaciones frecuentes, las cuales pueden consumir muchos recursos y pueden impactar directamente sobre el rendimiento de la aplicacin. Esto se aprecia mayormente cuando el cliente y el servicio que se necesita se encuentran en diferentes capas. Los clientes de los EJB podran necesitar reestablecer la conexin a un bean accedido previamente solamente mediante un manejador para el objeto manejador del EJB.

Solucin Se debe utilizar el objeto Service Locator para realizar una abstraccin del uso de JNDI y as ocultar su complejidad para realizar los procesos de la creacin del contexto inicial, la bsqueda del objeto EJB Home y la re-creacin del objeto EJB. Mltiples clientes pueden reutilizar el objeto Service Locator para reducir la complejidad del cdigo y as proveer un punto particular de control y aumentando el rendimientos, mediante la inclusin de mecanismos de cach. Este patrn reduce la complejidad del cliente que resulta de la dependencia y la necesidad de realizar procesos de bsqueda y creacin. Para eliminar estos problemas, este patrn provee un mecanismo que realiza una abstraccin de todas las dependencias y de los detalles de red dentro del Service Locator. Estructura La figura 3.14 ilustra el diagrama de clases del patrn Value List Handler.

Fig. 3.14 Diagrama de clases para el patrn Service Locator

Consecuencias Abstraccin de la complejidad

El patrn Service Locator encapsula la complejidad de los procesos de bsqueda y creacin (descritos en el problema) y mantiene los mantiene oculto del cliente. El cliente no necesita manipular directamente con los componentes de la factora de objetos, debido a que es el ServiceLocator a quien se le delega dicha responsabilidad. Provee a los clientes acceso uniforme al servicio

Este patrn realiza una abstraccin de todos los detalles de complejidad mencionados anteriormente. La interfaz del patrn asegura que todos los tipos de clientes en la aplicacin accedan de manera uniforme a los objetos del negocio, en trminos de su creacin y/o bsqueda. Esta uniformidad reduce el desarrollo y el mantenimiento de la aplicacin. Adicin de nuevos componentes de negocios

Debido a que los objetos EJBHome no son percibidos directamente por el cliente, es posible aadir nuevos objetos al EJBHome para los enterprise beans desarrollados sin que esto tenga un impacto potencial sobre el cliente. De igual forma, esta situacin se presenta para los componentes de JMS. Rendimiento de la red

Los clientes no se involucran directamente en la creacin y/o bsqueda de los objetos por medio de JNDI. Debido a que el Service Locator realiza esta labor, solo se realizan las llamadas por medio de la red cuando sea necesario, evitando as la sobrecarga que se produce por mltiples llamadas a mtodos remotos. Rendimiento de la cach El Service Locator puede establecer una cach con los objetos del contexto inicial y sus referencias a los objetos de la factora (EJBHome, factoras de conexiones JMS), para eliminar actividades innecesarias de JNDI que se suscitan cuando se obtiene el contexto inicial y otros objetos. Esto mejora el rendimiento de la aplicacin.

Patrones de la Capa de Integracin

1.- Patrn Data Access Object

Contexto El acceso a los datos puede variar dependiendo del origen de los datos(datasource). El acceso a almacenes persistentes de datos, tales como una base de datos, vara grandemente dependiendo del tipo de almacenamiento (bases de datos relaciones, orientadas a objetos, etc) y la implementacin del fabricante. Problema Muchas aplicaciones J2EE pueden requerir el uso de data persistente en algn momento. Para muchas aplicaciones, los repositorios persistentes utilizan mecanismos diferentes y existen grandes diferencias entre las APIs usadas por los distintos repositorios. Otras aplicaciones pueden necesitar acceder a los datos que residen en un mainframe, un servicio B2B o un repositorio LDAP. Tpicamente, las aplicaciones usan componentes distribuidos compartidos para representar la data persistente. Una aplicacin es analizada para determinar si debe utilizar persistencia manejada por el bean(BMP) o por el contenedor de beans(CMP). Las aplicaciones pueden usar el API JDBC para acceder a los datos residentes en una base de datos relacional. El API JDBC permite un acceso estndar y manipulacin de datos en un almacenamiento persistente. JDBC permite a las aplicaciones J2EE usar sentencias SQL, las cuales son estndar para el manejo de tablas en bases de datos relacionales. Sin embargo, incluso dentro de un ambiente relacional, la sintaxis y el formato de las sentencias SQL puede variar dependiendo del manejador de base de datos que se utilice. Existen variaciones mucho mayores que involucran la combinacin de varios tipos de almacenamiento. Los mecanismos de acceso, las APIs soportadas, y las caractersticas pueden variar drsticamente cuando se trata de comparar un tipo de almacenamiento persistente como una base de datos relacional con otro tipo de almacenamiento persistente. Las aplicaciones que necesitan acceder a datos que sen encuentran en sistemas legacy por lo general necesitan emplear APIs propietarias. Los datasources diferentes ofrecen dificultades a la aplicacin y puede crear una dependencia muy fuerte entre el cdigo de la aplicacin y el cdigo de integracin. Cuando los componentes de negocio necesitan acceder a un data source, pueden usar el API adecuada para lograr conectarse a un datasource y as manipular los datos que se encuentran en l. Pero, incluyendo la conectividad y el cdigo de acceso a los datos dentro de estos componentes puede generar una dependencia entre los componentes y la implementacin usada por el datasource. Esa dependencia de cdigo hace difcil y tedioso migrar la aplicacin de un tipo de datasource a otro, ya que cuando el datasource cambia los componentes deben ser cambiados tambin. Fortalezas Componentes tales como Entity beans de Tipo BMP, Beans de Sesin y Servlets necesitan obtener y almacenar datos de repositorios persistentes y otros Data source como sistemas legacy, B2B, LDAP, etc.

Las APIs usadas para acceder a los repositorios persistentes varan de acuerdo al fabricante del producto. Algunos data source pueden tener APIs no estndares o propietarias. Estas APIs y sus capacidades tambin varan segn el tipo de almacenamiento (Bases de datos relacionales, documentos XML, archivos planos. Etc). Existe una carencia de uniformidad en las APIs para el manejo de los requerimientos de acceso a datos que pueda tener el sistema. Los componentes que acceden a sistemas de tipo legacy para obtener y almacenar datos por lo general utilizan APIs propietarias. La portabilidad de los componentes se ve afectada directamente cuando mecanismos de acceso especficos y APIs son incluidos en los componentes. Los componentes necesitan deben tener un acceso a los datos transparentes totalmente independiente de las implementaciones que posean los Data source, para as permitir que se realice ms fcilmente la migracin entre diferentes productos de diferentes fabricantes.

Solucin Usar un Objeto de Acceso a Datos para abstraer y encapsular todos los accesos realizados al origen de los datos. Los Objetos de Acceso a Datos manejan la conexin con el origen de datos para obtener y almacenar datos. Los Objetos de Acceso a Datos (DAO) son el elemento principal de este patrn. Los DAO implementan los mecanismos de acceso requeridos para trabajar con el origen de los datos. Los orgenes de datos pueden ser un repositorio persistente tal como un Sistema Manejador de Bases de Datos Remoto, un servicio externo (por ejemplo una transaccin entre dos empresas), una base de datos LDAP o una funcin de negocio que puede ser accedida va CORBA IIOP. Los componentes de negocios que dependen de los DAO usan interfaces simples para la interaccin con los clientes. Debido a que la interfaz mostrada por los DAO a los clientes no cambia cuando la implementacin subyacente del origen de datos cambia, este patrn permite a los DAO adaptarse a diferentes esquemas de almacenamiento sin afectar a sus clientes o a los objetos de lgica de negocio. Los DAO actan como un adaptador entre los componentes y los data source. Estructura La figura 3.15 muestra el diagrama de clases y las relaciones usadas por el patrn Data Access Object.

Fig. 3.15 Diagrama de clases para el patrn Data Acess Object BusinessObject

La clase BusinessObject representa a los clientes y es un objeto que requiere acceso a los data source para obtener y almacenar datos. Un objeto de tipo Bussiness Object puede ser implementado como un bean de sesin, un entity bean, o algn otro objeto Java, incluyendo un servlet o un helper bean para acceder a los datos. DataAccessObject (DAO)

Los DAO son el objeto principal de este patrn, estos proveen las caractersticas de encapsulacin y delegacin al Business Object. Los DAO se abstraen de la implementacin subyacente para acceso a los datos permitiendo as que los objetos de negocio tengan un acceso transparente al origen de datos. Los objetos de Negocio delegan a los DAO las operaciones de almacenamiento y obtencin de los datos. DataSource

Este clase representa las implementacin usada por un data source. Un data source puede ser una base de datos relacional, una base de datos orientada a objetos, un repositorio XML o un sistema de archivos planos entre otros. Consecuencias Facilita la Transparencia

Los objetos de negocio pueden usar datos sin conocer los detalles especficos de la implementacin del origen de los datos. El acceso es transparente debido a

que los detalles de implementacin se encuentran encapsulados dentro del Objeto de Acceso a Datos (DAO) Facilita la migracin a diferentes implementaciones implementaciones de almacenes persistentes de

Una capa de Objetos de Acceso a Datos facilita a las aplicaciones el hecho de migrar a diferentes bases de datos. Los objetos de negocio no tienen conocimiento de la implementacin subyacente de los datos. As, al momento de realizar la migracin solo se consideran los cambios que deben realizarse a la capa de Acceso a Datos. Reduce la complejidad de cdigo de los Objetos de Negocio

Debido a que todas las complejidades relacionadas con el acceso a los datos es realizado por los Data Objects, todo el cdigo relacionado con la implementacin (por ejemplo sentencias SQL) es colocado fuera de los Objetos de negocio, mejorando con ello la legibilidad del cdigo e incrementando la productividad de desarrollo. Centraliza todos los accesos a datos en una capa independiente

Gracias a los Data Objects, la capa de acceso a datos puede ser vista como una capa que puede aislar el resto de la aplicacin de la implementacin de los datos, incrementando con ello la manejabilidad de la aplicacin. Poca utilidad con Entity Beans con Persistencia Manejada por el Contenedor (CMP)

Debido a que el contenedor de beans provee todos los servicios necesarios para el manejo de datos persistente. Las Aplicaciones que usen beans de tipo CMP no necesitan Objetos de Acceso a Datos, ya que el servidor de Aplicaciones donde se encuentre la aplicacin provee de forma transparente esta funcionalidad.

2. Service Activator
Contexto Los Enterprise Java Beans (EJB) y otros servicios de negocios necesitan una forma de ser activados de forma asncrona sin intervencin del usuario. Problema Los EJB implementados en especificaciones anteriores a la 2.0 no soportaban invocacin asncrona. La especificacin 2.0 introduce la integracin con el servicio de mensajera de Java (Java Message Service) por medio de los Message Driven Bean. Cuando un cliente necesita acceso a los servicios ofrecidos por un enterprise bean, se realiza una bsqueda de la interfaz home del bean, posteriormente se invoca a los mtodos create/find/remove de esa interfaz. Todas las interacciones entre el cliente y los componentes EJB se realizan de manera remota y sincrnica. La especificacin de los EJB le permite al contenedor remitir un enterprise bean a un repositorio secundario. Como resultado, el Contenedor EJB no posee mecanismos para proveer un servicio donde un bean se encuentre siempre en estado activo. Debido a que el cliente debe interactuar con el bean a travs de una

interfaz remota,(incluso si el bean se encuentra siempre en el contenedor), por lo cual siempre seguir interactuando con el bean de modo sincrnico. Si una aplicacin necesita procesamiento sincrnico para componentes de negocio del lado del servidor, entonces la eleccin apropiada es el uso de Enterprise Java Beans. Algunas aplicaciones cliente pueden requerir algo de procesamiento asincrnico para los objetos de negocio del lado del Servidor debido a que los clientes no necesitan esperar a que todo el procesamiento de datos se realice por completo. En tales casos, la funcionalidad de los beans provista en especificaciones anteriores a la 2.0 no cubre los requerimientos necesarios para brindar una solucin completa. En la especificacin 2.0 de los EJB, se introduce un Nuevo tipo de bean denominado Message-Driven Bean el cual es un tipo especial de bean sin estado. Sin embargo, esta nueva especificacin no ofrece invocacin asincrnica para otros tipos de Enterprise Java Beans. En general, cualquier servicio de negocio que provea nicamente procesamiento sincrnico puede tener limitaciones al trata de brindar facilidades de procesamiento asncrono. Fortalezas Los Enterprise Beans son mostrados a sus clientes por medio de sus interfaces remotas, las cuales solo permite acceso sincrnico. El contenedor controla a los enterprise beans, permitiendo interacciones solo por medio de referencias remotas. El contenedor EJB no permite acceso directo a la implementacin del bean o a sus mtodos. As, la implementacin de un componente escucha de mensajes en un Enterprise Bean no esta permitido ya que esto violaria las especificaciones de EJB anteriores a la 2.0, ya que se estaria permitiendo un acceso directo a la implementacin del bean. La especificacin de EJB 2.0 plantea un Nuevo tipo de bean denominado Message-Driven Bean que permite el desarrollo de un manejador de mensajes. Una aplicacin necesita proveer un framework de publicacin/suscripcin en el cual los clientes puedan publicar peticiones destinadas a los EJB, los cuales pueden procesar las peticiones de un modo asncrono. Los clientes necesitan capacidades de procesamiento asncrono de los EJB y otros componentes de negocio sncronos, con lo cual el cliente puede enviar una solicitud para su procesamiento sin necesidad de esperar los resultados. Los clientes pueden usar las interfaces middleware orientadas a mensajes ofrecidas por el Servicio de Mensajes de Java (JMS). Estas interfaces no estn integradas en los servidores EJB basados en especificaciones EJB anteriores a la 2.0. Proveer caractersticas similares a las de los procesos demonio permitiendo con esto que un bean pueda permanecer inactivo hasta la ocurrencia de un evento o la llegada de un Nuevo mensaje. Los Message Beans basados en la especificacin 2.0 son beans de sesin sin estado, por lo cual, no es posible realizar la invocacin asincrnica de cualquier otro tipo de beans.

Solucin Usar un Service Activator para recibir peticiones y mensajes asincrnicos del cliente. Al momento de la recepcin de un mensaje, el Service Activator localiza e invoca los mtodos de negocios necesarios para completar las solicitudes de manera asincrnica.

El ServiceActivator es un Manejador de Mensajes y delegador que requiere implementar la interfaz Message Listener para procesar todos los mensajes entrantes. Los Clientes actan como generadores de mensajes, generando eventos basados en su actividad. Cualquier cliente que necesite invocar asincrnicamente un servicio, como por ejemplo un enterprise bean, puede crear y enviar un mensaje al Service Activator. El Service Activator recibe los mensajes y los analiza para interpretar la solicitud del cliente. Una vez que se ha identificado la solicitud del cliente, se localizan componentes de negocio necesario para satisfacer los requerimientos del cliente. El Service Activator puede enviar un reconocimiento al cliente despus de completar exitosamente el procesamiento de una solicitud. El Service Activator puede utilizar los servicios de un Localizador de Servicios para localizar un componente de negocios. Estructura La figura 3.16 muestra el diagrama de clases del patrn Service Activator

Fig. 3.16 Diagrama de clases para el patrn Service Activator

Cliente (Client)

El cliente requiere facilidades de procesamiento asincrnico proveniente de los objetos de negocio provenientes de un flujo de trabajo. El cliente puede ser

cualquier tipo de aplicacin que tenga la capacidad de crear y enviar mensajes JMS. El cliente puede ser tambin un enterprise bean que necesite invocar los mtodos de otro bean enterprise de manera asncrona. Peticiones (Request)

Las peticiones son los mensajes creados por los clientes y enviados al Service Activator. De acuerdo con la especificacin de JMS, la peticin es un objeto que implementa la interfaz javax.jms.Message. El API de JMS muchos tipos de mensaje tales como: TextMessage,ObjectMessage,etc, que pueden ser usados para generar peticiones. ServiceActivator

La clase ServiceActivator es la clase principal de este patrn. Esta implementa la interfaz javax.jms.MessageListener, la cual es definida por la especificacin de JMS. La clase ServiceActivator posee un mtodo denominado onMessage() el cual es invocado cuando llega un Nuevo mensaje. Posteriormente la clase analiza el mensaje para determinar que debe hacerse para procesar la solicitud del usuario. BusinessObject

La clase BusinessObject es el objeto al cual el cliente necesita acceder de manera asincrona. El Objeto de Negocio es un rol que puede ser perfectamente desempeado por un Sesin Bean o un Entity Bean, aunque tambien puede ocurrir que el Objeto de Negocio sea representado por un servicio externo al cual el cliente desea acceder. Consecuencias Integracin del Servicio de Mensajes de Java en implementaciones anteriores a la especificacin EJB 2.0

Antes de la especificacin 2.0 de los EJB, no exista ningn tipo de integracin entre los EJB y los componentes JMS. Este patrn provee un medio para integrar JMS en una aplicacin que utilice EJBs, aadiendo adems capacidades de procesamiento asncrono. La especificacin 2.0 define un nuevo tipo de Bean de Sesin, denominado Message Bean, el cual permite realizar la implementacin de JMS con los EJB. Los Message Beans son capaces de implementar la interfaz Message Listener y recibir mensajes de forma asncrona. En este caso, el Servidor de Aplicaciones tomara el rol de Service Activator. Procesamiento Asincrono para cualquier Enterprise Bean

Usando el patrn Service Activator es possible proveer invocacin asincrona en todos los tipos de beans. Con ello, las aplicaciones no deben esperar por los resultados de todas sus peticiones para continuar con sus funciones habituales.

Estandarizacin de Procesos

El Activador de Servicios (service Activator) puede ser ejecutado como un proceso comn. Sin embargo, en una aplicacin critica, este debe ser monitoreado para asegurar disponibilidad. El manejo adicional de este proceso podra generar algo de sobrecarga al sistema.