Arquitectura de Aplicaciones Empresariales. Lic. Esteban Cesar Calabria

Transcripción

1 Arquitectura de Aplicaciones Empresariales

2 Aplicaciones empresariales Temario Aplicaciones Empresariales Arquitectura Aplicaciones Empresariales Layering Negocio Persistencia Presentación Ejemplos

3 Aplicaciones empresariales

4 Qué es una aplicación empresarial? Aplicaciones que se utilizan en una empresa Se integran en los procesos de negocio de la misma Muestran, manipulan y almacenan grandes cantidades de información También conocidos como Sistemas de Información

5 Las aplicaciones Empresariales pueden incluir: Manejo del Stock de la empresa Sistemas Financieros Sistemas de Reservas Ventas, Compras Manejo de la Producción ERP (Enterprise Resource Planning)

6 NO son aplicaciones empresariales: Sistemas Operativos Juegos de Computadoras Sistemas Embebidos Aplicaciones Ofimáticas Aplicaciones P2P que funcionen por Internet. Sistemas Inteligentes

7

8 Características Importantes Manejar Datos Persistentes Manejan Grandes Cantidades de Datos Se accede a los datos concurrentemente Muchas Interfaces de Usuario Se integran con otras aplicaciones empresariales Contienen lógica de negocio compleja

9 Además Los datos trascienden a la aplicación Los datos cambian a medida que pasa el tiempo Muchos, *Muchos* Datos

10 Buenas Practicas Construcción Iterativa Dale al usuario apenas se tenga algo útil aunque no este completamente terminado

11 Arquitectura Aplicaciones Empresariales

12 Que entendemos por arquitectura División de alto nivel de un sistema en sus partes Decisiones que son difíciles de cambiar

13 Existen distintas visiones de arquitectura que cambian durante el ciclo de vida del sistema. Es algo subjetivo, un conocimiento compartido sobre el diseño del sistema en forma de los componentes mas importantes y como interactúan.

14 Consideraremos como definir la arquitectura de una aplicación empresarial a.. Definir como separaremos la aplicaciones empresariales en capas. Definir como estructuraremos la lógica de negocios. Definir como va a ser la presentación. Describir el mecanismo que utilizaremos para Transportar objetos de memoria a la base de datos Acordar como realizaremos el manejo de sesiones

15 Algunos factores que intervendrán son: El equipo de trabajo La plataforma Cantidad de usuarios Complejidad de la lógica de negocios Escalabilidad

16 Layering

17 Layering es una técnica muy común utilizada a la hora de diseñar software para dividir un sistema complejo. Se puede ver en Arquitectura de computadoras Arquitectura de Redes Arquitectura de Sistemas Operativos

18 Ejemplo de Layering en Computadoras Lenguaje de Programación Llamadas al Sistema Operativo Llamadas a Assembler Hardware

19 Ejemplo de Layering en Redes FTP se construye sobre.. TCP que se construye sobre.. IP que se construye sobre Ethernet

20

21 Ejemplo de Layering en sistemas operativos

22 Características Existe la idea de Capa Superior y Capa inferior. Una capa superior usa los servicios de la capa inferior inmediata Una capa inferior no sabe nada de la existencia de las capas superiores Generalmente la capa 4 usa servicios de la capa 3 que a su vez usa servicios de la capa 2, pero la capa 4 desconoce la existencia de la capa 2

23 Ventajas Se puede entender una capa en particular sin saber demasiado sobre el resto de las capas Por ejemplo se puede construir un servidor ftp sobre tcp sin saber en detalle como funciona ethernet. FTP TCP???

24 Ventajas Se pueden sustituir capas con implementaciones alternativas que ofrezcan los mismos servicios Aplicacion Interfaz Capa Persistencia Interfaz Capa Persistencia Interfaz Capa Persistencia Capa que lee datos desde un archivo Capa que lee los datos desde una base de datos Access Capa que lee los datos desde una base de Firebird

25 Ventajas Agregar capas intermedias permite minimizar dependencias entre las capa. Por ejemplo podemos cambiar ADSL por Cabmemodem, pero mientras funcione la capa de IP, no tenemos que modificar el servidor FTP

26 Ventaja Una vez que se construye una capa, se puede reutilizar con muchos servicios de alto nivel FTP HTTP TELNET SSH TCP Ventaja Las capas y los servicios que ofrecen son un buen lugar para definir estándars.

27 Desventaja No existen estándares en cuanto a la definición de los servicios e interfaces entre capaz para las aplicaciones empresariales. No existe un estándar/consenso para el desarrollo de aplicaciones empresariales de la misma forma que existe por ejemplo con TCP/IP Desventaja Capas adicionales pueden dañar la performance

28 Desventajas Las capas encapsulan algunas cosas, pero no todas. Cambios en Cascada. Ejemplo Para agregar un campo nuevo para mostrar en la interfaz gráfica debe modificarse la base de datos y por consiguiente todas las capas en el medio

29 Evolución de las capas en Aplicaciones Empresariales

30 Años 80 y antes Sistema Batch Arquitectura Pipe And Filter Aplicación que tomaba los datos y devolvía el resultado No se manejaba la idea de Capa

31 Años 90 Aparecen las aplicaciones Cliente- Servidor y comienza la idea de capas (en este caso tiers) El cliente Contiene la interfaz de usuario El servidor la base de datos relacional Herramientas como.. Delphi, Visual Basic, PowerBuilder facilitaban la creación de este tipos de aplicaciones con interfaz grafica SQL-Aware

32 Consecuencia Arquitectura cliente-servidor Para aplicaciones que requieran mostrar datos simplemente actualizar el contenido de la base de datos. Pocas y simples validaciones los sistemas client-server funcionan bien.

33 Cuando aparecen Cálculos. Reglas de negocio. Validaciones complejas...la situacion se complica.

34 Si se pone la lógica de negocio en las pantallas del cliente: Se es propenso terminar con código duplicado Si se escribe la lógica en stored procedures en la base de datos se termina con: código incomodo se dificulta cambiar de motor de base de datos

35 Paralelamente en los Años 90 Comienza a aparecer la idea de la programación orientada a objetos La comunidad de objetos proponía mover a una arquitectura de tres capas donde los objetos se encargaban de la lógica de negocios

36 Consecuencias Los sistemas comenzaban siendo simple y no justificaban la arquitectura de 3 capas Las herramientas para cliente-servidor dificultaban el desarrollo en 3 capas.

37 Mediados de los 90 Comienzan a aparecerlas aplicaciones Web. Comienza a tomar fuerza el lenguaje java. La lógica para aplicaciones cliente-servidor tuvo que ser repensada para aplicaciones Web En este contexto cobra más fuerza la idea de tener un diseño en 3 capas.

38 Como sigue la cosa La tecnología regirá bastante el rumbo de la arquitectura de las aplicaciones empresariales. Se asoma.. Ajax Smart Clients WPF Web 2.0.NET

39 En ingles se distinguen los términos Tier y Layer En castellano no hay una clara separación y suele referir a todo como capa Tier Implica una separación física Separar un sistema en capas no significa que todas tienen que correr en una PC o procesos distinto. Hablaremos de Capas lógicas

40 Layering En Aplicaciones Empresariales

41 Centraremos la discusión sobre Aplicaciones empresariales en tres Layers o capas lógicas Presentación Dominio, Domain, Lógica de Negocio, Capa de legocios Data Source (ej:persistencia)

42 Layer Presentación Dominio Data Source Responsabilidad Proveer lo necesario para mostrar información y manejar las acciones que genera el usuario Modela y resuelve la problemática para la que el sistema fue concebido Comunicación con: base de datos, sistemas de mensajería, manejadores de transacciones, otros paquetes

43 Layering Dividir la aplicación en capas es algo conceptual. Por ejemplo, para un problema simple puedo hacer todo en un mismo método o hacer un método para la presentación, un método para la persistencia y un método para la lógica de negocios A medida que el sistema evoluciona esos métodos se pueden ir transformando en clases independientes

44 Capa de Negocios

45 Capa de Negocios Modela y resuelve la problemática para la que el sistema fue concebido

46 Capa de Negocios Opciones Trabajar orientado a transacciones: y tener un metodo/objeto que se encargue de procesar cada transaccion del sistema: Aprovechar las funcionalidades de una plataforma que base mucha de su funcionalidad alrededor de un RecordSet Construir un modelo de negocios rico con objetos

47 Capa de Negocios Opciones Transaction Script Table Module Domain Model

48 Layer de Negocios

49 Capa de Persistencia

50 Capa de Persistencia Comunicación con: base de datos, sistemas de mensajería, manejadores de transacciones, otros paquetes Debido a su importancia nos concentraremos en la comunicación del objeto con la base de datos

51 Capa de Persistencia Opciones Un objeto que abstraiga el acceso a una tabla Un objeto que abstraiga el acceso a un registro de la base de datos Un objeto que abstraiga el acceso a un registro de la base de datos y contenta lógica de negocios Un objeto que transporta objetos de memoria a una base de datos

52 Capa de Persistencia Opciones Table Data Gateway / DAO Row Data Gateway Active Record Data Mapper

53 Capa Presentación

54 Capa Presentación Proveer lo necesario para mostrar información y manejar las acciones que genera el usuario

55 Presentación Gran parte de la arquitectura de nuestra aplicación se vera afectada dependiendo si decidimos realizar: Rich Clients Thin Clients Smart Clients

56 Capa de Persistencia Opciones Model View Controller Model View Presenter Template View Transform View

57 Donde ejecutar cada capa

58 La separación de capas es útil incluso si todas las capas corren en la misma PC. La decisión es dónde ejecutar el procesamiento En el cliente En un servidor Ej : tener un front-end HTML que use un web browser

59 En el servidor Ventajas Facilita el deployment Facilita solucionar errores Soluciona problemas de compatibilidad

60 En el Cliente Ventajas Tiempos de Respuesta (responsiveness) Operaciones Desconectadas Interfaces Gráficas ricas y complejas

61 Ejemplos

62 Sitio e-commerce La gente maneja y compra Muchos usuarios concurrentes Uso de los recursos eficientemente Escalable para permitir agregar mas hardware Lógica de negocios simple Presentación Web Genérica Integración Ej: Integración con sistema de inventario

63 Sistema de contratos de celulares Pocos usuarios Lógica de negocio compleja Muchas reglas y promociones distintas orientadas a tener ventaja competitiva Presentación mas compleja Ej: gráficos para tomar decisiones

64 Estas dos aplicaciones empresariales no se ajustan a la misma arquitectura. Elegir una arquitectura implica entender y conocer los problemas particulares del sistema y realizar un diseño que se ajuste.

65 Preguntas?

66 Fin