Clases de aplicaciones distribuidas

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.