Download Desiciones

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)