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

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 307-322)• Client-Dispatcher-Server: [POSA1], din chap. 3.6 (pag 323-336)• Remote Proxy: [POSA1], din chap. 3.4 (pag 263-275)• Broker:

– [POSA1] chap 2.3 – [MSDN Library]- http://msdn.microsoft.com/en-us/library/ms978706.aspx

– Exemple de tehnologii de middleware care implementeaza tiparul Broker: Java RMI, CORBA, .NET Remoting

– Proiect varianta 3: implementarea unui Object Request Broker propriu

Client-Server

• Exemplu: InfoServer: poate furniza la cerere informatii despre starea vremii sau despre gradul de congestie pe sosele

Client1

Client2

InfoServer

Cum e vremea azi ?Innorat si ploua

Cum e congestia pe DN342?

70%

Modelul Client-Server

• 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

Solutie Client-Server ?Proces1 (Calculator 1)Proces2 (Calculator 2)

Deoarece Client si InfoServer ruleaza in procese diferite,nu exista spatiu de memorie comun/ variabile comune !

Trebuie utilizate mecanisme de comunicare intre procese

Ultra-scurta introducere in comunicarea intre procese in retea

Datele sunt transmise pe Canale de comunicareUn canal de comunicare este definit prin:

•2 communication endpoints•protocol

Un communication endpoint (socket):Adresa: are 2 componente: identificare host + port

Realizarearea modelului Client-Server

Deschide un canal de comunicare

Sta in asteptare pana la sosirea unui cereri de la un client

Accepta cererea

Citeste (date)

Scrie (date)

cerere

raspuns

Deschide un canal de comunicaresi se conecteaza la un canal

deschis de un server

Scrie (date)

Citeste(date)

Inchide canalul de comunicarenotificare

CLIENT

SERVER

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

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

Tipare arhitecturale pentru sisteme distribuite

• 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

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 Peer2

How are you ?

I am alive !

Exemplu Forwarder-Receiver

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);}

}

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

Structura Forwarder Receiver

[POSA]-Fig/P.310

Structura Forwarder-Receiver

[POSA]-Fig/P.311

Scenariu Forwarder-Receiver

[POSA]-Fig/P.312

Exemplu implementare

Peer1 Peer2

deliver ( marshal ( How are you ) unmarshal ) receive

Registry

F

R

R

F

Config.db“Peer1”: adresa …“Peer2”: adresa …

receive ( unmarshal ( I am alive ) marshal ) deliver

Registry

Config.db“Peer1”: adresa …“Peer2”: adresa …

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

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;}

}

theKey: numele sub care este cunoscut serviciul ( de exemplu Peer1, Peer2)

theDest, thePort: adresa IP+nr port

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);}

}

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

}}

Pas3: Alegerea protocolului de comunicatie

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

}…}

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;}

…}

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); } …}

Pas 5: Realizare configuratie de start

class Configuration {public Configuration(){ Entry entry=new Entry("127.0.0.1", 1111); Registry.instance().put("Peer2", entry); entry=new Entry("127.0.0.1", 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[]) {

new Configuration();Peer2 p2=new Peer2();p2.run();}

}

Adresele date ca exemplu reprezinta cazul particular in care componentele comunicante sunt pe acelasi calculator – localhost – identificat prin adresa IP de loopback 127.0.0.1

In acest exemplu, informatiile de configurare (adresele participantilor) sunt duplicate, fiind pastrate atat la

P1 cat si la P2 !

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

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

Client Server

cerereF

R

R

Fraspuns

Adr

Adr

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 !

Send-ReceiveClient Server

Sender

Receiver Sender

Receiver

ByteSender {public ByteSender(String theName) ;public void deliver(Address theDest, byte[] data);

}ByteReceiver {

public ByteReceiver(String theName, Address theAddr) {public byte[] receive()

}

Adr

Adr

Request-ReplyClient Server

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

}

Adr

Implementari

• Pentru exemple de implementari v. pagina web a cursului: http://www.cs.utt.ro/~ioana/arhit/curs.html

– 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

Implementare Forwarder-Receiver peste Send-Receive

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

Structura Client-Dispatcher-Server

[POSA]-Fig/P. 325

Structura Client-Dispatcher-Server

[POSA]-Fig/P. 326

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)

Interactiunea intre Client-Dispatcher-Server

Client Server

Dispatcher

CSProtocol

DSProtocolCDProtocol

Toate interactiunile implicamecanisme de comunicare intre procese !

Exemplu Peer-to-Peer:Implementare cu Forwarder-Receiver

Peer1 Peer2

deliver ( marshal ( How are you ) unmarshal ) receive

Registry

F

R

R

F

Config.db“Peer1”: adresa …“Peer2”: adresa …

receive ( unmarshal ( I am alive ) marshal ) deliver

Registry

Config.db“Peer1”: adresa …“Peer2”: adresa …

Exemplu Peer-to-Peer:Implem cu Forw-Rec + Dispatcher

Peer1 Peer2

“How are you ? “

Registry

F

R

R

F

Config.db“Peer1”: adresa …“Peer2”: adresa …

“I am alive “

R

F

“ I am Peer2 at addr Y

”

“Where is Peer 1? ”

“Peer 1 is at addr X ”

Peer 2 is at addr Y

I am Peer 1 at addr X

Where is Peer 2 ?

Exemplu Peer-to-Peer:Implem cu Req-Repl + Dispatcher

Peer1 Peer2

“How are you ? / I am alive “

Registry

Req Repl

Req

Config.db“Peer1”: adresa …“Peer2”: adresa …

Repl “ I am Peer2 at addr Y

”

Where is Peer 2?

Peer 2 is at addr Y

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

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

Client1

Client2

InfoServer

Cum e vremea azi ?Innorat si ploua

Dispatcher

Care e adresa unui server cu info Meteo?

InfoServer

Sunt InfoServer la addr X, info Meteo si Rutier

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”);

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

Structura generala Proxy

[POSA]-Fig/P.

Scenariul general Proxy

locateServer,marshal, deliver

receive, unmarshal

Remote Proxy: pre si postprocesarea este facuta in combinatie cu tiparul Forwarder-Receiver

[POSA]-Fig/P.

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.

Invoke foo on

Object X

Invoke bar on

Object Yfoo bar

Object X Object Y

Server1 Server2Client1 Client2

Broker

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

Variante de Broker

• Indirect 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

Indirect Broker

Client

ClientProxyF

R

Broker

R

F

Server

ServerProxyF

R

NamingService

1. call server

2. pack_data

4.find server

7. run service

5. call service

3. forward_request

6.unpack_data

8. pack_data9. forward_response

10.return11. unpack_data

Broker

[POSA]-Fig/P.107

[POSA]-Fig/P. 103-105

Serverul se inregistreaza la Broker

[POSA]-Fig/P.108

Brokerul rezolva o cerere Client-Server

[POSA]-Fig/P.109

Variante de Broker

• Indirect 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)

Direct Broker

Client

ClientProxyF

R

R

FServer

ServerProxyR

F

NamingService

1. call server

2. pack_data

6. run service

4. forward_request5.unpack_data

7. pack_data8. forward_response9. unpack_data

3. locate_server

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 !

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

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

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)

InterfataServer

Cod Proxy-uri

Broker in practica: Middleware

• 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”:1. Libraries+API pentru dezvoltarea aplicatiilor distribuite

2. Executabile server (de ex NamingService)

3. Tool-uri pentru dezvoltatorii de aplicatii (de ex Generator de proxy-uri)

Broker in practica: Middleware

Application Developer

Biblioteca(API)+ Executabile

Tool Generare Proxy-uri