590 likes | 745 Views
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
E N D
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 Cum e vremea azi ? Client1 Innorat si ploua InfoServer Cum e congestia pe DN342? 70% Client2
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 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 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
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: 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 Tipare arhitecturale pentru sisteme distribuite
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 !
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); } } 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
Structura Forwarder Receiver [POSA]-Fig/P.310
Structura Forwarder-Receiver [POSA]-Fig/P.311
Scenariu Forwarder-Receiver [POSA]-Fig/P.312
Exemplu implementare Peer1 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 …
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
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); } } Pas1: Specificarea maparii nume-adrese theDest, thePort: adresa IP+nr port theKey: numele sub care este cunoscut serviciul ( de exemplu Peer1, Peer2)
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()); } } Pas2: Specificarea protocolului de comunicatie pentru Peers
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; } … } Pas3: Alegerea protocolului de comunicatie
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 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 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(); } } 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 Adr Client cerere Server F R raspuns R F 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-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() }
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); }
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
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 CSProtocol Client Server DSProtocol CDProtocol Dispatcher Toate interactiunile implica mecanisme de comunicare intre procese !
Exemplu Peer-to-Peer:Implementare cu Forwarder-Receiver Peer1 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 …
Exemplu Peer-to-Peer:Implem cu Forw-Rec + Dispatcher “How are you ? “ Peer1 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 …
Exemplu Peer-to-Peer:Implem cu Req-Repl + Dispatcher “How are you ? / I am alive “ Peer1 Peer2 Req Repl Req Where is Peer 2? Peer 2 is at addr Y “ I am Peer2 at addr Y ” Repl Registry Config.db “Peer1”: adresa … “Peer2”: adresa …
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 Cum e vremea azi ? Innorat si ploua InfoServer Client1 Sunt InfoServer la addr X, info Meteo si Rutier InfoServer Care e adresa unui server cu info Meteo? Dispatcher Client2
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”); Exemplu Client-Server:
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 Remote Proxy: pre si postprocesarea este facuta in combinatie cu tiparul Forwarder-Receiver locateServer, marshal, deliver receive, unmarshal [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. Client1 Client2 Server2 Server1 Object X Object Y Invoke foo on Object X Invoke bar on Object Y foo bar 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 2. pack_data 8. pack_data 9. forward_response 3. forward_request F ClientProxy F ServerProxy R R R 10.return F 11. unpack_data 6.unpack_data 5. call service 1. call server 7. run service Broker Client Server 4.find server NamingService
Broker [POSA]-Fig/P.107
Serverul se inregistreaza la Broker [POSA]-Fig/P.108