diseño de patrones de arquitecturas de software enterprise tesista : diego montaldo - director :...

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

• Implementar el framework y permitir la construcción de una aplicación base completa sobre el mismo a partir del conocimiento del dominio.

ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones


Introducción

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

ObjetivoIntroducciónSistemas de Tipo Enterprise

ArquitecuraCapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones


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

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




• Arquitectura de Sistemas de Tipo Enterprise• Frameworks

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


ArquitecturaFrameworks



Definiendo la Arquitectura

• Criterios de Diseño

1. Programación orientada a objetos2. Desacoplar lo más posible al modelo de

dominio del resto de la aplicación3. Arquitectura basada en capas lógicas (Layer

Pattern)

ObjetivoIntroducciónArquitecuraCriterios de Diseño

CapasFrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones




cd Ev olución de Capas 1

DataSource Layer

Presentation Layer

Domain Model Layer





DataSource Layer

Domain Model Layer

Serv ice Layer

Presentation Layer





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ógicas

Capa de Servicio – Service Layer

• Introducción• ServiceFactory• Data Transfer Object• Servicios Locales y/o Remotos • Unidad de Trabajo (Unit Of Work)



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

FrameworkPatronesGeneradorCaso de EstudioTrabajo a FuturoConclusiones


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 Layer

cd Data Model

Serv ice Layer ClaseDominio

ClaseDominioAdaptada DomainObject

ObjetivoIntroducciónArquitecuraCapasServicioModelo del DominioPersistenciaPresentación



Serv ice Layer ClaseDominio

ClaseDominioAdaptada DomainObject

«interface»

IDomainObject

«realize»«realize»

ObjetivoIntroducciónArquitecuraCapasServicioModelo del DominioPersistenciaPresentación



• Capa de Persistencia – Persistence Layer

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, Class 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

– Interfaz IPersistenceBroker– PersistenceBroker– Factory PersistenceBrokerFactory– Finders




• Capa de Presentación – Presentation LayerEn 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

– Introducción– PageController– EntityManager




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.

– Reflection– Generación de código

ObjetivoIntroducciónArquitecuraCapasFrameworkPaquetesAspectos Relacionados



Aspectos Relacionados

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

• Autenticación• Autorización

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


• ConcurrenciaImplementación

Detección de errores

• Transaccionabilidad Unit of Work

• Sesiones• Auditoría• Excepciones






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)






Desplieguedd 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 Field• Asociaciones – Foreing Key Mapping• Lógica de Negocio – Domain Model• Mapeos de objetos a tablas

– Single, Class , Concrete Table Inheritance– Inheritance Mappers

• Consistencia– Identity Map

• Unidad de Trabajo– Unit Of Work

• Acceso a Servicios Comunes – Registry

• Acceso a los Datos Persistentes– Data Mapper – Separated Interface, Lazy Load

• Control de Concurrencia – Optimistic offline lock

• Remote Façade, Data Transfer Objects• Ajax – Active Front - PageController

ObjetivoIntroducciónArquitecuraCapasFrameworkPatronesIdentity Field

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

GeneradorCaso de EstudioTrabajo a FuturoConclusiones


• Relaciones entre los patronescd Relaciones Entre Patrones II

Use Case

Use CaseActor

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

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.



Demo

diseño de patrones de arquitecturas de software enterprise tesista : diego montaldo - director :...

Documents