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 Diseño de Patrones de Arquitecturas Enterprise FI UBA Í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 Diego Montaldo Guillermo Pantaleo 3 Diseño de Patrones de Arquitecturas Enterprise FI UBA 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 Diego Montaldo Guillermo Pantaleo 4 Diseño de Patrones de Arquitecturas Enterprise FI UBA Pessimistic Offline Lock........................................................................124 Active Front o Ajax................................................................................124 Referencias - Bibliografía.............................................................................128 Diego Montaldo Guillermo Pantaleo 5 Diseño de Patrones de Arquitecturas Enterprise FI UBA 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. Diego Montaldo Guillermo Pantaleo 6 Diseño de Patrones de Arquitecturas Enterprise FI UBA 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: (cid:131) Datos masivos (gran volumen) y persistentes. (cid:131) Acceso concurrente, lo que implica gran cantidad de usuarios. (cid:131) Variedad de interfaces de usuario, lo que implica diversidad en la funcionalidad brindada. (cid:131) Integración con otros sistemas, lo que implica que comparten funcionalidad y / o datos. (cid:131) 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. (cid:131) 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 Diego Montaldo Guillermo Pantaleo 7 Diseño de Patrones de Arquitecturas Enterprise FI UBA 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. Aspectos de Capas de una aplicación Enterprise interés Capa Capa Capa Capa Presentación Servicios Dominio del Persistencia Problema Contexto y Problemas Problemas Problemas de Problemas Problema derivados de la derivados del modelado del derivados de la capa receptora acceso al dominio y del persistencia de de modelo de negocio. objetos en bases requerimientos. objetos a relacionales y través de la acceso lógica de la multiusuario. aplicación. Patrones de Web Distribution Todos los Data Source Diseño Presentation Patterns patrones básicos Architectural utilizados en Patterns [Martin [Martin Fowler, de Categoría Patterns [Martin la resolución Fowler, 2003] 2003] Diseño. [Gamma Fowler, 2003] et al, 1995] Object Relational Behavioral Patterns [Martin Fowler, 2003] Object Relational Structural Patterns [Martin Fowler, 2003] Offline Concurrency Patterns [Martin Fowler, 2003] Transición Lógica de Lógica de Modelo del Modelo del Análisis Aplicación Aplicación / Problema / Problema /Diseño Lógica de Lógica de Persistente Negocio Negocio Tecnología Servlet /JSP POJO POJO EJBEntity / utilizada EJBSession EJBSession DataMappers / /EJBEntity POJO /EJBEntity Framework Generador de la básico de capa de soporte Servicios de logeo, configuración y seguridad. persistencia utilizando reflection. Tabla 1 Referencias para la tabla: (cid:131) POJO, del inglés “plain old java object”. [Marinescu 2002] Diego Montaldo Guillermo Pantaleo 8 Diseño de Patrones de Arquitecturas Enterprise FI UBA 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: (cid:131) ¿Cómo se convierten las columnas del resultado de un query SQL en objetos? (cid:131) ¿Cómo se refleja en forma eficiente en un query SQL el cambio de estado de un objeto en memoria? (cid:131) ¿Cómo se modelan las relaciones? (cid:131) ¿Cómo se mapean las relaciones de herencia de un modelo de objetos en un modelo relacional de una base de datos? (cid:131) ¿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. Diego Montaldo Guillermo Pantaleo 9 Diseño de Patrones de Arquitecturas Enterprise FI UBA 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 Diego Montaldo Guillermo Pantaleo 10