1.

Caracteristici fundamentale ale sistemelor ditribuite Definitii: Un sistem distribuit reprezinta a) acel sistem n care componentele, localizate n cadrul reelelor de calculatoare, comunic i i coordoneaz aciunile doar prin transmiterea de mesaje. b) 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 . 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. 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 fizic ct i logic: protecie mpotriva coruperii datelor sau a distrugerilor fizice disponibilitate - protecie pentru pstrarea modurilor de acces la resurse. 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 detective, de mascare a erorilor, de tolerare a erorilor, de tolerare, de redundanta. 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. Au fost identificate 8 forme de transparen: transparena accesului - permite resurselor locale 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. 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. Modelul client-server reprezint arhitectura cea mai important i rmne 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. 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. 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.

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

3. Arhitectura Grid 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. 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. Studiul realizat n continuare prezint trei generaii de portaluri grid. Prima generaie de portaluri grid: Majoritatea portalurilor grid utilizate n prezent fac parte din aceast categorie. 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; atorii realizeaz conexiuni sigure cu serverele web; utilizatorul; resc s o execute, web serverul lanseaz un manager de aplicaii. Managerul de aplicaii este reprezentat printr-un proces care controleaz i monitorizeaz execuia sarcinilor; zatorului. Serviciile furnizate de prima generaie de portaluri grid: autentificare si auorizare, managementul sarcinilor, transfer de date, servicii de informare. Portaluri grid din a doua generaie: Pentru a suplini problemele specifice primei generaii, portalurile grid din a doua generaie folosesc componentele denumite portlet. 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. . 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. 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. Gridul semantic poate fi divizat pe patru nivele: computational, de date, informational, al cunoasterii. 4. Arhitecturile de tip cloud 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: -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. 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 date 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. 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. 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. 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: sistarea rezolvrii problemelor; r de tip business inteligence; 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. 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 5 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 situate un utilizator reprezint un element important n definirea produselor i serviciilor relevante. n plus fa de aceste attribute, dezvoltarea calcului mobil este susinut de o serie de factori suplimentari, respectiv: - Larga disponibilitate a dispozitivelor mobile :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. - Cultura telefoanelor celulare : telefoanele celulare reprezint un fenomen social. - 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 e 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. 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. 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. Se 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 exista 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. 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 mecanism 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. 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

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

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. Sunt descrise patru caracteristici SOA: pentru tehnicile de tip messaging; tip UDDI conine lista serviciilor furnizate; 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 slabe i nu puternice, 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. 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. Acesta include: o Metadate: folosite pentru descrierea celor mai importante caracteristici SOA; o Modul de aranjare al caracteristicilor SOA; o Locaia serviciilor