Table Of ContentTESIS 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
Description:BizTalk Server Orchestration, para la coordinación de procesos. • Object Spaces, para el manejo de persistencia, que vendrá en la próxima versión.
