Patrones de Diseño de Arquitecturas de Software Enterprise

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

Patrones de Diseño de Arquitecturas

de Software Enterprise Tesista: Diego Fernando Montaldo Director: Profesor Ing. Guillermo Pantaleo Noviembre 2005


Objetivo

• Analizar los problemas que se plantean en el desarrollo de sistemas con arquitecturas enterprise.

• Examinar los patrones de diseño conocidos como solución a este tipo de problemas.

• Proponer una arquitectura que utilice, adapte e integre a estos patrones, obteniendo un framework de trabajo, que permita el desarrollo de una aplicación de tipo enterprise, teniendo resueltos a estos problemas típicos, permitiendo focalizarse en el problema del dominio del negocio en sí.

ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones


Introducción

• Sistemas de Tipo Enterprise

Dentro de lo que se denomina “Desarrollo de Software” se abarca el desarrollo de muchísimos sistemas, con características totalmente diferentes.

Cada uno con distintas complejidades y distintos objetivos, y para cada tipo de sistema se utiliza una estrategia diferente para su resolución.

Se distinguen entre todos los sistemas, a los sistemas de tipo enterprise.

ObjetivoIntroducciónSistemas de Tipo Enterprise

ArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones


• Características de los Sistemas de Tipo EnterpriseEntre las características salientes de un sistema de tipo enterprise, según [Rod Johnson, 2003], [Martin Fowler, 2003], [Marinescu 2002] se pueden mencionar las siguientes:

1. Datos masivos (gran volumen) y persistentes.2. Lógica de negocio, lo que implica procesamiento

de datos.3. Variedad de interfaces de usuario, lo que implica

diversidad en la funcionalidad brindada.




4. Integración con otros sistemas, lo que implica que comparten funcionalidad y / o datos.

5. Acceso concurrente, lo que implica gran cantidad de usuarios.

6. Disonancia conceptual (modelo de datos con distintas visiones), debido a que poseen un modelo de negocio subyacente que abarca distintos aspectos de un área de negocio. Por lo tanto prestan distintas funcionalidades a distintos tipos de usuarios.

7. Por lo general deben ser sistemas escalables y robustos.




• Arquitectura de Sistemas de Tipo Enterprise

Ha habido muchas formas de plantear una solución para este tipo de sistemas, y básicamente todo sistema enterprise tiene una estructura cliente / servidor, distribuido en capas verticales.


ArquitecturaFrameworks



• Frameworks

Hoy en día existen muchos frameworks que resuelven problemáticas asociadas a este tipo de arquitecturas. Desde plataformas tecnológicas, como las implementaciones de las especificaciones J2EE, la plataforma .Net de Microsoft, hasta frameworks que atacan problemas parciales (persistencia, presentación, transporte, etc) permitiendo combinarlos para obtener una arquitectura completa.





Algunos de ellos son:Persistencia

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

Presentación• Struts • WebWork• Tapestry





Definiendo la Arquitectura• Criterios de Diseño

Las aplicaciones del tipo Enterprise, poseen un dominio complejo, con lógica de negocio compleja y muchas reglas de negocio, las cuales varían con el tiempo. La idea central es modelar el dominio utilizando programación orientada a objetos, obteniendo así, un modelo del dominio, formado por objetos muy similares a la realidad, que se rigen según las reglas de negocio.

Para poder acompañar los cambios del negocio, actualizando así el modelo del dominio, se buscó la manera de mantener este dominio lo mas aislado posible del resto de la aplicación, éste es el objetivo principal en este trabajo, es decir se buscó desacoplar lo más posible al modelo de dominio del resto de la aplicación.

ObjetivoIntroducciónArquitecuraCriterios de Diseño

CapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones


Para ello la arquitectura elegida es una arquitectura basada en capas lógicas (Layer Pattern), donde una de estas capas es la capa de modelo del dominio (Domain Model Layer), y ésta es la capa que buscamos que tenga el menor acoplamiento posible.

Entonces partiendo de una arquitectura cliente servidor, el primer paso es quitar toda la lógica de negocio de la capa de presentación, y volcarla en la capa de modelo del dominio. Separando así muy bien todo lo que tiene que ver con obtención de información y presentación al usuario, de la lógica del dominio modelado.






cd Ev olución de Capas 1

DataSource Layer

Presentation Layer

Domain Model Layer


En una aplicación, vamos a encontrar lógica y reglas de negocio del dominio modelado, y lógica y reglas de negocio de la aplicación particular en sí, de acuerdo a como ésta hace uso del dominio.

Se busca que la lógica del dominio quede en la capa de dominio, pero no la lógica de aplicación, ya que ésta no es parte del dominio sino de la aplicación que hace uso de él.

Por lo que ingresamos otra nueva capa, la Service Layer, que haciendo uso del dominio, brinda los servicios necesarios para satisfacer los requerimientos de la aplicación.







DataSource Layer

Domain Model Layer

Serv ice Layer

Presentation Layer


Aun vemos que la capa del modelo del dominio sigue teniendo cierto acople con la capa de datos. Queremos evitar este conocimiento desde el modelo a la capa de datos, es decir lo que ahora buscamos es que el modelo, no conozca la manera en que sus datos son persistidos o almacenados, en la capa de datos, ya que éste es un problema tecnológico que no tiene nada que ver con los problemas del dominio a resolver, lo que nos lleva a introducir una nueva capa entre ambas, ésta capa es la capa de persistencia.







Presentation Layer

Domain Model Layer

DataSource Layer

Serv ice Layer

Persistence Layer




cd Distribución de lógica sobre las Capas

DataSource Layer

Domain Model Layer

Persistence Layer

Presentation Layer

Serv ice Layer

Componentes de PresentaciónLógica de Presentación

Lógica de la AplicaciónReglas de negocio de la AplicaciónTransacciones de Negocio (Casos de Uso)

Modelo del DominioReglas de Negocio del Dominio

Logica de PersistenciaTransacciones del DBMS





Capas LógicasDefinida la arquitectura se analiza la implementación de cada capa lógica

• Capa de Servicio – Service LayerTambién denominada Fachada de Servicio (Facade) [Martin Fowler, 2003] [Marinescu 2002], es la encargada de brindar los servicios necesarios a la capa de presentación.

Contiene la lógica de la aplicación, en forma de transacciones de negocio.

Todos los servicios necesarios para la capa de presentación referidos al dominio estan expuestos en la interfaz de servicio, lo que permite separar fisicamente ambas capas y jugar el papel de interfaz remota en dichos casos.



• La capa de presentación conoce las interfaces de servicio y cuenta con una Factory de servicios (ServiceFactory), para obtener una implementación de dicha interfaces.

• Los parámetros intercambiados entre ambas capas son objetos DTO (Data Transfer Object) [Martin Fowler, 2003] que son objetos simples (POJOs) utilizados para el intercambio de información.

ObjetivoIntroducciónArquitecuraCapasServicio

Modelo de DominioPersistenciaPresentación

FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones


cd Figura 5

presentation

+ fwk

(from framework)

fwk

+ ActionServlet

+ EntityController

+ Invoker

+ PageController

(from presentation)

Servidor de Presentación (Web) Servidor de Aplicaciones

serv ice

+ BaseService

+ pequi

(from framework)

pequi

+ clientes

+ ot

+ personas

(from service)

ot

+ ComponenteService

+ EstadoDeOrdenService

+ EstadoDeProcesoService

+ MaterialService

+ NotaService

+ ObservacionService

+ OrdenDeTrabajoService

+ ProcesoService

+ SolicitanteService

+ TipoDeProcesoService

+ TipoMaterialService

+ TurnoService

(from pequi)

iserv ice

+ IBaseService

+ dtoEntities

+ pequi

(from framework)

pequi

+ clientes

+ ot

+ personas

(from iservice)

ot

+ IComponenteService

+ IEstadoDeOrdenService

+ IEstadoDeProcesoService

+ IMaterialService

+ INotaService

+ IObservacionService

+ IOrdenDeTrabajoService

+ IProcesoService

+ ISolicitanteService

+ ITipoDeProcesoService

+ ITipoMaterialService

+ ITurnoService

(from pequi)

dtoEntities

+ CustomData

+ pequi

(from iservice)

ot

+ ComponenteDTO

+ EstadoDeOrdenDTO

+ EstadoDeProcesoDTO

+ MaterialDTO

+ NotaDTO

+ ObservacionDTO

+ OrdenDeTrabajoDTO

+ ProcesoDTO

+ SolicitanteDTO

+ TipoDeProcesoDTO

+ TipoMaterialDTO

+ TurnoDTO

(from pequi)

remoting

+ client

+ server

(from framework)

client

Service

+ ServiceFactory

(from remoting)

serv er

+ ServicePublisher

(from remoting)

Servidor de Remoting (RMI)

ObjetivoIntroducciónArquitecuraCapasServicioModelo de DominioPersistenciaPresentación



• Servicios Locales y/o Remotos La capa de servicio puede ser desarrollada para una arquitectura local y/o remota. Se quiere que ésto sea transparente a la capa de presentación.

Clases de servicios del dominio

Clases genéricas del Framework

RMI - jdk

UnicastRemoteObject

BaseService

ConcreteService

«interface» Remote

«interface» IBaseService

«interface» IConcreteService

«realize»

«realize»




cd Figura 7

Presentation Serv iceFactory RMI Registry Serv icePublisher

System Administrator

Serv ice Serv ice2

Escenario de creación y registración de servicios.

Escenario de obtención de servicios. Caso Servicio LocalServidor de Presentación es el mismo que servidor de Aplicaciones y no es necesario un servidor RMI

Escenario de obtención de servicios. Caso Servicio Remoto

SERVIDOR DE PRESENTACIÓN SERVIDOR RMI SERVIDOR DE APLICACIONES

runServices

getServicesInfo()

new

service

rebind(service)

new

service2rebind(service2)

getService(serviceName)

getServiceInfo(serviceName)

new

service2service2

getService(serviceName)

getServiceInfo(serviceName)

lookUp(serviceName)

serviceservice




• Capa de Modelo de Dominio - Domain Model LayerUno de los objetivos propuestos es que la capa de dominio este lo mas desacoplada posible del resto de las capas, por lo que no debe conocer a la capa de persistencia. La capa de persistencia es la que conoce al dominio y sabe como recuperar y alamacenar objetos de dominio.Sin embargo es necesario contar con cierta lógica relacionada a la persistencia, esta lógica puede estar ubicada en una clase base denominada DomainObject [Martin Fowler, 2003] como lo propone el patrón Domain SuperType, [Martin Fowler, 2003] donde cada objeto de dominio la extiende. Pero este esquema es un poco intrusivo ya que la clase de dominio debe sobrecargar ciertos métodos de DomainObject generando una fuerte dependencia de la capa de dominio a la capa de persistencia ya que DomainObject es una clase que forma parte de la capa de persistencia.

ObjetivoIntroducciónArquitecuraCapasServicioModelo del DominioPersistenciaPresentación



Para romper con esta dependencia recurrimos al uso del patrón de diseño Adapter.

cd Data Model

Serv ice Layer ClaseDominio

ClaseDominioAdaptada DomainObject




• Sin embargo este patrón no alcanza a resolver completamente el problema ya que los objetos del dominio necesitan ser manipulados en la capa de Persistencia de una manera genérica, es decir la capa de persistencia espera una interfaz común a todos los objetos de dominio para poder manejarlos abstractamente sin saber que clase de dominio concreta es.

• Por esta razón fue introducida la interfaz IDomainObject.




Serv ice Layer ClaseDominio

ClaseDominioAdaptada DomainObject

«interface»

IDomainObject

«realize»«realize»




• Capa de Persistencia – Persistence Layer

La capa de persistencia es la encargada de abstraer y resolver el acceso a datos a un motor de base de datos relacional.

Su objetivo es ser la única que conoce como son persistidos los objetos de dominio de la aplicación y como recuperarlos abstrayendo el choque de impedancias entre objetos y tablas relacionales.




La capa de persistencia, se expone a través de la interfaz IPersistenceBroker.La existencia de ésta interfaz es desacoplar como trabaja la capa de persistencia. Esta interfaz expone métodos como por ejemplo: crear un objecto de dominio, borrarlo, realizar búsquedas por clave y por distintos criterios.Para obtener una implementación de este broker de persistencia, se utiliza la factory PersistenceBrokerFactory. Con ella se obtiene a una instancia concreta del broker de persistencia. Este broker puede ser visto como un ORM, que se obtiene a través de una Factory de ORMs que cumplen con dicha interfaz.






cd Figura 10

Clase dePresentación

Clase deServ icio

PersistenceBrokerFactory PersistenceBroker

find(parámetros de búsqueda )

getInstance(PersistenceBrokerName)new

aPersistenceBrokeraPersistenceBroker

newUnitOfWork

findAll(Criterio, Parámetros)

aCollection

toDTO(aCollection)

commitUnitOfWorkDTOCollection


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

Para evitar el uso de código SQL que puede necesitarse para las búsquedas por criterio predefinidas, se utilizó un esquema de Finders. Un Finder recibe un nombre y define una sentencia SQL con parámetros en un archivo xml. Luego un método de servicio puede solicitar los objetos resultantes de un Finder y el DataMapper puede obtener la sentencia SQL asociada al mismo.Esto permite que el código SQL este agrupado en estos files xml, permitiendo que sean facilmente modificables y actualizables.




Algunos de los requerimientos buscados para la capa de persistencia son los siguientes [Scott Ambler 1]

• Manejar distintos tipos de mecanismos de persistencia (Single, Concrect, y Table Inheritance)

• Encapsular los mecanismos de persistencia (utilizando métodos al estilo: save(obj), delete(obj), create(obj), retrieve(obj))

• Manejo de transacciones• Identificación de objetos• Utilización de Proxies• Posibilidad de realizar consultas




• Capa de Presentación – Presentation Layer

Esta es la capa que interactua con el usuario final, es la encargada de presentar la información y recolectarla para hacer uso de los servicios expuestos por la capa de servicio, para satisfacer los casos de uso de la aplicación.

En este trabajo se utilizó como tecnología principal una interfaz web, a través del uso de un browser. Pero la capa de servicio, puede ser consumida desde cualquier tecnología vinculada, como clientes ricos, dispositivos móviles, etc




Para la obtención de vistas (páginas jsp) se utiliza el patrón PageController que permite obtener una vista perteneciente a un módulo.Las vistas pertenecen a un módulo y están definidas en un xml (modules.xml)Cada vista obtenida por el PageController mantiene un estándar de encabezado y pie de página, en el encabezado se visualiza un nombre para la vista y el pie de página contiene una sección destinada a visualizar mensajes al usuario y una botonera con botones que toman diferentes acciones sobre la vista. Toda esta información es configurada en el archivo xml perteneciente a la vista.






cd Figuras PageController

PageControllerBrowser Cliente

/servlet/PageController?module=moduleName&view=viewName

getViewInfo(Module, View)

buildHeaderFooter()

html Page


Por otro lado vamos a ver que muchas de los casos de uso del negocio van a ser para el manejo de creación, modificación y borrado de entidades de negocio, (servicios básicos de abm de una entidad que expone la capa de servicio). Es decir vamos a tener muchas vistas relacionadas a los abms de entidades. Este manejo se generalizó a través de vistas para “Administración” (Managers) que permiten buscar la entidad a través del uso de filtros y eliminarla o editarla o crear una nueva, a través de la vistas para “Edición” y “Alta” (Editor y New) que permiten la modificación de la entidad, y la vista de Selección (Selector) que permite seleccionar una entidad para utilizarla en otra vista.Todas estas vistas para manejos de abm y selección son manejadas a través de un control llamado EntityManager, que a partir de un nombre de vista y tipo, presenta dicha vista para manejo de esa entidad a través de los métodos expuestos en la capa de servicio.




cd Figuras EntityController

Browser Cliente EntityController

/servlet/EntityController?entity=entityName&useCase=useCaseType

EntityInfo:= getEntityInfo()

buildPage(EntityInfo)

html Page




cd Caso de Estudio - Pequi

presentation

+ fwk

(from framework)

fwk

+ ActionServlet

+ EntityController

+ Invoker

+ PageController

(from presentation)

iserv ice

+ IBaseService

+ dtoEntities

+ pequi

(from framework)

dtoEntities

+ CustomData

+ pequi

(from iservice)

serv ice

+ BaseService

+ pequi

(from framework)

pequi

+ clientes

+ ot

+ personas

(from iservice)

ot

+ IComponenteService

+ IEstadoDeOrdenService

+ IEstadoDeProcesoService

+ IMaterialService

+ INotaService

+ IObservacionService

+ IOrdenDeTrabajoService

+ IProcesoService

+ ISolicitanteService

+ ITipoDeProcesoService

+ ITipoMaterialService

+ ITurnoService

(from pequi)

domainModel

+ fwk

(from framework)

fwk

+ pequi

(from domainModel)

pequi

+ clientes

+ ot

+ personas

(from fwk)

ot

+ ComponenteFwk

+ EstadoDeOrdenFwk

+ EstadoDeProcesoFwk

+ MaterialFwk

+ NotaFwk

+ ObservacionFwk

+ OrdenDeTrabajoFwk

+ ProcesoFwk

+ SolicitanteFwk

+ TipoDeProcesoFwk

+ TipoMaterialFwk

+ TurnoFwk

(from pequi)

pequi

+ clientes

+ ot

+ personas

(from service)

ot

+ ComponenteService

+ EstadoDeOrdenService

+ EstadoDeProcesoService

+ MaterialService

+ NotaService

+ ObservacionService

+ OrdenDeTrabajoService

+ ProcesoService

+ SolicitanteService

+ TipoDeProcesoService

+ TipoMaterialService

+ TurnoService

(from pequi)

persistence

+ caseStudy

+ fwk

(from framework)

caseStudy

+ pequi

(from persistence)

pequi

+ clientes

+ ot

+ personas

(from caseStudy)

ot

+ ComponenteMapper

+ EstadoDeOrdenMapper

+ EstadoDeProcesoMapper

+ MaterialMapper

+ NotaMapper

+ ObservacionMapper

+ OrdenDeTrabajo_pequi_ot_MaterialDomainObjectCollectionRelation

+ OrdenDeTrabajo_pequi_ot_Observacion_mtmDomainObjectCollectionRelation

+ OrdenDeTrabajo_pequi_ot_ProcesoDomainObjectCollectionRelation

+ OrdenDeTrabajoMapper

+ ProcesoMapper

+ SolicitanteMapper

+ TipoDeProcesoMapper

+ TipoMaterialMapper

+ Turno_pequi_personas_PersonaFisica_mtmDomainObjectCollectionRelation

+ TurnoMapper

(from pequi)

utils

+ caseStudy

+ exceptions

+ helpers

+ log

+ persistence

(from framework)

caseStudy

+ NonPersistenceBroker

+ PersistenceBrokerFactory

+ StringHelper

+ IKey

+ IPersistenceBroker

(from uti ls)exceptions

+ ApplicationException

+ BusinessLogicException

+ ConcurrencyException

+ ExpiredSessionException

+ InvalidSessionException

(from uti ls)

helpers

+ CesarEncriptCryptographyHelper

+ ClassHelper

+ ConvertHelper

+ IOHelper

+ NonEncriptCryptographyHelper

+ PhpHelper

+ Serializer

+ TypeHelper

+ XmlHelper

+ ICryptographyHelper

(from uti ls)

log

+ ConsoleLog

+ FileLog

+ Logger

+ ILog

(from uti ls)

persistence

+ StorageMediumException

+ IReaderStorageMedium

+ IStorageMedium

+ db

(from uti ls)

db

+ BDatos

+ BDatosException

(from persistence)

pequi

+ clientes

+ ot

+ personas

(from dtoEntities)

ot

+ ComponenteDTO

+ EstadoDeOrdenDTO

+ EstadoDeProcesoDTO

+ MaterialDTO

+ NotaDTO

+ ObservacionDTO

+ OrdenDeTrabajoDTO

+ ProcesoDTO

+ SolicitanteDTO

+ TipoDeProcesoDTO

+ TipoMaterialDTO

+ TurnoDTO

(from pequi)

fwk

+ Context

+ DomainObject

+ DomainObjectCollection

- DomainObjectCollectionIterator

- DomainObjectCollectionIterator

+ DomainObjectCollectionRelation

+ IdentityMap

+ Key

+ KeyGenerator

+ Mapper

+ PersistenceBroker

+ Registry

+ UnitOfWork

+ IDomainObject

+ IFinder

+ IKeyGenerator

(from persistence)

remoting

+ client

+ server

(from framework)

client

Service

+ ServiceFactory

(from remoting)

serv er

+ ServicePublisher

(from remoting)

«xml»

Finder

«xml»

Regsitry

«xml»

Modules

«xml»

Actions

«xml»

Presentation Serv ices

Application Serv ices

«xml»

Entites

ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetes

PatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones


Si se observa el código de la parte especializada se nota que la misma es repetitiva y que puede automatizarse.

Una opción de automatizarla es mediante reflection, es decir que en tiempo de ejecución las clases del framework agreguen el comportamiento dado, leyendo la información faltante desde archivos descriptores, y la otra opción es la de generación de código, es decir generar las clases necesarias que especializan al framework en tiempo de desarrollo.

ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados



Aspectos Relacionados

Seguridad Autenticación y Autorización (Control de Acceso)

• Autenticación : Es el proceso por el cual se verifica que alguien (un sistema o un usuario) es quien dice ser.

• Autorización : Es el proceso por el cual se distingue si una persona, una vez autenticada, tiene o no permiso de acceso a un recurso. Seguridad al nivel Servidor de PresentaciónSeguridad al nivel Servidor de Aplicaciones


SeguridadConcurrencia

TransaccionabilidadSesionesAuditoría ExcepcionesDespliegue


cd Control de Acceso

«interface»

caseStudy::IAccessControl

+ login( name, password) : Token+ logout(Token) : void+ checkValideSession(Token) : void+ checkPermission(Context) : void


• Concurrencia

La concurrencia al sistema se implementó a partir del manejo de threads que dispone el servidor web administrando servlets, mediante la generación de un nuevo thread frente a cada nuevo request.Para resolver los problemas generados por el acceso concurrente al sistema y evitar adaptaciones perdidas y lecturas inconsistentes se implementó un esquema de detección de estos escenarios.Para esto se balanceó la corrección de los datos y la responsibidad del sistema. Se utilizó un patrón que detecta errores y genera avisos de que la transacción tuvo problemas y hay que rehacerla. El patrón utilizado es Optimistic Lock.






• TransaccionabilidadLa transaccionalidad del sistema se implementó mediante la administración de las transacciones de negocio por un patrón llamado Unit of Work. El mismo lleva un registro de los objetos que participaron en la transacción y de que forma lo han hecho, y frente a un comando commit, genera las acciones para mantener la consistencia entre dichos objetos y los de la base de datos.






• Sesiones

La sesión puede administrarse en el cliente, el servidor de aplicación, la base de datos, la memoria del web server

Se optó por utilizar sesión en el web server para mantener información de contexto vinculada a la seguridad, y si es necesario para vistas que necesiten hacer uso de ella, pero no compartir sesión entre distintas capas.

Compartir sesión entre las capas, hace que sea difícil escalar la aplicación mediante el uso de mas servidores, ya que si comparten sesión dos servidores, se genera un vínculo entre ellos, dificultando por ejemplo cambiar una petición (por balanceo de carga) a otro servidor de aplicaciones que se encuentra con menor carga de procesamiento en un instante dado.






• AuditoríaLa auditoría del sistema debería incluirse en la capa de servicio, ya que este es el punto de acceso a los mismos, antes de ejecutar el servicio y justo despues de autorizar, podría loguearse que servicio y con que parámetros utilizó cierto usuario, mas información adicional como fecha, hora, ubicación física, etc






• Excepciones

Inicialmente se pueden clasificar las excepciones en dos grandes jerarquías, una orientada a excepciones de negocio, es decir infracciones a reglas de negocio y otra orientada a excepciones ocurridas por errores en runtime en la aplicación, como ser la indisponibilidad de la red, de la base de datos, etc.

• De Negocio : BusinessLogicException• De Aplicación : ApplicationException






cd Excepciones

exceptions::ApplicationException

- innerException: Exception

+ ApplicationException()+ ApplicationException(String)+ ApplicationException(Exception)

exceptions::BusinessLogicException

- innerException: Exception

+ BusinessLogicException()+ BusinessLogicException(String)+ BusinessLogicException(Exception)

exceptions::ConcurrencyException

+ ConcurrencyException(String)+ ConcurrencyException(Exception, String)

Toda excepción producida por fallos en la aplicación que no se deban a reglas de negocio heredan de ApplicationException

La capa de presentación puede visualizarun mensaje genérico de error, pidiendo al usuario que se comunique con el servicio técnico de la aplicación.Esta excepción generalmente es logueada y se notifica al administrador.

Toda excepción que ocurra debido a que no se cumple con una regla de negocio hereda de BusinnessLogicException y el cliente (capa de presentación) decidirá que hacer con ella.Normalmente le informa al usuario visualizando el mensaje de la regla de negocio que no se cumple.

ConcurrencyException es la excepción que ocurre cuando se quiera actualizar, oborrar un objeto cuya versión no es la versión con que el usuario estuvo trabajando, es decir alguien modificó algún objeto interviniente mientras el lo estaba usando. Esto es por el uso de OptimisticLock para el manejo de concurrencia.

Exception

UnAuthorizedException

+ UnAuthorizedException()+ UnAuthorizedException(String)+ UnAuthorizedException(Exception)

Inv alidSessionException

+ InvalidSessionException(String)

UnAuthenticatedException

+ UnAuthenticatedException()+ UnAuthenticatedException(String)+ UnAuthenticatedException(Exception)

ExpiredSessionException

+ ExpiredSessionException(String)






• Despliegue

El framework permite que la aplicación sea desplegada físicamente en un único servidor o en varios servidores. Esta propiedad permite separar fisicamente la capa de presentación de la capa de negocio (en un Servidor de Presentación y otro Servidor de Aplicaciones).En estos casos, puede utilizarse un firewall para poner la limitación de que sólo el Servidor de Presentación tenga acceso al Servidor de Aplicaciones.Del mismo modo, si se separa físicamente la capa de persistencia de la capa de datos (en un Servidor de Aplicaciones y otro Servidor de Datos) puede limitarse con un firewall el acceso al Servidor de Datos y permitirle acceder solo al Servidor de Aplicaciones.






dd Despliegue

Cliente (Browser)

Serv idor Web

Serv idor de Aplicaciones

Serv idor de Base de Datos

«library»

Componentes::Back.jar

«library»

Componentes::Front.war

«library»

Componentes::Common.jar

Componentes : FrontComponentes : Common Componentes : Back

<< TCP / IP >>

<< HTTP >>






dd Despliegue Logico

Serv idor Web

Cliente (Browser)

Serv idor de Aplicaciones

Serv idor de Base de Datos

Presentation Layer

Service Interface

Domain ModelLayer

Persistence Layer

Service Layer

Service Interface

Persistence InterfaceData Source Layer

Proxy Proxy






Patrones Utilizados

• Identidad - Identity FieldIdentity Field

Identity Map

Foreign Key

Single Table Inheritance

Class Table Inheritance

Concrete Table Inheritance

Compound Key

Simple o Compuesta

Unica por base o clase

Unica por base o clase ojerarquia de clasesUnica por base o clase

o jerarquía de clases

Unico por base o clase, Simple o Compuesto

ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field

AsociacionesMapeos de Objetos a TablasConsistenciaUnit Of WorkRegistryAcceso a DatosConcurrenciaAjax - Active Front

GeneradorCaso de EstudioTrabajo a FuturoConclusiones


• Clave Simple • Clave Numérica• Única por Base de Datos• Comportamiento en DomainObjectAdaptada• Manejo de Clave administrado por tablas





• Asociaciones

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

En el caso de la asociación uno a uno, se añade el uso del patrón Lazy Load para evitar la carga transitiva de los objetos asociados. El mismo retrasa la carga de la instancia en forma transparente hasta el momento de ser utilizada. Esto está implementado en los getters de las clases DomainObjectAdaptadas ya que son redefinidos en ésta clase derivada para agregar este comportamiento.En las relaciones de uno a muchos, y muchos a muchos, se utilizó una AbstractDomainObjectCollection que es una variante del patrón Value List Holder.





Relación entre los patrones

cd Data Model

ForeignKey IdentityField

LazyLoad





Mapeos de objetos a tablas

• Single Table Inheritance • Class Table Inheritance• Concrete Table Inheritance

Se seleccionó la de Class Table Inheritance como mapeo por defecto para el generador de código (pero puede utilizarse cualquiera en el framework). Se seleccionó este tipo de mapeo porque administra los datos en forma normalizada en la base de datos y es mas directa la analogía entre una clase y una tabla.





Identity Field

Identity Map




Inheritance Mapper

Compound Key

Unica por base o portabla

Unica por base o tabla ojerarquia de clasesUnica por base o tabla o

jerarquía de clases

Unico por base o tabla, Simple o Compuesto

Unico?





• Consistencia

Se garantiza la consistencia entre objetos cargados de la base de datos.Se debe asegurar una sola instancia de cada objeto en una misma transacción, a efectos de evitar inconsistencias al cambiarlo. Este problema se resuelve aplicando el patrón Identity Map

• ¿ Tipo de Clave ?• ¿ Identity Map explícito o genérico ?• ¿ Cúantos ?• ¿ Dónde ?





finder Identity Map base de

datosAlgun Objeto

find(1)

found = get(1)

[found is null] found = select where id = 1

[found not null] found





• Patrones Relacionados

Identity Field

Identity Map


Data Mapper (Cuantos ???)

Compound Key

Optimistic Offline

Unit of Work

Registry

Unica por base o tabla ojerarquia de clases

Donde ?

Unico por base o tabla, Simple o Compuesto

Clave compuesta ?

Unico?

Donde ?





• Unidad de Trabajo

Cuando existen transacciones en las cuales se crean y modifican objetos, es indispensable mantener la consistencia de los objetos en memoria sobre los que se opera, y los datos correspondientes en la base de datos. Se debe conocer cuales son los cambios realizados para hacerlos persistentes. Por lo tanto es importante saber cuales objetos son nuevos, cuales fueron cargados desde la base de datos y no fueron alterados y cuales sí. Este problema es resuelto con el patrón Unit of Work. [Martin Fowler, 2003]





Ubicación, la Unit of Work puede estar en la sesión, puede pasarse como parámetro entre los objetos que la usan, o puede localizarse en la Registry. En este caso se optó de ponerlo en la Registry, la cual garantiza ser única por thread y facilita el acceso de la misma.

Session

UnitOfWork

New Objects DirtyObjects DeletedObjects





• Acceso a Servicios Comunes

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





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

:ClaseDominio :Mapper «Table»

:ClaseDominioTabla





• Control de Concurrencia

– Optimistic offline lock – Pessimistic offline lock

En el framework desarrollado se usó la variante Optimistic offline lock. Dicha implementación consta del versionado de los DomainObject y el control de la versión al momento del cierre de cada una de las transacciones del negocio. Si alguno de los objetos afectados dentro de dicha transacción no corresponde a la versión persistida, se genera una excepción de concurrencia.





• Ajax – Active Front

Generalmente el usuario obtiene una vista y trabaja con los datos obtenido por ella, modificando agregando, filtrando la información que contiene. En un entorno Web, ante cada acción se vuelve a enviar una acción la servidor yse recarga la vista (aunque ésta sea la misma, pero con otros datos) Este patrón, una vez cargada una vista, permite invocar los servicios sin recargar la vista. Obteniendo los datos resultantes para luego impactar con dicho resultado en la vista actual.









• Relaciones entre los patronescd Relaciones Entre Patrones II

Use Case

Use CaseActor

DomainModel

TransactionScript TableModule

ActiveRecord

RowData Gateway

TableData Gateway

DataMapper




Inheritance Mapper

Pessimitic Offline Lock

Optimistick Offline Lock

Coarse-Grained Lock

Layer SuperType

Identity Field

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 jerarquía

Finders

optimizacion de consultas

admin proxy/holder

control de versión

modelo simple

mapeo de jerarquía

acceso a DB

soportedeherencia

modelo complejo

control de concurrencia

root de jerarquía de objetos

modelo simple

Negocio Intermedio

Negocio Simple

acceso a DB

implementado en términos de

ensambla

genera

desacoplar clases intercambiadas

objetos distribuidosmapeo de jerarquía

administrar relaciones

implementado en términos de

identificación de DomainObjects

admin y almacenar info de identidad

carga tardía al navegar al root

admin y almacenar info de versión

alberga



Generador de Código

El generador de código genera, a partir de información de las clases de dominio, las clases que especializan a las clases base de frameworkPor ejemplo

cd Data Model

Mapper

# Save(IDomainObject) : void

PersonaMapper

# Save(IDomainObject) : void





Caso de Estudio• Descripción del dominio

Una empresa gráfica administra sus trabajos en Ordenes de Trabajo. Cada Orden de trabajo esta compuesta por Procesos, por ejemplo la Orden de Trabajo con nombre “Revista Noticiero”, esta compuesta por 2 procesos, uno de “Filmación” y otro de “Ploteo”. Todos los procesos deben realizarse para poder terminar la orden de trabajo. Cada proceso esta asignado a un Turno de trabajo. Los turnos de trabajo son tres, “mañana”, “tarde” y “noche”. Cada Turno esta compuesto por empleados de la empresa. Cada proceso puede tener una nota asociada, un Solicitante, y posee un conjunto de componentes, los componentes del trabajo, por ejemplo, la “tapa”, el “interior”, sus “pliegos”, etc Cada proceso tiene un “estado”, cuando todos los procesos de una orden están terminados, entonces la orden de trabajo estará terminada. Cada proceso tiene un tiempo asignado para su resolución.La orden de trabajo es para un cliente dado y tiene asociados un conjunto de materiales. Se almacenan la información asociada a los clientes y empleados, como domicilio, cuit, y teléfono.



Transición del Análisis al diseño• Casos de Uso




Modelo de Dominio


Trabajo a Futuro Agregar otros protocolos de comunicación entre capas• Agregar otras formas de mapeo de herencia de objetos a

relacional Clustering Administración de pool conexiones• Mejorar administración de colecciones en el dominio Integración con herramientas estándar (IDEs, Eclipse,

EA, etc) Mejorar la dinámica de generación ( refactoring del

dominio y adaptación automática de la base) Auditoría Generación automática de otras interfaces de

presentación Optimización de interacción con el motor de base de

datos



Conclusiones

• Separación en CapasSeparar problemas, trabajar en paralelo con diferentes roles.

• Uso de PatronesPermite hablar con mayor claridad y alto nivel a los participantes del desarrollo. No reinventar la rueda. Tener alternativas útiles a problemas conocidos.

• Uso de frameworksFacilitan el desarrollo de una aplicación, start up rápido, foco en el probleba del negocio.


Documents

Patrones de Diseño de Arquitecturas de Software Enterprise