Download Desiciones
Document related concepts
no text concepts found
Transcript
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… Layers de servicio de en sistemas distribuidos (modelo internet) Aplicaciones, servicios Middleware Capa TCP/IP Sistema Opetrativo Hardware (comp y red) Plataforma 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 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 Arquitecturas ClienteServidor • ¿ 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). El paradigma cliente-servirdor (Por ej. la Web) Programa servidor web respuesta THE INTERNET requerimiento Web recursos respuesta requerimiento Programa cliente web 1- El servidor abre un canal por el cual comienza a “oir” peticiones. SERVIDOR 1 ? INTERNET Web recursos CLIENTE 2- Un cliente que conoce esto, manda un mensaje y espera una respuesta SERVIDOR 2 INTERNET Web recursos 2 CLIENTE 3- El servidor analiza el request y manda una respuesta de acuerdo al protocolo preestablecido SERVIDOR Web resources 3 THE INTERNET 3 Esto pasa a todo nivel !!! CLIENTE El Modelo Cliente-servidor invocación Servidor2 Cliente resultado Servidor1 Cliente Servidor3 Servicios provistos por múltiples servidores Servidor1 Cliente Servidor1 Cliente Servidor2 Proxy servers y caches Servidor1 Cliente Proxy/cache Cliente Servidor2 Aplicaciones “pares” Aplicacón + Coordinación Aplicacón + Coordinación Aplicacón + Coordinación 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). 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) 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. 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 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 Arquitectura replicada Datos Datos Datos vista datos Comp 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) Arquitectura parcialmente replicada Datos Datos Datos 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 Arquitectura totalmente centralizada Vista / comandos Vista / comandos 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 ???) 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 The channel which server and client use to communicate (either int TCP or UDP) is called SOCKET When a server wants to start listening it must create a socket bound to a port. The port is specified with a number. www.thisserver.jp A SERVER 1 4444 A SERVER 2 3333 A SERVER 3 5555 If a client wants to communicate with server 1 should try to communicate with computer www.thisserver.jp through port 4444 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....) Once a server is listening, the client should create a datagram with the server’s address, port number and, the message www.waseda1.jp A SERVER www.waseda2.jp A CLIENT ? 4444 www.waseda1.jp 4444 message 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 www.waseda1.jp A SERVER www.waseda2.jp A CLIENT ? 4444 3333 Sending datagrams with UDP protocol Before the datagram leaves the client, it receives the address of the originating computer and the socket number www.waseda1.jp A SERVER www.waseda2.jp A CLIENT ! 4444 3333 Sending datagrams with UDP protocol 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 www.waseda1.jp www.waseda2.jp ? A SERVER 4444 3333 A CLIENT Sending datagrams with UDP protocol The server can extract the client’s address and port number to create another datagram with the answer www.waseda1.jp www.waseda2.jp ? A SERVER 4444 answer 3333 A CLIENT 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 ... www.waseda1.jp www.waseda2.jp ? A SERVER 4444 3333 A CLIENT 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(); } } } 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 216 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?) 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 !!!! www.waseda2.jp www.waseda1.jp bla A SERVER 4444 bla bla bla A CLIENT 3333 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 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 LOST !!! No confirmation !!! Sending 2nd bla again Ack 2nd bla The Window for improving efficiency The transmitter will handle a set of not acknowledged packets Sending 1st bla Sending 2nd bla Sending 3rd bla Ack 1st bla Ack 2nd bla Ack 3rd bla 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 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) {} } } 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 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 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 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 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 UDP - not complete info - fast - valid in a very short period of time - history not important TCP - Reliable - Complete - Valid in a certain period of time - No need of speed Mark with a + the applications to use TCP and with a = those to use UDP E-Mail Video conference Web server and client Stock values every 5 seconds Temperature every second 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) 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 Ejemplo de Multicast en Java import java.io.*; import java.io.*; import java.net.*; import java.net.*; public class MulticastClient { import java.util.*; public static void main(String[] args) throws IOException { public class MulticastServer { MulticastSocket socket = new MulticastSocket(4446); static public void main(String args[]) { InetAddress address = DatagramSocket socket = null; InetAddress.getByName("224.2.2.3"); BufferedReader in = null; socket.joinGroup(address); boolean moreQuotes = true; byte[] buf = new byte[256]; try { DatagramPacket packet; socket = new DatagramSocket(); while (true) { while(true) { InetAddress grupo = InetAddress.getByName("224.2.2.3"); packet = new DatagramPacket(buf, buf.length); for (int i=1; i< 1000; i++) { socket.receive(packet); String dString = i+"--"+(InetAddress.getLocalHost()); byte[] buf = dString.getBytes(); String received = new String(packet.getData()); DatagramPacket packet = System.out.println("Received: " + received); new DatagramPacket(buf, buf.length, grupo, 4446); try { socket.send(packet); Thread.currentThread().sleep(0); } try { catch (InterruptedException e) { } Thread.currentThread().sleep(200); } } catch (InterruptedException e) {} } } } } catch (IOException e) {} } } 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 Cliente doOperation (wait) (continue) Servidor getRequest (select object) (execute meth.) sendReplay 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 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 Internet Address port number time object number interface 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 Remote Procedure Calls • El cliente detiene su ejecución hasta que la lamada retorna RPC Client RPC Server Call(parameters) Receive results Server framework: provisto por el middleware 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 Invoca método Recibe resultado RemoteObjectServer 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 Cliente usa la interfaz para complilar Interface definition file Server Servidor la implementa 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. Naming.lookup(2) rmiregistry Naming.rebind(1) Internet Cliente Objeto.metodo() (3) servidor Cliente Servidor import java.r i m p or t jav a .r import java.r i m p or t jav a .r import java.u i m p or t j a v a .u public class p u b li c cla ss implements p ub l i c s t at { { public Date try { { super(); R e m o t eD } ( R e m ot "rm i: public Date D ate d { S ySystem.ou s t e m. } return ne cat c h ( E } { S yste m. public stat } { try } { } DateSer Naming. System. import } import catch ( E } public } Interfaz publi } CORBA: Common Object Request Broker CORBA es una especificación. No es un software o aplicación. Arquitecture 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) ¿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. · Infraestructura IT Aplicaciones Middleware Servicios de Red Servicios Locales Sistema Operativo 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. Middleware Conceptos claves en CORBA Los conceptos claves de CORBA son: Esencialmente especifica los servicios de middleware que serán usados por las aplicaciones (objetos). Existe una interfaz entre aplicaciones clientes y servidoras. Una lenguaje de definición de interfaz (IDL) ha sido definido específicamente para CORBA. Cualquier objeto puede ser un cliente, un servidor o ambos. Para efectos de descripción CORBA usa el modelo Cliente/Servidor. Soporta “static binding” y “dinamic binding” No 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). Diagrama conceptual de CORBA C C++ Java C C++ Java Cobol IDL IDL IDL IDL Cobol Client Stubs Server Skeletons Corba ORB Implementación de CORBA Cliente Implementación Objetos Skeleton estático Repositorio de Interfaces Invocación Dinámica Stub Cliente IDL iinterfaz ORB Corba ORB Invocación Skeleton Dinámico Object Adapter Repositorio de Implementaci ones Java Spaces 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 Ejemplo ? Services provistos por Jini Lookup Services (reggie) rmid JavaSpace (outriggger) Fiddler Mercury Norm Transaction Services (mahalo.jar) HTTP-Server (tools.jar) ¿ 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 Los métodos write y read write Space read A copy El método take write Space X take Existe solo aquí Eventos Distribuidos 4- El oidor es notificado 1- Crear un objeto Listener 3- Un objeto que coincide el template entra en el espacio 2- Notificar al servidor sobre el interés en recibir los eventos 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 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 Receiver Sender Send Message Buffer de Mensajes En realidad ... • Existe un sistema que envía-recibe mensajes a cada lado Sender Receiver 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 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 audiovideo o par audio-audio o par video-video)