Montaldo Tesisdegradoingenieriainformatica

TESIS DE GRADO EN
INGENIERA EN
INFORMTICA

Patrones de Diseo de
Arquitecturas de Software
Enterprise

TESISTA DIRECTOR
Diego Fernando Montaldo Profesor Ing. Guillermo Pantaleo
dmontal@fi.uba.ar gpantaleo@fi.uba.ar
http://www.fi.uba.ar/~dmontal/

Departamento de Computacin
Facultad de Ingeniera
Universidad de Buenos Aires

Noviembre 2005

Diseo de Patrones de Arquitecturas Enterprise FI UBA

Resumen

Se analizan los problemas surgidos de la implementacin de un sistema con
una arquitectura de software de tipo enterprise. Basndose en este anlisis
se derivan los criterios de diseo a utilizar en este tipo de desarrollo. Se
presenta un sistema reusable (framework) como solucin al problema de
construccin de un sistema del tipo analizado, mostrando los distintos
criterios de diseo elaborados. Se impuso como condicin 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 cdigo de una aplicacin completa sin su modificacin. Se
presenta la arquitectura original diseada para que esta condicin pueda ser
cumplida.

Diego Montaldo Guillermo Pantaleo
2
ndice

Objetivo............................................................................................................ 6
Introduccin ..................................................................................................... 7
Desarrollo de Software................................................................................. 7
Caractersticas 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 Presentacin..................................................................... 13
Definiendo la Arquitectura.............................................................................. 14
Criterios de diseo ..................................................................................... 14
Tecnologas, Protocolos y Estndares 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 Presentacin................................................................................ 30
Diagrama de paquetes del Framework ...................................................... 32
Cada uno tiene sus ventajas y desventajas, stas son analizadas en la
seccin Alternativa Reflection vs Generacin de Cdigo......................... 34
Aspectos relacionados a las capas del Framework ....................................... 35
Seguridad Autenticacin y Autorizacin (Control de Acceso) .................... 35
Autenticacin .......................................................................................... 35
Autorizacin............................................................................................ 36
Concurrencia.............................................................................................. 39
Auditoria..................................................................................................... 40
Excepciones............................................................................................... 41
Despliegue ................................................................................................. 43
Analizando los Patrones Utilizados................................................................ 47
Identificacin .............................................................................................. 47
Asociaciones .............................................................................................. 51
Patrones relacionados a esta eleccin....................................................... 52
Mapeos de objetos a tablas ....................................................................... 53
Patrones relacionados................................................................................ 53
Consistencia............................................................................................... 55
Unidad de Trabajo...................................................................................... 58
Acceso a Servicios Comunes.....................................................................61
Acceso a los Datos Persistentes................................................................ 62
Carga Tarda de Objetos............................................................................ 67
3
Modelado del Dominio del Problema.......................................................... 75
Acceso a la Capa de Negocio .................................................................... 76
Presentacin .............................................................................................. 80
Relaciones Entre Todos los Patrones Analizados...................................... 82
Framework Desarrollado................................................................................ 84
Alternativa Reflection vs Generacin de Cdigo ........................................ 84
De la Arquitectura Propuesta al Framework.............................................. 84
Detalle de las API del framework ............................................................... 86
Relaciones Entre Todos los Patrones Utilizados........................................ 93
Generador del Cdigo para el Framework..................................................... 95
Arquitectura ............................................................................................ 95
Tipos de Generadores Provistos ............................................................ 99
Caso de Estudio........................................................................................... 101
Descripcin del dominio ........................................................................... 101
Modelo del Dominio.................................................................................. 101
Transicin del anlisis al diseo............................................................... 102
Diagrama de Casos de Uso de sistema ............................................... 102
Anlisis de los Casos de Uso, Diagramas de Robustez....................... 103
Paquetes Lgicos del Diseo 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
Apndice 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
4
Pessimistic Offline Lock........................................................................ 124
Active Front o Ajax................................................................................ 124
Referencias - Bibliografa............................................................................. 128
5
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 ms capas.
Basndose en este anlisis establecer criterios de diseo de estos sistemas y
qu tecnologas utilizar. Se examinan los distintos Patrones de Diseo
conocidos como solucin a los distintos problemas que se plantean en el
desarrollo de este tipo de sistemas; tambin las distintas implementaciones
tecnolgicas construidas en base a estos patrones (Sun J2EE, Microsoft
.Net). A partir de este anlisis se fijan criterios de diseo que permiten
seleccionar la tecnologa a utilizar en cada caso, segn el tamao 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 tambin la funcionalidad capturada en el anlisis del problema
que el sistema en desarrollo busca resolver. Bsicamente se trata de que
estos criterios de diseo conduzcan el vuelco del producto del anlisis en una
arquitectura que si bien est dada (tres o ms capas), mantenga la
separacin de la lgica del negocio, la presentacin y los datos; y adems,
conserve el empaquetamiento logrado en el anlisis usando criterios de
cohesin del negocio.

Se desarrolla un sistema reusable (framework) como solucin al problema
planteado mostrando los distintos criterios de diseo elaborados. Se impuso
como condicin 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 cdigo de una
aplicacin completa sin su modificacin. Se presenta la arquitectura original
diseada para que esta condicin pueda ser cumplida.

6
Introduccin
Desarrollo de Software
Dentro de lo que se denomina Desarrollo de Software se abarca el
desarrollo de muchsimos sistemas, con caractersticas totalmente diferentes.
Cada uno con distintas complejidades y distintos objetivos, y para cada tipo
de sistema se utiliza una estrategia diferente para su resolucin.
Se distinguen entre todos los sistemas, a los sistemas de tipo enterprise.
Los sistemas de tipo enterprise son los analizados en este trabajo.

Caractersticas de Sistemas de Tipo Enterprise
Entre las caractersticas salientes de un sistema de tipo enterprise, segn
[Rod Johnson, 2003], [Martin Fowler, 2003], [Marinescu 2002] se pueden
mencionar las siguientes:

Datos masivos (gran volumen) y persistentes.
Acceso concurrente, lo que implica gran cantidad de usuarios.
Variedad de interfaces de usuario, lo que implica diversidad en la
funcionalidad brindada.
Integracin con otros sistemas, lo que implica que comparten
funcionalidad y / o datos.
Disonancia conceptual (modelo de datos con distintas visiones),
debido a que poseen un modelo de negocio subyacente que abarca
distintos aspectos de un rea de negocio. Por lo tanto prestan distintas
funcionalidades a distintos tipos de usuarios.
Lgica de negocio, lo que implica procesamiento de datos.

Ejemplos tpicos de estos sistemas son B2C ( comercio electrnico), sistemas
financieros en lnea, sistemas ERP ( Enterprise Resource Planning). Estos
sistemas por su volumen estn generalmente instalados fsicamente en
varios nodos (servidores). Por sus caractersticas de crecimiento es
importante en su diseo el concepto de escalabilidad y por la necesidad de
prestar servicios en forma continua es importante el concepto de robustez.
Ambos conceptos condicionan el diseo de la arquitectura de este tipo de
sistemas.

Arquitectura de Sistemas de Tipo Enterprise
Ha habido muchas formas de plantear una solucin para este tipo de
sistemas, y bsicamente 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 aplicacin 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 nmero 1 se muestran los aspectos de las arquitecturas de tipo
Enterprise que son de nuestro inters y hacia los cuales se orienta este
7
trabajo. Este trabajo plantea el anlisis de los tem mostrados en las celdas
de la tabla que sigue. Como conclusin al trabajo se desarrollar un
generador de cdigo para el framework desarrollado, donde se mostrarn los
criterios elaborados sobre la base del trabajo anterior.

Capas de una aplicacin Enterprise Aspectos de
inters Capa
Presentacin
Capa
Servicios
Capa
Dominio del
Problema
Capa
Persistencia
Contexto y
Problema
Problemas
derivados de la
capa receptora
de
requerimientos.
Problemas
derivados del
acceso al
modelo de
objetos a
travs de la
lgica de la
aplicacin.
Problemas de
modelado del
dominio y del
negocio.
Problemas
derivados de la
persistencia de
objetos en bases
relacionales y
acceso
multiusuario.
Patrones de
Diseo
utilizados en
la resolucin
Web
Presentation
Patterns [Martin
Fowler, 2003]
Distribution
Patterns
[Martin Fowler,
2003]
Todos los
patrones bsicos
de Categora
Diseo. [Gamma
et al, 1995]
Data Source
Architectural
Patterns [Martin
Fowler, 2003]
Object Relational
Behavioral
Patterns [Martin
Fowler, 2003]
Object Relational
Structural Patterns
[Martin Fowler,
2003]
Offline
Concurrency
Patterns [Martin
Fowler, 2003]
Transicin
Anlisis
/Diseo
Lgica de
Aplicacin
Lgica de
Aplicacin /
Lgica de
Negocio
Modelo del
Problema /
Lgica de
Negocio
Modelo del
Problema
Persistente
Tecnologa
utilizada
Servlet /JSP POJO
EJBSession

POJO
EJBSession
/EJBEntity
POJO /EJBEntity
EJBEntity /
DataMappers /

Framework
bsico de
soporte Servicios de logeo, configuracin y seguridad.
Generador de la
capa de
persistencia
utilizando
reflection.
Tabla 1
Referencias para la tabla:
POJO, del ingls plain old java object. [Marinescu 2002]

8
Problemas de Modelado del Dominio y del Negocio
Debido a que la mayora 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:

Cmo se convierten las columnas del resultado de un query SQL en
objetos?
Cmo se refleja en forma eficiente en un query SQL el cambio de
estado de un objeto en memoria?
Cmo se modelan las relaciones?
Cmo se mapean las relaciones de herencia de un modelo de
objetos en un modelo relacional de una base de datos?
Cmo se mapean los objetos cuyos atributos se persisten en varias
tablas de la base de datos?

Los modelos relacionales y su implementacin 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 expresin, 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 cul de ellos debe conducir el diseo?
Este es un tema de discusin y que tiene adeptos en ambos bandos. Existen
herramientas que generan cdigo 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 optimizacin del
modelo relacional resultante. Por otro lado existe el criterio del camino
opuesto, generar un modelo relacional y a partir de ste generar
automticamente el modelo de objetos. Este tiene la limitacin de que el
modelo relacional es mucho menos expresivo y limita l mismo el modelo de
objetos resultante.

El mejor mtodo de trabajo parece ser aquel que partiendo de un modelo de
objetos parcial, permite la construccin 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 tambin se podrn obtener modelos relacionales sin prdida de
performance y explotar mecanismo propios de un modelo relacional.
9
Estado del Arte
Frameworks
Existen en el mercado distintos servidores de aplicaciones propietarios y de
cdigo abierto y libre que resuelven el problema de una arquitectura de tipo
enterprise. Por ejemplo hay varias marcas que implementan la especificacin
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 adems la integracin 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. Tambin Microsoft ha desarrollado una plataforma basada en el lenguaje
c#, esta plataforma es .Net que tambin resuelve estos tipos de problemas.

J2EE
La plataforma J2EE [WEB-1] utiliza un modelo de aplicacin disitribuida
multicapa. Las partes de una aplicacin 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 mquina
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 lgicas, las aplicaciones J2EE en capas
son denominadas aplicaciones de 3 capas, ya que hace referencia a capas
10
fsicas, puesto que son distribudas en 3 lugares fsicos diferentes, mquina
Cliente, mquina Servidor J2EE y la mquina Servidor Base de Datos.

Las aplicaciones J2EE estan basadas en componentes, cada componente
tiene su propia funcionalidad y permite ser ensamblado en una aplicacin
J2EE, Estos componentes corren y son manejados por un servidor J2EE
La especificacin J2EE define los siguientes componentes:
Application Clients y applets son componentes que corren en el
cliente.
Java Servlet y JavaServer Pages (JSP) con componentes web que
corren en el servidor.
Enterprise Beans (EJB) son componentes de negocio que corren en el
servidor.
Existen 3 tipos de Enterprise Beans: session beans, entity beans, y message-
driven beans.
Un session bean reprepresenta un objeto no persistente que vive mientras
viva las sesin.
Un entity bean representa datos persistentes en una base de datos. Es decir
se encarga de persistir sus datos aunque la sesin del cliente termine o el
servidor se apague.
Un message-driven bean combina caractersticas de un session bean y un
Java Message Service (JMS), permitiendo a un componente de negocio,
recibir mensajes JMS asincronicos.

.NET
La plataforma .NET [WEB-2] nos brinda las siguientes componentes.
Formularios de Windows Forms, para disear las interfaces winform.
Pginas Microsoft ASP.NET, para disear las interfaces web
BizTalk Server Orchestration, para la coordinacin de procesos
Object Spaces, para el manejo de persistencia, que vendr en la
prxima versin
Enterprise Library, [WEB-3] es una librera de Application Blocks, que
son componentes diseados para asistir al desarrollador. Hay por
ejemplo para manejo de cache, de acceso a datos, de log, de
seguridad, de excepciones, etc

Frameworks de Persistencia
La capa de mayor criticidad y por consiguiente en la cual ms trabajo se ha
desarrollado en los ltimos aos es la de persistencia. Debido al choque de
impedancia que se produce entre los objetos del modelo de negocio y los
datos persistidos en una base de datos relacional, es que esta capa requiere
un tratamiento particular.
11
Gran parte de los productos que se han generado atacan el problema del
mapeo y acceso a los datos persistentes. Algunos de los ms conocidos son:

EJB Entity beans
JDBC
SQLJ
TopLink
CocoBase
Hibernate / nHibernate
JPOX (JDO)
Versant (JDO)
OBJ
Object Spaces

Debido a algunas limitaciones de EJB Entity Beans han surgido las otras
alternativas. Bsicamente los Entity Beans presentan la caracterstica de ser
usables cuando los modelos de dominio son simples, deben ser distribuidos y
conectarse a otros sistemas. Su utilizacin es buena cuando existe un mapeo
uno a uno con las tablas de la base de datos. Es decir cuando la granularidad
es baja. No admiten herencia entre clases componentes. Por esta razn y
debido a esta limitacin han surgido otros productos. Debido a esto tambin
es que se desaconseja su utilizacin.
Toplink es un producto muy utilizado en el mercado, ahora integrado al
servidor de aplicaciones Oracle 9i AS. Permite entre otras cosas:

Integracin de EJB CMP
Mapeo de objetos a mltiples tablas
Uso de herencia
Soporta bloqueo optimista de tablas
Transacciones anidadas
Permite adaptar el mapeo de datos entre objetos y tablas
Permite realizar el diseo en ambas direcciones, objetos / tablas y
tablas / objetos.
Permite adaptar cdigo SQL generado
Permite el uso de Store Procedures
Administra pool de objetos

Tiene una desventaja, es dependiente de APIs propietarias.
Hibernate tambin es muy utilizado tanto en el ambiente java como .net.
JDO es una especificacin java que se espera se convierta en el estndar de
administracin de bases de datos orientadas a objetos. No exige la
implementacin de interfaces. Presenta menor sobrecaga en la creacin de
objetos y su configuracin se realiza en un archivo XML, siendo ms simple
que la de los EJB CMP.
Presenta ventajas que hered de EJB tales como el encapsulamiento de
datos de la aplicacin, el mapeo a tablas, trabaja en transacciones
delimitadas por los Session Beans, administra pool de objetos. Tambin
posee ventajas propias como trabajar con clases java genricas y las hace
persistentes, requiere menor infraestructura.

12
Frameworks de Presentacin
Tambien hay varios frameworks de presentacin, que permiten implementar
el patrn MVC.
Entre ellos encontramos

Struts
WebWork
Tapestry

Estos permiten separar la lgica de presentacin facilitando el diseo y reuso.

13
Definiendo la Arquitectura

Criterios de diseo
Dado el tipo de aplicaciones seleccionado, es decir del tipo Enterprise, donde
las aplicaciones poseen un dominio complejo, con lgica de negocio compleja
y muchas reglas de negocio, las cuales varan con el tiempo, y van
modificando a las actuales, y nutrindose con otras nuevas, la idea central es
modelar el dominio utilizando programacin orientada a objetos, obteniendo
as, un modelo del dominio, formado por objetos muy similares a la realidad,
que se rigen segn las reglas de negocio.
Para poder acompaar 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 aplicacin, ste es el objetivo principal en este trabajo,
es decir se busc desacoplar lo ms posible al modelo de dominio del resto
de la aplicacin.
Para ello la arquitectura elegida es una arquitectura basada en capas lgicas
(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 lgica de negocio de la capa de presentacin, y volcarla en la
capa de modelo del dominio, como se muestra en la Figura 2. Separando as
muy bien todo lo que tiene que ver con obtencin de informacin y
presentacin al usuario, de la lgica del dominio modelado.

cd Evolucin de Capas 1
DataSource Layer
Presentation Layer
Domain Model Layer

Figura 2
En una aplicacin, vamos a encontrar lgica y reglas de negocio del dominio
modelado, y lgica y reglas de negocio de la aplicacin particular en s, de
acuerdo a como sta hace uso del dominio.
14
Se busca que la lgica del dominio quede en la capa de dominio, pero no la
lgica de aplicacin, ya que sta no es parte del dominio sino de la aplicacin
que hace uso de l.

En este esquema de tres capas, la lgica de la aplicacin o bien queda en la
capa de presentacin o queda en la capa de dominio. Sin embargo, no es
parte de ninguna de las dos realmente.

La idea es que el modelo de dominio, modele el dominio en general, posea
las reglas inherentes a este dominio y pueda ser reutilizado en distintas
aplicaciones. Cada aplicacin puede tener sus propias transacciones de
negocio que hacen uso del dominio de una manera particular.

Si la aplicacin tuviera diferentes tipos de clientes de presentacin y si ellos
albergaran la lgica de aplicacin, sta estara distribuda en cada capa
cliente, dificultando bastante su mantencin.

Por todo esto se justifica el uso una capa de servicio sobre el modelo de
negocio, que juega el papel de fachada (Facade Pattern). La misma puede
verse en la Figura 3.
Es decir la capa de servicio se encarga de exponer los servicios necesarios
en la aplicacin hacia la capa de presentacin.
La capa de presentacin solo busca obtener las funcionalidades o servicios
que le permitan resolver la problemtica de la aplicacin y exponer de forma
amigable y eficiente interfaces al usuario para la recoleccin y visualizacin
de la informacin vinculada a dichos servicios.

Por lo que esta capa obliga a definir una interfaz con la funcionalidad o
servicios que la capa de presentacin necesita para cumplir con su objetivo.
Esta fachada conoce al modelo y en cada servicio expuesto, har uso de los
objetos del dominio para la resolucin del mismo.

Si la capa de presentacin corre en otro espacio fsico que la capa de
negocio, esta tambin juega el papel de interfaz remota, minimizando el
trfico entre ambas capas ya que la lgica de la aplicacin se resuelve
completamente en la capa de servicio.

15
DataSource Layer
Domain Model Layer
Service Layer
Presentation Layer

Figura 3

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

16
Presentation Layer
Domain Model Layer
DataSource Layer
Service Layer
Persistence Layer

cd Distribucin de lgica sobre las Capas
DataSource Layer
Domain Model Layer
Persistence Layer
Presentation Layer
Service Layer
Componentes de Presentaci n
Lgi ca de Presentaci n
Lgi ca de l a Apl i caci n
Regl as de negoci o de l a Apl i caci n
Transacci ones de Negoci o
(Casos de Uso)
Model o del Domi ni o
Regl as de Negoci o del Domi ni o
Logi ca de Persi stenci a
Transacci ones del DBMS

Figura 4a Figura 4b

En la Figura 4b podemos ver como se distribuyen las diferentes partes de la
aplicacin sobre esta arquitectura en capas.

Buscando que esta arquitectura sea escalable y ms segura ante ataques, es
deseable poder distribuir estas capas lgicas (layers) en distintas capas
fsicas (tiers). Este tema es analizado en la seccin de Despliegue.

17
Tecnologas, Protocolos y Estndares a Utilizar

Se utilizaron para el presente trabajo:

JDK 1.4 [WEB-5]
Tomcat 5.0 [WEB-6]
Servlets
Ant.jar (compilacin, deploy) [WEB-7]
Xerces.jar (manejo de xml)
Drivers de SQL
Reflection
Generacin de cdigo
HTML
XML
XML-HTTP Object
JavaScript

18

Analizando cada Capa del Framework

Definida la arquitectura a utilizar, se analiza la implementacin de cada capa.

Capa de Servicio

Tambin denominada Fachada de Servicio (Facade) [Martin Fowler, 2003]
[Marinescu 2002], es la encargada de brindar los servicios necesarios a la
capa de presentacin.
Contiene la lgica de la aplicacin, en forma de transacciones de negocio.
Todos los servicios necesarios para la capa de presentacin referidos al
dominio estan expuestos en la interfaz de servicio, lo que permite separar
fisicamente ambas capas y jugar el papel de interfaz remota en dichos casos.
La capa de presentacin conoce las interfaces de servicio y cuenta con una
Factory de servicios (ServiceFactory), para obtener una implementacin de
dicha interfaces.
Los parmetros intercambiados entre ambas capas son objetos DTO (Data
Transfer Object) [Martin Fowler, 2003] que son objetos simples (POJOs)
utilizados para el intercambio de informacin.
Estos objetos DTO cumplen el papel de contenedores de datos para el
transporte entre las capas de presentacin/servicio. Estn orientados a cada
caso de uso y su vista asociada en la capa presentacin.
Contienen los datos vinculados al resultado de una transaccin en la capa de
servicio, que pueden ser datos resultantes de distintos objetos de negocio de
la capa de modelo de negocio.

La definicin de estos aspectos de la arquitectura se muestran en la Figura 5,
dnde la capa de Presentacin slo conoce a la ServiceFactory, y a las
interfaces que expone la capa de servicio junto a los objetos DTO de sus
parmetros.
Con la ServiceFactory obtiene una implementacin para las interfaces de
servicio que conoce a partir de su nombre y ya puede consumir los servicios
que sta le brinda.

19
cd Figura 5
presentation
+ fwk
(from framework)
fwk
+ Acti onServl et
+ Enti tyControl l er
+ Invoker
+ PageControl l er
(from presentati on)
Servi dor de Presentaci n (Web) Servi dor de Apl i caci ones

iservice
+ IBaseServi ce
+ dtoEnti ti es
+ pequi
(from framework)
service
+ BaseServi ce
+ pequi
(from framework)
pequi
+ cl i entes
+ ot
+ personas
(from servi ce)
ot
+ ComponenteServi ce
+ EstadoDeOrdenServi ce
+ EstadoDeProcesoServi ce
+ Materi al Servi ce
+ NotaServi ce
+ Observaci onServi ce
+ OrdenDeTrabaj oServi ce
+ ProcesoServi ce
+ Sol i ci tanteServi ce
+ Ti poDeProcesoServi ce
+ Ti poMateri al Servi ce
+ TurnoServi ce
(from pequi )
pequi
+ cl i entes
+ ot
+ personas
(from i servi ce)
ot
+ IComponenteServi ce
+ IEstadoDeOrdenServi ce
+ IEstadoDeProcesoServi ce
+ IMateri al Servi ce
+ INotaServi ce
+ IObservaci onServi ce
+ IOrdenDeTrabajoServi ce
+ IProcesoServi ce
+ ISol i ci tanteServi ce
+ ITi poDeProcesoServi ce
+ ITi poMateri al Servi ce
+ ITurnoServi ce
(from pequi )
dtoEntities
+ CustomData
+ pequi
(from i servi ce)
ot
+ ComponenteDTO
+ EstadoDeOrdenDTO
+ EstadoDeProcesoDTO
+ Materi al DTO
+ NotaDTO
+ Observaci onDTO
+ OrdenDeTrabaj oDTO
+ ProcesoDTO
+ Sol i ci tanteDTO
+ Ti poDeProcesoDTO
+ Ti poMateri al DTO
+ TurnoDTO
(from pequi )
remoting
+ cl i ent
+ server
(from framework)
client
Servi ce
+ Servi ceFactory
(from remoti ng)
server
+ Servi cePubl i sher
(from remoti ng)
Servi dor de Remoti ng (RMI)
Figura 5
20
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 presentacin.
Para ello el ServiceFactory se encarga de abstraer la localizacin del servicio,
pudiendo ser este local o remoto.
Por lo que de manera configurable (por cdigo xml) se permite que el
ServiceFactory instancie una implementacin local para la interfaz o utilice un
proxy a una implementacin remota. (Como ser un objeto de servicio
publicado por RMI en un servidor).
Todo esto es transaparente a la capa de presentacin ya que ella espera una
implementacin cualquiera para la interfaz de servicio que utiliza.
De esta manera de acuerdo a como este desplegada la aplicacin se puede
definir mediante configuracin, de acuerdo a los beneficios buscados, como
utilizar dicho servicio (local o remoto).
Para desacoplar el mecanismo de remoting utilizado por el framework, se
estructuraron las clases que lo implementan como se muestra en la figura 6.

Clases de servicios del dominio
Clases genricas del Framework
RMI - jdk
UnicastRemoteObject
BaseService
ConcreteService
interface
Remote
interface
IBaseService
interface
IConcreteService
realize
realize

Figura 6

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

21
Se puede ver su implementacin en el file BaseService.java del paquete
framework\service y IBaseService.java del paquete framework\iservice.

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

Se puede encontrar dicho script en el file servicePublisher.bat.

La dinmica de creacin, registracin y obtencin de servicios para ambos
escenarios se muestra en la Figura 7.
cd Figura 7
Presentation ServiceFactory
RMI Registry
Service
Publisher
System
Administrator
Service Service2
Escenari o de creaci n y
regi straci n de servi ci os.
Escenari o de obtenci n de servi ci os.
Caso Servi ci o Local
Servi dor de Presentaci n es el mi smo
que servi dor de Apl i caci ones y no es
necesari o un servi dor RMI
Escenari o de obtenci n de servi ci os.
Caso Servi ci o Remoto
SERVIDOR DE PRESENTACIN
SERVIDOR RMI
SERVIDOR DE APLICACIONES
runServi ces
getServi cesInfo()
new
servi ce
rebi nd(servi ce)
new
servi ce2
rebi nd(servi ce2)
getServi ce(servi ceName)
getServi ceInfo(servi ceName)
new
servi ce2
servi ce2
getServi ce(servi ceName)
getServi ceInfo(servi ceName)
l ookUp(servi ceName)
servi ce
servi ce

Figura 7
La capa de servicio, es el nico acceso al modelo desde la capa de
presentacin, por lo que es un buen lugar para agregar la seguridad a los
mismos.
Por lo que cada clase de servicio dentro de cada mtodo, deber antes
que nada verificar los permisos para el usuario actual.
22
Una vez autenticado un usuario, el mismo posee un token de
identificacin, (Ver secin de Autorizacin / Autenticacin), el mismo es
su identificador, y es pasado como contexto desde la capa de
presentacin, por lo que la capa de servicio debe verificar que el token
sea de un usuario ya autenticado, que no est vencido y verificar la
autorizacin para dicho servicio.

Asi mismo es un buen lugar para colocar la auditoria del sistema,
indicando que usuario intento ejecutar que servicio a que hora y con que
parmetros.
Con esto puede desarrollarse luego una interfaz para que un
administrador monitoree que esta haciendo un usuario dado.

23
Capa de Modelo del Dominio

Las Aplicaciones de Tipo Enterprise poseen un dominio de negocio complejo.
Esta capa contiene todas las clases que modelan dicho dominio, sus
entidades, sus relaciones y las reglas de negocios que cumplen.

Debemos recordar que una condicin que impusimos al framework de
persistencia es el requerimiento de instanciar sobre l un modelo de un
dominio cualquiera sin tener que modificarlo.
Esta restriccin es para que la Capa del Dominio este desacoplada del resto
de las capas. Esto ayuda a que el modelo del dominio y sus reglas de
negocio sean reusables, y puedan modelarse sin tener en cuenta otros
problemas mas all del dominio analizado.
Lo ideal es que a partir de un modelo de dominio, el mismo pueda integrarse
a una arquitectura como la propuesta sin que el framework y su arquitectura
sean intrusivos sobre el modelo de dominio dado.
Para esto, la capa de dominio no debe conocer a la capa de persistencia. La
capa de persistencia es la que conoce al dominio y sabe como recuperar y
alamacenar objetos de dominio.
Sin embargo es necesario contar con cierta lgica relacionada a la
persistencia (registrar cuando hay un objeto de dominio nuevo, cuando se
modifica, cuando debe ser eliminado del medio persistente).

Esta lgica puede estar ubicada en una clase base denominada
DomainObject [Martin Fowler, 2003] como lo propone el patrn Domain
SuperType, [Martin Fowler, 2003] donde cada objeto de dominio la extiende.
Pero este esquema es intrusivo ya que la clase de dominio debe sobrecargar
ciertos mtodos de DomainObject (en los setters debe informar que ha sido
modificada).
Todo esto genera una fuerte dependencia de la capa de dominio a la capa de
persistencia ya que DomainObject es una clase que forma parte de la capa
de persistencia.

Para romper con esta dependencia recurrimos al uso del patrn de diseo
Adapter. El diagrama de clases se muestra en la Figura 8.

24
cd Data Model
Service Layer ClaseDominio
ClaseDominioAdaptada DomainObj ect
Figura 8

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

Figura 9
25

Por ejemplo en la clase AbstractMapper de la capa de persistencia, en el
mtodo Load( DomainObject do) recibe un objeto y lo carga con datos
persistidos en la base de datos. En ste caso, ste mtodo cambi a Load(
IDomainObject do ).

Si los objetos del dominio heredan todos de DomainObject (como en el caso
de utilizar el patrn Layer SuperType), no se presenta este problema, sin
embargo se mostr que eso representa una dependencia muy fuerte entre la
capa de dominio y la de persistencia.
Esta es la razn por la cual nuestra solucin termin siendo la mostrada en la
Figura 9.

Al interactuar desde la capa de servicio con objetos del dominio, lo haremos
mediante la interfaz IPersistenceBroker, la misma expone mtodos para
obtener un objeto persistido, buscarlos, borrarlos, y crearlos. (Ver detalle de
la API en la seccin de Detalle de las API del framework)
Esto es debido a que el framework para contar con la lgica descripta debe
operar con clases del tipo DomainObjectAdaptadas, aunque las mismas sean
vistas como ClaseDominio ya que son ClaseDominio al heredar de ellas.

Si desde la capa de dominio fuera necesario instanciar otras entidades de
dominio que terminarn siendo persistentes, sto debe hacerse mediante el
uso de una Factory que presenta el framework para instanciarlos, es decir a
travs del mtodo createDomainObject(Class domainObjectClass) de la
interfaz IPersistenceBroker.
En este caso, esto implica que el desarrollo del modelo de dominio, debe
hacerse en el contexto de una previa definicin de la arquitectura que incluye
el mecanismo de persistencia. Slo de esta forma se garantiza no modificar
dicho dominio al instanciarlo en este framework. (Ver seccin de A Futuro)
26
Capa de Persistencia

La capa de persistencia es la encargada de abstraer y resolver el acceso a
datos a un motor de base de datos relacional.
Su objetivo es ser la nica que conoce como son persistidos los objetos de
dominio de la aplicacin y como recuperarlos abstrayendo el choque de
impedancias entre objetos y tablas relacionales.

La capa superior no interacta directamente con la base de datos, sino que lo
hace mediante la interfaz expuesta por la capa de persistencia, logrando as
la independencia buscada.
Esto permite cambiar la estrategia con que se persisten los objetos, incluso
cambiar la tecnologa o el motor utilizado sin impactar mas all de sta capa.

La capa de persistencia, se expone a travs de la interfaz IPersistenceBroker.
La existencia de sta interfaz es desacoplar como trabaja la capa de
persistencia.
Esta interfaz expone mtodos como por ejemplo: crear un objecto de
dominio, borrarlo, realizar bsquedas por clave y por distintos criterios.
Para obtener una implementacin 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 travs de una Factory de ORMs que cumplen con
dicha interfaz.

En la Figura 10 puede observarse el mecanismo, donde una clase de la capa
de presentacin solicita una bsqueda con ciertos parmetros a partir de un
criterio dado.
Desde la capa de presentacin llega un pedido a la capa de servicio, sta
obtiene una implementacin del IPersistenceBroker a travs de la Factory,
comienza una nueva unidad de trabajo (patrn UnitOfWork) realiza la
bsqueda, opera con los objetos de dominio resultantes, carga objetos DTO
para retornar a la capa de presentacin y los retorna.
27
cd Figura 10
Clase de
Presentacin
Clase de
Servicio
PersistenceBrokerFactory PersistenceBroker
fi nd(parmetros de bsqueda )
getInstance(Persi stenceBrokerName)
new
aPersi stenceBroker
aPersi stenceBroker
newUni tOfWork
fi ndAl l (Cri teri o, Parmetros)
aCol l ecti on
toDTO(aCol l ecti on)
commi tUni tOfWork
DTOCol l ecti on

Figura 10

Se puede ver su implementacin en el file PersistenceBrokerFactory.java
del paquete framework\utils\casestudy y IPersistenceBroker.java del
mismo paquete.

Se implementa el broker en la clase PersistenceBroker (utilizando patrones
como UnitOfWork, Mappers, IdentityMap, DomainObject, que fueron
adaptados para las necesitades puntuales del framework). El uso de los
mismos es explicado y detallado en el captulo de Analizando los patrones
utilizados.

Este PersistenceBroker es el nico acceso a la capa de persistencia.

Como dijimos anteriormente para obtener una instancia concreta de
IPersistenceBroker, se utiliza al PersistenceBrokerFactory que mediante
reflection instancia al broker indicado en los archivos de configuracin,
permitiendo cambiar la implementacin del mismo por otra mas adecuada.

Para evitar el uso de cdigo SQL que puede necesitarse para las bsquedas
por criterio predefinidas, se utiliz un esquema de Finders. Un Finder recibe
un nombre y define una sentencia SQL en un archivo xml. Luego un mtodo
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 cdigo SQL este agrupado en estos files xml, permitiendo
que sean facilmente modificables y actualizables.

28

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 mtodos al
estilo: save(obj), delete(obj), create(obj), retrieve(obj))
Manejo de transacciones
Identificacin de objetos
Utilizacin de Proxies
Posibilidad de realizar consultas

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

29
Capa de Presentacin

Esta es la capa que interactua con el usuario final, es la encargada de
presentar la informacin y recolectarla para hacer uso de los servicios
expuestos por la capa de servicio, para satisfacer los casos de uso de la
aplicacin.
En este trabajo se utiliz como tecnologa principal una interfaz web, a travs
del uso de un browser. Pero la capa de servicio, puede ser consumida desde
cualquier tecnologa vinculada, como clientes ricos, dispositivos mviles, etc,
como puede verse en algunos de los ejemplos que acompaan al trabajo.

Esta capa posee slo la lgica necesaria para juntar los datos e invocar un
servicio y mostrar su resultado. De ser necesario lgica de presentacin se
puede agregar una capa de UIP, o capa de Proceso de Interfaz del Usuario,
para poner cierta lgica relacionada con pantallas tipo wizards, que permiten
ir recoletando datos de una manera mas amigable al usuario para luego
invocar un nico mtodo de servicio. Pero no debe contener lgica de
negocio o de aplicacin ya que esta debe estar en su capas
correspondientes, facilitando su mantenimiento y modificacin.

Para la obtencin de vistas (pginas jsp) se utiliza el patrn PageController
que permite obtener una vista perteneciente a un mdulo.
Las vistas pertenecen a un mdulo y estn definidas en un xml (modules.xml)
En la Figura 11 puede verse un ejemplo de su utilizacin.

cd Figuras PageController
PageController Browser Cliente
/servl et/PageControl l er?modul e=modul eName&vi ew=vi ewName
getVi ewInfo(Modul e, Vi ew)
bui l dHeaderFooter()
html Page

Figura 11

Cada vista obtenida por el PageController mantiene un estndar de
encabezado y pie de pgina, en el encabezado se visualiza un nombre para
la vista y el pie de pgina contiene una seccin destinada a visualizar
mensajes al usuario y una botonera con botones que toman diferentes
acciones sobre la vista. Toda esta informacin es configurada en el archivo
xml perteneciente a la vista.

Por otro lado vamos a ver que muchas de los casos de uso del negocio van a
ser para el manejo de creacin, modificacin y borrado de entidades de
30
negocio, (servicios bsicos 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 travs de vistas para Administracin
(Managers) que permiten buscar la entidad a travs del uso de filtros y
eliminarla o editarla o crear una nueva, a travs de la vistas para Edicin y
Alta (Editor y New) que permiten la modificacin de la entidad, y la vista de
Seleccin (Selector) que permite seleccionar una entidad para utilizarla en
otra vista.
Todas estas vistas para manejos de abm y seleccin son manejadas a travs
de un control llamado EntityManager, que a partir de un nombre de vista y
tipo, presenta dicha vista para manejo de esa entidad a travs de los
mtodos expuestos en la capa de servicio.
Un ejemplo del mismo puede verse en la Figura 12

cd Figuras EntityController
Browser Cliente EntityController
/servl et/Enti tyControl l er?enti ty=enti tyName&useCase=useCaseType
Enti tyInfo:= getEnti tyInfo()
bui l dPage(Enti tyInfo)
html Page

Figura 12

En los archivos xml corrspondientes a las entidades (entityName.entity.xml)
se puede definir que atributos del obtejo DTO, visualizar, de que tipo de dato
es, facilitando verificaciones de dato sobre el control html renderizado, con
que nombre visualizar al atributo, valor inicial por defecto, etc.
El EntityController sabe a partir del useCase recibido como armar la vista, los
posibles useCase con: manager, editor, new, selector, cada uno tiene una
funcionalidad dada sobre la entidad, el manager permite a tarvs de sus
filtros realizar bsquedas de las entidades, seleccionar una y borrarla, o
llamar al editor o new, permitiendo modificar la entidad seleccionada o crear
una nueva.
El selector se utiliza para seleccionar una entidad a travs de un filtro, es
similar a una manager pero la entidad seleccionada permite llevarla a otra
vista para procesarla.
Para la ejecucin de mtodos de servicio en general (como hacen las vistas
obtenidas con el EntityController para ejecutar los mtodos de servicio
correspondientes a los abms simples de entidades), se hacen a travs del
patrn ActiveFront o Ajax, para los mismos es necesario dar de alta la
31
informacin correspondiente a la accin que representa al mtodo de servicio
a ejecutar en el archivo xml de acciones (servlet-actions.xml)
En la Figura 13 se observa un diagrama de secuencia de una invocacin a
una accin.
cd Figuras Invoker
User
Browser Cliente
JavaScriptObj ect
Invoker
Invoker
resul t := Instanti ate( Acti onInfo.cl ass,
Acti onInfo.method, Acti onInfo.parameters )
executeActi on(parameters)
Acti onXml Request:= bui l dActi onXMLRequestFromPage(parameters)
execute(Acti onXml Request)
/servl et/Invoke?Acti onXMLRequest
Acti onInfo:= process(Acti onXml Request)
xml Resul t:= seri al i zeXML(resul t)
xml Resul t
xml Resul t
renderResul tInPage(xml Resul t)

Figura 13

Diagrama de paquetes del Framework

En el diagrama de paquetes de la Figura 14 se muestra la arquitectura
resultante, implementada segn las capas que se analizaron.
Esta arquitectura ser analizada en detalle en una prxima seccin.
Se distinguen en dos colores, la parte genrica del framework y la parte
especializada para la aplicacin o caso de estudio.

32
cd Caso de Estudio - Pequi
presentation
+ fwk
(fromframework)
fwk
+ Acti onServl et
+ Invoker
+ PageControl l er
(frompresentati on)
iservice
+ IBaseServi ce
+ dtoEnti ti es
+ pequi
(fromframework)
dtoEntities
+ CustomData
+ pequi
(fromi servi ce)
service
+ BaseServi ce
+ pequi
(fromframework)
pequi
+ cl i entes
+ ot
+ personas
(fromi servi ce)
ot
+ INotaServi ce
+ IProcesoServi ce
+ ITurnoServi ce
(frompequi )
domainModel
+ fwk
(fromframework)
fwk
+ pequi
(fromdomai nModel )
pequi
+ cl i entes
+ ot
+ personas
(fromfwk)
ot
+ ComponenteFwk
+ EstadoDeOrdenFwk
+ EstadoDeProcesoFwk
+ Materi al Fwk
+ NotaFwk
+ Observaci onFwk
+ OrdenDeTrabaj oFwk
+ ProcesoFwk
+ Sol i ci tanteFwk
+ Ti poDeProcesoFwk
+ Ti poMateri al Fwk
+ TurnoFwk
(frompequi )
pequi
+ cl i entes
+ ot
+ personas
(fromservi ce)
ot
+ NotaServi ce
+ ProcesoServi ce
+ TurnoServi ce
(frompequi )
persistence
+ caseStudy
+ fwk
(fromframework)
caseStudy
+ pequi
(frompersi stence)
pequi
+ cl i entes
+ ot
+ personas
(fromcaseStudy)
ot
+ ComponenteMapper
+ EstadoDeOrdenMapper
+ EstadoDeProcesoMapper
+ Materi al Mapper
+ NotaMapper
+ Observaci onMapper
+ OrdenDeTrabaj o_pequi _ot_Materi al Domai nObj ectCol l ecti onRel ati on
+ OrdenDeTrabaj o_pequi _ot_Observaci on_mtmDomai nObj ectCol l ecti onRel ati on
+ OrdenDeTrabaj o_pequi _ot_ProcesoDomai nObj ectCol l ecti onRel ati on
+ OrdenDeTrabaj oMapper
+ ProcesoMapper
+ Sol i ci tanteMapper
+ Ti poDeProcesoMapper
+ Ti poMateri al Mapper
+ Turno_pequi _personas_PersonaFi si ca_mtmDomai nObj ectCol l ecti onRel ati on
+ TurnoMapper
(frompequi )
utils
+ caseStudy
+ excepti ons
+ hel pers
+ l og
+ persi stence
(fromframework)
caseStudy
+ NonPersi stenceBroker
+ Persi stenceBrokerFactory
+ Stri ngHel per
+ IKey
+ IPersi stenceBroker
(fromuti l s)
exceptions
+ Appl i cati onExcepti on
+ Busi nessLogi cExcepti on
+ ConcurrencyExcepti on
+ Expi redSessi onExcepti on
+ Inval i dSessi onExcepti on
(fromuti l s)
helpers
+ CesarEncri ptCryptographyHel per
+ Cl assHel per
+ ConvertHel per
+ IOHel per
+ NonEncri ptCryptographyHel per
+ PhpHel per
+ Seri al i zer
+ TypeHel per
+ Xml Hel per
+ ICryptographyHel per
(fromuti l s)
log
+ Consol eLog
+ Fi l eLog
+ Logger
+ ILog
(fromuti l s)
persistence
+ StorageMedi umExcepti on
+ IReaderStorageMedi um
+ IStorageMedi um
+ db
(fromuti l s)
db
+ BDatos
+ BDatosExcepti on
(frompersi stence)
pequi
+ cl i entes
+ ot
+ personas
(fromdtoEnti ti es)
ot
+ ComponenteDTO
+ EstadoDeOrdenDTO
+ Materi al DTO
+ NotaDTO
+ Observaci onDTO
+ ProcesoDTO
+ Sol i ci tanteDTO
+ Ti poDeProcesoDTO
+ TurnoDTO
(frompequi )
fwk
+ Context
+ Domai nObj ect
+ Domai nObj ectCol l ecti on
- Domai nObj ectCol l ecti onIterator
+ Domai nObjectCol l ecti onRel ati on
+ Identi tyMap
+ Key
+ KeyGenerator
+ Mapper
+ Persi stenceBroker
+ Regi stry
+ Uni tOfWork
+ IDomai nObject
+ IFi nder
+ IKeyGenerator
(frompersi stence)
remoting
+ cl i ent
+ server
(fromframework)
client
Servi ce
+ Servi ceFactory
(fromremoti ng)
server
(fromremoti ng)
xml
Finder
xml
Regsitry
xml
Modules
xml
Actions
xml
Presentation
Services
Application
Services
xml
Entites

Figura 14

Si se observa el cdigo de la parte especializada se nota que la misma es
repetitiva y que puede automatizarse.
Una opcin de automatizarla es mediante reflection, es decir que en tiempo
de ejecucin las clases del framework agreguen el comportamiento dado,
leyendo la informacin faltante desde archivos descriptores, y la otra opcin
es la de generacin de cdigo, es decir generar las clases necesarias que
especializan al framework en tiempo de desarrollo.
33
Cada uno tiene sus ventajas y desventajas, stas son analizadas en la
seccin Alternativa Reflection vs Generacin de Cdigo

34
Aspectos relacionados a las capas del
Framework

Seguridad Autenticacin y Autorizacin (Control de Acceso)

1) Autenticacin
2) Autorizacin
Autenticacin
Es el proceso por el cual se verifica que alguien (un sistema o un usuario) es
quien dice ser.
En el presente trabajo se implement utilizando un nombre de usuario y un
password, sistemas mas complejos pueden utilizar cualquier otro mtodo
para reconocer la identidad, como keys, smart cards, escaneo de retina,
huella digital, reconocimiento de voz, etc

Adems se puede limitar el acceso de acuerdo a la fecha, la direccin de
acceso, etc, para dificultar que el identificador se sesin pueda ser utilizado
por alguien no deseado que pueda obtenerlo sin autenticarse.

La Interfaz de Autenticacin se muestra en la Figura 15.

cd Control de Acceso
i nterface
caseStudy::IAccessControl
+ l ogi n( name, password) : Token
+ l ogout(Token) : voi d
+ checkVal i deSessi on(Token) : voi d
+ checkPermi ssi on(Context) : voi d

Figura 15

35
Autorizacin

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

Seguridad al nivel Servidor de Presentacin
El servidor de presentacin autentica a los usuarios al iniciar la aplicacin
para ya mantener su identificador de sesin en la sesin a lo largo de toda la
navegabilidad del sistema.

Cualquier aplicativo que desea autenticarse, consumir los servicios de
Control de Acceso, el mismo expone mtodos como logout(idSession), y,
login(name, pass) y checkSession(idSession) que no necesitan autenticacin,
De esta manera, cualquier aplicativo se autentica y obtiene un id de sesin
luego de hacer el login, y con l puede identificarse a lo largo de la sesin.

Como el punto de acceso a la capa de presentacin es el patrn
PageController, es decir a travs de los servlets PageController,
EntityController, por lo que cada peticin a una vista de la aplicacin pasa por
ellos, este es un buen lugar para verificar que quien la solicita este
autenticado. De no estarlo se redirige al sistema de Control de Acceso a que
se identifique.

El framework proporciona una implementacin a la interfaz IAcessControl,
pero la misma podria vincularse a cualquier frameworks, sistema de control
de acceso existente, o vincularlo con Active Directory por ejemplo.

Seguridad al nivel Servidor de Aplicaciones

En esta arquitectura basada en capas, la fachada de servicio es el punto de
acceso de los usuarios desde la capa de presentacin, por lo que es un buen
lugar para colocar la autenticacin.
Cada servicio, de esta fachada debe verificar que el usuario en el contexto
dado, este autenticado y luego verificar si posee privilegio de acceso a ese
servicio.
Para lograr esto, cada servicio toma por parmetro un objeto de la clase
Context, que posee un atributo que es un identificador de sesion. Dicho valor
se obtiene al autenticarse y debe ser mantenido durante toda la sesin, este
id de sesin tiene un tiempo de validez configurable, por ejemplo 30 minutos,
cada vez que el usuario accede a un servicio, este identificador actualiza su
fecha de ltimo acceso, de pasar el tiempo determinado en forma inactiva,
ese identificador de sesin se inactiva.
36
Al invocarse un servicio, se verifica que el id de sesin sea vlido sino es as,
se lanza una excepcin de InvalidSession o ExpiredSession. De ser vlida,
se pasa a verificar la autorizacin del mismo. Si no posee permiso se lanza
una excepcin de UnAuthorizedException en caso contrario se ejecuta el
servicio normalmente. En la Figura 16 se muestra la jerarqua de excepciones
mencionada.

cd Excepciones AccessControl
exceptions::BusinessLogicException
+ Busi nessLogi cExcepti on()
+ Busi nessLogi cExcepti on(Stri ng)
+ Busi nessLogi cExcepti on(Excepti on)
Exception
UnAuthorizedException
+ UnAuthori zedExcepti on()
+ UnAuthori zedExcepti on(Stri ng)
+ UnAuthori zedExcepti on(Excepti on)
InvalidSessionException
+ Inval i dSessi onExcepti on(Stri ng)
UnAuthenticatedException
+ UnAuthenti catedExcepti on()
+ UnAuthenti catedExcepti on(Stri ng)
+ UnAuthenti catedExcepti on(Excepti on)
ExpiredSessionException
+ Expi redSessi onExcepti on(Stri ng)

- i nnerExcepti on: Excepti on
Figura 16

Toda esta faceta de seguridad se agrega a la capa de servicio que es
expuesta. Si se trabaja en un mismo espacio fsico de memoria se debe
guardar el contexto en la sesin, y si se trabaja remotamente, el proxy cliente
generado, debera en cada invocacin tomar el contexto y enviarlo por
parmetro al proxy del lado servidor, donde este lo almacena en memoria o
sesin.
Luego cada mtodo de servicio debe verificar con la informacin del contexto
si est habilitado o no para ejecutar dicho servicio.
Otra opcin es la utilizacin de Aspect Programming para agregar estos
aspectos al comportamiento de la aplicacin.

37
Tambin podra utilizarse un Adapter que toma de sesin el contexto o lo
recibe en una instancia de Context, verifica la seguridad y delega la ejecucin
del servicio a la clase de servicio como muestra la Figura 17.

cd Control de Acceso
i nterface
caseStudy::IAccessControl
+ l ogi n(Stri ng, Stri ng) : Stri ng
+ l ogout(Stri ng) : voi d
+ checkVal i deSessi on(Stri ng) : voi d
+ checkPermi ssi on(Context) : voi d
DemoService
+ doServi ce(Obj ectDTO) : voi d
DemoServiceSecure
+ doServi ce(Obj ectDTO) : voi d
- doServi ce(Obj ectDTO, Context) : voi d
i nterface
IDemoService
+ doServi ce(ObjectDTO) : voi d
real i ze
real i ze

Figura 17
38
Concurrencia

La concurrencia al sistema se implement a partir del manejo de threads que
dispone el servidor web administrando servlets, mediante la generacin 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 deteccin de estos escenarios.
Para esto se balance la correccin de los datos y la responsibidad del
sistema. Se utiliz un patrn que detecta errores y genera avisos de que la
transaccin tuvo problemas y hay que rehacerla. El patrn utilizado es
Optimistic Lock.
Respecto de la transaccionalidad del sistema, la misma se implement
mediante la administracin de las transacciones de negocio por un patrn
llamado Unit of Work. El mismo lleva un registro de los objetos que
participaron en la transaccin y de que forma lo han hecho, y frente a un
comando commit, genera las acciones para mantener la consistencia entre
dichos objetos y los de la base de datos.

La sesin puede administrarse en
a) el cliente,
b) el servidor de aplicacin,
c) la base de datos,
d) la memoria del web server

Se opt por utilizar sesin en el web server para mantener informacin de
contexto vinculada a la seguridad, y si es necesario para vistas que necesiten
hacer uso de ella, pero no compartir sesin entre distintas capas.
Compartir sesin entre las capas, hace que sea difcil escalar la aplicacin
mediante el uso de mas servidores, ya que si comparten sesin dos
servidores, se genera un vnculo entre ellos, dificultando por ejemplo cambiar
una peticin (por balanceo de carga) a otro servidor de aplicaciones que se
encuentra con menor carga de procesamiento en un instante dado.
39
Auditoria

La auditora del sistema debera 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, podra loguearse que servicio y con que parmetros
utiliz cierto usuario, mas informacin adicional como fecha, hora, ubicacin
fsica, etc
Este es uno de los temas a futuro para continuar elaborando. Su esquema es
similar al de seguridad, ya que es un aspecto mas que se le agrega a la capa
de servicio.
Dotndo al framework con una aplicacin de auditora, un administrador del
sistema podra ver instantaneamente que operaciones esta haciendo cierto
usuario, que datos esta utilizando en dichas operaciones, ver un historial de
sus operaciones, horarios de acceso, etc. Podra permitirsele al administrador
inhabilitar a un Token, o limitar los privilegios de un usuario autenticado si ve
que esta haciendo mal uso de ellos.

40
Excepciones

Inicialmente se pueden clasificar las excepciones en dos grandes jerarquas,
una orientada a excepciones de negocio, es decir infracciones a reglas de
negocio, las cules deben ser informadas al usuario para que tome una
accin con respecto a ellas. A stas se las llama excepciones de negocio y
en la jerarqua de clases extienden a Exception generando una rama mas
especializada llamada BusinessLogicException, de la cul se irn
especializando las excepciones a reglas de negocio del dominio analizado.

La otra rama, es la de excepciones ocurridas por errores en runtime en la
aplicacin, como ser la indisponibilidad de la red, de la base de datos, etc.
Todos estos errores que pueden ocurrir en el transcurso del uso de la
aplicacin, se van a ubicar en la jerarqua de excepciones bajo
ApplicationException que tambin especializa a Exception.
Todas estas excepciones deben ser logueadas e informadas a un
administrator. Al usuario slo se le informar un mensaje amigable dicindole
que el sistema momentaneamente no puede resolver su peticin y que se
comunique con un administrador.

Dentro de las excepciones de negocio hay una particular que es
ConcurrencyException que ocurre cuando al intentar finalizar una
transaccin se detecta que los datos con los que se comenz la transaccin
han sido modificados por otra transaccin, por lo que para evitar los
problemas de concurrencia analizados (ver seccin de Concurrencia), se
lanza esta excepcin, la cual es informada al usuario, para que realice
nuevamente la operacin.

Y otras excepciones utilizadas en el framework son las vinculadas a la
seguridad InvalidSession, ExpiredSession y UnAuthorizedException, (ver
seccin de Autorizacin/Autenticacin)

Esta jerarqua de excepciones se muestra en la figura 18.

41
cd Excepciones
exceptions::ApplicationException
+ Appl i cati onExcepti on()
+ Appl i cati onExcepti on(Stri ng)
+ Appl i cati onExcepti on(Excepti on)
exceptions::BusinessLogicException
+ Busi nessLogi cExcepti on()
+ Busi nessLogi cExcepti on(Stri ng)
+ Busi nessLogi cExcepti on(Excepti on)
exceptions::ConcurrencyException
+ ConcurrencyExcepti on(Stri ng)
+ ConcurrencyExcepti on(Excepti on, Stri ng)
Toda excepci n produci da por fal l os en
l a apl i caci n que no se deban a regl as
de negoci o heredan de
Appl i cati onExcepti on
La capa de presentaci n puede vi sual i zar
un mensaj e genri co de error, pi di endo
al usuari o que se comuni que con el
servi ci o tcni co de l a apl i caci n.
Esta excepci n general mente es
l ogueada y se noti fi ca al admi ni strador.
Toda excepci n que ocurra
debi do a que no se cumpl e con
una regl a de negoci o hereda de
Busi nnessLogi cExcepti on y el
cl i ente (capa de presentaci n)
deci di r que hacer con el l a.
Normal mente l e i nforma al
usuari o vi sual i zando el mensaj e
de l a regl a de negoci o que no
se cumpl e.
ConcurrencyExcepti on es l a excepci n
que ocurre cuando se qui era actual i zar, o
borrar un obj eto cuya versi n no es l a
versi n con que el usuari o estuvo
trabaj ando, es deci r al gui en modi fi c
al gn obj eto i ntervi ni ente mi entras el l o
estaba usando.
Esto es por el uso de Opti mi sti cLock para
el manej o de concurrenci a.
Exception
UnAuthorizedException
+ UnAuthori zedExcepti on()
+ UnAuthori zedExcepti on(Stri ng)
+ UnAuthori zedExcepti on(Excepti on)
InvalidSessionException
+ Inval i dSessi onExcepti on(Stri ng)
UnAuthenticatedException
+ UnAuthenti catedExcepti on()
+ UnAuthenti catedExcepti on(Stri ng)
+ UnAuthenti catedExcepti on(Excepti on)
ExpiredSessionException
+ Expi redSessi onExcepti on(Stri ng)

Figura 18
42
Despliegue
El framework permite que la aplicacin sea desplegada fsicamente en un
nico servidor o en varios servidores. Esta propiedad permite separar
fisicamente la capa de presentacin de la capa de negocio (en un Servidor de
Presentacin y otro Servidor de Aplicaciones).
En estos casos, puede utilizarse un firewall para poner la limitacin de que
slo el Servidor de Presentacin tenga acceso al Servidor de Aplicaciones.

Del mismo modo, si se separa fsicamente la capa de persistencia de la capa
de datos (en un Servidor de Aplicaciones y otro Servidor de Datos) puede
limitarse con un firewall el acceso al Servidor de Datos y permitirle acceder
solo al Servidor de Aplicaciones.

Esta distribucin de las capas lgicas se muestra en la figura 19a.

dd Despliegue Logico
Servidor Web
Cliente
(Browser)
Servidor de
Aplicaciones
Servidor de Base de
Datos
Presentati on Layer
Servi ce Interface
Domai n Model
Layer
Persi stence Layer
Servi ce Layer
Servi ce Interface
Persi stence Interface
Data Source Layer
Proxy Proxy
Figura 19a

Una vez generadas las libreras (archivos .jar) que contienen los paquetes de
cada capa, los mismos se desplegarn fsicamente en cada servidor como se
indica en la Figura 19b. Como puede verse la librera common debe
desplegarse en ambos servidores, ya que contiene la interfaz entre ambas
capas.

43
dd Despliegue
Cliente
(Browser)
Servidor
Web
Servidor de
Aplicaciones
Servidor de
Base de Datos
l i brary
Componentes::Back.j ar
l i brary
Componentes::Front.war
l i brary
Componentes::Common.j ar
Componentes : Front
Componentes : Common
Componentes : Back
<< TCP / IP >>
<< HTTP >>

Figura 19b

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

cd Figuras Librerias Front
l i brary
front.war
j sp/html pages
web pages
presentation
+ fwk
(from framework)
fwk
+ Acti onServl et
+ Invoker
+ PageControl l er
(from presentati on)
remoting
+ cl i ent
+ server
(from framework)
client
Servi ce
+ Servi ceFactory
(from remoti ng)

Figura 19c
La librera common (common.jar) esta compuesta como se muestra en la
Figura 19d

44
cd Figuras Librerias Common
l i brary
common.j ar
iservice
+ IBaseServi ce
+ dtoEnti ti es
+ pequi
(from framework)
dtoEntities
+ CustomData
+ pequi
(from i servi ce)
pequi
+ cl i entes
+ ot
+ personas
(from i servi ce)
ot
+ INotaServi ce
+ IProcesoServi ce
+ ITurnoServi ce
(from pequi )
pequi
+ cl i entes
+ ot
+ personas
(from dtoEnti ti es)
ot
+ ComponenteDTO
+ EstadoDeOrdenDTO
+ Materi al DTO
+ NotaDTO
+ Observaci onDTO
+ ProcesoDTO
+ Sol i ci tanteDTO
+ Ti poDeProcesoDTO
+ TurnoDTO
(from pequi )
IServi ce representa el conj unto
de i nterfaces que i mpl ementa
cada cl ase de l a Capa de
Servi ci o y el conj unto de obj etos
DTO que exponen l as mi smas
como parmetros.
Este paquete se encuentra en l a
l i brera common.j ar que es
despl egada tanto en el Servi dor
de Presentaci n como en el
Servi dor de Apl i caci ones.
utils
+ caseStudy
+ excepti ons
+ hel pers
+ l og
+ persi stence
(from framework)
caseStudy
+ Stri ngHel per
+ IKey
(from uti l s)
exceptions
(from uti l s)
helpers
+ Cl assHel per
+ ConvertHel per
+ IOHel per
+ PhpHel per
+ Seri al i zer
+ TypeHel per
+ Xml Hel per
(from uti l s)
log
+ Consol eLog
+ Fi l eLog
+ Logger
+ ILog
(from uti l s)
persistence
+ IStorageMedi um
+ db
(from uti l s)
db
+ BDatos
+ BDatosExcepti on
(from persi stence)

Figura 19d
La librera back est compuesta como se muestra en la Figura 19e.
45
cd Figuras Librerias Back
l i brary
back.j ar
service
+ BaseServi ce
+ pequi
(from framework)
pequi
+ cl i entes
+ ot
+ personas
(from servi ce)
persistence
+ caseStudy
+ fwk
(from framework)
caseStudy
+ pequi
(from persi stence)
pequi
+ cl i entes
+ ot
+ personas
(from caseStudy)
ot
+ ComponenteMapper
+ EstadoDeOrdenMapper
+ EstadoDeProcesoMapper
+ Materi al Mapper
+ NotaMapper
+ Observaci onMapper
+ OrdenDeTrabaj o_pequi _ot_Materi al Domai nObj ectCol l ecti onRel ati on
+ OrdenDeTrabaj o_pequi _ot_Observaci on_mtmDomai nObj ectCol l ecti onRel ati on
+ OrdenDeTrabaj o_pequi _ot_ProcesoDomai nObj ectCol l ecti onRel ati on
+ OrdenDeTrabaj oMapper
+ ProcesoMapper
+ Sol i ci tanteMapper
+ Ti poDeProcesoMapper
+ Ti poMateri al Mapper
+ Turno_pequi _personas_PersonaFi si ca_mtmDomai nObj ectCol l ecti onRel ati on
+ TurnoMapper
(from pequi )
fwk
+ Context
+ Domai nObj ect
+ Domai nObj ectCol l ecti on
+ Domai nObjectCol l ecti onRel ati on
+ Identi tyMap
+ Key
+ KeyGenerator
+ Mapper
+ Persi stenceBroker
+ Regi stry
+ Uni tOfWork
+ IDomai nObject
+ IFi nder
+ IKeyGenerator
(from persi stence)
domainModel
+ fwk
(from framework)
fwk
+ pequi
(from domai nModel )
pequi
+ cl i entes
+ ot
+ personas
(from fwk)
ot
+ ComponenteFwk
+ EstadoDeOrdenFwk
+ EstadoDeProcesoFwk
+ Materi al Fwk
+ NotaFwk
+ Observaci onFwk
+ OrdenDeTrabaj oFwk
+ ProcesoFwk
+ Sol i ci tanteFwk
+ Ti poDeProcesoFwk
+ Ti poMateri al Fwk
+ TurnoFwk
(from pequi )
remoting
+ cl i ent
+ server
(from framework)
server
(from remoti ng)
ot
+ NotaServi ce
+ ProcesoServi ce
+ TurnoServi ce
(from pequi )

Figura 19e
46
Analizando los Patrones Utilizados

Se analizan los patrones utilizados en la implementacin de las distintas
capas de sta arquitectura. Y como se adaptaron a los mismos para que en
conjunto tengan el comportamiento esperado para el framework.

Identificacin

Buscando evitar la inconsistencia que a veces se produce con el uso de
datos del dominio como identificacin unvoca de los registros en una tabla (o
en el medio persistente), se selecciona el patrn Identity Field [Martin Fowler
2003] para poseer un mecanismo de identificacin de objetos.
Pero, como se respeta la restriccin de no modificar las clases de dominio, no
se agreg este atributo a estas clases de dominio como lo indica el patrn.
Por otro lado, la capa de persistencia necesita poder identificar a los objetos
de dominio en forma genrica, por lo que se necesita hacer uso del patrn
Domain Supertype [Martin Fowler 2003], cuya clase Domain Object
encapsula los mecanismos generales vinculados con la persistencia y la
administracin de la identificacin de los objetos.
Sin embargo esta solucin como se analiz anteriormente tambin modifica a
las clases del dominio. Para romper con esta dependencia se recurri al uso
del patrn de diseo Adapter [Gamma et al, 1995].
Un diagrama de clases se muestra en la Figura 20. Donde se genera una
nueva clase DomainObjectAdaptada o DomainObjectFwk que extiende a
la clase de dominio que no podemos modificar y agrega el comportamiento
faltante a travs de la clase DomainObject, a quien le delega dichas tareas
para no repetir este comportamiento cada vez.
cd Data Model

Figura 20

Sin embargo este patrn no alcanza a resolver completamente el problema
ya que los objetos instancias de las clases del dominio al ser manipuladas en
la Capa de Persistencia, deben ser de un tipo genrico para poder trabajar a
47
nivel abstracto sin necesitad de conocer con que objeto de dominio se trabaja
concretamente.
Esto es as ya que lo requiere funcionalidad asociada con la capa de
Persistencia.
Por esta razn fue introducida la interfaz IDomainObject la cal es
implementada por cada ClaseDominioAdaptada.
El patrn finalmente fue implementado como muestra la Figura 21.

Service Layer
ClaseDominio
i nterface
IDomainObject
real i ze
real i ze

Figura 21

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

En el framework desarrollado se us este patrn para cumplir con el
requerimiento impuesto de que el modelo del dominio no sea alterado, es
decir no tenga dependencias de la capa de persistencia. El mismo es una
adaptacin del DomainSupertype Su utilizacin en el framework puede
verse en las clases IDomainObject, DomainObject y las clases generadas a
partir de las clases de dominio.
48
Consideraciones importantes realizadas sobre el Identity Field:

Clave simple o compuesta (relacin con Foreign Key y con
Compound Key, [Martin Fowler, 2003]. Una clave simple hace uso de
un solo campo en la base de datos y un solo atributo en el objeto
asociado, mientras que una clave compuesta usa mas de uno.
Una clave compuesta es de utilidad ya que contiene mayor informacin
en determinados contextos, sin embargo, dificulta la generalizacin al
momento de generar cdigo para su administracin.

Se decidi utilizar una clave simple.

Tipo de dato asociado. El uso de variables de tipo numricas facilita la
manipulacin al momento de su comparacin e incremento.

Se decidi utilizar una clave numrica.

Identificador nico por base de datos o por tabla (relacin con Identity
Map y con los patrones de mapeo de jerarquas de herencia a tablas
relacionales). La clave puede ser administrada para cada tabla o para
toda la base de datos. El uso de la ltima est directamente
relacionado con la utilizacin de un nico Identity Map para toda la
base de datos. Esta estrategia est tambin vinculada con la
seleccionada para el mapeo de jerarquas de herencia a las tablas. Es
ms simple la utilizacin de claves por jerarquas que claves por tabla
cuando se usan los patrones Concrete Table Inheritance y Class
Table Inheritance. Los patrones mencionados sern tratados ms
adelante en este documento.

Se decidi utilizar una clave nica por base de datos.

Ubicacin, en el objeto, de la administracin de este recurso (relacin
con Domain Object, tratado ms adelante en este documento). Un
lugar apropiado para la administracin de este recurso, si seleccionan
las estrategias que permitan escribir cdigo genrico, es la clase
Domain Object, raz de la jerarqua del modelo de negocio.

Se decidi agregarla en la clase DomainObjectAdaptada

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

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

En el framework desarrollado se utiliz una clave numrica y simple. Para la
implementacin se utiliz una tabla propia para la administracin de las
claves y una clave nica para toda la base de datos. Esto ltimo debido al
uso del patrn Class Table Inherence para el mapeo de las jerarquas de
herencia. Este anlisis se puede ver en la seccin donde se presenta dicho
patrn. Se puede ver su implementacin en el file Key.java y Bdatos.java
de los paquetes framework\persistence\fwk y
framework\utils\persistence\db.

Patrones relacionados
De las consideraciones realizadas en la seccin anterior se desprende que
los patrones relacionados son los que se muestran en la Figura 22.
Identity Field
Identity Map
Foreign Key
Single Table
Inheritance
Class Table
Inheritance
Concrete Table
Inheritance
Compound
Key
Si mpl e o Compuesta
Uni ca por base o cl ase
Uni ca por base o cl ase o
j erarqui a de cl ases
Uni ca por base o cl ase
o j erarqua de cl ases
Uni co por base o cl ase, Si mpl e o Compuesto

Figura 22
50
Asociaciones

Se utilizaron los patrones Foreign Key Mapping, Association Table
Mapping [Martin Fowler, 2003] para mantener las relaciones entre objetos.

Se plantean problemas diferentes, dependiendo de las diferentes relaciones
de agregacin entre objetos:

Relacin uno a uno.
Relacin de uno a muchos.
Relacin de muchos a muchos.

Este problema se plantea por la forma diferente de relacionar objetos y
tablas entre s. Los objetos se relacionan a partir de referencias (direcciones
de memoria) y los registros de las tablas de la base de datos a partir de
claves. Adems, los objetos pueden mantener colecciones de relaciones
desde una nica instancia mientras que las tablas en forma normal
mantienen relaciones nicas. Para la resolucin de estos problemas se utiliza
el patrn ya introducido (Identity Field), para mapear las relaciones entre
referencias entre objetos y claves entre tablas. Este patrn es conocido
como Foreign Key Mapping. Cuando las relaciones son de muchos a
muchos el problema se resuelve utilizando el patrn Association Table
Mapping.

En el caso de la asociacin uno a uno, se aade el uso del patrn 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 patrn Value List
Holder.
Del mismo modo en los getters de las collecciones correspondientes a
relaciones mltiples, se accede a travs de las clases
DomainObjectAdaptadas a stas collecciones, que a medida que las mismas
son iteradas, van cargando de a N instancias, debido a que en su iterador
manejan la carga tarda.

En el framework desarrollado se us el patrn Foreign Key Mapping para
las relaciones de tipo agregaciones uno a uno. Esto fue implementado
usando un campo adicional en los registros de la tabla que representa la
clase que posee la relacin. Para las relaciones uno a muchos y muchos a
muchos se utiliz en el modelo de objetos una coleccin
DomainObjectCollectionRelation derivada de Collection del API de Java.
En la base de datos se genera una tabla de relaciones en ambos casos. En el
caso de uno a muchos, una de las columnas repetir sus valores para el
objeto nico, en el caso muchos a muchos se tienen valores que identifican
51
cada instancia del conjunto relacionado. Esta tabla se construye con el
nombre de ambas clases relacionadas.
La coleccin asociada tiene capacidad de administrar la consistencia entre
las instancias en memoria y los registros correspondientes en la base de
datos. Es decir, distinguir las nuevas instancias de las ya persistidas y
eliminadas (refirindose siempre a las referencias de las instancias que
participan de la relacin). En todos los casos se administra la carga tarda de
las instancias utilizando el patrn LazyLoad, solo cargando las claves de las
instancias que participan de las relaciones, esto puede verse en la
redefinicin de los getters y setters de las DomainModelAdaptadas
(DomainModelFwk). Se puede ver su implementacin en el file
DomainObjectCollectionRelation.java y ClaseDominioFwk.java de los
paquetes framework\persistence\fwk y framework\domainmodel\fwk..

Patrones relacionados a esta eleccin
De las consideraciones realizadas en la seccin anterior se desprende que
los patrones relacionados son los que se muestran en la Figura 23.

cd Data Model
ForeignKey
IdentityField
LazyLoad

Figura 23
52
Mapeos de objetos a tablas

Se utiliz el patrn de Class Table Inheritance para el mapeo de jerarquas
de objetos en la base de datos relacional.

De las tres alternativas de implementacin del mismo:

Single Table Inheritance
Class Table Inheritance
Concrete Table Inheritance

Se seleccion la de Class Table Inheritance como mapeo por defecto para el
generador de cdigo (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 analoga entre una clase
y una tabla.

En el framework desarrollado se us el patrn ClassTableInheritance. Se
puede ver su implementacin en el file AbstractMapper.java y en el mapper
concreto de cada clase de dominio que participe de una jerarqua de
herencia, cuyo cdigo es parte del cdigo generado. Los paquetes que
contienen estos files son framework\persistence\fwk y
framework\persistence\casestudy.

En la Figura 24 se muestran los patrones relacionados con los vistos en este
apartado.
53
Identity Field
Identity Map
Single Table
Inheritance
Class Table
Inheritance
Concrete Table
Inheritance
Inheritance
Mapper
Compound
Key
Uni ca por base o por
tabl a
Uni ca por base o tabl a o
j erarqui a de cl ases Uni ca por base o tabl a o
j erarqua de cl ases
Uni co por base o tabl a, Si mpl e o Compuesto
Uni co?

Figura 24

54
Consistencia

Se garantiza la consistencia entre objetos cargados de la base de datos.
Si se carga desde la base de datos dos veces la misma fila de una tabla y se
instancian a partir de ella dos objetos, los mismos son dos instancias de una
misma entidad. Operar sobre ambas sin control lleva a inconsistencias. Se
debe asegurar una sola instancia de cada objeto a efectos de evitar
inconsistencias al cambiarlo. Este problema se resuelve aplicando el patrn
Identity Map, ste mantiene referencias a los objetos cargados y devuelve
las mismas cada vez que se solicita un objeto ya cargado. De esta forma
acta como un cache dentro de la transaccin, lo cual tambin contribuye a
reducir el nmero de accesos a la base de datos.

Al momento de implementar este patrn se tuvieron en cuenta las siguientes
cuestiones:

Eleccin del tipo de clave a usar: esta eleccin impacta directamente
en la implementacin del Map. Una clave simple facilita la
implementacin ya que se usa esta misma como clave del Map.

Identity Map explicito o genrico: un Map explcito implica el uso de
distintos mtodos para realizar las bsquedas findObjetoTipoA(key),
uno para cada tipo de objeto. En uno genrico se realiza con uno nico
find(ObjetoTipoA, key). Esta eleccin esta vinculada con la anterior
ya que se puede implementar un Map genrico si tambin usamos el
mismo tipo de clave para todos los objetos. Y si la clave es nica para
toda la base de datos, directamente find( key )

Cuntos utilizar: en cada sesin se puede usar un Map por clase o uno
nico. Otra vez uno nico implica que se ha seleccionado el mismo
tipo de clave para todos los objetos. Esta seleccin facilita las
bsquedas ya que solo hay que realizarlas en un nico lugar. Cuando
existen jerarquas de herencia es ms fcil la administracin de un
Map nico, pero esto implica el uso de claves nicas para la jerarqua
de clases.

Dnde ubicarlos: el compromiso aqu es la existencia de una nica
instancia por sesin y el uso fcil del mismo. Es decir que se debe
ubicar sobre un objeto de sesin. Los lugares indicados si se estn
utilizando son el Unit of Work o el Registry. Otro lugar apropiado es
vincularlos a los Mappers.

En la Figura 25 se muestra un diagrama de secuencia con la dinmica de
este patrn.

55
fi nder Identi ty Map base de
datos
Al gun Obj eto
fi nd(1)
found = get(1)
[found i s nul l ] found = sel ect where i d = 1
[found not nul l ] found
Figura 25

En el framework desarrollado se us uno nico IdentityMap para todas las
clases, esto es consistente con la seleccin de una nica IdentityField por
base de datos. Este IdentityMap se ubic la UnitOfWork como se ver en la
seccin donde se describe este patrn. Se puede ver su implementacin en
el file IdentityMap.java del paquete framework\persistence\fwk.
56
En la Figura 26 se muestran los patrones relacionados descriptos en el
anlisis anterior.
Identity Field
Identity Map
Concrete Table
Inheritance
Data Mapper
(Cuantos ???)
Compound
Key
Optimistic
Offline
Unit of Work
Registry
Uni ca por base o tabl a o
j erarqui a de cl ases
Donde ?
Uni co por base o tabl a, Si mpl e o Compuesto
Cl ave compuesta ?
Uni co?
Donde ?
Figura 26
57
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 patrn Unit of Work. [Martin Fowler, 2003]

Solucin
Al gun
Obj eto
Cl i ente base de
datos
Uni t of Work
new
sel ect
regi stryCl ean
setDato
regi stryDi rty
commi t
save
update

Figura 27

En la Figura 27 se muestra la dinmica del patrn en la administracin de las
instancias de los objetos en sus diferentes estados. En la Figura 28 se
muestra una posible disposicin de clases formando parte de este patrn.
58

Session
UnitOfWork
NewObj ects DirtyObj ects
DeletedObj ects

Figura 28

Consideraciones importantes realizadas sobre el Unit Of Work:

Ubicacin, la Unit of Work puede estar en la sesin, puede pasarse
como parmetro entre los objetos que la usan, o puede localizarse en
la Registry. En este caso se opt de ponerlo en la Registry, la cual
garantiza ser nica por thread y facilita el acceso de la misma.

En el framework desarrollado se incluy el mecanismo para administrar la
consistencia de las relaciones entre objetos en memoria y las relaciones
persistidas, de manera similar a lo que se hace en el caso de instancias de
objetos. Para esto se agreg un coleccin que mantiene la lista de
DomainObjectCollectionRelation que se modificaron. Cuando el mtodo
commit() de la UnitOfWork es invocado, adems de operar sobre las
instancias de los objetos que participaron de la transaccin, se hace lo propio
sobre las relaciones entre los mismos. Se puede ver su implementacin en el
file UnitOfWork.java del paquete framework\persistence\fwk.
59

En la Figura 29 se muestran los patrones relacionados a este. Las relaciones
estn vinculadas a dnde ubicar al Unit Of Work.

O p ti m i s ti c
O ffl i n e
U n i t o f W o r k
P e s s i m i s ti c
O ffl i n e
R e g i s tr y
S e s s i o n
S e r v l e t (d o G e t) F r o n t
C o n tr o l l e r
(F r o n t
C o m m a n d )
D o n d e ?
D o n d e ?

Figura 29

60
Acceso a Servicios Comunes

Al existir un nmero grande de clases, de las cuales muchas de ellas hacen
uso de determinados servicios comunes se implement el patrn Registry al
cual se accede para obtener determinados servicios, por ejemplo obtener un
finder.

Los patrones relacionados son los que se muestran en el diagrama de clases
de la Figura 30.

cd Data Model
Registry
Mapper
UnitOfWork Finder
IdentityMap
DomainClass
DomainTable
real i ze

Figura 30

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

61
Acceso a los Datos Persistentes

Entre Table Data Gateway, Row Data Gateway, Active Record, Data
Mapper se seleccion al Data Mapper para acceso a los datos, ya que es el
mas adecuado para trabajar con Domain Model.

Es la solucin ms elaborada pero que permite aislar por completo al modelo
del dominio del de persistencia es el Data Mapper, con el cual se logra que
ambas capas (Negocio y Persistencia) evolucionen en forma independiente.
En las figuras que siguen se muestran diagramas conceptuales y de clases,
marcando las diferencias de estos patrones.

Diagrama conceptual del Data Mapper.
:ClaseDominio
:Mapper Tabl e
:ClaseDominioTabla

Figura 31

Diagrama de clases del Data Mapper.
Mapper
+ i nsert(Domai nObject) : voi d
+ update(DomainObj ect) : void
+ del ete(Domai nObj ect) : voi d
+* save(ID, DomainObject) : voi d
+* l oad(ID, DomainObject) : void
AbstractMapperJerarquia
+* save() : void
+* l oad() : void
MapperRootJerarquia
+ fi nd(ID) : RootJerarqui a
+ i nsert() : voi d
+ update() : voi d
MapperClaseConcreta1
+ fi nd(ID) : Cl aseConcreta1
+* save() : voi d
+* l oad() : voi d
MapperClaseConcreta2
+* save() : void
+* l oad() : void
+ find(ID) : Cl aseConcreta2

Figura 32

En los casos de relaciones simples, como se muestra en la figura de abajo,
la jerarqua de Mappers est constituida por una clase abstracta cuya
responsabilidad es definir el protocolo de uso de los mappers y el
62
mecanismo genrico de persistencia. El mapper concreto, para cada clase
cuyas instancias son persistentes, especializa a esta y es la que administra la
carga de datos desde y hacia la base de datos. O sea que hay un mapper
concreto por clase de dominio. Cuando aparecen relaciones de herencia
entre las clases de dominio y estas deben ser persistidas, una solucin es
dar de alta un nuevo mapper. Sin embargo en estos casos, este nuevo
mapper estar duplicando cdigo a efectos de administrar la parte de su
clase base. Una solucin ms conveniente es establecer alguna relacin
entre los mappers, que refleje la existente entre las clases que ellos mapean.
Esta relacin puede verse en la Figura 33. De esta forma cada mapper
heredar de otro y cada uno administrar la parte de la clase mapeada. En el
caso de existir una parte base, dejar al mapper correspondiente realizar lo
propio.

cd Mappers
AbstractMapper
ConcreteMapper
ConcreteClass
ConcretClassDerivada
ConcreteClassDerivadaMapper
ConcreteClassDerivadaMapper2
DomainObj ect

Figura 33

En los casos en que desde la capa de servicios se quiera obtener instancias
persistidas de un tipo superior en su jerarqua de herencia, se debe contar
con la posibilidad de obtener objetos de distintos tipos dentro de la jerarqua
nombrada. Por ejemplo, en la figura, obtener un conjunto de objetos de tipo
C. En este caso debern cargarse todos los objetos C y tambin los B,
ya que estos tambin son de tipo C. Esto es implementado como se
muestra en la Figura 34 a partir de un nuevo mapper que tiene el
conocimiento de todos los mappers concretos de dicha jerarqua y por lo
tanto delega a cada uno de estos la administracin de los datos de los tipos
concretos detectando estos tipos. Esto es posible a partir de la obtencin del
tipo concreto que es un atributo ms de las clases del framework.

63
cd Mappers
P
F C
B
AbstractMapper
PMapper
AbstractPM
CMapper
BMapper
FMapper
DomainObj ect

Figura 34

Como se describi anteriormente, en el presente trabajo se defini como
requerimiento no tener que modificar las clases del modelo de dominio a la
hora de utilizar el framework. Por esta razn se debi implementar los
mappers de una forma diferente. Segn se analiz, las clases persistentes
Fwk no tienen entre ellas una relacin de herencia, por esta razn los
mappers tampoco tienen una relacin de herencia entre s. Segn esto, no es
posible realizar un upcast de un BFwk a un CFwk. Tampoco es una solucin
realizar un upcast hacia C, ya que los objetos de la clase C de dominio, no
tienen la informacin necesaria para hacerlos persistentes (por ejemplo el Id
de las agregaciones).
La implementacin que se le dio se muestra en la Figura 35, donde se
observa la existencia de un mapper por clase persistente de dominio. Esta
solucin implic la repeticin de cdigo a nivel de algunos mappers, precio
que se paga por el fuerte requerimiento mencionado de la no modificacin de
las clases de dominio. Esta repeticin puede evitarse a partir de la extraccin
en un mdulos comunes.

cd Mappers
AbstractMapper
PMapper
CMapper
BMapper
FMapper
i nterface
IFinder
P
F C
B
i nterface
IDomainObject
PFwk
CFwk
BFwk

Figura 35

El manejo de objetos instancias de clases de un nivel superior, que en el
patrn lo administraba un mapper adicional (PM), en nuestro framework es
64
administrado en forma genrica por la clase AbstractMapper. Un ejemplo de
este manejo puede verse en la Figura 36.

sd NuestroMapper
Servi ceLayer
PersistenceBroker ClassNameMapper Registry
Type es el Cl assName correspondi ente a
una cl ase concreta
Cl assNameMapper.fi nd(Key key)
{
// veri fi ca si ya esta en el Identi tyMap
IDomai nObj ect resul t = Uni tOfWork.getCurrent().getDomai nObj ect(i d);
i f (resul t!=nul l ) return resul t;
// si no que el mapper concreto cree el domai n obj ect concreto
resul t = Regi stry.getInstance().getMapper(i d.getType()).CreateDomai nOj ect();
resul t.setFwk_Id(i d);
// que el mapper concreto l o cargue
Regi stry.getInstance().getMapper(i d.getType()).Load(resul t);
// se i ndi ca que el domai n Obj ect ya esta persi sti do, pues se traj o de l a DB.
resul t.setFwk_IsPersi sted(true);
// se agrega al i denti tyMap de l a Uni tOfWork
Uni tOfWork.getCurrent().addDomai nObj ect(resul t);
return resul t;
}
fi nd(Cl assName, i d)
getMapper(Cl assName)
new
fi nd(Cl assName, i d)
Type:= getType(Cl assName, i d)
Key:= newKey(Type, i d)
fi nd(Key)
Obj ect

Figura 36

Se puede ver su implementacin en el file AbstractMapper.java del paquete
framework\persistence\fwk, y en los archivos generados para cada mapper
de cada clase de dominio persistente, incluidas en el paquete
framework\persistence\caseStudy.
65
Los patrones relacionados pueden verse en la Figura 37
Identity Map
Data Mapper
(Cuantos ???)
Registry
Uni co por Base de
Datos
o por tabl a
Domain Obj ect
Donde ?
Conoce ?

Figura 37

66
Carga Tarda de Objetos

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

Se muestra en la Figura 38 la dinmica del patrn.
Cl i ente base de
datos
Al gun
Obj eto
getOrdenes
[ordenes no cargadas]
cargarOrdenes
retornarOrdenes

Figura 38

Hay diferentes formas de implementar este patrn [Martin Fowler, 2003]

Lazy Initialization: este es la implementacin ms simple. Consiste en
implementar la lgica de carga de los objetos relacionados en los mtodos de
acceso a los mismos. De esta forma se demora la carga real hasta el
momento en que es accedido por primera vez. La desventaja de esto es que
hay conocimiento de esta carga dentro del objeto del dominio.

67
Class DO1 ...
{
private DO2 do2;

public DO2 getDO2(){

if( do2 != null){

do2 = DO2.find(this.id);
}
return do2;
}
}

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

cd lazyLoad
DomainObj ect1 List
VirtualList
i nterface
VirtualListLoader
MapperDomainObj ect1
DomainObj ect2Loader

Figura 39

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

68
En el framework desarrollado se us Lazy Initialization para las relaciones
de agregacin. Se puede ver su implementacin en cualquiera de los
mtodos de acceso a agregaciones en el file DomainObjectFwk.java
correspondiente del paquete framework\domainModel\fwk. Adems debido
a las restricciones impuestas a la arquitectura del framework, relacionada con
el aislamiento del modelo de dominio, se implement este patrn de la forma
que se muestra ms abajo.

cd LazyLoadFwk
DomainObj ect1
DomainObj ect2
DomainObj ect1Fwk
DomainObj ect2Fwk
i nterface
DomainObject2Finder
Figura 40

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

69
En el framework desarrollado se us la solucin descripta para la carga
demorada de las colecciones. Pude verse a esta como una variante de un
Virtual Proxy con un Lazy Inicialization, ya que el Virtual Proxy carga a
todos los objetos de la lista mientras que en esta implementacin se cargan a
demanda, de a N elementos. De esta forma se evita el fenmeno ripple
loading [Martin Fowler, 2003] Esta implementacin pude verse en el file
DomainObjectCollectionRelation.java correspondiente del paquete

En la Figura 41 pueden verse los patrones relacionados.

cd LazyLoadFwk
Lazy
Inicialization
Adapter Domain
Supertype
ai sl ar capa de persi stenci a

Figura 41
70
Control de Concurrencia

Se busca la consistencia entre objetos alterados y las tablas que le dan
persistencia en la base de datos. La dinmica de una aplicacin enterprise
implica la modificacin de objetos ledos desde la base de datos. Cuando
existen transacciones en las cuales se modifican objetos, es indispensable
mantener la consistencia de los objetos en memoria, sobre los que se opera,
y los datos correspondientes en la base de datos. Es necesario asegurarse
que ningn otro proceso no modific las tablas asociadas despus de la
lectura, ya que si desde la transaccin en curso se guardan cambios
realizados en ella, se estara perdiendo el cambio realizado por el otro
proceso. Este problema de concurrencia se resuelve con los patrones de tipo
Lock. [Martin Fowler, 2003]

Las soluciones a este problema son dos y su efecto es bien distinto sobre el
resultado final.

Optimistic offline lock: resuelve el problema asociando un nmero de
versin con cada registro de la base de datos. La accin de lock
consiste en la comparacin entre, el valor ledo y mantenido en la
sesin, con el ledo al momento de hacer commit. Si coinciden hay
consistencia, nadie alter ese registro desde la ultima lectura, as que
se realiza el update y se incrementa el numero de versin. Sino, un
aviso de falla se genera y hay que comenzar nuevamente con la
transaccin. En la Figura 25 se muestra esta dinmica. Este patrn es
usado cuando la posibilidad de sesiones concurrentes sobre los
mismos datos tiene una baja probabilidad.

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

71
Sesi n A base de
datos
Sesi n B
rol l back
<------
System
Transacti on
Boundary
<-------
<--------
Busi ness
Transacti on
Boundary
<---------
getObj eto(129)
retornaObj eto(129)
edi taObj eto
getObj eto(129)
retornaObj eto(129)
edi taObj eto
updateObj eto(129)
updateObj eto(129)
fal l aObj etoVersi n

Figura 42
72

Sesi n A base de
datos
Sesi n B
-------->
Lock
Busi ness
Transacti on
Boundary
UnLock
--------->
getObj eto(120)
retornaObj eto(129)
getObj eto(129)
errorObj etoLocked
edi taObj eto

Figura 43

En el framework desarrollado se us la variante Optimistic offline lock. Dicha
implementacin consta del versionado de los DomainObject y el control de la
versin al momento del cierre de cada una de las transacciones del negocio.
Si alguno de los objetos afectados dentro de dicha transaccin no
corresponde a la versin persistida, se genera una excepcin de
concurrencia.
Se puede ver su implementacin en el file AbstractMapper.java del paquete
73

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

cd LazyLoadFwk
OptimisticOfflineLock
Mapper
LayerSupertype
control ada
versi onado en

Figura 44
74

Modelado del Dominio del Problema

Estos son algunos de los patrones vinculados al modelado del dominio del
problema y la lgica del negocio:, Transaction Script, Table Module,
Domain Model, Layer Supertype. [Martin Fowler, 2003]

El dominio del problema puede modelarse segn una perspectiva funcional
usando como base las acciones generadas en el cliente. Esta es una visin
enteramente funcional y consiste en un modelo transaccional. Este modelo es
adecuado en casos donde el dominio y la lgica del negocio son simples. En
estos casos Transaction Script es un patrn que puede utilizarse. Cuando el
dominio del problema y las reglas del negocio no son simples, este modelo
conduce a paquetes de funciones sin ninguna estructura cohesiva. En estos
casos es ms adecuado modelar utilizando el concepto de objetos y la
colaboracin entre ellos a efectos de lograr la funcionalidad requerida. Estos
son los casos donde utilizamos Domain Model. Entre las ventajas de estos
modelos se encuentran la posibilidad de obtener cdigo clausurado ante
cambios, lo que facilita la extensin de los modelos, su re uso y
mantenimiento de forma ms eficiente. Sin embargo, la mayor parte de las
aplicaciones usarn tecnologa de base de datos relacionales, lo cual
impondr mayor trabajo a efectos de vincular a estos modelos con su
persistencia, ver Table Data Gateway, Active Record, Data Mapper. Un
modelo intermedio entre los dos anteriores es Table Module, el cual se basa
en la organizacin del modelo en entidades asociadas con las tablas de la
base de datos ms que en paquetes o grupos de transacciones.

Solucin

En el framework desarrollado se us un modelo de objetos para modelar el
dominio, por lo cual se opt por el patrn Domain Model. Puede verse su
implementacin en los archivos .java del paquete framework\domainModel\
caseStudy.


75
Acceso a la Capa de Negocio

Service Layer, Remote Facade, Data Transfer Object. [Martin Fowler, 2003]
[Marinescu, 2002]

Como vimos es importante desacoplar la capa del dominio del problema y
negocio de la capa de aplicacin por distintas razones. Entre ellas se pueden
mencionar:

Problemas en la administracin de la concurrencia a partir de
transacciones de larga duracin en el tiempo.
Problemas en la eficiencia de las conexiones de red debido a
multiples accesos para concretar cada transaccin.
Alto acoplamiento entre la capa de aplicacin y de negocio, lo que
implica mnimo re uso.

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

Cl i ente Domai nObj ect
getAtri buto1
getAtri buto2
getAtri buto3
getAtri buto4
getAtri buto5

Figura 45

76
Cliente1
Cliente2
Cliente3
Regl a1
Regl a2
Regl a3
Obj ect1
Obj ect3
Obj ect2
Obj ect4
Obj ect5
Figura 46

Solucin

Transformacin de tipos de datos al cliente a efectos de lograr un
manejo mas apropiado con tipos usados en el cliente (ej.: string) y no
objetos y sus atributos.
Reduccin de la granularidad del acceso, a las capas mencionadas,
al nivel de la funcionalidad especificada en los casos de uso. Esto se
traduce en:
o Mejora de la concurrencia a partir de transacciones de menor
duracin en el tiempo.
o Mejora de la eficiencia en conexiones de red a travs del
acceso a las capas del negocio con un menor nivel de
granularidad. Esto se traduce en un menor numero de
invocaciones remotas.

Introduccin del control de transacciones y seguridad.
Reuso de reglas de negocio a partir del desacoplo de la capa de
aplicacin (presentacin).
77
Prueba del dominio del problema y negocio en forma separada de la
capa de aplicacin.

En la Figura 47 se muestra la introduccin de una capa de desacoplamiento
entre la de negocio y la de aplicacin. Adems los requerimientos contra esta
capa (Service Layer) devuelven objetos que el cliente administra de mejor
forma debido a la transformacin de datos implcita realizada en el Data
Transfer Object. En la Figura 48 se muestra el acceso a la capa de negocio a
travs del uso de una capa de aservicios de aplicacin (Service Layer). Es
importante destacar que en la capa de servicios de aplicacin (Service Layer)
se implementan clases que modelan directamente la dinmica de los casos
de uso del sistema.

Cl i ente DataTransferObj ect Servi ceLayer
getDataTransferObj ect
getAtri buto1
getAtri buto2
getAtri buto3
getAtri buto4
getAtri buto5

Figura 47

78
Cliente1
Cliente2
Cliente3
Regl a1
Regl a2
Regl a3
Obj ect1
Obj ect3
Obj ect2
Obj ect4
Obj ect5
Serv iceLayer

Figura 48

En el framework desarrollado se utiliz el patrn Service Layer que utiliza
los objetos del modelo del dominio para resolver los casos de uso de la
aplicacin. Se puede ver su implementacin en los archivos
IBaseService.java y BaseService.java del paquete framework\iservice
y framework\service.
Con este patrn se utiliz el patrn relacionado DataTransferObject para
independizar completamente la capa de presentacin de la del dominio.
Tambin con el objetivo de facilitar el transporte de informacin entre las
capas mencionadas, agrupando los datos necesarios de presentacin que
se encuentran en atributos de varios objetos del dominio, tambin la
conversin del formato de los datos mencionados. En los casos en que la
aplicacin sea instalada en varias capas fsicas, la capa de servicio es
usada en modo remoto, convirtindose en un Remote Facade, segn se
explic en la seccin Arquitectura Elegida (Capa de servicio).

79

Presentacin

Application Controller, Front Controller, Page Controller, Model View
Controller, Template View.

Dados los problemas en el diseo de la capa de aplicacin y su lgica, el
diseo de la administracin de la navegacin y el flujo de la aplicacin se
busca obtener la separacin de incumbencias en mdulos de presentacin,
lgica de aplicacin y lgica de negocio a invocar a partir de esta capa.

En el framework desarrollado se us un servlet de java como patrn Page
Controller para la obtencin de vistas. Se puede ver su implementacin en el
file PageController.java del paquete framework\presentation\fwk.

La implementacin de este Page Controller se muestra en la Figura 49.

od Custom
<html Page>
CustomPages
<xml >
Modules
PageController
+ doGet(vi ew :stri ng, modul e :stri ng) : html Page
Browser
pathFsi co

- footer: stri ng
- header: stri ng
Figura 49

En Modules se encuentra la informacin asociada a las vistas desarrolladas
en forma manual para la aplicacin y la estructura estndar de todas las
vistas. Estas vistas al ser direccionadas por el Page Controller son cargadas
y procesadas segn la informacin de Modules.xml y retornadas al cliente.

En toda aplicacin hay vistas con funcionalidad bien determinadas, por
ejemplo las orientadas a realizar alta, modificacin, seleccin y
administracin de datos. Por esta razn y a efectos de facilitar el desarrollo y
reuso de las mismas se utiliz un patrn denominado Entity Controller, como
se muestra en la Figura 50.

80
cd Custom2
<xml >
Entity
EntityController
+ doGet(useCase :stri ng, enti ty :stri ng) : html Page
Browser
<html >
UsecaseTempl ate

- fi el ds: Li st
Figura 50

En el framework desarrollado, las solicitudes de servicios al modelo de
dominio se implement de la siguiente manera. Una vez cargada una vista,
se invocan los servicios mencionados a travs del patrn Active Front o
AJAX. El mismo se muestra en la figura que sigue. Se puede ver su
implementacin en el file Invoker.java del paquete
framework\presentation\fwk. El mismo se representa en la Figura 51 y se
describe a continuacin.

o
n
o
n
A
L

V
e
r
s
i
o
n
A
L

V
e
r
s
i
o
n
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
E
A

3
.
5
1

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
E
A

3
.
5
1

U
n
r
e
g
i
s
t
E
A

3
.
5
1

-

U
n
r
e
g
i
E
A

3
.
5
1

E
A

3
.
5
E
A

3
.
5
1
DATOS
Vista
tabl a check
combo
Acci n A Acci n B
Servidor
Control
Actual i za l os datos

s
1
Figura 51

Esta implementacin puede verse como una variante del patrn MVC
aplicado a aplicaciones de tipo Web o como un patrn en s mismo.
Dado que el procesamiento de datos lo realiza el servidor en una capa de
servicio y el cliente solo visualiza y captura datos que enva al servidor para
que procese se busca evitar la recarga de una vista o pgina anteriormente
cargada cuando lo nico que se va a modificar entre request y request son
solo datos. Ya que la vista sigue siendo la misma. Es decir se evita el
rearmado de la vista con los nuevos datos y el viaje de la misma desde el
servidor.
La estrategia a utilizar es la tlima indiacada en el apendice de patrones, la
misma se basa en el uso de un componente llamado XML-HTTP que es
81
capaz de realizar requests a un servidor enviando xml y recibiendo xml como
respuesta.
Relaciones Entre Todos los Patrones Analizados.

La Figura 52, y 52b muestra las relaciones entre los patrones. De dichas
relaciones se derivan los compromisos de diseo en arquitecturas de este
tipo.

cdRelaciones Entre Patrones II
Use Case
Use Case
Actor
DomainModel
TransactionScript TableModule
ActiveRecord
RowData
Gateway
TableData
Gateway
DataMapper
Single Table
Inheritance
Class Table
Inheritance
Concrete Table
Inheritance
Inheritance
Mapper
Pessimitic
Offline Lock
Optimistick
Offline Lock
Coarse-Grained
Lock
Layer
SuperType
IdentityField
ForeingKey
Mapping
AssociationTable
Mapping
Unit Of Work
Registry
IdentityMap
Lazy Load
Service Layer
Remote Facade
Data Transfer
Object
Assembler
Session
ubicada
Separated
Interface
acceso a DB
Negocio Complejo
mapeo de jerarqua
Finders
optimizacion de consultas
admin proxy/holder
control de versin
modelo simple
mapeo de jerarqua
acceso a DB
soporte
de
herencia
modelo complejo
control de concurrencia
root de jerarqua de objetos
modelo simple
Negocio Intermedio
Negocio Simple
acceso a DB
implementado en trminosde
ensambla
genera
desacoplar clasesintercambiadas
objetosdistribuidos
mapeo de jerarqua
administrar relaciones
implementado en trminosde
identificacin de DomainObjects
admin y almacenar info de identidad
carga tarda al navegar al root
admin y almacenar info de versin
alberga

Figura 52
82

Figura 52 b
83
Framework Desarrollado
Alternativa Reflection vs Generacin de Cdigo

Para incorporar al framework, el comportamiento que surge del caso de
estudio en s, en principio hay dos alternativas, trabajar con reflection para ir
descubriendo a las clases interactuantes en runtime con ayuda de archivos
descriptores, o generar cdigo en tiempo de desarrollo a partir del uso de
relfection o alguna herramienta mediante code generation.
Ambas alternativas son vlidas y hay muchos frameworks basadas en ambas
alternativas. Cada una tiene ventajas y desventajas frente a la otra.

Anlisis de comparacin entre Michael J Retting y Martin Fowler [JavaWorld -
1]

El uso de reflection dificulta el entendimiento de las excepciones
ocurridas en runtime, mientras en code generation, la excepcin suele
ser mas clara.
En perfomance suele ser mas ptima la generacin de cdigo que el
uso de reflection, y en uso de memoria casi lo mismo.
El cdigo generado suele ser mas claro de entender que el cdigo de
reflection, igualmente este tipo de cdigos una vez que el framework o
generador de cdigo esta listo y no posee errores, no debera
modificarse, por lo cal no sera necesario entender el cdigo. (A
excepcin si se desea optimizar)

Para el presente trabajo se utiliz la generacin de cdigo para extender al
framework. El mismo es una aplicacin que a partir del modelo del dominio
(clases del dominio) genera el cdigo necesario para ser includo al
framework y tener una versin inicial funcionando del sistema.

De la Arquitectura Propuesta al Framework
El framework, presenta las clases bases de la estructura de una aplicacin
enterprise que resuelven los problemas anteriormente analizados, sobre ella,
dado un modelo de dominio en particular se debe extender al framework para
lograr una aplicacin completa.
Estas codificacin de las clases que extienden al framework para un caso de
estudio en particular, puede hacerse codificando a mano, o utilizando una
herramienta como un generador de cdigo.
El uso del generador de cdigo provee la codificacin o generacin de las
clases que extienden al framework, brindando una ayuda en la construccin
del sistema.

En la Figura 53 se observan las clases de cada capa resaltando en distintos
colores las que son calses que brinda el framework y las que son clases
generadas a partir de la herramienta de generacin de cdigo o a mano. Y
las clases de dominio que son las clases que modelan al dominio en
cuestin.

84

Figura 53
( Verde : Cdigo del Dominio - Amarillo : Cdigo Generado - Gris : Cdigo del Framework )

85
Detalle de las API del framework

Aqu se muestra cada paquete para cada capa de la aplicacn

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

Paquetes de Capa de Servicio del framework
framework.iService
framework.iService.dtoEntities
framework.service.fwk

Paquetes de Capa de Persistencia del framework
framework.persistence.caseStudy
framework.persistence.fwk

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

Paquetes de Capa de Utilidades del framework
framework.utils.caseStudy
framework.utils.exceptions
framework.utils.helpers
framework.utils.log
framework.utils.persistence
framework.remoting.client
framework.remoting.server

Paquete fsico common
framework.iService

Paquete fsico front

Paquete fsico back

Paquete fsico utils
framework.utils.log

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

cd Data Model
Persona
+ property get getNombre() : stri ng
+ property set setNombre(stri ng) : voi d
PersonaFwk
+ property get getNombre() : stri ng
+ property set setNombre(stri ng) : voi d
+ markDi rty() : voi d
+ getId() : stri ng
+ setId(stri ng) : voi d
+ getVersi on() : stri ng
+ setVersi on(stri ng) : voi d
DomainObj ect
i nterface
IDominaObject
+ getId() : stri ng
+ setId(stri ng) : voi d
+ getVersi on() : stri ng
+ setVersi on(stri ng) : voi d
real i ze

- Nombre: stri ng
Figura 54

En la Figura 54 vemos a la clase Persona, pertenece a la Capa de Dominio y
la clase PersonaFwk que pertenece a la Capa de Persistencia, sta ltima la
extiende redefiniendo sus getters para utilizarcarga tarda (Lazy Load), y
redefiniendo sus setters para marcarse como modificados (Unit Of Work),
agregando atributos para manejo de identidad (Identity Field) y para manejo
de concurrencia (Optimistic Lock). Las clases DomainObject y la interface
IDomainObject tambin son parte de la Capa de Persistencia.

framework.iService
Contiene las interfaces expuestas por la capa de servicio.

Las interfaces de servicio bsicas, es decir las que permiten el manejo bsico
como abms, son generadas por el generador.
87
cd Figura 55
personas::PersonaDTO
+ getNombre() : Stri ng
+ setNombre(Stri ng) : voi d
+ getDomi ci l i oId() : Stri ng
+ setDomi ci l i oId(Stri ng) : voi d
+ getDomi ci l i oDesc() : Stri ng
+ setDomi ci l i oDesc(Stri ng) : voi d
+ PersonaDTO()
+ toStri ng() : Stri ng
i nterface
personas::IPersonaService
+ searchPersona(Stri ng, Stri ng) : Col l ecti on
+ addPersona(PersonaDTO) : PersonaDTO
+ searchPersona(PersonaDTO) : PersonaDTO
+ del etePersona(PersonaDTO) : voi d
+ modi fyPersona(PersonaDTO) : PersonaDTO
+ toPersonaDTO(Persona) : PersonaDTO
+ toPersonaDTO(Col l ecti on) : Col l ecti on
Remote
i nterface
iservice::IBaseService
dtoEntities::CustomData
+ getId() : Stri ng
+ setId(Stri ng) : voi d
+ getFwk_Versi on() : Stri ng
+ setFwk_Versi on(Stri ng) : voi d
+ getToStri ng() : Stri ng
+ setToStri ng(Stri ng) : voi d
+ CustomData()

- _Nombre: Stri ng
- _Domi ci l i oId: Stri ng
- _Domi ci l i oDesc: Stri ng
- i d: Stri ng
- fwk_versi on: Stri ng
- toStri ng: Stri ng = ""
Figura 55

En la Figura 55 se muestra la interfase de servicio para la clase Persona
Aqu tambin se recomienda agregar las interfaces de servicio que se
adicionan para exponer funcionalidades a la capa de presentacin.

Contiene a los Data Transfer Object que utiliza la capa de servicio.
Son las clases DTO que son utilizadas como parmetros en los mtodos de
servicio, son generados por el generador.
En la Figura 55 se muestra las clases DTO para la clase Persona
Aqu se recomienda agregar las clases DTO que se adicionan.

Contiene las clases especializadas para el caso de estudio de manejo de la
persistencia. Las clases que especializan a los Mappers genricos del
framework (paquete framework.persistence.fwk) se ubican aqu y son
generados por el generador.
88
cd Figura 56
personas::PersonaMapper
+ PersonaMapper()
# getMappedCl assName() : Stri ng
# getMappedBaseCl assName() : Stri ng
# CreateDomai nObj ect() : IDomai nObj ect
+ Load(IDomai nObj ect) : voi d
+ Load(Col l ecti on) : voi d
+ LoadCol l ecti ons(IDomai nObj ect) : voi d
# Save(IDomai nObj ect) : voi d
+ Del ete(IDomai nObj ect) : voi d
fwk::Mapper
# getMappedCl assName() : Stri ng
# getMappedBaseCl assName() : Stri ng
+ Mapper()
# CreateDomai nObject() : IDomai nObject
# CreateDomai nObj ect(Col l ecti on) : Col l ecti on
# AbstractFi nd(IKey) : IDomai nObj ect
- setIsPersi stent(Col l ecti on) : voi d
# ManageLoad(IKey) : Col l ecti on
# LoadDOProperti es(IDomai nObj ect, Map) : IDomai nObj ect
# Fi ndRow(IKey, Stri ng) : Map
- expl odeKeys(IKey, Stri ng) : Stri ng
# Fi ndRows(IKey, Stri ng) : ArrayLi st
- getSql Fi nder(Stri ng, Stri ng) : Stri ng
- getSql Query(Stri ng, Stri ng, Stri ng) : Stri ng
- removeLastFi ndersFi el ds(Stri ng, i nt) : Stri ng
- fi l l Keys(AbstractCol l ecti on) : IKey[]
- fi l l Keys(AbstractCol l ecti on, i nt) : IKey[]
# Fi nd(Stri ng, Stri ng, Stri ng, Stri ng, i nt, i nt) : Col l ecti on
+ Fi nd(IKey) : IDomai nObj ect
+ Fi ndAl l (Stri ng, Stri ng, Stri ng) : Col l ecti on
+ Fi ndAl l (Stri ng, Stri ng, Stri ng, i nt, i nt) : Col l ecti on
+ Load(IDomai nObj ect) : voi d
+ Load(Col l ecti on) : voi d
+ Insert(IDomai nObj ect) : voi d
+ Update(IDomai nObj ect) : voi d
+ Del ete(IDomai nObj ect) : voi d
# throwConcurrencyExcepti on(IDomai nObj ect) : voi d
+ Fi nd(Stri ng, Stri ng) : Obj ect
+ nextKey() : IKey
+ nextKey(Stri ng) : IKey
+ LoadCol l ecti ons(IDomai nObject) : voi d
+ getType(Stri ng, Stri ng) : Stri ng
+ getTabl eNameFor(Stri ng) : Stri ng

Figura 56
En la Figura 56 se muestra el Mapper para la clase Persona.

Contiene las clases genricas del framework de manejo de la persistencia.
Aqu se encuentran las clases del framework que realizan el manejo genrico
de la persistencia.
En la Figura 57 se muestran las clases de este paquete.
89
cd Figura 57
fwk::Context
fwk::DomainObj ect
Col l ecti on
fwk::DomainObj ectCollection
Col l ecti on
fwk::DomainObjectCollectionRelation
Iterator
fwk::DomainObj ectCollectionIterator
fwk::IdentityMap
i nterface
fwk::IDomainObject
i nterface
fwk::IFinder
i nterface
fwk::IKeyGenerator
fwk::Key fwk::KeyGenerator
fwk::Mapper
fwk::PersistenceBroker
fwk::Registry
fwk::UnitOfWork
#domai nObj ectOfRel ati on
#mapper
-keyGenerator
-regi stry
-context
-i denti tyMap

Figura 57

Aqu se encuentran las clases del framework que resuelven la problemtica
del manejo de la capa de presentacin. Las mismas se muestran en la Figura
58.
90
cd fwk
HttpServl et
ActionServlet
# forward(Stri ng, HttpServl etRequest, HttpServl etResponse) : voi d
EntityController
+ Enti tyControl l er()
+ doGet(HttpServl etRequest, HttpServl etResponse) : voi d
+ doPost(HttpServl etRequest, HttpServl etResponse) : voi d
Invoker
- getActi onName(Stri ng) : Stri ng
+ i nvoke(Stri ng) : Stri ng
+ getInstance(Stri ng, Map) : Obj ect
- getProperti esMap(Col l ecti on) : Map
- processRequest(HttpServl etRequest, HttpServl etResponse, Stri ng) : voi d
- i sBusi nessLogi cExcepti on(j ava.l ang.refl ect.Invocati onTargetExcepti on) : bool ean
+ mai n(Stri ng) : voi d
PageController
+ PageControl l er()

- MODULE_PAGE: Stri ng = "xml s/modul es.xml " - MODULE_PAGE: Stri ng = "xml s/modul es.xml "
- CUSTOM_MODULE_PAGE: Stri ng = "xml s/modul es.c...
- servi cesMap: HashMap = new HashMap()
- servi ceFactory: Servi ceFactory = nul l
- name: Stri ng
- cl assName: Stri ng
- i sRemote: bool ean
- nami ngLookup: Stri ng
Figura 58
Aqu se encuentran las clases del framework que manejan el mecanismo de
remoting desde el punto de vista del cliente. Las mismas se muestran en la
Figura 59.

cd client
ServiceFactory
+ getInstance() : Servi ceFactory
- Servi ceFactory()
+ getServi ce(Stri ng) : Obj ect
- getServi ceInfo(Stri ng) : Servi ce
Service
+ getName() : Stri ng
+ setName(Stri ng) : voi d
+ getCl assName() : Stri ng
+ setCl assName(Stri ng) : voi d
+ i sRemote() : bool ean
+ setIsRemote(bool ean) : voi d
+ getNami ngLookup() : Stri ng
+ setNami ngLookup(Stri ng) : voi d
+ Servi ce()
xml
Services
-servi ceFactory

Figura 59

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

91
cd server
ServicePublisher
+ Servi cePubl i sher()
- runServi ces() : voi d
- publ i shServi ces(Col l ecti on) : voi d
+ mai n(Stri ng) : voi d
xml
Services

Figura 60

Contiene las clases de servicio bsicas, es decir las que permiten el manejo
bsico como abms, son generadas por el generador.
Aqu tambin se recomienda agregar las calses de servicio que se adicionan
para exponer funcionalidades a la capa de presentacin. Puede verse un
ejemplo en la Figura 61.

cd Figura 60
Uni castRemoteObject
service::
BaseService
+ BaseServi ce()
personas::PersonaService
+ PersonaServi ce()
+ searchPersona(Stri ng, Stri ng) : Col l ecti on
+ addPersona(PersonaDTO) : PersonaDTO
+ searchPersona(PersonaDTO) : PersonaDTO
+ del etePersona(PersonaDTO) : voi d
+ modi fyPersona(PersonaDTO) : PersonaDTO
+ toPersonaDTO(Persona) : PersonaDTO
+ toPersonaDTO(Col l ecti on) : Col l ecti on

- broker: IPersi stenceBroker
Figura 61

Aqu se encuentran clases tiles para el desarrollo de la resolucin del caso
de estudio. Contiene clases como Helpers, el broker de persistencia, etc.

Aqu se encuentran clases para el manejo de excepciones.

Aqu se encuentran clases con utilidades genricas que utiliza el framework.
92

framework.utils.log
Aqu se encuentran clases de manejo de log que utiliza el framework.

Aqu se encuentran clases e interfaces de manejo de medios persistencia
que utiliza el framework, tales como para un motor de base de datos, etc.

En la Figura 62 se muestran las clases del paquete framework.utils

cd utils
caseStudy
+ Stri ngHel per
+ IKey
exceptions
helpers
+ Cl assHel per
+ ConvertHel per
+ IOHel per
+ PhpHel per
+ Seri al i zer
+ TypeHel per
+ Xml Hel per
log
+ Consol eLog
+ Fi l eLog
+ Logger
+ ILog
persistence
+ IStorageMedi um
+ db
db
+ BDatos
+ BDatosExcepti on
(from persi stence)

Figura 62

Relaciones Entre Todos los Patrones Utilizados.

La Figura 62b muestra las relaciones entre los patrones como fueron
utilizados en el presente trabajo.

93

Figura 62b
94
Generador del Cdigo para el Framework
Arquitectura

Las clases que extienden al framewok desarrollado, se generan a partir del
generador que se describe a continuacin. De la arquitectura propuesta en la
seccin anterior, vemos por ejemplo que las clases genricas del paquete
persistence.fwk son provistas por el framework y stas dan la funcionalidad
bsica de la capa de persistencia. A partir de stas y de las clases del
modelo de dominio, se deben obtener las clases que extienden a las
genricas especializndolas.

Por ejemplo la clases de mapeo objeto relacional, se basan en la clase
Mapper, sta posee la funcionalidad comn para todos los objetos de
dominio, pero no sabe los atributos extra que presenta cada clase de
dominio, por lo que es necesario extender a la clase Mapper para cada clase
de dominio, redefiniendo y definiendo ciertos mtodos abstractos para
agregar dicho comportamiento faltante y especfico de la clase de dominio.
En la Figura 63 se muestra un ejemplo.

cd Data Model
Mapper
# Save(IDomai nObject) : voi d
PersonaMapper

Figura 63

En la presente propuesta se desarroll un generador que en forma autnoma
realiza esta generacin. (Ver el tema analizado anteriormente de Generador
vs Reflection)
Esto es posible gracias a la arquitectura analizada en la seccin anterior,
donde se mostr la independencia entre el modelo de dominio y el framework
que se describe.
El generador se alimenta de la informacin del modelo a persistir a partir de
un conjunto de archivos xml. Estos archivos contienen informacin de las
propiedades y mtodos de las clases. Existe un archivo por clase de dominio
95
a persistir. En la figura que sigue este archivo se muestra como
ClassData.xml. Estos archivos xml, pueden ser construidos a mano o ser
exportados desde una herramienta de modelado.
En ste trabajo se desarroll otro generador muy sencillo para este fin, que
genera dichos archivos xml a partir de las clases compiladas del dominio.

Una vez que se poseen dichos archivos xml (classData), se procede a
generar el cdigo para el framework.

El ClassData.xml tiene la estrucutra descripta en la Figura 64

<?xml version='1.0' encoding='ISO-8859-1' ?>
<class package="pequi.ot" name="OrdenDeTrabajo" type="concret"
baseClassName="java.lang.Object">
<attributes>
<attribute name="Color" relation="primitive"
type="java.lang.String" visibilityLevel="public"
isStatic="no" isFinal="no" isProperty="yes"
initialValue="" exceptions="" />
<attribute name="Cliente" relation="agregation"
isMandatory="no"
type="pequi.clientes.Cliente"
visibilityLevel="public"
<attribute name="FechaEntrada" relation="primitive"
type="java.util.Date" visibilityLevel="public"
<attribute name="Pliegos" relation="collection" pageSize="50"
manyToMany="true" type="pequi.ot.Pliegos"
visibilityLevel="public" isStatic="no" isFinal="no"
isProperty="yes" initialValue="" exceptions="" />
</attributes>
<dependencies></dependencies>
<implements></implements>
</class>

Figura 64

Es decir el mismo posee la descripcin de nombre, paquete, atributos,
dependencias, clase base e implementaciones de una clase de dominio.

El generador desarrollado es capaz de incorporar nuevos templates para
generar cdigo.
Inicialmente hay un template para cada clase o capa necesaria en el
framework pero el diseo actual permite la extensin del framework y su
generador a travs de la configuracin del mismo, dndo la posibilidad de
agregar nuevos templates a partir de nuevas clases que implementen la
interfaz IGenerator y su inclusin en la configuracin del mismo. Se muestra
el diagrama de clases en la Figura 65.

96

Figura 65

Esto se configura, en el archivo GeneradorConf.xml donde se listan los
templates existentes.

Se pueden ejecutar todos juntos o generar cdigo para una clase o capa en
particular.
En la Figura 66 se muestra un segmento de GeneratorConf.xml que configura
la interfaz visual del generador de cdigo, indicando que generadores posee,
que motores soporta, etc.

<codegenerator>
<configuration>
<sqlSupport>
<motor name="JET" displayName="Jet / MS Access"
default="true" passRequired="false"/>
<motor name="MSSQL" displayName="MS SQL Server"
default="false" passRequired="true"/>
<motor name="MYSQL" displayName="MYSQL"
default="false" passRequired="true"/>
</sqlSupport>
<outputLanguage>
<language name="java" displayName="Java" default="true"
/>
<language name="csharp" displayName="C#" default="false"
/>
</outputLanguage>
<classDataGenerator>
<option displayName="ClassData Generator"
tooltip="Generador de metadata de las clases">
<generator
class="codeGenerator.generator.ClassDataGenerator"
/>
</option>
</classDataGenerator>
<generators>
<option name="Persistence Layer"
displayName="Persistence Layer"
tooltip="Generador de clases de manejo de
persistencia para el framework">
<generator
class="codeGenerator.generators.ConcreteMapperGenerator" />
<generator
class="codeGenerator.generators.ConcreteDomainObjectGenerator"
/>
<generator
class="codeGenerator.generators.RegistryGenerator" />
</option>
<option name="DataBaseGenerator"
97
displayName="DataBase Generator"
tooltip="Generador de scripts de base de datos para el
framework">
<generator
class="codeGenerator.generators.DataBaseGenerator" />

</option>
</generators>
</configuration>
</codegenerator>
Figura 66
A partir de la interfaz del Generador View que se muestra en la Figura 67, se
entran los datos de : a) directorio de los archivos xml, b) el directorio donde
se har el despliegue, c) el directorio del cdigo genrico del framework, d)
motor de base de datos, e) lenguaje de la implementacin, f) lista de clases a
generar y g) datos de coneccin a la base de datos.

Figura 67

98
Tipos de Generadores Provistos

Se listan los distintos tipos de componentes generados y agrupados segn
las capas a que pertenecen.

Capa de persistencia

ConcreteMapperGenerator, genera cada uno de los Mapper
concretos que extienden a AbstractMapper, para cada clase del
dominio.
ConcreteDomainObjectGenerator, genera cada una de las clases del
dominio adaptada al framework, como se describi en una seccin
anterior.
RegistryGenerator, genera archivos xml donde se listan los Mappers a
ser usados por la clase genrica registry del framework.

Capa de base de datos

DataBaseGenerator, genera los scripts SQL para la creacin de las
tablas en la base de datos.
DataBaseXmlGenerator, genera un archivo xml donde se guarda el
string de conexin que utilizar el framework.

Capa de Servicio

ConcreteIServicelayerGenerator, genera cada unas de las interfaces
para los servicios bsicos (ABM) para cada clase persistente del
dominio.
ConcreteServicelayerGenerator, genera cada unas de las clases para
los servicios bsicos (ABM) para cada clase persistente del dominio.
ConcreteDTOGenerator, genera cada una de las clases de tipo DTO,
utilizadas en la capa de servicio, por cada una de las clases de
dominio.
FinderGenerator, genera un archivo xml con las consultas SQL a
utilizar desde la capa de servicio.
ServiceXmlGenerator, genera un archivo xml con la lista de servicios
disponible desde la capa de presentacin.

99
Capa de Presentacin

Los siguientes generadores proveen de archivos xml para la capa de
presentacin.
XMLActiveFrontActionGenerator, genera una lista de archivos
javascript con las funciones necesarias para la invocacin a travs del
mecanismo Ajax o ActiveFront utilizado desde la capa de
presentacin.
XMLEntityGenerator, genera un archivo xml con la descripcin de las
entidades DTO expuestas por los mtodos de la capa de servicios
para generar automaticamente las pantallas de ABM desde la capa de
presentacin a travs de EntityController.
XMLEntityManagerGenerator, genera un archivo xml con la lista de los
archivos generados por el XMLEntityGenerator.
XMLModulesGenerator, genera un archivo xml con la lista de modulos
definidos a usar por PageController desde la capa de presentacin.
XMLRegistryBDatosGenerator, genera un archivo xml con la
informacin relacionada con la Base de Datos requerida por la
Registry.
XMLRegistryMapperGenerator, genera un archivo xml con la
informacin para la obtencin de los Mappers requerida por la
Registry.
XMLServiceApplicationGenerator, genera un archivo xml con la
informacin de los servicios (locales, remotos, ubicacin de los
mismos) requerida por la ServiceFactory del lado del servidor de
aplicaciones.
XMLServicePresentationGenerator, genera un archivo xml con la
informacin de los servicios (locales, remotos, ubicacin de los
mismos) requerida por la ServiceFactory del lado del serivodr de
presentacin.
XMLServletActionGenerator, genera un archivo xml con la lista de
acciones disponibles a invocar desde la capa de presentacin.

100
Caso de Estudio
Descripcin del dominio

Una empresa grfica 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 Filmacin 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, maana, 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
estn terminados, entonces la orden de trabajo estar terminada. Cada
proceso tiene un tiempo asignado para su resolucin.
La orden de trabajo es para un cliente dado y tiene asociados un conjunto de
materiales. Se almacenan la informacin asociada a los clientes y
empleados, como domicilio, cuit, y telfono.

Modelo del Dominio

El diagrama de clases del modelo del dominio puede verse en la Figura 68
3 3 3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
A
3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
A
3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
A
3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
A
3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
A
3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
A
3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
A
3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
A
3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
A
3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
A
3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
A
3
.
5
1

-

U
n
r
e
g
E
A

3
.
5
1

-

U
n
r
e
g
E
A

3
.
5
1

-

U
n
r
e
g
A
3
.
5
1
A

3
.
5
E
A

3
.
5
OrdenDeTrabaj o Proceso
Material Componente
Solicitante
Turno
Nota
Cliente
EstadoDeOrden
EstadoDeProceso
i nterface
IPersona
Empleado
Domicilio Pais
Provincia
Partido
Localidad
0..*
1
1
0..1
1..*
ti ene
0..1
asi gnado a
0..1
0..1
1..*
1
1
1
1 1
0..*
0..*
0..*

n E
Figura 68
101
Transicin del anlisis al diseo

El objetivo es describir el proceso que conduce la transicin del anlisis al
diseo de arquitectura de un sistema de tipo Enterprise.
Para esto comenzamos actualizando algunas definiciones del concepto de
arquitectura de sistemas. Luego a partir de un modelo de casos de uso de
sistema comenzamos la descripcin del proceso mencionado.
Diagrama de Casos de Uso de sistema

En la Figura 68 se muestra un diagrama de casos de uso que modelan
parcialmente la funcionalidad de la aplicacin descripta. Estos casos de uso
fueron construdos en base a el Modelo de Dominio y un Modelo del Negocio
descripto. Estos casos de uso modelan los requerimientos funcionales. Los
mismos estarn acompaados por un listado de requerimientos no
funcionales. Es interesante notar que la arquitectura en estos casos est
dada en parte. Sin embargo, y segn fue mencionado en los objetivos, hay
que realizar la transicin de los productos del anlisis a esta arquitectura; es
decir, definir cmo este anlisis es volcado sobre las distintas partes de la
arquitectura de N Capas.

Figura 69
102
Anlisis de los Casos de Uso, Diagramas de Robustez

Anlisis de los casos de uso basndose en su descomposicin en clases de
anlisis. Cada uno de los casos de uso se descompone en sus aspectos vista
(view), datos (modelo) y dinmica (controller). Se analizan as la
colaboracin entre estos elementos y aparecen nuevos elementos
representando conceptos como las reglas del negocio. Algunos de los
elementos de tipo datos se corresponden con entidades del modelo del
dominio. Esto se muestra en la Figura 70.
Este modelo de robustez muestra adems las relaciones entre los distintos
casos de uso. Cuando en un paso posterior los casos de uso sean
empaquetados, estas relaciones constituirn las dependencias entre los
paquetes lgicos resultantes y sus interfaces.

Figura 70
103
Paquetes Lgicos del Diseo Conceptual

Los casos de uso son empaquetados siguiendo criterios de cohesin
derivados del negocio. Dicho empaquetamiento es una vista esttica y
constituye la primera y ms prematura arquitectura que tiene en cuenta la
funcionalidad pedida al sistema a desarrollar. Debido a que estos sistemas
son complejos en su mayora, podrn y debern ser descompuestos en
paquetes que modularmente contengan aspectos de distintos niveles de
abstraccin. Es decir buscaremos estratificarlo en capas (layer), donde cada
capa prestar servicios a la capa inmediatamente superior. Entre los criterios
de buen diseo que trataremos de seguir estarn la no inclusin de
dependencias circulares, la dependencia en la direccin de la mayor
generalidad, el re uso, etc. Las dependencias entre paquetes y las interfaces
de los mismos son definidas en base al anlisis de robustez.

Figura 71

Diagrama de una arquitectura de tipo Enterprise

En la Figura 72 se muestra mediante la utilizacin de nmeros asociados a la
Figura 70, la transicin del producto del relevamiento de requerimientos y su
anlisis sobre la estructura en capas utilizada en el framework. Se mapean
para cada paquete los distintos objetos a cada una de las capas.
Para cada capa (tier) se busca profundizar la estructura de capas (layer) con
paquetes fsicos. Aparecen restricciones impuestas por la tecnologa que
condicionan algunos de los requerimientos funcionales.

104

Figura 72

105
Uso del Framework

Luego del diseo se desarrollaron las clases del dominio.
Obteniendo los siguientes paquetes:
pequi.ot para las clases relacionadas a manejo de las ordenes de trabajo
pequi.personas clases relacionadas a manejo de personas
pequi.clientes clases relacionadas a manejo de clientes

Luego ejecuntado el generador de archivos xml descriptores, y luego el
generador de cdigo, se obtienen las clases que especializan a las clases
bases del framework.

Paquetes generados con detalle de clase generada asociada a la clase
Cliente:

Clases Domain Adapter del dominio
Paquetes:
framework.domainModel.fwk.pequi.ot
framework.domainModel.fwk.pequi.personas
framework.domainModel.fwk.pequi.clientes
Una clase como ejemplo:
ClienteFwk.class

Clases Data Transfer Object
Paquetes:
framework.iservice.dtoEntities.pequi.ot
framework.iservice.dtoEntities.pequi.personas
framework.iservice.dtoEntities.pequi.clientes
ClienteDTO.class

Interfaces de Servicio
Paquetes:
framework.iservice.pequi.ot
framework.iservice.pequi.personas
framework.iservice.pequi.clientes
IClienteService.class

Clases de manejo de Persistencia
Paquetes:
framework.persistence.casestudy.pequi.ot
framework.persistence.casestudy.pequi.personas
framework.persistence.casestudy.pequi.clientes
ClienteMapper.class

Clases de Servicio
Paquetes:
framework.service.pequi.ot
106
framework.service.pequi.personas
framework.service.pequi.clientes
ClienteService.class

Archivos y Xml Descriptores generados ejemplificados para la clase
Cliente:

Tambin se obtuvieron archivos xml con informacin necesaria por las clases
del framework.

Capa Presentacin
Archivos:
entityManager / pequi.clientes.Cliente.pageData.xml
modules.xml
servlet-actions.xml
AFActions / pequi_clientes_Cliente.js

Capa de Persistencia
Archivos:
Registry / BDatos.xml
Registry / Mappers.xml
Finders / Finders.xml

Capa de Servicio
Archivos:
Service / PresentationServices.xml
Service / ApplicationServices.xml

Scripts SQL generados:

Tambin se obtuvieron los archivos con los scripts utilizados para la creacin
de la base de datos.

Creacin de tablas de entidades
Un archivos de ejemplo:
TABLE_part_0_pequi_clientes_Cliente.sql

Creacin de Indices, Foreign Keys, Primary Keys
FK_pequi_ot_OrdenDeTrabajo.sql

Creacin de tablas de relaciones
COLLECTION_part_0_pequi_ot_OrdenDeTrabajo.sql

Pantallas obtenidas
107

A continuacin se muestran las pantallas de administracin y creacin de
clientes generada por la capa de presentacin mediante los archivos xml
mencionados anteriormente.

Manager / Selector

Figura 73

Editor / Nuevo

Figura 74
Resultados obtenidos al aplicar el framework

108
El generador dej todos estos paquetes y archivos empaquetados en un
archivo .war, llamado pequi.war, el cual puede ser directamente desplegado
en un contenedor web, como por ejemplo tomcat, brindando as la
funcionalidad bsica para administrar la entidades de dominio, de aqu en
mas los pasos seran customizar los archivos descriptores de presentacin
para brindar una interfaz mas amigable y desarrollar los servicios faltantes
asociados a los casos de uso apoyandose en el framework y la aplicacin
obtenida.
Es decir este mecanismo nos brinda un start up veloz, resolviendo las
problemticas tpicas en este tipo de aplicaciones.

109
Trabajo Futuro

Como trabajo futuro se listan una serie de items con los cuales sera
deseable contar y se podrn desarrollar fuera del alcance del presente
trabajo. Informacin sobre el avance del mismo puede obtenerse en [WEB-
Tesis]

Agregar otros protocolos de comunicacin entre capas

Se cuenta con la abstraccin necesaria para independizarse del
protocolo de comunicacin utilizado, pero hace falta agregar mas
protocolos, principalmente para manejo de web services, para brindar
mas opciones de configuracin que permitan al desarrollador optimizar
la aplicacin lo mas acorde a sus necesidades.

Agregar otras formas de mapeo de herencia de objetos a relacional
(eleccin de patrones de mapeo)

Se desea agregar la implementacin de otros patrones de diseo
vistos y analizados para mapear herencias dando as mas flexibilidad
de eleccin buscando siempre la mejor solucin particular a cada caso
concreto.

Clustering

Administracin de pool conexiones

Agregar un manejo de pool de conecciones agilizando el uso de las
mismas para ganar en performance. Agregar uso de drivers de
motores especificos para la coneccin.

Roll back de transacciones

Agregar un manejo de rollback de transacciones ya confirmadas,
dando la posibilidad de hacer un deshacer de la ltima accin si es
que no hubo otras que la afectaran

Mejorar administracin de colecciones en el dominio

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

110
Integracin con herramientas estndar (IDEs, Eclipse, EA, etc)

Integrar con herramientas de diseo a travs de plugins, permitiendo
as generar desde ellas los archivos descriptores que utiliza el
generador de cdigo evitando el uso de la herramienta presentada en
el presente trabajo, agilizando y facilitando el refactoring mediante su
uso.
Integrar con ambientes de desarrollos o IDEs. Para permitir generar
cdigo de distintas capas directamente desde plugins instalados en el
mismo ambiente de desarrollo.

Mejorar la dinmica de generacin ( refactoring del dominio y
adaptacin automtica de la base)

Darle mas funcionalidades a la dinmica de generacin permitiendo
actualizar cambios en la base de datos sin perder los datos
contenidos, es decir que al refactorizar por ejemplo objetos de
dominio, se actualizen su representacin en la base de datos sin
perder los datos contenidos en la misma.

Auditora

Agregar manejo de auditora a la capa de servicio, permitiendo as
tener una aplicacin que visualice que hiz y esta haciendo cierto
usuario, pudiendo directamente cerrarle la sessin o modificarle
permisos de control de acceso es necesario.

Generacin automtica de otras interfaces de presentacin

Agregar generacin de cdigo para otras interfaces de presentacin
tales como smart client basados en swing, u otros tipos de scripting.

Optimizacin de interaccin con el motor de base de datos

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

111
Conclusiones

La separacin de una aplicacin en capas permite separar las problemticas
y atacar los problemas de cada una en forma ms independiente del resto de
las capas, permitiendo as trabajar y avanzar con el desarrollo en forma
paralela una vez que se especificaron las interfaces entre capas, permitiendo
tener roles especializados en los temas a atacar en cada capa.
El uso de patrones ya analizados y estudiados permite hablar con mas
claridad y mas alto nivel a los participantes del desarrollo, permitiendo no
reinventar la rueda y tener alternativas tiles a problemas comunes.

La utilizacin de frameworks de trabajo, que son acordes a la resolucin de la
problemtica a resolver, facilitan el desarrollo de la aplicacin ya que
imponen un rden y una estructura ya pensada para un tipo de arquitectura
dada. Por lo que problemas comunes y genricos ya estn resueltos y
optimizados por el framework y se permite hacer uso de ellos y
especializarlos extendiendo al mismo. Esto brinda un rpido start up de la
aplicacin.
Lo importante es saber y distinguir claramente si un framework, es acorde a
la problemtica a resolver. Un problema tpico es el uso un framework
pensado para cierta arquitectura, cuando sta no es la adecuada para
nuestro problema, ya que dicho framework, fue pensado y optimizado para
otra problemtica.
Por esto es muy importante analizar la eleccin del framework adecuado.
Mediante el uso de un framework y en conjunto con metodologas y procesos
de desarrollo adecuados, se agiliza mucho el proceso de desarrollo de una
aplicacin, y es mas fcil obtener un resultado exitoso.

La solucin obtenida a la restriccin impuesta de no modificar el modelo de
dominio permiti que un modelo de dominio estudiado e implementado,
pueda ser facilmente integrado al framework para lograr as una aplicacin
para dicho modelo que puede ser desplegada en un ambiente distribuido,
resolviendo la problemtica que ataca el framework. Se logr separar toda la
problemtica relacionada a la resolucin del modelo de negocio, de los
problemas inherentes a la arquitectura elegida de acuerdo a las necesidades.

112
Apndice Patrones

Patrones de Arquitectura de Aplicaciones de tipo Enterprise
Patrones que resuelven distintos problemas asociados a las capa de una
Aplicacin de tipo Enterprise. [Martin Fowler eaaCatalog]
Los mismos fueron basados en el catlogo expuespo por Martin Fowler
desde su site en internet. http://www.martinfowler.com/eaaCatalog/

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

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

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

113

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

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

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

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

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

Transaction Script
Organiza la lgica de negocio a travs de procedimientos dnde cada uno
maneja un simple request (pedido) desde la capa de presentacin.

La mayora de las aplicaciones puede pensarse como una serie de
transacciones. Una transaccin puede ver cierta informacin organizada de
una manera particular, otra puede hacer cambios sobre sta. Cada
interaccin entre un cliente y un servidor contiene cierta lgica, en algunos
casos puede ser simple como visualizar informacin y en otros puede
incorporar una cierta cantidad de pasos de validaciones y clculos.
Un Transaction Script organiza toda esa lgica como un solo porcedimiento,
conectndose directamente a la base de datos, o a travs de un delgado
wrapper. Cada transaccin tiene su propio Transaction Script, aunque
algunas tareas comunes pueden volcarse en subprocedimientos.

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

Table Module organiza la lgica del dominio como una clase por tabla en la
base de datos, y una solo instancia de una clase contiene varios
procedimientos que interactan con la base. Se posee un solo objeto para
administrar todos filas de la base de datos
115

Service Layer
Define con una capa de servicios un lmite de la aplicacin que expone un
conjunto de operaciones.

Una Service Layer encapsula toda la lgica de negocio, control de
transacciones y coordinacin de la respuesta en la implementacin de las
operacin que expone.

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

Table Data Gateway contiene todo el SQL para acceder a una sola tabla o
vista
Otro cdigo invoca sus mtodos para interactuar con las base de datos.

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

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

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

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

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

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

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

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

Class Table Inheritance
Representa una jerarqua de clases con una tabla para cada clase.

118

Concrete Table Inheritance
Representa una jerarqua de clases con una tabla para cada clase concreta
de la jerarqua.

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

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

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

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

Unit of Work
Mantiene una lista de los objetos afectados por una transaccin de negocio y
cordina la actualizacin de los cambios en la base de datos y resuelve los
problemas de concurrrencia.

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

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

121

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

Layer Supertype
Una clase que acta como clase base de todas las clases en su capa.

No es raro que todos los objetos en una capa tengan ciertos mtodos que no
es deseable que esten duplicados. Todo ese comportamiento puede ser
desplazado para la Layer Supertype

Separated Interface
Define una interfaz en un paquete separado de su implementacin.

122

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

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

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

123
Optimistic Offline Lock
Previene conflictos de concurrencia en transacciones de negocio, detectando
un conflicto y realizando un rollback de la transaccin.

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

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

o
n
o
n
A
L

V
e
r
s
i
o
n
A
L

V
e
r
s
i
o
n
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
o
n
U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
A
L

V
e
r
s
i
E
A

3
.
5
1

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
E
A

3
.
5
1

-

U
n
r
e
g
i
s
t
e
r
e
d

T
R
I
E
A

3
.
5
1

U
n
r
e
g
i
s
t
E
A

3
.
5
1

-

U
n
r
e
g
i
s
E
A

3
.
5
1

E
A

3
.
5
1
E
A

3
.
5
1
DATOS
Vista
tabl a check
combo
Acci n A Acci n B
Servidor
Control
Actual i za l os datos

Esta implementacin puede verse como una variante del patrn MVC
aplicado a aplicaciones de tipo Web.

Nombre: ActiveFront, Ajax, MVC
Contexto: Sistemas de dos o mas capas donde el cliente es un cliente
delgado web. El procesamiento de datos lo realiza el servidor en una
capa de negocio o de servicio y el cliente solo visualiza y captura datos
que envia al servidor para que procese. Se cuenta con la posibilidad
de enriquecer un poco al cliente con el uso de scripting y el modelo de
objetos del explorador.
Problema: La recarga de una vista o pgina anteriormente cargada
cuando lo nico que se va a modificar entre request y request son solo
datos. La vista sigue siendo la misma. Es decir se evita el rearmado de
la vista con los nuevos datos y el viaje de la misma desde el servidor.
Causas: La comunicacin entre el cliente y el servidor es a travs de
requests. Y se deja que el servidor genere una nueva vista pero con
los nuevos datos cargados para que el cliente los visualize, cuando en
realidad la misma sigue igual, solo modifico sus datos.
Solucin: Separar los datos de la vista. Mediante el uso de un
pequeo controlador / invoker del lado del cliente dentro de la vista,
que administre los datos. Mediante el uso del modelo de objetos del
explorador y scripting del lado del cliente se realiza la carga y manejo
124
de datos sobre la vista anteriormente solicitada sin necesidad de
realizar un request cuando es posible con los datos actuales. Y al
momento de necesitar una accin del servidor para obtener mas datos,
se realiza la misma evitando la recarga de la vista que continua siendo
la misma.

o Estrategias:
1) Ejemplo de combos relacionados, Pas, Provincias,
Partidos y Localidades. La estrategia mas simple es que la
primera vez que se solicita la vista, venga con ella toda la
informacin posible, es decir de todos los pases, provincias,
partidos y localidades, inicialmente todos los combos vacos con
la opcin de seleccione, a excepcin de los pases que no
varan. Al seleccionar un pas mediante el uso de scripting y el
modelo de objetos del explorador se carga el siguiente combo
relacionado, provincias, para que el usuario elija y as
sucesivamente.
Ventajas:
1. Solucin muy simple de implementar.
Desventajas:
1. Limitada a casos donde se conocen de antemano todos
los datos posibles intervinientes.
2. Si los datos involucrados son muchos, la carga inicial de
la vista se ver considerablemente afectada debido a que
es mayor el tamao de los datos que de la vista en s,
haciendo muy lenta su carga.
2) Listados de datos visualizados en una tabla, cuyo
contenido es resultado de una bsqueda que realiza el servidor
de acuerdo a filtros que le indica la vista. Esta estrategia se
basa en tener un frame o iframe oculto que es encargado de
realizar un request al servidor con los parmetros de filtro de la
bsqueda, y una vez obtenida la respuesta bindear o enlazar
los datos a la tabla de la vista. Esto se puede realizar mediante
el uso de scripting, modelo de objetos del explorador y se puede
facilitar mas an si la respuesta del servidor es en formato xml,
para que con scripting se realice el bindeo o enlace automtico
entre las tablas y sus datasources (xmls).
Ventajas:
1. Solucin simple de implementar.
125
2. Permite obtener datos bajo demanda y luego
visualizarlos sin recargar las vistas.
3. Las vistas no se ven afectadas en cuanto a
tamao y estas pueden ser cacheadas por el
explorador ya que las mismas no expiraran
continuamente ya que sus datos son
manejados independientemente de la
presentacin.
4. Las vistas no son reescritas por el servidor por
lo que separa mas la vista en si de los datos,
permitiendo un mejor manejo por los
diseadores.
Desventajas:
1 Utiliza frames ocultos.
2 Utiliza mas scripting del lado del cliente.
3) Listados de datos visualizados en una tabla, cuyo contenido es
resultado de una bsqueda que realiza el servidor de acuerdo a filtros
que le indica la vista. Altas y bajas de entidades. Esta estrategia se
basa en el uso de un componente llamado XML-HTTP que es capaz
de realizar requests a un servidor enviando xml y recibiendo xml como
respuesta.

Ventajas:
1. Una vez implementada esta estructura, facilita el uso
de este patrn.
2. Permite obtener datos bajo demanda y luego
visualizarlos sin recargar las vistas.
3. Las vistas no se ven afectadas en cuanto a tamao y
estas pueden ser cacheadas por el explorador ya que
las mismas no expiraran continuamente ya que sus
datos son manejados independientemente de la
presentacin.
4. Las vistas no son reescritas por el servidor por lo que
separa mas la vista en si de los datos, permitiendo un
mejor manejo por los diseadores.
5. Tiene un manejo desde el lado del cliente, similar al
de un cliente rico, utilizando un esquema similar al
llamado de mtodos de objetos.
6. Permite realizar estas acciones sincrnica o
asincrnicamente, dando una mejor interaccin con el
usuario.
7. Esta estrategia puede utilizar un pequeo framework
con funciones de scripting del lado del cliente y un
manejo del lado del servidor. La idea es manejar
desde scripting funciones similares a los mtodos de
la clase a invocar (preferentemente asociado a una
capa de servicio). Desde el cliente el framework arma
126
un xml con un formato especfico que indicar una
accin, (previamente definida en el servidor, esta
mapear a un mtodo de una clase) y los parmetros
para invocarlo. Y esperara la respuesta en un xml.
Con esta respuesta realizar el binding a los objetos
(tablas, combos, etc) del explorador. El servidor valida
que la accin sea una accin vlida, controla que los
parmetros recibidos sean los que posee dicho
mtodo y mediante reflection instancia y ejecuta dicho
mtodo obteniendo el resultado deseado, el cual es
serializado a xml y devuelto en el response. O
directamente invoca al servidor y este retorna en su
response un xml con la informacin en el formato
definido

Desventajas:
1. Construccin de la base de esta estructura o
framework.
2. Utiliza mas scripting del lado del cliente.

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

Patrones Relacionados: MVC, Ajax

127

Referencias - Bibliografa

[Aplert, 1998] Sherman R. Alpert, Kyle Brown, Bobby Woolf, The Design
Patterns Smalltalk Companion. Addison Wesley, 1998.

[Copplien 1995] James Copplien, Douglas C. Schmidt, J. Vlissides, N.
Kerth, Robert Martin, Dirk Riehle, Frank Buschmann, Neil Harrison, Brian
Foote, and Hans Rohnert, Pattern Language of Program Design, 1, 2, 3, 4,
Addison Wesley, 1995.

[Fayad, 1999 ] Mohamed E. Fayad (Editor), Douglas C. Schmidt (Editor),
Ralph Johnson, Implementing Application Frameworks : Object-Oriented
Frameworks at Work, John Wiley. 1999

[Gamma et al, 1995] Erich Gamma, Richard Helm, Ralph Johnson, and
John Vlissides, Design Patterns, Elements of Reusable Object-Oriented
Software, Addison-Wesley, 1995.

[Hofmeister, 1999] Christine Hofmeister, Robert Nord, Dilip Soni, Christine
Hoffmeister, Applied Software Architecture , Addison Wesley, 1999.

[JavaWorld - 1] JavaWorld
http://www.javaworld.com/javaworld/jw-11-2001/jw-1102-codegen_p.html
By Michael J. Rettig with Martin Fowler

[Marinescu, 2002] Floyd Marinescu. EJB Design Patterns, Advanced
patterns, processes and idioms. John Wiley. 2002.

[Martin Fowler, 2003] Martin Fowler. Patterns of Enterprise Application
Architecture. Adison Wesley, 2003.

[Martin Fowler eaaCatalog] Sitio de Martin Fowler
http://www.martinfowler.com/eaaCatalog/

[Rod Johnson, 2003] Rod Johnson, Expert One-on-One J2EE Desgin and
Development. Wrox Press, 2003.

[Schmidt, 2000] Douglas Schmidt, Michael Stal, Hans Rohnet, Frank
Buschmann, Patern Oriented Software Arquitecture vol 2, John Wiley,
2000.

[Scott Ambler 1] Sitio de Scott Ambler
The Design of a Robust Persistence Layer For Relational Databases.
http://www.ambysoft.com/persistenceLayer.pdf
128

[Stal, 1997] Michael Stal, Hans Rohnet, Frank Buschmann, Regine
Meunier, Peter Sommerlad. Patern Oriented Software Arquitecture vol 1 ,
John Wiley, 1997.

[WEB-1] Sun Developer Network
http://java.sun.com/j2ee/learning/tutorial/index.html

[WEB-2] MSDN
http://www.microsoft.com/spanish/msdn/arquitectura/default.asp

[WEB-3] MSDN
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dnpag2/html/entlib.asp

http://java.sun.com/developer/technicalArticles/J2EE/AJAX/

http://java.sun.com/j2se/1.4.2/download.html

[WEB-6] Apache Software Foundation
http://jakarta.apache.org/tomcat/

[WEB-7] The Apache Software Foundation
http://ant.apache.org/

[WEB-Tesis] Sitio en Internet de la Tesis
http://www.jframework.com.ar
http://www.fi.uba.ar/~dmontal/

129

Montaldo Tesisdegradoingenieriainformatica

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Montaldo Tesisdegradoingenieriainformatica

Cargado por

Copyright:

Formatos disponibles

TESIS DE GRADO EN

También podría gustarte