Cuprins

Aceasta lucrare poate fi descarcata doar daca ai statut PREMIUM si are scop consultativ. Pentru a descarca aceasta lucrare trebuie sa fii utilizator inregistrat.

Extras din document

Cuprins
1. Introducere.......1
2. Arhitectura aplicatiei.......2
3. Implementare...6
3.1 Alegerea limbajului.......6
3.2 Caracteristici care au impus alegerea limbajului.......7
3.3 Alegerea mediului de dezvoltare..............10
3.3.1 Sockets......10
3.3.2 Datagrame.12
3.3.3 RMI...........13
3.3.3.1 Asemanari intre modelul obiectelor distribuite si cel al obiectelor locale...15
3.3.3.2 Deosebiri intre modelul obiectelor distribuite si cel al obiectelor locale...15
3.3.3.3 Activarea obiectelor la distanta...........17
3.3.4 CORBA.....18
3.3.4.1 Prezentare generala..............18
3.3.4.2 Arhitectura CORBA............19
3.3.4.3 Orb.........21
3.3.4.4 Clienti.....21
3.3.4.5 Implemetarile obiectelor......21
3.3.4.6 Referinte de obiecte.............21
3.3.4.7 OMG IDL.............22
3.3.4.8 DII..........22
3.3.4.9 Skeleton.22
3.3.4.10 DSI.......22
3.3.4.11 OA........23
3.3.4.12 IR.........23
3.3.4.13 Implementation Repository..............23
3.3.4.14 Tipuri de ORB....23
3.3.4.15 Integrarea altor sisteme de obiecte...24
3.3.5 DCOM......24
3.3.6 Citeva diferente intre cele trei implementari........24
3.3.7 Implementari............25
4. Solutia de implementare..............26
4.1 Consideratii asupra implementarii............27
4.2 Implementarea propriu-zisa.......29
4.2.1 Prezentarea interfetei client.....29
4.2.2 Prezentarea interfetei manager34
4.2.2.1 Subsectiunea de decizie.......34
4.2.2.2 Subsectiunea de informare...34
4.3 Comunicarea36
4.3.1 Comenzi si informatii. Evenimente.......36
4.3.2 Canalul de Evenimente...........39
4.3.2.1 Proxy consumers si proxy suppliers...40
4.3.2.2 Modele de comunicare.........40
4.3.2.3 Utilizarea canalelor de evenimente.....41
4.4 Entitati ce compun sistemul......45
4.4.1 Clienti........46
4.4.2 Manager....55
4.4.3 Canalul de comunicatie...........56
4.4.4 Fluxul programului..57
4.5 Testare..........70
5. Concluzii si directii de dezvoltare71
5.1 Concluzii......71
5.2 Directii de dezvoltare..72

Alte date

?

1. Introducere

Numele aplicatiei – “Grup de discutii pe Internet” – sugereaza faptul ca aceasta tema de proiect isi propune sa ofere o varianta de implementare pentru ideea de schimb de date in timp real, avind drept suport reteaua Internet.

Multe categorii de utilizatori – care folosesc calculatorul acasa, la scoala, in firme mici sau mari – pot acum sa beneficieze din plin de intinderea retelei Internet sau de retelele interne ale firmelor pentru a comunica si a colabora mai eficient in timp real.

Grupurile de interese de pe tot globul, ce poarta discutii privind orice subiect imaginabil, fac parte din realitatea cotidiana a unei anumite categorii de persoane, iar aceasta categorie va creste pina la dimensiunile intregii omeniri. Discutiile, in care o persoana trimite un mesaj si toti ceilalti abonati ai grupului de interes pot sa-l citeasca, se deruleaza in toate stilurile posibile. Atunci cind o anumita persoana considera ca poate beneficia de experienta altor persoane, intr-un anumit domeniu, se poate interesa daca exista un grup deja format in care se discuta probleme avind ca teme subiecte din sfera sa de interese. Aceasta este o alternativa viabila a solutiei care ar insemna browsing-ul pe Internet, in cautarea informatiei.

Grupurile de discutii au aparut inca de la inceputurile retelei Internet, permitind oamenilor de stiinta, interesati de acelasi subiect, sa emita intrebari si sa primeasca raspunsuri. Astazi, aceste grupuri pot fi asemanate cu cu cele care se formeaza intr-o locuinta sau local public, cu exceptia faptului ca informatiile se transmit prin scris (desenat), si nu prin viu grai. Fiecare participant poate citi ceea ce au scris altii si poate face propriile comentarii.

Exista mii de grupuri de discutii, ale caror subiecte acopera domenii ca stiinte sociale, calculatoare, literatura, economie, hobby-uri, economie etc. In cadrul acestor grupuri se pot face oferte de lucru, contracte, propuneri de afaceri, anunturi ale unor evenimente, se pot face schimburi de materiale in format electronic. Aceste facilitati sint obtinute fara a fi necesara parasirea mesei de lucru. Pe de alta parte, comunicarea se poate realiza la momentul ales de initiator.

Astazi, multe site-uri web au grupuri de discutii inglobate. Programe specializate ofera posibilitatea conectarii la un anume grup de discutii, in functie de preferintele solicitantului.

Se doreste realizarea unui un program care sa permita unui grup de discutii sa schimbe atat mesaje, lucru obisnuit in cazul grupurilor de discutii, cat si imagini si continut executabil.

Initiatorul grupului de discutii va trebui sa furnizeze informatii cu privire la momentul ales pentru declansarea discutiilor si sa puna la dispozitia celor interesati softul necesar participarii. In momentul in care un participant se conecteaza, initiatorul grupului de discutii trebuie sa fie, deja, in asteptarea cererilor, pentru a putea inregistra clientii. Dupa ce se inregistreaza la grupul de discutii, un participant poate lua parte, in mod efectiv, la conversatie.

Toti participantii au aceleasi drepturi. Cu toate acestea, managerul poate interveni pentru a opri din actiune un anume client care nu respecta regulile grupului de discutii.

2. Arhitectura aplicatiei

Aplicatia se executa pe un sistem distribuit format din mai multe masini, dintre care una joaca rol de server iar celelalte de clienti. Stabilirea serverului se face la pornirea sesiunii (masina de pe care se initiaza grupul de discutii va juca rolul de server pe parcursul existentei grupului respectiv).

Schematic, sistemul se prezinta astfel:

Fig. 1 – Schema grupului de discutii

Aplicatia este formata din mai multe module:

? modul server care are rol de coordonare si decizie in cadrul sistemului.;

? module clienti care se executa pe fiecare masina client.

Modulele client sunt constituite din trei sectiuni logice, fiecare tratind un alt aspect al comunicatiei. Cele trei sectiuni se ocupa, respectiv, de chat (discutii sub forma de text), transfer de informatie in format grafic si transfer de informatie sub forma unui continut executabil.

Arhitectura poate fi vazuta ca fiind de tipul client-server. Programele client ruleaza pe masini locale si solicita servicii, prin intermediul Internet-ului, serverului. Fiecare modul, dintre cele trei prezentate mai sus, are un corespondent pe masina client, cu care dialogheaza in vederea realizarii functionalitatii specifice. Pe masina server, programele reprezentind, primele doua module, ruleaza algoritmi ce au rolul de a implementa politici de alocare a drepturilor catre clienti. Clientii interactioneaza cu modulele locale prin intermediul unei interfete grafice, solicitind servicii catre server. Confirmarea primirii unui anume drept ii este adusa la cunostinta clientului prin intermediul modificarii unor controale grafice. Clientul poate decide pastrarea sau cedarea controlului intr-o masura limitata de catre server. Aceasta decizie este necesara pentru a pastra un anumit grad de echitate in ceea ce priveste alocarea drepturilor si durata acestei alocari.

Gestiunea clientlor conectati, la un moment dat, este tinuta de server intr-o baza de date.

La abandonarea discutiei, clientul anunta acest lucru server-ului. Din cind in cind, server-ul verifica daca un client cu care nu a mai comunicat un anume timp mai este activ. In caz ca nu primeste raspuns, clientul respectiv este scos din baza de date.

Server-ul primeste cereri de servicii de la clienti. In caz ca serviciul respectiv este disponibil, ele este oferit pe loc clientului. In caz contrar, clientul este inregistrat intr-o coada de asteptare, evoluind in cadrul acesteia in functie de o anumita politica. Clientul nu are posibilitatea sa mai faca o cerere pentru acelasi serviciu in caz ca cererea anterioara nu a fost, inca, acceptata. Are, insa, posibilitatea sa anunte ca renunta la cererea sa, fapt care se traduce, de partea server-ului, prin scoaterea clientului respectiv din coada de asteptare. Solicitarea unui client de a renunta la conexiunea cu server-ul duce, in mod automat, la scoaterea primului din toate cozile de asteptare asociate diverselor servicii solicitate anterior.

Clientii se pot decide asupra unuia sau mai multor servicii (dintre cele trei) de care vor sa beneficieze.

In ceea ce priveste alocarea drepturilor, aceasta se putea face si prin metoda votului, ceea ce ar fi dus la acordarea dreptului solicitat acelui participant care a obtinut cel mai mare numar de voturi din partea celorlalti. S-a renuntat la aceasta varianta deoarece, pe de-o parte, poate duce la inechitate, anumiti participanti putind fi favorizati de aprecierea unanima si, pe de alta parte, ar implica un schimb de mesaje suplimentar ce nu este binevenit, tinind seama de constringerile tehnice aparute in practica.

Ideea sincronizarii alocarii resurselor (detinerea simultana a dreptului de a desena si trimite text), ca modalitate de evolutie a sistemului, a fost abandonata, datorata unei anume lipse de naturalete si a overhead-ului implicat.