SISTEME DISTRIBUITE

Lect. Dr. Cristea Dragos

2

Cuprins 2.1 Abordare distribuit a managementului cunotinelor economice ............................... 4

2.1.1 Rolul mecanismelor informale pentru managementul distribuit de cunotine............. 9

2.1.2 Model arhitectural pentru managementul distribuit de cunotine .............................. 13

2.2 Sisteme distribuite, caracteristici i concepte fundamentale ....................................... 17

2.2.1 Caracteristici fundamentale ale sistemelor distribuite ................................................ 18

2.2.2 Paradigma comunicrii n sistemele distribuite .......................................................... 25

2.2.2.1 Comunicarea prin mesaje ..................................................................................... 26

2.2.2.2 Apelul procedurilor la distanta ................................................................................. 29

2.3 Arhitecturi distribuite aplicabile managementului cunotinelor economice ............ 31

2.3.1 Arhitectura client-server i variaii ale acesteia ....................................................... 31

2.3.1.1 Arhitectura client-server i managementul cunotinelor economice ................... 36

2.3.2 Arhitectura Grid .......................................................................................................... 40

2.3.2.1 Arhitectura grid i managementul cunotinelor economice ................................ 50

2.3.3 Arhitecturile de tip cloud i managementul cunotinelor economice................... 52

2.3.4 Agenii inteligeni i managementul cunotinelor economice ................................... 58

2.3.4.1 Construirea unui sistem pentru managementul cunotinelor folosind o abordare multi-agent ........................................................................................................................ 65

2.3.5 Calculul mobil i managementul cunotinelor economice......................................... 68

2.3.6 Arhitecturi de calcul omniprezente ............................................................................. 73

2.3.6.1 Arhitecturi omniprezente de calcul i managementul cunotinelor economice .. 75

2.3.7 Arhitecturi de calcul orientate spre servicii................................................................. 81

Concluzii .............................................................................................................................. 87

3

TEHNOLOGII DISTRIBUITE I MANAGEMENTUL CUNOTINELOR ECONOMICE

Cea mai bun cale de a prezice viitorul este s-l implementm. David Heinemeier

Al doilea capitol, intitulat Tehnologii distribuite i managementul cunotinelor economice reia ipoteza menionat la finalul primului capitol, conform creia dezvoltarea accelerat a tehnologiilor distribuite face posibil, n prezent, abordarea managementului cunotinelor dintr-o perspectiv distribuit.

Astfel, ne propunem, ca pe parcursul acestui capitol, s abordm problematica utilizrii sistemelor distribuite n contextul managementului cunotinelor. Mai mult, vom ncerca s demonstrm, att prin studiul literaturii de specialitate, ct i prin exemple proprii, faptul c dezvoltarea unui sistem pentru managementul cunotinelor, poate fi realizat optim, doar dac sunt folosite tehnologii, respectiv arhitecturi distribuite.

n acest sens, analiza sistemelor distribuite va fi realizat lund n considerare dou perspective:

Organizaional: n acest context, cercetarea referitoare la managementul distribuit al cunotinelor

va ncerca s rspund unor ntrebri, precum: o Ce nseamn, din punctul de vedere al structurii organizaionale, utilizarea arhitecturilor

distribuite? o Ce implicaii organizaionale exist, n contextul utilizrii sistemelor pentru managementul

cunotinelor? o Care este rolul mecanismelor informale n definirea soluiilor distribuite pentru

managementul cunotinelor? o Exist roluri specifice, generate de orientarea spre arhitecturi distribuite?

Tehnologic: Perspectiva tehnologic va fi abordat, n vederea determinrii conceptelor fundamentale ale sistemelor distribuite, precum i a caracteristicilor acestora. Considerm util definirea acestei perspective, deoarece, att proiectarea, ct mai ales implementarea optim a unui sistem distribuit pentru managementul cunotinelor depind de respectarea condiiilor impuse prin caracteristicile sistemelor distribuite.

Analiza arhitecturilor distribuite, conform celor dou perspective, reprezint o prima etap,

despre care putem afirma c este o etap conceptual, n vederea demonstrrii necesitii sistemelor distribuite pentru managementul cunotinelor.

n continuare, pornind de la premiza conform creia exist o legtur ntre managementul cunotinelor i sistemele distribuite, vom iniia a doua etap, al crui demers va fi acela de a sublinia caracteristicile i diferitele forme, pe care le poate lua aceast legtur.

Cu alte cuvinte, pe parcursul celei de-a doua etape, vom lua n considerare, analiza i prezenta diferite exemple, propuneri de modele, viziuni i scenarii posibile, aferente principalelor tehnologii distribuite, existente n prezent. Prin realizarea acestui plan, considerm c vom reui, n final, s delimitm i s nelegem relaia polivalent existent ntre sistemele distribuite i managementul cunotinelor economice.

4

2.1 Abordare distribuit a managementului cunotinelor economice

Ultimii ani au adus o schimbare a paradigmei socio-economice, n sensul n care capitalul i munca nu mai reprezint fundamentul managementului competitiv. n prezent, organizaiile depind, ntr-o mare msur, de capacitatea identificrii i utilizrii cunoaterii pe care o dein. Prin urmare, managementul cunotinelor a atras atenia multor organizaii, promind succes competitiv n noul mediu economic, aa cum subliniaz Bolloju [Bolloju, 2002].

Cu toate c exist recunoaterea economic a managementului cunotinelor, managerii se regsesc, adesea, n situaia n care nu pot identifica locurile unde se gsete cunoaterea i cum poate fi folosit aceasta pentru a deveni o organizaie a cunoaterii - Desouza [Desouza, 2003]. Aceast situaie poate aprea, mai ales, atunci cnd activitile specifice managementului cunotinelor sunt realizate nestructurat. Lipsa abordrii structurate denot o nelegere minimal a conceptelor MC i a activitilor pe care acestea le implic.

n vederea rezolvrii problemelor referitoare la structura iniiativei MC, cercettorii au propus o multitudine de modele, sintetizate n 1.4.1.1 1.4.1.7, pe care Holsapple [Holsapple, 1999] le-a clasificat n dou categorii:

Descriptive (exemplu: Wiig, Choo), care ncearc s caracterizeze natura fenomenelor

MC; Prescriptive (exemplu: Nonaka), care prezint metodologii de urmat pentru

implementarea managementului cunotinelor Pornind de la faptul c fiecare model MC subliniaz diferite aspecte i dimensiuni ale

managementului cunotinelor, am ncercat, n subcapitolul 1.4.2, s integrm elementele specifice modelelor prezentate ntr-un model MC integrativ i descriptiv. Aa cum se poate observa, modelul prezentat n figura 1.24 nu definete posibile metodologii de lucru. Am ales abordarea descriptiv, plecnd de la premiza conform creia orice program de management al cunotinelor trebuie s poat fi descris printr-un cadru conceptual larg, pe baza cruia s putem defini ulterior subcomponente i metodologii.

Cadrul conceptual al managementului cunotinelor reprezint un element necesar, dar n nici un caz suficient dezvoltrii unei iniiative MC. Astfel, o alt component, de asemenea important a programului MC, este reprezentat prin sistemul de management al cunotinelor. Pentru abordarea SMC, am considerat util folosirea unor modele arhitecturale, preponderent prescriptive - vezi tabel 1.23 - cu scopul de a oferi un punct de vedere concret asupra modului n care componenta tehnologic poate fi utilizat efectiv n dezvoltarea unui sistem pentru managementul cunotinelor - vezi figura 1.42.

Sfritul primului capitol a adus n discuie o problem arhitectural important, anume, posibilitatea construirii sistemelor pentru managementul cunotinelor folosind arhitecturi tehnologice centralizate sau distribuite. ntrebarea ce se nate poate fi formulat astfel: care tipologie arhitectural trebuie s fie folosit pentru dezvoltarea SMC?

Abordarea distribuit a managementului cunotinelor economice ncearc s suplineasc probleme specifice soluiilor MC tradiionale, cum ar fi: crearea unei structuri unice de cunotine, care nu permite autonomia unitilor organizaionale i, respectiv, existena unor scheme conceptuale diferite, reflectnd puncte diferite de vedere.

Potrivit lui Bonifacio [Bonifacio et al, 2002], aceast abordare arhitectural ia n considerare eterogenitatea elementelor cunoaterii i consider organizaiile complexe, orientate spre cunoatere, drept constelaii de uniti organizaionale, care gestioneaz cunotinele n moduri autonome i pe care le schimb ntre ele, prin intermediul proceselor de transfer i coordonare.

5

O mare parte a sistemelor pentru managementul cunotinelor au ca scop crearea depozitelor omogene de cunotine de mari dimensiuni, n care cunoaterea organizaional s poat fi unificat, reprezentat i organizat, conform unei scheme unice de reprezentare, partajat de membrii companiei. Rezultatul cel mai ntlnit al dezvoltrii unui SMC const n crearea unui portal de cunotine i a unei interfee, prin care se asigur punctul de acces la cunoaterea organizaional. Davenport [Davenport et al., 1998] i Borghoff [Borghoff, Pareschi, 1999] subliniaz faptul c, dac utilizatorii au profiluri diferite, reprezentarea intern a portalului de cunotine rmne neschimbat, reflectnd o reprezentare comun a cunoaterii organizaionale, care permite comunicarea i partajarea cunotinelor n ntreaga companie.

Bonifacio [Bonifacio et al., 2000], [Bonifacio et al., 2002] prezint abordarea distribuit drept o alternativ posibil pentru construirea unui SMC. Aceast abordare este fundamentat pe ipoteza, adoptat i de noi n subcapitolul 1.6, conform creia SMC-urile tradiionale sunt incompatibile cu natura a ceea ce au de gestionat (cunoatere/cunotine).

Perspectiva distribuit asupra SMC ia n considerare aspectele subiective i sociale ale cunoaterii, dificil de ncadrat ntr-o conceptualizare comun, unic i partajabil [Ghidini, 2001], [Benerecetti et al., 2000], [Dinsmore, 1991], mpreun cu rezultatul interaciunilor sociale din interiorul unitilor organizaionale [Wenger, 1998].

n opinia lui [Argyris, 1999] i [Boland, 1995], utilizarea arhitecturilor distribuite n managementul cunotinelor se bazeaz pe dou principii importante, i anume:

Principiul autonomiei, care garanteaz unitilor organizaionale un nivel ridicat de

autonomie semantic n gestiunea cunotinelor locale; Principiul coordonrii, care permite schimbul liber de cunotine ntre diferite uniti.

Sistemele pentru managementul cunotinelor, construite pe aceste principii, ar trebui

s poat susine crearea i gestiunea diferitelor scheme conceptuale, care coexist ntr-un SDMC1.

n cazul n care am fi nevoii s punctm acel element sau proces, ce definete cel mai bine necesitatea abordrii distribuite a managementului cunotinelor, apreciem c acesta poate fi reprezentat de procesul partajrii cunoaterii.

Alavi [Alavi, 2000] subliniaz c importana partajrii este determinat de faptul c simpla creare a cunoaterii nu conduce, n mod direct, la performane organizaionale superioare. Companiile trebuie s creeze valoare prin utilizarea cunoaterii, iar aceasta nu poate fi utilizat, dect dac este partajat. Partajarea cunoaterii are loc atunci cnd cunotinele sunt difuzate de la o entitate la alta. Provocrile aduse de acest proces se refer, n principal, la tipurile de cunotine, necesar a fi partajate, precum i la incapacitatea de a localiza i accesa sursele necesare de cunotine [Alavi, 2000].

Malone [Malone, 2002] argumenteaz, la rndul lui, c procesul de partajare a cunotinelor trebuie s se realizeze ntre domeniile de cunoatere existente n organizaie. Dup acesta, un domeniu de cunoatere definete un domeniu de practic, pe care o comunitate i propune s-l nvee, el putnd exista att n interiorul companiei, ct i n afara acesteia.

Prin urmare, fiecare angajat va obine cunoaterea necesar, direct sau indirect, din diferitele domeniile de cunoatere. De asemenea, Malone subliniaz faptul c filtrarea cunotinelor din DC2 se realizeaz att de ctre comunitile orientate spre cunoatere, ct i de comunitile de practic.

1 SDMC: Sistem Distribuit pentru Managementul Cunotinelor 2 DC: Domeniu Cunoatere

6

Potrivit lui Lacontora [Lacontora, 2003], o comunitate de practic reprezint un sistem tehnico-social, care furnizeaz mijloacele producerii i partajrii cunotinelor ntre angajaii cu aceeai profesie. Dei, att comunitile de practic, ct i comunitile orientate spre cunoatere, sunt comuniti aparinnd aceleiai organizaii, Malone [Malone, 2002] identific dou caracteristici principale, care le difereniaz, i anume:

Organizaia i asum responsabilitatea pentru stabilirea domeniilor de interes i formarea

comunitilor orientate spre cunoatere. Contrar, comunitile de practic se formeaz organic spontan, ca rspuns la interesele organizaionale din interiorul companiei;

Direciile i obiectivele comunitilor orientate spre cunoatere nu sunt foarte clar definite. Dei organizaia stabilete i susine aceste comuniti, ele nu au scopuri clar definite, n afar de extinderea gndirii angajailor, conform unor anumite zone de interes.

n opinia lui Pan [Pan, 2003], importana acestor comuniti provine din imposibilitatea separrii cunoaterii de un context specific. n toate tipurile de activiti bazate pe cunoatere, chiar i n contextul n care tehnologia este folosit intensiv, att persoanele care dein cunoatere, ct i cele care doresc a o regsi, necesit un mediu comun, care s ofere posibilitatea partajrii conversaiilor, experimentelor, experienelor, procedurilor de lucru, etc.

Una dintre provocrile oricrei iniiative ce privete managementul cunotinelor const n identificarea unui mod de a conecta comunitile sus-menionate.

Majoritatea proiectelor pentru managementul cunotinelor utilizeaz, pentru abordarea acestei probleme, soluii ce implic crearea unor depozite centralizate de cunotine. Astfel, cunoaterea este colectat, reprezentat i organizat, conform unei singure scheme conceptuale. O astfel de schem are drept scop conceptualizarea cunoaterii organizaionale, permind comunicarea i diseminarea cunotinelor, pe toate nivelurile organizaionale.

Rezultatul acestui mod de conectare a comunitilor organizaionale const n crearea unui portal organizaional, care furnizeaz un singur punct de acces la cunoaterea organizaional. Aceast modalitate de abordare a iniiativelor pentru managementul cunotinelor presupune c toate aspectele contextuale, subiective i sociale ale cunoaterii pot fi eliminate n favoarea unei codificri obiective, generale, cunoaterea putnd fi partajat i refolosit, n mod independent fa de angajai sau de unitile organizaionale n care a fost creat.

Aceast presupunere, dei coerent n contextul modelelor organizaionale tradiionale, este incompatibil cu multe teorii ale cunoaterii, n care aspectele subiective i sociale reprezint caracteristici eseniale.

Astfel, Bonifacio [Bonifacio, 2002] propune o abordare diferit, denumit managementul distribuit al cunotinelor, n care componenta social, subiectiv este privit drept o surs de valoare i nu o potenial problem.

n modelul Bonifacio, organizaia este modelat sub forma unei constelaii format din noduri de cunotine, situaie ce presupune gestiunea local (la nivelul fiecrui nod) a surselor de cunotine. Astfel, un sistem pentru managementul cunotinelor economice devine un instrument, care trebuie s susin dou procese diferite, i anume:

Gestiunea local a cunotinelor produse ntr-un singur nod de cunoatere (principiul

autonomiei); Coordonarea diferitelor noduri de cunotine, n absena unei semantici central definite

(principiul coordonrii).

7

Conform lui Bowker [Bowker, 1999], majoritatea proiectelor pentru managementul cunotinelor prezint un model comun, care implic urmtoarele etape:

Instalarea intraneturilor organizaionale, care asigur accesibilitatea fizic la informaie; Proiectarea unui limbaj organizaional i a hrilor de cunotine, care sunt folosite pentru

reprezentarea standardizat a cunoaterii organizaionale; Construirea depozitelor de cunotine, omogene din punct de vedere semantic i

independente de context; Crearea i susinerea comunitilor neformale, care reprezint locul unde se nasc primele

forme de cunoatere, acest proces realizndu-se prin interaciuni spontane, sociale ale angajailor din acelai domeniu. Aceste comuniti sunt denumite comuniti virtuale, ele folosind instrumente tehnologice de comunicare, precum sisteme groupware;

Definirea unui nou rol organizaional, managerul de cunotine, al crui scop este de a susine i facilita interaciunile din interiorul unitilor organizaionale;

Proiectarea unor procese care s permit membrilor fiecrei comuniti s converteasc propria cunoaterea din tacit spre explicit, folosind elemente de codificare oferite de limbajul organizaional;

Construirea portalului organizaional de cunotine, care furnizeaz o interfa unic, uor accesibil, prin care angajaii pot contribui la baza de cunotine, socializa i extrage informaie.

Conceptual, parcurgerea acestor etape poate conduce la realizarea unui cadru

pentru managementul cunotinelor, precum cel pe care l propunem n figura 2.1:

Figura 2.1: Cadru pentru managementul distribuit al cunotinelor

Sursa: adaptare dup Bonifacio [Bonifacio, 2002] Cadrul arhitectural prezentat n figura 2.1 se bazeaz pe tehnologii, precum cele

analizate n capitolul 1.5.2.1.3. Potrivit lui Orlikowski [Orlikowski, 1994], situaia cea mai ntlnit este aceea n care tehnologiile de tip content management systems sunt folosite pentru definirea unei viziuni partajate a ntregii colecii de documente organizaionale, avnd drept scop rezolvarea problemelor induse de eterogenitatea documentelor.

Cu toate c productorii software afirm c abordarea prezentat anterior este rspunsul la nevoile organizaiilor de a gestiona cunotine, introducerea sistemelor pentru managementul cunotinelor ntmpin o rezisten mare din parte angajailor.

8

Conform lui Bonifacio [Bonifacio, 2002], consecina acestei situaii este faptul c angajaii continu s produc i s partajeze cunotine ntr-o manier tradiional, adic prin structuri de relaii i procese, care sunt, adesea, diferite de cele nglobate n SMC-uri.

Bonifacio argumenteaz c aceast situaie nu i are originea n problemele tehnologice, ci n modelul epistemologic inadecvat, care este coerent cu paradigma clasic a controlului managerial, dar n contradicie cu natura cunoaterii. Prin urmare, majoritatea SMC sunt proiectate conform viziunii n care cunoaterea poate fi reprezentat ntr-o form obiectiv, independent de elemente contextuale, subiective.

Un numr mare de cercettori, abordnd domenii diferite, se opun acestei perspective. Argumentul fundamental al acestora const n definirea cunoaterii drept fiind mai mult dect o simpl imagine n oglind a realitii, deoarece, ntotdeauna va exista nevoia anumitor interpretri. Prin urmare, ceea ce numim cunotine, vor face parte cu adevrat din corpul cunoaterii dac exist o schem, care s ne permit o interpretare; diferite scheme vor genera interpretri diferite ale acelorai cunotine.

Acest aspect al cunoaterii a fost studiat din diferite perspective, astfel: Natura cognitiv a schemelor de reprezentare, unde prin schem de reprezentare putem

nelege: o Viziunea unui angajat asupra realitii organizaionale, potrivit lui McCarthy [McCarthy,

1993], Bouquet [Bouquet, 2002] i Ghidini[Ghidini, 2001]; o Spaiu mintal, potrivit lui Fauconnier [Fauconnier, 1985]; o Reprezentare partiionat, potrivit lui Dinsmore [Dinsmore, 1991].

Natura social a schemelor de reprezentare, schemele de reprezentare fiind n acest caz, forme speciale de acorduri formate n interiorul comunitilor Kuhn [Kuhn, 1979], Goffamn [Goffamn, 1974], Dougherty [Dougherty, 1992]

n opinia lui Bonifacio [Bonifacio et al, 2000], indiferent de perspectiva aleas,

abordarea epistemologic a cunoaterii conduce la dou consecine importante, ambele referindu-se la dezvoltarea sistemelor pentru managementul cunotinelor:

Proiectarea SMC, bazat pe organizarea cunoaterii organizaionale cu scopul oferirii

unei viziuni globale, poate conduce la introducerea forat a unei scheme privilegiate aceea a CKO n rndul unor angajai, care nu o neleg sau nu sunt de acord cu aceasta;

Orice abordare privind proiectarea unui SMC, care nu ine cont de pluralismul schemelor de interpretare, va conduce la un rezultat pe care angajaii l vor considera irelevant sau opresiv.

Prin urmare, potrivit lui Benerecetti [Benerecetti, 2000], conceptul de cunoatere

absolut, care se refer la definirea unei imagini ideale i obiective a organizaiei, poate fi nlocuit prin conceptul de cunoatere local. Cu alte cuvinte, cunoaterea local se refer la interpretri i perspective diferite, pariale sau aproximative, asupra organizaiei. Interpretrile sunt generate de angajai, att individual ct i n contextul unor grupuri, prin intermediul unor procese de negociere, al cror scop este obinerea unei scheme aprobat colectiv. Conform lui Boland [Boland, 1995] i Argyris [Argyris, 1999], cunoaterea local este definit n mod continuu de angajaii interesai n construirea unei perspective comune i care doresc s neleag modul n care viziuni diferite afecteaz mediul n care lucreaz. Cu alte cuvinte, n locul managementului cunoaterii cu caracter global, realizat prin intermediul SMC centralizate, cunoaterea poate fi gestionat la nivel local. Aceast abordare conduce la dezvoltarea unui sistem distribuit, care ofer posibilitatea de integrare a multitudinii schemelor de cunoatere existente n departamentele organizaiei.

9

2.1.1 Rolul mecanismelor informale pentru managementul distribuit de cunotine

Muli cercettori, precum Desouza, Cross, Teece sau Bartlett, acord o atenie din ce n ce mai mare managementului distribuit de cunotine. Conform lui Bartlett [Bartlett, 1989] i Nohira [Nohira, 1997], clienii, folosind Internetul i echipamentele de calcul mobile, pot accesa aproape orice produs i serviciu, ntr-un mod ieftin, rapid i nengrdit.

Potrivit lui Jarvenpaa [Jarvenpaa, 2002], n acest context, n prezent, o organizaie nu mai poate aciona drept o entitate individual. Ea trebuie s defineasc i s creeze reele strategice, care s uneasc clienii, partenerii i furnizorii, muli dintre acetia fiind localizai n diferite ri, posibil pe continente diferite.

O consecin a acestei situaii este faptul c organizaiile trebuie s-i utilizeze eficient resursele de cunotine n vederea dezvoltrii competitivitii pe pia - Teece [Teece, 1998] vezi capitol 1.3.2.

Putem afirma c, pn n prezent, n cele mai multe dintre cazuri, managementul cunotinelor a fost limitat la utilizarea mecanismelor organizaionale formale. n acest sens, Davenport [Davenport, 1998] identific opt factori cheie pentru succesul iniiativelor viznd managementul cunotinelor, dup cum urmeaz:

Definirea unei legturi clare cu valoarea economic; Infrastructur tehnologic i organizaional; Cultur; Limbaj; Motivare; Transfer de cunotine; Susinere din partea nivelului managerial.

Cu toate acestea, cunoaterea nu se regsete ntotdeauna n domenii gestionate

exclusiv de mecanisme formale. Cross [Cross et al, 2002] subliniaz c, n multe cazuri, cunotinele sunt partajate prin mecanisme informale, precum relaiile sociale dintre angajai. Rolul reelelor informale n medii organizaionale distribuite se refer, n principal, la identificarea i diseminarea cunotinelor.

Spre exemplu, Desouza [Desouza, 2003a], [Desouza, 2003b] a studiat rolul spaiilor sociale3 n susinerea schimbului de cunotine. Studiul a relevat faptul c folosirea comunicrii informale are efect asupra schimburilor de cunotine. De asemenea, Nonaka i Takeuchi [Nonaka, 1995] au studiat procesul socializrii n cadrul a diferite companii japoneze vezi capitol 1.4.1.5 i au ajuns la concluzia c socializarea contribuie semnificativ la mbuntirea proceselor de creare i partajare a cunotinelor.

Potrivit lui Nohria [Nohria, 2002], reelele informale sunt compuse din relaiile sociale i personale dintre angajai. Persoanele implicate n aceste reele au asociate diferite roluri, precum: conector central, conector inter-reele, puni i experi.

Un aspect interesant l gsim n cercetarea realizat de Cross [Cross et al, 2001] care, n urma unui interviu luat unui numr de 60 manageri, constat c 40 dintre acetia au indicat faptul c primesc informaii valoroase, provenind de la ali oameni, mult mai frecvent dect din surse impersonale.

O situaie similar managementului distribuit de cunotine este studiat de Evaristo [Evaristo, 2003], care a analizat conceptul de distributivitate, ns n contextul managementului de proiecte, identificnd ase dimensiuni care definesc distributivitatea: distana, ncrederea, nivelul dispersiei, sincronicitatea, expertiza i tehnologia. 3 Conceptul de spaiu social este ntlnit n literatura de specialitate i sub denumirea de game room

10

Privind, ns, din punctul de vedere al managementului cunotinelor, considerm c dintre acestea, dimensiunile definitorii pentru distributivitatea sistemic sunt urmtoarele:

Dispersia geografic, care indic existena unei distane fizice ntre angajai; Diferenele de expertiz, care indic existena unei distane profesionale ntre angajai,

diferen subliniat prin diferitele grade de internalizare a cunoaterii vezi 1.4.1.3.

Conform lui Evaristo, dispersia geografic poate avea dou forme: local sau global. Dispersia local se refer la faptul c angajaii au un loc de munc comun, interaciunea fiind uoar i frecvent, n timp ce n cazul dispersiei globale, interaciunea este aproape imposibil, fiind mpiedicat i de aspecte precum: timpii diferii, diferenele culturale sau limbaje eterogene. Diferenele de expertiz prezint o stare dihotomic. Astfel, cunoaterea poate fi omogen, omogenitatea acesteia fiind prezent n funciile organizaionale. Spre exemplu, un contabil din Bucureti va nelege aspectele financiare ale unei filiale din Frana. Prin urmare, chiar dac angajaii sunt separai prin distane geografice, cunoaterea pe care acetia o creeaz i utilizeaz are un caracter comun. Pe de alt parte, eterogenitatea cunoaterii se manifest frecvent n funciile organizaionale ale unei companii mari. n opinia lui Evaristo, creterea dimensiunii unei companii conduce implicit la creterea gradului de eterogenitate a cunoaterii.

Astfel, spre exemplu, exist situaia n care un contabil care lucreaz n Bucureti nu va nelege situaii care implic:

Aspectele financiare privind situaia contabil a unei filiale din Boston; Aspectele referitoare la sistemul tehnologic, care deservete departamentul de

contabilitate local.

Dimensiunile prezentate anterior definesc, conceptual, rolul esenial al sistemelor distribuite n managementul cunotinelor economice, anume, unificarea diferitelor reele organizaionale, att formale, ct i informale, avnd drept scop:

Suplinirea distanei ntre angajai, orict de mare ar fi aceasta, n procesele de creare, diseminare i utilizare a cunotinelor;

Stabilirea diferenelor de expertiz, crendu-se, astfel, la nivel organizaional un mediu orientat spre nvare vezi capitol 1.3.3.1

Muli cercettori au fost contieni de impactul reelelor informale asupra

managementului cunotinelor, aa cum este cazul lui Davenport [Davenport, 2000] i Hanson [Hanson, 1993].

Aa cum menionam anterior, reelele informale pot fi privite drept acele reele n care angajaii sunt interconectai mai mult pe baza relaiilor sociale i personale dect pe baza interaciunilor profesionale, generate n contextul diferitelor sarcini de lucru.

Dup prerea lui Hanson, reelele informale nu apar explicit n graficele i diagramele organizaionale, ele putnd fi ns ntlnite n aproape toate companiile.

Aceast categorie de reele este foarte dinamic i dificil de identificat. Angajaii sunt identificai drept noduri ale reelei, unitatea reelei fiind meninut prin intermediul legturilor dintre noduri.

n contextul celor prezentate anterior, dup Nohria [Nohria, 2002], Cross [Cross, 2002] i Kleiner [Kleiner, 2003], angajaii, reprezentnd nodurile unei reele informale, pot juca urmtoarele roluri:

11

Conectori centrali, reprezentai de angajaii care sunt frecvent contactai, de ali angajai. Au capacitatea de a identifica uor cunotinele locale dintr-un cadru local. Conectorii centrali pot nelege ceea ce i doresc angajaii care caut cunotine, cunoscnd pe acei angajai care pot furniza cunoaterea respectiv. Odat ce conectorii centrali identific ceea ce este cutat, ei realizeaz conexiunea ntre cel ce caut i cei care cunosc. De asemenea, un alt rol al conectorilor centrali este de a furniza scurtturi atunci cnd se pune problema folosirii unui sistem formal. Potrivit lui Cross [Cross, 2002], exemplul cel mai bun, de conector central, l reprezint managerii de departamente, care posed att cunotine, ct i o vast experien n propriul domeniu;

Conectori inter-reele, care, n opinia lui Tushman [Tushman, 1977] au scopul de a conecta reele informale diferite. Ei caut n permanen know-how de actualitate i posed o varietate de cunotine, care nu sunt restricionate de anumite expertize funcionale sau de mediul local, n care se regsesc. Davenport [Davenport, 2005] subliniaz c aceti angajai se regsesc adesea n programele de cercetare, prezeni la ct mai multe conferine, pentru a prezenta i a pune n practic idei noi. Cunotinele lor, specifice altor expertize, respectiv domenii, i ajut s comunice cu mai multe reele informale. De asemenea, conform Cross, conectorii inter-reele cunosc mai multe limbaje, fapt care i ajut s comunice uor.

Filtre, ce controleaz cunoaterea care intr sau iese dintr-o reea. Spre exemplu, angajatul, care gestioneaz un proces organizaional strategic, va controla fluxul informional i de cunotine, ntre acel proces i restul companiei - Kleiner [Kleiner, 2003]. Prin urmare, rolul filtrelor este de a proteja reelele informale de ameninri exterioare, prin filtrarea informaiei care nu este considerat necesar. Raider [Raider, 2003] a realizat un studiu referitor la modul n care bunurile intelectuale sunt folosite ntr-o companie de servicii. El a identificat prezena filtrelor, rolul acestora fiind de a asigura calitatea cunotinelor care circul ntre nodurile reelelor informale. Filtrele, ntocmai precum conectorii centrali, funcioneaz optim ntr-un context local i n prezena cunoaterii omogene;

Puni, cu rolul de a conecta angajaii care nu au aceleai competene i aceeai experien. Punile joac rolul translatorilor, care pot vorbi o varietate de limbaje i pot nelege cunotine provenind din contexte diferite. Conform lui Kleiner [Kleiner, 2003], un rol important al punilor este acela de a conecta oameni cu opinii diferite. Spre exemplu, un posibil conflict n grup poate aprea atunci cnd un inovator dorete s ncerce idei noi, n timp ce un conservator dorete refolosirea cunotinelor vechi. Acest tip de conflict se petrece, dat fiind c nu exist cunoaterea care s-i ajute s neleag punctul de vedere al fiecruia. Rolul punilor este acela de a suplini aceast problem, ele deinnd un volum mare de cunotine i excelente capaciti de comunicare.

Experii Conform lui Davenport [Davenport, 2007], experii sunt angajai care dein o vast cunoatere despre anumite tipuri de produse, servicii, procese. Cunotinele experilor sunt foarte valoroase pentru organizaie, deoarece sunt aproape imposibil de formalizat cu ajutorul unui instrument tehnologic. Experii exceleaz att n a nva din experien, ct i n a identifica, extrage i furniza ctre colegi cunotine importante.

Fluxul de cunotine organizaionale, realizat prin mecanisme informale distribuite,

prezint o dinamic accentuat, comparativ cu utilizarea mecanismelor formale. Potrivit cadrului prezentat de Katzy [Katzy, 2000], cele mai importante activiti MC, susinute prin mecanisme distribuite informale, sunt: agregarea cunoaterii, transferul cunotinelor i crearea sensului.

Fora relaiilor informale poate disprea uor, nodurile fiind importante pentru meninerea funcionrii reelei, prin funcionalitatea aferent, conform rolului jucat.

12

Pornind de la elementele descrise anterior, putem defini un set de caracteristici ale rolurilor jucate de angajai, ntr-un mediu informal, distribuit, anume:

Conectorii centrali au o calificare superioar, referitor la adunarea cunotinelor locale,

omogene Angajaii unui departament local se afl ntr-o permanent cutare de agregare a noilor cunotine, n vederea optimizrii procedurilor de lucru. Agregarea cunoaterii implic, ns, dou constrngeri. n primul rnd, este dificil a localiza noile cunotine, din moment ce sursa, n multe cazuri, nu este evident. n al doilea rnd, nici un angajat nu poate petrece un timp foarte ndelungat, n cutarea cunoaterii. Chiar i dac unul dintre angajai poate identifica sursa, accesibilitatea acelei surse poate fi dificil, deoarece, nu vor cunoate cui trebuie s se adreseze n interiorul organizaiei. Credem c n contextul acestor situaii, angajaii vor cuta involuntar un conector central. Prin urmare, sintetizm rolul conectorilor centrali, ca fiind acela de a realiza legtura ntre cuttor i cunoatere, att informal (prin oferirea unor date de contact ale persoanelor de unde pot obine cunotinele), ct i formal (folosind instrumente tehnologice, precum bazele de cunotine);

Conectorii inter-reele au o calificare superioara, n ceea ce privete achiziia cunotinelor globale, eterogene n plus fa de cunoaterea localizat, angajaii vor avea adesea nevoie de a cuta cunotine eterogene, specifice altor domenii. Spre exemplu, pentru rezolvarea unei probleme de analiz financiar, un angajat ar putea avea nevoie de cunotine referitoare la un anumit produs. Localizarea cunotinelor n contexte eterogene este un proces mai dificil dect identificarea cunoaterii n domenii clar delimitate, aceast situaie fiind datorat interaciunilor foarte rare ntre cuttor si alte domenii de cunoatere. Problema devine i mai complex, atunci cnd cutarea devine global. Datorit acestei complexiti, rolul conectorilor inter-reele va fi acela de a face posibil legtura dintre cuttor i cunoatere, indiferent de domeniu i distanele geografice;

Conectorii centrali pot afecta negativ transferul cunotinelor locale, omogene Conectorii centrali au o capacitate limitat, referitor la numrul de oameni cu care pot fi conectai la un moment dat. Dac aceast capacitate este depit, ei vor deveni inoperativi. Cross [Cross, 2001] a studiat o reea de 218 angajai i a observat c att timp ct conectorii centrali sunt accesai de numrul potrivit de angajai, acetia pot funciona bine. Oricum, ntocmai precum huburile ntr-o reea de calculatoare, suprancrcarea lor poate conduce la scderea drastic a randamentului. Un alt aspect subliniat de Cross, mai important dect primul menionat, este faptul c un conector central i poate exercita propria putere, crend n mod deliberat blocaje n schimbul de cunotine. Din moment ce ei controleaz fluxul de cunotine i conectivitatea n mediile locale, ar putea s ncerce o repoziionare, n vederea atingerii propriului avantaj;

Porile pot afecta negativ transferul cunotinelor n grupurile distribuite Porile controleaz ce cunotine pleac de la un anumit angajat i ce cunotine sunt acceptate, prin realizarea acestor funcii fiind asigurat stabilitatea i protecia reelei. Prin urmare, cunoaterea global nu este accesibil tuturor. Astfel, dei inteniile pot fi juste, poate exista un efect negativ n ceea ce privete transferul cunotinelor;

Punile au o calificare superioar, referitoare la definirea sensului cunotinelor locale sau globale, omogene sau eterogene n opinia lui Raider [Raider, 2003], agregarea i transferul cunotinelor sunt nefolositoare dac nu este identificat sensul cunotinelor. Definirea sensului este precedat de scheme, care faciliteaz nelegerea i definirea aciunilor referitoare la cunoatere. n organizaiile locale, angajaii i mprtesc

13

propria experien, crescnd probabilitatea definirii unor scheme comune. Problema definirii unui sens al cunotinelor se complic n cadrul cunoaterii eterogene, precum i a mediilor globale, deoarece angajaii pot vorbi diferite limbi, respectiv pot deine cunotine foarte diferite. Aceast situaie definete rolul punilor, anume, s posede capacitatea de a nelege o varietate de cunotine, n contexte diferite.

Experii au o calificare superioar, referitor la exploatarea cunotinelor Exploatarea cunotinelor este condiionat, adesea, de o multitudine de scheme, respectiv de cunotinele anterioare ale angajailor. Adesea, exploatarea cunotinelor ia forma rutinelor cotidiene, dar exist i cazuri n care o anumit cunoatere poate fi aplicat, punctual, o singur dat, cu rezultate vizibile asupra unui proces de afaceri.

Conectorii inter-reele au o calificare superioar, referitor la explorarea cunotinelor Explorarea cunoaterii reprezint o activitate pe care o regsim ntotdeauna lng utilizarea cunoaterii. Aceast operaie implic necesitatea existenei unor persoane conectorii inter-reele - care s poat iei din graniele unei mulimi prestabilite de cunotine i care s conduc la inovare Wilson [Wilson, 2003].

Aa cum reiese din cele prezentate anterior, componenta informal are un rol important, nu doar pentru managementul clasic (centralizat) al cunotinelor, ci i pentru managementul distribuit al cunoaterii. Am considerat important analiza modului n care literatura de specialitate prezint rolul componentei informale pentru managementul distribuit al cunotinelor, din urmtoarele dou motive:

Este necesar ca proiectarea unui sistem distribuit pentru managementul cunotinelor s

in cont de aspectul informal al cunoaterii, n contextul n care o mare parte a cunotinelor exist n mintea angajailor i nu n formate digitale;

Stabilirea unor roluri informale clare ofer posibilitatea optimizrii permanente a fluxurilor informaionale;

2.1.2 Model arhitectural pentru managementul distribuit de cunotine Cercetarea prezentat n subcapitolele 2.1 i 2.1.1, referitoare la managementul

distribuit al cunoaterii, ne ofer posibilitatea descrierii unui model conceptual pentru MDC4. Fr a detalia aspectele tehnologice, aspecte care susin dezvoltarea unui sistem distribuit precum cel din figura 1.43, ne propunem s integrm, ntr-un model unitar, vezi figura 2.2, principalele concepte regsite n literatura de specialitate referitoare la managementul distribuit de cunotine, i anume:

Domeniile de cunoatere; Elementele informale; Nodurile de cunotine; Procesele MC; Comuniti; Memoria organizaional.

4 Managementul distribuit al cunotinelor

Figura 2.2: Model pentru managementul distribuit al cunotinelor

15

Aa cum rezult din figura 2.2, un sistem pentru managementul distribuit de cunotine trebuie s susin dou categorii de procese, i anume:

Gestiunea autonom a cunotinelor create local, n interiorul unui singur nod de

cunoatere; Coordonarea diferitelor noduri de cunoatere, n lipsa unor semantici definite central.

Dac o organizaie complex poate fi considerat ca fiind format din suma nodurilor

de cunotine, o problem important care apare este cum poate fi realizat modelarea unei arhitecturi sociale distribuite, ntr-o arhitectur tehnologic distribuit, care s susin procesele managementului cunotinelor. n acest sens, am integrat n modelul prezentat n figura 2.2 conceptul nod de cunotine, descris de Bonifacio [Bonifacio, 2002].

Un nod de cunotine poate fi privit drept o reificare a unitilor organizaionale att a celor formale, precum departamentele, ct i a celor informale: grupuri cu aceleai interese, comuniti de practic, comuniti orientate spre cunoatere. Adesea, unitile informale manifest un grad mare de autonomie semantic unde, prin autonomie semantic, nelegem posibilitatea dezvoltrii schemelor locale de interpretare.

Potrivit lui Davenport [Davenport, 1998], fiecare nod de cunoatere reprezint un proprietar de cunotine, care are capacitatea de a-i gestiona propria cunoatere, att din punct de vedere tehnologic, ct i conceptual. Conform aceluiai autor, exist multe cazuri, n care proprietarii de cunotine nu sunt recunoscui n mod formal. Ca o consecin a acestui fapt, autonomia lor semantic conduce la crearea de instrumente, precum baze de date, site-uri web, colecii de documente i arhive, care nu fac parte din sistemul informaional oficial. n opinia lui Bouquet [Bouquet, 2002], o supoziie important, referitoare la sistemele distribuite pentru managementul cunotinelor, afirm c uniti organizaionale diferite tind ca ntr-un mod autonom s-i dezvolte propriile instrumente, potrivite cerinelor interne.

Aceast situaie se poate datora utilizrii unor sisteme vechi, care sunt n continuare eficiente sau faptului c diferitele sarcini pot necesita utilizarea unor aplicaii diferite. n figura 2.2, ca exemplu de aplicaii locale, putem ntlni orice tehnnologie descris n capitolul 1.5.2.1.3. Chiar dac tehnologiile i formatul datelor sunt comune, pentru dou sau mai multe noduri, nelegerea local a utilizrii acestora poate fi diferit.

Contextul este definit de ctre Bonifacio [Bonifacio, 2002], ca fiind o reprezentare explicit a unei perspective departamentale. Noiunea de context a fost studiat i definit formal de Ghidini [Ghidini, 2001] i Benerecetti [Benerecetti, 2000]. Astfel, contextul reprezint o reprezentare aproximativ i parial a realitii, dintr-o anumit perspectiv. Prin urmare, un context poate fi formalizat sub forma unei teorii locale, care exist ntr-o legtur, denumit relaie de compatibilitate, cu alte teorii locale despre lume. O astfel de relaie surprinde faptul conform cruia contextul, dei autonom, se poate referi la aceleai elemente ale realitii, prin urmare existnd nevoia unui anumit grad de coordonare semantic.

Spre exemplu, n situaii simple, contextul poate fi reprezentat formal, prin sistemul de categorii folosit pentru clasificarea documentelor. n cazul scenariilor mai complexe, reprezentarea contextului poate fi realizat prin intermediul ontologiilor sau a proceselor de afaceri. Din perspectiva proiectrii, contextele pot fi create pornind de la zero, dar adesea, ele vor fi extrase din informaiile semantice obinute prin folosirea aplicaiilor locale.

Din punct de vedere tehnologic, definirea contextului poate fi susinut de instrumente, precum CMS, groupware, text/data mining. Drept rezultat, ntr-un sistem distribuit pentru managementul cunotinelor, scopul acestor tehnologii este reinterpretat astfel: de la instrumente pentru crearea i gestiunea schemelor globale de interpretare, la instrumente pentru crearea i gestiunea schemelor locale de interpretare.

16

Agenii software i serviciile reprezint dou modaliti distincte de corelare a cunotinelor i informaiilor existente n mai multe noduri de cunoatere. Din punct de vedere tehnologic, aceste categorii software definesc arhitectura distribuit a sistemului.

Agenii i serviciile ndeplinesc dou funcii, respectiv:

Ajut utilizatorii nodului de cunoatere s aib acces la cunotine pe care le poate furniza nodul respectiv - omogenitatea, eterogenitatea, coerena sau corectitudinea acestor cunotine putnd fi tratate i ulterior, la nivelul componentei informale, reprezentat de conectori, puni i filtre.

Transfer cunotine i informaii ntre noduri. Memoria organizaional reprezint, aa cum se observ n figura 2.2, o parte

integrant a sistemului pentru managementul cunotinelor. Cadrul memoriei organizaionale se refer la procese i sisteme informaionale folosite pentru captura, cutarea, extragerea i prezentarea cunotinelor. Conform lui Croasdell [Croasdell, 2003], nodurile de cunoatere trebuie s ofere att posibilitatea stocrii cunotinelor n baze de cunotine, ct i pe cea a obinerii cunotinelor cerute de utilizatori.

Exist dou tendine referitoare la modelarea managementului cunotinelor, anume: modelul bazat pe un singur depozit de cunotine, respectiv modelul reea Alavi [Alavi, 2000].

Modelul prezentat n figura 2.2 reprezint un model hibrid. Caracterul hibrid este dat de existena a dou elemente, anume:

memoriile organizaionale, care reprezint, cel puin la nivel conceptual, un element

central n care regsim cunoatere; tehnologiile informaionale, folosite pentru susinerea fluxurilor formale sau informale de

cunotine, ntre domenii de cunoatere reprezentate prin noduri de cunotine. Un element, a crui prezentare lipsete n literatura de specialitate, este reprezentat de

abordarea managementului cunotinelor n funcie de distribuia geografic a organizaiei. Astfel, ntlnim organizaii locale, care au, n general, o structur simpl, centralizat, respectiv, organizaii distribuite exemple fiind companiile multinaionale sau acele companii care dein sucursale sau filiale.

Pe baza acestei tipologii, subliniem faptul c sistemele distribuite pentru managementul cunotinelor sunt aplicabile oricrui tip de companie, ns beneficiile maxime sunt obinute n cazul companiilor avnd un grad mare de distribuie.

Companiile de dimensiuni mici pot implementa soluii distribuite pentru managementul cunotinelor, spre exemplu pentru interconectare departamental. Desigur, o companie mic poate avea, n cazul existenei unui numr mare de clieni, parteneri i furnizori, o structur suficient de complex, care s justifice necesitatea arhitecturilor MC distribuite. Aa cum vom descrie, ulterior vezi capitol 2.3, crearea sistemelor distribuite, care s integreze mai multe companii, este posibil, ns puin implementat n prezent.

Practic, ceea ce regsim n prezent sunt organizaiile medii i mari, care ncearc, n primul rnd, optimizarea funciilor interne pentru ca n viitor, acestea s poat susine o posibil nou paradigm, n care toate sistemele s poat fi interconectate, indiferent de industrie, standarde i tehnologii.

n continuare, ne propunem s abordm, ca o completare la componenta ne-tehnologic -prezentat pn n acest punct - caracteristicile i conceptele fundamentale ale sistemelor distribuite, ulterior urmnd a vedea cum pot fi folosite acestea, n definirea de soluii viabile, pentru managementul cunotinelor.

17

2.2 Sisteme distribuite, caracteristici i concepte fundamentale

Literatura de specialitate prezint sistemele distribuite ntr-o multitudine de definiii. Spre exemplu, George Coulouris [Coulouris et al, 2004] prezint un sistem distribuit ca fiind acel sistem n care componentele, localizate n cadrul reelelor de calculatoare, comunic i i coordoneaz aciunile doar prin transmiterea de mesaje. Aceast definiie accentueaz importana unei caracteristici tehnice a sistemului distribuit, respectiv modul n care pot comunica componentele sistemului. Un alt exemplu i, implicit, o alt abordare, se regsesc la Andrew Tannenbaum [Andrew, 2006], care definete un sistem distribuit drept o colecie de calculatoare independente, prezentat utilizatorilor drept un singur calculator. Aa cum se observ, aceast definiie face referire la dou aspecte, i anume:

Aspect hardware, n sensul n care mainile sunt autonome; Aspect software, definit prin modul n care utilizatorii percep sistemul. Dup prerea lui Birman [Birman, 2005], principalul motiv pentru construirea unui

sistem distribuit l reprezint partajarea resurselor. Resursele pot fi gestionate de ctre servere specializate i accesate de clieni, sau, pot fi ncapsulate ca obiecte i accesate de alte obiecte, care nu se gsesc pe aceeai main.

n prezent, cel mai cunoscut sistem distribuit este Internetul, urmnd, pe aceeai linie tehnologic, Intranet-urile, respectiv sistemele mobile.

Abordarea internetului ca sistem distribuit este posibil deoarece: Internetul reprezint o vast colecie, format din reele eterogene de calculatoare,

interconectate pentru a oferi utilizatorilor imaginea unei singure entiti; Programele care ruleaz pe calculatoarele conectate la Internet interacioneaz prin

transmiterea de mesaje, folosind un mijloc comun de comunicare, respectiv protocoale.

Prin urmare, este oferit utilizatorilor, indiferent de localizare, posibilitatea folosirii unor servicii, precum: world wide web, pot electronic, transfer de fiiere. Internetul poate fi extins n orice moment, prin adugarea de noi servere i implicit, de servicii noi.

n prezent, cele mai limitate servicii oferite prin intermediul Internetului sunt cele de tip multimedia. Acest lucru se ntmpl deoarece este dificil de optimizat comunicarea impus de aceast categorie de date. Subliniem acest aspect deoarece, din punct de vedere al managementului cunotinelor, serviciile multimedia sunt o component vital, ntruct o mare parte a informaiei organizaionale, suficient de complex pentru a genera cunotine, exist n format multimedia.

Potrivit lui Steve [Steve, 2008], reelele Intranet reprezint subcomponente ale Internetului, administrate separat, cu limite ce pot fi configurate n vederea ntririi politicilor locale de securitate. De obicei, un intranet este conectat la Internet prin intermediul routerelor, fapt care permite utilizatorilor din interiorul intranetului s foloseasc servicii aflate la distan, localizate n alte reele de calculatoare. Acestea permit de asemenea utilizatorilor din alte reele s acceseze servicii locale. Multe organizaii necesit protejarea propriilor servicii mpotriva utilizrii neautorizate sau mpotriva programelor de tip virus.

De asemenea, exist i situaia n care companiile nu doresc s aib conectate reelele interne la Internet. ns, chiar i aceste organizaii vor dori s beneficieze de numrul mare de aplicaii, care se bazeaz pe protocoale de comunicare specifice Internetului. Soluia n acest caz o reprezint dezvoltarea unui intranet, fr ca acesta s fie conectat la Internet. O astfel de

18

reea va avea cea mai bun protecie mpotriva accesului neautorizat, respectiv lipsa unei legturi fizice cu sisteme exterioare ei.

Principalele situaii care apar in cadrul intranet-urilor sunt: Nevoia existenei unui serviciu special de fiiere pentru partajarea datelor; Programele firewall tind s mpiedice accesul legitim la date; Atunci cnd este necesar partajarea resurselor ntre utilizatori interni i externi

mecanismele de securitate trebuie a fi foarte corect implementate Costul programelor i al unei arhitecturi nchise poate fi ridicat, datorit utilizrii unui

numr mare de sisteme server, care deservesc clienii.

Sistemele mobile reprezint consecina fireasc a dezvoltrii tehnologice, att n domeniul miniaturizrii, ct i al reelelor fr fir. Acest lucru a condus la o cretere a integrrii echipamentelor portabile n sistemele distribuite. Dintre echipamentele portabile, frecvent ntlnite n dezvoltarea sistemelor distribuite, menionm: calculatoare portabile, PDA-uri, telefoane mobile, camere video i digitale, echipamente de tip embedded folosite n electrocasnice, sisteme hi-fi, maini, etc.

Astfel, utilizatorii aflai la distan de propria reea intranet au n continuare acces la resurse, att hardware, ct si software, folosind dispozitivele portabile de care dispun. Cu toate acestea, utilizarea dispozitivelor mobile, privit din punctul de vedere al dezvoltrii sistemelor, ridic o serie de probleme, aa cum arat Andy [Andy, 2003], i anume:

Reconfigurarea manual a dispozitivelor pentru fiecare sistem n parte unde sunt folosite; Conectivitatea limitat; Garantarea unui mediu privat i sigur, indiferent de locul n care utilizatorii i folosesc

dispozitivele mobile. Un alt posibil exemplu este cel n care considerm cazul unei reele de calculatoare

din departamentul unei companii. Pot exista, adiional fa de aceste calculatoare, un plus de procesoare, nedestinate unui anume utilizator, ci alocate dinamic, n funcie de necesiti.

Un astfel de sistem ar putea avea un sistem unitar de fiiere, fiiere accesibile pentru toate mainile, n acelai mod i folosind aceeai cale. Mai mult, atunci cnd utilizatorul tasteaz o comand, sistemul ar putea gsi locul cel mai potrivit de execuie: posibil pe calculatorul local, pe alt staie inactiv sau pe unul din procesoarele libere. Dac un astfel de sistem, privit ca ntreg, s-ar comporta precum un sistem clasic, cu un singur procesor, atunci el ar putea fi considerat sistem distribuit.

2.2.1 Caracteristici fundamentale ale sistemelor distribuite

Din studiul realizat asupra sistemelor distribuite de ctre Weiser [Weiser, 1994] reiese

faptul c provocrile dezvoltrii acestor sisteme se refer la urmtoarele aspecte: eterogenitatea componentelor; securitatea i scalabilitatea sistemului; tratarea erorilor i defeciunilor; concurena utilizatorilor; transparena componentelor. Studiul a fost efectuat dup ce, anterior, Saltzer [Saltzer, 1984] afirma despre sistemele distribuite c necesit o anumit infrastructur la nivelul sistemului de operare, precum i o modalitate specific de transmisie, respectiv control, a datelor.

19

Ulterior, Andrew [Andrew, 2006] sintetizeaz i unific cele dou perspective, vezi figura 2.3, definind sistemul distribuit prin urmtoarele noiuni: algoritmi distribuii; sisteme de fiiere distribuite; sisteme multimedia distribuite; memorie distribuit; tranzacii distribuite; concuren i replicare.

Figura 2.3: Concepte de baz ale sistemelor distribuite

Sursa: Adaptare dup Andrew [Andrew, 2006]

Figura 2.3 exprim relaia dintre conceptele menionate anterior - elementele fundamentale, precum modelele arhitecturale distribuite, infrastructura de transfer i modurile de comunicare, sunt completate prin dou niveluri logice, formate din algoritmi distribuii i aplicaii middleware. Componenta middleware este important, mai ales pentru programatori, deoarece nglobeaz tehnologii specifice dezvoltrii software-ului distribuit. Conceperea unui sistem distribuit, ca fiind acel sistem n care componentele hardware i software comunic i i coordoneaz activitatea prin transmiterea de mesaje, genereaz urmtoarele consecine:

Utilizatorii sunt att de obinuii cu beneficiile partajrii resurselor nct, adesea, uit importana acestui aspect. n prezent exist o rutin n a avea acces la resurse hardware i software. Partajarea hardware a fost i este important mai ales din punctul de vedere al costurilor. n practic, modelele de partajare a resurselor variaz att n ce privete gradul de acoperire ct i din punctul de vedere al distanei dintre utilizatori. Potrivit lui Coulouris [Coulouris, 2004], ntlnim, pe de o parte, motoarele de cutare pe Internet, care, practic, unesc utilizatori din orice locaie geografic, iar pe de alt parte modele de tip CSCW (computer supported cooperative working), unde totul se rezum la un grup restrns de utilizatori care coopereaz n mod direct. Prin urmare, att modelul partajrii, ct i distribuia geografic determin necesitatea unor mecanisme de coordonare a activitilor, pe care sistemul distribuit trebuie s le ofere;

Serviciile, specifice componentei middleware, delimiteaz o parte distinct a unui sistem. Ele gestioneaz o colecie de resurse interconectate i ofer funcionalitatea acestora utilizatorilor sau aplicaiilor. Spre exemplu, accesm fiiere prin intermediul unor servicii de fiiere, trimitem documente spre imprimant folosind servicii de tiprire, cumprm bunuri prin intermediul serviciilor electronice de plat, etc. Singura modalitate de acces a resurselor o reprezint setul de operaii puse la dispoziie de acestea.

20

Restricionarea accesului la resurse, printr-o mulime bine definit de operaii, reprezint o component a practicii ingineriei software. Aceasta se reflect i n organizarea fizic a unui sistem distribuit: Resursele unui sistem distribuit sunt ncapsulate fizic, n calculatoare, ele putnd fi accesate din exterior doar prin mecanisme specifice de comunicaie. Pentru partajarea eficient, fiecare resurs trebuie gestionat de un program care ofer o interfa de comunicare. n felul acesta, este permis accesarea i modificarea resursei ntr-un mod fiabil i consistent.

Abdelsalam [Abdelsalam, 2007] menioneaz faptul c sistemele distribuite trebuie s lase loc dezvoltrii ulterioare de servicii i programe mbuntite. Astfel, att dezvoltarea ct i mbuntirea sistemelor distribuite se bazeaz pe o serie de caracteristici fundamentale, sintetizate n tabelul 2.1:

Tabel 2.1: Principalele caracteristici ale sistemelor distribuite

Caracteristic Descriere

Eterogenitate

Internetul permite utilizatorilor s acceseze servicii i s ruleze aplicaii pe o colecie eterogen de calculatoare i reele. Conform lui Olivier [Olivier, 2001], 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, cum ar fi:

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. Spre exemplu, un calculator ataat unui mediu Ethernet va folosi o implementare a unei stive de protocoale construit special pentru acest mediu; alte medii vor folosi aceleai protocoale ns dezvoltate pentru situaiile respective;

Tipurile de date pot fi reprezentate n diferite moduri, funcie de componenta 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 ntre ele dac nu sunt folosite standarde comune.

Deschidere

Potrivit lui Carne [Carne, 2000], 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 componente dezvoltate de oameni diferii deci, implicit, grupuri eterogene. De aceea, 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

21

discuiile referitoare la protocoalele respective. Publicarea protocoalelor de comunicaie reprezint unul din factorii principali care a permis construirea unei varieti de aplicaii i sisteme. Astfel, dup prerea lui Carne, sistemele construite folosindu-se aceste specificaii sunt deschise. Cu alte cuvinte, ele au un grad mare de extensibilitate, putnd 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. Conform lui Oprea [Oprea, 2007], 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.

Stevens [Stevens, 1994] subliniaz faptul c securitatea nu nseamn doar ascunderea coninutului mesajului. Ea implic, de asemenea, cunoaterea utilizatorului sau agentului din partea cruia s-a fcut transmisia. Astfel, atunci cnd se pune problema securitii unui sistem distribuit, vom ntlni dou provocri majore: prima se refer la transmiterea informaiei ntr-o modalitate sigur, n timp ce a doua este centrat pe identificarea entitii care cere resurse. n plus, mai exist i alte probleme poteniale care pot aprea:

cazul DSA (Denial of Service Attacks) n opinia lui Jelena [Jelena, 2003], acest caz cuprinde situaiile n care se dorete ntreruperea funcionrii serviciului, folosindu-se pentru aceasta un numr foarte mare de cereri irelevante, emise ntr-un timp foarte scurt;

securitatea codului mobil - Putem considera, pentru exemplificarea acestei situaii, un caz frecvent ntlnit, respectiv un program executabil primit n pota electronic. Efectele rulrii acestui program sunt greu de prezis, n spatele unei execuii aparent normale, procesul putnd accesa resurse confideniale, sau chiar face parte din scenarii DSA.

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.

Neumann [Neumann, 2004] identific faptul c scalabilitatea unui sistem distribuit poate fi msurat pe cel puin trei dimensiuni:

mrime numrul de utilizatori sau resurse poate fi extins; geografic arealul geografic poate crete; administrativ acoperirea unui numr mai mare de compartimente ntr-o

companie.

22

Conform aceluiai autor, principalele provocri ale creterii scalabilitii sunt reprezentate prin:

costul resurselor fizice - Odat cu creterea necesarului de resurse, ar trebui s existe posibilitatea extinderii sistemului la un cost rezonabil.

controlul scderilor de performan Este ntlnit, spre exemplu, n gestiunea unui set de date, a crei mrime este proporional cu numrul de utilizatori sau

resurse din sistem, un exemplu n acest sens fiind tabela care conine corespondena dintre numele de domeniu i adresele IP. n acest caz, algoritmii care folosesc structuri ierarhice pot fi mai uor extini dect cei liniari. Prin folosirea structurilor ierarhice, o cretere a dimensiunii va conduce la scderea performanei - timpul necesar pentru accesarea unor date structurate variind logaritmic. Astfel, pentru ca un sistem s fie scalabil, scderea maxim de performan nu ar trebui s conduc la rezultate mai mici dect cele din cazul datelor structurate;

necesarul de resurse software adecvate - Conform lui Carla [Carla, 2007], unul dintre cele mai bune exemple pentru aceast provocare este regsit n arhitectura Internetului, fiind oferit de modul reprezentrii adreselor IP(v4), care, n contextul folosirii a 32 de bii i a ritmului prezent de dezvoltare, vor fi epuizate destul de curnd. Dei soluia pare a fi oferit sub forma noii versiuni de adresare IPv6 (pe 128 de bii), putem afirma c aceasta nu este dect o rezolvare temporar., deoarece este dificil de previzionat cererea ulterioar de adresare. Referitor la acest aspect, Joseph [Josephd, 2008] menioneaz, referitor la compensarea ulterioar a adreselor, c este necesar susinerii unei creteri neplanificate, dar c poate avea consecine mai grave dect adaptarea la o schimbare, atunci cnd aceast schimbare se impune. Acelai autor descrie i situaia ideal, respectiv aceea n care logica sistemului i aplicaiile software nu ar trebui s se schimbe n momentul creterii acestuia. Este o situaie care, ns, nu a fost atins.

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, constnd n dificultatea 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 [Joe, 2003].

n vederea tratrii erorilor, Dasgputa [Dasgputa, 1985] identific principalele tehnici folosite:

de detecie - Unele erori pot fi detectate. Pentru aceasta, pot fi folosite funcii de

23

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 componente. Spre exemplu, n cazul unui browser care nu poate contacta un server web, acesta nu va lsa utilizatorul s atepte pn la remedierea problemei, dimpotriv, l va informa pe acesta c resursa este indisponibil i o ncercare ulterioar de accesare ar putea aduce rezultatul dorit;

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. S considerm, spre exemplu, situaia n care trebuie s existe mai multe rute, ntre dou routere pe Internet. Pentru aceasta, n DNS, fiecare tabel este replicat pe cel puin dou servere. Dup prerea lui Andrew [Andrew, 2006], una dintre provocrile implementrii sistemelor distribuite o reprezint dezvoltarea tehnicilor eficiente, n vederea pstrrii redundante a datelor cu dinamic ridicat, fr pierderi majore de performan. n acest fel, sistemele distribuite vor putea avea un grad maxim de disponibilitate.

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

Conform lui Grolaux [Grolaux, 2005], 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, prezentate n cele ce urmeaz:

24

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. Potrivit lui Karlaplem [Karlaplem, 1994], aceste dou tipuri de transparen se regsesc sub numele

de transparena reelei.

Drept exemplu, referitor la transparena accesului, putem considera o interfa grafic, care conine o viziune unitar a directoarelor, indiferent dac acestea sunt locale

sau la distan. O alt situaie poate fi aceea a unui API pentru fiierele care folosesc aceleai operaii. Pe de alt parte, un foarte bun contraexemplu este situaia n care, pentru accesul fiierelor aflate pe alte sisteme, trebuie folosite programe ftp.

Michael [Michael, 2003] subliniaz faptul c numele resurselor web, respectiv url-urile, ofer un exemplu bun, n ceea ce privete transparena locaiei. Aceasta, deoarece elementul care identific un nume de domeniu se refer la numele unui calculator i nu la o adres Internet.

Oricum, adresele URL nu sunt transparente din punctul de vedere al mobilitii deoarece, spre exemplu, pagina personal nu poate fi mutat ntr-un alt domeniu toate legturile ctre ea vor face n continuare referiri ctre pagina original cunoscut a fi la o anume adres.

O alt ilustrare a transparenei de reea poate fi utilizarea unei adrese e-mail. Aceasta conine implicit un nume de utilizator i un nume de domeniu. Trimiterea unui mesaj ctre o asemenea adres nu implic cunoaterea locaiei fizice sau a reelei din care fac parte. De asemenea, procedura de trimitere a mesajului nu depinde de locaia receptorului. Potrivit lui Nissen [Nissen, 2002], tot n contextul potei electronice, poate fi ilustrat i transparena erorilor: un mesaj va fi transmis n cele din urm, chiar dac la un moment dat pot exista probleme de comunicaie, oricum utilizatorul nu le va cunoate. n acest caz, nivelul middleware este responsabil cu operaia de conversie a erorilor de reea n excepii de programare.

Pentru exemplificarea transparenei mobilitii, putem considera cazul telefoanelor mobile: S presupunem c att cel care sun ct si cel apelat cltoresc, trecnd prin

25

diferite celule mobile. Dac privim telefonul celui care apeleaz drept client, iar telefonul sunat drept resurs, pentru cele dou componente nu este relevant faptul c sunt n micare.

n plus fa de caracteristicile sistemelor distribuite, prezentate n tabelul 2.1, 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.

Prin urmare, n subcapitolul urmtor vom prezenta o sintez a caracteristicilor principalelor moduri de comunicare, folosite n tehnologiile distribuite actuale: comunicarea prin mesaje i apelul procedurilor la distan.

2.2.2 Paradigma comunicrii n sistemele distribuite

Sistemele de calcul distribuit, n particular cele gestionate de un sistem de operare

distribuit, trebuie s funcioneze rapid, pentru a induce utilizatorilor sentimentul unui calculator puternic Hohpe [Hohpe, 2004].

n acest context, construirea unui subsistem de comunicare, pentru obinerea unor performane ridicate, reprezint o problem fundamental a dezvoltrii sistemelor distribuite. n opinia lui Olivier [Olivier, 2001], factorii care influeneaz performanele procesului de comunicaie sunt:

viteza fizic a reelei, care poate varia ntre 10 Mbps i gigabii pe secund.; protocoalele de comunicaie, mai ales cele orientate pe conexiune, precum TCP; modelul comunicrii, care susine cooperarea ntre clieni, servere i sistemul de operare.

Olivier subliniaz faptul c exist dou situaii care pot aprea n contextul paradigmei comunicrii, ntruct un client poate trimite o cerere ctre un singur server sau ctre mai multe. Prin urmare, vom ntlni dou modele de comunicare: one-to-one i one-to-many.

Fiecare dintre cele dou modele de comunicare inter-procese pot fi dezvoltate, folosind dou tehnici diferite: transmiterea de mesaje sau apelul procedurilor la distan. Ambele tehnici sunt susinute de dou seturi diferite de primitive, furnizate prin sistemul de operare. Folosirea lor are rolul de a conduce la definirea unui format comun comunicaiei dintre procese aflate pe calculatoare diferite.

Potrivit lui Tai [Tai, 2004], cele dou tehnici de comunicare ntre procese se bazeaz pe concepte foarte puin asemntoare:

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.

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.

26

2.2.2.1 Comunicarea prin mesaje

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 mesaj cu tip formalizeaz informaia structural referitoare la 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.

Utilizarea mesajelor structurate este, din motive de eficien, preferat. 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], indiferent de tipul transmisiei care se realizeaz.

Pentru ca dou calculatoare, oricare, s schimbe date, este necesar 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 preprocesor 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 comunicarea 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 urmtoarelor dou tehnici:

Prima dintre acestea este comunicarea 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

5 Termenul marshalling(asemntor serializrii) reprezint procesul de transformare a reprezentrii unui obiect din memorie intr-un format de date potrivit stocrii sau transmisiei - http://en.wikipedia.org/wiki/Marshalling_(computer_science)

27

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, este comunicarea indirect, care utilizeaz conceptul de port. Rezult 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.

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.

Conform lui Tai [Tai, 2000], exist trei forme de primitive receive: blocante, neblocante i de control. Primitiva blocant este cel mai adesea ntlnit, din moment ce procesul receptor n cele mai multe cazuri nu are nimic de fcut dect s atepte sosirea mesajelor. Un proces poate primi toate mesajele i apoi selecta unul pentru a fi procesat. Primitivele blocante furnizeaz o cale simpl pentru a combina transferul datelor cu funcia de sincronizare.

n ceea ce privete primitivele neblocante, acestea prezint urmtoarele caracteristici: Primitiva send ntoarce controlul programului utilizator imediat ce mesajul a fost stocat

n coad sau a fost fcut o copie; Cnd un mesaj a fost transmis sau copiat ntr-un loc sigur pentru transmiteri ulterioare,

programul este ntrerupt pentru a se informa c buffer-ul poate fi refolosit; Primitiva receive corespondent semnalizeaz disponibilitatea de a primi un mesaj i

furnizeaz buffer-ul n care mesajul poate fi plasat. Avantajul primitivelor neblocante const n flexibilitatea maxim. Mai mult, aceste primitive sunt folosite pentru aplicaiile real-time. Dezavantajul provine din necesitatea realizrii operaiilor pe zona buffer n vederea eventualelor schimbri ale coninutului mesajului sau pentru a preveni accesul la mesaj. Posibilele accesri i modificri ale mesajului se pot produce nainte, n timpul transmisiei sau atunci cnd mesajul ateapt s fie recepionat.

Achour [Achour, 1993] subliniaz faptul c n unele sisteme de comunicaie bazate pe

mesaje, acestea sunt stocate n zone buffer n timpul perioadei de transmitere i de recepionare. n cazul n care un buffer este plin, execuia primitivei send implic dou soluii: trimiterea poate fi amnat pn cnd va exista spaiu n zona tampon sau poate fi

28

ntoars clientului, indicnd faptul c buffer-ul este nc plin iar mesajul nu a putut fi transmis.

Conform aceluiai autor, situaia serverului receptor este diferit. Primitiva receive informeaz sistemul de operare despre bufferul n care serverul dorete stocarea mesajului ce-a ajuns. Problema apare n momentul n care primitiva receive este emis dup ce mesajul ajunge. ntrebarea este ce s facem cu mesajul? Prima abordare ar fi tergerea mesajului. Clientul ar percepe o operaie de time-out i retransmite, spernd c ntre timp primitiva receive a fost emis. O a doua abordare este stocarea mesajului ntr-un buffer al sistemului de operare pentru o perioad determinat. Dac pe durata respectiv va fi emis primitiva necesar, mesajul va fi copiat n zona de pe server asociat. n cazul n care primitiva receive nu este invocat i timpul expir, mesajul va fi pierdut.

Houttuin [Houttuin, 1993] trateaz aspecte referitoare la bufferele de transmisie. El consider dou extreme: un buffer cu capacitate nelimitat, respectiv unul cu margini finite. Dac buffer-ul are capacitate nelimitat, atunci un proces nu va fi niciodat ntrziat n situaia n care se execut un send. Sistemele bazate pe aceast abordare sunt numite sisteme cu transfer asincron de mesaje sau sisteme no-wait.

Cea mai important caracteristic a tipului asincron const n faptul c permite unui expeditor s ajung, arbitrar, cu mult n faa unui destinatar. Atunci cnd un mesaj este recepionat, el va conine informaii despre starea expeditorului care ar putea s nu mai fie valide. Dac sistemul nu permite utilizarea zonelor buffer, execuia primitivei send este amnat pn la execuia unei operaii receive corespunztoare. Atunci cnd buffer-ul are limite, clientului i este permis s ajung n faa serverului dar nu ntr-un mod arbitrar, acesta beneficiind de trimiteri multiple pe baza mecanismelor de buffering.

Potrivit lui Houttuin, cea mai frecvent abordare o ntlnim atunci cnd este furnizat un apel sistem create-buffer, care creeaz un buffer cu dimensiunea specificat de utilizator. Aceast soluie implic clientul care trimite un mesaj ctre un port destinatar, unde este stocat n buffer pn n momentul n care va fi preluat de server. Lan [Lan, 1990] caracterizeaz sistemele bazate pe zone buffer, astfel:

Complexitatea lor este crescut din moment ce necesit crearea, distrugerea, gestiunea bufferelor.

Genereaz probleme de protecie i pot cauza situaii foarte neplcute atunci cnd un proces, proprietar al unui port, este terminat.

ntr-un sistem fr zone buffer, procesele trebuie sincronizate pentru ca transferul unui mesaj s poat avea loc.

Diferite evenimente, precum blocarea unui calculator sau a sistemului de comunicare, se pot ntmpla, frecvent, n cazul sistemelor distribuite. Aceasta poate provoca pierderea n reea a unui mesaj tip cerere sau a unui mesaj de rspuns. Mai mult, mesajele pot fi duplicate sau expediate ntr-o ordine eronat.

Primitivele prezentate pn n acest moment nu pot gestiona aceste probleme, din acest motiv fiind referite n literatura de specialitate sub numele de primitive nefiabile. O astfel de primitiv send nu face, n mod fundamental, dect s pun un mesaj pe reea. Nu exist nici o garanie a transmiterii sau o retransmisie automat executat prin sistemul de operare, atunci cnd un mesaj este pierdut.

Tratarea diferitelor probleme necesit furnizarea unor primitive fiabile. n cadrul unei comunicri fiabile ntre procese, primitiva send gestioneaz mesajele pierdute folosind retransmisii interne i atenionri pe baza strategiei time-out. Aceasta implic faptul c n momentul terminrii execuiei primitivei send, procesul este sigur c mesajul a fost recepionat i recunoscut. ntrebarea care se nate este dac tratarea fiabilitii ar trebui rezolvat pe un nivel att de nalt? Ar trebui mecanismele de recuperare s fie furnizate prin protocolul transport sau prin protocoale de nivel mai sczut?

29

2.2.2.2 Apelul procedurilor la distanta

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 ascun