1. Continutul cursului Conceptul de arhitectura software
Ce este arhitectura software ?
Stiluri arhitecturale fundamentale
Pipes and filters
Layers
Blackboard
Event-driven
Arhitecturi tipice pe domenii/tipuri de aplicatii:
Adaptive
Reflection
Distribuite
Client-server, Broker
Enterprise
Data access
Interoperability

2. Sisteme distribuite Continutul capitolului: Introducere:
Modele pentru aplicatii distribuite
Ultrascurta introducere in comunicarea intre procese in retea
Tipare utilizate in realizarea infrastructurii pentru sisteme distribuite:
Forwarder-Receiver: [POSA1], din chap.3.6 (pag )
Client-Dispatcher-Server: [POSA1], din chap. 3.6 (pag )
Remote Proxy: [POSA1], din chap. 3.4 (pag )
Broker:
[POSA1] chap 2.3
[MSDN Library]-
Exemple de tehnologii de middleware care implementeaza tiparul Broker: Java RMI, CORBA, .NET Remoting
Proiect varianta 3: implementarea unui Object Request Broker propriu

3. Client-Server
Exemplu: InfoServer: poate furniza la cerere informatii despre starea vremii sau despre gradul de congestie pe sosele
Cum e vremea azi ?
Client1
Innorat si ploua
InfoServer
Cum e congestia pe DN342?
70%
Client2

4. Modelul Client-Server
Caracteristic: relatie asimetrica:
Serverul ofera servicii
Clientii utilizeaza servicii
Alte modele:
n-tier (multistrat): combinatie client-server si layers
Peer-to-peer: relatie simetrica, toti participantii isi ofera servicii

5. Solutie Client-Server ?
Proces2 (Calculator 2)
Proces1 (Calculator 1)
Deoarece Client si InfoServer ruleaza in procese diferite,
nu exista spatiu de memorie comun/ variabile comune !
Trebuie utilizate mecanisme de comunicare intre procese

6. Ultra-scurta introducere in comunicarea intre procese in retea
Datele sunt transmise pe Canale de comunicare
Un canal de comunicare este definit prin:
2 communication endpoints
protocol
Un communication endpoint (socket):
Adresa: are 2 componente: identificare host + port

7. Realizarearea modelului Client-Server
Deschide un canal de comunicare
CLIENT
Sta in asteptare pana la sosirea
unui cereri de la un client
Deschide un canal de comunicare
si se conecteaza la un canal
deschis de un server
Accepta cererea
cerere
Citeste (date)
Scrie (date)
raspuns
Scrie (date)
Citeste(date)
notificare
Inchide canalul de comunicare

8. Dezavantaje:
programatorul de aplicatii trebuie sa se ocupe de multe aspecte de nivel scazut (trimiterea/receptionarea datelor in format binar)
logica aplicatiei nu este separata de partea de comunicatie

9. Suport pentru aplicatii distribuite
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
Middleware:
Infrastructura care suporta realizarea aplicatiilor distribuite
De obicei realizata de software “off-the-shelf”
Exemple: Java RMI, .NET Remoting, CORBA

10. Tipare arhitecturale pentru sisteme distribuite
Broker
Utilizeaza si integreaza tiparele:
Forwarder-Receiver: separation of concerns: ascunde detaliile mecanismelor specifice de comunicare intre procese (formatarea datelor, transmiterea/receptionarea mesajelor conform protocolului utilizat)
Client-Dispatcher-Server: location independency: decupleaza stabilirea conexiunii (cunoasterea adresei) de comunicarea ulterioara
Remote Proxy: location transparency: interactiunea cu un server la distanta are loc prin intermediul reprezentantului sau local

11. 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 !

12. 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
Exista un protocol (formate de mesaje) agreat de ambele parti
class Peer1 {
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 {
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); }

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

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

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

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

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

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

19. 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());

20. 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"); }

21. Pas4: Implementare Forwarder/Receiver
class Forwarder { …
private byte[] marshal(Message theMsg) {
String m = " " + theMsg.sender + ":" + theMsg.data;
byte b[] = new byte[m.length()];
b = m.getBytes();
b[0] = (byte)m.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.length()-1);
return new Message(sender, m); }

22. 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.run();
public class P2 {
public static void main(String args[]) {
Peer2 p2=new Peer2();
p2.run();
In acest exemplu, informatiile de configurare (adresele participantilor) sunt duplicate, fiind pastrate atat la P1 cat si la P2 !

23. 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 ca NamingService

24. Observatii privind tiparul Forwarder-Receiver la Client-Server
Interactiunea tipica Client-Server:
Un server are o adresa bine-cunoscuta (publica)
Un client trimite un mesaj pe adresa serverului, cerand un anumit serviciu, si apoi asteapta mesajul de raspuns de la server
Tiparul Forwarder-Receiver:
Abstractizeaza un canal de comunicatie unidirectional intre Forwarder si Receiver
Client-Server realizat cu Forwarder-Receiver:
Utilizeaza 2 canale de comunicatie distincte
Adr
Client
cerere
Server F R
raspuns R F
Adr

25. Tipare pentru comunicarea prin mesaje pe canale de comunicatie
In functie de protocol, un canal de comunicatie poate fi bidirectional sau unidirectional
Canal unidirectional: Send-Receive (Forward-Receive)
Canal bidirectional: Request-Reply
Daca protocolul utilizat permite canale de comunicatie bidirectionale, pentru implementarea unui sistem client-server (in care clientul este de tip blocking/sincron) este de preferat comunicarea de tip request-reply !

26. Send-Receive Client Server Adr Sender Receiver Adr Receiver Sender
ByteSender {
public ByteSender(String theName) ;
public void deliver(Address theDest, byte[] data); }
ByteReceiver {
public ByteReceiver(String theName, Address theAddr) {
public byte[] receive()

27. Request-Reply Client Server Adr Requestor Replyer Requestor{
public Requestor(String theName) ;
public byte[] deliver_and_wait_feedback(Address theDest, byte[] data); }
public interface ByteStreamTransformer{
public byte[] transform(byte[] in);
Replyer {
public Replyer(String theName, Address theAddr);
public void receive_transform_and_send_feedback(ByteStreamTransformer t);

28. Implementari
Pentru exemple de implementari v. pagina web a cursului:
ByteSender-ByteReceiver
Requestor-Replyer
Detaliile de implementare pentru acestea NU fac obiectul acestui curs (v. PRC)
Exemple de aplicatii client-server construite cu acestea:
Client-Server cu Send-Receive (SR)
Client-Server cu Requestor-Replyer (RR)
Implementarile date pot fi folosite ca puncte de plecare la realizarea temelor

29. Implementare Forwarder-Receiver peste Send-Receive

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

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

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

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

34. Interactiunea intre Client-Dispatcher-Server
CSProtocol
Client
Server
CDProtocol
DSProtocol
Dispatcher
Toate interactiunile implica
mecanisme de comunicare intre procese !

35. Exemplu Peer-to-Peer: Implementare cu Forwarder-Receiver
deliver ( marshal ( How are you ) unmarshal ) receive
Peer2 F R
receive ( unmarshal ( I am alive ) marshal ) deliver R F
Registry
Registry
Config.db
“Peer1”: adresa …
“Peer2”: adresa …
Config.db
“Peer1”: adresa …
“Peer2”: adresa …

36. Exemplu Peer-to-Peer: Implem cu Forw-Rec + Dispatcher
“How are you ? “
Peer2 F R
“I am alive “ R F
Peer 2 is at addr Y
“Peer 1 is at addr X ”
I am Peer 1 at addr X F
Where is Peer 2 ?
“ I am Peer2 at addr Y ” R
“Where is Peer 1? ”
Registry
Config.db
“Peer1”: adresa …
“Peer2”: adresa …

37. Exemplu Peer-to-Peer: Implem cu Req-Repl + Dispatcher
“How are you ? / I am alive “
Peer2
Req
Repl
Repl
Req
Where is Peer 2?
Peer 2 is at addr Y
“Where is Peer1?
Peer 1 is at addr X ”
I am Peer1 at addr X
“ I am Peer2 at addr Y ”
Repl
Registry
Config.db
“Peer1”: adresa …
“Peer2”: adresa …

38. 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 combinarea cu Forwarder-Receiver

39. Exemplu Client-Server: Implem cu Req-Repl + Dispatcher
Exemplu: InfoServer: poate furniza la cerere informatii despre starea vremii sau despre gradul de congestie pe sosele
Cum e vremea azi ?
Innorat si ploua
InfoServer
Client1
Sunt InfoServer la addr X,
info Meteo si Rutier
Care e adresa unui server cu info Meteo?
InfoServer
Dispatcher
Client2

40. Exemplu Client-Server:
Codul de implementare a lui Client1:
Transmite mesaj la NamingService (Dispatcher) – intreaba care e adresa unui server de info Meteo
Primeste raspunsul de la Dispatcher – ii da adresa lui InfoServer
Transmite mesaj la InfoServer (pe adresa aflata la pasul anterior) – intreaba care e vremea azi
Primeste raspunsul de la InfoServer cu prognoza pe azi
Ideal, Client1 ar trebui sa fie ceva de genul:
todayWeather=meteoServer.GetWeatherForecast(“today”);

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

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

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

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

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

46. Variante de Broker Indirect Broker: Direct Broker:
Broker-ul realizeaza o comunicatie indirecta intre client si server: orice comunicatie intre client si server este transmisa prin intermediul Broker-ului
Direct Broker:
Clientul poate comunica direct cu Server-ul, dupa ce conexiunea a fost realizata prin intermediul Broker

47. Indirect Broker F ClientProxy F ServerProxy R R R F 5. call service
2. pack_data
8. pack_data
3. forward_request
9. forward_response F
ClientProxy F
ServerProxy R R R
10.return F
11. unpack_data
5. call service
6.unpack_data
1. call server
7. run service
Broker
Client
Server
4.find server
NamingService

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

49. [POSA]-Fig/P

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

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

52. 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
Ineficient din punct de vedere al comunicatiei, dar prezinta avantajul ca se poate controla accesul la servere
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. De asemenea, Proxy-ul va interoga nameService-ul (locate_server)

53. Direct Broker F ClientProxy R ServerProxy R F 1. call server
2. pack_data
5.unpack_data F
4. forward_request
ClientProxy R
ServerProxy R F
8. forward_response
9. unpack_data
7. pack_data
1. call server
6. run service
3. locate_server R
Client
Server F
NamingService

54. Observatii: mecanisme de comunicatie folosite
Prezentarea patternurilor Broker a utilizat modelul Forwarder-Receiver (bazat pe mecanismul de comunicatie Send-Receive – presupune canale de comunicatie unidirectionale)
Daca:
protocoalele utilizate permit canale de comunicatie bidirectionale
Semantica apelurilor de la clienti la servere este cu apeluri sincrone (cu blocarea clientului in asteptarea raspunsului)
=> e de preferat sa se foloseasca in implementare mecanismul Request-Reply !

55. Exemplu Client-Server: cu Direct Broker
Codul de implementare a lui Client1:
todayWeather=meteoServer.GetWeatherForecast(“today”);
meteoServer este un obiect MeteoClientProxy
In codul de implementare a lui MeteoClientProxy:
La crearea proxy-ului:
Transmite mesaj la NamingService (Dispatcher) – intreaba care e adresa unui server de info Meteo
Primeste raspunsul de la Dispatcher – ii da adresa lui InfoServer (de fapt a MeteoServerProxy)
In metoda GetWeatherForecast:
Transmite mesaj la InfoServer (pe adresa aflata la creare) – intreaba care e vremea azi: in mesaj trebuie inclus: numele operatiei, valorile parametrilor
Primeste mesajul de raspuns de la InfoServer
Extrage (unmarshal) prognoza pe azi
Returneaza raspunsul

56. Exemplu Client-Server: cu Direct Broker (cont)
In codul de implementare a lui MeteoServerProxy:
Creaza Receiver (Replyer) si asteapta mesaje
La sosirea unui mesaj, extrage (unmarshal) informatii care ii spun despre ce operatie e vorba si care sunt valorile parametrilor
Invoca operatia corespunzatoare a InfoServer
Preia rezultatul, il formateaza (marshal) si trimite mesajul de raspuns inapoi

57. Generarea codului Proxy-urilor
Se observa ca “ugly stuff” s-a mutat din codul client in codul Proxy-urilor
ClientProxy depinde de interfata serviciului (implementeaza aceeasi interfata ca si serverul) => pentru fiecare tip de server vom avea alte clase Proxy
Avantaj: codul Proxy-urilor poate fi totusi generat automat !
Programatorul de aplicatii va scrie (manual) cod doar pentru client si server
Generator
(Descriere)
Interfata
Server
Cod
Proxy-uri

58. Broker in practica: Middleware
Infrastructura care suporta realizarea aplicatiilor distribuite
De obicei realizata de software “off-the-shelf”
Exemple: Java RMI, .NET Remoting, CORBA
Ce contine pachetul “off-the-shelf”:
Libraries+API pentru dezvoltarea aplicatiilor distribuite
Executabile server (de ex NamingService)
Tool-uri pentru dezvoltatorii de aplicatii (de ex Generator de proxy-uri)

59. Broker in practica: Middleware
Tool Generare Proxy-uri
Biblioteca(API)+ Executabile
Application Developer