Patrones de Diseño de Arquitecturas de Software …...Diseño de Patrones de Arquitecturas...

TESIS DE GRADO EN INGENIERÍA EN INFORMÁTICA

“Patrones de Diseño de Arquitecturas de Software

Enterprise”

TESISTA DIRECTOR Diego Fernando Montaldo Profesor Ing. Guillermo Pantaleo

[email protected] [email protected] http://www.fi.uba.ar/~dmontal/

Departamento de Computación Facultad de Ingeniería

Universidad de Buenos Aires

Noviembre 2005

Diseño de Patrones de Arquitecturas Enterprise FI UBA

Resumen

Se analizan los problemas surgidos de la implementación de un sistema con una arquitectura de software de tipo enterprise. Basándose en este análisis se derivan los criterios de diseño a utilizar en este tipo de desarrollo. Se presenta un sistema reusable (framework) como solución al problema de construcción de un sistema del tipo analizado, mostrando los distintos criterios de diseño elaborados. Se impuso como condición al problema del desarrollo del framework, que el modelo de negocio debe ser inmutable. Es decir no debe modificarse, sino que a partir del conocimiento del mismo se pueda generar el código de una aplicación completa sin su modificación. Se presenta la arquitectura original diseñada para que esta condición pueda ser cumplida.

Diego Montaldo Guillermo Pantaleo 2


Índice

Objetivo............................................................................................................6 Introducción .....................................................................................................7

Desarrollo de Software.................................................................................7 Características de Sistemas de Tipo Enterprise...........................................7 Arquitectura de Sistemas de Tipo Enterprise ...............................................7 Aspectos Relacionados al Desarrollo de Sistemas de Tipo Enterprise ........7 Problemas de Modelado del Dominio y del Negocio ....................................9

Estado del Arte ..............................................................................................10 Frameworks................................................................................................10 J2EE...........................................................................................................10 .NET ...........................................................................................................11 Frameworks de Persistencia ......................................................................11 Frameworks de Presentación.....................................................................13

Definiendo la Arquitectura..............................................................................14 Criterios de diseño .....................................................................................14 Tecnologías, Protocolos y Estándares a Utilizar ........................................18

Analizando cada Capa del Framework ..........................................................19 Capa de Servicio ........................................................................................19 Servicios Locales y/o Remotos ..................................................................21 Capa de Modelo del Dominio .....................................................................24 Capa de Presentación................................................................................30 Diagrama de paquetes del Framework ......................................................32 Cada uno tiene sus ventajas y desventajas, éstas son analizadas en la sección “Alternativa Reflection vs Generación de Código”.........................34

Aspectos relacionados a las capas del Framework .......................................35 Seguridad Autenticación y Autorización (Control de Acceso) ....................35

Autenticación ..........................................................................................35 Autorización ............................................................................................36

Concurrencia ..............................................................................................39 Auditoria .....................................................................................................40 Excepciones...............................................................................................41 Despliegue .................................................................................................43

Analizando los Patrones Utilizados................................................................47 Identificación ..............................................................................................47 Asociaciones ..............................................................................................51 Patrones relacionados a esta elección.......................................................52 Mapeos de objetos a tablas .......................................................................53 Patrones relacionados................................................................................53 Consistencia...............................................................................................55 Unidad de Trabajo......................................................................................58 Patrones relacionados................................................................................60 Acceso a Servicios Comunes.....................................................................61 Patrones relacionados................................................................................61 Acceso a los Datos Persistentes ................................................................62 Patrones relacionados................................................................................66 Carga Tardía de Objetos............................................................................67 Patrones relacionados................................................................................70



Patrones relacionados................................................................................74 Modelado del Dominio del Problema..........................................................75 Patrones relacionados................................................................................75 Acceso a la Capa de Negocio ....................................................................76 Presentación ..............................................................................................80 Relaciones Entre Todos los Patrones Analizados......................................82

Framework Desarrollado................................................................................84 Alternativa Reflection vs Generación de Código ........................................84 De la Arquitectura Propuesta al Framework..............................................84 Detalle de las API del framework ...............................................................86 Relaciones Entre Todos los Patrones Utilizados........................................93

Generador del Código para el Framework.....................................................95 Arquitectura ............................................................................................95 Tipos de Generadores Provistos ............................................................99

Caso de Estudio...........................................................................................101 Descripción del dominio ...........................................................................101 Modelo del Dominio..................................................................................101 Transición del análisis al diseño...............................................................102

Diagrama de Casos de Uso de sistema ...............................................102 Análisis de los Casos de Uso, Diagramas de Robustez .......................103 Paquetes Lógicos del Diseño Conceptual ............................................104 Diagrama de una arquitectura de tipo Enterprise .................................104

Uso del Framework ..................................................................................106 Resultados obtenidos al aplicar el framework ..........................................108

Trabajo Futuro .............................................................................................110 Conclusiones ...............................................................................................112 Apéndice Patrones.......................................................................................113

Patrones de Arquitectura de Aplicaciones de tipo Enterprise...................113 Identity Field .........................................................................................113 Foreign Key Mapping............................................................................113 Association Table Mapping...................................................................114 Domain Model.......................................................................................114 Transaction Script.................................................................................115 Table Module ........................................................................................115 Service Layer........................................................................................116 Table Data Gateway .............................................................................116 Row Data Gateway...............................................................................117 Active Record .......................................................................................117 Data Mapper .........................................................................................118 Single Table Inheritance .......................................................................118 Class Table Inheritance ........................................................................118 Concrete Table Inheritance ..................................................................119 Inheritance Mappers .............................................................................120 Identity Map ..........................................................................................120 Unit of Work ..........................................................................................121 Lazy Load .............................................................................................121 Layer Supertype ...................................................................................122 Separated Interface ..............................................................................122 Registry ................................................................................................123 Optimistic Offline Lock ..........................................................................124



Pessimistic Offline Lock........................................................................124 Active Front o Ajax................................................................................124

Referencias - Bibliografía.............................................................................128



Objetivo El objetivo de este trabajo es analizar los problemas que se plantean en el desarrollo de sistemas con arquitecturas de software de tipo Enterprise. Entendemos por Enterprise, sistemas cliente /servidor de tres o más capas. Basándose en este análisis establecer criterios de diseño de estos sistemas y qué tecnologías utilizar. Se examinan los distintos Patrones de Diseño conocidos como solución a los distintos problemas que se plantean en el desarrollo de este tipo de sistemas; también las distintas implementaciones tecnológicas construidas en base a estos patrones (Sun J2EE, Microsoft .Net). A partir de este análisis se fijan criterios de diseño que permiten seleccionar la tecnología a utilizar en cada caso, según el tamaño del sistema a desarrollar, el tipo de plataforma sobre el cual debe funcionar, la complejidad del negocio que el sistema resuelve, etc. Estos criterios contemplan también la funcionalidad capturada en el análisis del problema que el sistema en desarrollo busca resolver. Básicamente se trata de que estos criterios de diseño conduzcan el vuelco del producto del análisis en una arquitectura que si bien está dada (tres o más capas), mantenga la separación de la lógica del negocio, la presentación y los datos; y además, conserve el empaquetamiento logrado en el análisis usando criterios de cohesión del negocio. Se desarrolla un sistema reusable (framework) como solución al problema planteado mostrando los distintos criterios de diseño elaborados. Se impuso como condición al problema planteado del desarrollo del framework, que el modelo de negocio sea inmutable. Es decir no debe modificarse, sino que a partir del conocimiento del mismo se pueda generar el código de una aplicación completa sin su modificación. Se presenta la arquitectura original diseñada para que esta condición pueda ser cumplida.



Introducción Desarrollo de Software Dentro de lo que se denomina “Desarrollo de Software” se abarca el desarrollo de muchísimos sistemas, con características totalmente diferentes. Cada uno con distintas complejidades y distintos objetivos, y para cada tipo de sistema se utiliza una estrategia diferente para su resolución. Se distinguen entre todos los sistemas, a los sistemas de tipo enterprise. Los sistemas de tipo enterprise son los analizados en este trabajo. Características de Sistemas de Tipo Enterprise Entre las características salientes de un sistema de tipo enterprise, según [Rod Johnson, 2003], [Martin Fowler, 2003], [Marinescu 2002] se pueden mencionar las siguientes: Datos masivos (gran volumen) y persistentes. Acceso concurrente, lo que implica gran cantidad de usuarios. Variedad de interfaces de usuario, lo que implica diversidad en la

funcionalidad brindada. Integración con otros sistemas, lo que implica que comparten

funcionalidad y / o datos. Disonancia conceptual (modelo de datos con distintas visiones),

debido a que poseen un modelo de negocio subyacente que abarca distintos aspectos de un área de negocio. Por lo tanto prestan distintas funcionalidades a distintos tipos de usuarios.

Lógica de negocio, lo que implica procesamiento de datos. Ejemplos típicos de estos sistemas son B2C ( comercio electrónico), sistemas financieros en línea, sistemas ERP ( Enterprise Resource Planning). Estos sistemas por su volumen están generalmente instalados físicamente en varios nodos (servidores). Por sus características de crecimiento es importante en su diseño el concepto de escalabilidad y por la necesidad de prestar servicios en forma continua es importante el concepto de robustez. Ambos conceptos condicionan el diseño de la arquitectura de este tipo de sistemas. Arquitectura de Sistemas de Tipo Enterprise Ha habido muchas formas de plantear una solución para este tipo de sistemas, y básicamente todo sistema enterprise tiene una estructura cliente / servidor, distribuido en capas verticales. Estas capas consisten generalmente en algunas de las siguientes, una capa cliente, una capa de aplicación o web server, una capa de acceso a la capa de negocio, una capa de modelo de negocio, una capa de persistencia y una base de datos. Aspectos Relacionados al Desarrollo de Sistemas de Tipo Enterprise En la tabla número 1 se muestran los aspectos de las arquitecturas de tipo Enterprise que son de nuestro interés y hacia los cuales se orienta este



trabajo. Este trabajo plantea el análisis de los ítem mostrados en las celdas de la tabla que sigue. Como conclusión al trabajo se desarrollará un generador de código para el framework desarrollado, donde se mostrarán los criterios elaborados sobre la base del trabajo anterior.

Capas de una aplicación Enterprise Aspectos de interés Capa

Presentación Capa Servicios

Capa Dominio del Problema

Capa Persistencia

Contexto y Problema

Problemas derivados de la capa receptora de requerimientos.

Problemas derivados del acceso al modelo de objetos a través de la lógica de la aplicación.

Problemas de modelado del dominio y del negocio.

Problemas derivados de la persistencia de objetos en bases relacionales y acceso multiusuario.

Patrones de Diseño utilizados en la resolución

Web Presentation Patterns [Martin Fowler, 2003]

Distribution Patterns [Martin Fowler, 2003]

Todos los patrones básicos de Categoría Diseño. [Gamma et al, 1995]

Data Source Architectural Patterns [Martin Fowler, 2003] Object Relational Behavioral Patterns [Martin Fowler, 2003] Object Relational Structural Patterns [Martin Fowler, 2003] Offline Concurrency Patterns [Martin Fowler, 2003]

Transición Análisis /Diseño

Lógica de Aplicación

Lógica de Aplicación / Lógica de Negocio

Modelo del Problema / Lógica de Negocio

Modelo del Problema Persistente

Tecnología utilizada

Servlet /JSP POJO EJBSession

POJO EJBSession /EJBEntity POJO /EJBEntity

EJBEntity / DataMappers /

Framework básico de soporte Servicios de logeo, configuración y seguridad.

Generador de la capa de persistencia utilizando reflection.

Tabla 1 Referencias para la tabla: POJO, del inglés “plain old java object”. [Marinescu 2002]



Problemas de Modelado del Dominio y del Negocio Debido a que la mayoría de las aplicaciones de tipo enterprise son implementadas a partir de un modelo de objetos del dominio y la base de datos que persiste los datos es relacional, se produce un choque de impedancias entre ambos modelos. Algunas de los problemas derivados de este choque son:

¿Cómo se convierten las columnas del resultado de un query SQL en objetos?

¿Cómo se refleja en forma eficiente en un query SQL el cambio de estado de un objeto en memoria?

¿Cómo se modelan las relaciones? ¿Cómo se mapean las relaciones de herencia de un modelo de

objetos en un modelo relacional de una base de datos? ¿Cómo se mapean los objetos cuyos atributos se persisten en varias

tablas de la base de datos?

Los modelos relacionales y su implementación en bases de datos han sido muy usados y probados por lo cual son muy robustos. Por otro lado los modelos de objetos son mucho mas ricos en su expresión, y los lenguajes de alto nivel son implementaciones de este paradigma. Debido a que ambos modelos deben convivir y que ambos poseen ventajas frente al otro, se plantea la pregunta ¿cuál de ellos debe conducir el diseño? Este es un tema de discusión y que tiene adeptos en ambos bandos. Existen herramientas que generan código para la capa de persistencia a partir del modelo de objetos. Este criterio es el adoptado por el generador que se presenta en este trabajo. Este camino deja de lado la optimización del modelo relacional resultante. Por otro lado existe el criterio del camino opuesto, generar un modelo relacional y a partir de éste generar automáticamente el modelo de objetos. Este tiene la limitación de que el modelo relacional es mucho menos expresivo y limita él mismo el modelo de objetos resultante. El mejor método de trabajo parece ser aquel que partiendo de un modelo de objetos parcial, permite la construcción de un modelo relacional parcial, analizar este modelo relacional y ver que mejoras se requieren principalmente por performance e ir refinando los modelos, para lograr estas mejoras, y continuar iterando de esta forma hasta encontrar el modelo completo en ambos mundos. De esta forma tendremos la riqueza del modelo de objetos y también se podrán obtener modelos relacionales sin pérdida de performance y explotar mecanismo propios de un modelo relacional.



Estado del Arte Frameworks Existen en el mercado distintos servidores de aplicaciones propietarios y de código abierto y libre que resuelven el problema de una arquitectura de tipo enterprise. Por ejemplo hay varias marcas que implementan la especificación J2EE basadas en lenguaje Java. Las mismas presentan la posibilidad de ser utilizadas de distinta forma, por ejemplo EJB en la modalidad BMP (bean managed persistence) o CMP(component managed persistence), Session Bean stateless o statefull, etc. Estas plataformas permiten además la integración con sistemas de terceros para alguna de sus capas, por ejemplo la de persistencia. Entre ellas podemos mencionar Bea WebLogic, IBM Websphere, Oracle 9i AS, JBoss, etc. También Microsoft ha desarrollado una plataforma basada en el lenguaje c#, esta plataforma es .Net que también resuelve estos tipos de problemas. J2EE La plataforma J2EE [WEB-1] utiliza un modelo de aplicación disitribuida multicapa. Las partes de una aplicación J2EE mostradas en la Figura 1 son presentados en los siguientes componentes que brinda J2EE. • Componentes de la Capa Cliente (Client-Tier) que corren en la máquina cliente. • Componentes de la Capa Web (Web-Tier) que corren en el servidor J2EE. • Componentes de la Capa de Negocio (Business-tier) que corren en el servidor J2EE. • Software de la Capa de Enterprise information system (EIS-tier) que corren en el servidor EIS.

Figura 1

Aunque pueda contar de 3 o 4 capas lógicas, las aplicaciones J2EE en capas son denominadas aplicaciones de 3 capas, ya que hace referencia a capas



físicas, puesto que son distribuídas en 3 lugares físicos diferentes, máquina Cliente, máquina Servidor J2EE y la máquina Servidor Base de Datos. Las aplicaciones J2EE estan basadas en componentes, cada componente tiene su propia funcionalidad y permite ser ensamblado en una aplicación J2EE, Estos componentes corren y son manejados por un servidor J2EE

La especificación J2EE define los siguientes componentes:

• Application Clients y applets son componentes que corren en el cliente.

• Java Servlet y JavaServer Pages (JSP) con componentes web que corren en el servidor.

• Enterprise Beans (EJB) son componentes de negocio que corren en el servidor.

Existen 3 tipos de Enterprise Beans: session beans, entity beans, y message-driven beans. Un session bean reprepresenta un objeto no persistente que vive mientras viva las sesión. Un entity bean representa datos persistentes en una base de datos. Es decir se encarga de persistir sus datos aunque la sesión del cliente termine o el servidor se apague. Un message-driven bean combina características de un session bean y un Java Message Service (JMS), permitiendo a un componente de negocio, recibir mensajes JMS asincronicos. .NET La plataforma .NET [WEB-2] nos brinda las siguientes componentes.

• Formularios de Windows Forms, para diseñar las interfaces winform. • Páginas Microsoft ASP.NET, para diseñar las interfaces web • BizTalk Server Orchestration, para la coordinación de procesos • Object Spaces, para el manejo de persistencia, que vendrá en la

próxima versión • Enterprise Library, [WEB-3] es una librería de Application Blocks, que

son componentes diseñados para asistir al desarrollador. Hay por ejemplo para manejo de cache, de acceso a datos, de log, de seguridad, de excepciones, etc

Frameworks de Persistencia La capa de mayor criticidad y por consiguiente en la cual más trabajo se ha desarrollado en los últimos años es la de persistencia. Debido al choque de impedancia que se produce entre los objetos del modelo de negocio y los datos persistidos en una base de datos relacional, es que esta capa requiere un tratamiento particular.



Gran parte de los productos que se han generado atacan el problema del mapeo y acceso a los datos persistentes. Algunos de los más conocidos son: EJB Entity beans JDBC SQLJ TopLink CocoBase Hibernate / nHibernate JPOX (JDO) Versant (JDO) OBJ Object Spaces

Debido a algunas limitaciones de EJB Entity Beans han surgido las otras alternativas. Básicamente los Entity Beans presentan la característica de ser usables cuando los modelos de dominio son simples, deben ser distribuidos y conectarse a otros sistemas. Su utilización es buena cuando existe un mapeo uno a uno con las tablas de la base de datos. Es decir cuando la granularidad es baja. No admiten herencia entre clases componentes. Por esta razón y debido a esta limitación han surgido otros productos. Debido a esto también es que se desaconseja su utilización. Toplink es un producto muy utilizado en el mercado, ahora integrado al servidor de aplicaciones Oracle 9i AS. Permite entre otras cosas: Integración de EJB CMP Mapeo de objetos a múltiples tablas Uso de herencia Soporta bloqueo optimista de tablas Transacciones anidadas Permite adaptar el mapeo de datos entre objetos y tablas Permite realizar el diseño en ambas direcciones, objetos / tablas y

tablas / objetos. Permite adaptar código SQL generado Permite el uso de Store Procedures Administra pool de objetos

Tiene una desventaja, es dependiente de APIs propietarias. Hibernate también es muy utilizado tanto en el ambiente java como .net. JDO es una especificación java que se espera se convierta en el estándar de administración de bases de datos orientadas a objetos. No exige la implementación de interfaces. Presenta menor sobrecaga en la creación de objetos y su configuración se realiza en un archivo XML, siendo más simple que la de los EJB CMP. Presenta ventajas que heredó de EJB tales como el encapsulamiento de datos de la aplicación, el mapeo a tablas, trabaja en transacciones delimitadas por los Session Beans, administra pool de objetos. También posee ventajas propias como trabajar con clases java genéricas y las hace persistentes, requiere menor infraestructura.



Frameworks de Presentación Tambien hay varios frameworks de presentación, que permiten implementar el patrón MVC. Entre ellos encontramos

Struts WebWork Tapestry

Estos permiten separar la lógica de presentación facilitando el diseño y reuso.



Definiendo la Arquitectura Criterios de diseño Dado el tipo de aplicaciones seleccionado, es decir del tipo Enterprise, donde las aplicaciones poseen un dominio complejo, con lógica de negocio compleja y muchas reglas de negocio, las cuales varían con el tiempo, y van modificando a las actuales, y nutriéndose con otras nuevas, la idea central es modelar el dominio utilizando programación orientada a objetos, obteniendo así, un modelo del dominio, formado por objetos muy similares a la realidad, que se rigen según las reglas de negocio. Para poder acompañar los cambios del negocio, actualizando así el modelo del dominio, se buscó la manera de mantener este dominio lo mas aislado posible del resto de la aplicación, éste es el objetivo principal en este trabajo, es decir se buscó desacoplar lo más posible al modelo de dominio del resto de la aplicación. Para ello la arquitectura elegida es una arquitectura basada en capas lógicas (Layer Pattern), donde una de estas capas es la capa de modelo del dominio (Domain Model Layer), y ésta es la capa que buscamos que tenga el menor acoplamiento posible. Entonces partiendo de una arquitectura cliente servidor, el primer paso es quitar toda la lógica de negocio de la capa de presentación, y volcarla en la capa de modelo del dominio, como se muestra en la Figura 2. Separando así muy bien todo lo que tiene que ver con obtención de información y presentación al usuario, de la lógica del dominio modelado.

cd Evolución de Capas 1

DataSource Layer

Presentation Layer

Domain Model Layer

Figura 2

En una aplicación, vamos a encontrar lógica y reglas de negocio del dominio modelado, y lógica y reglas de negocio de la aplicación particular en sí, de acuerdo a como ésta hace uso del dominio.



Se busca que la lógica del dominio quede en la capa de dominio, pero no la lógica de aplicación, ya que ésta no es parte del dominio sino de la aplicación que hace uso de él. En este esquema de tres capas, la lógica de la aplicación o bien queda en la capa de presentación o queda en la capa de dominio. Sin embargo, no es parte de ninguna de las dos realmente. La idea es que el modelo de dominio, modele el dominio en general, posea las reglas inherentes a este dominio y pueda ser reutilizado en distintas aplicaciones. Cada aplicación puede tener sus propias transacciones de negocio que hacen uso del dominio de una manera particular. Si la aplicación tuviera diferentes tipos de clientes de presentación y si ellos albergaran la lógica de aplicación, ésta estaría distribuída en cada capa cliente, dificultando bastante su mantención. Por todo esto se justifica el uso una capa de servicio sobre el modelo de negocio, que juega el papel de fachada (Facade Pattern). La misma puede verse en la Figura 3. Es decir la capa de servicio se encarga de exponer los servicios necesarios en la aplicación hacia la capa de presentación. La capa de presentación solo busca obtener las funcionalidades o servicios que le permitan resolver la problemática de la aplicación y exponer de forma amigable y eficiente interfaces al usuario para la recolección y visualización de la información vinculada a dichos servicios. Por lo que esta capa obliga a definir una interfaz con la funcionalidad o servicios que la capa de presentación necesita para cumplir con su objetivo. Esta fachada conoce al modelo y en cada servicio expuesto, hará uso de los objetos del dominio para la resolución del mismo. Si la capa de presentación corre en otro espacio físico que la capa de negocio, esta también juega el papel de interfaz remota, minimizando el tráfico entre ambas capas ya que la lógica de la aplicación se resuelve completamente en la capa de servicio.



cd Ev olución de Capas 2

DataSource Layer

Domain Model Layer

Serv ice Layer

Presentation Layer

Figura 3

Aun vemos que la capa del modelo del dominio sigue teniendo cierto acople con la capa de datos. Queremos evitar este conocimiento desde el modelo a la capa de datos, es decir lo que ahora buscamos es que el modelo, no conozca la manera en que sus datos son persistidos o almacenados, en la capa de datos, ya que éste es un problema tecnológico que no tiene nada que ver con los problemas del dominio a resolver, lo que nos lleva a introducir una nueva capa entre ambas, ésta capa es la capa de persistencia. Entonces el objetivo de la capa de persistencia es quitar del dominio la problemática asociada a este problema tecnológico que no tiene nada que ver con nuestro dominio y agruparlo en esta nueva capa. De esta manera vamos llegando a la arquitectura propuesta para el framework desarrollado en esta tesis. La misma puede verse en la Figura 4a y 4b.



cd Ev olución de Capas 3

Presentation Layer

Domain Model Layer

DataSource Layer

Serv ice Layer

Persistence Layer

cd Distribución de lógica sobre las Capas

DataSource Layer

Domain Model Layer

Persistence Layer

Presentation Layer

Serv ice Layer

Componentes de PresentaciónLógica de Presentación

Lógica de la AplicaciónReglas de negocio de la AplicaciónTransacciones de Negocio (Casos de Uso)

Modelo del DominioReglas de Negocio del Dominio

Logica de PersistenciaTransacciones del DBMS

Figura 4a Figura 4b

En la Figura 4b podemos ver como se distribuyen las diferentes partes de la aplicación sobre esta arquitectura en capas. Buscando que esta arquitectura sea escalable y más segura ante ataques, es deseable poder distribuir estas capas lógicas (layers) en distintas capas físicas (tiers). Este tema es analizado en la sección de Despliegue.



Tecnologías, Protocolos y Estándares a Utilizar Se utilizaron para el presente trabajo:

• JDK 1.4 [WEB-5] • Tomcat 5.0 [WEB-6] • Servlets • Ant.jar (compilación, deploy) [WEB-7] • Xerces.jar (manejo de xml) • Drivers de SQL • Reflection • Generación de código • HTML • XML • XML-HTTP Object • JavaScript



Analizando cada Capa del Framework Definida la arquitectura a utilizar, se analiza la implementación de cada capa. Capa de Servicio También denominada Fachada de Servicio (Facade) [Martin Fowler, 2003] [Marinescu 2002], es la encargada de brindar los servicios necesarios a la capa de presentación. Contiene la lógica de la aplicación, en forma de transacciones de negocio. Todos los servicios necesarios para la capa de presentación referidos al dominio estan expuestos en la interfaz de servicio, lo que permite separar fisicamente ambas capas y jugar el papel de interfaz remota en dichos casos. La capa de presentación conoce las interfaces de servicio y cuenta con una Factory de servicios (ServiceFactory), para obtener una implementación de dicha interfaces. Los parámetros intercambiados entre ambas capas son objetos DTO (Data Transfer Object) [Martin Fowler, 2003] que son objetos simples (POJOs) utilizados para el intercambio de información. Estos objetos DTO cumplen el papel de contenedores de datos para el transporte entre las capas de presentación/servicio. Están orientados a cada caso de uso y su vista asociada en la capa presentación. Contienen los datos vinculados al resultado de una transacción en la capa de servicio, que pueden ser datos resultantes de distintos objetos de negocio de la capa de modelo de negocio. La definición de estos aspectos de la arquitectura se muestran en la Figura 5, dónde la capa de Presentación sólo conoce a la ServiceFactory, y a las interfaces que expone la capa de servicio junto a los objetos DTO de sus parámetros. Con la ServiceFactory obtiene una implementación para las interfaces de servicio que conoce a partir de su nombre y ya puede consumir los servicios que ésta le brinda.



cd Figura 5

presentation

+ fwk

(from framework)

fwk

+ ActionServlet+ EntityController+ Invoker+ PageController

(from presentation)

Servidor de Presentación (Web) Servidor de Aplicaciones

iserv ice

+ IBaseService+ dtoEntities+ pequi

(from framework)

serv ice

+ BaseService+ pequi

(from framework)

pequi

+ clientes+ ot+ personas

(from service)

ot

+ ComponenteService+ EstadoDeOrdenService+ EstadoDeProcesoService+ MaterialService+ NotaService+ ObservacionService+ OrdenDeTrabajoService+ ProcesoService+ SolicitanteService+ TipoDeProcesoService+ TipoMaterialService+ TurnoService

(from pequi)

pequi


(from iservice)

ot

+ IComponenteService+ IEstadoDeOrdenService+ IEstadoDeProcesoService+ IMaterialService+ INotaService+ IObservacionService+ IOrdenDeTrabajoService+ IProcesoService+ ISolicitanteService+ ITipoDeProcesoService+ ITipoMaterialService+ ITurnoService

(from pequi)

dtoEntities

+ CustomData+ pequi

(from iservice)

ot

+ ComponenteDTO+ EstadoDeOrdenDTO+ EstadoDeProcesoDTO+ MaterialDTO+ NotaDTO+ ObservacionDTO+ OrdenDeTrabajoDTO+ ProcesoDTO+ SolicitanteDTO+ TipoDeProcesoDTO+ TipoMaterialDTO+ TurnoDTO

(from pequi)

remoting

+ client+ server

(from framework)

client

Service+ ServiceFactory

(from remoting)

serv er

+ ServicePublisher

(from remoting)

Servidor de Remoting (RMI)

Figura 5



Servicios Locales y/o Remotos La capa de servicio puede ser desarrollada para una arquitectura local y/o remota. Se quiere que ésto sea transparente a la capa de presentación. Para ello el ServiceFactory se encarga de abstraer la localización del servicio, pudiendo ser este local o remoto. Por lo que de manera configurable (por código xml) se permite que el ServiceFactory instancie una implementación local para la interfaz o utilice un proxy a una implementación remota. (Como ser un objeto de servicio publicado por RMI en un servidor). Todo esto es transaparente a la capa de presentación ya que ella espera una implementación cualquiera para la interfaz de servicio que utiliza. De esta manera de acuerdo a como este desplegada la aplicación se puede definir mediante configuración, de acuerdo a los beneficios buscados, como utilizar dicho servicio (local o remoto). Para desacoplar el mecanismo de remoting utilizado por el framework, se estructuraron las clases que lo implementan como se muestra en la figura 6.

Clases de servicios del dominio

Clases genéricas del Framework

RMI - jdk

UnicastRemoteObject

BaseService

ConcreteService

«interface» Remote

«interface» IBaseService

«interface» IConcreteService

«realize»

«realize»

Figura 6

Cada clase de servicio extiende a BaseService e implementa una interfaz para sus servicios que a su vez extiende a IBaseService. Las clases bases, le agregan el comportamiento necesario para poder ser invocadas remotamente.



Se puede ver su implementación en el file BaseService.java del paquete framework\service y IBaseService.java del paquete framework\iservice.

De utilizarse servicios remotos es necesario, instanciar y publicar los servicios en la rmiRegistry, para lo cuál se cuenta con un script que lo hace. Este script configurado por un archivo xml, instancia y publica en la registry de RMI las clases de servicio, para que queden disponibles para el ServiceFactory.

Se puede encontrar dicho script en el file servicePublisher.bat. La dinámica de creación, registración y obtención de servicios para ambos escenarios se muestra en la Figura 7.

cd Figura 7

Presentation Serv iceFactory RMI Registry Serv icePublisher

System Administrator

Serv ice Serv ice2

Escenario de creación y registración de servicios.

Escenario de obtención de servicios. Caso Servicio LocalServidor de Presentación es el mismo que servidor de Aplicaciones y no es necesario un servidor RMI

Escenario de obtención de servicios. Caso Servicio Remoto

SERVIDOR DE PRESENTACIÓN SERVIDOR RMI SERVIDOR DE APLICACIONES

runServices

getServicesInfo()

new

servicerebind(service)

newservice2

rebind(service2)

getService(serviceName)

getServiceInfo(serviceName)

new

service2service2

getService(serviceName)

getServiceInfo(serviceName)

lookUp(serviceName)

serviceservice

Figura 7

La capa de servicio, es el único acceso al modelo desde la capa de presentación, por lo que es un buen lugar para agregar la seguridad a los mismos. Por lo que cada clase de servicio dentro de cada método, deberá antes que nada verificar los permisos para el usuario actual.



Una vez autenticado un usuario, el mismo posee un token de identificación, (Ver seción de “Autorización / Autenticación”), el mismo es su identificador, y es pasado como contexto desde la capa de presentación, por lo que la capa de servicio debe verificar que el token sea de un usuario ya autenticado, que no esté vencido y verificar la autorización para dicho servicio. Asi mismo es un buen lugar para colocar la auditoria del sistema, indicando que usuario intento ejecutar que servicio a que hora y con que parámetros. Con esto puede desarrollarse luego una interfaz para que un administrador monitoree que esta haciendo un usuario dado.



Capa de Modelo del Dominio Las Aplicaciones de Tipo Enterprise poseen un dominio de negocio complejo. Esta capa contiene todas las clases que modelan dicho dominio, sus entidades, sus relaciones y las reglas de negocios que cumplen. Debemos recordar que una condición que impusimos al framework de persistencia es el requerimiento de instanciar sobre él un modelo de un dominio cualquiera sin tener que modificarlo. Esta restricción es para que la Capa del Dominio este desacoplada del resto de las capas. Esto ayuda a que el modelo del dominio y sus reglas de negocio sean reusables, y puedan modelarse sin tener en cuenta otros problemas mas allá del dominio analizado. Lo ideal es que a partir de un modelo de dominio, el mismo pueda integrarse a una arquitectura como la propuesta sin que el framework y su arquitectura sean intrusivos sobre el modelo de dominio dado. Para esto, la capa de dominio no debe conocer a la capa de persistencia. La capa de persistencia es la que conoce al dominio y sabe como recuperar y alamacenar objetos de dominio. Sin embargo es necesario contar con cierta lógica relacionada a la persistencia (registrar cuando hay un objeto de dominio nuevo, cuando se modifica, cuando debe ser eliminado del medio persistente). Esta lógica puede estar ubicada en una clase base denominada DomainObject [Martin Fowler, 2003] como lo propone el patrón Domain SuperType, [Martin Fowler, 2003] donde cada objeto de dominio la extiende. Pero este esquema es intrusivo ya que la clase de dominio debe sobrecargar ciertos métodos de DomainObject (en los setters debe informar que ha sido modificada). Todo esto genera una fuerte dependencia de la capa de dominio a la capa de persistencia ya que DomainObject es una clase que forma parte de la capa de persistencia. Para romper con esta dependencia recurrimos al uso del patrón de diseño Adapter. El diagrama de clases se muestra en la Figura 8.



cd Data Model

Serv ice Layer ClaseDominio

ClaseDominioAdaptada DomainObject

Figura 8 En este esquema aparece una nueva clase, ClaseDominioAdaptada o ClaseDominioFwk ( como se la nombra en la implementación del framework ) Esta clase ClaseDominioAdaptada especializa a cada clase de dominio particular (invirtiendo la dependencia entre capas) y le agrega el comportamiento mencionado (en los setters se marca como modificada y llama al método base). Esta clase y la clase DomainObject pasan a formar parte del paquete de persistencia del framework, logrando que el paquete del dominio ya no dependa del de persistencia. Sin embargo este patrón no alcanza a resolver completamente el problema ya que los objetos del dominio necesitan ser manipulados en la capa de Persistencia de una manera genérica, es decir la capa de persistencia espera una interfaz común a todos los objetos de dominio para poder manejarlos abstractamente sin saber que clase de dominio concreta es. Por esta razón fue introducida la interfaz IDomainObject. El patrón finalmente fue implementado como muestra la Figura 9.

Service Layer ClaseDominio


«interface»IDomainObject

«realize»«realize»

Figura 9



Por ejemplo en la clase AbstractMapper de la capa de persistencia, en el método Load( DomainObject do) recibe un objeto y lo carga con datos persistidos en la base de datos. En éste caso, éste método cambió a Load( IDomainObject do ). Si los objetos del dominio heredan todos de DomainObject (como en el caso de utilizar el patrón Layer SuperType), no se presenta este problema, sin embargo se mostró que eso representa una dependencia muy fuerte entre la capa de dominio y la de persistencia. Esta es la razón por la cual nuestra solución terminó siendo la mostrada en la Figura 9. Al interactuar desde la capa de servicio con objetos del dominio, lo haremos mediante la interfaz IPersistenceBroker, la misma expone métodos para obtener un objeto persistido, buscarlos, borrarlos, y crearlos. (Ver detalle de la API en la sección de “Detalle de las API del framework”) Esto es debido a que el framework para contar con la lógica descripta debe operar con clases del tipo DomainObjectAdaptadas, aunque las mismas sean vistas como ClaseDominio ya que son ClaseDominio al heredar de ellas. Si desde la capa de dominio fuera necesario instanciar otras entidades de dominio que terminarán siendo persistentes, ésto debe hacerse mediante el uso de una Factory que presenta el framework para instanciarlos, es decir a través del método createDomainObject(Class domainObjectClass) de la interfaz IPersistenceBroker. En este caso, esto implica que el desarrollo del modelo de dominio, debe hacerse en el contexto de una previa definición de la arquitectura que incluye el mecanismo de persistencia. Sólo de esta forma se garantiza no modificar dicho dominio al instanciarlo en este framework. (Ver sección de “A Futuro”)



Capa de Persistencia La capa de persistencia es la encargada de abstraer y resolver el acceso a datos a un motor de base de datos relacional. Su objetivo es ser la única que conoce como son persistidos los objetos de dominio de la aplicación y como recuperarlos abstrayendo el choque de impedancias entre objetos y tablas relacionales. La capa superior no interactúa directamente con la base de datos, sino que lo hace mediante la interfaz expuesta por la capa de persistencia, logrando así la independencia buscada. Esto permite cambiar la estrategia con que se persisten los objetos, incluso cambiar la tecnología o el motor utilizado sin impactar mas allá de ésta capa. La capa de persistencia, se expone a través de la interfaz IPersistenceBroker. La existencia de ésta interfaz es desacoplar como trabaja la capa de persistencia. Esta interfaz expone métodos como por ejemplo: crear un objecto de dominio, borrarlo, realizar búsquedas por clave y por distintos criterios. Para obtener una implementación de este broker de persistencia, se utiliza la factory PersistenceBrokerFactory. Con ella se obtiene a una instancia concreta del broker de persistencia. Este broker puede ser visto como un ORM, que se obtiene a través de una Factory de ORMs que cumplen con dicha interfaz. En la Figura 10 puede observarse el mecanismo, donde una clase de la capa de presentación solicita una búsqueda con ciertos parámetros a partir de un criterio dado. Desde la capa de presentación llega un pedido a la capa de servicio, ésta obtiene una implementación del IPersistenceBroker a través de la Factory, comienza una nueva unidad de trabajo (patrón UnitOfWork) realiza la búsqueda, opera con los objetos de dominio resultantes, carga objetos DTO para retornar a la capa de presentación y los retorna.



cd Figura 10

Clase dePresentación

Clase deServ icio

PersistenceBrokerFactory PersistenceBroker

find(parámetros de búsqueda )

getInstance(PersistenceBrokerName)new

aPersistenceBrokeraPersistenceBroker

newUnitOfWork

findAll(Criterio, Parámetros)aCollection

toDTO(aCollection)

commitUnitOfWorkDTOCollection

Figura 10

Se puede ver su implementación en el file PersistenceBrokerFactory.java del paquete framework\utils\casestudy y IPersistenceBroker.java del mismo paquete. Se implementa el broker en la clase PersistenceBroker (utilizando patrones como UnitOfWork, Mappers, IdentityMap, DomainObject, que fueron adaptados para las necesitades puntuales del framework). El uso de los mismos es explicado y detallado en el capítulo de “Analizando los patrones utilizados”. Este PersistenceBroker es el único acceso a la capa de persistencia. Como dijimos anteriormente para obtener una instancia concreta de IPersistenceBroker, se utiliza al PersistenceBrokerFactory que mediante reflection instancia al broker indicado en los archivos de configuración, permitiendo cambiar la implementación del mismo por otra mas adecuada. Para evitar el uso de código SQL que puede necesitarse para las búsquedas por criterio predefinidas, se utilizó un esquema de Finders. Un Finder recibe un nombre y define una sentencia SQL en un archivo xml. Luego un método de servicio puede solicitar los objetos resultantes de un Finder y el DataMapper puede obtener la sentencia SQL asociada al mismo. Esto permite que el código SQL este agrupado en estos files xml, permitiendo que sean facilmente modificables y actualizables.



Algunos de los requerimientos buscados para la capa de persistencia son los siguientes [Scott Ambler 1]

• Manejar distintos tipos de mecanismos de persistencia (Single, Concrect, y Table Inheritance)

• Encapsular los mecanismos de persistencia (utilizando métodos al estilo: save(obj), delete(obj), create(obj), retrieve(obj))

• Manejo de transacciones • Identificación de objetos • Utilización de Proxies • Posibilidad de realizar consultas

Se puede ver la implementación de la capa de persistencia en las clases Mapper, IdentiyMap, UnitOfWork, DomainObject, del package framework\fwk\persistence.



Capa de Presentación Esta es la capa que interactua con el usuario final, es la encargada de presentar la información y recolectarla para hacer uso de los servicios expuestos por la capa de servicio, para satisfacer los casos de uso de la aplicación. En este trabajo se utilizó como tecnología principal una interfaz web, a través del uso de un browser. Pero la capa de servicio, puede ser consumida desde cualquier tecnología vinculada, como clientes ricos, dispositivos móviles, etc, como puede verse en algunos de los ejemplos que acompañan al trabajo. Esta capa posee sólo la lógica necesaria para juntar los datos e invocar un servicio y mostrar su resultado. De ser necesario lógica de presentación se puede agregar una capa de UIP, o capa de Proceso de Interfaz del Usuario, para poner cierta lógica relacionada con pantallas tipo wizards, que permiten ir recoletando datos de una manera mas amigable al usuario para luego invocar un único método de servicio. Pero no debe contener lógica de negocio o de aplicación ya que esta debe estar en su capas correspondientes, facilitando su mantenimiento y modificación. Para la obtención de vistas (páginas jsp) se utiliza el patrón PageController que permite obtener una vista perteneciente a un módulo. Las vistas pertenecen a un módulo y están definidas en un xml (modules.xml) En la Figura 11 puede verse un ejemplo de su utilización.

cd Figuras PageController

PageControllerBrowser Cliente

/servlet/PageController?module=moduleName&view=viewName

getViewInfo(Module, View)

buildHeaderFooter()

html Page

Figura 11

Cada vista obtenida por el PageController mantiene un estándar de encabezado y pie de página, en el encabezado se visualiza un nombre para la vista y el pie de página contiene una sección destinada a visualizar mensajes al usuario y una botonera con botones que toman diferentes acciones sobre la vista. Toda esta información es configurada en el archivo xml perteneciente a la vista. Por otro lado vamos a ver que muchas de los casos de uso del negocio van a ser para el manejo de creación, modificación y borrado de entidades de



negocio, (servicios básicos de abm de una entidad que expone la capa de servicio). Es decir vamos a tener muchas vistas relacionadas a los abms de entidades. Este manejo se generalizó a través de vistas para “Administración” (Managers) que permiten buscar la entidad a través del uso de filtros y eliminarla o editarla o crear una nueva, a través de la vistas para “Edición” y “Alta” (Editor y New) que permiten la modificación de la entidad, y la vista de Selección (Selector) que permite seleccionar una entidad para utilizarla en otra vista. Todas estas vistas para manejos de abm y selección son manejadas a través de un control llamado EntityManager, que a partir de un nombre de vista y tipo, presenta dicha vista para manejo de esa entidad a través de los métodos expuestos en la capa de servicio. Un ejemplo del mismo puede verse en la Figura 12

cd Figuras EntityController

Browser Cliente EntityController

/servlet/EntityController?entity=entityName&useCase=useCaseType

EntityInfo:= getEntityInfo()

buildPage(EntityInfo)

html Page

Figura 12

En los archivos xml corrspondientes a las entidades (entityName.entity.xml) se puede definir que atributos del obtejo DTO, visualizar, de que tipo de dato es, facilitando verificaciones de dato sobre el control html renderizado, con que nombre visualizar al atributo, valor inicial por defecto, etc. El EntityController sabe a partir del useCase recibido como armar la vista, los posibles useCase con: manager, editor, new, selector, cada uno tiene una funcionalidad dada sobre la entidad, el manager permite a tarvés de sus filtros realizar búsquedas de las entidades, seleccionar una y borrarla, o llamar al editor o new, permitiendo modificar la entidad seleccionada o crear una nueva. El selector se utiliza para seleccionar una entidad a través de un filtro, es similar a una manager pero la entidad seleccionada permite llevarla a otra vista para procesarla. Para la ejecución de métodos de servicio en general (como hacen las vistas obtenidas con el EntityController para ejecutar los métodos de servicio correspondientes a los abms simples de entidades), se hacen a través del patrón ActiveFront o Ajax, para los mismos es necesario dar de alta la



información correspondiente a la acción que representa al método de servicio a ejecutar en el archivo xml de acciones (servlet-actions.xml) En la Figura 13 se observa un diagrama de secuencia de una invocación a una acción.

cd Figuras Inv oker

User

Browser Cliente JavaScriptObjectInv oker

Inv oker

result := Instantiate( ActionInfo.class, ActionInfo.method, ActionInfo.parameters )

executeAction(parameters)

ActionXmlRequest:= buildActionXMLRequestFromPage(parameters)

execute(ActionXmlRequest)

/servlet/Invoke?ActionXMLRequest

ActionInfo:= process(ActionXmlRequest)

xmlResult:= serializeXML(result)

xmlResultxmlResult

renderResultInPage(xmlResult)

Figura 13

Diagrama de paquetes del Framework En el diagrama de paquetes de la Figura 14 se muestra la arquitectura resultante, implementada según las capas que se analizaron. Esta arquitectura será analizada en detalle en una próxima sección. Se distinguen en dos colores, la parte genérica del framework y la parte especializada para la aplicación o caso de estudio.



cd Caso de Estudio - Pequi

presentation

+ fwk

(from framework)

fwk


(from presentation)

iserv ice


(from framework)

dtoEntities

+ CustomData+ pequi

(from iservice)

serv ice


(from framework)

pequi


(from iservice)

ot


(from pequi)

domainModel

+ fwk

(from framework)

fwk

+ pequi

(from domainModel)

pequi


(from fwk)

ot

+ ComponenteFwk+ EstadoDeOrdenFwk+ EstadoDeProcesoFwk+ MaterialFwk+ NotaFwk+ ObservacionFwk+ OrdenDeTrabajoFwk+ ProcesoFwk+ SolicitanteFwk+ TipoDeProcesoFwk+ TipoMaterialFwk+ TurnoFwk

(from pequi)

pequi


(from service)

ot


(from pequi)

persistence

+ caseStudy+ fwk

(from framework)

caseStudy

+ pequi

(from persistence)

pequi


(from caseStudy)

ot

+ ComponenteMapper+ EstadoDeOrdenMapper+ EstadoDeProcesoMapper+ MaterialMapper+ NotaMapper+ ObservacionMapper+ OrdenDeTrabajo_pequi_ot_MaterialDomainObjectCollectionRelation+ OrdenDeTrabajo_pequi_ot_Observacion_mtmDomainObjectCollectionRelation+ OrdenDeTrabajo_pequi_ot_ProcesoDomainObjectCollectionRelation+ OrdenDeTrabajoMapper+ ProcesoMapper+ SolicitanteMapper+ TipoDeProcesoMapper+ TipoMaterialMapper+ Turno_pequi_personas_PersonaFisica_mtmDomainObjectCollectionRelation+ TurnoMapper

(from pequi)

utils

+ caseStudy+ exceptions+ helpers+ log+ persistence

(from framework)

caseStudy

+ NonPersistenceBroker+ PersistenceBrokerFactory+ StringHelper+ IKey+ IPersistenceBroker

(from utils)exceptions

+ ApplicationException+ BusinessLogicException+ ConcurrencyException+ ExpiredSessionException+ InvalidSessionException

(from utils)

helpers

+ CesarEncriptCryptographyHelper+ ClassHelper+ ConvertHelper+ IOHelper+ NonEncriptCryptographyHelper+ PhpHelper+ Serializer+ TypeHelper+ XmlHelper+ ICryptographyHelper

(from utils)

log

+ ConsoleLog+ FileLog+ Logger+ ILog

(from utils)

persistence

+ StorageMediumException+ IReaderStorageMedium+ IStorageMedium+ db

(from utils)

db

+ BDatos+ BDatosException

(from persistence)

pequi


(from dtoEntities)

ot


(from pequi)

fwk

+ Context+ DomainObject+ DomainObjectCollection- DomainObjectCollectionIterator- DomainObjectCollectionIterator+ DomainObjectCollectionRelation+ IdentityMap+ Key+ KeyGenerator+ Mapper+ PersistenceBroker+ Registry+ UnitOfWork+ IDomainObject+ IFinder+ IKeyGenerator

(from persistence)

remoting

+ client+ server

(from framework)

client


(from remoting)

serv er

+ ServicePublisher

(from remoting)

«xml»Finder

«xml»Regsitry

«xml»Modules

«xml»Actions

«xml»Presentation

Serv ices

Application Serv ices

«xml»Entites

Figura 14

Si se observa el código de la parte especializada se nota que la misma es repetitiva y que puede automatizarse. Una opción de automatizarla es mediante reflection, es decir que en tiempo de ejecución las clases del framework agreguen el comportamiento dado, leyendo la información faltante desde archivos descriptores, y la otra opción es la de generación de código, es decir generar las clases necesarias que especializan al framework en tiempo de desarrollo.



Cada uno tiene sus ventajas y desventajas, éstas son analizadas en la sección “Alternativa Reflection vs Generación de Código”



Aspectos relacionados a las capas del Framework

Seguridad Autenticación y Autorización (Control de Acceso) 1) Autenticación 2) Autorización

Autenticación Es el proceso por el cual se verifica que alguien (un sistema o un usuario) es quien dice ser. En el presente trabajo se implementó utilizando un nombre de usuario y un password, sistemas mas complejos pueden utilizar cualquier otro método para reconocer la identidad, como keys, smart cards, escaneo de retina, huella digital, reconocimiento de voz, etc Además se puede limitar el acceso de acuerdo a la fecha, la dirección de acceso, etc, para dificultar que el identificador se sesión pueda ser utilizado por alguien no deseado que pueda obtenerlo sin autenticarse. La Interfaz de Autenticación se muestra en la Figura 15.

cd Control de Acceso

«interface»caseStudy::IAccessControl

+ login( name, password) : Token+ logout(Token) : void+ checkValideSession(Token) : void+ checkPermission(Context) : void

Figura 15



Autorización Es el proceso por el cual se distingue si una persona, una vez autenticada, tiene o no permiso de acceso a un recurso. Generalmente las personas pertencen a un grupo que posee diferentes permisos a recursos. Es decir se limita la funcionalidad del aplicativo según el rol del usuario.

Seguridad al nivel Servidor de Presentación El servidor de presentación autentica a los usuarios al iniciar la aplicación para ya mantener su identificador de sesión en la sesión a lo largo de toda la navegabilidad del sistema. Cualquier aplicativo que desea autenticarse, consumirá los servicios de Control de Acceso, el mismo expone métodos como logout(idSession), y, login(name, pass) y checkSession(idSession) que no necesitan autenticación, De esta manera, cualquier aplicativo se autentica y obtiene un id de sesión luego de hacer el login, y con él puede identificarse a lo largo de la sesión. Como el punto de acceso a la capa de presentación es el patrón PageController, es decir a través de los servlets PageController, EntityController, por lo que cada petición a una vista de la aplicación pasa por ellos, este es un buen lugar para verificar que quien la solicita este autenticado. De no estarlo se redirige al sistema de Control de Acceso a que se identifique. El framework proporciona una implementación a la interfaz IAcessControl, pero la misma podria vincularse a cualquier frameworks, sistema de control de acceso existente, o vincularlo con Active Directory por ejemplo. Seguridad al nivel Servidor de Aplicaciones En esta arquitectura basada en capas, la fachada de servicio es el punto de acceso de los usuarios desde la capa de presentación, por lo que es un buen lugar para colocar la autenticación. Cada servicio, de esta fachada debe verificar que el usuario en el contexto dado, este autenticado y luego verificar si posee privilegio de acceso a ese servicio. Para lograr esto, cada servicio toma por parámetro un objeto de la clase Context, que posee un atributo que es un identificador de sesion. Dicho valor se obtiene al autenticarse y debe ser mantenido durante toda la sesión, este id de sesión tiene un tiempo de validez configurable, por ejemplo 30 minutos, cada vez que el usuario accede a un servicio, este identificador actualiza su fecha de último acceso, de pasar el tiempo determinado en forma inactiva, ese identificador de sesión se inactiva.



Al invocarse un servicio, se verifica que el id de sesión sea válido sino es así, se lanza una excepción de InvalidSession o ExpiredSession. De ser válida, se pasa a verificar la autorización del mismo. Si no posee permiso se lanza una excepción de UnAuthorizedException en caso contrario se ejecuta el servicio normalmente. En la Figura 16 se muestra la jerarquía de excepciones mencionada.

cd Excepciones AccessControl

exceptions::BusinessLogicException

+ BusinessLogicException()+ BusinessLogicException(String)+ BusinessLogicException(Exception)

Exception

UnAuthorizedException

+ UnAuthorizedException()+ UnAuthorizedException(String)+ UnAuthorizedException(Exception)

Inv alidSessionException

+ InvalidSessionException(String)

UnAuthenticatedException

+ UnAuthenticatedException()+ UnAuthenticatedException(String)+ UnAuthenticatedException(Exception)

ExpiredSessionException

+ ExpiredSessionException(String)

- innerException: Exception

Figura 16 Toda esta faceta de seguridad se agrega a la capa de servicio que es expuesta. Si se trabaja en un mismo espacio físico de memoria se debe guardar el contexto en la sesión, y si se trabaja remotamente, el proxy cliente generado, debería en cada invocación tomar el contexto y enviarlo por parámetro al proxy del lado servidor, donde este lo almacena en memoria o sesión. Luego cada método de servicio debe verificar con la información del contexto si está habilitado o no para ejecutar dicho servicio. Otra opción es la utilización de Aspect Programming para agregar estos aspectos al comportamiento de la aplicación.



También podría utilizarse un Adapter que toma de sesión el contexto o lo recibe en una instancia de Context, verifica la seguridad y delega la ejecución del servicio a la clase de servicio como muestra la Figura 17.

cd Control de Acceso

«interface»caseStudy::IAccessControl

+ login(String, String) : String+ logout(String) : void+ checkValideSession(String) : void+ checkPermission(Context) : void

DemoServ ice

+ doService(ObjectDTO) : void

DemoServ iceSecure

+ doService(ObjectDTO) : void- doService(ObjectDTO, Context) : void

«interface»IDemoService

+ doService(ObjectDTO) : void

«realize»«realize»

Figura 17



Concurrencia La concurrencia al sistema se implementó a partir del manejo de threads que dispone el servidor web administrando servlets, mediante la generación de un nuevo thread frente a cada nuevo request. Para resolver los problemas generados por el acceso concurrente al sistema y evitar adaptaciones perdidas y lecturas inconsistentes se implementó un esquema de detección de estos escenarios. Para esto se balanceó la corrección de los datos y la responsibidad del sistema. Se utilizó un patrón que detecta errores y genera avisos de que la transacción tuvo problemas y hay que rehacerla. El patrón utilizado es Optimistic Lock. Respecto de la transaccionalidad del sistema, la misma se implementó mediante la administración de las transacciones de negocio por un patrón llamado Unit of Work. El mismo lleva un registro de los objetos que participaron en la transacción y de que forma lo han hecho, y frente a un comando commit, genera las acciones para mantener la consistencia entre dichos objetos y los de la base de datos. La sesión puede administrarse en

a) el cliente, b) el servidor de aplicación, c) la base de datos, d) la memoria del web server

Se optó por utilizar sesión en el web server para mantener información de contexto vinculada a la seguridad, y si es necesario para vistas que necesiten hacer uso de ella, pero no compartir sesión entre distintas capas. Compartir sesión entre las capas, hace que sea difícil escalar la aplicación mediante el uso de mas servidores, ya que si comparten sesión dos servidores, se genera un vínculo entre ellos, dificultando por ejemplo cambiar una petición (por balanceo de carga) a otro servidor de aplicaciones que se encuentra con menor carga de procesamiento en un instante dado.



Auditoria La auditoría del sistema debería incluirse en la capa de servicio, ya que este es el punto de acceso a los mismos, antes de ejecutar el servicio y justo despues de autorizar, podría loguearse que servicio y con que parámetros utilizó cierto usuario, mas información adicional como fecha, hora, ubicación física, etc Este es uno de los temas a futuro para continuar elaborando. Su esquema es similar al de seguridad, ya que es un aspecto mas que se le agrega a la capa de servicio. Dotándo al framework con una aplicación de auditoría, un administrador del sistema podría ver instantaneamente que operaciones esta haciendo cierto usuario, que datos esta utilizando en dichas operaciones, ver un historial de sus operaciones, horarios de acceso, etc. Podría permitirsele al administrador inhabilitar a un Token, o limitar los privilegios de un usuario autenticado si ve que esta haciendo mal uso de ellos.



Excepciones Inicialmente se pueden clasificar las excepciones en dos grandes jerarquías, una orientada a excepciones de negocio, es decir infracciones a reglas de negocio, las cuáles deben ser informadas al usuario para que tome una acción con respecto a ellas. A éstas se las llama excepciones de negocio y en la jerarquía de clases extienden a Exception generando una rama mas especializada llamada BusinessLogicException, de la cuál se irán especializando las excepciones a reglas de negocio del dominio analizado. La otra rama, es la de excepciones ocurridas por errores en runtime en la aplicación, como ser la indisponibilidad de la red, de la base de datos, etc. Todos estos errores que pueden ocurrir en el transcurso del uso de la aplicación, se van a ubicar en la jerarquía de excepciones bajo ApplicationException que también especializa a Exception. Todas estas excepciones deben ser logueadas e informadas a un administrator. Al usuario sólo se le informará un mensaje amigable diciéndole que el sistema momentaneamente no puede resolver su petición y que se comunique con un administrador. Dentro de las excepciones de negocio hay una particular que es ConcurrencyException que ocurre cuando al intentar finalizar una transacción se detecta que los datos con los que se comenzó la transacción han sido modificados por otra transacción, por lo que para evitar los problemas de concurrencia analizados (ver sección de “Concurrencia”), se lanza esta excepción, la cual es informada al usuario, para que realice nuevamente la operación. Y otras excepciones utilizadas en el framework son las vinculadas a la seguridad InvalidSession, ExpiredSession y UnAuthorizedException, (ver sección de “Autorización/Autenticación”) Esta jerarquía de excepciones se muestra en la figura 18.



cd Excepciones

exceptions::ApplicationException

+ ApplicationException()+ ApplicationException(String)+ ApplicationException(Exception)

exceptions::BusinessLogicException

+ BusinessLogicException()+ BusinessLogicException(String)+ BusinessLogicException(Exception)

exceptions::ConcurrencyException

+ ConcurrencyException(String)+ ConcurrencyException(Exception, String)

Toda excepción producida por fallos en la aplicación que no se deban a reglas de negocio heredan de ApplicationException

La capa de presentación puede visualizarun mensaje genérico de error, pidiendo al usuario que se comunique con el servicio técnico de la aplicación.Esta excepción generalmente es logueada y se notifica al administrador.

Toda excepción que ocurra debido a que no se cumple con una regla de negocio hereda de BusinnessLogicException y el cliente (capa de presentación) decidirá que hacer con ella.Normalmente le informa al usuario visualizando el mensaje de la regla de negocio que no se cumple.

ConcurrencyException es la excepción que ocurre cuando se quiera actualizar, oborrar un objeto cuya versión no es la versión con que el usuario estuvo trabajando, es decir alguien modificó algún objeto interviniente mientras el lo estaba usando. Esto es por el uso de OptimisticLock para el manejo de concurrencia.

Exception

UnAuthorizedException

+ UnAuthorizedException()+ UnAuthorizedException(String)+ UnAuthorizedException(Exception)

InvalidSessionException

+ InvalidSessionException(String)

UnAuthenticatedException

+ UnAuthenticatedException()+ UnAuthenticatedException(String)+ UnAuthenticatedException(Exception)

ExpiredSessionException

+ ExpiredSessionException(String)

- innerException: Exception - innerException: Exception

Figura 18



Despliegue El framework permite que la aplicación sea desplegada físicamente en un único servidor o en varios servidores. Esta propiedad permite separar fisicamente la capa de presentación de la capa de negocio (en un Servidor de Presentación y otro Servidor de Aplicaciones). En estos casos, puede utilizarse un firewall para poner la limitación de que sólo el Servidor de Presentación tenga acceso al Servidor de Aplicaciones. Del mismo modo, si se separa físicamente la capa de persistencia de la capa de datos (en un Servidor de Aplicaciones y otro Servidor de Datos) puede limitarse con un firewall el acceso al Servidor de Datos y permitirle acceder solo al Servidor de Aplicaciones. Esta distribución de las capas lógicas se muestra en la figura 19a.

dd Despliegue Logico

Serv idor Web

Cliente (Browser)

Serv idor de Aplicaciones

Serv idor de Base de Datos

Presentation Layer

Service Interface

Domain ModelLayer

Persistence Layer

Service Layer

Service Interface

Persistence InterfaceData Source Layer

Proxy Proxy

Figura 19a Una vez generadas las librerías (archivos .jar) que contienen los paquetes de cada capa, los mismos se desplegarán físicamente en cada servidor como se indica en la Figura 19b. Como puede verse la librería common debe desplegarse en ambos servidores, ya que contiene la interfaz entre ambas capas.



dd Despliegue

Cliente (Browser)

Serv idor Web

Serv idor de Aplicaciones

Serv idor de Base de Datos

«library»Componentes::Back.jar

«library»Componentes::Front.war

«library»Componentes::Common.jar

Componentes : FrontComponentes : Common Componentes : Back

<< TCP / IP >>

<< HTTP >>

Figura 19b

La librería front ( front.war ) esta compuesta como se muestra en la Figura 19c

cd Figuras Librerias Front

«library»front.war

«jsp/html pages»web pages

presentation

+ fwk

(from framework)

fwk


(from presentation)

remoting

+ client+ server

(from framework)

client


(from remoting)

Figura 19c

La librería common (common.jar) esta compuesta como se muestra en la Figura 19d



cd Figuras Librerias Common

«library»common.jar

iserv ice


(from framework)

dtoEntities

+ CustomData+ pequi

(from iservice)

pequi


(from iservice)

ot


(from pequi)

pequi


(from dtoEntities)

ot


(from pequi)

IService representa el conjunto de interfaces que implementa cada clase de la Capa de Servicio y el conjunto de objetosDTO que exponen las mismas como parámetros.Este paquete se encuentra en la librería common.jar que es desplegada tanto en el Servidor de Presentación como en el Servidor de Aplicaciones.

utils

+ caseStudy+ exceptions+ helpers+ log+ persistence

(from framework)

caseStudy


(from uti ls)exceptions


(from uti ls)

helpers


(from uti ls) log


(from uti ls)

persistence

+ StorageMediumException+ IReaderStorageMedium+ IStorageMedium+ db

(from uti ls)

db


(from persistence)

Figura 19d La librería back está compuesta como se muestra en la Figura 19e.



cd Figuras Librerias Back

«library»back.jar

serv ice


(from framework)

pequi


(from service)

persistence

+ caseStudy+ fwk

(from framework)

caseStudy

+ pequi

(from persistence)

pequi


(from caseStudy)

ot

+ ComponenteMapper+ EstadoDeOrdenMapper+ EstadoDeProcesoMapper+ MaterialMapper+ NotaMapper+ ObservacionMapper+ OrdenDeTrabajo_pequi_ot_MaterialDomainObjectCollectionRelation+ OrdenDeTrabajo_pequi_ot_Observacion_mtmDomainObjectCollectionRelation+ OrdenDeTrabajo_pequi_ot_ProcesoDomainObjectCollectionRelation+ OrdenDeTrabajoMapper+ ProcesoMapper+ SolicitanteMapper+ TipoDeProcesoMapper+ TipoMaterialMapper+ Turno_pequi_personas_PersonaFisica_mtmDomainObjectCollectionRelation+ TurnoMapper

(from pequi)

fwk

+ Context+ DomainObject+ DomainObjectCollection- DomainObjectCollectionIterator- DomainObjectCollectionIterator+ DomainObjectCollectionRelation+ IdentityMap+ Key+ KeyGenerator+ Mapper+ PersistenceBroker+ Registry+ UnitOfWork+ IDomainObject+ IFinder+ IKeyGenerator

(from persistence)

domainModel

+ fwk

(from framework)

fwk

+ pequi

(from domainModel)

pequi


(from fwk)

ot

+ ComponenteFwk+ EstadoDeOrdenFwk+ EstadoDeProcesoFwk+ MaterialFwk+ NotaFwk+ ObservacionFwk+ OrdenDeTrabajoFwk+ ProcesoFwk+ SolicitanteFwk+ TipoDeProcesoFwk+ TipoMaterialFwk+ TurnoFwk

(from pequi)

remoting

+ client+ server

(from framework)

serv er

+ ServicePublisher

(from remoting)

ot


(from pequi)

Figura 19e



Analizando los Patrones Utilizados Se analizan los patrones utilizados en la implementación de las distintas capas de ésta arquitectura. Y como se adaptaron a los mismos para que en conjunto tengan el comportamiento esperado para el framework. Identificación Buscando evitar la inconsistencia que a veces se produce con el uso de datos del dominio como identificación unívoca de los registros en una tabla (o en el medio persistente), se selecciona el patrón Identity Field [Martin Fowler 2003] para poseer un mecanismo de identificación de objetos. Pero, como se respeta la restricción de no modificar las clases de dominio, no se agregó este atributo a estas clases de dominio como lo indica el patrón. Por otro lado, la capa de persistencia necesita poder identificar a los objetos de dominio en forma genérica, por lo que se necesita hacer uso del patrón Domain Supertype [Martin Fowler 2003], cuya clase Domain Object encapsula los mecanismos generales vinculados con la persistencia y la administración de la identificación de los objetos. Sin embargo esta solución como se analizó anteriormente también modifica a las clases del dominio. Para romper con esta dependencia se recurrió al uso del patrón de diseño Adapter [Gamma et al, 1995]. Un diagrama de clases se muestra en la Figura 20. Donde se genera una nueva clase “DomainObjectAdaptada” o “DomainObjectFwk” que extiende a la clase de dominio que no podemos modificar y agrega el comportamiento faltante a través de la clase DomainObject, a quien le delega dichas tareas para no repetir este comportamiento cada vez.

cd Data Model



Figura 20

Sin embargo este patrón no alcanza a resolver completamente el problema ya que los objetos instancias de las clases del dominio al ser manipuladas en la Capa de Persistencia, deben ser de un tipo genérico para poder trabajar a



nivel abstracto sin necesitad de conocer con que objeto de dominio se trabaja concretamente. Esto es así ya que lo requiere funcionalidad asociada con la capa de Persistencia. Por esta razón fue introducida la interfaz IDomainObject la cúal es implementada por cada ClaseDominioAdaptada. El patrón finalmente fue implementado como muestra la Figura 21.




«realize»«real ize»

Figura 21 De esta manera se logra identificar univocamente a cada objeto del dominio, y agregarle el comportamiento adicional necesario para el manejo de persistencia sin modificar la clase de dominio. La capa de persistencia va a interactuar con objetos que implementen IDomainObject, es decir cualquier ClaseDominioAdaptada.

En el framework desarrollado se usó este patrón para cumplir con el requerimiento impuesto de que el modelo del dominio no sea alterado, es decir no tenga dependencias de la capa de persistencia. El mismo es una adaptación del DomainSupertype Su utilización en el framework puede verse en las clases IDomainObject, DomainObject y las clases generadas a partir de las clases de dominio.



Consideraciones importantes realizadas sobre el Identity Field: Clave simple o compuesta (relación con Foreign Key y con

Compound Key, [Martin Fowler, 2003]. Una clave simple hace uso de un solo campo en la base de datos y un solo atributo en el objeto asociado, mientras que una clave compuesta usa mas de uno. Una clave compuesta es de utilidad ya que contiene mayor información en determinados contextos, sin embargo, dificulta la generalización al momento de generar código para su administración. Se decidió utilizar una clave simple.

Tipo de dato asociado. El uso de variables de tipo numéricas facilita la

manipulación al momento de su comparación e incremento.

Se decidió utilizar una clave numérica. Identificador único por base de datos o por tabla (relación con Identity

Map y con los patrones de mapeo de jerarquías de herencia a tablas relacionales). La clave puede ser administrada para cada tabla o para toda la base de datos. El uso de la última está directamente relacionado con la utilización de un único Identity Map para toda la base de datos. Esta estrategia está también vinculada con la seleccionada para el mapeo de jerarquías de herencia a las tablas. Es más simple la utilización de claves por jerarquías que claves por tabla cuando se usan los patrones Concrete Table Inheritance y Class Table Inheritance. Los patrones mencionados serán tratados más adelante en este documento.

Se decidió utilizar una clave única por base de datos.

Ubicación, en el objeto, de la administración de este recurso (relación

con Domain Object, tratado más adelante en este documento). Un lugar apropiado para la administración de este recurso, si seleccionan las estrategias que permitan escribir código genérico, es la clase Domain Object, raíz de la jerarquía del modelo de negocio.

Se decidió agregarla en la clase DomainObjectAdaptada

Obtención de una nueva clave y generación única. A efectos de contar

con un generador de claves se puede implementar a éste de distintas maneras. Usando alguna funcionalidad brindada por la base de datos (database counter), un generador asociado con el sistema (GUID: Globally Unique Identifier), un algoritmo basado en el incremento de la mayor clave en uso (table scan) o una tabla asociada donde se guarda el valor de la última clave asignada y una clase que administra su lectura, asignación e incremento (key table).



Se decidió administrarla mediante el uso de una tabla de claves, para obtener independencia con el motor de base de datos, manteniendo la simplicidad y performance al obtenerla.

En el framework desarrollado se utilizó una clave numérica y simple. Para la implementación se utilizó una tabla propia para la administración de las claves y una clave única para toda la base de datos. Esto último debido al uso del patrón Class Table Inherence para el mapeo de las jerarquías de herencia. Este análisis se puede ver en la sección donde se presenta dicho patrón. Se puede ver su implementación en el file Key.java y Bdatos.java de los paquetes framework\persistence\fwk y framework\utils\persistence\db. Patrones relacionados De las consideraciones realizadas en la sección anterior se desprende que los patrones relacionados son los que se muestran en la Figura 22.

Identity Field

Identity Map

Foreign Key

Single Table Inheritance

Class Table Inheritance

Concrete Table Inheritance

Compound Key

Simple o Compuesta

Unica por base o clase

Unica por base o clase ojerarquia de clasesUnica por base o clase

o jerarquía de clases

Unico por base o clase, Simple o Compuesto

Figura 22



Asociaciones Se utilizaron los patrones Foreign Key Mapping, Association Table Mapping [Martin Fowler, 2003] para mantener las relaciones entre objetos. Se plantean problemas diferentes, dependiendo de las diferentes relaciones de agregación entre objetos:

Relación uno a uno. Relación de uno a muchos. Relación de muchos a muchos.

Este problema se plantea por la forma diferente de relacionar objetos y tablas entre sí. Los objetos se relacionan a partir de referencias (direcciones de memoria) y los registros de las tablas de la base de datos a partir de claves. Además, los objetos pueden mantener colecciones de relaciones desde una única instancia mientras que las tablas en forma normal mantienen relaciones únicas. Para la resolución de estos problemas se utiliza el patrón ya introducido (Identity Field), para mapear las relaciones entre referencias entre objetos y claves entre tablas. Este patrón es conocido como Foreign Key Mapping. Cuando las relaciones son de muchos a muchos el problema se resuelve utilizando el patrón Association Table Mapping. En el caso de la asociación uno a uno, se añade el uso del patrón Lazy Load para evitar la carga transitiva de los objetos asociados. El mismo retrasa la carga de la instancia en forma transparente hasta el momento de ser utilizada. Esto está implementado en los getters de las clases DomainObjectAdaptadas ya que son redefinidos en ésta clase derivada para agregar este comportamiento. En las relaciones de uno a muchos, y muchos a muchos, se utilizó una AbstractDomainObjectCollection que es una variante del patrón Value List Holder. Del mismo modo en los getters de las collecciones correspondientes a relaciones múltiples, se accede a través de las clases DomainObjectAdaptadas a éstas collecciones, que a medida que las mismas son iteradas, van cargando de a N instancias, debido a que en su iterador manejan la carga tardía.

En el framework desarrollado se usó el patrón Foreign Key Mapping para las relaciones de tipo agregaciones uno a uno. Esto fue implementado usando un campo adicional en los registros de la tabla que representa la clase que posee la relación. Para las relaciones uno a muchos y muchos a muchos se utilizó en el modelo de objetos una colección DomainObjectCollectionRelation derivada de Collection del API de Java. En la base de datos se genera una tabla de relaciones en ambos casos. En el caso de uno a muchos, una de las columnas repetirá sus valores para el objeto único, en el caso muchos a muchos se tienen valores que identifican



cada instancia del conjunto relacionado. Esta tabla se construye con el nombre de ambas clases relacionadas. La colección asociada tiene capacidad de administrar la consistencia entre las instancias en memoria y los registros correspondientes en la base de datos. Es decir, distinguir las nuevas instancias de las ya persistidas y eliminadas (refiriéndose siempre a las referencias de las instancias que participan de la relación). En todos los casos se administra la carga tardía de las instancias utilizando el patrón LazyLoad, solo cargando las claves de las instancias que participan de las relaciones, esto puede verse en la redefinición de los getters y setters de las DomainModelAdaptadas (DomainModelFwk). Se puede ver su implementación en el file DomainObjectCollectionRelation.java y ClaseDominioFwk.java de los paquetes framework\persistence\fwk y framework\domainmodel\fwk.. Patrones relacionados a esta elección De las consideraciones realizadas en la sección anterior se desprende que los patrones relacionados son los que se muestran en la Figura 23.

cd Data Model

ForeignKey IdentityField

LazyLoad

Figura 23



Mapeos de objetos a tablas Se utilizó el patrón de Class Table Inheritance para el mapeo de jerarquías de objetos en la base de datos relacional. De las tres alternativas de implementación del mismo: Single Table Inheritance Class Table Inheritance Concrete Table Inheritance

Se seleccionó la de Class Table Inheritance como mapeo por defecto para el generador de código (pero puede utilizarse cualquiera en el framework). Se seleccionó este tipo de mapeo porque administra los datos en forma normalizada en la base de datos y es mas directa la analogía entre una clase y una tabla. En el framework desarrollado se usó el patrón ClassTableInheritance. Se puede ver su implementación en el file AbstractMapper.java y en el mapper concreto de cada clase de dominio que participe de una jerarquía de herencia, cuyo código es parte del código generado. Los paquetes que contienen estos files son framework\persistence\fwk y framework\persistence\casestudy. Patrones relacionados En la Figura 24 se muestran los patrones relacionados con los vistos en este apartado.



Identity Field

Identity Map




Inheritance Mapper

Compound Key

Unica por base o portabla

Unica por base o tabla ojerarquia de clasesUnica por base o tabla o

jerarquía de clases

Unico por base o tabla, Simple o Compuesto

Unico?

Figura 24



Consistencia Se garantiza la consistencia entre objetos cargados de la base de datos. Si se carga desde la base de datos dos veces la misma fila de una tabla y se instancian a partir de ella dos objetos, los mismos son dos instancias de una misma entidad. Operar sobre ambas sin control lleva a inconsistencias. Se debe asegurar una sola instancia de cada objeto a efectos de evitar inconsistencias al cambiarlo. Este problema se resuelve aplicando el patrón Identity Map, éste mantiene referencias a los objetos cargados y devuelve las mismas cada vez que se solicita un objeto ya cargado. De esta forma actúa como un cache dentro de la transacción, lo cual también contribuye a reducir el número de accesos a la base de datos. Al momento de implementar este patrón se tuvieron en cuenta las siguientes cuestiones: Elección del tipo de clave a usar: esta elección impacta directamente

en la implementación del Map. Una clave simple facilita la implementación ya que se usa esta misma como clave del Map.

Identity Map explicito o genérico: un Map explícito implica el uso de

distintos métodos para realizar las búsquedas findObjetoTipoA(key), uno para cada tipo de objeto. En uno genérico se realiza con uno único find(“ObjetoTipoA”, key). Esta elección esta vinculada con la anterior ya que se puede implementar un Map genérico si también usamos el mismo tipo de clave para todos los objetos. Y si la clave es única para toda la base de datos, directamente find( key )

Cuántos utilizar: en cada sesión se puede usar un Map por clase o uno

único. Otra vez uno único implica que se ha seleccionado el mismo tipo de clave para todos los objetos. Esta selección facilita las búsquedas ya que solo hay que realizarlas en un único lugar. Cuando existen jerarquías de herencia es más fácil la administración de un Map único, pero esto implica el uso de claves únicas para la jerarquía de clases.

Dónde ubicarlos: el compromiso aquí es la existencia de una única

instancia por sesión y el uso fácil del mismo. Es decir que se debe ubicar sobre un objeto de sesión. Los lugares indicados si se están utilizando son el Unit of Work o el Registry. Otro lugar apropiado es vincularlos a los Mappers.

En la Figura 25 se muestra un diagrama de secuencia con la dinámica de este patrón.



finder Identity Map base de datos

Algun Objeto

find(1)

found = get(1)

[found is null ] found = select where id = 1

[found not null ] found

Figura 25 En el framework desarrollado se usó uno único IdentityMap para todas las clases, esto es consistente con la selección de una única IdentityField por base de datos. Este IdentityMap se ubicó la UnitOfWork como se verá en la sección donde se describe este patrón. Se puede ver su implementación en el file IdentityMap.java del paquete framework\persistence\fwk.



Patrones relacionados En la Figura 26 se muestran los patrones relacionados descriptos en el análisis anterior.

Identity Field

Identity Map


Data Mapper (Cuantos ???)

Compound Key

Optimistic Offline

Unit of Work

Registry

Unica por base o tabla ojerarquia de clases

Donde ?

Unico por base o tabla, Simple o Compuesto

Clave compuesta ?

Unico?

Donde ?

Figura 26



Unidad de Trabajo Cuando existen transacciones en las cuales se crean y modifican objetos, es indispensable mantener la consistencia de los objetos en memoria sobre los que se opera, y los datos correspondientes en la base de datos. Se debe conocer cuales son los cambios realizados para hacerlos persistentes. Por lo tanto es importante saber cuales objetos son nuevos, cuales fueron cargados desde la base de datos y no fueron alterados y cuales sí. Este problema es resuelto con el patrón Unit of Work. [Martin Fowler, 2003] Solución

Algun Objeto

Cliente base de datos

Unit of Work

new

select

registryClean

setDato

registryDirty

commit

save

update

Figura 27

En la Figura 27 se muestra la dinámica del patrón en la administración de las instancias de los objetos en sus diferentes estados. En la Figura 28 se muestra una posible disposición de clases formando parte de este patrón.



Session

UnitOfWork

New Objects DirtyObjects DeletedObjects

Figura 28

Consideraciones importantes realizadas sobre el Unit Of Work:

• Ubicación, la Unit of Work puede estar en la sesión, puede pasarse como parámetro entre los objetos que la usan, o puede localizarse en la Registry. En este caso se optó de ponerlo en la Registry, la cual garantiza ser única por thread y facilita el acceso de la misma.

En el framework desarrollado se incluyó el mecanismo para administrar la consistencia de las relaciones entre objetos en memoria y las relaciones persistidas, de manera similar a lo que se hace en el caso de instancias de objetos. Para esto se agregó un colección que mantiene la lista de DomainObjectCollectionRelation que se modificaron. Cuando el método commit() de la UnitOfWork es invocado, además de operar sobre las instancias de los objetos que participaron de la transacción, se hace lo propio sobre las relaciones entre los mismos. Se puede ver su implementación en el file UnitOfWork.java del paquete framework\persistence\fwk.



Patrones relacionados En la Figura 29 se muestran los patrones relacionados a este. Las relaciones están vinculadas a dónde ubicar al Unit Of Work.

O p tim is ti c O ffl in e

U n i t o f W o r k

P e s s im is tic O ffl in e

R e g is tr y

S e s s io n

S e r v le t (d o G e t)F r o n t C o n tr o l l e r

(F r o n t C o m m a n d )

D o n d e ?

D o n d e ?

Figura 29



Acceso a Servicios Comunes Al existir un número grande de clases, de las cuales muchas de ellas hacen uso de determinados servicios comunes se implementó el patrón Registry al cual se accede para obtener determinados servicios, por ejemplo obtener un finder. Patrones relacionados Los patrones relacionados son los que se muestran en el diagrama de clases de la Figura 30.

cd Data Model

Registry

Mapper

UnitOfWork Finder

IdentityMap

DomainClass DomainTable

«realize»

Figura 30

En el framework desarrollado se implementó este patrón de la forma que se muestra en la figura anterior. Además de los Mappers, en la clase que implementa este patrón, se ubicó una clase (BDatos.java) que administra los mecanismos de acceso a la base de datos. Se puede ver su implementación en el file Registry.java del paquete framework\persistence\fwk.



Acceso a los Datos Persistentes Entre Table Data Gateway, Row Data Gateway, Active Record, Data Mapper se seleccionó al Data Mapper para acceso a los datos, ya que es el mas adecuado para trabajar con Domain Model. Es la solución más elaborada pero que permite aislar por completo al modelo del dominio del de persistencia es el Data Mapper, con el cual se logra que ambas capas (Negocio y Persistencia) evolucionen en forma independiente. En las figuras que siguen se muestran diagramas conceptuales y de clases, marcando las diferencias de estos patrones. Diagrama conceptual del Data Mapper.

:ClaseDominio :Mapper «Table»:ClaseDominioTabla

Figura 31

Diagrama de clases del Data Mapper.

Mapper

+ insert(DomainObject) : void+ update(DomainObject) : void+ delete(DomainObject) : void+* save(ID, DomainObject) : void+* load(ID, DomainObject) : void

AbstractMapperJerarquia

+* save() : void+* load() : void

MapperRootJerarquia

+ find(ID) : RootJerarquia+ insert() : void+ update() : void

MapperClaseConcreta1

+ find(ID) : ClaseConcreta1+* save() : void+* load() : void

MapperClaseConcreta2

+* save() : void+* load() : void+ find(ID) : ClaseConcreta2

Figura 32

En los casos de relaciones simples, como se muestra en la figura de abajo, la jerarquía de Mappers está constituida por una clase abstracta cuya responsabilidad es definir el protocolo de uso de los mappers y el



mecanismo genérico de persistencia. El mapper concreto, para cada clase cuyas instancias son persistentes, especializa a esta y es la que administra la carga de datos desde y hacia la base de datos. O sea que hay un mapper concreto por clase de dominio. Cuando aparecen relaciones de herencia entre las clases de dominio y estas deben ser persistidas, una solución es dar de alta un nuevo mapper. Sin embargo en estos casos, este nuevo mapper estará duplicando código a efectos de administrar la parte de su clase base. Una solución más conveniente es establecer alguna relación entre los mappers, que refleje la existente entre las clases que ellos mapean. Esta relación puede verse en la Figura 33. De esta forma cada mapper heredará de otro y cada uno administrará la parte de la clase mapeada. En el caso de existir una parte base, dejará al mapper correspondiente realizar lo propio.

cd Mappers

AbstractMapper

ConcreteMapperConcreteClass

ConcretClassDeriv ada

ConcreteClassDeriv adaMapper

ConcreteClassDeriv adaMapper2

DomainObject

Figura 33

En los casos en que desde la capa de servicios se quiera obtener instancias persistidas de un tipo superior en su jerarquía de herencia, se debe contar con la posibilidad de obtener objetos de distintos tipos dentro de la jerarquía nombrada. Por ejemplo, en la figura, obtener un conjunto de objetos de tipo “C”. En este caso deberán cargarse todos los objetos “C” y también los “B”, ya que estos también son de tipo “C”. Esto es implementado como se muestra en la Figura 34 a partir de un nuevo mapper que tiene el conocimiento de todos los mappers concretos de dicha jerarquía y por lo tanto delega a cada uno de estos la administración de los datos de los tipos concretos detectando estos tipos. Esto es posible a partir de la obtención del tipo concreto que es un atributo más de las clases del framework.



cd Mappers

P

F C

B

AbstractMapper

PMapper

AbstractPM

CMapper

BMapper

FMapper

DomainObject

Figura 34

Como se describió anteriormente, en el presente trabajo se definió como requerimiento no tener que modificar las clases del modelo de dominio a la hora de utilizar el framework. Por esta razón se debió implementar los mappers de una forma diferente. Según se analizó, las clases persistentes Fwk no tienen entre ellas una relación de herencia, por esta razón los mappers tampoco tienen una relación de herencia entre sí. Según esto, no es posible realizar un upcast de un BFwk a un CFwk. Tampoco es una solución realizar un upcast hacia C, ya que los objetos de la clase C de dominio, no tienen la información necesaria para hacerlos persistentes (por ejemplo el Id de las agregaciones). La implementación que se le dio se muestra en la Figura 35, donde se observa la existencia de un mapper por clase persistente de dominio. Esta solución implicó la repetición de código a nivel de algunos mappers, precio que se paga por el fuerte requerimiento mencionado de la no modificación de las clases de dominio. Esta repetición puede evitarse a partir de la extracción en un módulos comunes.

cd Mappers

AbstractMapper

PMapper

CMapper

BMapper

FMapper

«interface»IFinder

P

F C

B


PFwk

CFwk

BFwk

Figura 35

El manejo de objetos instancias de clases de un nivel superior, que en el patrón lo administraba un mapper adicional (PM), en nuestro framework es



administrado en forma genérica por la clase AbstractMapper. Un ejemplo de este manejo puede verse en la Figura 36.

sd NuestroMapper

ServiceLayer

PersistenceBroker ClassNameMapperRegistry

Type es el ClassName correspondiente auna clase concreta

ClassNameMapper.find(Key key){// verifica si ya esta en el IdentityMapIDomainObject result = UnitOfWork.getCurrent().getDomainObject(id);if (result!=null) return result;

// sino que el mapper concreto cree el domain object concreto result = Registry.getInstance().getMapper(id.getType()).CreateDomainOject(); result.setFwk_Id(id);

// que el mapper concreto lo cargueRegistry.getInstance().getMapper(id.getType()).Load(result);

// se indica que el domain Object ya esta persistido, pues se trajo de la DB.result.setFwk_IsPersisted(true);

// se agrega al identityMap de la UnitOfWorkUnitOfWork.getCurrent().addDomainObject(result);

return result;}

find(ClassName, id)

getMapper(ClassName)

new

find(ClassName, id)

Type:= getType(ClassName, id)

Key:= newKey(Type, id)

find(Key)

Object

Figura 36

Se puede ver su implementación en el file AbstractMapper.java del paquete framework\persistence\fwk, y en los archivos generados para cada mapper de cada clase de dominio persistente, incluidas en el paquete framework\persistence\caseStudy.



Patrones relacionados Los patrones relacionados pueden verse en la Figura 37

Identity M ap

Data M apper (Cuantos ???)

Regis try

Unico po r Base de Da toso po r tab la

Domain Obj ect

Donde ?

Conoce ?

Figura 37



Carga Tardía de Objetos Se buscó la optimización en la carga de objetos con muchas dependencias desde la base de datos. Cuando el modelo de objetos del dominio es complejo, existen relaciones entre los mismos que hacen que cada vez que se carga un objeto, se carguen una gran cantidad de otros relacionados. Sin embargo, en muchos casos estos no son accedidos. Una estrategia para evitar la baja de performance en estas situaciones es desacoplar las dependencias con el uso de clases proxy que representan a los objetos relacionados y que solo generan su carga real a memoria cuando se acceden. El patrón utilizado es Lazy Load. Se muestra en la Figura 38 la dinámica del patrón.

Cliente base de datos

Algun Objeto

getOrdenes

[ordenes no cargadas]

cargarOrdenes

retornarOrdenes

Figura 38

Hay diferentes formas de implementar este patrón [Martin Fowler, 2003] Lazy Initialization: este es la implementación más simple. Consiste en implementar la lógica de carga de los objetos relacionados en los métodos de acceso a los mismos. De esta forma se demora la carga real hasta el momento en que es accedido por primera vez. La desventaja de esto es que hay conocimiento de esta carga dentro del objeto del dominio.



Class DO1 ... { private DO2 do2; public DO2 getDO2(){ if( do2 != null){ do2 = DO2.find(this.id); } return do2;

} } Virtual Proxy: Para evitar esta dependencia se utiliza un proxy que encapsula el conocimiento de la carga de los objetos relacionados. De esta forma los objetos de dominio ven a sus relaciones a través de dicho proxy, el cual administra la carga real al momento de usar los datos. En la figura se muestran las clases que participan de este patrón.

cd lazyLoad

DomainObject1 List

VirtualList

«interface»VirtualListLoader MapperDomainObject1

DomainObject2Loader

MapperDomainObject2

Figura 39

Ghost: En esta implementación en lugar de contar con un proxy que controla el acceso a un objeto completo, la carga demorada se implementa para cada uno de los atributos de éste, contando desde un primer momento sólo con una instancia vacía e identificada a partir de su ID. La desventaja es la pérdida de performance en el control de carga y en el acceso a la base de datos para cada uno de los atributos mencionados. Por esta razón, se pueden agrupar de acuerdo a su uso, e incluso cargarlo en forma completa. La ventaja frente a la primera de las soluciones es que se puede intercambiar la referencia de la agregación, sin la necesidad de que el objeto representado por ésta se halla realmente cargado. En el caso del Lazy Inicialitation, al acceder a la agregación, el objeto representado se carga, mientras que en este caso solo se cargará cuando alguno de sus atributos sea accedido. En este caso como en la primera solución, se tiene la desventaja del acoplamiento con la capa de persistencia analizada en ese caso (Lazy Load).



En el framework desarrollado se usó Lazy Initialization para las relaciones de agregación. Se puede ver su implementación en cualquiera de los métodos de acceso a agregaciones en el file DomainObjectFwk.java correspondiente del paquete framework\domainModel\fwk. Además debido a las restricciones impuestas a la arquitectura del framework, relacionada con el aislamiento del modelo de dominio, se implementó este patrón de la forma que se muestra más abajo.

cd LazyLoadFw k

DomainObject1

MapperDomainObject1

MapperDomainObject2DomainObj ect2

DomainObj ect1Fw k

DomainObj ect2Fw k

«interface»DomainObject2Finder

Figura 40 Como se indica en la Figura 40, el hecho de haber implementado este patrón en su variante Lazy Inicialization en este framework no trae aparejada la desventaja del conocimiento de la capa de persistencia como en su versión original. Esto es debido a la implementación del patrón Adapter Domain Supertype y sus clases Fwk. Para el caso de las colecciones, se optimiza la carga de colecciones de objetos resultantes de una búsqueda desde la base de datos. Cuando se realiza una búsqueda como resultado deben instanciarse una gran cantidad de objetos. Sin embargo, en muchos casos esta colección no es completamente iterada, o lo es pero de a poco y en momentos discontinuos. Una estrategia para evitar la baja de performance en estas situaciones es evitar la instanciación completa de dichos objetos, y traer solamente como resultado de la búsqueda solo las Identiy Fields de los objetos resultantes, y dejar a la implementación del iterador de la colección el manejo Lazy Load de dichas instancias. Es decir al momento de iterar la colección, el iterador verifica si las siguientes intancias están cargadas, si es así ya retorna como resultado de la iteración, pero en caso este mismo se encarga a través de los finders correspondientes de cargar una cantidad configurable de instancias para poder continuar la iteración. Por lo que si la colección no se itera completamente o es iterada en diferentes momentos, el tiempo de la instanciación y el de realizar consultas que manejan gran cantidad de datos desde la base, son distribuidas a medida que realmente es necesario. Este patrón es conocido con el nombre de Domain Object Collection. Se Implementó una Collection cuyo iterador conoce como instanciar sus items contenidos a medida que son solicitados, realizando las cargas a modo Lazy Load de a N de ellos.



En el framework desarrollado se usó la solución descripta para la carga demorada de las colecciones. Pude verse a esta como una variante de un Virtual Proxy con un Lazy Inicialization, ya que el Virtual Proxy carga a todos los objetos de la lista mientras que en esta implementación se cargan a demanda, de a N elementos. De esta forma se evita el fenómeno ripple loading [Martin Fowler, 2003] Esta implementación pude verse en el file DomainObjectCollectionRelation.java correspondiente del paquete framework\persistence\fwk. Patrones relacionados En la Figura 41 pueden verse los patrones relacionados.

cd LazyLoadFw k

Lazy Inicialization

Adapter Domain Supertype

aislar capa de persistencia

Figura 41



Control de Concurrencia Se busca la consistencia entre objetos alterados y las tablas que le dan persistencia en la base de datos. La dinámica de una aplicación enterprise implica la modificación de objetos leídos desde la base de datos. Cuando existen transacciones en las cuales se modifican objetos, es indispensable mantener la consistencia de los objetos en memoria, sobre los que se opera, y los datos correspondientes en la base de datos. Es necesario asegurarse que ningún otro proceso no modificó las tablas asociadas después de la lectura, ya que si desde la transacción en curso se guardan cambios realizados en ella, se estaría perdiendo el cambio realizado por el otro proceso. Este problema de concurrencia se resuelve con los patrones de tipo Lock. [Martin Fowler, 2003] Las soluciones a este problema son dos y su efecto es bien distinto sobre el resultado final. Optimistic offline lock: resuelve el problema asociando un número de

versión con cada registro de la base de datos. La acción de lock consiste en la comparación entre, el valor leído y mantenido en la sesión, con el leído al momento de hacer commit. Si coinciden hay consistencia, nadie alteró ese registro desde la ultima lectura, así que se realiza el update y se incrementa el numero de versión. Sino, un aviso de falla se genera y hay que comenzar nuevamente con la transacción. En la Figura 25 se muestra esta dinámica. Este patrón es usado cuando la posibilidad de sesiones concurrentes sobre los mismos datos tiene una baja probabilidad.

Pessimistic offline lock: fuerza a la obtención de un lock sobre los

datos antes de comenzar a usarlos y los mantendrá en ese estado hasta que termine de usarlos, evitando así la posible inconsistencia. Este patrón es usado cuando la posibilidad de sesiones concurrentes sobre los mismos datos tienen una alta probabilidad. Su implementación esta basada en un lock manager el cual administra una tabla de locks. Para los detalles asociados a cada uno ver [Martin Fowler, 2003].



Sesión A base de datos

Sesión B

rollback

<------

System Transaction Boundary

<-------

<--------

BusinessTransactionBoundary

<---------

getObjeto(129)

retornaObjeto(129)

editaObjeto

getObjeto(129)

retornaObjeto(129)

editaObjeto

updateObjeto(129)updateObjeto(129)

fal laObjetoVersión

Figura 42



Sesión A base de datos

Sesión B

-------->Lock

BusinessTransactionBoundary

UnLock--------->

getObjeto(120)

retornaObjeto(129)

getObjeto(129)

errorObjetoLocked

editaObjeto

Figura 43 En el framework desarrollado se usó la variante Optimistic offline lock. Dicha implementación consta del versionado de los DomainObject y el control de la versión al momento del cierre de cada una de las transacciones del negocio. Si alguno de los objetos afectados dentro de dicha transacción no corresponde a la versión persistida, se genera una excepción de concurrencia. Se puede ver su implementación en el file AbstractMapper.java del paquete framework\persistence\fwk.



Patrones relacionados Una posibilidad es ubicar el chequeo de consistencia en el Unit of Work o en los Mappers. En la Figura 44 se muestran estas posibles relaciones.

cd LazyLoadFw k

OptimisticOfflineLockMapper

LayerSupertype

controlada

versionado en

Figura 44



Modelado del Dominio del Problema Estos son algunos de los patrones vinculados al modelado del dominio del problema y la lógica del negocio:, Transaction Script, Table Module, Domain Model, Layer Supertype. [Martin Fowler, 2003] El dominio del problema puede modelarse según una perspectiva funcional usando como base las acciones generadas en el cliente. Esta es una visión enteramente funcional y consiste en un modelo transaccional. Este modelo es adecuado en casos donde el dominio y la lógica del negocio son simples. En estos casos Transaction Script es un patrón que puede utilizarse. Cuando el dominio del problema y las reglas del negocio no son simples, este modelo conduce a paquetes de funciones sin ninguna estructura cohesiva. En estos casos es más adecuado modelar utilizando el concepto de objetos y la colaboración entre ellos a efectos de lograr la funcionalidad requerida. Estos son los casos donde utilizamos Domain Model. Entre las ventajas de estos modelos se encuentran la posibilidad de obtener código clausurado ante cambios, lo que facilita la extensión de los modelos, su re uso y mantenimiento de forma más eficiente. Sin embargo, la mayor parte de las aplicaciones usarán tecnología de base de datos relacionales, lo cual impondrá mayor trabajo a efectos de vincular a estos modelos con su persistencia, ver Table Data Gateway, Active Record, Data Mapper. Un modelo intermedio entre los dos anteriores es Table Module, el cual se basa en la organización del modelo en entidades asociadas con las tablas de la base de datos más que en paquetes o grupos de transacciones. Solución En el framework desarrollado se usó un modelo de objetos para modelar el dominio, por lo cual se optó por el patrón Domain Model. Puede verse su implementación en los archivos .java del paquete framework\domainModel\ caseStudy.

Patrones relacionados



Acceso a la Capa de Negocio Service Layer, Remote Facade, Data Transfer Object. [Martin Fowler, 2003] [Marinescu, 2002] Como vimos es importante desacoplar la capa del dominio del problema y negocio de la capa de aplicación por distintas razones. Entre ellas se pueden mencionar: Problemas en la administración de la concurrencia a partir de

transacciones de larga duración en el tiempo. Problemas en la eficiencia de las conexiones de red debido a

multiples accesos para concretar cada transacción. Alto acoplamiento entre la capa de aplicación y de negocio, lo que

implica mínimo re uso. En la figura 45 se muestra el contexto de un cliente accediendo directamente a la capa de negocio, con el consiguiente acoplamiento e ineficiencia de acceso. En este diagrama y en los siguientes (46, 47 y 48) el cliente puede ser un applet o un objeto de la capa de aplicación (servlet / jsp).

Cliente DomainObject

getAtributo1

getAtributo2

getAtributo3

getAtributo4

getAtributo5

Figura 45



Cliente1

Cliente2

Cliente3

Regla1

Regla2

Regla3

Object1

Object3

Object2

Object4

Object5

Figura 46 Solución Transformación de tipos de datos al cliente a efectos de lograr un

manejo mas apropiado con tipos usados en el cliente (ej.: string) y no objetos y sus atributos.

Reducción de la granularidad del acceso, a las capas mencionadas, al nivel de la funcionalidad especificada en los casos de uso. Esto se traduce en:

o Mejora de la concurrencia a partir de transacciones de menor duración en el tiempo.

o Mejora de la eficiencia en conexiones de red a través del acceso a las capas del negocio con un menor nivel de granularidad. Esto se traduce en un menor numero de invocaciones remotas.

Introducción del control de transacciones y seguridad. Reuso de reglas de negocio a partir del desacoplo de la capa de

aplicación (presentación).



Prueba del dominio del problema y negocio en forma separada de la capa de aplicación.

En la Figura 47 se muestra la introducción de una capa de desacoplamiento entre la de negocio y la de aplicación. Además los requerimientos contra esta capa (Service Layer) devuelven objetos que el cliente administra de mejor forma debido a la transformación de datos implícita realizada en el Data Transfer Object. En la Figura 48 se muestra el acceso a la capa de negocio a través del uso de una capa de aservicios de aplicación (Service Layer). Es importante destacar que en la capa de servicios de aplicación (Service Layer) se implementan clases que modelan directamente la dinámica de los casos de uso del sistema.

Cliente DataTransferObject ServiceLayer

getDataTransferObject

getAtributo1

getAtributo2

getAtributo3

getAtributo4

getAtributo5

Figura 47



Cliente1

Cliente2

Cliente3

Regla1

Regla2

Regla3

Object1

Object3

Object2

Object4

Object5

Serv iceLayer

Figura 48

En el framework desarrollado se utilizó el patrón Service Layer que utiliza los objetos del modelo del dominio para resolver los casos de uso de la aplicación. Se puede ver su implementación en los archivos IBaseService.java y BaseService.java del paquete framework\iservice y framework\service. Con este patrón se utilizó el patrón relacionado DataTransferObject para independizar completamente la capa de presentación de la del dominio. También con el objetivo de facilitar el transporte de información entre las capas mencionadas, agrupando los datos necesarios de presentación que se encuentran en atributos de varios objetos del dominio, también la conversión del formato de los datos mencionados. En los casos en que la aplicación sea instalada en varias capas físicas, la capa de servicio es usada en modo remoto, convirtiéndose en un Remote Facade, según se explicó en la sección Arquitectura Elegida (Capa de servicio).



Presentación Application Controller, Front Controller, Page Controller, Model View Controller, Template View. Dados los problemas en el diseño de la capa de aplicación y su lógica, el diseño de la administración de la navegación y el flujo de la aplicación se busca obtener la separación de incumbencias en módulos de presentación, lógica de aplicación y lógica de negocio a invocar a partir de esta capa. En el framework desarrollado se usó un servlet de java como patrón Page Controller para la obtención de vistas. Se puede ver su implementación en el file PageController.java del paquete framework\presentation\fwk. La implementación de este Page Controller se muestra en la Figura 49.

od Custom

«<htmlPage>»CustomPages

«<xml>»Modules

PageController

+ doGet(view :string, module :string) : htmlPage

Browser

pathFísico

- footer: string- header: string

Figura 49 En Modules se encuentra la información asociada a las vistas desarrolladas en forma manual para la aplicación y la estructura estándar de todas las vistas. Estas vistas al ser direccionadas por el Page Controller son cargadas y procesadas según la información de Modules.xml y retornadas al cliente. En toda aplicación hay vistas con funcionalidad bien determinadas, por ejemplo las orientadas a realizar alta, modificación, selección y administración de datos. Por esta razón y a efectos de facilitar el desarrollo y reuso de las mismas se utilizó un patrón denominado Entity Controller, como se muestra en la Figura 50.



cd Custom2

«<xml>»Entity

EntityController

+ doGet(useCase :string, entity :string) : htmlPage

Browser

«<html>»UsecaseTemplate

- fields: List

Figura 50 En el framework desarrollado, las solicitudes de servicios al modelo de dominio se implementó de la siguiente manera. Una vez cargada una vista, se invocan los servicios mencionados a través del patrón Active Front o AJAX. El mismo se muestra en la figura que sigue. Se puede ver su implementación en el file Invoker.java del paquete framework\presentation\fwk. El mismo se representa en la Figura 51 y se describe a continuación. on onAL Version

AL Version

tered TRIAL Version

tered TRIAL Version

Unregistered TRIAL Version


Unregistered TRIAL Versi

EA 3.51 - Unregistered TRIAL Versi

EA 3.51

Unregistered TRI

EA 3.51 - Unregistered TRI

EA 3.51

Unregist

EA 3.51 - Unregi

EA 3.51 EA 3.5

EA 3.51

DATOSVista

tabla check

combo

Acción A Acción B

Serv idor

Control

Actualiza los datos

s1Figura 51

Esta implementación puede verse como una variante del patrón MVC aplicado a aplicaciones de tipo Web o como un patrón en sí mismo.

Dado que el procesamiento de datos lo realiza el servidor en una capa de servicio y el cliente solo visualiza y captura datos que envía al servidor para que procese se busca evitar la recarga de una vista o página anteriormente cargada cuando lo único que se va a modificar entre request y request son solo datos. Ya que la vista sigue siendo la misma. Es decir se evita el rearmado de la vista con los nuevos datos y el viaje de la misma desde el servidor.

La estrategia a utilizar es la útlima indiacada en el apendice de patrones, la misma se basa en el uso de un componente llamado XML-HTTP que es



capaz de realizar requests a un servidor enviando xml y recibiendo xml como respuesta.

Relaciones Entre Todos los Patrones Analizados. La Figura 52, y 52b muestra las relaciones entre los patrones. De dichas relaciones se derivan los compromisos de diseño en arquitecturas de este tipo.

cd Relaciones Entre Patrones II

Use Case

Use CaseActor

DomainModel

TransactionScript TableModule

ActiveRecord

RowData Gateway

TableData Gateway

DataMapper




Inheritance Mapper

Pessimitic Offline Lock

Optimistick Offline Lock

Coarse-Grained Lock

Layer SuperType

Identity Field

ForeingKey Mapping

AssociationTable Mapping

Unit Of Work

Registry

IdentityMap Lazy Load

Service Layer

Remote Facade

Data Transfer Object

Assembler

Session

ubicada

Separated Interface

acceso a DB

Negocio Complejo

mapeo de jerarquía

Finders

optimizacion de consultas

admin proxy/holder

control de versión

modelo simple

mapeo de jerarquía

acceso a DB

soportedeherencia

modelo complejo

control de concurrencia

root de jerarquía de objetos

modelo simple

Negocio Intermedio

Negocio Simple

acceso a DB

implementado en términos de

ensamblagenera

desacoplar clases intercambiadas

objetos distribuidosmapeo de jerarquía

administrar relaciones

implementado en términos de

identificación de DomainObjects

admin y almacenar info de identidad

carga tardía al navegar al root

admin y almacenar info de versión

alberga

Figura 52



Figura 52 b



Framework Desarrollado Alternativa Reflection vs Generación de Código Para incorporar al framework, el comportamiento que surge del caso de estudio en sí, en principio hay dos alternativas, trabajar con reflection para ir descubriendo a las clases interactuantes en runtime con ayuda de archivos descriptores, o generar código en tiempo de desarrollo a partir del uso de relfection o alguna herramienta mediante code generation. Ambas alternativas son válidas y hay muchos frameworks basadas en ambas alternativas. Cada una tiene ventajas y desventajas frente a la otra. Análisis de comparación entre Michael J Retting y Martin Fowler [JavaWorld - 1]

• El uso de reflection dificulta el entendimiento de las excepciones ocurridas en runtime, mientras en code generation, la excepción suele ser mas clara.

• En perfomance suele ser mas óptima la generación de código que el uso de reflection, y en uso de memoria casi lo mismo.

• El código generado suele ser mas claro de entender que el código de reflection, igualmente este tipo de códigos una vez que el framework o generador de código esta listo y no posee errores, no debería modificarse, por lo cúal no sería necesario entender el código. (A excepción si se desea optimizar)

Para el presente trabajo se utilizó la generación de código para extender al framework. El mismo es una aplicación que a partir del modelo del dominio (clases del dominio) genera el código necesario para ser incluído al framework y tener una versión inicial funcionando del sistema. De la Arquitectura Propuesta al Framework El framework, presenta las clases bases de la estructura de una aplicación enterprise que resuelven los problemas anteriormente analizados, sobre ella, dado un modelo de dominio en particular se debe extender al framework para lograr una aplicación completa. Estas codificación de las clases que extienden al framework para un caso de estudio en particular, puede hacerse codificando a mano, o utilizando una herramienta como un generador de código. El uso del generador de código provee la codificación o generación de las clases que extienden al framework, brindando una ayuda en la construcción del sistema. En la Figura 53 se observan las clases de cada capa resaltando en distintos colores las que son calses que brinda el framework y las que son clases generadas a partir de la herramienta de generación de código o a mano. Y las clases de dominio que son las clases que modelan al dominio en cuestión.



Figura 53

( Verde : Código del Dominio - Amarillo : Código Generado - Gris : Código del Framework )



Detalle de las API del framework Aquí se muestra cada paquete para cada capa de la aplicacón Paquetes de Capa de Dominio del framework

framework.domainModel.fwk Paquetes de Capa de Servicio del framework

framework.iService framework.iService.dtoEntities framework.service.fwk

Paquetes de Capa de Persistencia del framework

framework.persistence.caseStudy framework.persistence.fwk

Paquetes de Capa de Presentación del framework

framework.presentation.fwk Paquetes de Capa de Utilidades del framework

framework.utils.caseStudy framework.utils.exceptions framework.utils.helpers framework.utils.log framework.utils.persistence framework.remoting.client framework.remoting.server

Paquete físico common framework.iService framework.iService.dtoEntities

Paquete físico front

framework.presentation.fwk Paquete físico back

framework.service.fwk framework.domainModel.fwk framework.persistence.caseStudy framework.persistence.fwk

Paquete físico utils framework.utils.caseStudy framework.utils.exceptions framework.utils.helpers framework.utils.log framework.utils.persistence framework.remoting.client framework.remoting.server

framework.domainModel.fwk



Contiene las clases que representan a los Domain Objects del usuario. Estas clases pueden ser generadas por el generador de código y extienden a las clases de dominio agregando el comportamiento necesario expuesto anteriormente para poder actuar en el framework dando la funcionalidad necesaria.

cd Data Model

Persona

+ «property get» getNombre() : string+ «property set» setNombre(string) : void

PersonaFwk

+ «property get» getNombre() : string+ «property set» setNombre(string) : void+ markDirty() : void+ getId() : string+ setId(string) : void+ getVersion() : string+ setVersion(string) : void

DomainObject

+ markDirty() : void

«interface»IDominaObject

+ markDirty() : void+ getId() : string+ setId(string) : void+ getVersion() : string+ setVersion(string) : void

«realize»

- Nombre: string

Figura 54

En la Figura 54 vemos a la clase Persona, pertenece a la Capa de Dominio y la clase PersonaFwk que pertenece a la Capa de Persistencia, ésta última la extiende redefiniendo sus getters para utilizarcarga tardía (Lazy Load), y redefiniendo sus setters para marcarse como modificados (Unit Of Work), agregando atributos para manejo de identidad (Identity Field) y para manejo de concurrencia (Optimistic Lock). Las clases DomainObject y la interface IDomainObject también son parte de la Capa de Persistencia. framework.iService Contiene las interfaces expuestas por la capa de servicio. Las interfaces de servicio básicas, es decir las que permiten el manejo básico como abms, son generadas por el generador.



cd Figura 55

personas::PersonaDTO

+ getNombre() : String+ setNombre(String) : void+ getDomicil ioId() : String+ setDomicil ioId(String) : void+ getDomicil ioDesc() : String+ setDomicil ioDesc(String) : void+ PersonaDTO()+ toString() : String

«interface»personas::IPersonaService

+ searchPersona(String, String) : Collection+ addPersona(PersonaDTO) : PersonaDTO+ searchPersona(PersonaDTO) : PersonaDTO+ deletePersona(PersonaDTO) : void+ modifyPersona(PersonaDTO) : PersonaDTO+ toPersonaDTO(Persona) : PersonaDTO+ toPersonaDTO(Collection) : Collection

Remote«interface»

iservice::IBaseService

dtoEntities::CustomData

+ getId() : String+ setId(String) : void+ getFwk_Version() : String+ setFwk_Version(String) : void+ getToString() : String+ setToString(String) : void+ CustomData()

- _Nombre: String- _DomicilioId: String- _DomicilioDesc: String

- id: String- fwk_version: String- toString: String = ""

Figura 55 En la Figura 55 se muestra la interfase de servicio para la clase Persona Aquí también se recomienda agregar las interfaces de servicio que se adicionan para exponer funcionalidades a la capa de presentación. framework.iService.dtoEntities Contiene a los Data Transfer Object que utiliza la capa de servicio. Son las clases DTO que son utilizadas como parámetros en los métodos de servicio, son generados por el generador. En la Figura 55 se muestra las clases DTO para la clase Persona Aquí se recomienda agregar las clases DTO que se adicionan. framework.persistence.caseStudy Contiene las clases especializadas para el caso de estudio de manejo de la persistencia. Las clases que especializan a los Mappers genéricos del framework (paquete framework.persistence.fwk) se ubican aquí y son generados por el generador.



cd Figura 56

personas::PersonaMapper

+ PersonaMapper()# getMappedClassName() : String# getMappedBaseClassName() : String# CreateDomainObject() : IDomainObject+ Load(IDomainObject) : void+ Load(Collection) : void+ LoadCollections(IDomainObject) : void# Save(IDomainObject) : void+ Delete(IDomainObject) : void

fwk::Mapper

# getMappedClassName() : String# getMappedBaseClassName() : String+ Mapper()# CreateDomainObject() : IDomainObject# CreateDomainObject(Collection) : Collection# AbstractFind(IKey) : IDomainObject- setIsPersistent(Collection) : void# ManageLoad(IKey) : Collection# LoadDOProperties(IDomainObject, Map) : IDomainObject# FindRow(IKey, String) : Map- explodeKeys(IKey, String) : String# FindRows(IKey, String) : ArrayList- getSqlFinder(String, String) : String- getSqlQuery(String, String, String) : String- removeLastFindersFields(String, int) : String- fil lKeys(AbstractCollection) : IKey[]- fil lKeys(AbstractCollection, int) : IKey[]# Find(String, String, String, String, int, int) : Collection+ Find(IKey) : IDomainObject+ FindAll(String, String, String) : Collection+ FindAll(String, String, String, int, int) : Collection+ Load(IDomainObject) : void+ Load(Collection) : void# Save(IDomainObject) : void+ Insert(IDomainObject) : void+ Update(IDomainObject) : void+ Delete(IDomainObject) : void# throwConcurrencyException(IDomainObject) : void+ Find(String, String) : Object+ nextKey() : IKey+ nextKey(String) : IKey+ LoadCollections(IDomainObject) : void+ getType(String, String) : String+ getTableNameFor(String) : String

Figura 56

En la Figura 56 se muestra el Mapper para la clase Persona. framework.persistence.fwk Contiene las clases genéricas del framework de manejo de la persistencia. Aquí se encuentran las clases del framework que realizan el manejo genérico de la persistencia. En la Figura 57 se muestran las clases de este paquete.



cd Figura 57

fwk::Context

fwk::DomainObject

Collectionfwk::DomainObjectCollection

Collectionfwk::DomainObjectCollectionRelation

Iteratorfwk::DomainObjectCollectionIterator

fwk::IdentityMap

«interface»fwk::IDomainObject

«interface»fwk::IFinder

«interface»fwk::IKeyGenerator

fwk::Key fwk::KeyGenerator

fwk::Mapper

fwk::PersistenceBroker

fwk::Registry

fwk::UnitOfWork

#domainObjectOfRelation

#mapper

-keyGenerator

-registry

-context

-identityMap

Figura 57

framework.presentation.fwk Aquí se encuentran las clases del framework que resuelven la problemática del manejo de la capa de presentación. Las mismas se muestran en la Figura 58.



cd fwk

HttpServletActionServlet

# forward(String, HttpServletRequest, HttpServletResponse) : void

EntityController

+ EntityController()+ doGet(HttpServletRequest, HttpServletResponse) : void+ doPost(HttpServletRequest, HttpServletResponse) : void

Inv oker

- getActionName(String) : String+ invoke(String) : String+ getInstance(String, Map) : Object- getPropertiesMap(Collection) : Map+ doGet(HttpServletRequest, HttpServletResponse) : void+ doPost(HttpServletRequest, HttpServletResponse) : void- processRequest(HttpServletRequest, HttpServletResponse, String) : void- isBusinessLogicException(java.lang.reflect.InvocationTargetException) : boolean+ main(String) : void

PageController

+ PageController()+ doGet(HttpServletRequest, HttpServletResponse) : void+ doPost(HttpServletRequest, HttpServletResponse) : void

- MODULE_PAGE: String = "xmls/modules.xml"- MODULE_PAGE: String = "xmls/modules.xml"- CUSTOM_MODULE_PAGE: String = "xmls/modules.c...

- servicesMap: HashMap = new HashMap()- serviceFactory: ServiceFactory = null

- name: String- className: String- isRemote: boolean- namingLookup: String

Figura 58 framework.remoting.client Aquí se encuentran las clases del framework que manejan el mecanismo de remoting desde el punto de vista del cliente. Las mismas se muestran en la Figura 59.

cd client

Serv iceFactory

+ getInstance() : ServiceFactory- ServiceFactory()+ getService(String) : Object- getServiceInfo(String) : Service

Serv ice

+ getName() : String+ setName(String) : void+ getClassName() : String+ setClassName(String) : void+ isRemote() : boolean+ setIsRemote(boolean) : void+ getNamingLookup() : String+ setNamingLookup(String) : void+ Service()

«xml»Serv ices

-serviceFactory

Figura 59

framework.remoting.server Aquí se encuentran las clases del framework que manejan el mecanismo de remoting desde el punto de vista del servidor. Las mismas se muestran en la Figura 60.



cd serv er

Serv icePublisher

+ ServicePublisher()- runServices() : void- publishServices(Collection) : void+ main(String) : void

«xml»Serv ices

Figura 60

framework.service.fwk Contiene las clases de servicio básicas, es decir las que permiten el manejo básico como abms, son generadas por el generador. Aquí también se recomienda agregar las calses de servicio que se adicionan para exponer funcionalidades a la capa de presentación. Puede verse un ejemplo en la Figura 61.

cd Figura 60

UnicastRemoteObjectserv ice::

BaseServ ice

+ BaseService()

personas::PersonaServ ice

+ PersonaService()+ searchPersona(String, String) : Collection+ addPersona(PersonaDTO) : PersonaDTO+ searchPersona(PersonaDTO) : PersonaDTO+ deletePersona(PersonaDTO) : void+ modifyPersona(PersonaDTO) : PersonaDTO+ toPersonaDTO(Persona) : PersonaDTO+ toPersonaDTO(Collection) : Collection

- broker: IPersistenceBroker

Figura 61 framework.utils.caseStudy Aquí se encuentran clases útiles para el desarrollo de la resolución del caso de estudio. Contiene clases como Helpers, el broker de persistencia, etc. framework.utils.exceptions Aquí se encuentran clases para el manejo de excepciones. framework.utils.helpers Aquí se encuentran clases con utilidades genéricas que utiliza el framework.



framework.utils.log Aquí se encuentran clases de manejo de log que utiliza el framework. framework.utils.persistence Aquí se encuentran clases e interfaces de manejo de medios persistencia que utiliza el framework, tales como para un motor de base de datos, etc. En la Figura 62 se muestran las clases del paquete framework.utils

cd utils

caseStudy


exceptions


helpers


log


persistence

+ StorageMediumException+ IReaderStorageMedium+ IStorageMedium+ dbdb


(from persistence)

Figura 62

Relaciones Entre Todos los Patrones Utilizados. La Figura 62b muestra las relaciones entre los patrones como fueron utilizados en el presente trabajo.



Figura 62b



Generador del Código para el Framework Arquitectura Las clases que extienden al framewok desarrollado, se generan a partir del generador que se describe a continuación. De la arquitectura propuesta en la sección anterior, vemos por ejemplo que las clases genéricas del paquete persistence.fwk son provistas por el framework y éstas dan la funcionalidad básica de la capa de persistencia. A partir de éstas y de las clases del modelo de dominio, se deben obtener las clases que extienden a las genéricas especializándolas. Por ejemplo la clases de mapeo objeto relacional, se basan en la clase Mapper, ésta posee la funcionalidad común para todos los objetos de dominio, pero no sabe los atributos extra que presenta cada clase de dominio, por lo que es necesario extender a la clase Mapper para cada clase de dominio, redefiniendo y definiendo ciertos métodos abstractos para agregar dicho comportamiento faltante y específico de la clase de dominio. En la Figura 63 se muestra un ejemplo.

cd Data Model

Mapper

# Save(IDomainObject) : void

PersonaMapper

# Save(IDomainObject) : void

Figura 63

En la presente propuesta se desarrolló un generador que en forma autónoma realiza esta generación. (Ver el tema analizado anteriormente de Generador vs Reflection) Esto es posible gracias a la arquitectura analizada en la sección anterior, donde se mostró la independencia entre el modelo de dominio y el framework que se describe. El generador se alimenta de la información del modelo a persistir a partir de un conjunto de archivos xml. Estos archivos contienen información de las propiedades y métodos de las clases. Existe un archivo por clase de dominio



a persistir. En la figura que sigue este archivo se muestra como ClassData.xml. Estos archivos xml, pueden ser construidos a mano o ser exportados desde una herramienta de modelado. En éste trabajo se desarrolló otro generador muy sencillo para este fin, que genera dichos archivos xml a partir de las clases compiladas del dominio. Una vez que se poseen dichos archivos xml (classData), se procede a generar el código para el framework. El ClassData.xml tiene la estrucutra descripta en la Figura 64 <?xml version='1.0' encoding='ISO-8859-1' ?> <class package="pequi.ot" name="OrdenDeTrabajo" type="concret" baseClassName="java.lang.Object"> <attributes> <attribute name="Color" relation="primitive" type="java.lang.String" visibilityLevel="public" isStatic="no" isFinal="no" isProperty="yes" initialValue="" exceptions="" /> <attribute name="Cliente" relation="agregation" isMandatory="no" type="pequi.clientes.Cliente" visibilityLevel="public" isStatic="no" isFinal="no" isProperty="yes" initialValue="" exceptions="" /> <attribute name="FechaEntrada" relation="primitive" type="java.util.Date" visibilityLevel="public" isStatic="no" isFinal="no" isProperty="yes" initialValue="" exceptions="" /> <attribute name="Pliegos" relation="collection" pageSize="50" manyToMany="true" type="pequi.ot.Pliegos" visibilityLevel="public" isStatic="no" isFinal="no" isProperty="yes" initialValue="" exceptions="" /> </attributes> <dependencies></dependencies> <implements></implements> </class>

Figura 64

Es decir el mismo posee la descripción de nombre, paquete, atributos, dependencias, clase base e implementaciones de una clase de dominio. El generador desarrollado es capaz de incorporar nuevos templates para generar código. Inicialmente hay un template para cada clase o capa necesaria en el framework pero el diseño actual permite la extensión del framework y su generador a través de la configuración del mismo, dándo la posibilidad de agregar nuevos templates a partir de nuevas clases que implementen la interfaz IGenerator y su inclusión en la configuración del mismo. Se muestra el diagrama de clases en la Figura 65.



Figura 65

Esto se configura, en el archivo GeneradorConf.xml donde se listan los templates existentes. Se pueden ejecutar todos juntos o generar código para una clase o capa en particular. En la Figura 66 se muestra un segmento de GeneratorConf.xml que configura la interfaz visual del generador de código, indicando que generadores posee, que motores soporta, etc. <codegenerator> <configuration> <sqlSupport> <motor name="JET" displayName="Jet / MS Access" default="true" passRequired="false"/> <motor name="MSSQL" displayName="MS SQL Server" default="false" passRequired="true"/> <motor name="MYSQL" displayName="MYSQL" default="false" passRequired="true"/> </sqlSupport> <outputLanguage> <language name="java" displayName="Java" default="true" /> <language name="csharp" displayName="C#" default="false" /> </outputLanguage> <classDataGenerator> <option displayName="ClassData Generator" tooltip="Generador de metadata de las clases"> <generator class="codeGenerator.generator.ClassDataGenerator" /> </option> </classDataGenerator> <generators> <option name="Persistence Layer" displayName="Persistence Layer" tooltip="Generador de clases de manejo de persistencia para el framework"> <generator class="codeGenerator.generators.ConcreteMapperGenerator" /> <generator class="codeGenerator.generators.ConcreteDomainObjectGenerator" /> <generator class="codeGenerator.generators.RegistryGenerator" /> </option> <option name="DataBaseGenerator"



displayName="DataBase Generator" tooltip="Generador de scripts de base de datos para el framework"> <generator class="codeGenerator.generators.DataBaseGenerator" /> </option> </generators> </configuration> </codegenerator>

Figura 66 A partir de la interfaz del Generador View que se muestra en la Figura 67, se entran los datos de : a) directorio de los archivos xml, b) el directorio donde se hará el despliegue, c) el directorio del código genérico del framework, d) motor de base de datos, e) lenguaje de la implementación, f) lista de clases a generar y g) datos de conección a la base de datos.

Figura 67



Tipos de Generadores Provistos Se listan los distintos tipos de componentes generados y agrupados según las capas a que pertenecen. Capa de persistencia

ConcreteMapperGenerator, genera cada uno de los Mapper concretos que extienden a AbstractMapper, para cada clase del dominio.

ConcreteDomainObjectGenerator, genera cada una de las clases del dominio adaptada al framework, como se describió en una sección anterior.

RegistryGenerator, genera archivos xml donde se listan los Mappers a ser usados por la clase genérica registry del framework.

Capa de base de datos

DataBaseGenerator, genera los scripts SQL para la creación de las tablas en la base de datos.

DataBaseXmlGenerator, genera un archivo xml donde se guarda el string de conexión que utilizará el framework.

Capa de Servicio

ConcreteIServicelayerGenerator, genera cada unas de las interfaces para los servicios básicos (ABM) para cada clase persistente del dominio.

ConcreteServicelayerGenerator, genera cada unas de las clases para los servicios básicos (ABM) para cada clase persistente del dominio.

ConcreteDTOGenerator, genera cada una de las clases de tipo DTO, utilizadas en la capa de servicio, por cada una de las clases de dominio.

FinderGenerator, genera un archivo xml con las consultas SQL a utilizar desde la capa de servicio.

ServiceXmlGenerator, genera un archivo xml con la lista de servicios disponible desde la capa de presentación.



Capa de Presentación Los siguientes generadores proveen de archivos xml para la capa de presentación.

XMLActiveFrontActionGenerator, genera una lista de archivos javascript con las funciones necesarias para la invocación a través del mecanismo Ajax o ActiveFront utilizado desde la capa de presentación.

XMLEntityGenerator, genera un archivo xml con la descripción de las entidades DTO expuestas por los métodos de la capa de servicios para generar automaticamente las pantallas de ABM desde la capa de presentación a través de EntityController.

XMLEntityManagerGenerator, genera un archivo xml con la lista de los archivos generados por el XMLEntityGenerator.

XMLModulesGenerator, genera un archivo xml con la lista de modulos definidos a usar por PageController desde la capa de presentación.

XMLRegistryBDatosGenerator, genera un archivo xml con la información relacionada con la Base de Datos requerida por la Registry.

XMLRegistryMapperGenerator, genera un archivo xml con la información para la obtención de los Mappers requerida por la Registry.

XMLServiceApplicationGenerator, genera un archivo xml con la información de los servicios (locales, remotos, ubicación de los mismos) requerida por la ServiceFactory del lado del servidor de aplicaciones.

XMLServicePresentationGenerator, genera un archivo xml con la información de los servicios (locales, remotos, ubicación de los mismos) requerida por la ServiceFactory del lado del serivodr de presentación.

XMLServletActionGenerator, genera un archivo xml con la lista de acciones disponibles a invocar desde la capa de presentación.



Caso de Estudio Descripción del dominio Una empresa gráfica administra sus trabajos en Ordenes de Trabajo. Cada Orden de trabajo esta compuesta por Procesos, por ejemplo la Orden de Trabajo con nombre “Revista Noticiero”, esta compuesta por 2 procesos, uno de “Filmación” y otro de “Ploteo”. Todos los procesos deben realizarse para poder terminar la orden de trabajo. Cada proceso esta asignado a un Turno de trabajo. Los turnos de trabajo son tres, “mañana”, “tarde” y “noche”. Cada Turno esta compuesto por empleados de la empresa. Cada proceso puede tener una nota asociada, un Solicitante, y posee un conjunto de componentes, los componentes del trabajo, por ejemplo, la “tapa”, el “interior”, sus “pliegos”, etc Cada proceso tiene un “estado”, cuando todos los procesos de una orden están terminados, entonces la orden de trabajo estará terminada. Cada proceso tiene un tiempo asignado para su resolución. La orden de trabajo es para un cliente dado y tiene asociados un conjunto de materiales. Se almacenan la información asociada a los clientes y empleados, como domicilio, cuit, y teléfono. Modelo del Dominio El diagrama de clases del modelo del dominio puede verse en la Figura 68 3 3 3.51 - Unregistered TRIAL Version

.51 - Unregistered TRIAL Version

.51 - Unregistered TRIAL V

A 3.51 - Unregistered TRIAL Version

EA 3.51 - Unregistered TRIAL Version

EA 3.51 - Unregistered TRIAL V



















A 3.51 - Unregistered TRIAL Versio



A 3.51 - Unregistered TRIAL Vers

EA 3.51 - Unregistered TRIAL Ver


A 3.51 - Unregistered TR

EA 3.51 - Unregistered TR

EA 3.51 - Unregistered TR

A 3.51 - Unreg

EA 3.51 - Unreg

EA 3.51 - UnregA 3.51

A 3.5

EA 3.5

OrdenDeTrabajo Proceso

Material Componente

Solicitante

Turno

Nota

Cliente

EstadoDeOrden

EstadoDeProceso

«interface»IPersona

Empleado

Domicilio Pais

Prov incia

Partido

Localidad

0..* 1

1

0..1

1..*

tiene

0..1

asignado a

0..1

0..1

1..*

1

1

111 0..*

0..*

0..*

n EFigura 68



Transición del análisis al diseño El objetivo es describir el proceso que conduce la transición del análisis al diseño de arquitectura de un sistema de tipo Enterprise. Para esto comenzamos actualizando algunas definiciones del concepto de arquitectura de sistemas. Luego a partir de un modelo de casos de uso de sistema comenzamos la descripción del proceso mencionado.

Diagrama de Casos de Uso de sistema En la Figura 68 se muestra un diagrama de casos de uso que modelan parcialmente la funcionalidad de la aplicación descripta. Estos casos de uso fueron construídos en base a el Modelo de Dominio y un Modelo del Negocio descripto. Estos casos de uso modelan los requerimientos funcionales. Los mismos estarán acompañados por un listado de requerimientos no funcionales. Es interesante notar que la arquitectura en estos casos está dada en parte. Sin embargo, y según fue mencionado en los objetivos, hay que realizar la transición de los productos del análisis a esta arquitectura; es decir, definir cómo este análisis es volcado sobre las distintas partes de la arquitectura de N Capas.

Figura 69



Análisis de los Casos de Uso, Diagramas de Robustez Análisis de los casos de uso basándose en su descomposición en clases de análisis. Cada uno de los casos de uso se descompone en sus aspectos vista (view), datos (modelo) y dinámica (controller). Se analizan así la colaboración entre estos elementos y aparecen nuevos elementos representando conceptos como las reglas del negocio. Algunos de los elementos de tipo “datos” se corresponden con entidades del modelo del dominio. Esto se muestra en la Figura 70. Este modelo de robustez muestra además las relaciones entre los distintos casos de uso. Cuando en un paso posterior los casos de uso sean empaquetados, estas relaciones constituirán las dependencias entre los paquetes lógicos resultantes y sus interfaces.

Figura 70



Paquetes Lógicos del Diseño Conceptual Los casos de uso son empaquetados siguiendo criterios de cohesión derivados del negocio. Dicho empaquetamiento es una vista estática y constituye la primera y más prematura arquitectura que tiene en cuenta la funcionalidad pedida al sistema a desarrollar. Debido a que estos sistemas son complejos en su mayoría, podrán y deberán ser descompuestos en paquetes que modularmente contengan aspectos de distintos niveles de abstracción. Es decir buscaremos estratificarlo en capas (layer), donde cada capa prestará servicios a la capa inmediatamente superior. Entre los criterios de buen diseño que trataremos de seguir estarán la no inclusión de dependencias circulares, la dependencia en la dirección de la mayor generalidad, el re uso, etc. Las dependencias entre paquetes y las interfaces de los mismos son definidas en base al análisis de robustez.

Figura 71

Diagrama de una arquitectura de tipo Enterprise En la Figura 72 se muestra mediante la utilización de números asociados a la Figura 70, la transición del producto del relevamiento de requerimientos y su análisis sobre la estructura en capas utilizada en el framework. Se mapean para cada paquete los distintos objetos a cada una de las capas. Para cada capa (tier) se busca profundizar la estructura de capas (layer) con paquetes físicos. Aparecen restricciones impuestas por la tecnología que condicionan algunos de los requerimientos funcionales.



Figura 72



Uso del Framework Luego del diseño se desarrollaron las clases del dominio. Obteniendo los siguientes paquetes: pequi.ot para las clases relacionadas a manejo de las ordenes de trabajo pequi.personas clases relacionadas a manejo de personas pequi.clientes clases relacionadas a manejo de clientes Luego ejecuntado el generador de archivos xml descriptores, y luego el generador de código, se obtienen las clases que especializan a las clases bases del framework. Paquetes generados con detalle de clase generada asociada a la clase Cliente:

• Clases Domain Adapter del dominio Paquetes:

framework.domainModel.fwk.pequi.ot framework.domainModel.fwk.pequi.personas framework.domainModel.fwk.pequi.clientes

Una clase como ejemplo: ClienteFwk.class

• Clases Data Transfer Object

Paquetes: framework.iservice.dtoEntities.pequi.ot framework.iservice.dtoEntities.pequi.personas framework.iservice.dtoEntities.pequi.clientes

Una clase como ejemplo: ClienteDTO.class

• Interfaces de Servicio

Paquetes: framework.iservice.pequi.ot framework.iservice.pequi.personas framework.iservice.pequi.clientes

Una clase como ejemplo: IClienteService.class

• Clases de manejo de Persistencia

Paquetes: framework.persistence.casestudy.pequi.ot framework.persistence.casestudy.pequi.personas framework.persistence.casestudy.pequi.clientes

Una clase como ejemplo: ClienteMapper.class

• Clases de Servicio

Paquetes: framework.service.pequi.ot



framework.service.pequi.personas framework.service.pequi.clientes

Una clase como ejemplo: ClienteService.class

Archivos y Xml Descriptores generados ejemplificados para la clase Cliente: También se obtuvieron archivos xml con información necesaria por las clases del framework.

• Capa Presentación Archivos:

entityManager / pequi.clientes.Cliente.pageData.xml modules.xml servlet-actions.xml AFActions / pequi_clientes_Cliente.js

• Capa de Persistencia

Archivos: Registry / BDatos.xml Registry / Mappers.xml Finders / Finders.xml

• Capa de Servicio

Archivos: Service / PresentationServices.xml Service / ApplicationServices.xml

Scripts SQL generados: También se obtuvieron los archivos con los scripts utilizados para la creación de la base de datos.

• Creación de tablas de entidades Un archivos de ejemplo:

TABLE_part_0_pequi_clientes_Cliente.sql

• Creación de Indices, Foreign Keys, Primary Keys Un archivos de ejemplo:

FK_pequi_ot_OrdenDeTrabajo.sql

• Creación de tablas de relaciones Un archivos de ejemplo:

COLLECTION_part_0_pequi_ot_OrdenDeTrabajo.sql Pantallas obtenidas



A continuación se muestran las pantallas de administración y creación de clientes generada por la capa de presentación mediante los archivos xml mencionados anteriormente.

• Manager / Selector

Figura 73

• Editor / Nuevo

Figura 74

Resultados obtenidos al aplicar el framework



El generador dejó todos estos paquetes y archivos empaquetados en un archivo .war, llamado pequi.war, el cual puede ser directamente desplegado en un contenedor web, como por ejemplo tomcat, brindando así la funcionalidad básica para administrar la entidades de dominio, de aquí en mas los pasos serían customizar los archivos descriptores de presentación para brindar una interfaz mas amigable y desarrollar los servicios faltantes asociados a los casos de uso apoyandose en el framework y la aplicación obtenida. Es decir este mecanismo nos brinda un start up veloz, resolviendo las problemáticas típicas en este tipo de aplicaciones.



Trabajo Futuro Como trabajo futuro se listan una serie de items con los cuales sería deseable contar y se podrán desarrollar fuera del alcance del presente trabajo. Información sobre el avance del mismo puede obtenerse en [WEB-Tesis] Agregar otros protocolos de comunicación entre capas

Se cuenta con la abstracción necesaria para independizarse del protocolo de comunicación utilizado, pero hace falta agregar mas protocolos, principalmente para manejo de web services, para brindar mas opciones de configuración que permitan al desarrollador optimizar la aplicación lo mas acorde a sus necesidades. Agregar otras formas de mapeo de herencia de objetos a relacional

(elección de patrones de mapeo)

Se desea agregar la implementación de otros patrones de diseño vistos y analizados para mapear herencias dando así mas flexibilidad de elección buscando siempre la mejor solución particular a cada caso concreto.

Clustering

Administración de pool conexiones

Agregar un manejo de pool de conecciones agilizando el uso de las mismas para ganar en performance. Agregar uso de drivers de motores especificos para la conección. Roll back de transacciones

Agregar un manejo de rollback de transacciones ya confirmadas, dando la posibilidad de hacer un “deshacer” de la última acción si es que no hubo otras que la afectaran

Mejorar administración de colecciones en el dominio

Mejorar el uso de collecciones para objetos del dominio, permitiendo a los wrappers de las mismas administrar en forma mas eficiente los lazy loads que utilizan para optimizar la performance de acuerdo a cada caso en particular



Integración con herramientas estándar (IDEs, Eclipse, EA, etc)

Integrar con herramientas de diseño a través de plugins, permitiendo así generar desde ellas los archivos descriptores que utiliza el generador de código evitando el uso de la herramienta presentada en el presente trabajo, agilizando y facilitando el refactoring mediante su uso. Integrar con ambientes de desarrollos o IDEs. Para permitir generar código de distintas capas directamente desde plugins instalados en el mismo ambiente de desarrollo. Mejorar la dinámica de generación ( refactoring del dominio y

adaptación automática de la base)

Darle mas funcionalidades a la dinámica de generación permitiendo actualizar cambios en la base de datos sin perder los datos contenidos, es decir que al refactorizar por ejemplo objetos de dominio, se actualizen su representación en la base de datos sin perder los datos contenidos en la misma.

Auditoría

Agregar manejo de auditoría a la capa de servicio, permitiendo así tener una aplicación que visualice que hizó y esta haciendo cierto usuario, pudiendo directamente cerrarle la sessión o modificarle permisos de control de acceso es necesario. Generación automática de otras interfaces de presentación

Agregar generación de código para otras interfaces de presentación tales como smart client basados en swing, u otros tipos de scripting.

Optimización de interacción con el motor de base de datos

Utilizar consultas batch para enviar todas las consultas que tiene la Unit Of Work al realizar el commit para evitar el round trip con el motor de base de datos. Mejorar la carga de datos en las collecciones lazy load de las relaciones.



Conclusiones La separación de una aplicación en capas permite separar las problemáticas y atacar los problemas de cada una en forma más independiente del resto de las capas, permitiendo así trabajar y avanzar con el desarrollo en forma paralela una vez que se especificaron las interfaces entre capas, permitiendo tener roles especializados en los temas a atacar en cada capa. El uso de patrones ya analizados y estudiados permite hablar con mas claridad y mas alto nivel a los participantes del desarrollo, permitiendo no reinventar la rueda y tener alternativas útiles a problemas comunes. La utilización de frameworks de trabajo, que son acordes a la resolución de la problemática a resolver, facilitan el desarrollo de la aplicación ya que imponen un órden y una estructura ya pensada para un tipo de arquitectura dada. Por lo que problemas comunes y genéricos ya están resueltos y optimizados por el framework y se permite hacer uso de ellos y especializarlos extendiendo al mismo. Esto brinda un rápido start up de la aplicación. Lo importante es saber y distinguir claramente si un framework, es acorde a la problemática a resolver. Un problema típico es el uso un framework pensado para cierta arquitectura, cuando ésta no es la adecuada para nuestro problema, ya que dicho framework, fue pensado y optimizado para otra problemática. Por esto es muy importante analizar la elección del framework adecuado. Mediante el uso de un framework y en conjunto con metodologías y procesos de desarrollo adecuados, se agiliza mucho el proceso de desarrollo de una aplicación, y es mas fácil obtener un resultado exitoso. La solución obtenida a la restricción impuesta de no modificar el modelo de dominio permitió que un modelo de dominio estudiado e implementado, pueda ser facilmente integrado al framework para lograr así una aplicación para dicho modelo que puede ser desplegada en un ambiente distribuido, resolviendo la problemática que ataca el framework. Se logró separar toda la problemática relacionada a la resolución del modelo de negocio, de los problemas inherentes a la arquitectura elegida de acuerdo a las necesidades.



Apéndice Patrones Patrones de Arquitectura de Aplicaciones de tipo Enterprise Patrones que resuelven distintos problemas asociados a las capa de una Aplicación de tipo Enterprise. [Martin Fowler eaaCatalog] Los mismos fueron basados en el catálogo expuespo por Martin Fowler desde su site en internet. http://www.martinfowler.com/eaaCatalog/

Identity Field Guarda un campo ID de la base de datos en un objeto para mantener la identidad entre un objeto en memoria y una fila de una tabla en una base de datos.

Las bases de datos relacionales, distinguen una fila de otra utilizando una key Los objetos en memoria no necesitan de esta key ya que el runtime mantiene la correcta identificación de los mismos en memoria. Al momento de guardar en la base de datos, es necesario haber vinculado un objeto en memoria con una fila en la base de datos para poder hacerlo. Identity Field agrega la primary key de la fila de la base de datos como un atributo en el objeto.

Foreign Key Mapping Mantiene una asociación entre objetos para referencias de foreign key en tablas de la base de datos.



Los objetos en memoria se referencias con otros directamente por sus referencias en memoria. Para persistir estas relaciones en la base de datos, es necesario guardar estas referencias. Por lo que Foreign Key Mapping vincula una referencia a un objeto, a un foreign key en la base de datos.

Association Table Mapping Guarda una asociación entre objetos como una tabla con las foreign keys a las tablas que esos objetos estan asociados.

Los objetos pueden manejar asociaciones multiples a través del uso de una collección. En las bases de datos relacionales, en las relaciones uno a muchos, se puede usar una foreign key para persistir la relación, pero en las relaciones muchos a muchos es necesario agregar una nueva tabla que asocia las dos keys de los objetos relacionados

Domain Model Un modelo de objetos del dominio que incorpora comportamiento y datos.



Cuando la lógica de negocio es muy compleja, y depende de muchos factores, los objetos son los indicados para modelarlo. Un Modelo de Dominio crea una red de objetos interconectados, donde cada objeto representa algo significativo e individual.

Transaction Script Organiza la lógica de negocio a través de procedimientos dónde cada uno maneja un simple request (pedido) desde la capa de presentación.

La mayoría de las aplicaciones puede pensarse como una serie de transacciones. Una transacción puede ver cierta información organizada de una manera particular, otra puede hacer cambios sobre ésta. Cada interacción entre un cliente y un servidor contiene cierta lógica, en algunos casos puede ser simple como visualizar información y en otros puede incorporar una cierta cantidad de pasos de validaciones y cálculos. Un Transaction Script organiza toda esa lógica como un solo porcedimiento, conectándose directamente a la base de datos, o a través de un delgado wrapper. Cada transacción tiene su propio Transaction Script, aunque algunas tareas comunes pueden volcarse en subprocedimientos.

Table Module Una única instancia que maneja la lógica para todas las filas de una tabla o vista en la base de datos.

Table Module organiza la lógica del dominio como una clase por tabla en la base de datos, y una solo instancia de una clase contiene varios procedimientos que interactúan con la base. Se posee un solo objeto para administrar todos filas de la base de datos



Service Layer Define con una capa de servicios un límite de la aplicación que expone un conjunto de operaciones.

Una Service Layer encapsula toda la lógica de negocio, control de transacciones y coordinación de la respuesta en la implementación de las operación que expone.

Table Data Gateway Un objeto que actúa como Gateway a la base de datos. Una instancia que maneja todas las filas en una tabla.

Table Data Gateway contiene todo el SQL para acceder a una sola tabla o vista Otro código invoca sus métodos para interactuar con las base de datos.



Row Data Gateway Un objeto que actúa como Gateway a un solo registro en la base de datos. Hay una instancia por registro o fila en la tabla.

Row Data Gateway permite tener objetos que se parecen a los registros en la base de datos, pero que pueden ser accedidos con métodos del lenguaje. Todos los detalles de acceso a la base estan ocultos detrás su interfaz

Active Record Un objeto que hace de wrapper a una fila de una tabla o vista de la base de datos encapsulando el acceso a los datos y agregando la logica del dominio a sus datos.

Un objeto que posee tanto datos como comportamiento y muchos de sus datos son persistentes y necesitan ser almacenados en una base de datos. Active Record pone la lógica de acceso a datos en el objeto de dominio, permitiendo que cada objeto de dominio sepa como cargarse y guardarse desde y hacia la base de datos.



Data Mapper Una capa de Mappers mueven los datos entre objetos y una base de datos mientras mantienen la independecia entre el objeto y su mapeo en la base.

Data Mapper es una capa de software que separa los obejtos en memoria de su representación en la base de datos. Su responsabilidad es transferir los datos entre los dos y asilarlos a uno del otro. Con Data Mapper los objetos en memoria no necesitan saber que existe una base de datos, ni saber de código SQL, ni como son persistidos.

Single Table Inheritance Representa una jerarquía de clases como una sola tabla que tiene las columnas necesarias para todos los campos de las clases de la jerarquía

Las bases de datos relacionales no soportan herencia. Single Table Inheritance, mapea todos los campos de todas las clases de la jerarquía a una sola tabla.

Class Table Inheritance Representa una jerarquía de clases con una tabla para cada clase.



Concrete Table Inheritance Representa una jerarquía de clases con una tabla para cada clase concreta de la jerarquía.



Inheritance Mappers Es una estructura para organizar el mapeo a la base de datos que maneja toda la jerarquía de herencia

Provee un mapeo para comportamiento abstracto y concreto que permite guardar y cargar entidades bases de la jerarquía como entidades derivadas. Esta estructura funciona para cualquier esquema de mapero de herencia.

Identity Map Se asegura que cada objeto sea cargado solo una vez manteniendo cada objeto cargado en un mapa. Cuando requieren un objeto mira en el mapa si ya lo tiene cargado.



Un Identity Map mantiene un registro de todos los objetos que fueron cargados de la base de datos dentro de una transacción de negocio. Cuando se desea un objeto, se verifica que no este ya en Identity Map para ver si ya fue cargado.

Unit of Work Mantiene una lista de los objetos afectados por una transacción de negocio y cordina la actualización de los cambios en la base de datos y resuelve los problemas de concurrrencia.

Unit of Work mantiene el seguimiento de todo lo que ocurren en una transacción de negocio que puede afectar a la base de datos. Cuando termina la transacción, se encarga de hacer todo lo necesario para impactar todos los cambios resultantes en la base de datos.

Lazy Load Un objeto que no contiene los datos necesarios, pero sabe como obtenerlos.



Lazy Load interrumpe por el momento el proceso de carga de objetos relacionados, dejando listo para cuando sus datos sean requeridos, el pueda cargarse automaticamente. De no ser necesario esos datos, no hubo que ir a buscarlos ahorrando el tiempo insumido en ello.

Layer Supertype Una clase que actúa como clase base de todas las clases en su capa. No es raro que todos los objetos en una capa tengan ciertos métodos que no es deseable que esten duplicados. Todo ese comportamiento puede ser desplazado para la Layer Supertype

Separated Interface Define una interfaz en un paquete separado de su implementación.



Se trata de reducir el acoplamiento entre partes del sistema. La forma es agrupar las clases en paquetes y controlar la dependencia entre ellos. Verificando que las clases de un paquete pueden depender de las del otro pero no a la inversa. Pero cuando no es posible, Separated Interface permite definir una interfaz en un paquete e implementarla en el otro. De esta manera los que necesitan esa dependencia usan la interfaz pero no les interesa donde esta implementada

Registry Un objeto conocido que otros objetos pueden utilizar para encontrar objetos y servicios comunes

Registry es en esencia un objeto global o al menos parece uno, (singleton) el cual es accedido directamente por otros objetos



Optimistic Offline Lock Previene conflictos de concurrencia en transacciones de negocio, detectando un conflicto y realizando un rollback de la transacción.

Pessimistic Offline Lock Previene conflictos de concurrencia en transacciones de negocio, permitiendo que solo una transacción de negocio acceda a los datos a la vez.

Active Front o Ajax Evita la recarga de las vistas cuando no es necesario cambiar la vista, sino que busca los datos y carga los mismos en la vista. Ver artículos referidos al tema [WEB-4]. on onAL Version

AL Version

tered TRIAL Version

tered TRIAL Version



Unregistered TRIAL Versi

EA 3.51 - Unregistered TRIAL Versi

EA 3.51

Unregistered TRI

EA 3.51 - Unregistered TRI

EA 3.51

Unregist

EA 3.51 - Unregis

EA 3.51 EA 3.51

EA 3.51

DATOSVista

tabla check

combo

Acción A Acción B

Serv idor

Control

Actualiza los datos

Esta implementación puede verse como una variante del patrón MVC aplicado a aplicaciones de tipo Web.

• Nombre: ActiveFront, Ajax, MVC • Contexto: Sistemas de dos o mas capas donde el cliente es un cliente

delgado web. El procesamiento de datos lo realiza el servidor en una capa de negocio o de servicio y el cliente solo visualiza y captura datos que envia al servidor para que procese. Se cuenta con la posibilidad de enriquecer un poco al cliente con el uso de scripting y el modelo de objetos del explorador.

• Problema: La recarga de una vista o página anteriormente cargada cuando lo único que se va a modificar entre request y request son solo datos. La vista sigue siendo la misma. Es decir se evita el rearmado de la vista con los nuevos datos y el viaje de la misma desde el servidor.

• Causas: La comunicación entre el cliente y el servidor es a través de requests. Y se deja que el servidor genere una nueva vista pero con los nuevos datos cargados para que el cliente los visualize, cuando en realidad la misma sigue igual, solo modifico sus datos.

• Solución: Separar los datos de la vista. Mediante el uso de un pequeño controlador / invoker del lado del cliente dentro de la vista, que administre los datos. Mediante el uso del modelo de objetos del explorador y scripting del lado del cliente se realiza la carga y manejo



de datos sobre la vista anteriormente solicitada sin necesidad de realizar un request cuando es posible con los datos actuales. Y al momento de necesitar una acción del servidor para obtener mas datos, se realiza la misma evitando la recarga de la vista que continua siendo la misma.

o Estrategias:

1) Ejemplo de combos relacionados, País, Provincias, Partidos y Localidades. La estrategia mas simple es que la primera vez que se solicita la vista, venga con ella toda la información posible, es decir de todos los países, provincias, partidos y localidades, inicialmente todos los combos vacíos con la opción de seleccione, a excepción de los países que no varían. Al seleccionar un país mediante el uso de scripting y el modelo de objetos del explorador se carga el siguiente combo relacionado, provincias, para que el usuario elija y así sucesivamente.

Ventajas:

1. Solución muy simple de implementar.

Desventajas:

1. Limitada a casos donde se conocen de antemano todos los datos posibles intervinientes.

2. Si los datos involucrados son muchos, la carga inicial de la vista se verá considerablemente afectada debido a que es mayor el tamaño de los datos que de la vista en sí, haciendo muy lenta su carga.

2) Listados de datos visualizados en una tabla, cuyo contenido es resultado de una búsqueda que realiza el servidor de acuerdo a filtros que le indica la vista. Esta estrategia se basa en tener un frame o iframe oculto que es encargado de realizar un request al servidor con los parámetros de filtro de la búsqueda, y una vez obtenida la respuesta “bindear” o enlazar los datos a la tabla de la vista. Esto se puede realizar mediante el uso de scripting, modelo de objetos del explorador y se puede facilitar mas aún si la respuesta del servidor es en formato xml, para que con scripting se realice el bindeo o enlace automático entre las tablas y sus datasources (xmls).

Ventajas:

1. Solución simple de implementar.



2. Permite obtener datos bajo demanda y luego visualizarlos sin recargar las vistas.

3. Las vistas no se ven afectadas en cuanto a tamaño y estas pueden ser cacheadas por el explorador ya que las mismas no expirarían continuamente ya que sus datos son manejados independientemente de la presentación.

4. Las vistas no son reescritas por el servidor por lo que separa mas la vista en si de los datos, permitiendo un mejor manejo por los diseñadores.

Desventajas:

1 Utiliza frames ocultos. 2 Utiliza mas scripting del lado del cliente.

3) Listados de datos visualizados en una tabla, cuyo contenido es resultado de una búsqueda que realiza el servidor de acuerdo a filtros que le indica la vista. Altas y bajas de entidades. Esta estrategia se basa en el uso de un componente llamado XML-HTTP que es capaz de realizar requests a un servidor enviando xml y recibiendo xml como respuesta.

Ventajas:

1. Una vez implementada esta estructura, facilita el uso de este patrón.

2. Permite obtener datos bajo demanda y luego visualizarlos sin recargar las vistas.

3. Las vistas no se ven afectadas en cuanto a tamaño y estas pueden ser cacheadas por el explorador ya que las mismas no expirarían continuamente ya que sus datos son manejados independientemente de la presentación.

4. Las vistas no son reescritas por el servidor por lo que separa mas la vista en si de los datos, permitiendo un mejor manejo por los diseñadores.

5. Tiene un manejo desde el lado del cliente, similar al de un cliente rico, utilizando un esquema similar al llamado de métodos de objetos.

6. Permite realizar estas acciones sincrónica o asincrónicamente, dando una mejor interacción con el usuario.

7. Esta estrategia puede utilizar un pequeño framework con funciones de scripting del lado del cliente y un manejo del lado del servidor. La idea es manejar desde scripting funciones similares a los métodos de la clase a invocar (preferentemente asociado a una capa de servicio). Desde el cliente el framework arma



un xml con un formato específico que indicará una acción, (previamente definida en el servidor, esta mapeará a un método de una clase) y los parámetros para invocarlo. Y esperara la respuesta en un xml. Con esta respuesta realizará el binding a los objetos (tablas, combos, etc) del explorador. El servidor valida que la acción sea una acción válida, controla que los parámetros recibidos sean los que posee dicho método y mediante reflection instancia y ejecuta dicho método obteniendo el resultado deseado, el cual es serializado a xml y devuelto en el response. O directamente invoca al servidor y este retorna en su response un xml con la información en el formato definido

Desventajas:

1. Construcción de la base de esta estructura o framework.

2. Utiliza mas scripting del lado del cliente.

• Consecuencias: El uso de scripting del lado del cliente puede traer inconvenientes en la compatibilidad entre distintos exploradores. Mayor conocimiento de scripting para los desarrolladores.

• Patrones Relacionados: MVC, Ajax



Referencias - Bibliografía

[Aplert, 1998] Sherman R. Alpert, Kyle Brown, Bobby Woolf, The Design Patterns Smalltalk Companion. Addison Wesley, 1998. [Copplien 1995] James Copplien, Douglas C. Schmidt, J. Vlissides, N. Kerth, Robert Martin, Dirk Riehle, Frank Buschmann, Neil Harrison, Brian Foote, and Hans Rohnert, Pattern Language of Program Design, 1, 2, 3, 4, Addison Wesley, 1995. [Fayad, 1999 ] Mohamed E. Fayad (Editor), Douglas C. Schmidt (Editor), Ralph Johnson, Implementing Application Frameworks : Object-Oriented Frameworks at Work, John Wiley. 1999 [Gamma et al, 1995] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. [Hofmeister, 1999] Christine Hofmeister, Robert Nord, Dilip Soni, Christine Hoffmeister, Applied Software Architecture , Addison Wesley, 1999. [JavaWorld - 1] JavaWorld http://www.javaworld.com/javaworld/jw-11-2001/jw-1102-codegen_p.html By Michael J. Rettig with Martin Fowler

[Marinescu, 2002] Floyd Marinescu. EJB Design Patterns, Advanced patterns, processes and idioms. John Wiley. 2002. [Martin Fowler, 2003] Martin Fowler. Patterns of Enterprise Application Architecture. Adison Wesley, 2003. [Martin Fowler eaaCatalog] Sitio de Martin Fowler http://www.martinfowler.com/eaaCatalog/ [Rod Johnson, 2003] Rod Johnson, Expert One-on-One J2EE Desgin and Development. Wrox Press, 2003. [Schmidt, 2000] Douglas Schmidt, Michael Stal, Hans Rohnet, Frank Buschmann, Patern Oriented Software Arquitecture vol 2, John Wiley, 2000. [Scott Ambler 1] Sitio de Scott Ambler The Design of a Robust Persistence Layer For Relational Databases. http://www.ambysoft.com/persistenceLayer.pdf



[Stal, 1997] Michael Stal, Hans Rohnet, Frank Buschmann, Regine Meunier, Peter Sommerlad. Patern Oriented Software Arquitecture vol 1 , John Wiley, 1997. [WEB-1] Sun Developer Network http://java.sun.com/j2ee/learning/tutorial/index.html [WEB-2] MSDN http://www.microsoft.com/spanish/msdn/arquitectura/default.asp [WEB-3] MSDN http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/entlib.asp [WEB-4] Sun Developer Network http://java.sun.com/developer/technicalArticles/J2EE/AJAX/ [WEB-5] Sun Developer Network http://java.sun.com/j2se/1.4.2/download.html [WEB-6] Apache Software Foundation http://jakarta.apache.org/tomcat/ [WEB-7] The Apache Software Foundation http://ant.apache.org/ [WEB-Tesis] Sitio en Internet de la Tesis http://www.jframework.com.ar http://www.fi.uba.ar/~dmontal/


Patrones de Diseño de Arquitecturas de Software …...Diseño de Patrones de Arquitecturas...

Documents

Transcript of Patrones de Diseño de Arquitecturas de Software …...Diseño de Patrones de Arquitecturas...