1

INTRODUCERE Lucrarea de faţă reprezintă o carte în domeniul Sistemelor Distribuite, conţinând o serie de concepte, algoritmi şi aplicaţii economice ale sistemelor distribuite elaborate şi testate în tehnologie Java. Cartea se adresează studenţilor de la specializarea Informatică Economică (sub formă de curs pentru disciplina aferentă) dar şi tuturor celor interesaţi de problematica tratată. Lucrarea este sistematizată în patru părţi, fiecare parte având un număr de trei sau patru capitole. Bibliografia este asociată fiecărei părţi. PARTEA I, Sisteme Distribuite este împărţită în trei capitole: Capitolul 1 prezintă caracteristicile generale ale sistemelor distribuite cum ar fi: definiţii, componente, modele de organizare, avantaje, dezavantaje, cum se face testarea acestor sisteme, cât şi cadrul formal. Capitolu 2 IPv6 prezintă o nouă versiune de Protocol Internet, creat ca succesor al versiunii curente de IP şi anume IPv4. În aceste capitol sunt detaliate următoarele: terminologia IPv6, arhitectura IPv6 pentru Windows .Net Server 2003, adresele IPv6, header-ul IPv6 şi structura unui pachet, autoconfigurarea adresei, rezoluţia numelui petru IPv6, rutarea, mobilitatea, tehnologiile LAN şi WAN. În capitolul 3, Prezentarea Platformei .NET sunt prezentate: tehnologiile necesare construirii aplicaţiilor ditribuite, limbaje de programare, caracteristicile limbajului de programare Visual C#.NET, proiecte şi soluţii dezvoltate cu ajutorul tehnologiei Microsoft Visual Studio.NET PARTEA II, Sistem de informare mutiagent folosind Managementul de Proiecte în tehnologia .NET face parte din vastul domeniu al Managementului Proiectelor Software. Această parte cuprinde: Capitolul 4, denumit Managementul proiectelor – soluţia efectivă pentru gestionarea proiectelor, prezintă noţiunile generale ce ţin de sinteza unui proiect şi componente care stau la baza elaborării efective a acestuia. Este prezentată metodologia tradiţională a MP. Nu au fost ocolite nici variantele îmbunătăţite ale Managementului Proiectelor, dezvoltate mai recent şi anume Managementul Adaptiv şi cel Extrem, caracteristicile şi fazele specifice acestor strategii de management, asemănările şi deosebirile dintre ele. Toate acestea contribuie la o înţelegere cât mai bună şi apoi la o aplicare eficientă a tehnologiilor de organizare şi administrare a proiectelor. În acest capitol sunt prezentate fazele parcurse conform MP Tradiţional (Clasic). Datorită faptului că domeniul din care face parte lucrare dată este Managementul Proiectelor Software, nu a lipseşte nici prezentarea fazelor ciclului de viaţă ale proiectelor software. Gestionarea activităţilor proiectului în acest capitol este abordată prin prisma MP tradiţional. Această gestionare este facilitată de utilizarea Structurii Ierarhice a Activităţilor (SIA) proiectului. În acelaşi timp este prezentat modul în care este construită şi utilizată SIA în scopuri diferite. La fel sunt prezentate modalităţile de estimare ale duratelor activităţilor aferente unui proiect, cerinţele de resurse necesare desfăşurării activităţilor proiectului şi drept rezultat - estimarea costului pentru activităţile proiectului. Totodată sunt prezentate tehnici de organizare a diagramelor de reţea sau grafuri pentru gestionarea efectivă şi clară a activităţilor în cadrul proiectului. Sunt evidenţiate dependenţele care pot apare între activităţile proiectului şi constrângerile care sunt impuse pentru organizarea mai eficientă a acestora. Este introdusă şi explicată noţiunea de drum

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

2

critic, dar şi un concept mai nou, mult mai eficient (din punctul de vedere al organizării activităţilor proiectului şi al alocării de resurse acestor activităţi) şi anume lanţul critic. Sunt subliniate unele idei ce ţin de organizarea efectivă a şedinţelor de planificare ale proiectului şi desfăşurarea activităţilor ce ţin de organizarea echipei funcţionale pentru proiectul respectiv. În capitolul 1 sunt discutate de asemenea diferite tehnici de monitorizare şi supraveghere a rezultatelor, care permit urmărirea desfăşurării proiectului. Acest control este realizat cu ajutorul rapoartelor generate periodic, folosind instrumente speciale. Aceste rapoarte pot fi reprezentate numeric, sau grafic (mult mai semnificative, destinate adeseori top-managerilor). În Capitolul 5, denumit Microsoft Visual Studio .NET – soluţia pentru dezvoltarea aplicaţiilor inteligente, este prezentat şi explicat efectul de Inteligenţă Artificială, specific multor tehnologii recent dezvoltate, care de fapt nu se păstrează pe parcursul perioadei îndelungate de timp. Fraza următoare explică foarte bine acest lucru : Orice fiind odată văzut ca nou şi diferit repede devenind vechi şi depăşit. Pe lângă aceasta mai sunt enumerate principalele direcţii de cercetare în domeniul Inteligenţei Artificiale. Totodată sunt descrise concepte noi precum procesare avansată (extinsă) şi integrală, care la rândul lor prezintă tendinţele în direcţia dezvoltării de aplicaţii software mult mai utile, folosind diferite tehnologii de ultima oră, sau a unor idei noi în conceperea funcţionării aplicaţiilor software. La fel sunt prezentate pe scurt tehnologii de Inteligenţă Artificială aplicate în practică, pentru a creşte utilitatea aplicaţiilor tradiţionale sau pentru dezvoltarea unor aplicaţii noi şi mai bune. Un alt subiect al acestui capitol îl reprezintă platforma Visual Studio.NET 2003, dezvoltată de firma Microsoft, ca o tehnologie cu un potenţial mare în dezvoltarea produselor software de orice complexitate, fie ele pentru automatizarea unor calcule sau pentru dezvoltarea aplicaţiilor inteligente. Aici sunt prezentate atât principalele caracteristici şi performanţe ale acestei platforme, cât şi valoarea de afacere a acesteia. În finele capitolului 2 sunt marcate tendinţele în sfera procesării avansate, tehnologiile de generaţie următoare oferite de firma Microsoft, pentru dezvoltarea unor produse software mult mai eficiente. Tot aici sunt prezentaţi Agenţii Software, o categorie de produse software care asigură un sprijin enorm activităţii utilizatorilor finali, în special pentru eliberarea acestora de activităţi de rutină. Capitolul 6 abordează un Sistem de informare multi-agent, ca o soluţie multi-agent dezvoltată pentru eliberarea utilizatorului final de actualizarea periodică a informaţiilor necesare desfăşurării activităţilor acestuia. Informaţiile în cazul dat sunt stocate în fişiere-documente. Soluţia dată este compusă din doi agenţi software, care au fost dezvoltaţi ca servicii Windows (rularea independentă de utilizator, fiind avantajul principal al serviciilor Windows). Servicii-agenţi, care rulează unul pe Server şi celălalt pe sistemul clientului, cooperează prin intermediul unui serviciu Web, cu rol de interfaţă. Pentru dezvoltarea acestei soluţii a fost utilizată platforma Microsoft Visual Studio.NET 2003. Codul sursă pentru soluţia dată este scris în limbajul C#. În acest capitol se prezintă o eventuală parcurgere a etapelor Managementului Proiectelor pentru organizarea şi administrarea proiectului software. Sunt identificate obiectivele sau scopul proiectului pentru o mai bună înţelegere a ceea ce se cere pentru dezvoltare. Sunt prezentate în forma schematică infrastructura sistemului multi-agent. Structura ierarhică funcţionalităţilor pe care trebuie să realizeze agentul client. Este prezentată posibilitatea divizării proiectului software de faţă în trei sub-proiecte. Şi dezvoltării separate a acestor trei componente ale sistemului. PARTEA III, Organizaţii Virtuale prezintă o nouă modalitate de structurare a unei organizaţii virtuale plecând de la două tipuri de structuri: coaliţia şi structura ierarhică. Această nouă structură

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

3

intitulată "coaliţie ierarhică" prezintă o posibilă structură a unei organizaţii virtuale cu toate avantajele şi limitele sale. Coaliţia ierarhică este importantă prin faptul că oferă posibilitatea unei noi modalităţi de planificare utilizând organizaţiile ierarhice. Partea III este structurată pe 3 capitole, astfel: Capitolul 7 realizează o expunere a caracteristicilor de bază a organizaţiilor (structuri ierarhice şi coaliţii) utilizate în crearea unui model de organizare în care agenţii vor fi utilizaţi pentru implementarea unei structuri multiagent. După prezentarea celor două tipuri de organizaţii se prezintă şi un mod de integrare a lor într-o organizaţie ce moşteneşte avantajele fiecărei organizaţii părinte. În continuare este descris modul în care se poate realiza planificare în coaliţiile ierarhice, avantajele pe care coaliţiile ierarhice le aduc planificării, precum şi limitările şi neajunsurile pe care coaliţiile ierarhice le implică, conceptul de planificare bazat pe constrângeri precum şi câteva modele de planificare bazate pe constrângeri. În final, se prezintă interacţiunea om-agent şi modul în care aceştia interacţionează. În capitolul 8 descriem o ontologie bazată pe constrângeri care a fost extinsă şi adaptată pentru a susţine definiţia modelelor de planificare. Încă de la începutul capitolului justificăm folosirea acestei ontologiei ca bază pentru planul reprezentării, caracterizăm componentele ontologiei şi modul cum sunt folosite pentru a descrie planuri. După aceea sintetizăm cerinţele discutate în capitolul anterior pe care le putem analiza din aceeaşi perspectivă. Pentru acest scop arătăm un punct de vedere centrat pe agent al procesului de planificare, clasificând diferite seturi de constrângeri şi funcţii care au legătură cu acest proces. Fiecare set de constrângeri sau funcţii sunt asociate cu o cerinţă care ghidează descrierea lor. O versiune extinsă a ontologiei împreună cu un grup de funcţii de manipulare a constrângerilor sunt rezultate din această investigaţie, creând o reprezentare unificată pentru activităţi de planificare colaborative om-agent. În capitolul 9 prezentăm mai mulţi algoritmi pentru a găsi o soluţie optimă a unei probleme de planificare. După aceea demostrăm corectitudinea fiecărui algoritm, la final implementăm doi algoritmi în limbajul Java pentru a arăta modul de funcţionare a unor astfel de algoritmi. PARTEA IV, Aplicaţie de tip CRM pentru o agenţie imobiliară prezintă rolul managementului relaţiilor cu clienţii (Customer Relationship Management – CRM) din perspectiva tehnologiilor informatice (capitolul 10). În capitolul 11 al acestei părţi este prezentat sistemul informaţional al relaţiilor cu clienţii (CRM – Customer Relationship Management) ca fiind o parte integrată a întreprinderilor adaptive. În capitolul 12 este descris modul în care organizaţiile din domeniul afacerilor electronice au implementat soluţiile CRM având, astfel, posibilitatea de a urmări fiecare interacţiune cu clienţii – indiferent dacă aceasta s-a desfăşurat prin e-mail, telefon sau scrisori tradiţionale – dintr-o locaţie centralizată. În capitolul 13 este prezentat limbajul JavaServer Pages (JSP) pentru realizarea unei componente din structura unei soluţii CRM. Este prezentat modul în care limbajul JSP se înrudeşte cu Java ” si sunt descrise elementele necesare scrierii de programe utilizând un server de aplicaţii ce suportă această tehnologie. În capitolul 14 este prezentată o soluţie de implementare a unui sistem de tip CRM în domeniul imobiliar prin prezentarea arhitecturii unui site Web intitulat FindMyHome. Site-ul Web pune la dispoziţia utilizatorului diverse metode de prezentare si localizare (căutare) a informaţiilor pe care le deţine, iar dacă acesta este interesat de un anumit imobil, va trebui sa completeze un

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

4

formular de contact. De asemenea, el are posibilitatea să înregistreze spre vânzare imobile, acestea urmând să fie actualizate în baza de date de către administrator. Aplicaţia are şi un modul de administrare, a cărei accesare este restricţionată vizitatorilor neautorizaţi şi care conţine instrumentele necesare întreţinerii site-ului Web. Reţelele de calculatoare au o extindere rapidă într-o multitudine de domenii cum ar fi sistemul bancar, administraţia publică, alocarea temporară de resurse în hoteluri, rezervarea biletelor de avion, rezervarea biletelor de tren etc. Aplicaţiile moderne iau în considerare accesul unui număr cât mai mare de utilizatori, mai ales de când se prevede extinderea folosirii cardurilor şi creşte numărul persoanelor care utilizează Internetul. Definiţii posibile pentru un sistem de calcul distribuit sunt:

1. Un sistem de calcul distribuit este cel în care un număr de procesoare şi zone de stocare de date autonome suportă procesări şi/sau interacţiuni cu bazele de date în scopul cooperării comune pentru a obţine un rezultat comun. Procesele coordonează activităţile, schimbă informaţii prin intermediul unei reţele de comunicaţii”. Sloam & Kramer (1987).

2. Un sistem este distribuit doar dacă existenţa nodurilor autonome este transparentă pentru utilizatorii sistemului adică se comportă virtual ca un singur calculator. Definiţia este importantă deoarece pune în evidenţă rolul sistemului de operare distribuit, care trebuie să permită programarea şi execuţia unei aplicaţii distribuite la fel de uşor ca a uneia secvenţiale (Tanenbaum - 1992).

Din punct de vedere al comunicaţiei, un sistem distribuit trebuie să poată realiza un schimb sigur de informaţii între noduri. Această proprietate este asigurată de ajungerea la destinaţie a mesajelor transmise, lipsa erorilor ca şi a copiilor multiple. În sistemele cu memorie distribuită procesoarele au propria lor zona de stocare şi manipulare a datelor, comunicarea datelor realizându-se prin intermediul transferului de mesaje. S-a observat că memoria comună impune, la un moment dat, limitări din punct de vedere al scalabilităţii sistemelor, acestea fiind de obicei folosite pentru aplicaţii care au o granularitate mică. În cazul în care problemele abordate au o granularitate medie sau mare şi, în plus, implica un transfer de date (mesaje) scăzut, cele mai bune rezultate se obţin în cazul folosirii sistemelor cu memorie distribuită. In cazul calculul distribuit se poate spune că există o paletă de sisteme care evoluează de la sisteme centralizate către un set de calculatoare diversificate, autonome, dispersate fizic şi care sunt conectate printr-o reţea de comunicaţii.

Atributele unui sistem distribuit sunt: număr arbitrar de sisteme şi procese (resurse logice), arhitectură fizică modularizată (resursele fizice), sistem de control deschis, costuri reduse, modularitate şi simplitate a softului, flexibilitate şi extensibilitate, fiabilitate şi integritate, performanţa.

Principalele cerinţe pentru aplicaţiile distribuite sunt: interfeţe puternice, fiabilitate foarte mare, securitate ridicată, viteza ridicată de prelucrare şi transmitere a datelor. În figura 1.1, gazda master M trimite periodic cereri computaţionale către gazdele S. Cererile trec prin nodul intermediar N, care trimite mesajele către gazdele S. După ce gazdele S, termină calculele (într-un timp uniform), ele trimit mesajele cu rezultate către M prin N. Venirea mesajelor cu rezultate sunt corelate cu mesajele cereri cu ajutorul lui L, unde: M este gazda master, N este un nod intermediary, S reprezintă gazde ce servesc lui M ce trimit mesajele lui M prin N, L este legătură

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

5

  

Figura 1.1 Exemplu de aplicaţie distribuită 

Cuvântul cheie este integrarea, deja realizată fizic, a sistemelor de mare performanţă (masiv paralele, supercalculatoare, calculatoare vectoriale) în cadrul reţelelor de calculatoare. În felul acesta se creează reţele eterogene de dimensiuni foarte mari, în care rolul principal îl joacă staţiile de lucru. Într-o astfel de reţea, sistemele paralele reprezintă nuclee de calcul foarte puternice ce pot fi folosite pentru accelerarea execuţiei aplicaţiilor complexe (fizică atomică, previziuni meteo, gestiunea bazelor de imagini etc.). Majoritatea sistemelor de calcul paralel sunt accesibile în reţea, dar ele pot fi folosite acum numai individual, prin intermediul unui calculator gazdă. Un utilizator se conectează la gazda sistemului paralel, dacă are un cont, execută aplicaţia, după care se deconectează. Prin soluţia integratoare, utilizatorul îşi creează un domeniu de execuţie, format din mai multe staţii din reţea inclusiv sisteme de mare performanţă. Domeniul de execuţie, care reprezintă o maşină de calcul virtuală foarte puternică, are o evoluţie dinamică: se pot introduce în domeniu sau se pot elimina în orice moment staţii de lucru, servere de baze de date, procesoare specializate etc. Domeniul de execuţie este conceptul software, iar corespondentul său fizic este ciorchinele (clusterul) de calculatoare. Viteza de calcul a fiecărui procesor, întârzierile de comunicaţie (latencies) între staţiile aceluiaşi cluster sau între clustere sunt factori de performanţă importanţi. Când se proiectează o aplicaţie distribuită, trebuie să se tină cont de aceşti parametri la definirea clusterului. Domeniul de execuţie al unei aplicaţii, format din unul sau mai mulţi ciorchini este o parte a sistemului distribuit eterogen. Mai multe staţii de lucru formează un cluster care poate fi alocat unei singure aplicaţii sau mai multor aplicaţii. Aplicaţia, formată din mai multe taskuri concurente, este alocată unui domeniu de execuţie a cărui configuraţie poate varia de la staţia iniţială până la zeci sau sute de staţii de lucru. Domeniul include numai nodurile de calcul de interes. Pentru definirea domeniului de execuţie se folosesc mai multe criterii: 1. caracteristicile  aplicaţiei  în  termenii  timpului  de  execuţie,  raport  calcule/  comunicaţii  si 

necesarul de resurse;  2. disponibilitatea resurselor şi estimarea încărcării;  3. mapare posibilă a grafului de execuţie al aplicaţiei pe graful de comunicaţii al domeniului 

de execuţie;  4. condiţii de performanţă speciale, cum ar fi execuţie în timp real, toleranţă la defecte sau o 

precizie foarte mare.  

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

6

Domeniile de execuţie se pot suprapune, dar trebuie să se ţină cont că simultan se execută mai multe aplicaţii, între care interferenţele trebuie să fie minime, iar timpul de execuţie al fiecăreia să fie semnificativ mai mic decât în varianta mono-procesor. O aplicaţie distribuită este o entitate de control inteligentă, care poate să fie de orice tip ce rulează într-un mediu distribuit. Poate fi o singură componentă cum ar fi o pagină Web, o bază de date, un obiect Corba, un URL, un proces UNIX, o clasa Java, etc. Teoretic, însă o aplicaţie distribuită este combinaţia dintre obiecte si procese cu relaţii de dependentă, care comunică între ele cu scopul de a oferi anumite servicii utilizatorilor finali. Un exemplu de aplicaţie distribuită ce rulează în cadrul unei firme este cea prezentată în figura 1.2:

 

Figura 1.2 Exemplu de aplicaţie distribuită 

Cele 4 procese P1, P2, P3 si P4 formează o aplicaţie distribuită ce rulează pe 3 reţele locale (LAN) ale unei întreprinderi. Cele 4 procese reprezintă: P1- server Web, operează şi ca un client CORBA; P2 – serviciu CORBA middle-tier; P3 – server CORBA middle-tier; P4 – baza de date back-end.

Se presupune că P1 este partea de început (front-end) a aplicaţiei, server web. Acest server web operează şi ca un client CORBA, care comunică cu serverul P3. Cursul operaţiilor ce au loc este următorul: când cererea unui client vine la P1, P1 transmite lui P2, şi obţine numele serverului P3 şi o referinţă la obiect pentru un anumit context. P1 pasează apoi cererea la P3 folosind referinţa nume. P3 va interacţiona cu P4 pentru interogarea bazei de date sau pentru actualizare. După aceea, P3 va întoarce rezultatul la P1. Acesta îl va transmite mai departe clientului. Cu acest exemplu, este evident că serviciul oferit de o aplicaţie distribuită necesită ca fiecare componentă din cadrul aplicaţiei să coopereze şi să comunice cu celelalte. Relaţiile de dependenţă pentru această aplicaţie sunt: P1 depinde de P2 si P3, P3 de P2 si P4, etc. Gestionarea aplicaţiilor distribuite necesită timp real, monitorizarea online a tuturor obiectelor, la fel ca şi alte resurse ale reţelei sau sistemului necesare funcţionării aplicaţiei. De asemenea, gestionarea aplicaţiilor distribuite presupune şi monitorizarea serviciilor pentru utilizatorul final, ca şi maparea la nivel de aplicaţie, de sistem, de reţea. Tehnologia necesară managementului aplicaţiilor mari nu a putut ţine pasul cu dezvoltarea la scară largă a aplicaţiilor distribuite, eterogene. Aceasta a dus la apariţia anumitor probleme în departamentele de IT ale marilor firme. Într-un mediu distribuit, mai multe calculatoare eterogene sunt conectate la o infrastructură de comunicaţii. Aplicaţiile distribuite ce rulează într-un astfel de mediu transmit mesaje prin reţeaua de comunicaţie, şi deci se folosesc de avantajul infrastructurii de comunicaţii.

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

7

Componentele unui sistem distribuit  

Aplicaţiile distribuite constau  în mai multe componente ce rulează pe maşini diferite, acestea aplicaţii  integrând acţiunile componentelor lor. Proiectarea aplicaţiilor distribuite se axează nu numai  pe  detaliile  părţilor  individuale,  ci  şi  pe  realizarea  unei  integrări  a  componentelor distribuite, astfel  încât acestea să coopereze  foarte bine  între ele. Un sistem distribuit are ca principale componente: hardware distribuit; şi/sau control distribuit (soft de sistem); şi/sau date distribuite (soft de aplicaţii). Hardware distribuit 

1. Un sistem distribuit  trebuie să conţină două sau mai multe sisteme de calcul,  fiecare cu procesorul şi memoria lui locală. Acest aspect al distribuţiei fizice este foarte important în definirea unui sistem distribuit.  

2. Pentru ca aceste calculatoare distribuite să poată comunica, este nevoie de o  formă de reţea de comunicare. 

3. Distribuirea  calculatoarelor  poate  reflecta  distribuirea  fizică  a  aplicaţiei  sau descompunerea funcţională a sistemului, unde sisteme de calcul diferite realizează funcţii diferite (de exemplu procesoarele dedicate). 

Control distribuit 

1. Sistemele  conţin  resurse  fizice  sub  forma  procesoarelor,  imprimante,  etc.  precum  şi resurse logice sub forma proceselor, fişierelor etc. 

2. Strategia  folosită pentru  controlul  resurselor poate  fi  centralizată  ierarhic  sau  să permită o autonomie  completă  a  procesoarelor  individuale  peste  resursele  locale.  Această  ultimă abordare  necesită  o  cuplare  slabă  între  componentele  sistemului  (de  exemplu  reţelele  de calculatoare). 

3. În multe cazuri se încearcă obţinerea unei transparenţe, în sensul că sistemul apare ca un sistem unic, uniform, ascunzând distribuţia fizică şi neomogenitatea componentelor sale. 

Datele distribuite 

1. Una din resursele majore ce necesită control şi din partea sistemului şi din partea aplicaţiei sunt datele. 

2. Datele  în  curs  de  procesare  pot  fi  distribuite  prin:  replicare  (copii  multiple  la  locaţii diferite); partiţionare (părţi ale lor sunt stocate în diferite locaţii).  

3. Datele  sunt adesea distribuite atât pentru a  creşte  toleranţa  la defecte,  cât  şi pentru a permite creşterea perfor 

4. manţei prin stocarea datelor în apropierea zonelor unde sunt produse sau folosite.  

Modele de organizare a aplicaţiilor distribuite 

Există următoarele modele de organizare a aplicaţiilor distribuite:  

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

8

1. aplicaţii tip „client ‐ server”, care presupun executarea unui volum important de prelucrări locale sau autonome şi partajarea resurselor de calcul sau date 

2. aplicaţii pe „cluster”, presupun utilizarea mai multor calculatoare conectate  în reţea, sub forma unei resurse unice 

3. aplicaţii distribuite colaborative, care oferă posibilitatea participării mai multor persoane la atingerea unui obiectiv sau a mai multora, prin intermediul tehnologiei calculatoarelor – calcul plus comunicaţii 

4. metacalculul,  care  se  referă  la utilizarea unui număr  foarte mare de  resurse de  calcul, foarte puternice şi distribuite pe o arie mare, pentru rezolvarea unor probleme de o mare complexitate.  

 

Modele arhitecturale specifice. Modelul cu acces neuniform la memorie NUMA (Non‐Uniform Memory Acces). NUMA cu memorii  locale distribuite este o structură de sistem strâns cuplat folosită  de  obicei  în  cazul  supercalculatoarelor.  NUMA  ierarhic  cu  clustere  (ciorchine  sau grupare de staţii de  lucru  legate printr‐o reţea care cooperează  la realizarea unui  ţel comun). Clusterul poate fi de tip NUMA sau UMA. Cazul conectării tip Butterfly local este cel mai rapid, iar cel la distanţă cel mai lent.  

 

Figura 1.3 NUMA cu memorii locale distribuite 

 

Modelele calcului distribuit 

1. modelul  “fermă  de  procesoare”:  se  caracterizează  prin  existenţa  unui  ansamblu  de elemente de prelucrare generice şi de servere cu funcţii specifice, ale căror facilităţi  sunt accesate de la staţii de lucru, care în general au resurse de calcul şi de memorare reduse. 

2. modelul “client‐server”: presupune executarea unui volum important de prelucrări  locale sau autonome şi partajarea resurselor de calcul sau date. 

3. modelul “data flow”: se bazează pe organizarea prelucrării conform unui graf în care nodurile sunt elemente de prelucrare, iar arcele sunt conexiuni logice prin care circulă mesajele.  

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

9

4. modelul  ierarhic:  resursele de prelucrare  sunt organizate  (fizic  sau  logic)  într‐o  reţea de prelucrare arborescentă. În mod curent, nivelurilor mai înalte ale ierarhiei le sunt asociate resurse de prelucrare mai puternice. 

5. modelul “cache”: se bazează pe prelucrări realizate etapă cu etapă, efectuate de diverse elemente de calcul, şi pe combinarea rezultatelor parţiale pe un alt element de calcul, de regulă mai puternic. O strategie de partajare a operaţiunilor este adecvată în acest caz. 

 

Modelul Client Server 

1. În  sistemele de operare pentru  reţele de  calculatoare  se utilizează de  cele mai multe ori modelul client‐server. 

2. În acest  caz  sistemul de operare  conţine,  în afară de nucleu, un grup de procese numite servere, care oferă servicii proceselor utilizator, acestea devenind astfel clienţi. 

3. Există  procese  specializate  care  realizează  diferite  servicii,  cum  ar  fi:  lucrul  cu  fişiere, compilare, tipărire etc. Un proces care are nevoie de o astfel de acţiune, o cere de la unul din serverele care sunt dedicate pentru respectivul tip de problemă. 

4. În timpul execuţiei diferite procese pot fi atât client, cât şi server; de exemplu serverul de fişiere poate deveni client pentru serverul care oferă timpul curent. 

5. Dacă  atât  serverele,  cât  şi  clienţii  se  execută  în  spaţiul  de memorie  utilizator,  structura nucleului  se  simplifică  mult,  rolul  acestuia  din  punctul  de  vedere  al  comunicaţiei restrângându‐se la trimiterea şi recepţionarea de mesaje. 

6. Dacă  realizarea  comunicaţiei  se  bazează  pe  operaţii  de  tipul  transmisie  sau  recepţie, înseamnă că elementele principale utilizate  în programare sunt de tip operaţie de  intrare‐ieşire. 

7. Activităţile din timpul execuţiei unei aplicaţii distribuite sunt asociate de obicei, abstractizării de proces si ele nu vor putea să existe decât ca părţi ale aplicaţiei.  

8. Un sistem client‐server este realizat pe trei nivele, cel al prezentării, cel al aplicaţiei şi cel al accesului  la  date.  Separarea  fizică  a  celor  trei  nivele  se  numeşte  partiţionarea  aplicaţiei. Întotdeauna nivelul prezentării va fi implementat de către client. Împărţirea celorlalte două nivele între client şi server conduce la 5 stiluri diferite: prezentare distribuită; prezentare la distanţă;  aplicaţie  distribuită,  când  calculele  sunt  împărţite  între  client  şi  server;  date  la distanţă; date distribuite. 

 

  

Figura 1.4 Arhitectura client/server 

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

10

Aplicaţiile distribuite acţionează într‐un mediu foarte diferit de cel al aplicaţiilor client/server. In paradigma  client/server,  componentele aplicaţiei  software  sunt  folosite de  către  calculatorul client si calculatorul server.  In mediul aplicaţiilor distribuite, aplicaţia poate avea componente care să ruleze pe mai multe calculatoare din reţea. Diferenţa dintre client şi server dispare. În mod evident, o componentă a unei aplicaţii distribuite acţionează atât drept client, cât  şi ca server. 

Avantajele sistemelor distribuite 

1. Costuri reduse ‐ s‐a demonstrat economic că este mult mai ieftin să se folosească mai multe sisteme  de  calcul  la  rezolvarea  unei  probleme  complexe,  decât  unul  foarte  performant. Acesta  are  un  cost  foarte mare  şi  este  dedicat,  în  general,  numai  un  flux  continuu  de probleme de calcul de foarte mari dimensiuni. 

2. Modularitatea şi simplitatea soft‐ului – sistemele distribuite pot fi construite într‐o manieră foarte modularizată,  unde  fiecare  componentă  permite  interfaţarea  cu  restul  sistemului (celelalte componente)  sau servicii foarte bine definite. Modularitatea permite o proiectare simplă a sistemului, instalare şi întreţinere mai simple. 

3. Flexibilitatea  şi  extensibilitatea  –  modularitatea  sistemului  permite  schimbarea  sau modificarea elementelor de calcul fără a deranja major operaţiile în curs de desfăşurare. Prin folosirea  protocoalelor  standard  de  comunicaţii  este  posibil  să  se  includă  într‐o  reţea echipamente provenind de la diferiţi producători, rezultând o reţea omogenă. 

4. Fiabilitate  şi  integritate  sistemele  distribuite  au  proprietatea  de  a  putea  continua operaţiunile indiferent de starea unei părţi a sistemului folosirea mai multor noduri de calcul permite  ca,  în  cazul  defectării  sau  blocării  unei  resurse,  sistemul  să  continue  activitatea resurselor critice, în acest caz, pot avea control dublu sau triplu dacă softul este proiectat în stil tolerant la erori, sistemul poate continua absolut toate calculele în curs, prin redirectarea task‐urilor de calcul care nu mai răspund spre alte procesoare 

5. Performanţa este  în general definită  în termenii timpului de răspuns  la un anumit grad de încărcare  timpul de  răspuns poate  fi scăzut,  în mod particular dacă majoritatea procesării este făcuta local paralelismul datorat nodurilor multiple reduce defecţiunile şi încetinirile ce pot apărea  la nivelul proceselor de  calcul  şi generează o  creştere a performanţei globale software‐ul local poate fi folosit şi la preprocesarea sau compactarea datelor, reducându‐se astfel încărcarea pe reţeaua de comunicaţie şi crescând performanţele sistemului. 

• Lipsa cunoştinţelor despre starea globală În fluxul de control al unui algoritm centralizat, deciziile se pot lua în funcţie de starea întregului sistem.  Chiar  dacă  starea  sistemului  se  poate  deduce  din  valorile  pe  care  le  au mai multe variabile, aceasta nu poate fi determinată în mod corect, deoarece în procesul de inspectare a valorilor  lor, nici una dintre variabile nu poate  fi modificată de un alt process. Nodurile unui sistem distribuit pot avea acces doar  la  starea  lor proprie  şi nu  la  starea globală a  întregului sistem distribuit. Rezultă că nu este posibil să se ia o decizie în funcţie de această stare. Starea unui  sistem de comunicaţii  (adică mesajele ce  sunt  în  tranzit  la un moment dat) nu poate  fi 

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

11

observată  în mod  direct,  ci  doar  prin  compararea  informaţiilor  despre mesajele  trimise  şi mesajele primite de toate nodurile. 

• Lipsa unui timp global Evenimentele  care  constituie  executarea unui  algoritm  centralizat  formează o mulţime  total ordonată  conform  apariţiei  lor  temporale.  Relaţia  de  ordonare  temporala  indusă  asupra evenimentelor  care  constituie  execuţia  unui  anumit  algoritm  distribuit  nu  este  o  relaţie  de ordine  totală. Există perechi de evenimente pentru  care  se poate decide  care dintre ele  s‐a produs primul şi care al doilea, dar acest lucru nu este valabil întotdeauna. 

• Nedeterminismul  Comportamentul  unui  program  centralizat  poate  fi  descris  în  funcţie  de  datele  de  intrare. Pentru  un  anumit  set  de  intrare,  comportamentul  unei  aplicaţii  distribuite  este  de  obicei nedeterminist. Acest  nedeterminism  apare  ca  urmare  a  unor  diferenţe  posibile  în  viteza  de execuţie a componentelor sistemului. De exemplu, un proces server primeşte cereri de  la un număr necunoscut de procese clienţi. Serverul nu poate să înceapă să prelucreze toate cererile după  ce acestea au  sosit, deoarece el nu poate  şti  câte mesaje va primi. Rezultă  că    fiecare cerere trebuie să fie servită imediat, iar ordinea prelucrărilor cererilor poate coincide cu ordinea în care acestea au sosit. Ordinea în care clienţii trimit cererile poate fi cunoscută, dar pentru că întârzierile specifice transmisiilor nu pot fi cunoscute, cererile pot sosi în altă ordine, deci să fie tratate  în  altă  ordine  decât  cea  în  care  au  fost  trimise.  Aceste  diferenţe  între  sistemele distribuite şi cele centralizate induc diferenţe conceptuale între algoritmii distribuiţi şi algoritmii centralizaţi. 

Testarea  aplicaţiilor  bazate  pe  arhitectura Web,  în  plus  faţă  de  testarea  aplicaţiilor  clasice, necesită o serie de teste specifice cum ar fi: testarea de încărcare, testarea de compatibilitate, testarea  funcţională,  testarea  conţinutului,  testarea  serverului  Web,  testarea  securităţii, testarea serverului de aplicaţii  şi  testarea bazelor de date. Testarea de  încărcare se utilizează pentru  a  verifica  dacă  site‐ul  Web  poate  gestiona  un  anumit  număr  de  utilizatori  care  îl accesează concurent  în limite acceptabile ca timp de răspuns. Prin testarea de compatibilitate urmăreşte aspectul  şi  comportamentul  site‐ului Web  în  raport  cu o  varietate de  sisteme de operare  şi  de  navigatoare  Internet.  Această  testare  scoate  în  evidenţă  problemele  cu controalele ActiveX, applet‐urile Java, funcţiile JavaScript sau VBScript şi formulare din pagini. La ora actuală există peste 100 de combinaţii posibile între diverse sisteme de operare Windows şi diverse versiuni ale navigatoarelor Netscape şi Internet Explorer. 

Testarea  funcţională  se  realizează  pentru  a  constata  dacă  site‐ul  se  comportă  conform  cu specificaţiile  sale. Detaliile  acestui  tip de  testare depind de natura  site‐ului Web.  În  general constă  în verificarea  legăturile paginilor, testarea  formularelor, verificarea tranzacţiilor pentru comerţul  electronic  şi  pentru  baze  de  date,  testarea  applet‐urilor  Java.  Pentru  testarea conţinutului se urmăreşte corectitudinea şi aşezarea în pagină a textelor, imaginilor şi fişierelor de animaţie şi video din cadrul site‐ului. 

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

12

Testarea serverul Web are în vedere testarea interacţiunilor dintre serverul Web şi serverul de aplicaţii, verificarea  integrităţii bazei de date  în cadrul serverului de baze de date, verificarea faptului  că  scripturile  ASP,  PHP  sau  JSP  se  execută  corect  pe  server.  Testarea  securităţii tranzacţiilor efectuate este foarte  importantă pentru aplicaţiile de comerţ electronic având  în vedere faptul că sunt vehiculate date confidenţiale, la care dacă au acces persoane neautorizate sau răuvoitoare se pot produce pierderi materiale importante. Testarea serverului de aplicaţii se realizează  ţinându‐se  seama  de  caracteristicile  funcţionale  si  structurale  ale  acestuia.  Se testează  componentele  serverului,  folosind metode  clasice de  testare, precum  şi metode de testare ce  iau  în considerare tranzacţiile şi comunicaţiile asincrone dintre aceste componente. Testarea bazelor de date presupune verificarea executării corecte a  interogărilor şi operaţiilor de adăugare  şi actualizare a datelor, precum,  şi verificarea conexiunilor dintre  site‐ul Web  şi baza  de  date.  Prin  testarea  performantelor  se  măsoară  comportamentul  site‐ului  Web  în diverse condiţii de trafic. În prezent există o mulţime de instrumente pentru testarea automata a aplicaţiilor distribuite bazate pe web. Astfel de aplicaţii precum eValid, Rational SiteCheck, SilkPerformer,  LoadRunner  au  următoarele  caracteristici:  oferă  suport  pentru  testarea funcţională, analizează integritatea legăturile dintre pagini, analizează încărcarea şi capacitatea serverului Web,  oferă  o  serie  de  indicaţii  pentru  reglaje  fine  ale  site‐ului.  Construirea  unui sistem  distribuit  este  echivalentă  cu  construirea  unei  reţele,  care  sunt  performanţele  sau caracteristicile reţelei este o problemă care ţine de performanţele echipamentelor. 

Cadrul formal pentru sistemele distribuite Procesarea distribuită oferă multe avantaje: disponibilitate şi siguranţă prin copii, performanţă prin paralelism, distribuire şi interoperaţionalitate prin interconectare, flexibilitate şi expansiune incrementală prin modularizare. Într‐o explicare formală şi riguroasă a procesului, este necesară prezenţa unui formalism matematic ce permite sublinierea tuturor caracteristicilor sistemului. În acelaşi timp, în cazul unor probleme de dimensiuni mari, sunt necesare şi anumite facilităţi de structurare.  Abordarea  aceasta  adoptă  paradigma  orientată  obiect  ca  un  principiu  de structurare. 

CO‐OPN: Concurrent Object‐Oriented Petri Nets 

– Structuri de date  = Tipuri de date abstracte algebrice – Concurenţă, control  = Reţele Petri algebrice – Modularitate = Orientarea obiectului cu încapsulare – Dinamicitate = Referinţe, crearea obiectelor – Comunicare = Sincronizare între obiecte – Distribuţie = Context = Unităţi + Migrarea informaţiei 

 

CO‐OPN = Structuri de date + Reţele Petri + Orientare obiecte 

 

Sisteme Distribuite cu Aplicaţii Economice folosind Tehnologii Java

13

Pe de o parte, este  folosit un formalism general care poate exprima, atât aspectele abstracte, cât  şi  cele  concrete  ale  sistemelor,  cu  precădere  axându‐se  pe  descrierea  concurenţei  şi  a tipurilor  abstracte  de  date.  Această  abordare,  denumită  Reţele  Petri  concurente  orientate obiect (CO‐OPN/2), îmbunătăţeşte performanţele predecesorului său orientat obiect COOPN.  

Pe de altă parte, pentru a se putea lucra mai bine cu arhitecturi distribuite a fost dezvoltat un nivel (strat) de coordonare, denumit Limbaj de interfaţă cu obiecte şi context (COIL). O abordare ce oferă atât formalismul matematic, cât şi facilităţile de structurare are la bază reţelele Petri. În cadrul acestei abordări este folosit un exemplu tipic de sistem distribuit, numit nod de tranziţie, iar progresiv este construit un sistem distribuit de comunicare alcătuit din mai multe noduri de tranziţie. Dezvoltarea propriu‐zisă presupune mai multe etape. Prima  se  referă  la  tipurile de date abstracte şi construieşte o versiune de bază a unui sistem de comunicaţie,  în care toate nodurile de tranziţie pot transmite mesaje celorlalte. A doua etapă îmbunătăţeşte sistemul de bază  în  ceea ce priveşte porturile de  intrare  şi  ieşire a datelor.  În  cea de‐a  treia etapă,  sunt adăugate  rute;  construirea  noului  sistem  se  bazează  pe moştenire.  Acum  este  introdus  un sistem distribuit şi eterogen mai realist. Acest sistem  ia  în considerare  informaţii despre timp, algoritmi de detectare a erorilor, porţi ale sistemelor distribuite eterogene. Într‐o ultimă etapă, este introdus nivelul de coordonare COIL pentru a sprijini construirea arhitecturilor distribuite.  

CO‐OPN/2  este un  formalism  folosit pentru  exprimarea  şi modelarea  sistemelor  concurente mari. Cele 2 formalisme folosite de abordarea CO‐OPN/2 sunt: specificaţiile algebrice şi reţelele Petri care sunt combinate. Formalismul mai vechi este folosit pentru descrierea structurilor de date şi a aspectelor funcţionale ale sistemului, în timp ce formalismul de mai târziu este folosit pentru modelarea  caracteristicilor  operaţionale  şi  concurenţiale.  Cu  toate  acestea,  ambele formalisme nu pot exprima generalul. Din aceasta cauză, pentru a compensa lipsa capacităţilor de  structurare  a  reţelelor  Petri,  paradigma  obiect  a  fost  preluată  de  abordarea  CO‐OPN/2. Astfel,  un  sistem  este  considerat  ca  fiind  o  colecţie  de  entităţi  independente  care interacţionează  şi  colaborează  unele  cu  altele  pentru  îndeplinirea  diferitelor  task‐uri  ale sistemului.  Pentru  depăşirea  anumitor  limite  ale  predecesorului  său,  CO‐OPN/2  introduce câteva noţiuni specifice abordării obiectuale, cum ar fi noţiunea de clasă şi moştenirea.