Diseo de Patrones de Arquitecturas de Software Enterprise

1
Patrones de Diseño de Arquitecturas de Software
Enterprise

• Tesista Diego Fernando Montaldo
• Director Profesor Ing. Guillermo
  Pantaleo
• Noviembre 2005

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

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

• Objetivo
• Introducción
• Sistemas de Tipo Enterprise
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

4

• Características de los Sistemas de Tipo
  Enterprise
• Entre las características salientes de un
  sistema de tipo enterprise, según Rod Johnson,
  2003, Martin Fowler, 2003, Marinescu 2002 se
  pueden mencionar las siguientes
• Datos masivos (gran volumen) y persistentes.
• Lógica de negocio, lo que implica procesamiento
  de datos.
• Variedad de interfaces de usuario, lo que implica
  diversidad en la funcionalidad brindada.

• Objetivo
• Introducción
• Sistemas de Tipo Enterprise
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

5

• 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.
• 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.
• Por lo general deben ser sistemas escalables y
  robustos.

• Objetivo
• Introducción
• Sistemas de Tipo Enterprise
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

6

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

• Objetivo
• Introducción
• Sistemas de Tipo Enterprise
• Arquitectura
• Frameworks
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

7

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

• Objetivo
• Introducción
• Sistemas de Tipo Enterprise
• Arquitectura
• Frameworks
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

8

• 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

• Objetivo
• Introducción
• Sistemas de Tipo Enterprise
• Arquitectura
• Frameworks
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

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

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

10

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

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

11

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

12

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

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

13

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

14

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

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

15

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

16

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

17

• Objetivo
• Introducción
• Arquitecura
• Criterios de Diseño
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

18
Capas Lógicas

• Definida la arquitectura se analiza la
  implementación de cada capa lógica
• Capa de Servicio Service Layer
• Tambié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.

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

19

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

20

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

21

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

22

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

23

• Capa de Modelo de Dominio - Domain Model Layer
• Uno 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.

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo del Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

24

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo del Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

25

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo del Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

26

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo del Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

27

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

28

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

29

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

30

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

31

• 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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

32

• 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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

33

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

34

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

35

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

36

• Objetivo
• Introducción
• Arquitecura
• Capas
• Servicio
• Modelo de Dominio
• Persistencia
• Presentación
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

37

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

38

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

39
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ón
• Seguridad al nivel Servidor de Aplicaciones

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

40

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

41

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

42

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

43

• Auditoría
• La 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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

44

• 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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

45

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

46

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

47

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

48

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Paquetes
• Aspectos Relacionados
• Seguridad
• Concurrencia
• Transaccionabilidad
• Sesiones
• Auditoría
• Excepciones
• Despliegue
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

49
Patrones Utilizados

• Identidad - Identity Field

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

50

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

51

• 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 AbstractDomainObjectCollect
  ion que es una variante del patrón Value List
  Holder.

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

52

• Relación entre los patrones

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

53

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

54

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

55

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

56

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

57

• Patrones
• Relacionados

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

58

• 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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

59

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

60

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

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.

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

62

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

63

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

64

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Identity Field
• Asociaciones
• Mapeos de Objetos a Tablas
• Consistencia
• Unit Of Work
• Registry
• Acceso a Datos
• Concurrencia
• Ajax - Active Front
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

65

• Relaciones entre los patrones

66

67
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 framework
• Por ejemplo

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

68

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

70

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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

71

• Modelo de Dominio

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

72
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

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones

73
Conclusiones

• Separación en Capas
• Separar problemas, trabajar en paralelo con
  diferentes roles.
• Uso de Patrones
• Permite hablar con mayor claridad y alto nivel a
  los participantes del desarrollo. No reinventar
  la rueda. Tener alternativas útiles a problemas
  conocidos.
• Uso de frameworks
• Facilitan el desarrollo de una aplicación, start
  up rápido, foco en el probleba del negocio.

• Objetivo
• Introducción
• Arquitecura
• Capas
• Framework
• Patrones
• Generador
• Caso de Estudio
• Trabajo a Futuro
• Conclusiones