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

Sistema Opetrativo

Hardware (comp y red)

Plataforma

Capa TCP/IP

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 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).

El paradigma cliente-servirdor (Por ej. la Web)

Programa servidor web

Webrecursos

requerimiento

respuesta

THE INTERNET

requerimientorespuesta

Programa cliente web

1- El servidor abre un canal por el cual comienza a “oir” peticiones.

SERVIDOR

Webrecursos

INTERNET

CLIENTE

1 ?

2- Un cliente que conoce esto, manda un mensaje y espera una respuesta

SERVIDOR

Webrecursos

INTERNET

CLIENTE

2

2

3- El servidor analiza el request y manda una respuesta de acuerdo al

protocolo preestablecido

SERVIDOR

Webresources

THE INTERNET

CLIENTE

3

3

Esto pasa a todo nivel !!!

El Modelo Cliente-servidor

Cliente

Cliente

Servidor1

Servidor2

Servidor3

invocación

resultado

Servicios provistos por múltiples servidores

Cliente

Cliente

Servidor1

Servidor2

Servidor1

Proxy servers y caches

Cliente

Cliente

Proxy/cache

Servidor2

Servidor1

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

DatosDatos

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 datosEl 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

A SERVER 1

When a server wants to start listening it must create a socketbound 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

UDP: communication with datagramsDATAGRAM: 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

www.waseda1.jp

message

4444

Once a server is listening, the client should create a datagramwith the server’s address, port number and, the message

www.waseda2.jp

?

Sending datagrams with UDP protocol

Then it should open a socket and send the datagramto 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

?

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

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

A SERVER A CLIENT

4444

www.waseda1.jp

3333

www.waseda2.jp

?

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

?

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

?

Ejemplo UDP en Javaimport 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 !!!!

A SERVER A CLIENT

4444

www.waseda1.jp

3333

www.waseda2.jp

bla bla bla bla

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

Sending 2nd bla again

Ack 2nd bla

No confirmation !!!

LOST !!!

The Window for improving efficiencyThe 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

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 TCPimport 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

- Reliable- Complete

- Valid in a certainperiod of time

- No need of speed

UDP TCP

- not complete info- fast- valid in a very short period of time- history not important

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

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

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 Javaimport 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) {} }}

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)

Cliente 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

Internet Address port number time object number interface

Estructura de los mensajes

Tipo de mensaje

requestIDobjectReferencemethodIdargumentos

int (0 = request, 1 = reply)intRemoteObjectRefintarreglo de bytes

Representación de una referencia remota de objeto

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

Call(parameters)

Receive results

RPC ServerRPC Client

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

RemoteObjectServerInvoca método

Recibe resultado

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

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

servidorservidor

InternetNaming.rebind(1)

Naming.lookup(2)

Objeto.metodo() (3)

import java.rmi.*;import java.rmi.server.*;import java.util.Date;

public class DateClient { public static void main( String args[] ) { try { RemoteDate dateobj = (RemoteDate)Naming.lookup( "rmi://"+args[0]+"/DateServer" ); Date d = dateobj.getDate(); System.out.println( "Date is: "+ d ); } catch ( Exception e ) { System.out.println(e);; } }}

import java.rmi.*;import java.rmi.server.*;import java.util.Date;

public class DateServer extends UnicastRemoteObject implements RemoteDate{ public DateServer() throws RemoteException { super(); }

public Date getDate() { System.out.println("a client's call !!"); return new Date(); }

public static void main( String args[] ) { try { DateServer ds = new DateServer(); Naming.rebind( "DateServer", ds ); System.out.println( "Date Server readys ..." ); } catch ( Exception e ) { System.out.println(e); } }}

import java.rmi.*;import java.util.Date;

public interface RemoteDate extends Remote { public Date getDate() throws RemoteException;}

Cliente Servidor

Interfaz

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)

¿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.

M idd leware

A plicaciones

S ervic iosde R ed

S ervic iosLoca les

S istem a O pera tivo

· In fraestructura IT

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.

M iddleware

Conceptos claves en CORBALos 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 Cobol

C lient S tubs Server Ske le tons

C C++ Java Cobol

IDL IDL IDL IDL

C orba O R B

Implementación de CORBA

iin terfazO R B

C orba O R B

InvocaciónSkeletonD inám ico

Skeletonestático

Stub C lienteID L

InvocaciónD inám ica

O bject Adapter

R epositorio deIm plem entaci

onesR epositoriode

Interfaces

C liente Im plem entación O bjetos

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

HTTP-Server (tools.jar)

Transaction Services (mahalo.jar)

JavaSpace (outriggger)Fiddler

MercuryNorm

¿ 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

X

write

Space

take

Existe solo aquí

Eventos Distribuidos

1- Crear un objeto Listener

2- Notificar al servidorsobre el interés en recibirlos eventos

3- Un objeto que coincide el template entra en el espacio

4- El oidor es notificado

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

Send Message

SenderReceiver

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 audio-video o par audio-audio o par video-video)