1. Sisteme distribuite Continutul capitolului:
Stiluri arhitecturale pentru aplicatii distribuite
Tipare utilizate in realizarea infrastructurii pentru sisteme distribuite:
Client-Dispatcher-Server
Forwarder-Receiver
Remote Proxy
Broker
Exemple de tehnologii de middleware care implementeaza tiparul Broker: Java RMI, CORBA, .NET Remoting

2. Arhitecturi de aplicatii distribuite
Client-Server:
Servicii distribuite, furnizate de Servere, care sunt utilizate de Clienti
Clientii sunt diferiti de Servere
Exemplu: Biblioteca online de multimedia
N-Tiers:
Combinatie intre Layered si Client-Server
Cazul tipic: 3-Tiers:
Exemplu: Internet banking
Peer-to-Peer:
Toti participantii sunt egali
Fiecare Peer furnizeaza unele servicii si utilizeaza alte servicii
Variante: p2p semicentralizat
Exemplu: Sistem de peer to peer filesharing

3. Exemplu Client-Server
Internet
Sommerville
Catalogue V
ideo
Pictur e W
eb serv er
serv er
serv er
serv er
Library
Film clip
Dig
itis ed
Film and ca
talo
gue
files
photo g r a
phs
photo info.
[Sommerville]

4. Exemplu 3-Tiers Presentation Layer Application Processing Layer Data
Management Layer
Client
HTTP interaction
Web server
Database server
Client
SQL query
Customer
Account service S QL
account
provision
database
Sommerville
Client
Client
[Sommerville]

5. Suport pentru aplicatii distribuite
Middleware:
Infrastructura care suporta realizarea aplicatiilor distribuite
De obicei realizata de software “off-the-shelf”
Incercari de standardizare: CORBA
[POSA2]

6. Rolul middleware Calitati dorite ale sistemelor distribuite:
Separation of concerns: logica aplicatiei sa fie separata de aspectele legate de realizarea comunicatiei la distanta => “cineva” trebuie sa rezolve stabilirea canalului de comunicatie si eventualele transformari ale formatului datelor
Location independence: interactiunile client-server sa se desfasoare la fel, independent de locatia serverului => “cineva” trebuie sa rezolve localizarea serverului
Location transparence: interactiunea unui client cu un server la distanta sa aiba loc in mod similar cu un server local => “cineva” trebuie sa rezolve aducerea unei referinte la un obiect aflat la distanta
Tipare arhitecturale pentru sisteme distribuite:
Broker
Utilizeaza si integreaza tiparele:
Forwarder-Receiver
Client-Dispatcher-Server
Remote Proxy

7. Client-Dispatcher-Server
Tiparul Client-Dispatcher-Server introduce o componenta intermediara = Dispatcher intre componentele clienti si servere. Rolul unui Dispatcher este de a realiza transparenta locatiei serverelor prin intermediul unui Naming Service si de a ascunde detaliile stabilirii legaturii (la distanta) intre clienti si servere.
Exemplu: Sistemul “Achilles” de regasire a informatiilor stiintifice
Furnizorii de informatii sunt atat locali cat si la distanta
Accesarea unui furnizor de informatii se face specificand locatia acestuia si serviciul solicitat:
de exemplu: Client trimite la serverul “NASA/HUBBLE_TELESCOPE”, un mesaj cu continutul “HUBBLE_DOC_RECEIVE, ANDROMEDA.JPG”

8. Exemplu Client-Dispatcher-Server
Clientul nu trebuie sa cunoasca locatia serverelor pe care le foloseste
Dispatcher: furnizeaza un Naming Service
Codul care implementeaza functionalitatea clientului trebuie sa fie separat de codul care realizeaza conexiunea cu serverul
Dispatcher: realizeaza stabilirea legaturii de comunicatie intre Client si Server
[POSA]-Fig/P.323

9. Structura Client-Dispatcher-Server
[POSA]-Fig/P. 325

10. Structura Client-Dispatcher-Server
[POSA]-Fig/P. 326

11. Scenariu Client-Dispatcher-Server
[POSA]-Fig/P.327

12. Pasi de definire a unei arhitecturi Client-Dispatcher-Server
Separarea componentelor in clienti si servere
Stabilirea mecanismelor de comunicare necesare
In functie de “distanta” intre clienti si servere:
In acelasi spatiu de nume
Pe aceeasi masina
In retea
Specificarea protocoalelor de interactiune intre componente:
Protocol: specifica
o secventa ordonata de activitati necesare pentru initializarea si pastrarea canalului de comunicatie
Structura mesajelor/datelor care se pot transmite
CDProtocol
DSProtocol
CSProtocol
Numirea serverelor
Proiectarea si implementarea Dispatcher
Implementarea protocoalelor de interactiune
Gestiunea canalelor de comunicatie daca reprezinta o resursa limitata (de ex – numarul de socket-uri ce se pot deschide)
Performanta: N Clienti, N Servere, 1 Dispatcher ! => multithreading in implementarea Dispatcher
Implementarea Clientilor si Serverelor

13. Varianta: Client-Dispatcher-Service
Clientii adreseaza Servicii si nu Servere
Dispatcher-ul gaseste in repository-ul sau un server care furnizeaza respectivul serviciu (Pot fi mai multe servere care furnizeaza acel serviciu)
Exemplu: urmatorul exemplu simplu ilustreaza realizarea unui asemenea Naming Service, pentru un sistem simplificat in care Dispatcher, Clientii si Services ruleaza toti in acelasi spatiu de nume
Cod complet -> vezi ClientDispatcherServer.jsl

14. Exemplu: Implementare Dispatcher
class Dispatcher {
Hashtable registry = new Hashtable();
Random rnd = new Random(12345);
public void register(String svc, Service obj) {
Vector v = (Vector)registry.get(svc);
if (v == null) {
v = new Vector();
registry.put(svc, v); }
v.addElement(obj);
public Service locate(String svc) throws NotFound {
if (v == null) throw new NotFound();
if (v.size() == 0) throw new NotFound();
int i = rnd.nextInt() % v.size();
return (Service)v.elementAt(i);

15. Exemplu: Implementare Service
abstract class Service {
String nameOfService;
String nameOfServer;
public Service(String svc, String srv) {
nameOfService = svc;
nameOfServer = srv;
CDS.disp.register(nameOfService, this); }
abstract public void service();
class PrintService extends Service {
public PrintService(String svc, String srv) {
super(svc, srv);
public void service() {
System.out.println("Service " + nameOfService + " by " + nameOfServer);
Presupune cazul particular in care D-S sunt in acelasi spatiu de nume, caz in care D poate fi realizat de un Singleton.
Altfel protocolul S-D este mai complicat de implementat (D va trebui sa existe ca serviciu care ruleaza la o adresa prestabilita si cunoscuta de toate partile)

16. Exemplu: Implementare Client
Presupune cazul particular in care C-D sunt in acelasi spatiu de nume, caz in care D poate fi realizat de un Singleton.
class Client {
public void doTask() {
Service s;
try {
s = CDS.disp.locate("printSvc");
s.service();
} catch (NotFound n) {
System.out.println("Service not available"); }
} catch (NotFound n) {
s = CDS.disp.locate("drawSvc");
Presupune cazul particular in care C-S ruleaza in acelasi spatiu de nume

17. Exemplu:Inregistrare servicii, client
public class CDS {
public static Dispatcher disp = new Dispatcher();
public static void main(String[] args){
Service s1 = new PrintService("printSvc", "srv1");
Service s2 = new PrintService("printSvc", "srv2");
Client client = new Client();
client.doTask(); }

18. Proprietati ale tiparului Client-Dispatcher-Server
Avantaje:
Exchangeability of servers
Location and migration transparency
Re-configuration
Fault-tolerance
Atentionari:
Lower efficiency: performanta este determinata de overhead-ul introdus de dispatcher (1 singur Dispatcher la N Clienti si M Servere)
Localizarea serverelor
Inregistrarea serverelor
Stabilirea conexiunilor
Nu incapsuleaza detaliile infrastructurii de comunicatie (vezi pe diagrama de colaborari cate operatii diferite traverseaza limitele proceselor !) => e nevoie de alt pattern mai bun din acest punct de vedere: Forwarder-Receiver

19. Forwarder-Receiver
Tiparul Forwarder-Receiver realizeaza transparenta comunicatiilor inter-procese pentru sisteme care interactioneaza dupa un model peer-to-peer. Tiparul introduce elementele Forwarder si Receiver pentru a decupla functionalitatea fiecarui peer de mecanismul de comunicare utilizat.
Peer1
How are you ?
Peer2
I am alive !

20. Exemplu Forwarder-Receiver
Problema:
Un Peer nu trebuie sa cunoasca mecanismul de comunicare intre procese utilizat la baza
Solutia trebuie sa permita schimbarea mecanismului de comunicare, fara a afecta functionalitatea Peers
Fiecare Peer cunoaste doar numele altui Peer cu care comunica
class Peer1 extends Thread {
Receiver r;
Forwarder f;
public void run() {
f = new Forwarder("Peer1");
Message msg = new Message
("Peer1", "How are you");
f.sendMsg("Peer2", msg);
Message result = null;
r = new Receiver("Peer1");
result = r.receiveMsg();
System.out.println("Peer1 receptionat mesaj " + result.data + " de la " + result.sender); }
class Peer2 extends Thread {
Receiver r;
Forwarder f;
public void run() {
Message result = null;
r = new Receiver("Peer2");
result = r.receiveMsg();
System.out.println("Peer2 receptionat mesaj "+result.data+" de la "+result.sender);
f = new Forwarder("Peer2");
Message msg = new Message
("Peer2", "I am alive");
f.sendMsg(result.sender, msg); }

21. Structura Forwarder Receiver
[POSA]-Fig/P.310

22. Structura Forwarder-Receiver
[POSA]-Fig/P.311

23. Scenariu Forwarder-Receiver
[POSA]-Fig/P.312

24. Exemplu implementare Peer1 Peer2 F R R F Registry Config.db
deliver ( marshal ( How are you ) unmarshal ) receive
Peer2 F R
receive ( unmarshal ( I am alive ) marshal ) deliver R F
Registry
Config.db
“Peer1”: adresa …
“Peer2”: adresa …

25. Pasi implementare tipar Forwarder-Receiver
Specificarea maparii nume – adrese
Specificarea protocolului de comunicatie intre peers si intre Peers si Forwarders/Receivers: sendMsg, receiveMsg
Alegerea mecanismului de comunicatie
Implementare Forwarder: deliver, marshal
Implementare Receiver: receive, unmarshal
Implementare Peers
Implementare configuratie de start

26. Pas1: Specificarea maparii nume-adrese
class Entry {
private String destinationId;
private int portNr;
public Entry(String theDest, int thePort) {
destinationId = theDest;
portNr = thePort; }
public String dest() {
return destinationId;
public int port() {
return portNr;
public class Registry {
private Hashtable hTable = new Hashtable();
private static Registry _instance=null;
private Registry(){}
public static Registry instance() {
if (_instance==null)
_instance=new Registry();
return _instance; }
public void put(String theKey, Entry theEntry) {
hTable.put(theKey, theEntry);
public Entry get(String aKey) {
return (Entry)hTable.get(aKey);
theDest, thePort:
adresa IP+nr port
theKey: numele sub care este cunoscut serviciul ( de exemplu Peer1, Peer2)

27. Pas2: Specificarea protocolului de comunicatie pentru Peers
class Message {
public String sender;
public String data;
public Message(String theSender, String rawData)
sender = theSender;
data = rawData; }
class Forwarder { …
public void sendMsg(String theDest, Message theMsg)
deliver(theDest, marshal(theMsg)); }
class Receiver
public Message receiveMsg()
return unmarshal(receive());

28. Pas3: Alegerea protocolului de comunicatie
class Receiver {
private ServerSocket srvS;
private Socket s;
private InputStream iStr; …
private byte[] receive() {
int val;
byte buffer[] = null;
try {
Entry entry = Registry.instance().get(myName);
srvS = new ServerSocket(entry.port(), 1000);
s = srvS.accept();
iStr = s.getInputStream();
val=iStr.read();
buffer=new byte[val];
iStr.read(buffer);
iStr.close();
s.close();
srvS.close();
} catch (IOException e) {
System.out.println("IOE receiver"); }
return buffer; }
class Forwarder {
private Socket s;
private OutputStream oStr; …
private void deliver(String theDest, byte[] data) {
try {
Entry entry = Registry.instance().get(theDest);
if (entry == null) {
System.out.println(“Dest unknown");
return; }
s = new Socket(entry.dest(), entry.port());
oStr = s.getOutputStream();
oStr.write(data);
oStr.flush();
oStr.close();
} catch (IOException e) {
System.out.println("IOE forwarder"); }

29. Pas4: Implementare Forwarder/Receiver
class Forwarder { …
private byte[] marshal(Message theMsg) {
String m = " "+theMsg.sender + ":" + theMsg.data;
byte b[]=new byte[ m.get_Length()];
b = m.getBytes();
b[0]=(byte)m.get_Length();
return b; }
class Receiver {
private Message unmarshal(byte[] anArray) {
String msg=new String(anArray);
String sender = msg.substring(1, msg.IndexOf(':'));
String m = msg.substring(msg.IndexOf(':')+1, msg.get_Length());
return new Message(sender, m);

30. Pas 5: Realizare configuratie de start
Adresele date ca exemplu reprezinta cazul particular in care componentele comunicante sunt pe acelasi calculator – localhost – identificat prin adresa IP de loopback
class Configuration {
public Configuration(){
Entry entry=new Entry(" ", 1111);
Registry.instance().put("Peer2", entry);
entry=new Entry(" ", 2222);
Registry.instance().put("Peer1", entry); }
public class P1 {
public static void main(String args[]) {
new Configuration();
Peer1 p1=new Peer1();
p1.start();
public class P2 {
public static void main(String args[]) {
Peer2 p2=new Peer2();
p2.start();

31. Proprietati ale tiparului Forwarder-Receiver
Avantaje:
Comunicare eficienta inter-procese
Incapsulare a facilitatilor de comunicare inter-procese
Atentionari:
Nu suporta reconfigurarea flexibila a componentelor => combinatie cu dispatcher

32. Remote Proxy
Tiparul Proxy permite clientilor unei componente sa comunice cu un “reprezentant” al acesteia, in loc de a comunica cu originalul.
Remote Proxy: permite clientilor unei componente la distanta sa un acces transparent la aceasta, ascunzand clientilor aspectele ce tin de adresarea si comunicarea la distanta

33. Structura generala Proxy
[POSA]-Fig/P.

34. Scenariul general Proxy
Remote Proxy: pre si postprocesarea
este facuta in combinatie cu tiparul Forwarder-Receiver
marshal, deliver
unmarshal, receive
[POSA]-Fig/P.

35. Broker
Tiparul Broker structureaza sisteme distribuite constand din componente decuplate care interactioneaza prin invocarea de servicii la distanta. Broker-ul realizeaza coordonarea comunicarii si ascunderea detaliilor comunicarii fata de componentele implicate.
Client1
Client2
Server1
Server2
Object X
Object Y
Invoke
foo on
Object X
Invoke
bar on
Object Y
foo
bar
Broker

36. Broker vs Forwarder-Receiver
Ambele tipare realizeaza coordonarea comunicarii si ascunderea detaliilor comunicarii fata de componentele implicate
Forwarder-Receiver: comunicarea are loc prin mesaje al caror format este stabilit si cunoscut de componentele Peer care participa
Broker: componentele interactioneaza prin invocare de servicii la distanta (invocare de operatii exportate de o interfata), in mod transparent fata de locatia componentelor.
Realizarea tiparului Broker presupune integrarea unui tipar Remote Proxy cu tiparul Forwarder-Receiver

37. [POSA]-Fig/P

38. Broker
[POSA]-Fig/P.107

39. Serverul se inregistreaza la Broker
POSA
[POSA]-Fig/P.108

40. Brokerul rezolva o cerere Client-Server
[POSA]-Fig/P.109

41. Variante de Broker Indirect Broker: Direct Broker:
realizeaza o comunicatie indirecta intre client si server: orice comunicatie intre client si server este transmisa prin intermediul Broker-ului
Corespunde cu varianta prezentata in scenariul general din diagrama de colaborari anterioara
Direct Broker:
Clientul poate comunica direct cu Server-ul, dupa ce conexiunea a fost realizata prin intermediul Broker => creste eficienta comunicatiei
Operatiile descrise in diagrama anterioara raman valabile ca principiu si secventa dar sunt rearondate intre Proxy-uri si Broker: Proxy-urile vor prelua operatiile forward_request si forward_response de la Broker

42. Interactiunea intre diferiti Brokeri
[POSA]-Fig/P.110

43. Implementari de referinta ale arhitecturii Broker
Middleware care implementeaza tiparul Broker:
CORBA: Common Object Request Broker Architecture. Arhitectura de referinta elaborata de OMG (Object Management Group)
Diverse implementari, comerciale sau open
RMI: Java Remote Method Invocation - Sun
.NET Remoting - Microsoft

44. Arhitectura RMI Server Client implements Remote Interface Remote
Object
uses
implements
Stub
(ClientSide Proxy)
Skeleton
(ServerSide Proxy)
Remote Reference
Layer
Transport
Layer

45. ORB (Object Request Broker)
Arhitectura CORBA
Server
Client
Remote
Interface
IDL
Remote
Object
Dynamic
Invocation
Interface
IDL Stub
(ClientSide
Proxy)
IDL Skeleton
(ServerSide
Proxy)
Object
Adapter
ORB
Interface
Implem
Repository
Interface
Repository
ORB (Object Request Broker)

46. .NET Remoting Architecture
Server
Client
Remote
Interface
Remote
Object
TransparentProxy
RealProxy
Remoting system
Remoting system
Channel