Arquitectura de Aplicaciones Empresariales
Aplicaciones empresariales Temario Aplicaciones Empresariales Arquitectura Aplicaciones Empresariales Layering Negocio Persistencia Presentación Ejemplos
Aplicaciones empresariales
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
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)
NO son aplicaciones empresariales: Sistemas Operativos Juegos de Computadoras Sistemas Embebidos Aplicaciones Ofimáticas Aplicaciones P2P que funcionen por Internet. Sistemas Inteligentes
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
Además Los datos trascienden a la aplicación Los datos cambian a medida que pasa el tiempo Muchos, *Muchos* Datos
Buenas Practicas Construcción Iterativa Dale al usuario apenas se tenga algo útil aunque no este completamente terminado
Arquitectura Aplicaciones Empresariales
Que entendemos por arquitectura División de alto nivel de un sistema en sus partes Decisiones que son difíciles de cambiar
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.
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
Algunos factores que intervendrán son: El equipo de trabajo La plataforma Cantidad de usuarios Complejidad de la lógica de negocios Escalabilidad
Layering
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
Ejemplo de Layering en Computadoras Lenguaje de Programación Llamadas al Sistema Operativo Llamadas a Assembler Hardware
Ejemplo de Layering en Redes FTP se construye sobre.. TCP que se construye sobre.. IP que se construye sobre Ethernet
Ejemplo de Layering en sistemas operativos
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
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???
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
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
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.
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
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
Evolución de las capas en Aplicaciones Empresariales
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
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
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.
Cuando aparecen Cálculos. Reglas de negocio. Validaciones complejas...la situacion se complica.
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
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
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.
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.
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
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
Layering En Aplicaciones Empresariales
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)
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
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
Capa de Negocios
Capa de Negocios Modela y resuelve la problemática para la que el sistema fue concebido
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
Capa de Negocios Opciones Transaction Script Table Module Domain Model
Layer de Negocios
Capa de Persistencia
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
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
Capa de Persistencia Opciones Table Data Gateway / DAO Row Data Gateway Active Record Data Mapper
Capa Presentación
Capa Presentación Proveer lo necesario para mostrar información y manejar las acciones que genera el usuario
Presentación Gran parte de la arquitectura de nuestra aplicación se vera afectada dependiendo si decidimos realizar: Rich Clients Thin Clients Smart Clients
Capa de Persistencia Opciones Model View Controller Model View Presenter Template View Transform View
Donde ejecutar cada capa
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
En el servidor Ventajas Facilita el deployment Facilita solucionar errores Soluciona problemas de compatibilidad
En el Cliente Ventajas Tiempos de Respuesta (responsiveness) Operaciones Desconectadas Interfaces Gráficas ricas y complejas
Ejemplos
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
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
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.
Preguntas?
Fin