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 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 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 Diseño de Patrones de Arquitecturas de Software Enterprise Tesista : Diego Montaldo - Director : Guillermo Pantaleo

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

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

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

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

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

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

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

Objetivo Introducción Arquitecura Capas Framework 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

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

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

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

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

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

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

Patrones de Diseño de Arquitecturas de Software Enterprise