Sisteme Distribuite. Exemple Sugestive de Utilizare

Sisteme distribuite

Concepte generale privind sistemele distribuite

Un sistem distribuit reprezintă o colecție de calculatoare ce au acces la memoria proprie sau la anumite memorii comune partajate, fiind conceput cu scopul partajării unor resurse și pentru rezolvarea concurentă a unor aplicații paralele.

Din modul de definire a sistemelor distribuite se pot enumera câteva caracteristici de bază:

concurența: se poate lucra simultan pe diferite calculatoare din rețea, eventual partajându-se aceleași resurse (pagini web, fișiere);

lipsa unui ceas global: există limite în ceea ce privește capacitatea calculatoarelor din rețea de a-și sincroniza ceasurile interne;

rezistenta la erori: un defect în rețea poate duce la izolarea unor calculatoare, însă rețeaua va funcționa în continuare și programele care vor rula pe nodul deconectat nu vor detecta că a fost întreruptă conex-iunea sau că aceasta a devenit lentă, iar celelalte noduri din sistem nu vor sesiza imediat faptul că unul din noduri nu este funcțional.

Sistemele distribuite sunt organizate prin intermediul unui nivel logic, denumit middleware, care joacă rolul unei platforme de comunicație între componentele de nivel înalt și asigură interfața cu utilizatorii și sistemul de operare.

Dificultatea construirii unor astfel de sisteme apare în momentul elaborării algoritmilor de prelucrare ce sunt folosiți în sistemele distribuite. Algoritmii utilizați în sistemele distribuite trebuie să fie corecți, flexibili, eficienți și trebuie să țină cont de resursele disponibile și de modul de comunicare între acestea. Astfel, sistemele distribuite prezintă următoarele avantaje:

facilitatea schimbului de informații: sistemele distribuite reprezintă un mijloc eficient de comunicare la distanță prin intermediul unei rețele conectate la Internet;

partajarea resurselor scumpe: interconectarea unor calculatoare mai slabe ca performanță cu un număr redus de calculatoare mai puternice, ale căror resurse (memorie, putere a procesorului, periferice de capacități mari) sunt partajate între acestea;

abilitate mărită în funcționare: dacă un sistem de calcul este format dintr-un singur calculator, defectarea acestuia face imposibilă utilizarea întregului sistem;

creșterea performanței prin paralelizarea calculului: existența mai multor procesoare într-un sistem distribuit face posibilă reducerea timpului de realizare a unui calcul laborios prin împărțirea sarcinilor între diferite procesoare, colectarea ulterioară a rezultatelor parțiale și determinarea rezultatului final;

specializarea nodurilor: împărțirea sistemului de calcul în module, fiecare modul implementând o parte din funcționalități și comunicând cu alte module;

scalabilitatea: un sistem distribuit poate fi modificat relativ ușor prin adăugarea sau îndepărtarea unor noduri;

Sistemele distribuite sunt de două tipuri:

sisteme informatice distribuite omogene (bazate pe multiplicarea unor resurse identice), de exemplu unele multiprocesoare sau unele clustere;

sisteme informatice distribuite eterogene (neomogene), de exem-plu rețeaua Internet, unele clustere sau un sistem grid etc.

Cele mai utilizate sunt sistemele distribuite eterogene, formate din următoarele componente:

hardware local neomogen: echipamentele electrice și electronice fizice diferite;

software local neomogen: programele de rețea și procese care formează sistemul distribuit sunt făcute în diverse limbaje de progra-mare, sistemele de operare din nodurile rețelei pot fi diferite;

componente conceptuale neomogene: topologia rețelelor care intră în alcătuirea sistemului distribuit, modul de comunicare, sincronizare și coordonare între procese.

Cerințe în proiectarea unui sistem informatic distribuit

Eterogenitatea

Această caracteristică a sistemelor informatice distribuite se manifestă la diverse nivele. Un sistem distribuit de tip intranet este format din calculatoare eterogene, la nivel de hardware, tipurile de date, cum ar fi sirurile de caractere, de exemplu, au o reprezentare diferită în funcție de tipul de procesor folosit. Un alt exemplu este modul cum se face schimbul de mesaje la sistemele de operare (în UNIX este diferit de cel din Windows). Eterogenitatea apare și la utilizarea limbajelor de programare și diferitelor aplicații pentru utilizatori.

Pentru mascarea eterogenității la nivelurile amintite mai sus se utilizează conceptul de arhitectură distribuită middleware, cele mai reprezentative fiind:

CORBA (Common Object Request Broker Architecture);

DCE (Distributed Computing Environment);

DCOM (Distributed Component Object);

Java RMI (Remote Method Invocation).

CORBA este un cadru standard de dezvoltare a aplicațiilor distribuite în medii eterogene, la elaborarea căruia au participat toate marile companii de software, cu excepția Microsoft. CORBA lucrează cu noțiunea de “server” (fiecare obiect este asociat unui server). Rolul acestuia este de a include implementarea obiectelor asociate, modelul impunând doar invocarea de către clienți a obiectelor de pe server și nu a serverului însuși.

DCOM (Distributed Component Object) este soluția oferită de Microsoft pentru platforme Windows. Acesta este sistem de transmitere a mesajelor, alcătuit din “clienți” ce utilizează diferite obiecte distribuite: un model de comunicare între obiecte COM (Component Object Model), un model de document compus OLE (Object Linking and Embedding), cu servicii de comunicare între documente și gestiunea lor, ActiveX- pentru aplicații Web.

DCE (Distributed Computing Environment) este un sistem elaborat de către OSF (Open Software Foundation). Facilitățile oferite sunt: thread-uri, apeluri de procedură la distanță, servicii de directoare. Există un standard gateway între DCE și CORBA prin care CORBA poate lucra peste DCE (protocolul DCE CIOP).

Diferența dintre DCE si CORBA constă în stilurile de programare adoptate: CORBA folosește un model obiectual, DCE are la bază un model procedural în care se folosesc apeluri la distanță (RPC – Remote Procedure Call).

Java RMI (Remote Method Invocation) a fost dezvoltată de Sun Microsystem. Interfața de programare Java RMI este un model orientat pe obiecte, oferit de Java, unde se pot crea obiecte și metode ce pot fi invocate din alte mașini virtuale.

Este utilizat conceptul de trimitere a codului de pe o mașina pe alta, cod mobil care rulează la destinație (este nevoie de existența unei mașini virtuale pentru a putea rula). Relația între Java RMI și CORBA este una de complementaritate, dar există o rivalitate între Java/CORBA pe de o parte și DCOM, pe de altă parte.

Scalabilitatea

Scalabilitatea este o caracteristică utilizată pentru compararea sistemelor paralele, ce permite modificarea liniară a performanțelor unui sistem, adică nu se produce o modificare semnificativă a performanțelor odată cu modificarea numărului sau calității resurselor instalate (număr de procesoare sau procesoare mai rapide, capacitatea memoriei etc.).

Un calculator paralel de tip multiprocesor cu memorie comună asigură scalabilitatea numai până la aproximativ 30 de procesoare. În plus, costurile sistemelor paralele sunt prea mari raportate la ciclul de viață, motiv pentru interesul s-a deplasat spre sisteme distribuite eterogene, formate din colecții de PC-uri, stații de lucru, supercalculatoare, multiprocesoare, MPP (Masssively Parallel Processors) și rețele de calculatoare.

Un sistem distribuit eterogen este scalabil, dacă funcționarea sa nu este afectată atunci când se modifică semnificativ numărul și tipul de resurse, precum și numărul de utilizatori. Deși numărul de utilizatori de Internet crește semnificativ în fiecare an, sistemul distribuit și eterogen Internet rămâne scalabil.

Din punct de vedere al programării, dacă un sistem distribuit este scalabil, creșterea în timp a complexității unei aplicații sau mărirea dimensiunii sale nu prezintă nici o problemă pentru programator.

Un sistem distribuit este scalabil, dacă la proiectarea sa se respectă următoarele cerințe:

controlul costului resurselor fizice: pentru ca un sistem cu n utilizatori să fie scalabil, cantitatea de resurse fizice trebuie să fie în jur de O(n);

controlul pierderii performanțelor: creșterea dimensiunii duce în general la scăderea performanțelor, deci trebuie găsite soluții pentru ca această scădere să fie semnificativă;

prevenirea căderii resurselor software;

evitarea strangulărilor: un exemplu de strangulare se întâlnea la predecesorul DNS-ului actual, când tabelul era ținut într-un singur fișier master care putea fi downloadat de oricine avea nevoie.

Rezolvarea problemei scalabilității este foarte importantă și dificilă în domeniul sistemelor distribuite. Un sistem distribuit nu ar trebui modificat atunci când numărul de utilizatori sau de resurse cresc, dar acest lucru este greu de realizat. Astfel, soluțiile propuse pentru ameliorarea scalabilității sunt: replicarea datelor, tehnici de cashing, crearea de taskuri similare care să funcționeze concurent, crearea de servere care să conlucreze pentru rezolvarea anumitor taskuri etc.

Securitatea

Există trei noțiuni fundamentale de securitate a informației dintr-un sistem distribuit:

Atac de securitate: orice acțiune care poate compromite securitatea informațiilor dintr-un sistem;

Mecanism de securitate: mijloc pentru detectarea și prevenirea atacurilor de securitate;

Serviciu de securitate: monitorizează atacurile și declanșează mecanismele de securitate adecvate.

Principalele atacuri de securitate, pasive sau active, asupra unui sistem informatic distribuit (în special în rețelele de calculatoare) sunt:

Întreruperea: un element al sistemului este scos din uz (distrugerea unei piese hardware sau compromiterea unei linii de comunicație);

2. Intercepția: o persoană sau un program are acces în sistem, putând prelua date sau copia fișiere și programe;

3. Modificarea: o entitate neautorizată poate modifica conținutul mesajelor transmise sau poate schimba date în fișiere;

4. Falsificarea: o entitate neautorizată poate să insereze mesaje false în rețea sau să adauge înregistrări false în fișierele de date.

Atacurile active se grupează în patru categorii:

Mascarada: o entitate se prezintă ca fiind o altă entitate, de exemplu o entitate cu drepturi mai puține în sistem poate să pretindă că este o alta cu mai multe privilegii;

Retransmiterea: după preluarea datelor, acestea sunt retransmise pentru a produce un efect neautorizat;

Modificarea mesajelor: porțiunea unui mesaj poate fi modificată astfel încât să producă efecte de modificare a autorizării inițiale.

Refuzul de servicii: o entitate neautorizată poate suspenda drepturile de acces a unei alte entități autorizate sau poate supraîncărca rețeaua cu mesaje de bruiaj, scăzându-i astfel performanțele.

Atacurile pasive dintr-o rețea de calculatoare doar studiază și monitorizează activitatea din sistem, fără a face modificări asupra fișierelor sau a mesajelor transmise. De aceea, atacurile passive sunt foarte greu de depistat.

Există două tipuri de atacuri pasive:

atacuri care interceptează conținutul mesajelor transmise în rețea;

atacuri care analizează traficul în rețea, putând determina locațiile sursei și destinatarului, frecvența și lungimea mesajelor etc.

Serviciile de securitate a unei resurse (computer, bază de date, fișier, imprimantă etc.) aflate într-un sistem distribuit vizează următoarele aspecte:

Confidențialitatea: protecția datelor împotriva atacurilor pasive (de la protecția fizică la algoritmi matematici);

Controlul accesului: dreptul de acces la resursă doar pentru utilizatorii autorizați pe bază de nume utilizator și parolă și protecție împotriva accesului neautorizat;

Integritatea: protecție împotriva manipulării de date (alterării sau coruperii) resursei prin programe malițioase lansate de o entitate neautorizată;

Disponibilitatea: protecție împotriva interferențelor atunci când se dorește accesarea unei resurse la care avem drept de utilizare și asigurarea că datele, aplicațiile sau programele sunt întotdeauna disponibile pentru entitățile autorizate;

Autenticitatea: două entități se pot identifica una pe alta prin asigurarea la inițierea comunicației că cele două entități sunt autentice și protecția împotriva interferării unei a treia entități neautorizate pe parcursul comunicației, care ar putea pretinde că este una din cele două entități autorizate;

Nerepudierea: previne ca nici o entitate să nu refuze recunoașterea faptului că a beneficiat de un serviciu executat, de exemplu, când un mesaj este trimis, se poate demonstra de către destinatar că mesajul primit este cel trimis de emițător, respectiv emițătorul poate demonstra că destinatarul a primit mesajul trimis de emițător.

Știința care se ocupă de studiul siguranței comunicațiilor se numește criptologie. Criptologia are două ramuri: criptografia și criptanaliza.

Criptografia studiază algoritmii de criptare și decriptare pentru asigurarea secretizării și autenticității mesajelor (poate fi simetrică – cu cheie secretă sau asimetrică – cu chei publice);

În general, autentificarea criptografică este mai sigură decât autentificarea bazată pe parolă sau pe adresă. În schimb, noile tehnici bazate pe dovezi zero-knowledge pot oferi mecanisme de autentificare mai puternice. Aceste tehnici necesită calcule matematice destul de complexe dar prezintă mai multe facilități atractive pentru autentificare: permit părții ce se autentifică să dovedească că știe secretul fără a transfera efectiv informația către verificator și evită problema distribuției cheilor care apare în cazul unor mecanisme multe dintre schemele propuse, care folosesc aceleași informații publice.

În ciuda aparentei simplități, proiectarea sistemelor distribuite este foarte dificilă. O serie de protocoale publicate au prezentat erori de securitate substanțiale sau subtile. Astefl, s-au creat utilitare pentru dezvoltarea protocoalelor de autentificare și distribuție a cheilor cu o anumită asigurare formală a securității. În loc de a produce protocoale specifice, aceste metodologii se utilizează pentru a verifica un set de afirmații presupus adevărate. Realizările cele mai notabile sunt logica BAN și logica GNY.

Criptanaliza este ramura ce studiază spargerea cifrurilor pentru refacerea informațiilor.

Există mai multe tipuri de atacuri criptografice:

brut, prin încercarea tuturor combinațiilor posibile, fie de chei de criptare, fie de simboluri din text pentru deducerea textului în clar;

asupra textului criptat interceptat, prin analiza căruia se încearcă găsirea textului original sau a cheii de criptare;

asupra unui text în clar cunoscut, pentru care s-a aflat criptograma și pe baza căruia se face o extrapolare pentru deducerea iterativă a altor porțiuni din mesaj;

asupra unor texte criptate alese, pentru care se obțin pictogramele asociate unor texte folosind algoritmi de criptare cu chei și se urmărește aflarea cheilor de decriptare.

Mecanismele de securitate stabilite de OSI (Open System Interchange) sunt:

Criptarea: se utilizează pentru asigurarea confidențialității și are rolul de a transforma datele, astfel încât să devină inteligibile numai de către entitatea autorizată;

Mecanismul de semnătură digitală: are scopul de a confirma că datele au fost produse chiar de semnatar (cuprinde mecanismul pentru producerea semnăturii și mecanismul pentru verificarea semnăturii);

Mecanismul de integritate a datelor: este menit să asigure integritatea datelor în timpul transmisiei, adică asigurarea faptului că în timpul transmisiei datele nu pot fi șterse sau amestecate (la expediere, expeditorul adaugă o informație adițională ce depinde numai de datele transmise, iar la recepție, receptorul generează aceeași informație adițională și o compară cu cea primită);

Mecanismul de control al accesului: controlul accesului la resurse a entităților prin mecanisme bazate pe una sau multe din următoarele instrumente: lista drepturilor de acces, parole, etichete de securitate, durata accesului, timpul de încercare a accesului, calea de încercare a accesului;

Mecanismul de autentificare a schimbului: constă în parole sau tehnici criptografice menite să dovedească identitatea entităților (la expediere, expeditorul adaugă o informație adițională ce depinde numai de datele transmise, iar la recepție, receptorul generează aceeași informație adițională și o compară cu cea primită);

Mecanismul de control al rutării: informațiile sunt dirijate pe baza unui protocol prestabilit sau pe baza unuia dinamic pe rutele considerate mai sigure;

Mecanismul de umplere artificială a traficului: ajută la protecția împotriva analizei traficului și constă în una din următoarele procedee: generarea unui trafic fals, umplerea pachetelor de date transmise cu date redundante; transmiterea de pachete și spre alte destinații în afara celei vizate;

Mecanismul de notariat: implică existența unui mecanism de arbitraj, numit notar, în care au încredere toate entitățile, cu scopul obținerii de garanții în privința autenticității și integrității.

Principalele soluții de securitate pentru informațiile din Internet sunt:

la nivel de rețea: o arhitectură de securitate la nivel de IP și la nivel de protocol TCP/IP (Transmision Control Protocol/ Internet Protocol);

la nivel de sesiune: se folosește protocolul SSL (Secure Sockets Layer), care oferă servicii de securitate chiar deasupra nivelului TCP, folosind criptosisteme cu chei publice și secrete, astfel încât să asigure confidențialitatea, integritatea și autenticitatea clientului sau serverului din sistem.

Tratarea erorilor

O componentă a unui sistem distribuit, de exemplu un calculator din rețea, poate eșua în mod independent de celelalte. Astfel, fiecare componentă din sistem trebuie să țină cont de faptul că o altă componentă de care depinde poate eșua, și să fie capabilă să găsească o soluție în caz de avarie.

Tehnici folosite pentru tratarea erorilor:

Detectarea erorilor (doar a celor care pot fi detectate)

Un exemplu îl constituie utilizarea sumei de control, ce poate fi folosită pentru a verifica dacă unele date au fost corupte. Sunt și erori care sunt greu de detectat, de exemplu căderea la distanță a unui server, marea provocare fiind de a găsi soluții în cazul de erori care nu pot fi detectate cu precizie, ci doar suspectate.

Mascarea erorilor

Unele erori care pot fi detectate pot fi ascunse sau pot fi găsite soluții de ameliorare a lor. Un exemplu este situație de ascundere a erorilor este un mesaj care poate fi retransmis atunci când transmisia sa a eșuat; O soluție de ameliorare a unei erori este păstrarea copiei unui fișier pe un alt suport și dacă o variantă a fost coruptă se poate folosi varianta păstrată.

Toleranța la erori

Spre exemplu, un browser web performant care nu poate intra în contact cu un server, informează utilizatorul asupra problemei și nu îl face să aștepte indefinit.

Recuperarea datelor

Sistemul distribuit trebuie proiectat astfel încât datele să poată fi recuperate după ce serverul a căzut.

Redundanța

Serviciile dintr-un sistem distribuit trebuie să fie tolerante la erori prin folosirea unor tehnici de redundanță (multiplicare a datelor și căilor de comunicare).

Între două rutere din Internet trebuie să existe minim două căi de acces diferite. Astfel, în Domain Name Service (DNS), fiecare tabel se găsește pe cel puțin două servere diferite, o bază de date poate fi replicată pe mai multe servere (atunci când un server cade utilizatorul este redirectat către serverul care funcționează).

Deschiderea

Pentru un sistem distribuit, deschiderea se referă, în primul rând la disponibilitatea de adăugare și apoi, la publicarea de noi servicii de partajare a resurselor (interfețele cărora devin publice).

Sistemele distribuite deschise sunt bazate pe asigurarea unui mecanism uniform de comunicare și publicare a interfețelor pentru accesul la resursele partajate în mod transparent. Sistemele distribuite pot fi constituite din entități eterogene, dar trebuie să se asigure buna funcționare a acestora în cadrul sistemelor distribuite. Marea provocare a deschiderii constă în integrarea componentelor scrise de utilizatori diferiți.

Concurența

Într-un sistem distribuit există posibilitatea ca aceeași resursă partajată să poată fi accesată de mai mulți utilizatori simultan. O soluție limitativă și greu de acceptat este mecanismul care face managementul resursei să servească numai un singur client.

În general, aplicațiile în sistemele distribuite sunt construite pentru a putea deservi mai mulți clienți simultan (multiprocessing, multitasking etc.). Pentru ca un obiect să fie sigur într-un mediu concurent, operațiile asupra lui trebuie să poată fi sincronizate astfel încât să avem date consistente pentru fiecare utilizator. Acest lucru se poate obține prin tehnici standard de sincronizare, cum ar fi semafoarele.

Transparența

Un sistem distribuit este transparent atunci când este perceput ca un întreg și nu ca o simplă colecție de componente independente și eterogene. Există mai multe tipuri de transparență:

1. Acces transparent: permite ca resursele remote și cele locale să poată fi accesate prin aceleași operații;

2. Transparența localizării: face posibilă accesarea resurselor fără să se știe unde sunt localizate;

3. Transparența concurenței: permite ca mai multe procese să opereze concurent folosind resursele partajate fără să interfereze între ele;

4. Transparența replicării: oferă posibilitatea ca mai multe instanțe a unei resurse să poată fi folosite, mărindu-se astfel performanța și robustețea;

5. Transparența erorilor: facilitează ascunderea erorilor ce permite utilizatorilor să-și rezolve task-ul chiar dacă apar erori software sau hardware;

6. Mobilitate transparentă: face posibilă mobilitatea resurselor și a clienților în sistemele distribuite fără să fie afectată operaționalitatea;

7. Performanța transparentă: permite sistemelor distribuite să poată fi reconfigurate pentru a fi performante;

8. Scalabilitate transparentă: permite extinderea sistemelor distribuite fără să se schimbe structuria sistemului sau a algoritmilor folosiți.

3. Middleware

3.2. Middleware

Middleware este software-ul de calculator care oferă servicii de aplicații software în afara celor disponibile de la sistemul de operare. Pentru a simpli-fica procesul de dezvoltare și integrare a aplicațiilor distribuite, componenta middleware trebuie să se bazeze pe un anumit model în ceea ce privește distribuția componentelor și comunicarea dintre acestea.

Unul dintre modele propune ca fiecare resursă din sistem să fie tratată ca un fișier (abordare originar introdusă în UNIX). O extensie a acestei abordări este considerată configurația cu sistem de fișiere distribuit.

O altă abordare a nivelului middleware a fost cea bazată pe apeluri de proceduri la distanță (Remote Procedure Calls – RPC). In acest model ac-centul cade pe ideea de a face posibilă comunicarea în rețea prin punerea la dispoziția proceselor a unui mecanism prin care li se permite apelul unei pro-ceduri a cărei implementare se află pe o altă mașină în rețea. Când o astfel de procedură este apelată, parametrii acesteia sunt transferați către mașina de la distanță, unde procedura este executată, rezultatele fiind trimise înapoi către mașina apelatoare, respectându-se același grad de transparență al co-municării. Totul apare ca și cum a fost executat un apel local, procesul care inițiază apelul nesesizând faptul că a avut loc o comunicare în rețea.

În prezent, sistemele distribuite neomogene, prin programele de trans-latare, interacționează între ele într-un mod transparent pentru utilizator, formând un întreg. Astfel, programatorul poate să creeze un model orientat pe obiecte al unei întreprinderi și apoi să scrie aplicațiile care cer informații din obiecte și nu din anumite surse de date. Cererea este coordonată de un Object Request Broker (ORB), adică un intermediar de cereri orientat pe obiecte, ce implementează o interfață care ascunde detaliile interne de implementare a obiectului pentru utilizatorii acestuia.

Fig. 1.1: Structura generală a unui sistem distribuit

Arhitecturi middleware

Ideea unei platforme de comunicație care să poată pune în conexiune aplicații scrise în limbaje de programare diferite, pentru platforme diferite și care rulează într-un mediu de calcul distribuit și eterogen, a constituit una dintre cerințele dezvoltatorilor de aplicații software.

Sistemele de mesagerie utilizate rezolvă probleme legate de siguranța livrării datelor între aplicații, probleme legate de capacitatea de ajustare a dimensiunilor sistemelor în funcție de volumul datelor de prelucrat, dar și probleme specifice diverselor domenii (sfera afacerilor, domeniul educațional, medical, etc.).

Caracteristica principală a platformelor de mesagerie într-un sistem in-formatic distribuit este posibilitatea integrării unor sisteme eterogene. Java Message Service (JMS) este o interfață de comunicare prin intermediul unui middleware orientat pe mesaje (MOM), ce oferă abilitatea de procesare a cererilor în mod asincron, oferind fiecărei componente posibilitatea de a pre-lucra datele în ritmul propriu, fără a afecta performanțele altor componente ale sistemului informatic, crescând în acest fel productivitatea utilizatorului final și posibilitatea sistemului de a face față unui volum de date de prelucrat, care poate crește de-a lungul perioadei de exploatare.

Forma generală de interconectare a două aplicații distribuite prin inter-mediul unui MOM este ilustrată mai jos.

Fig. 1.2: Comunicarea între aplicații prin intermediul unui MOM

Unul dintre conceptele de bază ale unui MOM este acela de livrare asincronă a mesajelor între sistemele conectate într-o rețea. Livrarea asincronă a mesajelor presupune că aplicația care trimite un mesaj nu trebuie să aștepte ca mesajul respectiv să fie recepționat sau prelucrat de aplicația căreia i-a fost destinat. Aplicația care produce mesajul are libertatea de a trimite mesajul și de a continua apoi propriul flux de prelucrare.

Mesajele asincrone sunt manipulate ca unități de sine stătătoare, adică fiecare mesaj conține toate datele necesare pentru a putea fi prelucrat din perspectiva logicii aplicației ce se găsește la destinație. In general, aplicațiile utilizează o interfață (Application Programing Interface – API) simplă pentru a construi mesaje, iar aceste mesaje sunt ulterior transmise către platforma de comunicație orientată pe mesaje, pentru ca aceasta din urmă să le livreze către destinațiile avute în vedere.

Arhitecturile utilizate pentru implementarea MOM pot urmări diferite abordări: o arhitectură centralizată, care se bazează pe un server ce re-alizează rutarea mesajelor sau o arhitectură descentralizată, în care se dis-tribuie componenta de rutare a mesajelor pe mașinile clienților. Protocoalele de comunicație utilizate la nivelul de rețea transport includ TCP/IP, HTTP, SSL și IP multicast.

Aplicațiile conectate la platforma de comunicație a sistemului informatics devin clienți ai acestui middleware. Sistemele de comunicație orientate pe mesaje sunt compuse din mesajele aplicațiilor client ale platformei și com-ponenta de server de middleware pentru rutarea acestor mesaje. Clienții transmit mesaje către serverul de mesagerie, iar acestea sunt apoi distribuite de acesta către alți clienți ai sistemului.

3.2.1. Arhitecturi MOM centralizate

Sistemele de mesagerie ce se bazează pe o arhitectură centralizată folosesc un server de mesaje, denumit și router de mesaje sau broker de mesaje, și este responsabil cu livrarea mesajelor între clienții sistemului. Serverul de mesaje realizează, în acest fel, decuplarea clientului care produce mesajul de cel care consumă mesajul respectiv. Clienții intră în contact numai cu serverul de mesaje și nu cu ceilalți clienți ai sistemului, permițând eliminarea sau adăugarea de noi clienți, fără afectarea întregului sistemului.

O arhitectură centralizată utilizează o topologie de tip stea. Configurația cea mai simplă este formată dintr-un broker de mesaje plasat central, la care se conectează toți clienții sistemului. Arhitectura de tip stea oferă un număr minim de conexiuni de rețea, interconectând totodată fiecare componentă a sistemului cu toate celelalte.

Fig. 1.3: Arhitectura MOM centralizată

3.2.2. Arhitecturi MOM descentralizate

În practică, serverul central de mesagerie poate fi o grupare de servere distribuite fizic, dar operând ca o singură entitate la nivel logic. Astfel, o arhitectură MOM centralizată poate furniza un model generic de mesagerie pentru sistemele complexe, oferind un grad înalt de flexibilitateși posibilitatea redimensionării.

Toate arhitecturile descentralizate folosesc la nivel de rețea protocolul IP multicast. Un sistem de mesagerie bazat pe multicasting nu are un server central pentru livrarea mesajelor. Funcționalitățile oferite de serverul aces-tei arhitecturi sunt încorporate în partea de client (facilități de lucru cu tranzacții, aspecte legate de siguranța comunicării), iar rutarea mesajelor este delegată către nivelul de rețea, prin folosirea protocolului IP multicast.

Fiecare grup de multicast folosește o adresă IP de rețea prin care fiecare mesaj ce este primit va fi redistribuit către toți membrii grupului. In acest fel, aplicațiile pot trimite mesaje către o adresă IP de tip multicast și se așteaptă ca nivelul de rețea să asigure distribuirea acestor mesaje în mod corespunzător membrilor care au subscris la acea adresă IP.

Rutarea se realizează în mod automat, la nivel de rețea, fără a mai fi necesar un server dedicat pentru face acest lucru.

Fig. 1.4: Arhitectura MOM descentralizată

Anumite funcționalități oferite de server sunt incluse în fiecare client, aspect ce poate conduce la încărcarea clienților și la distribuirea acestor funcționalități gestionate la nivel logic.

Arhitecturi MOM hibride

O arhitectură centralizată presupune existența unui server de middleware sau a unui cluster de servere, iar într-o abordare descentralizată, serverul se referă la componentele locale de tip server încorporate în client. Arhitec-tura centralizată folosește, în general, protocolul TCP/IP ca bază pentru realizarea comunicării între diversele componente, iar arhitectura descentral-izată implică utilizarea protocolului IP multicast.

O platformă comercială de comunicație, cum ar fi TIBCO Rendezvous, poate combina cele două abordări. Astfel, clienții se pot conecta TCP/IP la un daemon care, la rândul lui, comunică cu alte procese daemon utilizând grupuri de IP multicast. În acest context, termenul de broker sau server de mesaje se referă la o componentă responsabilă de rutarea și distribuirea mesajelor.

Platforme pentru implementarea sistemelor distribuite

4.1. Sisteme de operare pentru sistemele distribuite

În gestiunea și managementul sistemelor distribuite se utilizează software specializat, în funcție de arhitectura sistemului:

DOS (Distributed Operating Systems): sisteme de operare pentru sistemele distribuite puternic cuplate: multiprocesoare și multicalculatoare omogene (este ascuns și gestionează resursele hardware);

NOS (Network Operating Systems): sisteme de operare pentru sistemele distribuite slab cuplate: multicalculatoare eterogene (oferă service pentru clienți de pretutindeni din rețea);

Middleware: nivel adițional al NOS, care realizează comunicarea între entitățile eterogene și asigură transparența sistemului.

Sisteme de operare UNIX

UNIX este cel mai folosit sistem multiuser. Sistemele de operare multiuser au mecanisme adecvate procesării paralele. După implementarea unei probleme pe un calculator paralel, prima sarcină este aceea de a o descompune, astfel încât procesoarele să lucreze simultan la obținerea soluției. Comunicarea între procesoare poate să genereze conflicte, ce pot fi evitate, dacă se are în vedere sincronizarea proceselor și minimizarea numărului de comunicații.

Sistemul de operare UNIX se bazează pe tehnica pipelining, pentru conectarea programelor sau întrepătrunderea execuției coproceselor concurente prin mecanismele fork și join. Mecanismul fork împarte procesul părinte în două coprocese distribuite, iar join recombină două coprocese într-unul singur, cu posibilitatea așteptării (delay), dacă unul din ele nu s-a terminat.

UNIX este dezvoltat de către compania AT&T Bell Laboratories. Sistemele ce cuprind cuvântul UNIX în numele lor sunt autentice, restul sistemelor fiind clasificate în:

sisteme derivate din UNIX (UNIX based);

sisteme similare cu UNIX (UNIX like).

UNIX based sunt sisteme personalizate de către un constructor pe propria mașină, a unui UNIX obținut prin licență de la AT&T. Numele cu sufixul NIX, IX, sau X se aplică versiunilor comerciale ale unor astfel de sisteme, de exemplu:

XENIX (calculatoare personale);

HP-UX (familia Hewlett-Packard 9000);

A/UX (Apple MacIntosh);

AIX/ESA (IBM), SINIX (Siemens);

PARIX, pentru sistemele bazate pe transputere;

DYNIX, pentru sistemul Sequent Symmetry.

Un rol deosebit îl ocupă sistemele de operare SunOS și Solaris ale firmei Sun Microsystems, care fac parte tot din familia UNIX.

Sistemul UNIX este un sistem de operare multitasking și multiuser, utilizabil atât pe un singur calculator, cât și pentru rețele de calculatoare, și suportă următoarele concepte:

multiproces (poate planifica concurent spre execuție mai multe procese);

multiutilizator (poate suporta simultan sesiuni de lucru pentru mai mulți utilizatori);

multiecran (pe ecranul calculatorului pot fi afișate rând pe rând mai multe ecrane virtuale);

multi-interactiv (mai multe procese se pot executa simultan – grad înalt de multiprogramare).

Sisteme de operare Linux

Linux este o versiune de UNIX, distribuită gratuit, dezvoltată în principal de Linus Torvalds la Universitatea din Helsinki, Finlanda. La software-ul pentru Linux, dezvoltat în cadrul proiectului GNU al Fundației pentru Software Liber (Free Software Foundation) din Cambridge, Massachusetts, au contribuit programatorii din întreaga lume. Astăzi, Linux este o variantă de UNIX completă, capabilă să execute Xwindows, TCP/IP, Emacs, poștă electronică și știri.

Pachetele de programe distribuite liber au fost transportate și pe Linux, tot mai multe aplicații comerciale devenind disponibile și pentru acest sistem de operare. Linux este compatibil în mare măsură cu un număr de standarde UNIX, incluzând caracteristicile IEEE POSIX. 1, System V și BSD, la nivel de sursă.

Scopul principal în timpul dezvoltării acestui sistem de operare a fost acela de a asigura un nivel de compatibilitate cât mai mare cu restul sistemelor și aplicațiilor UNIX. Pe sistemul de operare Linux poate fi compilat un număr mare de programe UNIX, accesibile liber, disponibile prin Internet sau altfel. Codul sursă al Linux-ului, incluzând nucleul, driverele pentru periferice, bibliotecile, programele utilizator și utilitarele de dezvoltare sunt distribuite liber.

Caracteristicile Linux-ului sunt:

controlul execuției job-urilor de tip POSIX;

pseudoterminalele, suportul pentru versiuni naționale sau particularizate de tastatură folosind driverele de tastatură încărcate dinamic și console virtual;

nucleul poate emula instrucțiuni în virgulă mobilă astfel încât toate programele pot fi executate și pe procesoare fără coprocesor integrat;

pot fi memorate date în numeroase sisteme de gestiune a fișierelor: cel nativ, ext2fs, dar și Minix-1, Xenix, DOS și ISO9660 pentru discuri;

posedă o implementare completă a suitei de protocoale de comunicație TCP/IP, adică sunt incluse drivere pentru cele mai răspândite plăci de rețea Ethernet, implementări pentru SLIP, PLIP și PPP, sistem de fișiere în rețea (NFS). Tot aici mai este inclusă o gama completă de servicii client și server TCP/IP, cum sunt ftp, telnet, smtp, nntp;

poate lansa execuția programelor cu ajutorul tehnicii de paginare la cerere, adică numai acele porțiuni de program necesare pentru execuție într-un anumit moment sunt citite de pe disc în memoria principală;

utilizează partajarea de memorie între programe cu copiere la scriere, adică are loc o reducere a necesarului de memorie și o mai bună utilizare globală a acesteia;

pentru creșterea memoriei disponibile pentru execuția programelor, Linux implementează paginarea pe disc, permițând alocarea a până la 256 MB a spațiului de swap; nucleul gestionează întreaga memorie internă atât pentru execuția programelor cât și pentru accesul mai rapid la fișiere, de tip cache. Astfel, toată memoria disponibilă este utilizată pentru cache de fișiere; dacă se rulează programe mari, zona de cache este diminuată corespunzător;

programele executabile pot folosi legarea dinamică la bibliotecile partajate: codul bibliotecii, utilizat în comun, se găsește într-un unic fișier pe disc, adică programele executabile pot ocupa mai puțin spațiu;

există și posibilitatea legării statice, când codul este introdus în întregime în fișierul executabil, pentru cei care doresc depanarea sau întreținerea unor executabile complete;

pentru a ușura depanarea programelor, nucleul face posibil vidajul de memorie și analiza lui în cazul terminării anormale, pentru a putea determina cauzele execuției defectuoase.

În UNIX/ Linux mai mulți utilizatori pot folosi calculatorul în același timp executând independent aplicații diferite. Un utilizator este o persoană care poate interacționa cu sistemul prin deschiderea unei sesiuni de lucru, fie de la un terminal, fie din alt sistem în cadrul rețelei.

Linux oferă un mediu complet UNIX pentru dezvoltarea de programe și aplicații, incluzând bibliotecile standard, compilatoarele, depanatoarele și întregul set de utilitare software necesar.

În mod obișnuit, dezvoltarea de programe pentru UNIX se face în limbajele C/C++. Compilatorul standard pentru aceste limbaje este compilatorul GNU, gcc pentru C și g++ pentru C++. Alte limbaje compilate sau interpretate, disponibile sub Linux, sunt: Smalltalk, FORTRAN, Pascal, Lisp, Scheme, JAVA și Ada.

Asambloare disponibile pentru scrierea de cod în mod protejat sunt pentru i80386. Interpretoarele pentru dezvoltarea de aplicații sub Xwindow, folosite de UNIX, cum este Perl sau Tcl/Tk, sunt disponibile și sub Linux. Depanatorul standard care permite execuția controlată a unui program sau analiza unui vidaj de memorie este gdb.

Cu ajutorul utilitarului Gprof se realizează culegerea de statistici referitoare la execuția unui program în scopul ameliorării performanțelor sale. Utilitarul pentru compilarea aplicațiilor mari este make, și un sistem pentru întreținerea versiunilor unui program este RCS. Legarea bibliotecilor se poate face dinamic, permițând fișiere executabile mici sau înlocuirea de rutine din bibliotecă cu rutine utilizator.

Linux este un mediu modern, standard și bine echipat pentru dezvoltarea de programe. Utilitarul make a fost creat pentru întreținerea programelor mari, compuse dîntr-o mulțime de fișiere sursă, cu problemă la compilare. Pe baza unui fișier de descriere, make determină ce componentă trebuie recompilată și execută comenzile corespunzătoare pentru recompilare. Fișierul de descriere al lui make poate fi makefile sau Makefile, dar poate avea orice nume dorit dacă se lansează: $ make -f nume_makefile

Un fișier makefile este în principal compus din reguli și poate folosi schema următoare:

ȚINTA (sau SCOPUL): DEPENDENłE

COMANDA1

COMANDA2

ȚINTA sau SCOPUL este de obicei numele unui fișier generat sau actualizat de program. O dependență este un fișier utilizat în crearea țintei. O țintă poate avea mai multe dependențe care apar pe aceeași linie.

Exemplu. Se consideră fișierul makefile:

prog: principal.o sub1.o sub2.o

cc -o prog principal.o sub1.o sub2.o

principal.o: principal.c def.h

sub1.o: sub1.c def.h

sub2.o: sub2.c def.h

clean:

rm -rf prog *.o

Fișierul descrie dependențele programului executabil prog. Acesta este compus din modulele obiect principal.o, sub1.o, sub2.o. Este regula pe care make o aplică implicit. Dacă unul din modulele obiect este mai recent decât executabilul, atunci se va da comanda de link-edit-are asociată.

Tot pentru vizualizarea proceselor din sistem se poate folosi programul top (Linux) prin comanda:

$ top [opțiuni] [fișier]

Programul permite monitorizarea în timp real a proceselor din sistem și a altor parametrii cum ar fi încărcarea sau utilizarea memoriei.

Lista opțiunilor pentru vizualizarea proceselor din sistem:

k – distruge un proces;

i – afișează doar procesele active;

n sau # – modifică numărul proceselor afișate;

r – modifică prioritatea a unui proces;

S – schimbă modul cumulativ; totalizează sau nu și timpul proceselor;

s – schimba intervalul de actualizare a datelor pe ecran;

f sau F – adaugă sau scade câmpuri afișate;

o sau O – modifică ordinea de afișare a informațiilor;

Utilizatorul are posibilitatea să determine terminarea forțată a unor procese care lucrează, durează mult, nu evoluează conform așteptărilor, sunt blocate în așteptarea unor condiții care nu se vor îndeplini niciodată.

Pentru aceasta el are la dispoziție comanda:

$ kill [număr_semnal] identificator_proces

Comanda kill poate controla într-un mod complex execuția proceselor, mod dependent chiar de procesele controlate. Procesele pot primi din exterior semnale și pot reacționa la acestea în modul în care programatorul crede de cuviință. Semnalul SIGKILL (cu numărul 9) nu poate fi tratat de procese și efectul va fi ca procesul dispare. Opțiunea -l tipărește o listă a semnalelor disponibile în sistem pentru comunicarea cu procesele.

Cea mai frecventă utilizare este de forma: $ kill -SIGTERM 678 și transmite procesului cu identificatorul 678 semnalul SIGTERM în speranța că acesta se va termina. În administrarea sistemului se folosesc frecvent semnalele SIGHUP sau SIGINT pentru a comunica unui server faptul că s-au efectuat modificări în sistem și acestea trebuie să-și recitească fișierele de configurație.

Modificarea priorității de execuție a unui proces se realizează prin comanda:

$ nice [-increment] comanda [argumente]

Astfel, comanda se va executa la o prioritate, mai mică. Prioritatea de planificare este un număr întreg între -20 (cea mai mare prioritate) și 19 (cea mai mică). Prioritatea moștenită se incrementează. Dacă nu se specifică, prioritatea este implicit egală cu 10.

Sistemul de operare PARIX

PARIX este un sistem de operare destinat transputerelor. Limbajele de programare care permit utilizarea facilităților acestui sistem sunt: C, ANSI C, PASCAL, MODULA, C++, FORTRAN 77, FORTRAN 90. Fiecare procesor aparține partiției de lucru destinată utilizatorului și deține o copie a programului.

Comportarea diferită a procesoarelor se datorează:

execuției codului care depinde de poziția procesorului în rețea;

execuției unor instrucțiuni identice asupra unor date diferite.

Topologia rețelei fizice a unui sistem de transputere sub PARIX este bazat pe o grilă tridimensională. Sistemul permite și emularea pe o grilă bidimensională. Identificarea poziției unui procesor este esențială pentru execuția unui program. Ea este realizată printr-un set de date globale păstrate în fiecare nod-element de procesoare.

Principalele date sunt:

dimensiunile spațiale ale rețelei de procesoare;

numărul de procesoare din rețea;

poziția în spațiu a procesorului;

identificatorul procesorului(utilizat pentru a atribui date sau cod unui processor).

Mecanismul de accesare a datelor de identificare diferă de la un limbaj la altul. Partea statică a unui program sub sistem PARIX include un mecanism inițial de încărcare care distribuie un program “principal” identic tuturor procesoarelor.

Datele globale ale unui nod conțin setul ce permite identificarea poziției procesorului în rețea (din structura rădăcină). Depinzând de poziția proprie, fiecare procesor execută diferite secțiuni ale programului.

Facilitățile de comunicare sub PARIX sunt reprezentate de legăturile virtuale. O legătură virtuală este o linie de comunicare între două procesoare, bidirecțională, sincronizată, ce nu utilizează spații de memorie. Definirea corectă a unui set de legături virtuale permite construirea unei topologii virtuale. Un exemplu sugestiv este arborele binar sau hipercubul.

Există patru tipuri de comunicare posibile în sistemul PARIX:

comunicarea sincronă printr-o legătură virtuală;

Procesele conectate printr-o legătură virtuală sunt sincronizate în timpul comunicării. Procesul care atinge primul un punct de comunicare așteaptă intrarea în aceeași fază a celuilalt, astfel încât transferul de date are loc numai atunci când ambele procese sunt pregătite pentru comunicare. Un proces poate aștepta comunicațiile prin mai multe legături.

Funcțiile C de bibliotecă utilizate pentru comunicarea sincronă printr-o legătură virtuală sunt: Send( ), Recv( ), SendLink( ), RecvLink( ), Select( );

comunicarea sincronă aleatoare;

Acest tip de comunicare nu necesită definirea unor legături virtuale. Funcțiile C de bibliotecă sunt: SendNode( ), ReceiveNode( );

comunicarea asincronă printr-o legătură virtuală;

Comunicarea se efectuează simultan cu calculul. Emiterea și recepționarea informațiilor se realizează în timp ce procesul continuă execuția. Mesajele sunt stocate în spații de memorie intermediare, atât la emițător cât și la receptor.

Funcțiile C de bibliotecă, corespunzătoare sunt: AInit( ), ASend( ), ARecv( ), ASync( );

comunicarea asincronă aleatoare este bazată pe principiul „cutiilor poștale”.

Nu este necesară o legătură virtuală între cele două procese care comunică. Transferul de date are loc pe baza utilizării rețelei fizice. Procesul receptor are posibilitatea de a gestiona „cutia poștală” și poate aștepta sosirea unui anumit mesaj.

Funcțiile specific din C sunt: PutMessage(), GetMessage( ), ExchangeMessage( ).

Performanțele de comunicare se obțin în cazul primelor trei tipuri. Pentru realizarea asincronă a unor operații distincte se utilizează tehnica thread, ce permite rularea concurentă în același context și partajarea tuturor variabilelor globale definite în program. Sincronizarea se realizează prin operarea asupra unor semafoare. Tehnica thread permite rularea concurentă a mai multor procese pe un singur procesor.

Într-un sistem de calcul distribuit, procesul este creat în memoria calculatorului de către sistemul de operare atunci când utilizatorul comandă calculatorului execuția unui program și este format din instrucțiuni, date și o parte administrativă.

În memoria calculatorului informația unui proces se organizează în trei regiuni repartizate în două zone:

partea administrativă a procesului (tabelul paginilor de memorie alocate, fișiere deschise, valoarea registrului numărător de program la pierderea controlului CPU etc.) este în zona alocată sistemului de operare;

instrucțiunile și datele, care sunt repartizate în zona utilizator.

Un proces poate fi activ (atâta timp cât sistemul execută instrucțiuni ale sale) sau inactiv (când nu este în execuție și se află într-una din stările: gata de execuție, în așteptare pe disc etc.). Sistemul de operare acționează ca un comutator, repartizând diferitele procese diverselor procesoare (planificarea proceselor) și protejând zonele de memorie ale fiecărui proces (gestiune a memoriei).

Procesele concurente pot fi create în mod static (dacă sunt specificate înaintea execuției, numărul de procese fiind fix) sau dinamic (dacă se generează și se distrug în timpul execuției, atuncu numărul de procese este variabil).

În ambele cazuri programele sunt compilate și transformate în coduri executabile înaintea execuției propriu-zise. Pentru execuția unui program paralel, procesele concurente pot fi grupate și asignate unor procesoare virtuale (unități de planificare).

Paralelismul este introdus atât de ansamblul proceselor definite în cadrul programului cât și de ansamblul procesoarelor. Se definesc următoarele tipuri de paralelism:

paralelismul pur presupune ca fiecare proces să fie încapsulat de un procesor virtual constituit dintr-un singur procesor;

paralelismul la nivel de utilizator constă în faptul că un procesor virtual, format dintr-un singur procesor, are mai multe procese;

paralelismul la nivel de sistem se referă la un procesor virtual ce încapsulează un singur proces, iar pe un procesor sunt definite mai multe procesoare virtuale;

paralelismul dublu imbricat presupune ca un procesor virtual să încapsuleze mai multe procese și pe un singur procesor să se definească mai multe procesoare virtuale.

Sistemele de operare sunt programe paralele, formate din supervizoare separate pentru fiecare procesor (o copie a sistemului de operare), o structură formată dintr-un procesor ce lucrează în mod supervisor și celelalte componenete care lucrează în mod utilizator. Sistemul de operare se execută de către toate procesoarele, adică are o structură simetrică.

În cazul în care limbajul de programare paralelă nu permite exprimarea explicită a paralelismului, pentru crearea și distrugerea proceselor paralele se pot folosi construcții de tipul: process_fork, ce are ca efect copierea zonei de memorie ocupată de procesul părinte de un număr de ori dat de numărul proceselor nou create, cu excepția regiunii partajate cu alte procese, și process_join, cu efect de asociere a proceselor.

Când se încarcă programul în memorie, se creează un număr de copii ale procesului părinte, egal cu numărul de procesoare, iar după încărcare se trece controlul procesului părinte, singurul care se execută. Când acesta apelează process_fork, execuția va începe din punctul indicat în apel, iar la întâlnirea unui apel process_join, firul de execuție este suspendat până la întâlnirea unui nou process_fork. Pentru această operație se extinde modelul de proces prin crearea unei biblioteci pentru fire de execuție sau prin modificări ale sistemului UNIX (utilizarea sistemului MACH, SYMUNIX, TROLLIUS sau IDRIS).

O facilitate dinamică este posibilitatea de încărcare a unui cod adițional la orice moment pentru unul sau mai multe procesoare. Funcția C de bibliotecă care permite apelul unor coduri adiționale este Execute().

Fiecărei legătură virtuală are asociat un bloc de control a legăturii, LinkCB. Comunicațiile prin legăturile virtuale se realizează pe baza accesării blocului LinkCB corespunzător. Într-o topologie virtuală, comunicarea datelor se efectuează pe baza aceluiași mecanism, dar blocul de control este înlocuit cu anumite adrese topologice, identificate prin ID și poziții relative.

Legăturile care constituie structura unei grile tridimensionale pot fi gestionate separat de legăturile care formează un hipercub. O legătură din acest context poate fi specificată prin numărul de legătură relativ la topologia virtuală. Se pot conferi nume simbolice legăturilor unei grile bidimensionale (nord, spre exemplu) sau legăturii dintr-un arbore (părinte sau fiu). Funcțiile Send(), Recv(), ASend(), ARecv() operează asupra topologiilor virtuale prin specificarea orientării relative în topologie, iar funcțiile SendLink(), RecvLink() se referă direct la blocul de control LinkCB.

Biblioteca topologiilor virtuale este folosit la construirea rețelelor de comunicare, pentru anumite probleme standard. Prin utilizarea topologiilor din bibliotecă, la execuție se realizează o optimizare a legăturilor virtuale pe structura fizică de comunicare la nivelul:

legăturilor virtuale, transpunerea pe rețea se realizează implicit;

topologiilor definite de utilizator, transpunerea se face de asemenea implicit;

topologiilor din bibliotecă, se realizează optimizarea proiecției pe rețeaua fizică.

Pentru adăugarea unor legături suplimentare într-o topologie virtuală, au fost construite o serie de funcții care extrag blocul de control al unei legături dintr-o topologie dată. Multiplicarea mesajelor se realizează la execuția programului, cand este multiplicat la numărul de procesoare specificat în comanda run.

Parallel Virtual Machine

PVM (Parallel Virtual Machine) este un pachet de programe dezvoltat de Oak Ridge National Laboratory, Universitatea statului Tennessee și Universitatea Emory, ce permite ca o mulțime eterogenă de mașini UNIX (PC, stații de lucru, calculatoare paralele, calculatoare vectoriale), legate în rețea, să funcționeze ca un singur calculator paralel.

Prin utilizarea puterii de calcul a mai multor calculatoare, pot fi rezolvate probleme care necesitau utilizarea unor calculatoare paralele foarte puternice (cu prețuri de circa 10 milioane dolari). Astfel, prin conectarea în această rețea a unor calculatoare masiv paralele sau supercalculatoare, se poate obține o putere de calcul foarte greu de realizat.

Sistemul prototip PVM 1.0, folosit doar în cadrul laboratorului, a fost conceput de Vaidy Sunderam si Al Geist. A doua versiunea a PVM, utilizat pentru rezolvarea multor probleme științifice, a fost scrisă la Universitatea Tennessee și distribuită în martie 1991. În februarie 1993, PVM a fost complet rescris, adăugându-se si o interfață grafică X-window, numită XPVM.

PVM asigură un mediu de lucru unitar în care programele paralele pot fi dezvoltate într-un mod eficient, utilizând mediul hardware existent. Utilizatorul va scrie aplicațiile ca o colecție de taskuri care cooperează în PVM. Aceste taskuri vor accesa resursele PVM cu ajutorul unor biblioteci de rutine de interfață.

Rutinele din cadrul bibliotecilor asigură inițierea si terminarea taskurilor, comunicarea si sincronizarea între taskuri. În orice punct al execuției unei aplicații concurente, orice task în execuție poate iniția sau termina alte taskuri, poate adăuga sau elimina calculatoare din mașina virtuală.

Utilizatorii pot scrie aplicații paralele în Fortran sau C utilizând Rutinele din bibliotecile PVM. Modelul de programare utilizat este cel cu transfer de mesaje, adică prin trimiterea si recepționarea mesajelor, taskurile aplicației cooperează pentru a rezolva o problemă în paralel.

Componentele unui sistem PVM sunt:

demon, numit pvmd3 sau pvmd, este un program care trebuie lansat în background, pe fiecare procesor fizic participant la mașina virtuală și care rămâne în așteptarea unei solicitări la care să răspundă.

După logare, utilizatorul care dorește să ruleze o aplicație PVM, își creează mașina virtuală si apoi pornește mașina. O aplicație PVM poate fi pornită de la orice gazdă. Mai mulți utilizatori pot configura mașini virtuale care se pot suprapune, iar fiecare utilizator poate executa câteva aplicații PVM simultan.

biblioteca de rutine PVM conține un set complet de primitive care sunt necesare pentru cooperarea între taskuri . Conține un set de funcții prin intermediul cărora aplicația PVM poate folosi mecanismele de schimb de mesaje, sincronizare între procese, de creare de noi procese sau de modificare a mașinii virtuale oferite de PVM. Deoarece PVM suportă programe scrise în limbajele C si FORTRAN, există de două biblioteci: una pentru C (libpvm3.a) si alta pentru FORTRAN (libfpvm3.a).

Modelul de calcul utilizat de PVM se bazează pe faptul că o aplicație este alcătuită din mai multe taskuri. Fiecare task este responsabil pentru calculul unei părți a problemei.

Există două modele ce pot fi utilizate pentru a dezvolta o aplicație PVM:

Dacă o aplicație este paralelizată din punct de vedere al funcțiilor pe care le realizează, adică fiecare task execută o funcție diferită (de exemplu intrare, soluționare, ieșire, afișare). Acest proces se numește paralelism funcțional.

O altă metodă de paralelizare este exploatarea paralelismului datelor, denumită SPMD (Single Program Multiple Data). În cadrul acestei metode toate taskurile sunt identice, dar fiecare task deține și utilizează pentru rezolvare numai o parte din date.

Principiile unui sistem PVM sunt următoarele:

“Host-pool” configurat de utilizatori: taskurile aplicației sunt executate pe un set de mașini, numite host, care sunt selectate de utilizatori pentru o rulare dată a PVM. Un host-pool poate fi compus atât din mașini uniprocesor, cât si mașini multiprocessor, incluzând calculatoare cu memorie partajată si cu memorie distribuită. În timpul rulării, pentru asigurarea toleranței la defecte, se pot adăuga sau elimina mașini.

Acces transparent la hardware: programele de aplicație pot vedea mediul hardware ca o colecție de procesoare virtuale asemănătoare sau pot alege ca părți ale problemei să fie rulate pe o anume gazdă, adică pe cea mai potrivită pentru subproblema respectivă.

Calcul bazat pe procese: unitatea de calcul în cadrul PVM este taskul (care poate fi un proces UNIX). Nu este implicată o mapare proces – procesor, în particular mai multe taskuri pot fi executate într-un singur processor.

Model message-passing: taskurile unei aplicații cooperează prin trimitere si recepționare de mesaje, a căror dimensiune este limitată de mărimea memoriei disponibile.

Suport pentru eterogenitate: sistemul PVM suportă eterogenitatea în termenii mașinii, ai rețelei și ai aplicațiilor și permite ca mesajele să conțină mai mult de un singur tip de date și să fie schimbate între mașini cu reprezentări diferite ale datelor.

Suport pentru multiprocesoare: PVM utilizează facilitățile hardware native de transfer a mesajelor din cadrul sistemelor multiprocesor.

Toate taskurile PVM sunt identificate cu un întreg numit task identifier (TID). Aceste TID-uri trebuie să fie unice în cadrul mașinii virtuale si sunt asigurate de demonul pvmd local. PVM conține rutine care returnează valoarea TID, astfel încât aplicațiile pot identifica taskurile din sistem.

Pentru a programa o aplicație, un utilizator trebuie să scrie unul sau mai multe programe secvențiale în C, C++, Fortran 77, cu apeluri la rutinele din bibliotecile PVM.

Fiecare program este, de fapt, un task și toate aceste taskuri formează aplicația, a cărui execuție poate fi paralelizată prin intermediul unor primitive de comunicație prin mesaje, tipice oricărei mașini MIMD cu memorie distribuită. În acest fel, prin schimb de mesaje, mai multe task-uri pot coopera pentru rezolvarea paralelă a unei probleme.

Fiecare task din PVM este compilat pentru fiecare arhitectură existentă în host-pool și fișierele se vor plasa la locații accesibile mașinilor din host-pool. Pentru a executa o aplicație, un utilizator inițiază o copie a unui task master de la o mașină din host-pool, iar acesta va iniția taskuri PVM care pot fi rulate pe alte mașini sau pe aceeași mașină cu taskul master.

O aplicație poate accesa resursele de calcul în trei moduri diferite:

modul transparent, în care taskurile sunt plasate automat de sistem pe mașina potrivită, fără intervenția utilizatorului;

modul dependent de arhitectură, în care utilizatorul poate indica o arhitectură specifică pe care un task să fie executat;

modul „lowe-level”, cu specificare a mașinii, în care utilizatorul poate specifica un anumit task să se execute pe o anumită mașină.

Obiectivul general al sistemului PVM este să permită unei mulțimi de calculatoare să fie utilizată pentru calculul paralel sau concurent. În Statele Unite cei mai importanți utilizatori sunt NASA, Departamentul Energiei, precum și numeroasele universități unde este utilizat atât pentru cercetare cât si pentru realizarea orelor de aplicații.

În România, PVM este utilizat în Universitatea Transilvania Brașov, unde se desfășoară un seminar PVM, Universitatea Tehnică "Gh. Asachi" Iași în cadrul orelor de aplicații la cursul de calcul paralel și distribuit, Universitatea "Politehnica" București, Universitatea Tehnică Timișoara și Universitatea din Oradea.

Există numeroase sisteme software cu o funcționalitate asemănătoare PVM: P4 (Argonne National Laboratory), Express (ParaSoft Corporation), Linda (Scientific Computing), MPI (Message Passing Interface).

Message Passing Interface (MPI)

MapReduce este o paradigmă de programare folosită pentru procesarea unor cantități mari de date în mod paralel și distribuit pe un cluster.[1]

Un program MapReduce este compus dintr-o procedură Map() care selectează și sortează datele și o procedură Reduce() care îndeplinește operația de însumare a rezultatelor. Sistemul MapReduce administrează serverele distribuite, se asigură că diferitele sarcini sunt rulate în paralel, administrează comunicarea și tranferul de date dintre diferitele componente ale sistemului și oferă suport în cazul în care apar erori în sistem.

Modelul este inspirat din funcțiile Map și Reduce care apar în programarea funcțională, mai precis din programul Lisp [2], deși scopul lor în paradigma MapReduce este diferit față de cel din acest program.[3] Mai mult, contribuțiile cheie ale paradigmei MapReduce nu sunt procedurile Map și Reduce în sine, ci scalabilitatea (caracteristică a unui sistem informatic de a se comporta similar, fără defecțiuni, atunci când volumul de date pe care îl prelucrează devine mai mare) și rezistența la stres, obținute prin optimizare.

Librariile MapReduce sunt scrise în mai multe limbaje de programare. O implemetare foarte cunoscută este Apache Hadoop.

Wiki???

Java Message Service (JMS)

Java Message Service (JMS) este o interfață de comunicare orientată pe mesaje creată de către Sun Microsystems pe baza specificațiilor JSR-914 (Java Specification Request), publicate la începutul anului 2002. JMS nu este un sistem de mesagerie în sine, ci o interfață abstractă, care împreună cu clasele necesare clienților unui sistem de mesagerie permite aplicațiilor să creeze, să trimită, să recepționeze și să citească mesaje ce conțin informații. Utilizând interfața JMS, o aplicație client a unui sistem de mesagerie devine portabilă din perspectiva serverului concret de mesagerie la care se conectează

Obiectivul inițial a fost acela de a furniza un API Java pentru conexiunea la sisteme de mesagerie deja existente la acel moment. Ulterior, scopul proiectului început de Sun Microsystems a fost oferirea unei alternative de comunicare, prin intermediul unui MOM, la paradigma de comunicare creată prin existența sistemelor bazate pe RPC, precum CORBA și EnterpriseJava- Beans.

O aplicație JMS are următoarele componente:

un furnizor JMS este un sistem de mesagerie care implementează interfețele JMS și permite controlul serviciului. Cel mai utilizat furnizor JMS este inclus pe platforma J2EE;

clienții JMS sunt programe sau componente Java care produc sau con- sumă mesajele gestionate de furnizor;

mesajele sunt obiecte ce transmit informații între clienții JMS;

obiectele administrative sunt obiecte JMS preconfigurate și create de un administrator pentru a fi utilizate de clienți. Sunt de două tipuri: destinații și fabrică de conexiuni;

clienții non JMS sunt programe care scriu sau consumă mesaje din ser- viciul propriu și sunt implementate într-o manieră nativă, dependentă de platformă.

Toate aceste componente interacționează datorită legăturii dintre destinații și fabrica de conexiuni, ce se realizează în spațiul de nume API Java Naming and Directory Interface (JNDI). Un client JMS poate căuta obiectele administrate în spațiul de nume și apoi să stabilească o legătură logică cu aceleași obiecte cu ajutorul furnizorului JMS.

Producerea și consumarea mesajelor este o activitate asincronă, în sensul că nu există o dependență fundamentală între momentul producerii și consumării unui mesaj. Specificațiile JMS folosesc termenii de sincronizare astfel:

consumare sincronă: consumatorul preia în mod explicit mesajul de la destinație apelând metoda receive(). Metoda invocată poate bloca consumatorul până la apariția mesajului sau poate aștepta această sosire un interval maxim de timp;

consumare asincronă: consumatorul definește un message listener. Ori de câte ori mesajul sosește la destinație, furnizorul JMS livrează mesajul de apel ascultătorului ca argument al metodei onMessage(), care acționează asupra conținutului mesajului.

Componentele unei aplicații JMS sunt următoarele:

obiecte administrative: fabrică de conexiuni și destinații;

conexiuni;

sesiuni;

producători de mesaje;

consumatori de mesaje;

mesaje.

4.7.1. Obiecte administrative

Cele două obiecte administrative ale unei aplicații JMS sunt fabrica de conexiuni și destinațiile. Tehnologia care stă la baza acestor componente diferă de la o implementare a JMS API la alta.

De obicei, un administrator configurează obiectele administrative în spațiul de nume al API Java Naming and Directory Interface (JNDI), iar clienții JMS le caută folosind JNDI API.

Fabrica de conexiuni este un obiect pe care un client îl folosesc pentru a crea o conexiune cu un furnizor. În avest obiect sunt încapsulați un set de parametri de configurare definiți de către un administrator.

O pereche de fabrici de conexiuni este predefinită în J2EE SDK și este accesibilă imediat ce pornește serviciul. Obiectele predefinite implicit pentru a crea conexiuni sunt: interfața QueueConnectionFactory sau interfața TopicConnectionFactory.

Deasemenea, se pot crea noi fabrici de conexiuni utilizând următoarele comenzi: j2eeadmin −addJmsFactory jndi name queue

j2eeadmin −addJmsFactory jndi name topic

La începutul unui program client JMS se efectuează, de obicei, căutarea de fabrică de conexiuni în JNDI API. De exemplu, următorul fragment de cod obține un obiect InitialContext și îl folosește pentru a căuta după nume QueueConnectionFactory și TopicConnectionFactory:

Context ctx = new InitialContext ();

QueueConnectionFactory queueConnectionFactory = (QueueConnectionFactory) ctx. lookup (”QueueConnectionFactory”) ;

TopicConnectionFactory topicConnectionFactory = (TopicConnectionFactory) ctx. lookup (”TopicConnectionFactory”) ;

Apelarea metodei InitialContext fără parametri realizează căutarea căii curente pentru un fișier specific numit jndi.properties. Acest fișier indică ce implementare a JNDI API se va folosi și ce spațiu de nume se va utiliza.

O destinație este obiectul pe care un client îl folosește pentru a specifica ținta mesajelor pe care le produce și sursa mesajelor pe care le consumă.

În domeniul de mesaje point-to-point, destinațiile sunt numite cozi, și pentru a le crea se utilizează următoarea comandă J2EE SDK:

j2eeadmin −addJmsDestination queue namequeue

În domeniul de mesaje publicare/înscriere, destinațiile poartă numele de topic și se pot obține rulând următoarea comandă în editorul J2EE SDK:

j2eeadmin −addJmsDestination topic nametopic

Într-o aplicație JMS se pot folosi mai multe cozi sau topic-uri. Pentru a căuta un topic denumit MyTopic, creat anterior și pe care îl atribuie unui obiect de tip Topic, se utilizează următoarea linie de cod:

Topic myTopic = (Topic) ctx.lookup (”MyTopic”);

Pentru a căuta o coadă denumită MyQueue și pe care o atribuie unui obiect de tip Queue, se utilizează următoarea linie de cod:

Queue myQueue = (Queue) ctx.lookup (”MyQueue”);

4.7.2. Conexiuni

O conexiune încapsulează o conexiune virtuală cu un furnizor JMS. O conexiune ar putea reprezenta un socket TCP/IP deschis între un client și un furnizor de servicii daemon. O conexiune se folosește pentru a crea una sau mai multe sesiuni.

Conexiunile se împart în două categorii: QueueConnection sau TopicConnection. După obținerea obiectelor QueueConnectionFactory sau TopicConnectionFactory se poate crea o conexiune astfel:

QueueConnection queueConnection = queueConnectionFactory.createQueueConnection ();

TopicConnection topicConnection = topicConnectionFactory.createTopicConnection();

Când o aplicație se termină, toate conexiunile create trebuie închise. În cazul în care nu se face acest lucru, resursele alocate de către JMS nu vor fi dezalocate.

Închiderea unei conexiuni implică, de asemenea, închiderea sesiunilor, ale producătorilor de mesaje și ale consumatorilor de mesaje.

queueConnection.close();

topicConnection.close();

Sesiuni

Sesiunea reprezintă contextul în care se produc și se consumă mesajele. În cadrul sesiunilor se creează producători de mesaje, consumatori de mesaje și mesaje.

Sesiunile se împart în două categorii: QueueSession și TopicSession. După obținerea unui obiect TopicConnection se poate crea o sesiune TopicSession:

TopicSession topicSession = topicConnection.createTopicSession(false, Session. AUTOACKNOWLEDGE);

Primul parametru al metodei createTopicSession indică faptul că sesiunea nu a început, iar al doilea arată că sesiunea recunoaște automat mesajele atunci când au fost primite cu succes. Similar, se folosește un obiect QueueConnection pentru a crea o sesiune QueueSession:

QueueSession queueSession = queueConnection.createQueueSession (true , 0);

Primul parametru al metodei createQueueSession arată că sesiunea s-a terminat, iar al doilea indică faptul că mesajul de confirmare nu este specificat pentru sesiunile tranzacționate.

Producători de mesaje

Un producător de mesaje este un obiect creat de o sesiune și este folosit pentru a trimite mesaje către o destinație.

Un producător de mesaje din domeniul point-to-point implementează interfața QueueSender, iar unul din domeniul publicare/înscriere implementează interfața TopicPublisher.

Pentru a crea un producător pentru coada myQueue se folosește QueueSession, iar pentru topicul myTopic se folosește TopicSession.

QueueSender queueSender = queueSession.createSender (myQueue);

TopicPublisher topicPublisher = topicSession.createPublisher (myTopic);

Se poate crea un producător neidentificat, prin specificarea argumentului null pentru metoda createSender() sau createPublisher(), dar trebuie specificată destinația pentru a trimite mesajul.

După ce s-a creat producătorul, se trimit mesaje către o destinație. Metoda send() se folosește pentru QueueSender, iar metoda publish() pentru TopicPublisher:

queueSender.send(message);

topicPublisher.publish (message);

Consumatori de mesaje

Un consumator de mesaje este un obiect creat de o sesiune și este folosit pentru primirea mesajelor trimise la o destinație. Furnizorul JMS se asigură că toți consumatorii de mesaje înregistrați unei destinații primesc mesajele adresate lor.

Dacă folosim domeniul point-to-point în transmiterea mesajelor, consumatorii de mesaje implementează interfața QueueReceiver, iar cei din domeniul publicare/înscriere implementează interfața TopicSubscriber. Pentru a crea un consumator pentru coada myQueue, se utilizează QueueSession, iar pentru crearea unui consumator pentru topic-ul myTopic se folosește TopicSession.

QueueReceiver queueReceiver = queueSession.createReceiver (myQueue);

TopicSubscriber topicSubscriber = topicSession.createSubscriber (myTopic);

Odată ce a fost creat consumatorul, el devine activ, și poate fi folosit pentru a recepționa mesaje. Consumatorul devine inactiv prin apelarea metodei close() pentru QueueReceiver sau TopicSubscriber.

Livrarea mesajelor începe atunci când pornește conexiunea, prin apelarea metodei start().

Pentru consumarea unui mesaj sincron se utilizează metoda receive() astfel:

queueConnection.star ();

Message m = queueReceiver.receive ();

topicConnection.start();

Message m = topicSubscriber.receive (1000) ; // pauză de o secundă

Mesaje

Scopul fundamental al unei aplicații JMS este de a produce și a consuma mesaje. Mesajele JMS au un format simplu, dar flexibil, ce permite crearea altor mesaje, care se potrivesc cu formatele folosite de aplicații non- JMS pe platforme eterogene.

Un mesaj JMS are trei componente:

antet;

proprietăți;

corp.

Un mesaj JMS joacă un rol unic în domeniul sistemelor distribuite. El poate transporta atât date specifice de aplicație, cât și notificări pentru evenimente legate de activitatea aplicațiilor sistemului.

Un astfel de mesaj JMS nu îi impune aplicației care îl recepționează ce anume să facă cu el, iar aplicația care l-a produs nu așteaptă după un răspuns. Se obține în acest fel o decuplare a producătorului mesajului de consumatorul acestuia, făcând sistemele orientate pe mesaje mult mai dinamice și mai flexibile decât cele bazate pe paradigma cerere-răspuns realizate în maniera sincronă.

Mesajele JMS pot fi de mai multe tipuri, în funcție de maniera în care sunt organizate datele utile de transferat (payload), respectiv pot fi foarte structurate, cum sunt StreamMessage și BytesMessage, sau aproape deloc structurate, cum sunt tipurile TextMessage, ObjectMessage și MapMessage.

Proprietățile unui mesaj JMS acționează ca elemente de caracterizare suplimentară a mesajului, pe lângă cele conținute de antet. Ele permit programatorului să adauge mai multe informații structurate cu privire la conținutul mesajului.

Interfața Message oferă metode de acces și modificare a acestor proprietăți. Valoarea luată de o proprietate poate fi de următoarele tipuri: String, boolean, byte, short, int, long, float sau double.

Există trei categorii de proprietăți care se pot asocia unui mesaj JMS:

proprietăți specifice aplicației;

proprietăți definite de către interfața JMS;

proprietăți specifice serverului de mesagerie.

Proprietățile specifice aplicației sunt setate înainte ca mesajul să fie livrat sistemului. Există numeroase metode în interfața Message care sunt destinate accesului și setării diferitelor tipuri de proprietăți.

package javax . jms ;

public String getStringProperty(String name) throws JMSException, MessageFormatException;

public void setStringProperty(String name, String value) throws JMSException, MessageNotWriteableException;

public int getIntProperty(String name) throws JMSException, MessageFormatException;

public void setIntProperty(String name, int value) throws JMSException, MessageNotWriteableException;

public boolean getBooleanProperty(String name) throws JMSException, MessageFormatException;

public void setBooleanProperty(String name, boolean value) throws JMSException, MessageNotWriteableException;

public double getDoubleProperty(String name) throws JMSException, MessageFormatException;

public void setDoubleProperty(String name, double value) throws JMSException, MessageNotWriteableException;

public float getFloatProperty(String name) throws JMSException, MessageFormatException;

public void setFloatProperty(String name, float value) throws JMSException, MessageNotWriteableException;

public byte getByteProperty(String name) throws JMSException, MessageFormatException;

public void setByteProperty(String name, byte value) throws JMSException, MessageNotWriteableException;

public long getLongProperty(String name) throws JMSException, MessageFormatException;

public void setLongProperty(String name, long value) throws JMSException, MessageNotWriteableException;

public short getShortProperty(String name) throws JMSException, MessageFormatException;

public void setShortProperty(String name, short value) throws JMSException, MessageNotWriteableException;

public Object getObjectProperty(String name) throws JMSException, MessageFormatException;

public void setObjectProperty(String name, Object value) throws JMSException, MessageNotWriteableException;

public void clearProperties() throws JMSException;

public Enumeration getPropertiyNames() throws JMSException;

public boolean propertyExists(String name) throws JMSException;

Odată ce un mesaj este publicat sau transmis, proprietățile asociate acestuia devin protejate la scriere și nu mai pot fi schimbate de către consummator sau de către producător.

Proprietățile pot fi schimbate la nivel de mesaj prin invocarea metodei clearProperties(), care va șterge toate proprietățile mesajului, permițând astfel adăugarea unor proprietăți noi. Metoda getPropertyNames(), componentă a interfeței Message, poate fi utilizată pentru a obține într-un tip Enumeration toate numele proprietăților conținute de un mesaj. Acestea pot fi apoi utilizate pentru extragerea valorilor proprietăților în cauză, utilizând metodele de acces de mai sus, pentru diferitele tipuri de date.

public void onMessage(Message message) {

Enumeration propertyNames = message.getPropertyNames();

while (propertyNames.hasMoreElements())

{

String name = (String) propertyNames.nextElement();

Object value = getObjectProperty(name);

System.out.println(”\nName = ” + name + ” , Value = ” + value ) ;

}

}

Exemple sugestive de utilizare

Bibliografie

Claudiu Vințe, Modele informatice în studiul pieței de capital, note de curs, Academia de Studii Economice, București

Ioan Dzițac, Grigor Moldovan, Sisteme distribuite: Modele informatice, Editura Universitățtii Agora, Oradea, 2006.

Kareem Yusuf, Enterprise Messaging Using JMS and IBM WebSphere, Prentice Hall, Upper Saddle River, 2004

www.oracle.com

CUPRINS

1. Sisteme distribuite 1

1.1. Concepte generale privind sistemele distribuite 1

1.2. Cerințe în proiectarea unui sistem informatic distribuit 3

1.2.1. Eterogenitatea 3

1.2.2. Scalabilitatea 4

1.2.3. Securitatea 5

1.2.4. Tratarea erorilor 8

1.2.5. Transparența 10

1.3. Middleware 11

1.4. Arhitecturi middleware 12

1.4.1. Arhitecturi MOM centralizate 14

1.4.2. Arhitecturi MOM descentralizate 15

1.4.3. Arhitecturi MOM hibride 16

Bibliografie 17