SDIS 5.1-6

Los modelos de requisitos que debemos incluir al expresar el diseño de nuestra aplicación distribuida son los modelos... de seguridad, de interacción y de fallo. de interacción y de fallo. de interacción, de fallo y de comunicación. de prestaciones, de interacción y de fallo.

Los sistemas basados en colas de mensajes facilitan la implementación de modelos de comunicación del tipo... remote procedure call. publish/subscribe. tuple spaces. abstract groupware.

Las aplicaciones de tipo cliente-servidor populares en Internet como ftp, web, telnet, se implementan mediante... protocolos de texto. agentes móviles. sistemas peer-to-peer. servicios remotos.

Todo sistema distribuido, tal y como lo concebimos en esta materia, ha de comunicarse mediante un modelo de paso de mensajes, a la forma en que se concretan las características del paso de mensajes de nuestra aplicación lo denominamos... modelo de interacción. modelo arquitectónico. modelo de sincronización. modelo de fallos.

El elemento del middleware RPC que permite mantener el modelo de sincronización presente en la invocación de procedimientos no distribuida es... el stub del cliente. el stub (skeleton) del servidor. La infraestructura de sockets. el lenguaje de definición de interfaz.

¿A qué paradigma de aplicación distribuida pertenece un sistema donde ciertos procesos sólo administran recursos y otros sólo los utilizan?. Peer-to-Peer (P2P). Emisor-Receptor. Tanto C-S como P2P. Cliente-Servidor (C-S).

Uno de los inconvenientes del middleware es la complicación en el tratamiento de los diversos modos de fallo cuando... tratamos con otros niveles inferiores de aplicación. el sistema incurre en fallos y errores. conectamos aplicaciones sobre diferentes máquinas. empleamos distintos lenguajes de programación.

Las fluctuaciones o cortes en un caudal de datos provienen de... tasas de deriva excesivas. problemas del modelo de interacción. problemas de prestaciones del canal. una mala ocultación de fallos.

¿Podemos considerar que la repetición de un mismo mensaje sobre un servicio (por una tercera parte ajena) puede amenazar la seguridad del sistema?. No, pues en cualquier caso se considerará que proviene del mismo emisor. Sí, por ejemplo influyendo negativamente en las prestaciones del sistema. No, si no se suplanta la identidad del principal receptor. Sólo si se suplanta la identidad del principal emisor.

La forma habitual de medir el tiempo en nuestros sistemas, ya sean distribuidos o no, es mediante la relación de cada evento que acaece con un cierto timestamp (marca temporal) que nos permita la ordenación o la ubicación absoluta del evento en el eje temporal. En el caso de los "sistemas distribuidos asíncronos que utilizan internet", tenemos un gran problema, pues no existe un eje temporal absoluto que nos permita ordenar los eventos completamente, pues además de los errores en los relojes de cada componente físico del sistema, añadimos…. velocidades de proceso muy variables. el comportamiento imprevisible de las comunicaciones. la posibilidad de fallos bizantinos. un modelo de fallos incompleto.

Los servicios de red FTP y DNS son ejemplos físicos de una aplicación que obedece a un paradigma: De igual a igual. De igual a igual, pero con roles diferenciados. Cliente-Servidor, siempre que los roles no vengan asignados en el protocolo. Cliente-Servidor.

Los fallos por caída son especialmente dañinos, aunque podemos tratar de detectarlos principalmente mediante: Sondeo. Notificación de caída. Errores en el checksum de los mensajes. Asincronía en los relojes locales.

Decimos que el sistema se comporta erróneamente (error) cuando detectamos una desviación entre su comportamiento observado y cómo debería comportarse. Sabes bien que estos fallos son consecuencia de “fallas” o (fallos) en alguna parte del sistema…. Y con un solo fallo se produce un error en el sistema. Pero en el momento en que se produce un fallo el error es irrecuperable. Y hace falta más de un fallo distinto para que se produzca un error. Aunque no necesariamente un fallo debe provocar un error.

El modelo de fallo, en los sistemas distribuidos, es una parte de la documentación del diseño de la aplicación distribuida que ¿define?. Todas las formas posibles en que puede fallar un sistema. El modo en que se ven los fallos para un observador externo de la aplicación. Cuál es el abanico de fallos contemplados y cómo tratar con ellos. Los posibles errores del sistema y a qué fallos corresponden.

¿Qué tiempos intervienen en la latencia de una comunicación?. La velocidad del canal y el tiempo de transmisión del mensaje. El tiempo de transmisión del mensaje. El tiempo de transmisión del mensaje y el tiempo de propagación por los niveles software. El tiempo de acceso al canal, el tiempo de transmisión del mensaje y la propagación en los niveles software.

Las tres primitivas más básicas que permiten construir un espacio de objetos son…. depositar, leer y tomar. Tomar, notificar y leer. Tomar, notificar y reificar. Supervisar, notificar y depositar.

Las posibles amenazas de seguridad de un sistema se pueden clasificar en diversas categorías. En concreto la amenaza que consiste en la falsificación de servicios se encuadra dentro de la categoría de…. Amenazas a la disponibilidad del servicio. Amenazas a los procesos. Amenazas a la integridad de la seguridad del tráfico. Amenazas a los canales.

Los fallos de emisión son más frecuentes de lo que parece, pues nuestra aplicación descansa sobre una plataforma de comunicaciones que puede ser muy elaborada (por ejemplo, un servicio de mensajería) y pueden detectarse…. Sólo mediante prueba forense, posterior. Sólo desde el receptor, pues el emisor no podrá contactar con el receptor. Tanto desde el emisor como desde el receptor, con las pruebas adecuadas. Sólo desde el emisor, pues el receptor no podrá contactar con el emisor.

El que en cierto sistema los eventos puedan observarse desordenados con respecto a su generación se puede deber a diversas causas entre las que están…. velocidades de proceso muy variables, y retardos imprevisibles en la transmisión. la inclusión de timeouts. timeouts de procesamiento y recepción conocidos. retardos previsibles y tasas de deriva previsibles en los relojes.

En un fallo de los que denominamos bizantino…. son fácilmente detectables. los procesos caen y se detienen. los mensajes nunca llegan a recibirse. los componentes incumplen sus especificaciones posiblemente sin detenerse.

Entre los fallos por omisión que afectan al proceso, el más benigno es el…. fallo por rotura (o caída). fallo por omisión de envío. fallo y detención. fallo arbitrario.

Uno de los servicios auxiliares que dan soporte a cualquier middleware de mensajería es…. al servicio de notificación de mensajes. un ORB. las colas publish/subscribe. el protocolo Point-to-Point.

El modelo arquitectónico de base para una aplicación distribuida es…. previo al análisis de la aplicación. uno de los primeros elementos del diseño. posterior al diseño de la aplicación. un resultado del diseño detallado del sistema.

El modelo de interacción de una aplicación distribuida debe tratar la forma en que aparecen, entre otros, los siguientes aspectos…. las fluctuaciones, los identificadores de red y las derivas de los relojes. las fluctuaciones, las derivas de los relojes, y la atomicidad de las operaciones. las fluctuaciones, las derivas de los relojes y la inconsistencia de estado. la latencia de la red, las fluctuaciones y las derivas de los relojes.

Una práctica común cuando tratamos de detectar fallos de prestaciones en los procesos de un S.D. es…. sincronización frecuentes. sondeo con procesos de apoyo para descartar el canal. invalidaciones de relojes locales. paradas del sistema programadas.

Los fallos por omisión de recibimientos afectan…. a los procesos. al canal y a la temporización. la temporización. a los procesos y al canal.

¿Es cierto que el hecho de utilizar un protocolo sobre el nivel de transporte TCP/IP, presupone que estamos construyendo una aplicación cliente-servidor?. No, pues la asimetría inicial de TCP/IP sólo se aplica en la conexión. Sí, pues la asimetría inicial de TCP/IP no sólo se aplica en la conexión. Depende de la asimetría inicial. Todas son correctas.

La razón más importante para decidirse por un diseño basado en agentes móviles es: Que los procesos agente deben ejecutarse en distintos entornos de ejecución, remotos. Que los procesos agente deben ejecutarse en los mismos entornos de ejecución, no remotos. Que los procesos agente deben ejecutarse en los mismos entornos de ejecución, remotos. Que los procesos agente deben ejecutarse en los distintos entornos de ejecución, no remotos.

Cuando los procesos que componen todo el sistema distribuido interaccionan entre ellos de la misma forma, se trata de un modelo arquitectónico…. De igual a igual. De distinto a distinto. No se trata de ningún modelo arquitectónico. Dios jugando al tenis.

El paradigma de interacción de igual a igual…. Los procesos que componen el sistema distribuido interaccionan entre ellos de la misma forma. Los procesos que componen el sistema distribuido no interaccionan entre ellos de la misma forma. se basan en los requisitos de diseño. Dios jugando al basket.

El los modelos fundamentales de una aplicación distribuida plasman. requisitos del diseño de la aplicación. requisitos de eficiencia de la aplicación. requisitos de tecnología de la aplicación. requisitos de eficacia de la aplicación.

entre los fallos por omisión que afectan solo al proceso el mas benigno es el. fallo y detención. fallo y continuación. no hay fallo alguno. todos los fallos.

¿Es posible, en Java RMI, solicitar referencias a objetos que todavía no se han creado?. Sí, mediante el mecanismo de activación. Sí, con clases de factoría. No, pues siempre tienen que existir de antemano. No, pues es preciso registrarlos primero.

¿Es necesario que todos los métodos de una interfaz que extiende la interfaz Remote de JavaRMI declaren poder lanzar la excepción RemoteException?. No es necesario, pero si se recomienda que la lancen. No, no sería deseable que tuvieran que hacerlo. Sí, porque la plataforma puede fallar. Sí, porque si se produce algún error al compilar la clase se lanzará esa excepción.

En esencia un componente ORB de un sistema distribuido proporciona... un mecanismo de intermediación de objetos. un mecanismo de mensajería de alto nivel. un servicio web. un espacio de tuplas de objetos.

Cuando el programa lanzador ha creado los objetos remotos del servidor y los ha enlazado con el registro... el servidor termina. el middleware RMI se hace cargo de la ejecución del servidor. los objetos remotos sirven los métodos en ejecución en ese momento y terminan. el registro desenlaza el objeto remoto.

Las referencias a los objetos remotos que se envían como argumentos de invocaciones remotas se pasan... por valor. por referencia. por http:. por contenido.

IIOP... es un protocolo de integración de mensajes de la ONC. nos permite integrar Java RMI en CORBA. es un mecanismo de RPC de notificación de eventos. Es la implementación Internet del GIOP.

Las interfaces Java, para RMI, se usan para definir interfaces de servicios remotos, pero ¿sirven, por sí solas, para saber cómo ha de hacerse la serialización y deserialización de los objetos?. No, pues es preciso la cooperación del registro RMI. Sí, al igual en el IDL de CORBA. Sí, dado que contienen toda la información precisa. No, se precisa conocer su implementación.

Lo normal es que los objetos de tipo callback... se envíen como referencias en invocaciones remotas. se serialicen. se creen mediante métodos factoría. se registren en registros RMI remotos.

¿Se pueden comparar ROID (Remote Object Identifier)?... Sí, pues son únicos para cada clase remota en todo el sistema. Sí, pues son únicos para cada objeto remoto en todo el sistema. Sí, pero dentro de cada servidor. No, pues dependen de la máquina virtual donde se construyan.

La propiedad del servidor "java.rmi.server.codebase" permite, en condiciones idóneas... la descarga dinámica de las clases usadas por el servidor. conocer exactamente el formato de las referencias. indicar la ubicación del registro RMI. indicar el directorio donde están los objetos remotos.

Las invocaciones de objetos remotos…. deben desencadenarse desde threads independientes. son más eficientes cuanto más encadenadas. no pueden encadenarse. pueden encadenarse pero no es aconsejable.

¿Cómo se pasan los objetos locales como argumentos de métodos remotos, en Java RMI?. Por nombre. Por valor. Por referencia. Por http.

En un servidor de objetos remotos donde aparecen dos invocaciones remotas simultáneas, aparecen dos nuevos hilos activos…. en cada objeto remoto. además de los hilos activos de los clientes que efectúan las invocaciones. pero el número de hilos activos en el sistema RPC completo, en ese momento, es igual que antes. aunque nunca actúan sobre el mismo objeto remoto.

¿Qué patrón implementan las clases locales a los clientes de los objetos remotos, y que sirven de intermediarios entre los clientes y el middleware RMI?. Proxy. CORBA. RMI. PortForward.

¿Es posible que como consecuencia de una invocación RMI obtengamos un nuevo ROID?. Sí, tanto en Java como en CORBA lo permiten. No, solo lo permite CORBA. No, solo lo permite Java. No lo permite ninguna.

El mecanismo de invocación de métodos remotos de Java RMi implementa un mecanismo petición-respuesta…. Síncrono, bloqueante. Síncrono, no bloqueante. Asíncrono, bloqueante. Asíncrono, no bloqueante.