1.

Caracteristici fundamentale ale sistemelor ditribuite Definitii: a) Un sistem distribuit - acel sistem n care componentele, localizate n cadrul reelelor de calculatoare, comunic i i coordoneaz aciunile doar prin transmiterea de mesaje. b) Un sistem distribuit drept o colecie de calculatoare independente, prezentat utilizatorilor drept un singur calculator n prezent, cel mai cunoscut sistem distribuit este Internetul, urmnd pe aceeai linie tehnologic Intranet-urile, respectiv sistemele mobile. Eterogenitate

Internetul permite utilizatorilor s acceseze servicii i s ruleze aplicaii pe o colecie eterogen de calculatoare i reele. Conceptul eterogen poate fi aplicat: reelelor, componentelor hardware ale unui sistem, sistemelor de operare, limbajelor de programare, implementrilor fcute de diferii dezvoltatori Eterogenitatea poate aprea n diferite contexte: - Cu toate c Internetul conine multe tipuri de reele, diferenele sunt mascate de faptul c toate calculatoarele conectate la acestea folosesc protocoale comune de comunicare - Tipurile de date pot fi reprezentate n diferite moduri, funcie de component hardware aceste diferene n reprezentare trebuie a fi tratate nainte de realizarea propriu zis a comunicrii; - Dei sistemele de operare ale tuturor calculatoarelor conectate la Internet trebuie s conin o implementare a protocoalelor TCP-IP, ele nu ofer n mod obligatoriu aceeai interfa de programare pentru aceste protocoale; - Diferitele limbaje de programare folosesc reprezentri diferite pentru caractere i structuri de date; - Programele scrise de programatori diferii nu pot comunica unul cu altul dac nu sunt folosite standarde comune. Deschidere

Deschiderea unui sistem reprezint o caracteristic care determin dac sistemul poate fi extins sau reimplementat n alte moduri. Deschiderea unui sistem distribuit este determinat n principal de gradul n care noile servicii pot fi adugate i fcute disponibile. Aceast proprietate nu poate exista dac specificaiile i documentaia interfeelor sistemului nu sunt fcute publice. Cu alte cuvinte, interfeele sistemului trebuie publicate. Publicarea interfeelor reprezint punctul de pornire n adugarea i extinderea serviciilor ntr-un sistem distribuit. Adevrata provocare este dat de gestionarea complexitii sistemului distribuit, sistem alctuit dintr-o sum de component dezvoltate de oameni diferii i, implicit, grupuri eterogene. n acest sens, arhitecii protocoalelor Internet au introdus documentele RFC, n scopul publicrii specificaiilor protocoalelor de comunicare. Un aspect important este faptul c documentele RFC conin, pe lng specificaiile propriu-zise, i cunoatere provenind din discuiile referitoare la protocoalele respective. Publicarea protocoalelor de comunicaie reprezin unul din factorii principali care a permis construirea unei varieti de aplicaii i sisteme. Astfel, sistemele construite folosindu-se

aceste specificaii sunt deschise. Cu alte cuvinte, ele au un grad mare de extensibilitate: pot fi extinse att la nivel hardware, prin adugarea de noi calculatoare n reea, ct i la nivel software prin mbuntirea funcionalitii deja existente. Securitate

Multe dintre resursele partajate i gestionate n sistemele distribuite au o valoare mare pentru utilizator. n acest context securitatea este una dintre cele mai importante caracteristici ale unui sistem distribuit. Pot fi identificate trei componente referitoare la securitatea resurselor informaionale: confidenialitate - protecie mpotriva falsificrilor de documente i a accesului neautorizat; integritate att fizic ct i logic: protecie mpotriva coruperii datelor sau a distrugerilor fizice disponibilitate - protecie pentru pstrarea modurilor de acces la resurse. O problem des ntlnit o reprezint permisiunea de a avea liber acces n resursele unui intranet. Dei un firewall poate fi folosit pentru a crea o barier spre o reea intranet, restricionarea traficului care intr sau iese nu va garanta modul corespunztor de folosire a resurselor de ctre utilizatori din interiorul reelei. Securitatea nu nseamn doar ascunderea coninutului mesajului. Ea implic, de asemenea, cunoaterea utilizatorului sau agentului din partea cruia s-a fcut transmisia. Scalabilitate

Sistemele distribuite trebuie s poat opera eficient, indiferent de numrul componentelor sale. Un sistem este descris ca fiind scalabil dac va rmne eficient n momentul creterii numrului de resurse i de utilizatori. Sunt identificate trei dimensiuni: numrul de utilizatori sau resurse poate fi extins; arealul geografic poate crete; acoperirea unui numr mai mare de compartimente ntr-o companie. Tratarea erorilor

Orice sistem artificial, mai devreme sau mai trziu, va prezenta anomalii n funcionare. Dac aceste anomalii intervin n interiorul componentei hardware sau software, programele vor produce rezultate incorecte sau s-ar putea opri nainte de terminarea calculelor ncepute. De asemenea, anomaliile pot exista i n logica sistemului, respectiv n algoritmii implementai. Aceast situaie are consecine mai puin vizibile, ns, mult mai periculoase: datele prelucrate, conform unor algoritmi eronai, sunt transformate n informaii i implicit cunotine neconforme realitii, cu impact direct asupra calitii actului decizional. Erorile existente ntr-un sistem distribuit pot fi:

pariale unele componente vor avea probleme, n timp ce altele vor continua s funcioneze, acest lucru avnd o consecin att pozitiv (viznd disponibilitatea sistemului) ct i una negativ datorit dificultii cu care se face depanarea ntr-un context distribuit; totale toate componentele sistemului prezint probleme fizice sau logice. Din punct de vedere al erorilor fizice, aceast situaie este foarte puin probabil s se realizeze Joe. n vederea tratrii erorilorse identific principalele tehnici folosite: de detecie - Unele erori pot fi detectate. Pentru aceasta, pot fi folosite funcii de tip checksum, care verific dac datele din fiiere sau mesaje sunt corupte. n alte cazuri, care vizeaz mai ales componenta hardware, detecia unei erori poate fi imposibil ; de mascare a erorilor - Unele erori pot fi ascunse sau ncercat a se minimaliza efectul lor. Spre exemplu, mesajele pot fi retransmise atunci cnd nu reuesc s ajung, datele din fiiere pot fi scrise pe mai multe discuri, astfel nct, atunci cnd unele sunt corupte, s existe un set de rezerv. Cu siguran, vom ntlni ns i erori suficient de grave care s nu poat fi tratate astfel; de tolerare a erorilor Se poate observa faptul c majoritatea serviciilor Internet devin la un moment dat indisponibile. Nu ar fi practic a se ncerca permanent detectarea si ascunderea tuturor tipurilor de erori, care pot aprea ntr-o reea cu att de multe component de recuperare - Aceast situaie implic existena unui software special, software care s permit operaii de tip roll-back dup ce un server s-a defectat. n general, calculele efectuate de unele programe vor fi incomplete, n condiiile cnd apare o eroare. Consecina direct a aceste situaii o reprezint pierderea strii de consisten; de redundan - Serviciile pot fi construite pentru a trata erorile, folosind pentru aceasta componente redundante. Concuren

Att serviciile ct si aplicaiile furnizeaz resurse, care pot fi partajate de clienii unui sistem distribuit. Exist, prin urmare, posibilitatea ca un numr oarecare de clieni s acceseze aceeai resurs n acelai timp. Poate fi presupus c fiecare resurs este ncapsulat ca un obiect i invocrile sunt executate pe fire separate de execuie. n acest caz, exist posibilitatea concurenei pe un obiect a mai multor fire de execuie. n aceast situaie, operaiile realizate asupra obiectului vor fi n conflict, fiind generate rezultate inconsistente. Astfel, fiecare obiect, care reprezint o resurs partajat dintr-un sistem distribuit trebuie, s fie responsabil pentru operarea corect ntr-un mediu concurent. Orice programator care ncearc folosirea unui obiect nedestinat folosirii ntr-un sistem distribuit, trebuie s-l fac sigur pentru situaiile concureniale. Sigurana, n acest caz, nseamn un proces de sincronizare, astfel nct datele s rmn consistente. Acest lucru poate fi obinut prin tehnici standard precum semafoarele, care sunt folosite n majoritatea sistemelor de operare. Transparena

Transparena reprezint ascunderea fa de utilizator i dezvoltatorul de aplicaie a componentelor sistemului distribuit, astfel nct sistemul s fie perceput ca un ntreg i nu ca o

colecie de sisteme independente. n cadrul RM-ODP (Reference Model for Open Distributed Processing), au fost identificate 8 forme de transparen, dintre acestea alegnd nlocuirea termenului distribuia migraiei prin distribuia mobilitii, atribuindu-i astfel un scop mult mai larg: transparena accesului - permite att resurselor locale ct i celor de la distan s fie accesate folosind operaii identice; transparena locaiei - permite accesarea resurselor fr a cunoate locaia efectiv; transparena concurenei - permite mai multor procese s opereze concurent, folosind resurse partajate, fr a exista interferene ntre ele; transparena replicrii - permite mai multor instane ale unor resurse s fie folosite pentru creterea fiabilitii i performanei, fr ca utilizatorul sau programatorul s cunoasc existena replicilor; transparena erorilor - permite ascunderea diferitelor erori tehnice sau software, n acest fel utilizatorul va putea s-i ndeplineasc, mcar parial, sarcinile; transparena mobilitii permite micarea resurselor i clienilor dintr-un sistem, fr afectarea operaiilor sau programelor; transparena performanei - permite sistemului s fie configurat pentru mbuntirea performanei, atunci cnd variaz numrul de utilizatori; transparena extinderii - permite extinderea sistemului, fr modificri de structur sau algoritmi. Considerm c cele mai importante tipuri de transparen sunt transparena accesului, respectiv transparena locaiei, deoarece prezena sau absena acestora afecteaz cel mai mult, att utilizarea resurselor distribuite, ct i dezvoltarea aplicaiilor. Aceste dou tipuri de transparen se regsesc sub numele de transparena reelei. n plus fa de caracteristicile sistemelor distribuite prezentate, un alt element important, mai ales pentru dezvoltatorii de sisteme distribuite, l reprezint modul n care se poate realiza comunicarea ntre procese aflate pe diferite maini. Considerm acest element ca fiind important, mai ales n cazul sistemelor de management al cunotinelor, deoarece procesele de comunicare trebuie s poat permite existena unor fluxuri de date, ce reprezint adesea informaii complexe, att structurate, ct i nestructurate.

2. Arhitectura Client-Server i variaii ale acesteia Arhitectura unui sistem distribuit se refer la modul n care sunt plasate componentele sale i la relaiile dintre ele. n prezent, cele mai cunoscute exemple arhitecturale de sisteme distribuite sunt reprezentate prin modelul client-server, respectiv modelul punct la punct. Un model arhitectural definete modurile n care pot interaciona componentele unui sistem, respectiv felul cum sunt reprezentate acestea ntr-o reea de calculatoare. Prin urmare, poate fi descris structura stratificat a componentei software dintr-un sistem distribuit, precum i modelele arhitecturale principale, modele care determin locaiile i interaciunile dintre componente. n opinia lui Matthew modelul client-server reprezint arhitectura cea mai citat n discuiile referitoare la sistemele distribuite. Este cea mai important i rmne, din punct de vedere istoric, cel mai adesea utilizat. Procesele server pot fi la rndul lor clieni pentru alte servere. Serviciile furnizate prin intermediul serverelor Web pot fi implementate ca i mai multe procese server, rulnd pe calculatoare diferite i interacionnd atunci cnd este necesar pentru furnizarea serviciului ctre un proces client. Serverele pot partiiona setul de obiecte din care este construit serviciul sau pot pstra replici pe mai multe gazde. Arhitectura client-server folosete adesea servere proxy i zone cache. O zon cache reprezint un depozit pentru datele i obiectele recent accesate, care este mai aproape de process dect obiectele. Cnd un obiect nou este recepionat pe un calculator, el este adugat n cache, nlocuind dac este necesar unele dintre obiectele deja existente. Cnd un obiect este cerut de un proces client, serviciul cache nti verific aceast zon i furnizeaz obiectul doar dac acesta este actualizat. n caz contrar, va fi adus o copie actualizat. Zonele cache pot fi associate fiecrui client sau pot fi localizate ntr-un server proxy, care poate fi partajat de mai muli clieni. Aceast strategie este folosit mult n practic. Browserele web menin n cache paginile recent vizitate i alte servere web n sistemul de fiiere local clientului, folosind cereri HTTP pentru a verifica dac paginile stocate n cache sunt actualizate, nainte de afiarea lor. Serverele proxy

partajeaz o zon tampon, coninnd resurse web. Scopul acestor servere este dat de creterea disponibilitii i performanei serviciului prin reducerea ncrcrii n reelele mari i pe servere. Serverele proxy pot avea i alte roluri cum ar fi posibilitatea de a accesa servere web prin componentele firewall pe care acestea le au implementate. Opus modelului client-server regsim procesele punct la punct. n aceast arhitectur toate procesele joac roluri similare interacionnd ntr-un mod cooperativ, ca i egale, pentru efectuarea activitilor distribuite sau a calculelor, fr a se face distincie ntre clieni i servere. n acest model, codul acestor procese menine consistena resurselor la nivelul aplicaie i sincronizeaz aciunile (tot la nivelul aplicaie), atunci cnd este necesar. Eliminarea proceselor server reduce comunicarea ntre procese i ntrzierile n accesarea resurselor locale. Modelul client-server poate avea multiple variaii,care provin din factori, precum: utilizarea codului mobil i a agenilor mobili, nevoia utilizatorilor pentru calculatoare ieftine, uor de folosit cu posibilitatea conectrii n reele de calculatoare, respectiv necesitatea de adugare, ntr-o manier convenabil, a dispozitivelor mobile. Variaii ale modelului client server Codul mobil Un avantaj al execuiei codului descrcat local este realizarea unui bun rspuns interactiv, din moment ce nu exist ntrzieri sau variaii n limea de band asociat comunicrii n reea. Accesarea serviciilor nseamn execuia de cod care le apeleaz operaiile. Unele servicii sunt suficient de standardizate pentru a putea fi accesate i cunoscute prin intermediul aplicaiilor existente. Web-ul este un exemplu clasic, dar chiar i n acest caz, unele site-uri web folosesc o funcionalitate care nu este ntlnit n browserele standard i necesit descrcarea de cod adiional. S considerm o aplicaie care necesit ca utilizatorii s fie informai n timp real referitor la schimbrile care se desfoar pe o surs de informaie, ntr-un server. Aceasta nu se poate obine prin interaciuni normale, care sunt ntotdeauna iniiate de client. Soluia o reprezint folosirea unui software adiional care opereaz ntr-un mod diferit, adesea ca i model de tip push n care serverul i nu clientul iniiaz interaciunea. Spre exemplu, un agent de burs ar putea furniza un serviciu personalizat pentru a notifica clienii de schimbri n preul aciunilor; pentru a folosi serviciul, fiecare client ar trebui s descarce un program care primete modificrile de la serverul agentului, acestea putnd fi afiate utilizatorului, care poate chiar efectua operaii de vnzare-cumprare declanate de condiii ale clienilor i stocate local n sistemul clientului. Agenii mobili Un agent mobil - program care se mic ntre calculatoarele unei reele pentru execuia unor sarcini precum colectarea informaiilor - poate realiza multiple invocri de resurse locale, cum ar fi accesarea nregistrrilor din baze de date. Dac vom compara aceast arhitectur cu un client static care realizeaz apeluri la distan ctre unele resurse, posibil transferuri mari de date, vom observa o reducere a comunicrii i a timpului prin nlocuirea invocrilor la distan cu cele locale. Agenii mobili ar putea fi folosii pentru instalarea i mentenana componentei software pe calculatoarele unei organizaii sau n alt caz, cu totul diferit, pentru a compara preurilor produselor de la un numr oarecare de comerciani, prin vizitarea fiecrui site i efectuarea unei serii de operaii pe baza de date. Un exemplu similar este programul de tip Worm, dezvoltat de XEROX PARC, care a fost proiectat pentru a folosi calculatoarele (procesoarele) n stare inactiv n efectuarea unor calcule intensive Agenii mobili (i codul mobil) sunt un potenial pericol n ceea ce privete securitatea resurselor. Mediul care primete un agent mobil ar trebui s decid care dintre resursele locale sunt disponibile, bazndu-se pe identitatea utilizatorului din

partea cruia se recomand a fi agentul identitatea lor trebuie inclus ntr-un mod ct se poate de sigur n codul agentului mobil. n plus, agenii mobili pot fi ei nii vulnerabili ca i consecin nu vor putea s-i ndeplineasc sarcinile dac li se va refuza accesul la resurse. Sarcinile efectuate de agenii mobili pot fi n general realizate i prin alte mijloace. Spre exemplu, programele crawler, care au nevoie s acceseze resurse pe servere web, lucreaz suficient de bine prin folosirea apelurilor la distan ctre procesele serverului. Calculatoarele n reea n cea mai mare parte a cazurilor, aplicaiile ruleaz pe un calculator personal (local). Sistemul de operare i software-ul aplicaie pentru calculatoarele desktop necesit ca o mare parte a codului activ i a datelor s fie pstrate pe discurile locale. Managementul fiierelor aplicaie, precum i mentenana componentei software locale necesit adesea un efort ethnic considerabil pe care utilizatorii nu sunt calificai s-l furnizeze. Calculatoarele cu suport n reea sunt un rspuns la aceast problem. Ele i descarc sistemul de operare i orice software aplicaie necesar utilizatorilor de pe un server de fiiere. Aplicaiile sunt rulate local, dar fiierele sunt gestionate de un alt server. Din moment ce toate datele aplicaiei ct i codul sunt stocate de un server de fiiere, utilizatorii pot migra de la un calculator la altul. Capacitile procesorului i ale memoriei pot fi reduse cu scopul de a obine costuri ct mai mici. Dac totui este pus la dispoziie i o resurs local de stocare, aceasta va conine doar un minim de software i va fi folosit n principal ca zon cache pentru replici care au fost recent ncrcate de pe server. Administrarea zonei cache nu necesit efort manual, obiectele stocate astfel sunt invalidate de fiecare dat cnd o versiune nou a fiierului este scris pe server. Clieni uori(thin) Se refer la un nivel software care susine o interfa grafic utilizator (local) n timp ce aplicaia se execut pe un alt calculator. Acest model de arhitectur prezint acelai management de nivel sczut i costuri hardware asemntoare schemei bazat pe reeaua de comunicaie, singura diferen fiind execuia programelor pe un calculator foarte performant, care are capacitatea rulrii unui numr mare de procese simultane. Principalul inconvenient l identificm n activitile grafice cu un grad mare de interactivitate precum CAD sau procesarea de imagini, unde ntrzierile experimentate de utilizatori sunt crescute de nevoia transferului de imagini, inducnd blocaje: att n reea ct i n sistemul de operare. Aceast categorie de clieni sunt considerai a fi simpli ca i concept de implementare: Spre exemplu, majoritatea variantelor UNIX includ sistemul X11. Acest sistem reprezint un proces care gestioneaz display-ul i echipamentele interactive de intrare (tastatur, mouse) ale calculatorului pe care ruleaz. X11 furnizeaz o bibliotec extensiv de proceduri (protocolul x11) pentru afiarea i modificarea obiectelor grafice, precum i crearea sau manipularea ferestrelor. Sistemul x11 este referit ca fiind un proces server de tip fereastr. Clienii serverului x11 sunt programe aplicaie cu care interacioneaz utilizatorul. Programul client comunic cu serverul prin invocarea aplicaiilor din protocolul x11, acestea incluznd operaii care deseneaz text i obiecte grafice n ferestre. Clienii nu trebuie s fie localizai pe acelai calculator ca i serverul, din moment ce procedurile sunt ntotdeauna invocate, folosind un mecanism RPC. Dispozitivele mobile i reelele spontane Mediul tehnologic este populat cu un numr din ce n ce mai mare de dispositive portabile: laptopuri, PDA-uri, telefoane mobile, camere digitale, chiar aparatur electrocasnic, toate folosind microprocesoare. Majoritatea acestor echipamente pot folosi tehnologii fr fir n contextul unei reele metropolitane sau chiar pe suprafee extinse (GSM, CDPD). Odat cu integrarea n sistemele distribuite, aceste echipamente pot furniza suport pentru calculul mobil,

cu att mai mult cu ct utilizatorii i poart dispozitivele mobile n diferite reele i pot beneficia att de avantajele serviciilor locale ct i a celor de la distan. Forma distribuiei care integreaz dispozitivele mobile i alte echipamente ntr-o reea, o putem descrie cel mai bine sub termenul de reea spontan. Acest concept este folosit pentru a cuprinde aplicaii care implic conectarea att a elementelor mobile, ct i a celor fixe n reele de comunicaie. Caracteristici ale reelelor spontane: o conectare uoar la o reea local: Legturile fr fir evit nevoia cablrii i inconvenienele legate de fiabilitatea echipamentelor de conectare mufe, prize de reea; sunt singurele linii de comunicare care pot fi meninute n momentul deplasrii utilizatorilor; un echipament adus ntr-o reea nou este reconfigurat ntr-un mod transparent pentru a obine conectivitate -o astfel de reea, descoper automat ce servicii sunt oferite. Reelele spontane ridic i o serie de probleme arhitecturale. Este vorba despre modul de implementare a unei conectri i integrri convenabile i mai ales eficiente. Spre exemplu, adresarea Internet i algoritmii de rutare presupun existena calculatoarelor n anumite subreele. Dac un calculator este mutat ntr-o alt subreea, acesta nu mai poate fi accesat cu aceeai adres Internet. O alt problem apare pentru utilizatorii mobili. Acetia pot experimenta o conectivitate sczut pe msur ce cltoresc i n plus extrem de nesigur. conectivitatea limitat: Utilizatorii nu sunt ntotdeauna conectai pe durata deplasrii lor. Spre exemplu, ei ar putea fi n mod intermitent deconectai de la o reea fr fir atunci cnd sunt ntrun tunel. Ei ar putea fi total deconectai pentru perioade mai lungi n regiuni unde conectivitatea fr fir este indisponibil sau unde este prea scump pentru a rmne conectai. Problema este cum poate susine sistemul, clienii deconectai, pentru ca acetia s poat lucra n continuare. securitate i intimitate: Astfel, hotelul i clienii sunt vulnerabili la atacuri din partea fie a altor oaspei sau chiar a personalului propriu, care ncearc conectri ntr-un mod nesupervizat. Unele sisteme in evidena locaiei fizice a utilizatorilor pe msur ce acetia se mic fapt care poate fi considerat un atentat la intimitate .n final, mai menionm i cazul n care permiterea utilizatorilor s-i acceseze propriul intranet n timp ce se deplaseaz, poate expune date care n mod normal ar trebui s fie protejate de un firewall. descoperirea serviciilor: Reelele spontane cer proceselor client rulnd pe dispositive portabile s acceseze servicii pe reelele unde acestea sunt conectate. Cum pot ns clienii s fie conectai la serviciile de care au nevoie pentru a ndeplini sarcini utile? Este nevoie de mijloacele necesare clienilor s identifice serviciile care sunt disponibile n reea (unde sunt conectai) i s le investigheze proprietile. Scopul unui serviciu de descoperire este s accepte i s stocheze detalii ale serviciilor care sunt disponibile pe reea i s rspund interogrilor clienilor despre ele. Mai precis, un astfel de serviciu ofer dou interfee: cereri de nregistrri de la servere i nregistreaz detalii despre acestea baza de date pentru servicii nregistrate care se potrivesc cererii fcute. Rezultatul ar trebui s conin suficiente detalii pentru a da posibilitatea clienilor s aleag ntre servicii similare pe baza atributelor lor i s fac conexiunile ctre unul sau mai multe dintre acestea. Observm c toate modelele de sisteme prezentate partajeaz o serie de proprieti fundamentale. Fiecare dintre ele sunt alctuite din procese care comunic ntre ele prin transmiterea de mesaje

printr-o reea de calculatoare. Toate modelele se bazeaz pe un set de cerine, viznd proiectarea, care au scop creterea performanei, fiabilitii i a securitii resurselor partajate. n general, un model conine doar componentele eseniale pe care trebuie s le lum n considerare pentru a nelege aspectele de comportament ale sistemului. Un model al unui system distribuit trebuie s rspund urmtoarelor ntrebri: - care sunt principalele entiti n sistem? cum interacioneaz acestea? care sunt caracteristicile care influeneaz comportamentul lor (att individual, ct i colectiv). Putem sintetiza i afirma c scopul unui model este pe de o parte s fac explicite toate presupunerile relevante despre sistemul modelat, iar pe de alt parte s realizeze generalizri privind ceea ce este posibil i imposibil, pe baza presupunerilor despre sistem.

3. Arhitectura Grid Conform Foster, grid-ul reprezint o platform de calcul pentru rezolvarea problemelor complexe, care necesit o mulime vast de resurse. Arhitectura Grid unific o mare varietate

de resurse computaionale, sisteme de stocare, surse de date, baze de date, instrumente tiinifice, prezentndu-le sub forma unei resurse unitare. Considerm, c din punctul de vedere al dezvoltrii aplicaiilor, mediul Grid reprezint o provocare complex, deoarece resursele sunt: distribuite geografic, eterogene sau deinute de companii avnd politici proprii. Utilizatorii unui grid interacioneaz cu o component GRB(grid resource broker), care ascunde complexitatea managementului resurselor. Componenta GRB descoper resursele folosind servicii speciale de informare, negociaz costuri cu agenii resurselor, realizeaz selecia resurselor, identific aplicaiile i datele necesare procesrii i transmite utilizatorului rezultatele finale. Buya subliniaz faptul c arhitectura Grid poate fi aplicat cu succes n mediul economic. Utilizarea gridului n mediul economic implic interaciuni ntre dou componente - furnizorii de resurse, respectiv consumatorii de resurse- n care ambele au propriile strategii. Consumatorii de resurse vor adopta strategia rezolvrii problemelor la un cost ct mai sczut, ntr-un interval de timp dat, n timp ce furnizorii de servicii vor urmri obinerea unor rezultate financiare ct mai bune. Utilizarea tehnologiilor Grid implic existena a dou categorii de utlizatori: dezvoltatori de sisteme, respectiv utilizatori finali. Dezvoltatorii de sisteme sunt aceia care construiesc soluii Grid, folosind pentru aceasta instrumente precum Globus, Unicore sau Condor. Utilizatorii finali, reprezentai de savani, ingineri, economiti, etc., folosesc Grid-ul pentru rezolvarea unor probleme specifice, prin intermediul portalurilor Grid. Considerm c pentru managementul cunotinelor economice, portalurile grid prezint o foarte mare importan, deoarece ele se vor adresa unui numr mare de persoane. Practic, utilizarea gridului va depinde de nelegerea funcionrii portalului. n plus, fiecare portal Grid ofer acces la o mulime bine definit de servicii ale gridului. Deoarece de-a lungul timpului aceste servicii s-au diversificat, portalurile au nceput s cunoasc i ele modificri semnificative. Studiul realizat n continuare prezint trei generaii de portaluri grid, realizarea lui fiind motivat de importana acestor tehnologii, n contextul n care, ele pot determina eficiena angajailor organizaiei: Prima generaie de portaluri grid: Majoritatea portalurilor grid utilizate n prezent fac parte din aceast categorie. Conform lui Foster, portalurile din prima generaie sunt construite pe baza unei arhitecturi pe 3 niveluri. Aceste portaluri au n comun urmtoarele caracteristici: precum baze de date, calculatoare performante, dispozitive de stocare, echipamente specializate;

utilizatorul; ilor, definitorii pentru sarcina care doresc s o execute, web serverul lanseaz un manager de aplicaii. Managerul de aplicaii este reprezentat printr-un proces care controleaz i monitorizeaz execuia sarcinilor; Serviciile furnizate de prima generaie de portaluri grid: Autentificare i autorizare: prin autentificare este identificat cine este conectat la sistem,

n timp ce prin autorizare sunt stabilite resursele pe care utilizatorul are drepturi s le foloseasc. Un portal grid ofer un singur mecanism de tip sign on, care permite utilizatorilor s acceseze resurse multiple, dup efectuarea autentificrii; Managementul sarcinilor: un portal grid furnizeaz utilizatorilor posibilitatea de a-i gestiona sarcinile, acest lucru putnd fi realizat att secvenial, ct i paralel. Spre exemplu, lansarea n execuie a aplicaiilor, prin intermediul unui browser, ntr-un mod sigur i fiabil, respectiv monitorizarea strii curente, oprirea sau anularea sarcinilor n execuie; Transfer de date: este permis utilizatorilor s ncarce seturi de date, care s acompanieze sarcinile necesar a fi executate; Servicii de informare: un portal grid utilizeaz mecanisme de descoperire pentru identificarea resurselor necesare i disponibile pentru o anumit sarcin. Dei prima generaie de portaluri Grid poate susine dezvoltatorii de sisteme Grid n construirea rapid de portaluri, ea prezint o serie de limitri: principal prin instrumente dedicate dezvoltatorilor. Adesea, utilizatorii finali se gsesc n postura de a folosi scripturi sau diferite forme de API, ceea ce reprezint o situaie nedorit. Instrumentele optime ar trebui s poat ascunde complexitatea gridului fa de utilizatorii finali; arhitecturilor grid, structurate pe trei niveluri, este reprezentat de slaba interoperabilitate a acestora. Acest tip arhitectural conduce la urmtoarea problem: interfeele utilizator sunt dependente de nivelul de mijloc al gridului, care la randul su este dependent de sistemul back-end. Astfel, este dificil integrarea serviciilor grid, construite pe baza unor tehnologii diferite, ntr-un portal din prima generaie. Portaluri grid din a doua generaie: Pentru a suplini problemele specifice primei generaii, portalurile grid din a doua generaie folosesc componentele denumite portlet. Spre exemplu, proiecte tiinifice, precum Xportlet, respectiv GridSphere i propun s furnizeze un cadru pentru construirea portalurilor grid cu ajutorul portlet-urilor. Din perspectiva utilizatorilor, un portlet reprezint o fereastr n portal, care furnizeaz acces la un serviciu specific sau la o anumit informaie. Pe de alt parte, din perspective dezvoltatorului de aplicaii, portlet-urile reprezint module proiectate pentru a rula n interiorul unui container, existent pe un portal server. Portlet-urile reprezint forme avansate ale servleturilor Java. Portalul server colecteaz mai multe portlet-uri, utilizatorul avnd posibilitatea de a accesa o gam larg de aplicaii. ntocmai precum componentele Java Servlet, un portlet va procesa cererile HTTP i va produce rezultate HTML. Rezultatul HTML nu reprezint, ns, dect o parte a paginii Web finale. A treia generaie de portaluri grid: Dac a doua generaie de portaluri grid era orientat spre utilizarea componentelor de tip portlet, portalurile din a treia generaie vor fi centrate pe serviciile care pot fi oferite i in special pe cele semantice. Conform W3C, a treia generaie de portaluri grid vor implica folosirea grid-urilor semantice, promovnd astfel orientarea spre servicii i folosirea tehnologiilor specific serviciilor Web. n aceast arhitectur, serviciile Web pot fi publicate, descoperite, respective conectate la aplicaii interne. Un serviciu specific gridului semantic va avea implicit nelegeri semantice, fiind folosite pentru aceasta cele mai potrivite i fiabile resurse. n cadrul gridului semantic, un portlet va ncapsula unul dintre serviciile oferite i va avea o semantic anume. Serviciile oferite prin aceast categorie de portaluri sunt mai complexe dect cele din a doua generaie, ele fiind n strns corelare cu un domeniu i bazate pe cunotine. Teoretic, pentru

obinerea unei soluii la o problem, utilizatorii vor trebui doar s descrie problem i s refere, eventual, un set de date iniiale. Gridul semantic poate fi divizat pe patru nivele: Nivelul computaional are drept scop integrarea unui numr mare de resurse de procesare. Serviciile oferite se refer la descoperirea i alocarea resurselor, monitorizarea resurselor, autentificarea utilizatorilor, tolerana la erori; Nivelul de date este construit pe baza serviciilor oferite prin nivelul computaional. Acest nivel furnizeaz: o accesul la procese de calcul intensiv: o posibilitatea de analiz a unui volum mare de date de ordinul PetaBytes. Serviciile furnizate de acest nivel se refer la stocarea datelor, gestiunea metadatelor, replicare i transfer. Nivelul informaional este construit pe baza serviciilor oferite de nivelul de date, permind accesul la surse eterogene de informaie. Serviciile oferite pot varia, n funcie de tipul aplicaiilor ce sunt implicate. Spre exemplu: o calcule tiinifice: serviciile pot include rezolvarea unor probleme precum previziuni meteo sau dinamici moleculare; o calcul comercial: serviciile pot fi reprezentate prin rutine statistice sau datamining; o hypermedia: serviciile pot ngloba algoritmi pentru analiza coninutului multimedia. Serviciile specifice acestui nivel pot fi oferite att de furnizori individuali, ct i de corporaii, putnd fi specializate n funcie de specificul aplicaiilor. identificarea unor modele n structurile de date existente. Scopul principal al acestui nivel este de a descoperi cunotine ntr-un volum mare de date folosind tehnici de datamining.

4. Arhitecturile de tip cloud Datorit dezvoltrii tehnologiilor informaionale i mai ales de comunicare, att tehnologiile Web 2.0, ct i calculul de tip cloud cunosc o dezvoltare rapid, aducnd schimbri n proiectarea i dezvoltarea sistemelor informaionale. Calculul de tip cloud reprezint o consecin major a tehnologiilor Web 2.0 n dezvoltarea software i descoperirea noilor modele de afaceri. Au fost definite urmtoarele concepte, permindu-se astfel o posibil reformulare a poziiei sistemului informaional n organizaie: tware-ul ca i serviciu (SAAS): module software prezentate sub forma unor servicii gzduite i accesate prin intermediul Internetului; sunt furnizate de comanii tere; stocare i reele, poate fi distribuit sub forma unui serviciu de tip cloud, n mod tipic prin procese de virtualizare. Kim discut beneficiile calculului ntr-o arhitectur cloud: agilitate, adaptabilitate, flexibilitate, scderea costurilor, interoperabilitate. Pe lng aceste avantaje exist i o serie de probleme, pe care le ntmpin aceast abordare. Conform aceluiai autor, cele mai importante probleme sunt reprezentate de securitate i flexibilitatea organizaional. Serviciile pe care calculul cloud le include pot fi structurate pe patru componente: Servicii gestionate - Servicii construite pentru a oferi organizaiei posibilitatea folosirii unui anume software SAAS - Furnizorii SAAS ruleaz o singur aplicaie ntr-un centru de date44 i ofer utilizatorilor funcionalitatea acesteia, prin intermediul Internetului. Servicii Web - Furnizorii de servicii Web ofer API-uri, pe care programatorii le pot folosi n dezvoltarea aplicaiilor IAAS - Multe companii ofer, prin intermediul Internetului resurse de calcul, precum

servere virtuale, sau clustere de procesoare PAAS - Este oferit companiilor, sub forma unui serviciu, posibilitatea utilizrii unor medii complexe pentru dezvoltarea aplicaiilor. Cunoaterea din nor (KC) reprezint un concept nou formulat de ctre Cerri, extinzndu-l pe acela de date din nor46. Pentru a beneficia de avantajele KC, n primul rnd trebuie s poat fi realizat o extracie a unei cunoateri semantice, din informaia disponibil. Aceast cunoatere este partajat prin intermediul tehnologiilor componente din arhitectura cloud. Dezvoltarea unei arhitecturi SMC folosind calculul cloud poate reprezenta urmtorul pas ctre o soluie MC distribuit, orientat spre utilizator. Dup prerea lui Li, adoptarea arhitecturilor cloud va facilita partajarea cunoaterii i integrarea diferitelor platforme, respectiv servicii IT. Pentru aceasta, sunt definite dou tipuri de nori: interni i externi. Acelai autor subliniaz faptul c exist o tendin clar de expansiune a norilor externi, aceast situaie fiind susinut de mbuntirea modelului cloud i a msurilor de securitate. Un alt beneficiu al calculului cloud, l reprezint faptul c ofer posibilitatea angajailor de a integra coninut provenind din nori externi sau interni, folosind pentru aceasta instrumente Web 2.0, precum: Mashups, Wiki, Blogs. Sunt create astfel spaii de lucru virtuale, care faciliteaz transferul cunotinelor. Belsis subliniaz faptul c instrumente, precum software-ul social sau Web 2.0 au revoluionat modul n care tehnologia informaiei poate susine procese specific managementului cunotinelor economice. Managementul cunotinelor organizaionale reprezint un domeniu fundamentat pe tehnologii informaionale i de comunicare, ce prezint urmtoarele funcii principale - funcii care reprezint i scopul arhitecturilor de tip cloud:

a anumitor sarcini. Dezvoltarea structurilor nor de tip privat, partener sau public i interconectarea lor la SMC permite utilizarea inteligenei colective, format n fiecare nor, n toate procesele managementului cunotinelor.

5. Calculul mobil si implicatii Calculul mobil a adus schimbri semnificative n ceea ce privete o multitudine de practici organizaionale. Contextul n care efectuarea unei sarcini necesita prezena fizic a angajatului n faa unui calculator conectat la o reea reprezenta o limitare major pentru toate acele persoane ale cror atribuii nu le permiteau un spaiu de lucru fix. Identificm trei soluii oferite de mediul tehnologic pentru aceast problem: i care s le fac portabile; mobile n medii de comunicare fr fir. Conform lui Dogac i Tumer [Dogac, 2002] calculul mobil prezint dou caracteristici majore: Mobilitatea: calculul mobil i afacerile mobile se bazeaz pe faptul c utilizatorii poart un dispozitiv mobil oriunde ar merge. Mobilitatea implic portabilitate. Prin urmare, indiferent de poziia lor, utilizatorii pot iniia o legtur n timp real cu alte sisteme, cu condiia s fie n raza de acoperire a unei reele wi-fi, reea care s le asigure accesul la Internet. Acoperire larg : n contextul calculului mobil, oamenii pot fi gsii oriunde s-ar afla. Desigur, utilizatorii pot bloca accesul la diferite ore sau pentru anumite mesaje, dar n

afara acestor excepii ei pot fi contactai instantaneu. Despre aceste dou caracteristici putem afirma c realizeaz unificarea dimensiunii temporale cu cea geografic, identificnd pe baza lor cinci atribute importante ale afacerilor mobile: Omniprezena: disponibilitatea n orice locaie, la orice moment de timp; Convenabilitate : este foarte convenabil pentru un utilizator s acioneze ntr-un mediu mobil. Tot ceea ce are nevoie este doar un dispozitiv mobil cu posibilitate de conectare la Internet ; Conectivitatea instantanee : echipamentele mobile permit utilizatorilor s se conecteze la Internet sau Intranet, timpul de ncarcare al sistemului de operare fiind mult mai mic dect n cazul calculatoarelor personale ; Personalizare : ofer posibilitatea pregtirii de informaie specializat pentru fiecare utilizator ; Localizarea produselor i a serviciilor : cunoaterea locului geografic unde se afl situat un utilizator reprezint un element important n definirea produselor i serviciilor relevante. n plus fa de aceste atribute, potrivit lui Coursaris [Coursaris, 2004], dezvoltarea calcului mobil este susinut de o serie de factori suplimentari, respectiv : Larga disponibilitate a dispozitivelor mobile : Spre exemplu, numrul telefoanelor mobile n lume a depit 2 miliarde62, fiind estimat c n aproximativ 5 ani, mai mult de 70% dintre ele vor avea acces la Internet. Prin urmare, exist disponibil o potenial pia pentru activiti de tip mbusiness Nu exist nevoia unui PC : Deoarece internetul poate fi accesat prin intermediul echipamentelor mobile, exist posibilitate ca nevoia de PC-uri s scad. Dei costul unui PC, folosit exclusiv pentru acces la Internet, este foarte sczut, ntlnim dou dezavantaje : dificultatea nvrii de a opera un calculator, respectiv costurile de ntreinere i actualizare ; Cultura telefoanelor celulare : Telefoanele celulare reprezint un fenomen social. Practic, nc din copilarie, majoritatea persoanelor posed un telefon mobil ; Scderea preurilor i creterea funcionalitii : Odat cu trecerea timpului, preul dispozitivelor mobile este n scdere, n timp ce funcionalitatea lor este extins. 6. Comunicarea prin mesaje Transmiterea mesajelor ntre procesele locale i la distan este vizibil programatorului. Traseul informaiei este unidirecional de la client la server. Oricum, n cazul transmiterii avansate de mesaje, precum cea a mesajelor structurate, fluxul va fi bidirecional: un mesaj de rspuns fiind formalizat ca rspuns la cererea iniial. Mai mult, transmiterea de mesaje este o tehnic n totalitate netipizat.

Exist dou aspecte importante n acest tip de comunicaie: mesajele folosite n comunicare i mecanismele folosite pentru a le transmite i recepiona. Orice utilizator care folosete aceast form de comunicaie va cunoate explicit ambele aspecte menionate anterior. Conform lui Oszu [Ozsu, 2000] , un mesaj reprezint o colecie de date avnd un antet de mrime fix i un corp variabil sau constant, care poate fi gestionat de un proces i transmis la destinaie. Un tip asociat cu un mesaj formalizeaz informaia structural despre modul n care mesajul ar trebui identificat. Mesajul poate fi de orice mrime i poate conine date sau referine (pointeri) la date n afara zonei continue a mesajului. Coninutul este determinat de procesele care l transmit. Mesajele pot fi complet structurate sau nestructurate. Mesajele nestructurate au flexibilitatea de a putea fi interpretate. Cu toate acestea, folosirea lor poate ridica probleme, deoarece anumite pri ale mesajelor, cum ar fi numele porturilor, trebuie interpretate de ctre sistemele de operare distribuite sau de ctre protocolul de comunicare. Mesajele structurate sunt favorizate din motive de eficien: Majoritatea informaiei transferat ntre procese este structurat prin faptul c reprezint date care nglobeaz tipuri diferite. Folosirea mesajelor nestructurate pentru astfel de date este costisitoare deoarece ncapsularea i decapsularea mesajelor structurate n forme liniare nestructurate adaug un nivel de ncrcare (overhead), care crete costurile comunicrii. Sistemele de operare care funcioneaz preponderent n reele de calculatoare au implementate o multitudine de instrumente cu ajutorul crora poate fi vizualizat ncrcarea reelei - Evi [Evi, 2006], indifferent de tipul transmisiei care se realizeaz. Pentru ca oricare dou calculatoare s schimbe date, trebuie s reprezentm structurile de date, respectiv datele propriu-zise n mesaje. Structurile de date trebuie liniarizate naintea transmisiei i reconstruite la destinaie. Liniarizarea structurilor de date n secvene de date fundamentale se folosete pentru procesul de transmitere fizic. n mod obinuit, un preprocessor de limbaj (interface compiler) poate fi folosit pentru generarea automat a acestor operaii (marshalling/unmarshalling5). O component important a comunicrii prin mesaje se refer la mecanismele folosite pentru a transmite i recepiona mesaje. Aceste mecanisme implic un set de primitive folosite pentru comunicaie. John [John, 2003] identific dou aspecte referitoare la mecanismele transmiterii mesajelor: primul se refer la identificarea primitivelor de comunicare, n timp ce al doilea face referire la semantica acestora, menionnd faptul c problema fundamental n comunicare mesajelor este dat de destinaia mesajelor. ntr-o astfel de comunicare, un mesaj este trimis i recepionat prin execuia explicit a primitivelor send i receive. Primitiva receive trebuie s fie activ naintea sosirii mesajului, altfel cererea ar putea fi declarat ca pierdut, fiind necesar retransmiterea ei de ctre client. Referitor la comunicarea ntre procese, John [John, 2007] prezint posibilitatea utilizrii a dou tehnici: Prima tehnic este denumit comunicare direct i folosete nume directe. n comunicarea direct, fiecare proces care dorete s trimit sau s recepioneze un mesaj trebuie s numeasc n mod explicit destinatarul i expeditorul. Comunicarea direct este mai uor de implementat i folosit. Ea permite unui proces s controleze timpii la care primete mesaje de la fiecare proces. Dezavantajul acestei scheme este reprezentat de modularitatea limitat a proceselor rezultate.

Schimbarea numelui unui proces poate necesita schimbarea multor alte definiii de procese. Toate referinele spre procesul vechi trebuie gsite pentru a le putea modifica cu noile nume, acest lucru fiind mai bine evitat din punctul de vedere al compilrii separate. Comunicarea direct nu permite mai mult de un client. Aceasta din cauz c emiterea primitivei receive ar fi necesar pentru fiecare client; procesul server nu poate anticipa numele tuturor potenialilor clieni. De asemenea, acest model de comunicare nu permite trimiterea unei cereri spre mai mult de un server. A doua tehnic se numete comunicare indirect i utilizeaz conceptul de port. Se formeaz astfel nevoia unei tehnici mai sofisticate, aceasta bazndu-se pe porturi. Putem s privim portul ca un obiect din nucleul sistemului de operare, n care procesele pot plasa mesaje i de unde mesajele pot fi extrase (astfel mesajele sunt trimise i recepionate prin porturi). Procesele pot avea drepturi de proprietar, de citire sau scriere pe un port. Fiecare port are asociat (logic i nu fizic) o structur de tip coad (avnd o lungime limitat) unde vom gsi mesajele trimise ctre acest port, dar care nu au fost terse de un proces. Totodat, mesajele pot fi adugate de ctre orice proces, care poate referi portul printr-un nume local. Portul poate aparine fie unui proces, fie sistemului de operare. Dac gestiunea este fcut de un proces, atunci portul este ataat sau definit ca o parte a procesului (drepturile asupra lui pot fi transmise n cadrul mesajelor de la un proces la altul). Dac sistemul de operare are drepturi asupra unui port, el va furniza un mechanism care permite unui proces s creeze un nou port (procesul fiind proprietarul de drept), s transmit i s recepioneze mesaje prin port, sau s-l distrug. Cypher [Cypher, 1994] precizeaz faptul c una dintre cele mai importante proprieti ale primitivelor de transmitere a mesajelor se refer la posibilitatea ca execuia lor s produc ntrzieri. Facem, astfel, distincie ntre primitive blocante i neblocante. Spunem despre o primitiv c are semantic neblocant dac execuia ei nu produce ntrzieri pe partea celui care o invoc. Altfel, spunem despre o primitiv c este blocant, dac mesajele trebuie stocate n zone tampon - mesaje de tip buffered.

7. Apelul procedurilor la distanta Tehnica RPC se bazeaz pe conceptul cunoscut sub numele de apel al procedurii. Acest termen general reprezint, de fapt, un mecanism tipizat, care permite unui apel, realizat ntr-un anume spaiu de memorie, s fie automat transformat ntr-un apel corespondent pe alt calculator. Transmiterea mesajelor este invizibil programatorului RPC, necesitnd pentru aceasta un

protocol de transport n vederea susinerii transmisiei argumentelor, precum i a rezultatului. Chappel [Chappel,1994] subliniaz faptul c multe sisteme distribuite au fost bazate pe schimbul explicit de mesaje ntre procese. Oricum, primitivele send i receive nu ascund procesul de comunicare, proces important pentru obinerea transparenei accesului n sistemele distribuite. Aceast situaie poate fi ns obinut, dac este permis programelor s apeleze proceduri localizate pe alte maini. Cnd un proces aflat pe maina A apeleaz o procedur pe maina B, procesul apelant de pe A este suspendat i execuia procedurii invocate are loc pe B. Informaia poate fi transportat cu ajutorul parametrilor de la apelant la apelat i se poate ntoarce n rezultatul procedurii. Nici un schimb de mesaje nu este vizibil programatorului. Aceasta este tehnica pe care o gsim sub numele RPC (Remote Procedure Call). Ideea din spatele RPC este de a face ca apelul unei proceduri la distan s par ct mai asemntor celui local. Cu alte cuvinte, dorim RPC s fie transparent. S presupunem c un program are nevoie de a citi nite date dintr-un fiier. Programatorul va pune n cod un apel ctre o procedur de citire pentru a obine datele. ntr-un sistem tradiional, reprezentat de un singur procesor, rutina de citire este extras din librrii i introdus n program. Aceasta este o procedur scurt, n general implementat prin apelul unei proceduri sistem echivalente. Cu alte cuvinte, procedura de citire reprezint o interfa ntre codul utilizatorului i sistemul de operare local. Dei prin procedura implementat de utilizator este realizat un apel sistem, acesta este realizat n modul clasic, prin aezarea parametrilor n stiv. n acest mod, programatorul nu cunoate faptul c metoda lui realizeaz ceva auxiliar. RPC i obine transparena ntr-un mod analog. Cnd procedura de citire este la distan, ruleaz, spre exemplu pe un server de fiiere, o versiune diferit a ei, numit stub client, este pus n bibliotec. ntocmai precum originalul, aceasta va fi apelat folosind secvena clasic, iniiindu-se astfel un apel sistem. n mod clasic, stub-ul server trebuie s apeleze primitiva receive i s stea blocat n ateptare de mesaje. El va despacheta parametrii din mesaj pentru ca ulterior s apeleze procedurile n modul clasic. Din punctul de vedere al serverului este ca i cum apelul s-ar face direct parametrii i adresele sunt toate pe stiv i nimic nu pare neobinuit. Procesul server i va efectua sarcina i apoi va ntoarce rezultatul apelantului. Spre exemplu, n cazul procedurii de citire, buffer-ul refereniat de al doilea parametru va fi umplut. Acest buffer va fi intern stub-ului server. Odat ce stub-ul server preia controlul, dup ce apelul a fost completat, va mpacheta rezultatul ntr-un mesaj i va apela primitiva send pentru a-l ntoarce clientului. Cnd mesajul ajunge napoi pe maina client, sistemul de operare observ c este adresat procesului client (stub-ului client sistemul de operare nu face ns nici o diferen). Mesajul este copiat n buffer-ul de ateptare i procesul client deblocat. Stub-ul client inspecteaz mesajul, despacheteaz rezultatul i l pred procesului apelant. Cnd acest proces primete controlul, dup apelul primitivei read, tot ceea ce cunoate este c datele sunt disponibile. Nu exist nici un element care s-l fac s neleag c ntreg mecanismul s-a desfurat pe alt main i nu sub gestiunea sistemului de operare local. Serviciile remote sunt astfel accesate prin apeluri de proceduri locale i nu prin apelarea direct a primitivelor send i receive. Toate detaliile transmiterii de mesaje sunt ascunse n cele dou biblioteci, tot la fel precum apelurile sistem sunt ascunse prin bibliotecile standard. n opinia lui Shiva [Shiva, 1993], transmiterea parametrilor referin reprezint cazul cel mai dificil de tratat; cu alte cuvinte, cum sunt transmii pointerii? Aceasta reprezint o

ntrebare care este posibil s rmn, chiar i n viitor, fr un rspuns complet i satisfctor. Dup cum este cunoscut, o referin are semnificaie doar n spaiul de adrese al procesului care este folosit. Una dintre soluii ar fi interzicerea utilizrii parametrilor de tip pointer. Oricum, acetia sunt att de importani nct aceast soluie este complet nedorit. S considerm cazul n care stub-ul client tie c al doilea parametru face referire la un vector de caractere. S presupunem de asemenea c acesta tie i dimensiunea vectorului. n acest caz devine vizibil o posibil strategie: copierea vectorului n mesaj i trimiterea lui pe server. Stubul server poate apela serverul cu un pointer la acest vector, chiar dac va avea o valoare numeric diferit dect al doilea parametru, provenind din primitiva read. Schimbrile pe care serverul le face folosind pointer-ul, afecteaz direct mesajul din stubul server. Cnd procesul server este complet, mesajul original poate fi trimis napoi la stub-ul client, care va trimite rezultatul n procesul client. Putem realiza o optimizare care ar face mecanismul de dou ori mai eficient. n cazul n care stub-ul cunoate dac buffer-ul este un parametru de intrare sau de ieire pentru server, una din copiile realizate ar putea fi eliminat. Dac vectorul este un input pentru server (ntr-un apel de scriere) nu este necesar copierea lui napoi. Trebuie s menionm, ns, c dei putem manevra referine ctre vectori sau structuri de complexitate redus, nu putem gestiona transmiterea cazului de referin cel mai general, ctre o structur oarecare. Din ceea ce am prezentat anterior, este clar c ascunderea apelului unei proceduri la distan necesit ca att apelantul ct i apelatul s se neleag asupra formatului mesajelor pe care le schimb i s urmeze aceiai pai indiferent dac este vorba transmiterii unui parametru simplu sau a unei structuri complexe de date. Cu alte cuvinte, ambele pri n contextul RPC ar trebui s urmeze acelai protocol. Indiferent dac este vorba despre comunicarea prin mesaje sau cea folosind apelul procedurilor, putem afirma c procesul comunicrii reprezint o parte component a nucleului tehnologiilor distribuite. Problema care se pune, n cazul dezvoltrii sistemelor pentru managementul cunotinelor, este dac modul actual de realizare a comunicrii acoper necesitile acestor sisteme. Este dificil de oferit un rspuns la aceast ntrebare, n contextul n care mediul economico-tehnologic nu a standardizat, nc, conceptul de sistem pentru managementul cunotinelor. Cu toate acestea, aa cum vom observa n subcapitolul urmtor, o mare parte a situaiilor implicate de managementul cunotinelor poate fi susinut prin tehnicile de comunicare existente. n continuare, ne propunem s ptrundem n lumea tehnologiilor distribuite, lume reprezentat print-o miriad de posibile arhitecturi, pentru a nelege i prezenta diferite moduri prin care acestea pot fi aplicate managementului cunotinelor economice.

8. Arhitecturi de calcul orientate spre servicii Definiii ale arhitecturii SOA Open Group Stil architectural, care susine dezvoltarea software bazat pe servicii

OASIS SOA reprezint o paradigm pentru organizarea i utilizarea unor resurse distribuite. Definiia OASIS include i un model de referin, care formalizeaz detaliile definiiei. OMG SOA reprezint un stil arhitectural, dedicat unei comuniti de furnizori i consumatori de servicii, cu ajutorul cruia poate fi generat valoare de ambele pri. n plus, OMG specific faptul c SOA permite independena tehnic ntre membrii comunitii, specificnd standardele la care membrii trebuie s adere W3C SOA reprezint o form arhitectural pentru un system distribuit, caracterizat prin urmtoarele caracteristice: existena unei perspective logic, orientare spre comunicarea prin mesaje, structur descriptiv i granular, independen fa de platform XML.com SOA reprezint un stil architectural, al crui scop este construirea sistemelor caracterizate prin legturi slabe ntre ageni software. Un serviciu reprezint o component software, realizat de ctre un furnizor, cu ajutorul creia, consumatorul poate obine o mulime de rezultate JavaWorld.com SOA reprezint evoluia calculului distribuit, fundamentat pe paradigma cerere/rspuns, n cazul aplicaiilor sincrone i asincrone. Kodali [Kodali, 2005] descrie patru caracteristici SOA: ezentate de fiiere XSD, ar trebui s fie folosite pentru tehnicile de tip messaging;

IBM SOA descrie un stil architectural, care privete componenta software sub forma unei mulimi de servicii Conform acestor definiii, conceptul SOA este privit drept un mod de a construi structura informaional-tehnologic a unei organizaii. Prin urmare, SOA nu poate fi abordat ca o tehnologie; mai degrab, reprezint un mod de structurare i aranjare a altor tehnologii, n vederea ndeplinirii unor sarcini clar definite. De asemenea, multe dintre definiii indic faptul c este de preferat ca legturile care se stabilesc ntre module s fie slabe85 i nu puternice86, ceea ce nseamn c dependena ntre module va fi minimal. Aceast cerin este necesar pentru a permite configurarea serviciilor pe baza nevoilor i nu conform unor structuri predeterminate. Dezavantajul acestei abordri l reprezint multitudinea de definiii i abordri ale implementrilor SOA.

Conform lui Krafzig [Krafzig, 2005], cele mai importante caracteristici, care ar trebui s fie incluse n definiiile formale ale SOA, pot fi incluse ntr-un cadru, care s permit o abordare standardizat. Cadrul propus de Krafzig, prezentat n figura 2.13 include: o Metadate: folosite pentru descrierea celor mai importante caracteristici SOA; o Modul de aranjare al caracteristicilor SOA; o Locaia serviciilor

9. Agenti inteligenti Jennings [Jennings, 1998] descrie agenii inteligeni ca fiind o nou paradigm pentru dezvoltarea software-ului aplicaie. O definiie a agenilor inteligeni este cea prezentat de Russel i Norwig [Russel, 2003], n care un agent inteligent reprezint o entitate, care poate percepe, prin senzori, mediul n care exist i care acioneaz asupra mediului prin efectori. Conform Barbara H.[Barbara, 1995], agenii inteligeni realizeaz trei funcii n mod continuu: rii percepiilor. Aceast definiie este asemntoare cu cea din [Russel, 2003], cu excepia faptului c include raionamente i interpretarea percepiilor, ceea ce necesit ca un agent s aib un anumit nivel de inteligen. n plus, putem considera un agent ca fiind o entitate software, care funcioneaz continuu i autonom ntr-un mediu, care este adesea populat de ali ageni i procese. Spre exemplu, conform Wooldridge i Jennings [Woolridge, 1995], termenul agent reflect o component software care posed urmtoarele proprieti: o Autonomie: agenii interacioneaz fr intervenia direct a oamenilor i au control parial sau total asupra propriilor aciuni; o Abilitate social: agenii pot interaciona cu ali ageni, prin intermediul unor limbaje speciale; o Reactivitate: agenii pot percepe propriul mediu i efectua schimbri n el; o Pro-activitate: agenii nu acioneaz doar ca un rspuns la mediul n care se afl. Ei pot manifesta un comportament orientat spre ndeplinirea unor sarcini precise, lund iniiative. O alt definiie a agenilor inteligeni, din perspectiva proprietilor acestora, este regsit n Gilbert [Gilbert et al., 1995], unde autorii descriu agentul inteligent n contextul unui spaiu definit prin trei dimensiuni: Gradul de autonomie i de autoritate: reprezint o dimensiune care poate fi msurat calitativ, n urma interaciunii dintre agent i alte entiti din sistem; Inteligen: este reprezentat de complexitatea raionamentelor agentului, cu alte cuvinte de abilitatea agentului de a accepta i nelege dorinele utilizatorului i de a ndeplini sarcinile asociate. Pe nivelul cel mai nalt, lund ca punct de reper inteligena, regsim acele sisteme care nva i se adapteaz la mediul n care se gsesc, att din punct de vedere al obiectivelor utilizatorului, ct i al resurselor disponibile; Mobilitate: se refer la uurina cu care agenii pot circula n reea. Spre exemplu, obiectele mobile sunt transportate ntre maini, purtnd cu ele informaiile de stare, pe care le-au acumulat.

ntr-un alt caz, Nwana [Nwana, 1996] descrie diferitele tipuri de ageni, lund n considerare trei dimensiuni: cooperare, nvare, operare autonom. Din intersecia acestor dimensiuni, se pot obine diferite tipuri de ageni, precum: ageni colaborativi, ageni interfa, ageni colaborativi de nvare, respectiv ageni inteligeni. Definitii Orice entitate care poate percepe propriul mediu i care acioneaz asupra lui Sisteme computaionale care se regsesc n medii dinamice, complexe i care pot simi i aciona autonom pentru ndeplinirea unor sarcini Component software sau hardware, care este capabil s acioneze n numele unui utilizator, n vederea ndeplinirii unor sarcini. Entitate a crei stare este format din componente mentale, precum: credine, capaciti, alegeri. Agentul autonom reprezint un sistem, care face pt dintr-un mediu , mediu pe care-l poate percepe i folosi. Sistem care face dintr-un mediu, capabil de aciuni autonome n vederea satisfacerii propriilor obiective Reprezint o entitate software, avnd propria stare, propriul comportament, precum i abilitatea de a interaciona i comunica cu alte entiti: oameni, ageni, sisteme.

n ceea ce privete susinerea managementul cunotinelor economice, Ludger [Ludger, 2003] propune trei dimensiuni pentru descrierea sistemelor bazate pe ageni: Proiectarea i dezvoltarea sistemic: ingineria software ar putea beneficia de utilizarea tehnologiei agent n proiectarea i implementarea sistemelor informaionale complexe, care conin mai multe componente distincte i independente. Agenii permit, de asemenea, agregarea diferitelor funcionaliti, precum planificarea, nvarea, respectiv coordonarea. Structura sistemelor agent: se refer la societile de ageni, arhitecturi i limbaje. Pe acest nivel, ntrebrile cele mai frecvente sunt de forma: De ci ageni avem nevoie, ce tipuri de ageni, care este topologia referitoare la fluxul informaional i sincronizarea deciziilor; Zone de aplicabilitate: Zonele de aplicabilitate, specifice managementului cunotinelor se refer la funcionalitatea, pe care agenii trebuie s o implementeze. Considerm c, din punctul de vedere al managementului cunotinelor, domeniu fundamentat pe existena unei perspective organizaionale coerente, structura sistemelor agent reprezint dimensiunea cu impactul cel mai puternic asupra modalitilor de proiectare, dezvoltare i implementare ale unui SMC. Astfel, prezentm n tabelul 2.12 o sintez referitoare la principale instrumente agent, specifice dimensiunii structur, regsite n literatura de specialitate: - Arhitectura un singur agent. Exemplele cele mai ntlnite sunt reprezentate de agenii responsabili cu interfeele utilizator, respectiv agenii informaionali. Agenii pentru interfa colaboreaz cu utilizatorul n acelai mediu, n timp ce agenii informaionali sunt legai de o surs de date - Abordri omogene multi agent. Arhitecturi formate dintr-un numr oarecare de ageni, aparinnd aceleiai clase, care interacioneaz pentru rezolvarea unei probleme. n contextul acestei abordri, agenii coopereaz, nefiind necesar ca ei s aib acelai scop, cu toate c sarcinile i capacitile lor sunt adesea comparabile

Abordri eterogene multi agent. Numr mare de ageni din diferite clase, interacionnd pentru rezolvarea problemelor. Aceti ageni au obiective, capaciti i caracteristici sociale diferite. Aceast abordare nu prespune ca agenii s colaboreze, fiind posibil existena n sistem a agenilor necooperativi.