Decisiones al Desarrollar un Sistema Distribuido Qué servicio de la capa de transporte vamos a usar (TCP, UDP, o un middleware) Arquitectura del Software.

Presentación del tema: "Decisiones al Desarrollar un Sistema Distribuido Qué servicio de la capa de transporte vamos a usar (TCP, UDP, o un middleware) Arquitectura del Software."— Transcripción de la presentación:

1 Decisiones al Desarrollar un Sistema Distribuido Qué servicio de la capa de transporte vamos a usar (TCP, UDP, o un middleware) Arquitectura del Software : replicada, centralizada Arquitectura de las comunicaciones : centralizada, en red Diseño de los servidores : concurrentes, iterativos, con/sin estado Etc…

2 Layers de servicio de en sistemas distribuidos (modelo internet) Aplicaciones, servicios Middleware Sistema Opetrativo Hardware (comp y red) Plataforma Capa TCP/IP

3 Internet : Dos maneras básicas para transmitir mensajes (desde el punto de vista del programador) The UDP: User Defined Package: like writing a letter TCP or UDP

4 Hoy día hay una gran oferta de middleware que hace la programación de sistemas distribuidos más fácil Bibliotecas y servicios para el desarrollo (middleware) RPC, CORBA, RMI

5 Arquitecturas Cliente- Servidor ¿ Qué son las arquitecturas cliente/servidor ? –El modelo cliente/servidor (oidor/llamador) Porque TCP/IP no provee ningun mecanismo que automáticamente cree un programa que empeice a ejecutarse cuando llega un mensaje, un programa debe esperar a aceptar una comunicación ANTES que el requerimiento llegue. ¿ Existe otra forma de comunicarse ? –Multicasting (el servidor no tiene idea de los clientes) ¿ Qué son los ports de protocolo de una máquina ? –Es una dirección dentro de la máquina en la cual hay un programa servidor escuchando si hay algun cliente que quiere solicitar algún servicio que él presta. En máquinas UNIX hay “ports bien conocidos” para ciertos servicios. Para acceder a los servicios se debe seguir un cierto protocolo. Tanto el port como el protocolo deben ser publicados (conocidos).

6 El paradigma cliente-servirdor (Por ej. la Web) Programa servidor web Web recursos requerimiento respuesta THE INTERNET requerimiento respuesta Programa cliente web

7 1- El servidor abre un canal por el cual comienza a “oir” peticiones. SERVIDOR Web recursos INTERNET CLIENTE 1 ?

8 2- Un cliente que conoce esto, manda un mensaje y espera una respuesta SERVIDOR Web recursos INTERNET CLIENTE 2 2

9 3- El servidor analiza el request y manda una respuesta de acuerdo al protocolo preestablecido SERVIDOR Web resources THE INTERNET CLIENTE 3 3 Esto pasa a todo nivel !!!

10 El Modelo Cliente-servidor Cliente Servidor1 Servidor2 Servidor3 invocación resultado

11 Servicios provistos por múltiples servidores Cliente Servidor1 Servidor2 Servidor1

12 Proxy servers y caches Cliente Proxy/cache Servidor2 Servidor1

13 Aplicaciones “pares” Aplicacón + Coordinación Aplicacón + Coordinación Aplicacón + Coordinación

14 Arquitecturas de comunicaciones para Aplicaciones Distribuidas Servidores como Clientes –Los programas no siempre se comportan definitivamente como servidores puros o como clientes puros. Ej: un servidor de archivos que necesita un timestamp para registrar el último cambio. –Cuando todas las aplicaciones deben comportarse simultáneamente como servidores y clientes: ¿ cómo organizar las comunicaciones ? Cada aplicación abre un canal con otra aplicación (configuración red) Hay un servidor de comunicaciones y todoas las aplicaciones se comunican con él (configuración estrella).

15 Arquitectura de comunicación en red Cada par de aplicaciones que necesitan comunicarse abren un canal exclusivo Se abren a lo más n*(n-1)/2 canales para n aplicaciones Ventajas: –un canal exclusivo, no hay cuellos de botella Desventajas: –todas las aplicaciones deben saber cómo comunicarse con las demás. –La dinámica se vuelve más complicada (entrada/salida de aplicaciones)

16 Arquitectura de comunicación en estrella Las aplicaciones envían sus requerimientos de comunicación a un servidor y éste se encarga de mandarlas a su punto de destino final. Se abren a lo más n canales para n aplicaciones Ventajas: –Es más fácil manejar los parámetros de la comunicación Desventajas: –se puede saturar el servidor o las líneas.

17 Arquitectura de comunicación híbrida Hay un o más servidores que tienen registradas las direcciones de los hosts de los proceso que quieren comunicarse entre si Cuando un proceso quiere comunicarse con otro, pregunta al serividor dónde se encuentra (también puede ser quien se encuentra) con un nickname del que busca Luego establece una comunicación P2P

18 Arquitecturas Replicadas Cada computador tiene una copia de la aplicación y los datos Modificaciones locales se “distribuyen” a todos los participantes sincronización normalmente por eventos, no por estados Qué pasa con los que llegan más tarde ? La aplicación es normalmente la misma para todos la arquitectura de las comunicaciones puede ser centralizada o en red

19 Arquitectura replicada Datos vista datos Comp

20 Arquitecturas Semi Replicadas Los datos se mantienen centralizados en un servidor Cada cliente mantiene su propia “vista” actualizada de los datos modelo único, varias vistas y controlador replicados Uso de interfaces distintas frecuente Sincronizacion por estado y eventos igualmente posible Arquitectura de las comunicaciones normalmente centralizada (servidor de comunicaciones donde esta el modelo)

21 Arquitectura parcialmente replicada Datos

22 Arquitecturas Centralizadas Los datos y la vista se mantienen centralizados en un servidor Cada cliente aporta un servidor gráfico para desplegar la vista Todos comparten los mismos datos y las vistas Sincronización por nedio de estado (de la vista) Arquitectura de las comunicaciones simpre centralizada Necesidad de implementar filtros Provoca gran tráfico de datos (ya que se refresca la vista) De uso general

23 Arquitectura totalmente centralizada Vista / comandos

24 Implementación de Comunicaciones en red TCP/IP A “bajo” nivel (¿futuro “assembler de las comunicaciones”?) - Basado en la abstracción “sockets” y “ports” - Originalmente desarrollado para BSD UNIX pero presentes ahora en casi todos los sistemas (UNIX, LINUX, Macintosh OS, Windows NT) - El destino de un mensaje se establece por dirección de máquina y número de port (esto es verdad también en comunicaciones a más “alto nivel”) cada máquina tiene 2**16 ports - El origen del mensaje es a través de un socket en el cual “pocas” veces importa el port al cual está amarrado - Ports se asocian a servicios (también de comunicación) - Otros sistemas usan IP address y número de proceso (ventajas, desventajas ???)

25 Las 3 formas básicas UDP lo más parecido a lo que realmente pasa en la internet El cliente manda un paquete a través de un socket (amarrado a cualquier) dirigido a un ip-address y a un port. El servidor espera recibir paquetes en un port acordado TCP Simula un flujo de datos El cliente debe establecer primero una comunicación con el servidor, luego escribe. El servidor debe estar “esperando” la comunicación en un port acordado para luego leer y/o escribir en el flujo de datos abierto Multicast especial para comunicación en grupos cuando el grupo no está definido desde un principio (sponaneous networking) ya que es igual a UDP pero puede ser recibido por cualquier host que se interese (usa direcciones ip “generales”). Comunicaciones sin servidor central

26 The channel which server and client use to communicate (either int TCP or UDP) is called SOCKET A SERVER 1 When a server wants to start listening it must create a socket bound to a port. The port is specified with a number. A SERVER 2 A SERVER 3 www.thisserver.jp 4444 3333 5555 If a client wants to communicate with server 1 should try to communicate with computer www.thisserver.jp through port 4444

27 UDP: communication with datagrams DATAGRAM: an independent, self-contained message sent over the internet whose arrival, arrival time and content are not guaranteed (like regular mail in some countries....) A SERVER A CLIENT 4444 www.waseda1.jp message 4444 Once a server is listening, the client should create a datagram with the server’s address, port number and, the message www.waseda2.jp ?

28 Sending datagrams with UDP protocol Then it should open a socket and send the datagram to the internet. The “routing algorithm” will find the way to the target computer A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ?

29 Before the datagram leaves the client, it receives the address of the originating computer and the socket number A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ! Sending datagrams with UDP protocol

30 After the datagram is sent, the client computer may start hearing at the port created for sending the datagram if an answer from the server is expected A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ?

31 Sending datagrams with UDP protocol The server can extract the client’s address and port number to create another datagram with the answer A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp answer ?

32 Sending datagrams with UDP protocol Finally is sends the datagram with the answer to the “client”. When a datagram is sent there is no guarantee that it will arrive to the destination. If you want reliable communication you should provide a checking mechanism, or use... A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ?

33 Ejemplo UDP en Java import java.net.*; import java.io.*; public class UDPClient { public static void main(String args[]) { DatagramSocket socket = null; try { socket = new DatagramSocket(); byte[] m = args[0].getBytes(); InetAddress host = InetAddress.getByName(args[1]); int port = 6789; DatagramPacket req = new DatagraPacket(m, args[0].length, host, port); socket.send(req); byte[] n = new byte[1000]; DatagramPacket rep = new DatagraPacket(n, n.length); socket.receive(rep); System.out.println(“Received “+ new String (rep.getData())); } catch (SocketException e) { System.out.println(“Socket: “+e.getMessage()); } } catch (IOException e) { System.out.println(“IO: “+e.getMessage());} } finally { if (socket != null) socket.close(); } } import java.net.*; import java.io.*; public class UDPServer { public static void main(String args[]) { DatagramSocket socket = null; try { socket = new DatagramSocket(6789); byte[] n = new byte[1000]; while (true) { DatagramPacket req = new DatagraPacket(n, n.length); socket.receive(req); DatagramPacket rep = new DatagramPacket(req.getData(), req.getLength(), req.getAddress(), req.getPort()); socket.send(rep); } } catch (SocketException e) { System.out.println(“Socket: “+e.getMessage()); } } catch (IOException e) { System.out.println(“IO: “+e.getMessage());} } finally { if (socket != null) socket.close(); } }

34 Particularidades de UDP Tamaño del mensaje: el recibidor debe establecer el largo del mensaje a recibir, si es más chico que el que se mandó se trunca (se puede hasta 2 16 pero muchos ambientes lo limitan a 8 kilobytes) Bloqueo: la instrucción de send no bloquea Los datagramas son almacenados en una cola en el destino. Si no hay proceso esperándolos se descartan. Receive bloquea hasta que hay algo que leer de la cola o hasta el timeout Timeouts: se pueden definir sobre el socket, por default no hay setSoTimeout. Recibe de cualquiera: el receive no especifica de quién, así que el origen se saca del datagrama. Se puede abrir un DatagramSocket que sólo pueda mandar a una dirección y a un port connect (en qué casos es útil?)

35 TCP: communication with data flow After the client contacts the server, a reliable channel is established. After this, client and server may begin sending data through this channel. The other should be reading this data: They need a protocol !!!! A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp bla

36 TCP: How is reliability achieved ? The internet itself works only with the datagram paradigm. Internet frames are may “get lost” (destroyed): For every frame delivered carrying a part of the data flow there is a confirmation! Sending bla bla bla Sending 1st bla Ack 1st bla Sending 2nd bla Ack 2nd bla Sending 3rd bla Ack 3rd bla

37 What if a message get lost ? The server waits a certain amount of time. If it does not receive any confirmation it sends the message again. Sending bla bla bla Sending 1st bla Ack 1st bla Sending 2nd bla Sending 2nd bla again Ack 2nd bla No confirmation !!! LOST !!!

38 The Window for improving efficiency The transmitter will handle a set of not acknowledged packets Sending 1st bla Ack 1st bla Sending 2nd bla Ack 2nd bla Sending 3rd bla Ack 3rd bla

39 TCP or UDP Protocol: decision at the transport level What does it means for the programmer/designer: –By choosing one or the other protocol for establishing a connection between machines the programmer/designer decides about the reliability and speed of the communication. TCP provides high reliability: data are only sent if the communication was established. An underlying protocol is responsible for retranslating, ordering, eliminating duplicate packages UDP reflects just what the internet does with the packages: best effort delivery, no checking. –Also the programming style is quite different : With TCP the data is sent a flow (of bytes, in principle) which can be written, read as if they were stored in a file. With UDP the programmer must assemble the package and send it to the internet without knowing if it will arrive its pretended destination

40 Lo mismo con TCP import java.net.*; import java.io.*; public class TCPClient { public static void main(String args[]) { Socket socket = null; try { s = new Socket(args[1], 6789); DataInputStream in = new DataInputStram(s.getInputStream()); DataOutputStream out = new DataOutputStream(s.getOutputStream()); out.writeUTF(args[0]); String data = in.readUTF(); System.out.println(“Received “+ data); } catch (UnknownHostException e) { System.out.println(“Sock: “+e.getMessage()); } } catch (EOFException e) { System.out.println(“EOF: “+e.getMessage());} } catch (IOException e) { System.out.println(“IO: “+e.getMessage());} } finally { if (socket != null) try { socket.close(); } catch(IOException e) {} } import java.net.*; import java.io.*; public class UDPServer { public static void main(String args[]) { try { DataInputStream in = null; DataOutputStream out = null; ServerSocket ss = new ServerSocket(6789); while(true) { Socket s = ss.accept(); in = new DataInputStream(s.getInputStream()); out = new OutputStream(s.getOutputStream()); String data = in.readUTF(); out.writeUTF(data); } } catch (EOFException e) { System.out.println(“EOF: “+e.getMessage());} } catch (IOException e) { System.out.println(“IO: “+e.getMessage());} } finally { if (socket != null) try { socket.close(); } catch(IOException e) {} }

41 Particularidades de TCP Coincidencia de datos en los extremos : Bloqueo: hay chequeo (ack) Fallas : TCP trata de hacer coincidir las velocidades de escritura y lectura. Si el escribidor es muy rápido, trata de bloquearlo hasta que el lector haya consumido suficiente. Duplicación y orden de mensajes: los paquetes ip contienen identificadores correlativos que permiten al recibidor detectar duplicados o cambiados de orden Destino de los mensajes: como se abre una conexión virtual entre ambos extremos, no es necesario especificar a quién va ya que el socket se abre con un connect

42 Qué esconde TCP Tamaño del mensaje: Las aplicaciones deciden cuánto leer y cuánto escribir. El sistema subyacente decide cómo transmitirlo. Mensajes Perdidos: hay chequeo (ack) Control de flujo: TCP trata de hacer coincidir las velocidades de escritura y lectura. Si el escribidor es muy rápido, trata de bloquearlo hasta que el lector haya consumido suficiente. Duplicación y orden de mensajes: los paquetes ip contienen identificadores correlativos que permiten al recibidor detectar duplicados o cambiados de orden Destino de los mensajes: como se abre una conexión virtual entre ambos extremos, no es necesario especificar a quién va ya que el socket se abre con un connect

43 Problemas de TCP Coincidencia de datos: Lo que se mande por un lado y lo que se lea (formato) debe coincidir (en especial al mandar objetos). Bloqueo: hay que asegurarse que cundo se escribe pocos datos estos se manden si es necesario contar con ellos pronto o pueden bloquear la ejecución (buffer) La comunicación se establece de punto a punto, así que sólo se atiende a un cliente a la vez (a menos que se haga concurrente) Falla de la conexión: si se demora mucho en hacer el ack entonces la conexión se declara rota (se tira un IOException). En este sentido TCP no es más seguro de lo que la red lo es. El proceso usando la conexión no puede distinguir si la falla se debe a la red o a que el proceso par se cayó No puede saber después de la caída qué llego efectivamente a destino y qué no alcanzó a llegar

44 When to use one or another Considerations –TCP imposes a much higher load to the network than UDP (almost 6 times) –We can expect high package loss when the information travels trough many routers. –Inside a LAN UDP communications may be reliable is there is not much traffic. Although with some congestion we can expect some packages to be lost inside the LAN In general, it is recommended especially for beginners (but also to skilled programmers) to use only TCP to develop distributed applications. Not only it is more reliable but the programming style is also simpler. UDP is normally used if the application needs to implement hardware supported broadcasting or multicasting, or if the application cannot tolerate the overload of TCP

45 When do programmers should use UDP or TCP ? - TCP generates 6 times more traffic than UDP - It is also slower to send and receive the messages - Reliable - Complete - Valid in a certain period of time - No need of speed UDP TCP - not complete info - fast - valid in a very short period of time - history not important

46 Mark with a + the applications to use TCP and with a = those to use UDP E-Mail Video conference Temperature every second Web server and client Stock values every 5 seconds

47 Comunicación de Grupo con Multicast Provee: Tolerancia a fallas basada en la replicidad de servicios: un servicio replicado consiste en un grupo de servidores. El cliente manda el request a todos los servidores que realizan la misma operación. Encuentro de servicios de descubrimiento de servidores: clientes y servidores usan mensajes de multicast para localizar servicios presentes en la red para poder registrar sus interfaces y y hacer lookup de interfaces de otros servicios Mejor performance por datos replicados: a veces se replican los datos en los computadores cliente (cache) cuando estos varían el servidor manda mensajes por multicast Propagación de eventos de notificación: para notificar a procesos interesados en ciertos eventos que estos tuvieron lugar (jini)

48 Fallas en Multicast Ya que se basa en UDP puede pasar : Tolerancia a fallas basada en la replicac de servicios: Si los servidores parten de un mismo estado inicial y se coordinan con los updates en un orden preciso. Si un miembro no recibe el update o lo recibe en mal orden se vuelve inconsistente Encuentro de servicios de descubrimiento de servidores: esto no es problema si las peticiones de localización se hacen reiterativamente en tiempos regulares. Así se hace en Jini Mejor performance por datos replicados: si en vez de replicar operaciones en los datos lo que se replica es el dato mismo, estos pueden aparecer inconsistentemente en cada servidor Propagación de eventos de notificación: El servicio de anuncio acerca de nuevos servicios en la red provisto por Jini envia mensajes multicast reiterativos a tiempos regulares

49 import java.io.*; import java.net.*; public class MulticastClient { public static void main(String[] args) throws IOException { MulticastSocket socket = new MulticastSocket(4446); InetAddress address = InetAddress.getByName("224.2.2.3"); socket.joinGroup(address); byte[] buf = new byte[256]; DatagramPacket packet; while(true) { packet = new DatagramPacket(buf, buf.length); socket.receive(packet); String received = new String(packet.getData()); System.out.println("Received: " + received); try { Thread.currentThread().sleep(0); } catch (InterruptedException e) { } Ejemplo de Multicast en Java import java.io.*; import java.net.*; import java.util.*; public class MulticastServer { static public void main(String args[]) { DatagramSocket socket = null; BufferedReader in = null; boolean moreQuotes = true; try { socket = new DatagramSocket(); while (true) { InetAddress grupo = InetAddress.getByName("224.2.2.3"); for (int i=1; i< 1000; i++) { String dString = i+"--"+(InetAddress.getLocalHost()); byte[] buf = dString.getBytes(); DatagramPacket packet = new DatagramPacket(buf, buf.length, grupo, 4446); socket.send(packet); try { Thread.currentThread().sleep(200); } catch (InterruptedException e) {} } } catch (IOException e) {} }

50 El esquema request-reply Muchas veces cuando se usa TCP o UDP se modela el protocolo de comunicación entre cliente y servidor con el esquema de request-reply Son la base para implementar middleware como RMI, RPC, CORBA o algo parecido Se basan en un trio de primitivas de comunicación: doOperation, gerRequest y sendReply doOperation (wait) (continue) ClienteServidor getRequest (select object) (execute meth.) sendReplay

51 El esquema request-reply Aunque a Implementación UDP tiene ventajas: el acknowladge de TCP es innecesario ya que se hace un reply a cada request a nivel de aplicación se evitan los mensajes para la conexión el control de flujo es innecesario cuando los argumentos pasados son pequeños (caben en una trama) Un esquema en Java (Ejemplo) public byte[] doOperation(RemoteObjectref o, int methodID, byte args) manda una operación sobre un objeto y retorna el reply public byte[] getRequest() recibe un request de un cliente public void sendReply(byte[] reply, InetAddress clientHost, int clientPort) manda un reply a la dirección y port especificados

52 Internet Address port number time object number interface Estructura de los mensajes Tipo de mensaje requestID objectReference methodId argumentos int (0 = request, 1 = reply) int RemoteObjectRef int arreglo de bytes Representación de una referencia remota de objeto

53 Remote Procedure Calls (RPC) Motivatción: desarrollo del NFS (SUN) Un cliente puede llamar a una función en la aplicación corriendo en un servidor como si estuviera localmente implementada Pasa los parámetros y recibe los resultados en un formato apropiado (integer, string, float,..) eXternal Data Representation Serialización

54 Remote Procedure Calls El cliente detiene su ejecución hasta que la lamada retorna Call(parameters) Receive results RPC Server RPC Client Server framework: provisto por el middleware

55 Objetos Remotos Reemplazó rápidamente al paradigma anterior Una aplicación puede invocar un método de un objeto ubicado en otra JVM El archivo de interfaz permanece como el concepto clave en la implementación RemoteObjectServer Invoca método Recibe resultado

56 El archivo de interfaz Especifica el protocolo de la función remota: nombre, parámetros requeridos (cuantos y de que tipo), resultado (tipo). Se llama archivo de interfaz ya que el cliente obtiene de él la información que necesita Cliente usa la interfaz para complilar Servidor la implementa Server Cliente Interface definition file

57 El registro de Objetos remotos Es un programa que provee java llamado rmiregistry Se echa a correr en la máquina donde está el programa servidor del objeto remoto Cualquier cliente que quiera ocupar el objeto remoto debe pedirle a él una referencia al objeto remoto antes de ocuparlo => debe saber con qué nombre se registró y en qué máquina esta corriendo. Cliente rmiregistry servidor Internet Naming.rebind(1) Naming.lookup(2) Objeto.metodo() (3)

58 Cliente Servidor Interfaz

59 CORBA: Common Object Request Broker Arquitecture  CORBA es una especificación. No es un software o aplicación.  Auspiciado por Object Managament Group (OMG), para establecer una especificación de inter-operabilidad entre plataformas.  OMG es fundada en 1989, por American Airlines, Canon, Data General, HP, Philips Telecomunicaciones, Sun, 3Com y Unisys  Hay un gran número de implementaciones de CORBA. Estas son conocidas como Object Request Broker (ORB)

60 ¿que soluciona Corba? Aplicaciones. Procesos clientes y servidores que representan la lógica del negocio como objetos que pueden residir en distintas máquinas. Middleware. Soporte que permite la comunicación entre aplicaciones. Servicios de Red. Transporta la información entre computadores. Servicios Locales. Ejemplo, bases de datos y administradores de transacciones. Sistema Operativo. Provee servicios básicos de scheduling.

61 Definición Middleware Conjunto de servicios comunes no relacionado con “la lógica de negocio” que permite que aplicaciones servidoras y clientes interactuen con otras a través de una Red. En esencia el Middleware es el software que reside sobre la red, permitiendo software de aplicacion orientados sólo a “logica de negocio.

62 Conceptos claves en CORBA Los conceptos claves de CORBA son: 3Esencialmente especifica los servicios de middleware que serán usados por las aplicaciones (objetos). 3Existe una interfaz entre aplicaciones clientes y servidoras. Una lenguaje de definición de interfaz (IDL) ha sido definido específicamente para CORBA. 3Cualquier objeto puede ser un cliente, un servidor o ambos. Para efectos de descripción CORBA usa el modelo Cliente/Servidor. 3Soporta “static binding” y “dinamic binding” 3No conoce los detalles de las implementaciones fundamentales de los objetos. Un “object adapter” mapea modelos genéricos a implementaciones, siendo la principal manera en que las implementaciones de los objetos acceden los servicios provistos por el ORB (object Request Broker).

63 Diagrama conceptual de CORBA

64 Implementación de CORBA

65 Java Spaces

66 JavaSpaces es parte de Jini (spec.). Jini es una colección de especificación de servicios Ayuda a que ellos se encuentren mutuamente en la red Máquinas provistas de Jini pueden encontrar servicios en la red a la cual se conectan y ofrecen los suyos Las máquinas son clientes y servidores a la vez

67 Ejemplo ? ?

68 Services provistos por Jini Lookup Services (reggie) rmid HTTP-Server (tools.jar) Transaction Services (mahalo.jar) JavaSpace (outriggger) Fiddler Mercury Norm

69 ¿ Qué provee Jini concretamente ? Un espacio en el cual se pueden guardar objetos, recuperar o sacar una coipa de ellos. Métodos : write, read, take, (readIfExists, takeIfExists) Un mecanismo para proveer completitud de transacciones Un mecanismo para notificación de eventos

70 Los métodos write y read write Space read A copy

71 El método take X write Space take Existe solo aquí

72 Eventos Distribuidos 1- Crear un objeto Listener 2- Notificar al servidor sobre el interés en recibir los eventos 3- Un objeto que coincide el template entra en el espacio 4- El oidor es notificado

73 Transacciones Es un conjunto de operaciones que deben realizarse atómicamente, o sea, todas o ninguna. En JavaSpaces se puede definir un conjunto de operaciones write, read, y take que deban ser realizadas de esta manera. Para esto, un objeto transaction debe ser creado y pasado como parámetro con cualquier operación que deba pertenecer a la transacción Una vez que todas las opreaciones write, read, take, con la misma transacción han sido “ejecutadas” una operación commit va a ejecutar todas o nunguna. En el ultimo caso se lanza una exception

74 Comunicación basada en Mensajería El cliente NO detiene necesariamente su ejecución solo manda el mensaje El recibidor eventualmente leerá el mensaje del buffer Lo importante es la persistencia del mensaje Send Message Sender Receiver Buffer de Mensajes

75 En realidad... Existe un sistema que envía-recibe mensajes a cada lado Sender Receiver

76 Esquema de Mensajes con/sin Requerimientos Se manda un mensaje y se sigue sin importar qué pasó con él Se manda un mensaje y se espera hasta que el sistema receptor de mensajes del destinatario lo haya guardado Se manda un mensaje y se espera hasta que el proceso destinatario lo haya recibido Se manda un mensaje y se espera hasta que el proceso destinatario lo haya procesado

77 Comunicación basada en streams Interesantes son los sistemas en que existe un requerimiento de demora máxima y mínima de transmisión del mensaje punto a punto (Jitter) Esto es especialmente importante cuando la transmisión incluye más de un stream, los cuales son dependientes entre sí (par audio- video o par audio-audio o par video-video)