1 / 202

ARQUITECTURA TECNOLÓGICA DE APLICACIONES WEB – IN72J

Ezequiel T. Muñoz K. etmunoz@gmail.com , etmunoz@yahoo.com Ingeniero Civil Industrial, MBE (i) ‏ Departamento de Ingeniería Industrial Universidad de Chile. ARQUITECTURA TECNOLÓGICA DE APLICACIONES WEB – IN72J. Aplicaciones. Contexto Arquitectura. Arquitectura Empresarial CODELCO.

tanuja
Télécharger la présentation

ARQUITECTURA TECNOLÓGICA DE APLICACIONES WEB – IN72J

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Ezequiel T. Muñoz K. etmunoz@gmail.com, etmunoz@yahoo.com Ingeniero Civil Industrial, MBE (i)‏ Departamento de Ingeniería Industrial Universidad de Chile ARQUITECTURA TECNOLÓGICA DE APLICACIONES WEB – IN72J

  2. Aplicaciones

  3. Contexto Arquitectura Arquitectura Empresarial CODELCO Arquitectura del Negocio Arquitectura de Desarrollo e Integración Arquitectura de Calidad y Seguridad Estrategia del Negocio y Organización Arquitectura de Procesos de Negocios Arquitectura de Datos Arquitectura de Aplicaciones Arquitectura de Información Arquitectura de Aplicaciones (Portafolio)‏ Arquitectura de Operaciones Arquitectura de Aplicaciones (Diseño)‏ Arquitectura Técnica Arquitectura de Infraestructura Arquitectura de Operaciones

  4. Arquitectura Empresarial Arquitectura del Negocio Conductores del Negocio Visión del Negocio Misión Objetivos Impulsos Estratégicos Visión Futuro Oportunidades Maneja, Requiere Arquitectura de Información Guía el Desarrollo Arquitectura de Aplicaciones Se soporta con Arquitectura de Infraestructura

  5. Zachman

  6. Arquitectura Empresarial Arquitectura del Negocio Arquitectura de Información Arquitectura de Aplicaciones Arquitectura de Infraestructura • Procesos que soportan el Negocio • Funciones del Negocio • Organización que desarrolla el Negocio • Ubicaciones del Negocio • Factores y Conductores del Negocio • Componentes del Negocio • Modelo de Información • Conjuntos de Datos • Repositorios • Relación con Funciones del Negocio • Relación con Aplicaciones • Aplicaciones y sus Módulos • Relación con Procesos del Negocio • Relación entre Aplicaciones • Tecnología Empleada • Requerimientos de Interfaz • Hardware • Software • Redes de Comunicaciones • Telecomunicaciones • Radiocomunicaciones • Tecnología de Automatización

  7. La Estandarización Arquitectura Empresarial CODELCO Arquitectura del Negocio Arquitectura de Desarrollo e Integración Arquitectura de Calidad y Seguridad Estrategia del Negocio y Organización Arquitectura de Procesos de Negocios Arquitectura de Datos Arquitectura de Aplicaciones Arquitectura de Información Arquitectura de Aplicaciones (Portafolio)‏ Arquitectura de Operaciones Arquitectura de Aplicaciones (Diseño)‏ Arquitectura Técnica Arquitectura de Infraestructura Arquitectura de Operaciones Estándares de Negocio Estándares de Información Estándares de Desarrollo e Integración Estándares de Calidad y Seguridad Estándares de Aplicaciones Estándares de Infraestructura La estandarización es un proceso que apunta al manejo óptimo de los recursos TIC.

  8. Las Aplicaciones

  9. Tipos de componentes De cara a clasificar las diferentes arquitecturas, es necesario distinguir los tipos fundamentales de componentes que se dan en una aplicación: De presentación Se encarga de la entrada de datos y de mostrar los resultados De negocio Realiza las funciones propias de la aplicación Normalmente es necesario cierto procesamiento de datos De acceso a datos Permite comunicarse con el sistema de almacenamiento de datos (normalmente una base de datos, aunque también podría ser un sistema jerárquico de ficheros)

  10. Antecedentes Al principio, todo centralizado: Mainframe Toda la lógica estaba en un único ordenador central El usuario se comunicaba con él a través de terminales “tontas” Compartimiento de archivos Las primeras redes de ordenadores personales (PC) estaban basadas en arquitecturas de compartimiento de ficheros Había un servidor de ficheros y todo el trabajo se realizaba en la máquina local En los 90 cambia el modelo de computación, debido al aumento del número de usuarios y al advenimiento de las interfaces gráficas de usuario (GUI)‏

  11. Surgimiento de la arquitectura Cliente/Servidor Suele llevar asociada una base de datos (SGBD)‏ Hace falta algún mecanismo de comunicación distribuida Por ejemplo, Remote Procedure Calls (RPC)‏

  12. Esquema de la arquitectura C/S Aplicaciones clientes Base de datos

  13. Arquitectura Cliente/Servidor También conocida como arquitectura en dos capas, ya que consiste en dos partes que cooperan entre sí Los clientes se comunican directamente con el servidor Puede haber varios tipos: Que los clientes se encarguen únicamente de mostrar los resultados, y en el servidor se ejecute toda la lógica del negocio, de acceso a datos e incluso la mayor parte de la presentación El otro extremo sería cuando casi toda la lógica reside en el cliente, y el servidor sólo realiza el acceso a los datos P. ej., mediante el uso de applets de Java

  14. Características La base de datos compartida reside en un servidor con el suficiente espacio en disco y capacidad de procesamiento para soportar grandes volúmenes de información y consultas El término base de datos se usa aquí de modo genérico (puede referirse a cualquier origen de datos) Balance: ó FAT ‏CLIENT Ó FAT SERVER

  15. Ventajas (dos capas)‏ La mayoría de las organizaciones necesitan un control centralizado sobre los datos que asegure su consistencia Por el contrario, las aplicaciones que hacen uso de estos datos suelen requerir mucho menos control centralizado La mayoría se limitan a presentar estos datos de alguna forma La arquitectura en dos capas se adapta bien a estas necesidades

  16. Inconvenientes (dos capas)‏ La idea anterior de tener todos los datos compartidos y todo el procesamiento local no deja de ser una simplificación un tanto burda Muchos de los aspectos de procesamiento de una empresa están compartidos Las bases de datos distan mucho de proporcionar un lenguaje de programación “completo” Los datos no están encapsulados, por lo que sigue siendo necesario que el programador de las aplicaciones realice bastantes tareas de control de la integridad Todo ello hace que este enfoque sea difícil de mantener No resulta fácil cambiar la estructura de una base de datos de la que dependen un montón de aplicaciones Los procedimientos almacenados, aunque ayudan, no son la solución (cuidado con la portabilidad)

  17. Complejidad Cliente/Servidor

  18. El esquema anterior ha ido evolucionando en el tiempo y ha dado lugar a una arquitectura mejorada de tres capas (aunque realmente algo similar ya había sido propuesto a finales de los 70). Arquitectura de tres capas

  19. Esquema de la arquitectura Aplicaciones clientes Dominio Base de datos Esquema externo Esquema conceptual Esquema interno

  20. Nueva capa: Dominio Aparece una nueva capa: la de Dominio Representa realmente a la empresa Debería obviar tanto la estructura de los datos como su ubicación Es su contribución más importante Permite describir las aplicaciones basándose únicamente en el dominio a modelar También posibilita cambiar la estructura física de la base de datos y su ubicación sin afectar a las aplicaciones existentes La Tecnología de Objetos representa el mejor modo de implementar (modelar) dicha capa

  21. Arquitecturas de ‘n’ capas A la hora de la verdad (en el diseño detallado), las arquitecturas en tres capas suelen separarse aún más Así, es posible diferenciar entre lógica de presentación y de aplicación De un lado, estrictamente la interfaz de usuario De otro, los servicios utilizados tanto por la capa de presentación como por el dominio

  22. Despliegue Una arquitectura lógica de tres capas admite varias implementaciones físicas En el caso de las aplicaciones Web, normalmente los clientes “pesados” del modelo tradicional cliente/servidor se dividen en: Un cliente ligero Normalmente, un navegador Web encargado de mostrar las páginas HTML que le envía el servidor, y que sirve también para la entrada de datos La lógica de aplicación, que se traslada al servidor

  23. Ventajas Reutilización La aplicación está formada por una serie de módulos que se comunican a través de interfaces, y que cooperan entre sí para dar lugar al comportamiento deseado Idealmente, se trataría de objetos independientes que podrían ser empleados en otras aplicaciones Facilidad de mantenimiento Eficiencia en el acceso a los datos y en el uso de la red Posibilita la especialización de los desarrolladores

  24. Servidores de aplicaciones Es un programa que provee la infraestructura necesaria para las aplicaciones Web empresariales ¿Qué quiere decir esto? Que los programadores van a poder dedicarse casi en exclusiva a implementar la lógica del dominio, ya que servicios de uso común, como transacciones, seguridad, persistencia, etc. ya son proporcionados por el servidor Web Se ha convertido en una pieza de software clave para cualquier empresa dedicada al comercio electrónico Es una capa intermedia (middleware) que se sitúa entre el servidor Web y las aplicaciones y bases de datos subyacentes

  25. Visión general Servidor de aplicaciones (Transacciones, mensajería, servicios Web…)‏ CORBA J2EE .NET Aplicación cliente Aplicación cliente Aplicación cliente SGBD

  26. Motivación Comienzan a surgir cuando queda claro que las aplicaciones cliente/servidor no iban a ser escalables a un gran número de usuarios Debido a las características de los clientes “pesados” Se hacía necesario mover las reglas de negocio a algún lugar intermedio entre los clientes y la base de datos Empezaron a surgir productos para hacer esa tarea Cada compañía los llamaba de una forma distinta Servidores de transacciones, servidores de aplicaciones…

  27. Servicios proporcionados Creación y gestión de los componentes del servidor Clustering Equilibrado de carga Transacciones Seguridad Acceso a datos …

  28. Gestión de la sesión HTTP es un protocolo sin sesión No permite mantener una conexión abierta entre el cliente y el servidor más allá de lo que dura la transferencia del documento en cuestión En cualquier aplicación de comercio electrónico, es necesario poder identificar al usuario a través de su navegación por el sitio Web Autenticación, adición de productos al carrito de la compra, etc. El servidor ha de conservar información entre peticiones del usuario a lo largo de la duración de una sesión

  29. Gestión de la sesión La implementación “a mano” se complicaría enormemente en el caso de contar con varios servidores (equilibrado de carga)‏ La petición de un usuario registrado en la máquina A puede ser redirigida al servidor B Lo lógico es que sea el servidor de aplicaciones quien se encargue de gestionar la sesión Además, debería ser más eficiente que si lo programamos nosotros mismos

  30. Equilibrado de carga Por equilibrado de carga (load balancing) se entiende la capacidad de repartir el procesamiento entre distintos servidores Las peticiones de los clientes se redirigen a la máquina que más desocupada se encuentre en ese momento Mejora de rendimiento de la aplicación No es tan sencillo como añadir una nueva máquina y ya está Además de la escalabilidad, se consigue una mayor tolerancia a fallos Los servidores de aplicaciones proporcionan mecanismos de equilibrado de carga (aspecto clave para la escalabilidad)‏

  31. Acceso a datos Los servidores de aplicaciones proveen facilidades para administrar conexiones a bases de datos relacionales Oracle, SQL Server, DB2… Los componentes (las clases que implementan la lógica del negocio) acceden a ellas de forma estándar Independiente de la base de datos subyacente También suelen permitir acceder a otros tipos de fuentes de datos: Tales como distintos ERP (SAP, Vaan...), repositorios XML, etc. Los servidores de aplicaciones son también importantes, por tanto, como mecanismo de integración de sistemas heredados

  32. “Pooling” de conexiones Abrir una conexión a una base de datos suele ser un proceso costoso No es viable abrir una nueva conexión por cada consulta a la base de datos Penalizaría enormemente el rendimiento de la aplicación Los servidores de aplicaciones suelen contar con una serie de conexiones permanentemente abiertas que distribuye de forma transparente a los distintos procesos Se debería poder configurar el número de conexiones abiertas, e incluso la política de asignación

  33. Gestión transaccional Son un elemento básico de cualquier aplicación comercial Evitan que haya información inconsistente Sería complejísimo implementarlas “a mano” Con un servidor de aplicaciones que tenga esta característica, bastaría con indicarle dónde empieza y termina la transacción Encargándose él de deshacer los pasos intermedios en caso de un error del sistema Transacción: secuencia de pasos que, o se ejecutan todos, o si no el sistema queda en el estado original

  34. Tecnologías actuales Actualmente, las dos plataformas más comunes que implementan los servidores de aplicaciones son J2EE y, más recientemente, ha surgido .NET De hecho, hasta hace poco hablar de servidores de aplicaciones era prácticamente hablar de J2EE (aunque no debemos hacer tal asociación)‏

  35. Algunas Definiciones

  36. El “modelo de red“ muestra las principales componentes del sistema, donde están ubicadas y como se conectan unas con otras. La especificación de hardware y software describen estas componentes en detalle y apoya la compra y adquisición de productos para la implementación. Definiciones

  37. ¿Que es un Servidor? Es un programa cuyo input son peticiones recibidas por la red, y cuyo output es enviado por la red al cliente que envió la petición. Usualmente se le asocia a la máquina física, pero una máquina por si sola no hace nada... Las peticiones/respuestas estan formalizadas por el llamado Protocolo de transmisión. El lenguage de la transmisión y los pasos que se deben cumplir para enviar/recibir los datos. SERVIDOR PROTOCOLO petición CLIENTE respuesta

More Related