Aplicaciones Distribuidas.ppt
- 1. Infraestructura en la Web Curso de la carrera Especialización en Ingeniería Web UNIVERSIDAD CATÓLICA DE SANTIAGO DEL ESTERO Marzo- Abril de 2014 Dra. María de los Ángeles Martín Univ. Nac. de La Pampa martinma@ing.unlpam.edu.ar
- 2. Introducción al Curso • Docentes: Maria de los Ángeles Martín Hernán Molina • Objetivos: Que el alumno adquiera los conocimientos relacionados con: Los conceptos teóricos y prácticos básicos relacionados con la Tecnología Web. Las diferencias y semejanzas entre la Ingeniería de Software y la Ingeniería Web. Las funcionalidades básicas de la Web y sus herramientas asociadas.
- 3. Introducción al Curso • Aplicaciones Distribuidas en la Web Desarrollo de Aplicaciones Distribuidas Diseño Arquitectónico Tecnologías Curso Teórico y Práctico Trabajo final integrador
- 4. Bibliografía (conocimientos previos) • Distributed Systems, Concepts and Design , George Coulouris, Jean Dollimore, Tim Kindberg, Ed. Addison Wesley. • Data and Computer Communications - W. Stallings. Fifth Edition. Prentice Hall, NJ-USA, 1997. • Client/Server Survival Guide 3rd edition , Orfali, R., Harkey, D., Edwards, J. , 1999 • Distributed Systems: Principles and Paradigms – Andrew S Tanenbaum, Maarten Van Steen – Prentice Hall, 2007.
- 5. Bibliografía (Conceptos) • Software Engineering – Ian Sommerville - Addisson Wesley, 2004. • Ingenieria del Sosftware – Roger S. Pressman – Mc Graw Hill • World Wide Web Consortium, Reportes Técnicos: http://www.w3c.org/TR/ • Web Services Concepts, Architectures and Applications – Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju – Springer, 2004. • Apuntes de clases.
- 6. Bibliografía (Tecnologías) • Inside Corba. Thomas J. Mowbray, Willian A. Ruh. Addison-Wesley, 1997. • Building Web Services with Java, Making sense of XML, SOAP, WSDL, and UDDI – Steve Graham, Doug Davis, Simeon Simeonov, Glen Daniels, Peter Brittenham, Yuichi Nakamura, Paul Fremantle, Dieter Koenig, Claudia Zentner. – Sams Publishing, 2004. • Material disponible en el sitio de la facultad diversos.
- 7. Aplicaciones Distribuidas • Conceptos • Desafíos • Inconvenientes • Aspectos de diseño
- 8. Aplicaciones Distribuidas Una aplicación con distintos componentes que se ejecutan en entornos separados, normalmente en diferentes plataformas conectadas a través de una red
- 9. Sistemas Distribuidos • El concepto de sistema distribuido se opone al de sistema centralizado el basado en una sola CPU+memoria+disco, con uno o varios puestos de trabajo. • Varias CPUs desacopladas (unidas por una red)
- 10. Definición de sistema distribuido • Definición para empezar: “Un sistema distribuido es una colección de computadoras y sub-sistemas independientes que aparecen ante los usuarios del sistema como una única computadora”
- 11. Definición de sistema distribuido • Definición de Coulouris: “Un sistema distribuido es aquel en el que los componentes localizados en computadores, conectados en red, comunican y coordinan sus acciones únicamente mediante el paso de mensajes”
- 12. Tipos de sistemas distribuidos • Procesamiento distribuido • Datos distribuidos • Datos y procesos distribuidos • Objetos distribuidos
- 13. Ventajas de los ss.dd. • Prestaciones relativas: Resulta más rentable aumentar la potencia del sistema CPU comprando más ordenadores, que comprando una CPU más potente. • Velocidad: Un solo procesador no puede alcanzar tanta velocidad como queramos (existen límites físicos) • Escalabilidad: Si se desea más potencia, en un s.d. basta con comprar más microprocesadores. Además, los equipos antiguos pueden seguir dando servicio.
- 14. Ventajas de los ss.dd. • Aplicaciones distribuidas: Muchas aplicaciones actualmente sólo se conciben como distribuidas (correo electrónico, sistemas de información en Internet, trabajo corporativo, bancos, etc.) • Fiabilidad: Si una sola máquina se viene abajo, el sistema en conjunto puede continuar dando servicio. • Disponibilidad: Los servicios en el lugar y momento que se necesiten
- 15. Más ventajas • Compartición de recursos (discos, CPUs, impresoras...), Compartición de información • Flexibilidad de uso: todos los servicios están disponibles desde cualquier puesto la ejecución puede realizarse en otras máquinas que estén menos cargadas
- 16. Características problemáticas de un s.distr. • Comunicación no fiable: fallos en la red • Comunicación insegura • Comunicación costosa: ahora no tanto • Heterogeneidad de los nodos • Sincronización
- 17. Inconvenientes • Actualmente no hay software para gestionar apropiadamente un sistema distribuido • La probabilidad de fallos en partes del sistema es mayor • Hay más problemas de seguridad • Hay más problemas de administración • Nuestro sistema local puede verse afectado por fallos en máquinas de otros lugares
- 18. Desafío: Transparencia • Las Aplicaciones Distribuidas dan a los usuarios una visión de maquina única sobre un conjunto heterogéneo de redes y computadores. • Esta transparencia debe ser considerada sobre varios aspectos: . Ubicaciones . Nombres . Paralelismo
- 19. Aspectos de diseño: Transparencia Transparencia de localización Los recursos tienen nombres que no denotan la máquina en la que están Transparencia de migración Los recursos deben poder moverse de una posición a otra sin tener que cambiar sus nombres Transparencia de réplica Se debe poder mantener copias de los recursos sin que lo noten los usuarios Transparencia de concurrencia Varios usuarios deben poder compartir recursos sin problemas Transparencia de paralelismo Los programas deberían aprovechar el paralelismo sin intervención de los usuarios
- 20. Desafío: Heterogeneidad • Las Aplicaciones Distribuídas permiten que los usuarios accedan a recursos y servicios sobre un conjunto heterogéneo de redes y computadores. • Esta heterogeneidad se aplica a todos los siguientes elementos: . Redes. . Hardware de computadores. . Sistemas operativos. . Lenguajes de programación. . Implementaciones de diferentes desarrolladores.
- 21. Desafío: Heterogeneidad • Middleware: se aplica al software que provee una abstracción de programación que permite soslayar la heterogeneidad de los sistemas operativos y redes empleadas • Se crean para facilitar la creación de aplicaciones distribuidas • Ejemplos: Sun RPC, Java RMI y CORBA • CORBA, por ejemplo, proporciona invocación sobre objetos remotos, sin que el programador sepa cómo y por dónde se realiza la comunicación necesaria para realizarla
- 22. Desafío: Extensibilidad • La extensibilidad de un sistema de cómputo es la característica que determina si el sistema puede ser extendido y reimplementado en diversos aspectos. • La extensibilidad de los sistemas distribuidos se determina en primer lugar por el grado en el cual se pueden añadir nuevos servicios de compartición de recursos y ponerlos a disposición para el uso por una variedad de programas cliente.
- 23. Desafío: Seguridad • Entre los recursos de información que se ofrecen y se mantienen en los sistemas distribuidos, muchos tienen un alto valor intrínseco para sus usuarios. Por esto su seguridad es de considerable importancia. • La seguridad de los recursos de información tiene tres componentes: • confidencialidad • integridad • disponibilidad
- 24. Desafío: Escalabilidad • Las aplicaciones distribuidas operan efectiva y eficientemente en muchas escalas diferentes, desde pequeñas intranets a Internet. • Se dice que un sistema es escalable si conserva su efectividad cuando ocurre un incremento significativo en el número de recursos y el número de usuarios.
- 25. Aspectos de diseño: Escalabilidad • hay que evitar: los componentes centralizados: p.ej. un supercomputador servidor central tablas –bases de datos- centralizadas algoritmos centralizados: hay que intentar que: ninguna máquina tenga información global acerca del estado del sistema las máquinas tomen decisiones solo en base a la información local no se confíe en un reloj global
- 26. Desafío: Escalabilidad • Retos: • Control del costo de los recursos físicos. • Control de las pérdidas de prestaciones. • Prevención de desbordamiento de recursos software. • Evitar cuellos de botella de prestaciones
- 27. Aspectos de diseño: Confiabilidad • Si alguna máquina falla, alguna otra máquina se encargue del trabajo • En teoría la confiabilidad total del sistema debería ser la suma de la confiabilidad de los distintos componentes • En la práctica esto no suele ser así: “un s.d. es aquel del cual no puedo obtener un trabajo debido a que cierta máquina de la cual nueca he oído se ha roto”, Leslie Lamport • Disponibilidad: la fracción de tiempo en que se puede utilizar el sistema • Tolerancia a fallos: ¿cómo de bien tolera el sistema los fallos? Si un servidor falla y se rearranca ¿se recupera el sistema fácilmente?
- 28. Aspectos de diseño: Eficiencia • Eficiencia: además de transparente y confiable, un s.d. debe ser rápido y eficiente • A este respecto, en los s.d. es muy importante la velocidad de la red utilizada. • Los cálculos pueden ser de grano fino (p.ej sumar dos números) o de grano grueso • Para cálculos de grano fino no compensa que se realicen en otras máquinas, porque se tarda más en la comunicación que en el cálculo
- 29. Transacciones atómicas • Necesitamos una operación de mayor nivel, de mayor capacidad • Tal abstracción existe y se utiliza mucho en sistemas distribuidos: la transacción atómica • Supongamos que queremos viajar de Las Palmas a Bata (ciudad de Guinea Ecuatorial) • Iremos a la agencia de viajes para intentar reservar un billete a Madrid. Lo conseguimos • Luego intentaremos reservar un billete de Madrid a Malabo, (en fecha posterior al del primer viaje, naturalmente). Lo conseguimos • Intentamos ahora buscar un vuelo de Malabo a Bata. Pero resulta que no hay disponibles • En ese caso deberíamos ser capaces de deshacer lo hecho, las dos reservas anteriores • O SE HACE TODO O NO SE HACE NADA
- 30. Transacciones atómicas • Ejemplo en el ámbito informático: supongamos un banco al que podemos conectarnos por Internet, con la intención de retirar dinero de nuestra cuenta para transferirlo a otra: Retirar(cantidad, cuenta1) Ingresar(cantidad, cuenta) • Si la conexión telefónica falla después de la primera operación pero antes de la segunda ? • El problema debe resolverse haciendo que ambas acciones constituyan una transacción atómica: o se hacen ambas o no se hace ninguna
- 31. Tolerancia a fallos • Un sistema falla cuando no cumple su especificación • Los fallos de un sistema pueden estar en un fallo en algún componente. Los fallos de componentes pueden ser: fallos transitorios: una erupción solar que inutiliza un momento un satélite?? fallos intermitentes: mal contacto en un cable,... fallos permanentes: circuito quemado, error software,...
- 32. Tolerancia a fallos • El método más usado en tolerancia a fallos es el empleo de redundancia • La redundancia puede ser: de información: p.ej. añadiendo bits con código de Hamming que permita recuperar errores de tiempo: se realiza una acción, y en caso necesario, se repite en el tiempo. P.ej. la transacción atómica. La redundancia en el tiempo es muy útil en fallos intermitentes y transitorios física: se agregan equipos o procesadores adicionales. Se puede hacer de dos formas: réplica activa respaldo primario
- 33. Comunicación en los ss.dd.
- 34. Comunicación en los ss.dd. • La diferencia más importante entre un s.d y un sistema con un solo procesador es la comunicación entre procesos • En un sistema con un procesador, la comunicación entre procesos supone de manera implícita la existencia de memoria compartida • Incluso la forma más básica de sincronización, el semáforo, supone la existencia de una variable compartida (la propia variable del semáforo) • En los ss.dd. no contamos con esa memoria compartida, hemos de replantear la comunicación de procesos desde cero
- 35. Comunicación en los ss.dd. • Debido a la ausencia de memoria compartida, la comunicación en los ss.dd. se basa en la transferencia de mensajes a través de la red • Las redes se suelen estudiar en base al modelo de referencia para interconexión de sistemas abiertos (OSI) • El modelo OSI divide en 7 capas los diferentes elementos y servicios que intervienen en las comunicaciones
- 36. Comunicación en los ss.dd. • Tipo de conexión: circuito virtual u orientado a conexión: al conectar se realiza una búsqueda de un camino libre entre origen y destino. Se mantiene el camino en toda la conexión no orientado a conexión: no se fija un camino. Cada paquete podrá ir por cualquier sitio. No se garantiza la recepción secuencial
- 37. El modelo cliente-servidor • Existen procesos servidores, que proporcionan cierto recurso o servicio, y procesos clientes que hacen solicitudes a los servidores • El servidor recibe peticiones y envía respuestas
- 38. El modelo cliente-servidor • Direccionamiento: ¿cuál es la dirección del servidor que debe usar el cliente? • Posibilidades: máquina.proceso el proceso servidor elige una dirección al azar, el cliente debe emitir un paquete especial de localización usar un servidor de nombres; el cliente interroga primero al servidor de nombres
- 39. El modelo cliente-servidor • Las primitivas de envío y recepción podrán ser: con bloqueo o síncronas sin bloqueo o asíncronas. ¿cómo saber que ya se puede volver a usar el buffer de envío? send con bloqueo hasta que el mensaje se envie send sin bloqueo, con copia del mensaje en buffer interno send sin bloqueo, con interrupción que señaliza que ya se puede usar el buffer
- 40. Inconvenientes • Actualmente no hay software para gestionar apropiadamente una aplicación distribuida. • La probabilidad de fallos en partes del sistema es mayor. • Hay más problemas de seguridad. • Hay más problemas de administración
- 41. Diseño de Aplicaciones Distribuidas • Requerimientos funcionales. Si todo lo que importara fuese la funcionalidad, cualquier software monolítico serviría, ... • Requerimientos no funcionales Transparencia Heterogeneidad Extensibilidad Seguridad Escalabilidad Confiabilidad Eficiencia Tolerancia a las fallas Transacciones atómicas
- 42. Diseño Arquitectónico • La medida en que un sistema alcanza sus requisitos no funcionales depende de las decisiones de arquitectura. • Las cualidades no funcionales del producto deben diseñarse como parte de la arquitectura. • Un cambio en la arquitectura que mejora una cualidad suele afectar las otras cualidades. • La arquitectura sólo puede permitir, no garantizar, que cualquier requisito de calidad no funcional se alcance.