Continutul cursului Conceptul de arhitectura software Ce este

  • Slides: 58
Download presentation
Continutul cursului • Conceptul de arhitectura software – Ce este arhitectura software ? •

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

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: [POSA 1], din chap. 3. 6 (pag 307 -322) Client-Dispatcher-Server: [POSA 1], din chap. 3. 6 (pag 323 -336) Remote Proxy: [POSA 1], din chap. 3. 4 (pag 263 -275) Broker: – [POSA 1] chap 2. 3 – Exemple de tehnologii de middleware care implementeaza tiparul Broker: Java RMI, CORBA, . NET Remoting

Distributed Object Computing ? Proces 2 (Calculator 2) Proces 1 (Calculator 1) Deoarece Client

Distributed Object Computing ? Proces 2 (Calculator 2) Proces 1 (Calculator 1) Deoarece Client si Info. Server 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

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

Realizarearea modelului Client-Server SERVER Deschide un canal de comunicare CLIENT Sta in asteptare pana

Realizarearea modelului Client-Server 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 Scrie (date) Citeste(date) Inchide canalul de comunicare Accepta cerere raspuns notificare Citeste (date) Scrie (date)

Dezavantaje: • programatorul de aplicatii trebuie sa se ocupe de multe aspecte de nivel

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:

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 –

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

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. How are you ? Peer 1 I am alive ! Peer 2

Exemplu Forwarder-Receiver Problema: • Un Peer nu trebuie sa cunoasca mecanismul de comunicare intre

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 Peer 1 { Receiver r; Forwarder f; public void run() { f = new Forwarder("Peer 1"); Message msg = new Message ("Peer 1", "How are you"); f. send. Msg("Peer 2", msg); Message result = null; r = new Receiver("Peer 1"); result = r. receive. Msg(); System. out. println("Peer 1 receptionat mesaj " + result. data + " de la " + result. sender); } } class Peer 2 { Receiver r; Forwarder f; public void run() { Message result = null; r = new Receiver("Peer 2"); result = r. receive. Msg(); System. out. println("Peer 2 receptionat mesaj "+result. data+" de la "+result. sender); f = new Forwarder("Peer 2"); Message msg = new Message ("Peer 2", "I am alive"); f. send. Msg(result. sender, msg); } }

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

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

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

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

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

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

Exemplu implementare deliver ( marshal ( How are you ) unmarshal ) receive Peer

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

Pasi implementare tipar Forwarder-Receiver • Specificarea maparii nume – adrese • Specificarea protocolului de

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

Pas 1: Specificarea maparii nume-adrese class Entry { private String destination. Id; private int

Pas 1: Specificarea maparii nume-adrese class Entry { private String destination. Id; private int port. Nr; public Entry(String the. Dest, int the. Port) { destination. Id = the. Dest; port. Nr = the. Port; } public String dest() { return destination. Id; } public int port() { return port. Nr; } } the. Dest, the. Port: adresa IP+nr port public class Registry { private Hashtable h. Table = 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 the. Key, Entry the. Entry) { h. Table. put(the. Key, the. Entry); } public Entry get(String a. Key) { return (Entry)h. Table. get(a. Key); } } sub care este the. Key: numele cunoscut serviciul ( de exemplu Peer 1, Peer 2)

Pas 2: Specificarea protocolului de comunicatie pentru Peers class Message { public String sender;

Pas 2: Specificarea protocolului de comunicatie pentru Peers class Message { public String sender; public String data; public Message(String the. Sender, String raw. Data) { sender = the. Sender; data = raw. Data; } } class Forwarder { … public void send. Msg(String the. Dest, Message the. Msg) { deliver(the. Dest, marshal(the. Msg)); } } class Receiver { … public Message receive. Msg() { return unmarshal(receive()); } }

Pas 3: Alegerea protocolului de comunicatie class Forwarder { private Socket s; private Output.

Pas 3: Alegerea protocolului de comunicatie class Forwarder { private Socket s; private Output. Stream o. Str; class Receiver { private Server. Socket srv. S; private Socket s; private Input. Stream i. Str; … private void deliver(String the. Dest, byte[] data) { try { Entry entry = Registry. instance(). get(the. Dest); if (entry == null) { System. out. println(“Dest unknown"); return; } s = new Socket(entry. dest(), entry. port()); o. Str = s. get. Output. Stream(); o. Str. write(data); o. Str. flush(); o. Str. close(); } catch (IOException e) { System. out. println("IOE forwarder"); } } } … private byte[] receive() { int val; byte buffer[] = null; try { Entry entry = Registry. instance(). get(my. Name); srv. S = new Server. Socket(entry. port(), 1000); s = srv. S. accept(); i. Str = s. get. Input. Stream(); val=i. Str. read(); buffer=new byte[val]; i. Str. read(buffer); i. Str. close(); srv. S. close(); } catch (IOException e) { System. out. println("IOE receiver"); } return buffer; } …

Pas 4: Implementare Forwarder/Receiver class Forwarder { … private byte[] marshal(Message the. Msg) {

Pas 4: Implementare Forwarder/Receiver class Forwarder { … private byte[] marshal(Message the. Msg) { String m = " " + the. Msg. sender + ": " + the. Msg. data; byte b[] = new byte[m. length()]; b = m. get. Bytes(); b[0] = (byte)m. length(); return b; } … } class Receiver { … private Message unmarshal(byte[] an. Array) { String msg = new String(an. Array); String sender = msg. substring(1, msg. index. Of(": ")); String m = msg. substring(msg. index. Of(": ")+1, msg. length()-1); return new Message(sender, m); } … }

Pas 5: Realizare configuratie de start class Configuration { public Configuration(){ Entry entry=new Entry("127.

Pas 5: Realizare configuratie de start class Configuration { public Configuration(){ Entry entry=new Entry("127. 0. 0. 1", 1111); Registry. instance(). put("Peer 2", entry); entry=new Entry("127. 0. 0. 1", 2222); Registry. instance(). put("Peer 1", entry); } } public class P 1 { public static void main(String args[]) { new Configuration(); Peer 1 p 1=new Peer 1(); p 1. run(); } } public class P 2 { public static void main(String args[]) { new Configuration(); Peer 2 p 2=new Peer 2(); p 2. 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 P 1 cat si la P 2 !

Proprietati ale tiparului Forwarder-Receiver • Avantaje: – Comunicare eficienta inter-procese – Incapsulare a facilitatilor

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 Naming. Service

Observatii privind tiparul Forwarder-Receiver la Client-Server • Interactiunea tipica Client-Server: – Un server are

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 cerere Client F R Adr raspuns Adr R F Server

Tipare pentru comunicarea prin mesaje pe canale de comunicatie • In functie de protocol,

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 clientserver (in care clientul este de tip blocking/sincron) este de preferat comunicarea de tip request-reply !

Send-Receive Client Sender Adr Receiver Server Adr Receiver Sender Byte. Sender { public Byte.

Send-Receive Client Sender Adr Receiver Server Adr Receiver Sender Byte. Sender { public Byte. Sender(String the. Name) ; public void deliver(Address the. Dest, byte[] data); } Byte. Receiver { public Byte. Receiver(String the. Name, Address the. Addr) { public byte[] receive() }

Client Requestor Request-Reply Server Adr Replyer Requestor{ public Requestor(String the. Name) ; public byte[]

Client Requestor Request-Reply Server Adr Replyer Requestor{ public Requestor(String the. Name) ; public byte[] deliver_and_wait_feedback(Address the. Dest, byte[] data); } public interface Byte. Stream. Transformer{ public byte[] transform(byte[] in); } Replyer { public Replyer(String the. Name, Address the. Addr); public void receive_transform_and_send_feedback(Byte. Stream. Transformer t); }

Implementari • Pentru exemple de implementari v. pagina web a cursului: http: /staff. cs.

Implementari • Pentru exemple de implementari v. pagina web a cursului: http: /staff. cs. upt. ro/~ioana/arhit/curs. html – Byte. Sender-Byte. Receiver – 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

Implementare Forwarder-Receiver peste Send-Receive

Client-Dispatcher-Server Tiparul Client-Dispatcher-Server introduce o componenta intermediara = Dispatcher intre componentele clienti si servere.

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

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

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

Varianta: Client-Dispatcher-Service • Clientii adreseaza Servicii si nu Servere • Dispatcher-ul gaseste in repository-ul

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 CSProtocol Server DSProtocol CDProtocol Dispatcher Toate interactiunile implica mecanisme

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

Exemplu Peer-to-Peer: Implementare cu Forwarder-Receiver deliver ( marshal ( How are you ) unmarshal

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

Exemplu Peer-to-Peer: Implem cu Forw-Rec + Dispatcher “How are you ? “ Peer 1

Exemplu Peer-to-Peer: Implem cu Forw-Rec + Dispatcher “How are you ? “ Peer 1 F R “I am alive “ R Pe Ia er m Wh ere Pe er is Pe er 2 i sa 1 a ta 2? dd r ta dd r X r 1 Y F e “Pe R Registry Config. db “Peer 1”: adresa … “Peer 2”: adresa … t is a “ ” X dr Peer 2 F ad m Ia t 2 a r ee P ” ? r 1 ” ad e e s. P i e r he “W Y dr

Exemplu Peer-to-Peer: Implem cu Req-Repl + Dispatcher “How are you ? / I am

Exemplu Peer-to-Peer: Implem cu Req-Repl + Dispatcher “How are you ? / I am alive “ Peer 1 Req Repl Peer 2 (Server) 2? er dr Y Pe d is t a re is a he 2 W er Pe Req Repl Registry Config. db “Peer 1”: adresa … “Peer 2”: adresa … a “ I m Pe er t 2 a ad Y dr ”

Proprietati ale tiparului Client-Dispatcher-Server • Avantaje: – – Exchangeability of servers Location and migration

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: Info. Server: poate furniza la

Exemplu Client-Server: Implem cu Req-Repl + Dispatcher • Exemplu: Info. Server: poate furniza la cerere informatii despre starea vremii sau despre gradul de congestie pe sosele Cum e vremea azi ? Innorat si ploua Client 1 Ca Info. Server re e adr esa Info Ser ver Client 2 unu i se Sunt Info. Server la addr X, info Meteo si Rutier rve r cu info Me teo ? Dispatcher

Exemplu Client-Server: Codul de implementare a lui Client 1: • Transmite mesaj la Naming.

Exemplu Client-Server: Codul de implementare a lui Client 1: • Transmite mesaj la Naming. Service (Dispatcher) – intreaba care e adresa unui server de info Meteo • Primeste raspunsul de la Dispatcher – ii da adresa lui Info. Server • Transmite mesaj la Info. Server (pe adresa aflata la pasul anterior) – intreaba care e vremea azi • Primeste raspunsul de la Info. Server cu prognoza pe azi Ideal, Client 1 ar trebui sa fie ceva de genul: today. Weather=meteo. Server. Get. Weather. Forecast(“today”);

Remote Proxy Tiparul Proxy permite clientilor unei componente sa comunice cu un “reprezentant” al

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.

Structura generala Proxy [POSA]-Fig/P.

Proxy – comportament [POSA]-Fig/P.

Proxy – comportament [POSA]-Fig/P.

Remote Proxy: pre and postprocessing contain a Forwarder-Receiver locate. Server, marshal, deliver Proxy Helper

Remote Proxy: pre and postprocessing contain a Forwarder-Receiver locate. Server, marshal, deliver Proxy Helper serverloop receive, unmarsha service marshal, deliver receive, unmarshal

Broker Tiparul Broker structureaza sisteme distribuite constand din componente decuplate care interactioneaza prin invocarea

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. Client 1 Client 2 Server 1 Invoke foo on Object X Invoke bar on Object Y Object X foo Broker Server 2 Object Y bar

Broker vs Forwarder-Receiver • Ambele tipare realizeaza coordonarea comunicarii si ascunderea detaliilor comunicarii fata

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

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 2. pack_data 8. pack_data 3. forward_request 9. forward_response F Client. Proxy R

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

Broker [POSA]-Fig/P. 107

Broker [POSA]-Fig/P. 107

[POSA]-Fig/P. 103 -105

[POSA]-Fig/P. 103 -105

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

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

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

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

Variante de Broker • Indirect Broker: – realizeaza o comunicatie indirecta intre client si

Variante de Broker • Indirect Broker: – realizeaza o comunicatie indirecta intre client si server: orice comunicatie intre client si server este transmisa prin intermediul Brokerului – 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 name. Service-ul (locate_server)

Direct Broker 2. pack_data 4. forward_request 5. unpack_data F R Client. Proxy R 9.

Direct Broker 2. pack_data 4. forward_request 5. unpack_data F R Client. Proxy R 9. unpack_data 1. call server Client 3. 8. forward_response lo ca te Server. Proxy F 7. pack_data _s er ve r R F Naming. Service 6. run service Server

Observatii: mecanisme de comunicatie folosite • Prezentarea patternurilor Broker a utilizat modelul Forwarder-Receiver (bazat

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 Client 1: –

Exemplu Client-Server: cu Direct Broker • Codul de implementare a lui Client 1: – today. Weather=meteo. Server. Get. Weather. Forecast(“today”); – meteo. Server este un obiect Meteo. Client. Proxy • In codul de implementare a lui Meteo. Client. Proxy: – La crearea proxy-ului: • Transmite mesaj la Naming. Service (Dispatcher) – intreaba care e adresa unui server de info Meteo • Primeste raspunsul de la Dispatcher – ii da adresa lui Info. Server (de fapt a Meteo. Server. Proxy) – In metoda Get. Weather. Forecast: • Transmite mesaj la Info. Server (pe adresa aflata la creare) – intreaba care e vremea azi: in mesaj trebuie inclus: numele operatiei, valorile parametrilor • Primeste mesajul de raspuns de la Info. Server • Extrage (unmarshal) prognoza pe azi • Returneaza raspunsul

Exemplu Client-Server: cu Direct Broker (cont) • In codul de implementare a lui Meteo.

Exemplu Client-Server: cu Direct Broker (cont) • In codul de implementare a lui Meteo. Server. Proxy: • 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 Info. Server • 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

Generarea codului Proxy-urilor • Se observa ca “ugly stuff” s-a mutat din codul client in codul Proxyurilor • Client. Proxy 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 (Descriere) Interfata Server Generator Cod Proxy-uri

Broker in practica: Middleware • Middleware: – – – • Infrastructura care suporta realizarea

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. 2. 3. Libraries+API pentru dezvoltarea aplicatiilor distribuite Executabile server (de ex Naming. Service) Tool-uri pentru dezvoltatorii de aplicatii (de ex Generator de proxy-uri)

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

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