Patrones de Diseño de Arquitecturas de Software Enterprise

Patrones de Diseño de Arquitecturas de Software Enterprise
Tesista: Diego Fernando Montaldo Director: Profesor Ing. Guillermo Pantaleo Noviembre 2005 Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Objetivo Analizar los problemas que se plantean en el desarrollo de sistemas con arquitecturas enterprise. Examinar los patrones de diseño conocidos como solución a este tipo de problemas. Proponer una arquitectura que utilice, adapte e integre a estos patrones, obteniendo un framework de trabajo, que permita el desarrollo de una aplicación de tipo enterprise, teniendo resueltos a estos problemas típicos, permitiendo focalizarse en el problema del dominio del negocio en sí. Objetivo Introducción Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Bueno, el objetivo fue analizar los problemas que existen en aplicaciones con arquitecturas de tipo enterprise. Este tipo de aplicaciones tienen complejidades inherentes las cuales ya fueron analizadas y hay una serie de patrones que brindan soluciones a estos problemas en un contexto dado. Quizas para un mismo problema vemos direfentes soluciones, de acuerdo a algunas variedades en el contexto. Por lo que se examinaron estos patrones existentes, (prinicpalemnte los presentados por Fowler, Gamma, Marinescu, en sus libros). En estos libros se analizan los patrones casi en forma individual, pero al haber varias posibles combinaciones de ellos, no presentan o proponen mas bien lo dejan a criterio del lector, su seleccion para uso en conjunto. La idea nuestra fue tratar de ver como se vinculan entre si, ya que al proponer la utilizacion de uno en particular, este afecta a la utilizacion de otro para otro problema, es decir hay decisiones que se toman al utilizar un patron, que inhabilitan o condicionan a la solucion a dar en otro problema vinculado. Como objetivo final la idea fue proponer una arquitectura, seleccionando estos patrones existentes, vinculandolos entre si, adaptandolos cuando fuera necesario para que puedan funcionar en conjunto, Donde esta arquitectura ya tenga analizado estos problemas y brinde soluciones, permitiendo a los diseñadores, desarrolladores, focalizarse en la resolución de los problemas del dominio y del negocio, que son a los que hay que brindar una solucion. Finalmente se implemento un framework en java que se adapta a la arquitectura propuesta y facilita el desarrollo de aplicaciones con estas carcteristicas. Es decir el mismo ya tiene resuelto en sus clases bases muchas de estas problematicas y permite al especializar ciertas clases darle el comportamiento faltante a la abstraccion del framework. Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Introducción Sistemas de Tipo Enterprise
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. Objetivo Introducción Sistemas de Tipo Enterprise Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Dentro de lo que se denomina desarrollo de software se abarca el desarrollo de muchos sistemas, con caracteristicas totalmente diferentes y cada uno con distintas complejidades y distintos objetivos y para cada tipo de sistema se utiliza una estrategia diferente para su resolucion Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Características de los 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. Lógica de negocio, lo que implica procesamiento de datos. Variedad de interfaces de usuario, lo que implica diversidad en la funcionalidad brindada. Objetivo Introducción Sistemas de Tipo Enterprise Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones 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: 1) Manejan gran catidad de datos, masivos en gran volumne y que deben alamcenarse en algun medio persistente (donde este generalemtne es una base de datos relacional) 2) Poseen mucha Lógica de negocio, es decir, reglas asociadas al dominio o a la manera en que hacen uso de la informacion en el contexto del negocio analizado, lo que implica gran procesamiento de datos, verificando y aplicando estas reglas. 3) Gran Variedad de interfaces de usuario, lo que implica diversidad en la funcionalidad brindada. Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

5. Acceso concurrente, lo que implica gran cantidad de usuarios.
4. Integración con otros sistemas, lo que implica que comparten funcionalidad y / o datos. 5. Acceso concurrente, lo que implica gran cantidad de usuarios. 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. Por lo general deben ser sistemas escalables y robustos. Objetivo Introducción Sistemas de Tipo Enterprise Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones 4. Integración con otros sistemas, lo que implica que comparten funcionalidad y / o datos. 5. Acceso concurrente, lo que implica gran cantidad de usuarios. 6. 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. RECALCAR: 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. Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Sistemas de Tipo Enterprise Arquitectura Frameworks Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Frameworks Hoy en día existen muchos frameworks que resuelven problemáticas asociadas a este tipo de arquitecturas. Desde plataformas tecnológicas, como las implementaciones de las especificaciones J2EE, la plataforma .Net de Microsoft, hasta frameworks que atacan problemas parciales (persistencia, presentación, transporte, etc) permitiendo combinarlos para obtener una arquitectura completa. Objetivo Introducción Sistemas de Tipo Enterprise Arquitectura Frameworks Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Algunos de ellos son: Persistencia Presentación Objetivo Introducción
EJB Entity beans JDBC SQLJ TopLink CocoBase Hibernate / nHibernate JPOX (JDO) Versant (JDO) OBJ Object Spaces Presentación Struts WebWork Tapestry Objetivo Introducción Sistemas de Tipo Enterprise Arquitectura Frameworks Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Definiendo la Arquitectura
Criterios de Diseño Las aplicaciones del tipo Enterprise, poseen un dominio complejo, con lógica de negocio compleja y muchas reglas de negocio, las cuales varían con el tiempo. 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. Objetivo Introducción Arquitecura Criterios de Diseño Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. 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. Objetivo Introducción Arquitecura Criterios de Diseño Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Objetivo Introducción Arquitecura Capas Framework Patrones Generador
Criterios de Diseño Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Por lo que ingresamos otra nueva capa, la Service Layer, que haciendo uso del dominio, brinda los servicios necesarios para satisfacer los requerimientos de la aplicación. Objetivo Introducción Arquitecura Criterios de Diseño Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Criterios de Diseño Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Capas Lógicas Definida la arquitectura se analiza la implementación de cada capa lógica Capa de Servicio – Service Layer 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. Objetivo Introducción Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Capas Servicio Modelo de Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Servicio Modelo de Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Capas Servicio Modelo de Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Capa de Modelo de Dominio - Domain Model Layer
Uno de los objetivos propuestos es que la capa de dominio este lo mas desacoplada posible del resto de las capas, por lo que 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, 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 un poco intrusivo ya que la clase de dominio debe sobrecargar ciertos métodos de DomainObject generando 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. Objetivo Introducción Arquitecura Capas Servicio Modelo del Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Para romper con esta dependencia recurrimos al uso del patrón de diseño Adapter.
Objetivo Introducción Arquitecura Capas Servicio Modelo del Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Por esta razón fue introducida la interfaz IDomainObject.
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. Objetivo Introducción Arquitecura Capas Servicio Modelo del Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Servicio Modelo del Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Capa de Persistencia – Persistence Layer
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. Objetivo Introducción Arquitecura Capas Servicio Modelo de Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Capas Servicio Modelo de Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Este PersistenceBroker es el único acceso a la capa de persistencia.
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 con parámetros 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. Objetivo Introducción Arquitecura Capas Servicio Modelo de Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Manejo de transacciones Identificación de objetos
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 Objetivo Introducción Arquitecura Capas Servicio Modelo de Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Capa de Presentación – Presentation Layer
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 Objetivo Introducción Arquitecura Capas Servicio Modelo de Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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) 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. Objetivo Introducción Arquitecura Capas Servicio Modelo de Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Capas Servicio Modelo de Dominio Persistencia Presentación Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Paquetes Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Capas Framework Paquetes Aspectos Relacionados Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Aspectos Relacionados
Seguridad Autenticación y Autorización (Control de Acceso) Autenticación : Es el proceso por el cual se verifica que alguien (un sistema o un usuario) es quien dice ser. 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. Seguridad al nivel Servidor de Presentación Seguridad al nivel Servidor de Aplicaciones Objetivo Introducción Arquitecura Capas Framework Paquetes Aspectos Relacionados Seguridad Concurrencia Transaccionabilidad Sesiones Auditoría Excepciones Despliegue Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Capas Framework Paquetes Aspectos Relacionados Seguridad Concurrencia Transaccionabilidad Sesiones Auditoría Excepciones Despliegue Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Transaccionabilidad La transaccionalidad del sistema 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. Objetivo Introducción Arquitecura Capas Framework Paquetes Aspectos Relacionados Seguridad Concurrencia Transaccionabilidad Sesiones Auditoría Excepciones Despliegue Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Sesiones La sesión puede administrarse en el cliente, el servidor de aplicación, la base de datos, 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. Objetivo Introducción Arquitecura Capas Framework Paquetes Aspectos Relacionados Seguridad Concurrencia Transaccionabilidad Sesiones Auditoría Excepciones Despliegue Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Auditoría 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 Objetivo Introducción Arquitecura Capas Framework Paquetes Aspectos Relacionados Seguridad Concurrencia Transaccionabilidad Sesiones Auditoría Excepciones Despliegue Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

De Negocio : BusinessLogicException
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 y otra orientada a excepciones ocurridas por errores en runtime en la aplicación, como ser la indisponibilidad de la red, de la base de datos, etc. De Negocio : BusinessLogicException De Aplicación : ApplicationException Objetivo Introducción Arquitecura Capas Framework Paquetes Aspectos Relacionados Seguridad Concurrencia Transaccionabilidad Sesiones Auditoría Excepciones Despliegue Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Paquetes Aspectos Relacionados Seguridad Concurrencia Transaccionabilidad Sesiones Auditoría Excepciones Despliegue Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Capas Framework Paquetes Aspectos Relacionados Seguridad Concurrencia Transaccionabilidad Sesiones Auditoría Excepciones Despliegue Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Paquetes Aspectos Relacionados Seguridad Concurrencia Transaccionabilidad Sesiones Auditoría Excepciones Despliegue Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Patrones Utilizados Identidad - Identity Field Objetivo Introducción
Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Comportamiento en DomainObjectAdaptada
Clave Simple Clave Numérica Única por Base de Datos Comportamiento en DomainObjectAdaptada Manejo de Clave administrado por tablas Objetivo Introducción Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Asociaciones Se utilizaron los patrones Foreign Key Mapping, Association Table Mapping [Martin Fowler, 2003] para mantener las relaciones entre objetos. 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. Objetivo Introducción Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Relación entre los patrones
Objetivo Introducción Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Mapeos de objetos a tablas
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. Objetivo Introducción Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Objetivo Introducción Arquitecura Capas Framework Patrones
Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Consistencia Se garantiza la consistencia entre objetos cargados de la base de datos. Se debe asegurar una sola instancia de cada objeto en una misma transacción, a efectos de evitar inconsistencias al cambiarlo. Este problema se resuelve aplicando el patrón Identity Map ¿ Tipo de Clave ? ¿ Identity Map explícito o genérico ? ¿ Cúantos ? ¿ Dónde ? Objetivo Introducción Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Patrones Relacionados Objetivo Introducción Arquitecura Capas
Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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] Objetivo Introducción Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Control de Concurrencia
Optimistic offline lock Pessimistic offline lock 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. Objetivo Introducción Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Ajax – Active Front Generalmente el usuario obtiene una vista y trabaja con los datos obtenido por ella, modificando agregando, filtrando la información que contiene. En un entorno Web, ante cada acción se vuelve a enviar una acción la servidor yse recarga la vista (aunque ésta sea la misma, pero con otros datos) Este patrón, una vez cargada una vista, permite invocar los servicios sin recargar la vista. Obteniendo los datos resultantes para luego impactar con dicho resultado en la vista actual. Objetivo Introducción Arquitecura Capas Framework Patrones Identity Field Asociaciones Mapeos de Objetos a Tablas Consistencia Unit Of Work Registry Acceso a Datos Concurrencia Ajax - Active Front Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Relaciones entre los patrones
Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Diseño de Patrones de Arquitecturas de Software Enterprise
Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Generador de Código El generador de código genera, a partir de información de las clases de dominio, las clases que especializan a las clases base de framework Por ejemplo Objetivo Introducción Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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. Objetivo Introducción Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Transición del Análisis al diseño Casos de Uso
Objetivo Introducción Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Modelo de Dominio Objetivo Introducción Arquitecura Capas Framework
Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Trabajo a Futuro Agregar otros protocolos de comunicación entre capas
Agregar otras formas de mapeo de herencia de objetos a relacional Clustering Administración de pool conexiones Mejorar administración de colecciones en el dominio Integración con herramientas estándar (IDEs, Eclipse, EA, etc) Mejorar la dinámica de generación ( refactoring del dominio y adaptación automática de la base) Auditoría Generación automática de otras interfaces de presentación Optimización de interacción con el motor de base de datos Objetivo Introducción Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Conclusiones Separación en Capas Uso de Patrones Uso de frameworks
Separar problemas, trabajar en paralelo con diferentes roles. Uso de Patrones Permite hablar con mayor claridad y alto nivel a los participantes del desarrollo. No reinventar la rueda. Tener alternativas útiles a problemas conocidos. Uso de frameworks Facilitan el desarrollo de una aplicación, start up rápido, foco en el probleba del negocio. Objetivo Introducción Arquitecura Capas Framework Patrones Generador Caso de Estudio Trabajo a Futuro Conclusiones Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

Patrones de Diseño de Arquitecturas de Software Enterprise

Presentaciones similares

Presentación del tema: "Patrones de Diseño de Arquitecturas de Software Enterprise"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Patrones de Diseño de Arquitecturas de Software Enterprise

Presentaciones similares

Presentación del tema: "Patrones de Diseño de Arquitecturas de Software Enterprise"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback