Aplicatii Distribuite Aplicatie Avand Ca Scop Gestiunea Unor Conturi Bancare

CUPRINS

CAPITOLUL 1

Aplicatii distribuite

1.1 Introducere

In ultimii ani, programarea distribuita apare tot mai des ca solutie la problemele din domeniul tehnologiei informatiei, probleme aparute o data cu dezvoltarea vertiginoasa a Internetului si in general a industriei calculatoarelor si a industriei informatiei.

Programarea distribuita poate fi privita, intr-o forma simpla, ca impartirea unei aplicatii in mai multe subunitati de procesare care pot fi distribuite intr-o retea de calculatoare, si care lucreaza cooperativ pentru a realiza o sarcina bine definita. Motivele pentru care ar fi necesara aceasta impartire ar fi multe dar pot fi mentionate cele mai comune si importante dintre ele:

Procesand sarcini in paralel prin impartirea problemei in parti mai mici se pot rezolva probleme mai complicate fara a apela la calculatoare mai complexe.

Seturile mari de date sunt in general mai usor de administrat fiind localizate intr-un singur loc anume. Astfel utilizatorii sunt nevoiti sa se bazeze pe servere de date situate la distanta, pentru a accesa datele cerute.

Agenti redundanti de procesare in retelele de calculatoare pot fi utilizati de catre sisteme care au nevoie de toleranta la erori. Astfel, daca unul dintre agenti se defecteaza, procesul poate continua.

1.2 Arhitectura unei aplicatii distribuite

O aplicatie distribuita este construita pe cateva straturi. La cel mai jos nivel, o retea conecteaza un grup de calculatoare gazda impreuna astfel incat acestea sa poata comunica intre ele. Protocoalele de retea ca TCP/IP permit comunicarea intre calculatoare oferind posibilitatea de a impacheta, de a adreasa, si de a trimite datele unui anumit calculator. Servicii de nivel mai inalt pot fi defininite peste protocolul de retea, ca de exemplu servicii de directoare sau protocoale de securitate. Aplicatia distribuita in sine, functioneaza deasupra acestor straturi, folosind serviciile de nivel mijlociu, protocoalele de retea cat si sistemele de operare, spre a realiza sarcini coordonate in retea.

Orice aplicatie care presupune interactiunea cu un utilizator, are ca parti principale o parte de prezentare (interfata cu utilizatorul), o parte de logica a aplicatiei (calculele si cursul aplicatiei), si o parte de date (datele necesare partii de logica). Aceste parti pot fi implementate de un singur program (aplicatie monolitica), sau pot fi implementate pe mai multe nivele. Aceasta ultima varianta se imparte, la randul ei, in doua variante de implementare:

Aplicatii two-tier (aplicatii pe doua nivele). Aceste aplicatii grupeaza partea de prezentare si partea de logica a aplicatiei pe o masina client in timp ce partea de date este situata pe o masina server, tipul de aplicatii two-tier reprezentand de altfel modelul clasic client–server.

Aplicatii three-tier (aplcatii pe trei nivele). In cazul aplicatiilor de tip three-tier, cele trei parti sunt separate conceptual, ele putand fi situate fiecare pe un calculator diferit. Aceasta varianta permite o flexibilitate mai mare a aplicatiilor deoarece clientul poate apela la serviciile mai multor servere pentru a satisface o cerere, iar serverul la randul sau poate apela serviciile altei componente server.

In principiu o aplicatie distribuita poate fi scrisa in orice limbaj care suporta comunicarea intre doua masini. In conditiile unei diversitati destul de ridicate a configuratiilor sistemelor de calcul, independenta de platforma a unui limbaj poate constitui un adevarat avantaj.

In ceea ce priveste modul in care se desfasoara comunicatia intre componentele unei aplicatii, exista mai multe variante printre care: modelul client-server, apelarea procedurii la distanta – RPC (Remote Procedure Call), etc.

1.3 Modele de programare a aplicatiilor distribuite

1.3.1 Modelul client-server

Comunicatia de tip client-server este una dintre primele aparute si cea mai utilizata pana in prezent. Acest model de comunicatie se bazeaza pe transferul de mesaje. Avantajul principal consta in eficienta executiei. Comunicatia are loc fara sa fie stabilita mai inainte o conexiune intre client si server, clientul trimitand o cerere iar serverul raspunzand cu datele solicitate. Dezavantajul comunicatiei de tip client-server consta in dificultatea de programare, programatorul trebuind sa apeleze explicit functiile de transfer de mesaje. Din acest motiv a fost necesara dezvoltarea unor alte modele de programare distribuita, care pornind tot de la transferurile de mesaje ca operatii de baza, sa ofere o interfata de programare mai simpla.

1.3.2 Apelul procedurilor la distanta (RPC – Remote Procedure Call)

Ideea de la care a pornit dezvoltarea acestei arhitecturi este apelarea procedurilor pe alt procesor. Atunci cand un proces de pe o masina apeleaza o procedura de pe cea de a doua masina, procesul apelant este suspendat si procedura apelata se executa pe cealalta masina. Informatiile pot fi transferate de la apelant la apelat sub forma unor parametrii si pot fi returnate sub forma rezultatelor procedurii, transferurile de mesaje fiind complet transparente programatorului.

Scopul RPC este de a face un apel de procedura la distanta sa para pe cat mai posibil un apel local, fara ca programatorul sa lucreze direct cu soclurile, comunicatia efectuandu-se la nivel de procedura. Cel mai simplu mod de a apela procedurile la distanta este de a lega clientului o biblioteca de proceduri numita stub-ul clientului. Stub-ul clientului reprezinta procedura serverului in spatiul de adresa al clientului. In mod similar, serverul este legat la o biblioteca care se numeste skeleton. Aceste biblioteci au rolul de a ascunde faptul ca apelul procedurii nu este local.

Procedura clientului trebuie sa apeleze stub-ul clientului care are acelasi nume ca procedura serverului. Din moment ce procedura clientului si stub-ul clientului se afla in acelasi spatiu de adresa, parametrii sunt pasati in mod obisnuit. Similar procedura serverului este apelata de o procedura din spatiul sau de adrese, pasandu-i-se parametrii primiti de la client. Astfel comunicatia intre cele doua masini este mascata de simplul apel al unei proceduri.

In figura 1, este prezentata structura modelului RPC:

Fig.1 Structura modelului de comunicatie RPC

Comunicatia de tip RPC se face in felul urmator:

Procedura client apeleaza stub-ul clientului.

Stub-ul clientului impacheteaza parametrii intr-un mesaj pe care il trimite kernel-ului. Impachetarea parametrilor se numeste marshaling.

Kernel-ul clientului trimte mesajul kernel-ului serverului.

Kernel-ul serverului trimite mesajul skeleton-ului.

Skeleton-ul despacheteaza parametrii mesajului si apeleaza procedura server-ului cu acestia.

Procedura se executa iar rezultatul se trimite skeleton-ului.

Skeleton-ul impacheteaza rezultatul intr-un mesaj si il trimite kernel-ului.

Kernel-ul serverului trimite mesakul catre kernel-ul masinii client.

Kernel-ul clientului preia mesajul pasand rezultatul stub-ului clientului.

10) Stub-ul clientului despacheteaza rezultatul din mesaj si il returneaza procedurii client.

RPC are si dezavantaje ca:

Pasarea ca parametru a pointerilor. Acest lucru nu este posibil deoarece spatiile de adresa ale masini client si cele ale masinii server difera.

Slabiciunea anumitor limbaje de programare. De exemplu, imposibilitatea impachetarii ca parametri a vectorilor. Nu se poate face acest lucru deoarece nu se stie dimensiunea exacta a vectorilor, lucru posibil in C, unde se pot declara vectori fara a fi nevoie a se specifica dimensiunea maxima a lor.

Utilizarea variabilelor globale. Comunicarea intre procedura apelanta si cea apelata nu se mai poate face prin intermediul variabilelor globale, deoarece spatiile de adrese corespunzatoare celor doua proceduri nu mai coincid.

1.3.3 Programarea distribuita obiect-orientata

Programarea obiect-orientata distribuita extinde un sistem de programare obiect-orientat permitand obiectelor sa fie distribuite intr-o retea heterogena, astfel incat sa interopereze ca un intreg. Aceste obiecte pot fi localizate pe calculatoare diferite intr-o retea, sa existe in propriul spatiu de adrese si totusi sa para ca fiind locale unei aplicatii. Obiectele distribuite constituie un instrument cu potential foarte ridicat, instrument care s-a dezvoltat mai mult in ultimii ani. Avantajul obiectelor distribuite consta in posibilitatea ca orice componenta situata intr-un anumit calculator sa interactioneze direct cu un anumit obiect, situat la distanta (pe un alt calculator din retea). Scopul majoritatii sistemelor distribuite obiect orientate este de a permite oricarui obiect sa poata fi localizat oriunde in retea, si sa permita aplicatiilor sa interactioneze cu ele ca si cum ar fi locale. Alte sisteme distribuite obiect orientate au si facilitati precum ar fi posibilitatea construirii unui obiect pe un calculator si transmiterea lui pe un altul, sau posibilitatea unei componente de a crea un obiect nou pe un alt calculator. Eficienta utilizarii obiectelor distribuite este mai evidenta in cazul aplicatiilor mai mari si mai compilcate.

1.4 Modele de programare distribuita obiect-orientata

1.4.1 DCOM (Distributed Component Object Model)

DCOM reprezinta solutia Microsoft pentru programarea distribuita bazata pe obiecte. DCOM este de fapt un sistem de transmitere a mesajelor, un model de comunicare intre obiecte COM, cu servicii de comunicare intre documentele compuse OLE (Object Linking and Embedding), si gestiunea lor. DCOM separa interfetele obiectelor de implementarile lor. Pentru reutilizarea obiectelor, DCOM prezinta mecanisme de agregare si delegare. Prin mecanismul de agregare, obiectul exterior expune interfetele obiectelor interioare ca si cum ar fi ale sale iar prin mecanismul de delegare obiectul exterior retransmite delegarile de metode catre obiectele interioare. Practic o interfata DCOM poate fi vazuta ca o interfata de functii, clientul accesand functiile respective printr-un pointer, interfetele DCOM neputand fi instantiate si neavand stari. Pentru suportul obiectelor distribuite, DCOM foloseste un protocol denumit ORPC (Object Remote Procedure Call), protocol derivat din mai vechiul protocol RPC. DCOM se foloseste cu preponderenta sub platformele Windows dar exista si implementari sub UNIX.

1.4.2 Java RMI (Java Remote Method Invocation)

Java RMI respecta indeaproape structura RPC dar si modelul obiect-orientat permitand crearea unor obiecte ale caror metode pot fi apelate de pe alte masini virtuale JVM (Java Virtual Machine). De asemenea, facilitatea serializarii obiectelor (posibilitatea obiectelor de a fi transformate in stream-uri) permite transferul instantei unui obiect prin valoare de la un calculator la altul. Din moment ce RMI se bazeaza exclusiv pe Java, toate interfetele obiectelor, atat clientul cat si serverul trebuiesc scrise in Java. Pentru a localiza prima data un obiect server, RMI depinde de un mecanism RMIRegistry, mecanism ce ruleaza pe server si detine informatii referitor la obiectele server disponibile. Un client Java RMI cauta o referinta la un obiect server si ii apeleaza metodele ca si cum ar fi un obiect local. Obiectele server Java RMI, sunt numite folosind URL-uri (URL – Uniform Resource Locator), deci pentru a obtine o referinta la un obiect server, trebuie specificat URL-ul obiectului, la fel ca la o pagina HTML (HyperText Markup Language). Protocolul folosit de Java RMI este JRMP (Java Remote Method Protocol). Un alt lucru de mentionat este ca Java RMI este disponibil pe orice platforma pe care exista o masina virtuala JVM.

1.4.3 Microsoft .Net

Microsoft .Net este o platforma si o tehnologie complet noua, care prezinta viziunea companiei asupra Internetului, viziune conform careia Internetul va fi constituit de un numar infinit de aplicatii web interoperabile, care impreuna formeaza o retea globala de servicii de schimb, aceste servicii avand la baza protocolul SOAP (Simple Object Access Protocol) si XML (eXtensible Markup Language).
nguage).

Microsoft .Net Remoting inlocuieste DCOM-ul. Principiul de baza este descris in continuare. Metodele apelate de client fiind implementate intr-un obiect la distanta, clientul trebuie sa foloseasca un proxy, care arata ca un obiect real, cu aceleasi metode publice. Cand se apeleaza metodele proxy-ului, se genereaza mesaje care sunt serializate prin intermediul unei clase formatter, si apoi sunt trimise printr-un “canal” al clientului. Acesta comunica cu partea serverului de “canal”, pentru a transfera mesajele. Odata ajunse la server, mesajele sunt deserializate tot de o clasa formatter, iar apoi directionate catre obiectul respectiv. Atat “formatter”-ul cat si proxy-ul sunt generate de automat. Obiectul server este instantiat intr-un proces pe calculatorul la distanta. Atat serverul cat si clientul trebuiesc configurate prin intermediul unui fisier in care sunt specificate URL-ul obiectului server (adresa calculatorului, portul, protocolul, numele serverului, numele obiectului). Acest fisier este citit de catre o metoda “Configure()”, el ne necesitand o recompilare in cazul modificarii lui.

Fata de DCOM, Microsoft .Net vine cu cateva noutati. De exemplu, la DCOM programatorul trebuia sa inregistreze componenta pe server (informatiile trebuiau reactualizate in registrii), in timp ce la .Net, componentele, cunoscute si sub denumirea de assemblies (ansambluri), nu trebuie decat sa se situeze in acelasi director cu aplicatia. Fisierele “ansamblu” contin toate informatiile necesare in sectiuni denumite manifests. Cand aplicatia client cere o instanta a unei componente, .Net cauta in directorul respectiv assembly-ul, interogand manifest-urile acestuia pentru a afla ce clase contine acea componenta. ). Mai multe detalii despre Microsoft .NET vor fi prezentate in capitolul urmator.

1.4.4 CORBA (Common Object Request Broker Architecture)

CORBA este un standard elaborat de OMG (Object Management Group), reprezentand de fapt un cadru de dezvoltare a aplicatiilor distribuite in medii heterogene. In arhitectura CORBA, totul depinde de un ORB (Object Request Broker) care se comporta ca o magistrala centrala de obiecte, prin care fiecare obiect CORBA interactioneaza transparent cu alte obiecte CORBA locale, sau la distanta. Fiecare obiect CORBA are o interfata si ofera niste metode. Pentru a accesa metodele unui obiect server, un client CORBA capata o referinta la obiectul respectiv, ORB-ul fiind responsabil cu gasirea implementarii obiectului, pregatirea lui in vederea deservirii cererii, transmiterea cererii catre acesta si transmiterea rezultatului inapoi. Interactiunea intre un obiect si ORB se face fie prin interfata ORB-ului, fie printr-un OA (Object Adapter). OA este de doua feluri: BOA (Basic Object Adapter) si POA (Portable Object Adapter), o varianta mai noua a BOA, cu multe imbunatatiri. Fiind doar o specificatie, CORBA poate exista pe o varietate mare de platforme, atat timp cat exista o imlementare ORB pentru acea platforma. Protocolul folosit de CORBA este GIOP (General Inter-ORB Protocol) sau IIOP (Internet Inter-ORB Protocol

CAPITOLUL 2

Tehnologia Microsoft .NET

2.1 Introducere

Tehnologia .NET, dezvoltata de gigantul Microsoft, se bazeaza pe asa numitul “.NET Framework”, care este o platforma de calcul care simplifica dezvoltarea aplicatiilor in mediul puternic distribuit al Internetului. Acest .NET Framework este conceput astfel incat sa satisfaca urmatoarele obiective:

Sa ofere un mediu consistent de programare, obiect-orientat, indiferent daca codul obiectului este stocat si executat local, executat local dar distribuit pe Internet, sau executat la distanta.

Sa ofere un mediu de executie a codului care sa minimizeze desfasurarea software-ului si conflictele de versiune.

Sa ofere un mediu de executie a codului care sa garanteze executia sigura a codului, incluzand codul creat de dezvoltatori (third-party) necunoscuti sau necertificati.

Sa ofere un mediu de executie a codului care sa elimine problemele de performanta ale mediilor scripted sau interpreted.

Sa faca experienta dezvoltatorului consistenta in cazul variatelor tipuri de aplicatii, cum ar fi aplicatiile de tip Windows-based si aplicatiile de tip Web-based.

Sa construiasca toate comunicatiile pe standarde industriale care sa asigure faptul ca codul bazat pe .NET Framework poate fi integrat in orice alt cod.

2.2 Prezentare generala

Platforma .Net este mult mai mult decat un nou limbaj , software development kit (SDK), sau chiar un sistem de operare. Ofera servicii noi foarte puternice, un nou format binar independent de procesor, noi limbaje, extensii pentru limbaje vechi si lista continua. Folosirea eficienta a acestor noi unelte si aplicatii, nu este posibila cunoastere buna a platforma ce va da viata aplicatiilor.

Premiza din spatele platformei .NET este ca lumea calculatoarelor se schimba de la un calculator conectat la servere prin retele de genul Internetului, la un calculator unde toate felurile de device-uri inteligente, calculatoare si servicii, lucreaza impreuna pentru a oferi o experienta mai bogata utilizatorului. Platforma .NET este raspunsul acestor provocari pe care schimbarea le va aduce programatorilor.

Platforma .NET este formata din mai multe componente, care pot fi grupate in trei categorii de baza:

.NET Framework – o aplicatie complet noua pentru dezvoltarea platformelor.

Produse .NET – diverse aplicatii Microsoft bazate pe .NET Framework, incluzand noi versiuni de Exchange si SQL Server, XML – toate integrate in platforma .NET.

Servicii .NET – mai multe servicii .NET, asigurate de Microsoft pentru folosire in dezvoltarea aplicatiilor ce merg pe .NET Framework. Foarte importante si de amintit sunt serviciile Web (Web Services).

Insusi .NET Framework poate fi divizat in trei parti:

CLR (Common Language Runtime) este un mediu de executie care se ocupa de alocarea memoriei, captarea erorilor si interactiunea cu serviciile sistemului de operare.

Base Class Library este o colectie extinsa de componente pentru programare si aplicatii pentru interfete de programare (API).

Doua tinte de dezvoltare de nivel inalt. Una dintre ele este pentru aplicatiile Web (ASP.NET) si alta pentru aplicatii normale Windows (Windows Forms).

Avantajele oferite de catre .NET Framework includ cicluri mai rapide de dezvoltare (refolosirea codurilor, mai putine surprize de programare, suport pentru mai multe limbaje de programare), mai putine bug-uri legate de tipul datelor datorita securitatii integrale, scurgere de memorie redusa datorita Garbage Collector-ului si, in general, aplicatii sigure.

CLR-ul (common language runtime), este fundatia .NET Framework. Va puteti gandi la runtime ca la un agent care administreaza codul in momentul executiei, oferind servicii de baza precum managementul memoriei, managementul thread-urilor, si servicii de lucru la distanta, in timp ce promulga siguranta tipurilor si alte forme de acuratete a codului, care asigura securitate si robustete. De fapt, conceptual de management al codului este un principiu fundamental al runtime-ului. Codul care vizeaza runtime-ul este cunoscut ca managed code iar codul care nu vizeaza runtime-ul este cunoscut ca unmanaged code. Biblioteca de clase, cealalta componenta principala a Framework-ului .NET, este o colectie cuprinzatoare, obiect-orientata, de tipuri reutilizabile care poate fi folosita pentru dezvoltarea variatelor aplicatii, pornind de la aplicatiile traditionale in linie de comanda sau cu interfata grafica (GUI – Graphical User Interface), pana la aplicatii bazate pe ultimele inovatii oferite de ASP.NET, inovatii precum Web Forms sau XML Web services.

FiFig.2 Arhitectura platformei .NET

In figura 2 este reprezentata arhitectura platformei .NET. In esenta, familiile de limbaje .NET sunt compilate fiecare in MSIL (Microsoft Intermediate Language), iesirea respectand specificatiile Common Language. Aplicatiile primare de dezvolatare sunt Web Forms, Web Services si aplicatii Windows Forms. Aceste aplicatii comunica folosind XML si SOAP(Simple Object Access Protocol), luandu-si functionalitatea din Base Class Library si functionand in interiorului mediului CLR.

2.3. Caracteristici ale platfomei .NET

Nucleul platformei .NET este gasit in CLR(Common Language Runtime), BCL(Base Class Library) si CLS(Common Language Specification). BCL-ul expune caracteristicile CLR-ului in acelasi fel in care API-ul da voie sa utilizezi caracteristicile sistemului de operare Windows, insa mai asigura foarte multe caracteristici de nivel inalt care faciliteaza refolosirea codului. Aceasta arhitectura aduce foarte multe beneficii, una fiind consistenta API-ului. Scriind in CLR si folosind .NET BCL toate caracteristicile aplicatiilor sunt folosibile printr-un model de programare orientat pe obiecte comun. Astazi unele dintre caracteristicile sistemului de operare sunt accesate prin apeluri DLL folosind API-uri scrise in C si alte facilitati accesate prin obiecte COM, dezvoltatorul depunand mai mult efort pentru a face ca totul sa lucreze eficient. Unele dintre aceste caracteristici sunt disponibile numai programatorilor ce lucreaza in lmbaje de nivel mic fortand decizii de desing.

Acest nou model de programare siplifica foarte mult eforturile ce erau depuse scriind aplicatii Windows DNA, sau aproape orice proiect Win32 sau COM. Dezvoltatorii nu mai au nevoie sa fie un guru al arhitecturii Windows sau COM cu o intelegere aprofundata a GUID-urilor, si ale metodelor de interfata Iunknown, AddRef, Release, al pointerului generic HRESULTS, si altele. .NET nu numai ca acunde acestea de programator, in noua platforma .NET aceste concepte pur si simplu nu exista.

Alt mare beneficiu pentru programatorii .NET este modelul de Error Handling (gestiunea erorilor) prin exceptii. Creand software pentru platformele Windows a insemnat intotdeauna sa fi prins in propriile inconsistente. Unele functii ar returna coduri de eroare Win32, altele ar returna HRESULTS si unele ar genera exceptii, toate fortand programatorul sa scrie diferite tipuri de coduri pentru gestionarea erorilor. In .NET toate erorile sunt raportate prin exceptii ceea ce simplifica foarte mult scrierea, citirea si ingrijirea codului. Gratie CLS-ului si CTS-ului (Common Type System), exceptiile .NET functioneaza de asemenea dealungul modulelor si granitelor de limbaj.

2.3.1 Dezvoltarea multilimbaj

Pentru ca foarte multe limbaje au ca tinta CLR-ul .NET, este acum mult mai usor sa implementezi portiuni din propriile aplicatii folosind limbajul cel mai potrivit. Metode mai vechi dau voie limbajelor de programare diferite sa interopereze, cum COM sau CORBA au facut astfel folosind IDL (Interface Definition Language). Platforma .NET da voie limbajelor sa fie integrate una cu alta folosind MSIL (Microsoft Intermediate Language). Desi contine instructiuni ce par similare cu codul de asamblare, cum ar fi operatiile de mutare si scoatere a valorilor si variabilelor din si in registrii, contine de asemenea instructiuni pentru ingijirea obiectelor si invocarea metodelor lor, mainpuland matrici si generand si prinde exceptiile.

Limbajul Microsoft CLS descrie ce alti autori de unelte de dezvoltare ar trebui sa faca pentru ca compilatoarele lor sa scoata codurile ce le dau voie sa integreze usor cu alte limbaje .NET. Microsoft asigura in momentul de fata mai multe compilatoare ce produc codurile ce au ca tinta runtime-ul limbajului comun: C++, C#, Jscript si Visual Basic. In plus, alte companii, in afara de Microsoft, produc compilatoare de limbaje ce au de asemenea ca tinta CLR-ul .NET. In momentul de fata diversi producatori au anuntat aparitia suportului necesar pentru COBOL, Eiffel, Fortran, Perl, Python, Scheme si multe altele.

Mostenirea limbajelor cross-language este o alta caracteristica facuta posibila prin folosirea libajului intermediar (IL). Astfel se poate crea o noua clasa bazata pe componente scrise in alte limbaje, fara sa fie nevoie de codul sursa al componentei de baza. De exemplu, se poate crea o clasa in C++ care este derivata dintr-o clasa implementata in visual Basic. .NET poate permite aceasta pentru ca defineste si sigura un tip de sistem comun tuturo limbajelor .NET.

Una dintre marile greutati a dezvoltarii de aplicatii sub specificatiile Windows DNA a fost constituita de catre debuggingul aplicatiilor dezvoltate intr-o varietate de limbaje. Multumita dezvoltarii unificate a mediului Visual Studio .NET si folosirii limbajului intemediar ca iesire al tuturor limbajelor .NET, debuggingul limbajelor cross-language este posibil fara a apela la asamblarea limbajelor. Runtime-ul limbajului comun .NET suporta integral debug-ul aplicatiilor ce trec de granitele limbajelor. Runtime-ul asigura de asemenea facilitati integrate de parcurgere a stivei, facand mult mai usoara localizarea bug-urilor si erorilor.

2.3.2 Platforma si independenta fata de procesor

Limbajul intermediar este independent fata de procesor si este mult mai inalt ca nivel fata de majoritatea limbajelor dependente de masina. Odata scrisa si construita, o aplicatiei .NET se poate executa pe orice platforma ce suporta runtime-ul limbajulului comun .NET. Pentru ca CTS-ul .NET defineste marimea tipurilor de date de baza care sunt valabile aplicatiilor .NET, si aplicatiile functioneaza in interiorul mediului runtime-ului limbajului comun, dezvoltatorul aplicatiei este scutit de specificatiile oricarui hardware sau sistem de operare ce suporta platforma .NET.

2.3.3 Managementul automat al memoriei

Programatorii ce cunosc Visual Basic sau COM sunt familiarizati cu tehnica de numarare prin referinta. Aceasta tehnica salveaza memoria folosita de catre un obiect cand nici un alt obiect nu are o referinta catre el, in mod esential atunci cand nu mai este nevoie de el. Desi suna perfect in teorie, practic are cateva probleme. Una dintre acestea este referinta circulara spre problema atunci cand un obiect contine o referinta catre alt obiect care contine de asemea o referinta catre primul obiect. Cand managerul de memorie cauta obiecte ce nu mai sunt in uz, aceste obiecte vor avea intotdeauna un numar de referinta mai mare de zero, deci daca nu sunt distruse implicit, memoria lor nu va mai putea fi salvata. Pentru un programator C sau C++, asta este perfect normal si un bun motiv pentru a nu avea incredere in nimeni altcineva sa aiba grija de resurse, insa in mediul .NET, Microsoft incearca sa faca dezvoltarea de software mult mai simpla.

Framework-ul .NET poate fi suportat de componente de tip unmanaged care incarca CLR-ul (common language runtime) in procesele lor si initiaza executia codului de tip managed, in felul acesta creand un mediu software care poate exploata atat trasaturile de tip managed cat si pe cele de tip unmanaged. .NET Framework nu ofera doar cateva suporturi pentru runtime, ci permite si dezvoltarea de suporturi pentru runtime de catre dezvoltatorii third-party.

De exemplu, ASP.NET suporta runtime-ul pentru a oferi un mediu scalabil si orientat catre server pentru codul de tip managed. ASP.NET lucreaza direct cu runtime-ul pentru a permite aplicatii de tip Web Forms sau servicii de tip XML Web.

Urmatoarea ilustratie arata relatia CLR-ului si a bibliotecii de clase cu aplicatiile utilizatorului si cu sistemul. Ilustratia mai arata si cum codul de tip managed opereaza in cadrul unei arhitecturi mai mari.

Figura 3. Relatia dintre CLR si aplicatiile utilizatorului si sistem

Internet Explorer este un exemplu de aplicatie de tip unmanaged care suporta runtime-ul (sub forma unei extensii de tip MIME). Folosind Internet Explorer pentru a suporta runtime-ul, permite incoroporarea componentelor de tip managed sau a controalelor de tip Windows Forms in documente HTML. Suportand runtime-ul in acest fel, face codul mobil de tip managed (similar controalelor ActiveX) posibil, dar cu imbunatatiri semnificative pe care doar codul de tip managed le poate oferi, precum executia de tip semitrusted si stocarea sigura a fisierelor izolate.

Urmatoarele sectiuni vor descrie principalele componente si trasaturi ale arhitecturii .NET mai detaliat.

2.3.4 Trasaturi ale CLR-ului (Common Language Runtime)

CLR-ul administreaza memoria, executia thread-urilor, executia codului, verificarea sigurantei codului, compilarea, si alte servicii ale sistemului. Aceste trasaturi sunt intrinseci codului de tip managed care ruleaza pe CLR.

Cu privire la securitate, componentelor de tip managed li se acorda variate grade de incredere, in functie de un numar de factori care includ originea acestora (precum Internet-ul, retea enterprise sau computer local). Aceasta inseamna ca o componenta de tip managed s-ar putea, sau nu, sa poata efectua operatii de acces la fisiere, operatii de acces la registrii sau alte functii senzitive chiar daca este folosita in cadrul aceleiasi aplicatii active.

Runtime-ul promulga securitatea accesului la cod. De exemplu, utilizatorii pot avea incredere ca un executabil incorporat intr-o pagina web poate reproduce o animatie pe ecran sau poate reproduce un cantec, dar nu poate accesa datele lor personale, sistemul de fisiere sau retea. Trasaturile de securitate ale runtime-ului permit software-ului desfasurat pe Internet sa aiba o gama foarte variata de caracterstici.

Runtime-ul, de asemenea, mai promulga robustetea codului, implementand o infra-structura de verificare stricta a tipului, respectiv codului, denumita CTS (Common type system). CTS-ul se asigura de faptul ca tot codul de tip managed este autodescriptiv. Diversele compilatoare de limbaj de la Microsoft sau de la firme de tip third-party genereaza cod de tip managed care este conform cu sistemul de tipuri comune (CTS-ul). Aceasta inseamna ca acel cod de tip managed poate consuma alte tipuri si instante de tip managed, in acelasi timp promulgand fidelitatea si securitatea tipurilor.

In plus, mediul de tip managed al runtime-ului elimina multe probleme comune ale software-ului. De exemplu, runtime-ul manevreaza automat aranjarea obiectelor si administreaza referintele la obiecete, eliberandu-le atunci cand acestea nu mai sunt folosite. Acest management automat al memoriei rezolva cele mai intalnite doua erori ale aplicatiilor, si anume scurgerile de memorie (memory leaks) si referentieri invalide ale memoriei (invalid memory references).

Runtime-ul de asemenea accelereaza productivitatea dezvoltatorului. De exemplu, programatorii pot scrie aplicatiile intr-un limbaj de dezvoltare, la alegere, si totusi sa profite de avantajele runtime-ului, ale bibliotecii de clase, si a componentelor scrise in alte limbaje, de catre alti dezvoltatori. Orice ofertant de compilatoare care alege sa vizeze runtime-ul poate proceda asa. Compilatoarele de limbaj care vizeaza Framework-ul .NET fac trasaturile .NET Framework disponibile codului existent, scris in acel limbaj, usurand foarte mult procesul de adaptare pentru aplicatiile existente.

Cu toate ca runtime-ul este conceput pentru software-ul viitorului, el accepta si aplicatii actuale sau mai vechi. Interoperabilitatea intre codul de tip managed si cel de tip unmanaged le permite dezvoltatorilor sa continue sa foloseasca componente COM (Component Object Model) si DLL-uri (Dynamic Link Library) necesare.

Runtime-ul este conceput sa sporeasca performanta. Cu toate ca CLR-ul ofera multe servicii standard de tip runtime, codul de tip managed nu este niciodata interpretat. O trasatura care se numeste Just-In-Time Compiling (JIT) permite oricarui cod de tip managed sa ruleze in limbajul nativ-masina al sistemului pe care se executa. Intre timp, managerul memoriei inlatura posibilitatile fragmentarii memoriei si creste pozitia referintelor, pentru a spori si mai mult performantele.

In cele din urma, runtime-ul poate fi suportat de aplicatii ultra-performante, orientate catre server, precum Microsoft SQL Server si Internet Information Services (IIS). Aceasta infrastructura permite utilizarea codului de tip managed pentru scrierea logicii afacerii, si in acelasi timp savurarea performantei superioare ale celor mai bune servere de tip enterprise ale industriei, care ofera suport runtime.

2.3.5 Biblioteca de clase .NET Framework

Biblioteca de clase .NET Framework este o colectie de tipuri reutilizabile care se integreaza strans cu CLR-ul. Bibiloteca de clase este obiect-orientata, oferind tipuri de la care codul personal de tip managed poate deriva in functionalitate. Acest lucru nu numai ca face tipurile .NET Framework usor de folosit, dar de asemenea reduce timpul asociat invatarii unor noi trasaturi ale .NET Framework. In plus, componentele de tip third-party se pot integra dintr-o singura bucata cu clasele .NET Framework.

De exemplu, colectia de clase .NET Framework implementeaza un set de interfete care pot fi folosite pentru dezvoltarea colectiilor de clase personale. Colectia personala de clase se va imbina strans cu clasele din .NET Framework.

Dupa cum e de asteptat de la o colectie de clase obiect-orientata, tipurile .NET Framework permit realizarea unei serii de sarcini uzuale de programare, incluzand sarcini precum managementul sirurilor, colectarea datelor, conectivitatea la bazele de date si accesul la fisiere. In plus fata de aceste sarcini uzuale, biblioteca de clase include tipuri care suporta o variata gama de scenarii de dezvoltare specializata. De exemplu, se poate folosi .NET Framework pentru a dezvolta urmatoarele tipuri de aplicatii si servicii:

Aplicatii in mod consola.

Aplicatii de tip scripted sau hosted.

Aplicatii cu interfata grafica cu utilizatorul (GUI) pentru Windows (Windows Forms).

Aplicatii ASP.NET.

Servicii XML Web.

Servicii Windows.

De exemplu, clasele Windows Forms formeaza un set curpinzator de tipuri reutilizabile, care simplifica mult dezvoltarea interfetelor grafice cu utilizatorul (GUI). In cazul scrierii unei aplicatii ASP.NET Web Form, se pot folosi clasele Web Forms.

2.3.6 Dezvoltarea aplicatiilor client

Aplicatiile client sunt cele mai apropiate fata de stilul traditional al aplicatiilor in programarea Windows-based. Acestea sunt tipurile de aplicatii care afiseaza ferestre sau form-uri pe dektop, permitand utilizatorului sa efectueze o sarcina. Aplicatiile client includ aplicatii de tipul procesoarelor de text si spreadsheets, precum si aplicatii de afaceri personalizate, ca de exemplu instrumente de introducere a datelor, instrumente de raportare, si asa mai departe. Aplicatiile client, de obicei folosesc ferestre, meniuri, butoane si alte elemente de interfata grafica cu utilizatorul (GUI), si cel mai probabil acceseaza resurse locale precum sistemul de fisiere, si periferice precum imprimante.

Un alt fel de aplicatie client o reprezinta traditionalele controale ActiveX (acum inlocuite de controlul de tip managed Windows Forms) desfasurate pe Internet, sub forma unei pagini web. Aceasta aplicatie este foarte asemanatoare cu orice alta aplicatie client: este executata firesc, are acces la resursele locale, si include elemente grafice.

In trecut, dezvoltatorii creasera astfel de aplicatii folosind C/C++ impreuna cu MFC (Microsoft Foundation Classes), sau cu un mediu rapid de dezvoltarea a aplicatiilor,( RAD – Rapid Application Development), precum Visual Basic. Framework-ul .NET incorporeaza aspecte ale acestor produse existente, intr-un singur mediu de dezvoltare, consistent, care simplifica in mod drastic dezvoltarea aplicatiilor client.

Clasele Windows Forms continute in .NET Framework, sunt concepute pentru a fi folosite pentru dezvoltarea interfetelor grafice cu utilizatorul (GUI). Se pot usor crea ferestre de comanda, butoane, meniuri, bare de instrumente si alte elemente de interfata, cu flexibilitatea necesara adaptarii nevoilor afacerilor, aflate in continua schimbare.

De exemplu, .NET Framework ofera simple proprietati pentru ajustarea atributelor vizuale asociate form-urilor. In unele cazuri, sistemul de operare de baza nu suporta schimbarea directa a acestor atribute, si in acest caz, .NET Framework recreaza automat form-urile. Acesta este unul din modurile prin care .NET Framework integreaza interfata dezvoltatorului, facand scrierea codului mai simpla si mai mai consecventa.

Spre deosebire de controalele ActiveX, controalele de tip Windows Forms au acces de tip semi-trusted la calculatorul unui utilizator. Aceasta inseamna ca codul binar sau nativ aflat in executie poate accesa unele dintre resursele sistemului utilizatorului (precum acces la elemente de tip GUI sau acces limitat la fisiere), fara a putea accesa sau corupe alte resurse. Din cauza securitatii privind accesul codului, multe aplicatii care trebuiau instalate pe sistemul utilizatorului, pot fi instalate in siguranta prin intermediul Web-ului. Propriile aplicatii pot implementa trasaturile unei aplicatii locale si totusi sa fie accesate precum o pagina web.

2.3.7 Dezvoltarea aplicatiilor server

Aplicatiile de tip server in lumea aplicatiilor dinamice, sunt implementate prin intermediul gazdelor runtime. Aplicatiile de tip unmanaged suporta CLR-ul (Common Language Runtime) care permite codului personalizat de tip managed sa controleze comportamentul serverului. Acest model ofera toate trasaturile CLR-ului si biblioteca de clase, profitand in acelasi timp de performanta si scalabilitatea serverului gazda.

Urmatoarea ilustratie prezinta schema de baza a unei retele, cu cod de tip managed ruland in medii server diferite. Servere precum IIS (Internet Information Services) si SQL Server pot efectua operatii standard in timp ce logica aplicatiei este executata prin intermediul codului de tip managed.

Figura 4. Schema de baza a unei retele, cu cod de tip managed

ruland in medii server diferite

ASP.NET este mediul gazda care permite dezvoltatorilor sa foloseasca framework-ul .NET pentru a viza aplicatiile de tip Web-based. Si totusi, ASP.NET este mai mult decat o gazda runtime; este o arhitectura completa pentru dezvoltarea siturilor Web si obiectelor distribuite pe Internet folosind codul de tip managed. Atat Web Forms cat si serviciile XML Web folosesc IIS si ASP.NET ca mecanism de publicare pentru aplicatii, si amandoua au o colectie de clase care le suporta in .NET Framework.

Serviciile XML Web, o evolutie importanta in tehnologia bazata pe web, sunt componente distribuite ale aplicatiilor server, similare siturilor Web obisnuite. Si totusi, spre deosebire de aplicatiile bazate pe Web, componentele serviciilor XML Web nu au interfata cu utilizatorul si nu sunt destinate browser-elor precum Internet Explorer sau Netscape Navigator. In schimb, serviciile XML Web constau in componente software reutilizabile concepute pentru a fi consumate de catre alte aplicatii, precum traditionalele aplicatii client, aplicatiile bazate pe Web, sau chiar alte servicii XML Web. Drept urmare, tehnologia serviciilor XML Web indreapta rapid dezvoltarea aplicatiilor si deployment-ul acestora catre mediul extrem de distribuit al Internetului.

Daca ati mai folosit versiuni precedente ale tehnologiei ASP (Active Server Pages), veti remarca imediat imbunatatirile pe care ASP.NET si Web Forms le ofera. De exemplu, se pot dezvolta pagini Web Forms in orice limba suportata .NET Framework. In plus, codul nu mai are nevoie sa imparta acelasi fisier cu textul HTTP (cu toate ca se poate acest lucru). Paginile Web Forms se executa in limbajul nativ masinii deoarece, ca orice alta aplicatie de tip managed, profita din plin de runtime. In contrast, paginile ASP de tip unmanaged sunt intotdeauna in forma scrisa si interpretate. Paginile ASP.NET sunt mai rapide, mai functionale, si mai usor de dezvoltat decat paginile ASP de tip unmanaged, deoarece ele interactioneaza cu runtime-ul ca orice alta aplicatie de tip managed.

.NET Framework ofera de asemenea o colectie de clase si instrumente pentru a ajuta in dezvoltarea si utilizarea de aplicatii XML Web services. Serviciile XML Web sunt construite pe standarde precum SOAP, XML si WSDL (Web Services Description Language). Framework-ul .NET este construit pe aceste standarde pentru a promova interoperabilitatea cu alte solutii decat cele oferite de Microsoft.

De exemplu, instrumentul WSDL inclus in kit-ul de dezvoltare software (SDK – Software Development Kit) al .NET Framework poate interoga un serviciu XML Web publicat pe Web, analiza descrierea sa WSDL, si produce cod sursa C# sau Visual Basic care poate fi folosit de catre aplicatie pentru a deveni un client al serviciului XML Web respectiv. Codul sursa poate crea clase derivate din clasele aflate in biblioteca de clase care sa manevreaze toata comunicatia de la nivelul inferior, folosind analiza XML si SOAP. Desi se poate folosi biblioteca de clase pentru a utiliza servicii XML Web direct, instrumentul WSDL (Web Services Description Language) precum si celelalte instrumente incluse in SDK, usureaza eforturile dezvoltarii cu ajutorul .NET Framework.

Daca dezvoltati si publicati propriul dumneavoastra serviciu XML Web, framework-ul .NET ofera un set de clase care sunt in concordanta cu toate standardele de comunicatie de la nivel inferior, precum SOAP, WSDL si XML. Folosirea acestor clase permite concetrarea asupra logicii serviciului fara preocuparea privind infrastructura comunicatiilor ceruta de dezvoltarea software-ului distribuit.

In cele din urma, precum Web Forms in mediul managed, propriile servicii XML Web vor rula cu viteza caracteristica limbajului nativ masinii folosind comunicarea scalabila a IIS (Internet Information Services).

2.4 .NET Remoting

Sistemele de operare asigura de obicei pentru fiecare aplicatie un nivel de protectie fata de efectele altor aplicatii. Aceste nivele de protectie sunt necesare pentru a proteja o aplicatie in cazul esecului altei aplicatii. Microsoft Windows a urmarit aceasta tehnica implementand procese pentru fiecare aplicatie. Fiecare aplicatie este astfel incarcata intr-un spatiu de proces separat. Codul si memoria folosita in fiecare proces nu poate accesa alt cod ce ruleaza intr-un proces diferit, desi exista metode bine definite, controlate de sistemul de operare, pentru a obtine acest lucru. In .NET Framework, Microsoft introduce conceptul de domeniul aplicatiei “Application Domain”.

2.4.1 Domeniul aplicatiei

Domeniile aplicatiei (AppDomains) sunt unitati pe care .NET Framework le foloseste pentru a asigura izolarea dintre doua aplicatii. Este posibil sa se ruleze mai multe domenii de aplicatii intr-un acelasi proces. Izolarea bazata pe AppDomains asigura cateva avantaje generale, mai ales pentru aplicatii server-side. Existenta diferitelor domenii de aplicatie in interiorul unui singur proces, inseamna ca daca orice parte de cod dintr-un domeniu de aplicatie nu functioneaza corect dintr-un motiv sau altul, acest lucru nu va afecta alte domenii de aplicatie din acelasi proces. Se poate deasemenea opri o parte de cod inclusa in domeniul aplicatiei. Oricum, cel mai important factor este acela ca codul rulat in AppDomain nu poate accesa cod dintr-un alt AppDomain. Procesul care este folosit pentru a asigura comunicatia dintre diferite obiecte din diferite AppDomain se numeste .NET Remoting.

Framework-ul .NET Remoting poate fi folosit pentru a activa comunicatia dintre doua aplicatii diferite. Aceste aplicatii se pot gasi pe aceeasi statie, intr-o retea LAN, pe Internet, sau in orice alta zona geografica conectata printr-un anume protocol.

Unul dintre avantajele .NET Remoting, deriva din faptul ca, spre deosebire de protocoalele folosite de Microsoft DCOM si Java RMI, Remoting este construit pe standarde acceptate, cum ar fi SOAP (Simple Object Access Protocol), HTTP si TCP. Acest lucru face posibil ca aplicatii diferite sa comunice pe Internet in acelasi fel ca in cazul unei conexiuni peste o retea privata.

Totusi, cu toate ca Remoting poate folosi protocoalele SOAP si HTTP, nu este obligat sa o faca. De fapt, merita sa te gandesti de doua ori inainte sa folosesti SOAP cu Remoting, deoarece se pierd unele din beneficiile de performata ale folosirii Remoting cu servicii Web ASP.NET. Daca este folosit mai de graba, Remoting decat serviciile Web, eficienta este probabil un factor semnificativ si pentru a obtine cea mai buna performanta trebui folosita codarea binara pe canalul TCP.

2.4.2 Functionarea .NET Remoting

Pentru a folosi framework-ul Remoting, aplicatia host trebuie mai intai incarcata si trebuie creat un canal si un port pentru ascultarea conexiunilor. Clientul trebuie sa creeze acelasi canal. Putem sa privim un canal ca un mediu de transport dintre server si client. Canalele folosesc protocoale de retea cum ar fi TCP sau HTTP pentru a trimite date de la un obiect la altul. Dupa de clientul a creat canalul, creaza o noua instanta a clasei Remote. Daca clientul reuseste sa instantieze un obiect remote, primeste o referinta la obiectul server prin care apela metode ale obiectului remote ca si cum ar fi facut parte din procesul client. Sistemul Remoting foloseste un proxy pentru a implementa acest lucru. Cand clientul creaza o instanta a obiectului remote framework-ul remoting intercepteaza apelul si creaza un obiect proxy cu aceeasi interfata publica ca si obiectul real si returneaza acest obiect proxy clientului. Clientul apoi apeleaza metode de pe acest proxy. Aceste apeluri sunt interceptate de framework-ul remoting si sunt rutate catre procesul server. Procesul server instantiaza apoi obiectul, apeleaza metoda, si trimite valoarea returnata aplicatiei client prin proxy-ul clientului.

Fig.5. Diagrama functionarii .NET Remoting

2.4.3. Canale (Channels)

Canalele sunt folosite pentru a transporta mesaje de la si catre obiectele remote. Cand un client apeleaza o metoda pe obiectul server, parametrii si alte detalii ale metodei sunt impachetate in interiorul unui mesaj si transportate printr-un canal si transportate la obiectul remote. Un client poate selecta orice tip de canal care a fost creat pe server pentru a fi folosit ca mediu de transport. Acest lucru permite programatorilor sa aleaga cel mai potrivit canal pentru nevoile lor. Desi exista doua tipuri de canal de transport incluse, exista posibilitatea exitinderii lor sau chiar a crearii unui tip de canal complet nou care sa fie folosit in medii sau scenarii specializate. Rezultatele sunt returnate de la server intr-un mod similar.

2.4.4 Sink-uri

Canalele ruteaza fiecare mesaj printr-o serie de sinkuri. Fiecare sink schimba sau filtreaza mesajul si apoi il transmite urmatorului sink din lant catre aplicatia destinatie sau canalului insusi. Pot exista un numar de sinkuri care proceseaza mesajele trimise prin canal in asa fel incat un sink de securitate (pentru criptarea mesajului), sau un sink de logare (pentru urmarirea procesului de remoting).

La client, primul sink este sinkul de formatare; acesta paseaza mesajul catre orice sinkuri personalizate implementate in lantul de sinkuri. La sfarsit mesajul ajunge in sinkul de transport care il scrie pe canalul de transport.

La server, intregul proces este inversat. Sinkul de transport primeste mesajul de pe canal si transmite mai departe lantului de sinkuri. Ultimul sink din lant este sinkul de formatare, care ruteaza mesajul catre infrastructura remoting in asa fel incat el sa poata fi transmis mai departe aplicatiei ce il asteapta:

Fig.6. Diagrama transmiterii de mesaje.

Exista doua tipuri de canale puse la dispozitie de .NET Framework:

TcpChannel

HttpChannel

2.4.5 Sink-uri de formatare

Sinkurile de formatare sunt folosite pentru codarea si decpdarea mesajelor inainte de transportarea lor prin canal. Exista doua sinkuri de formatare oferite de framework-ul .NET.

Sinkul de formatare binara. Canf formatarea binara este folosita pentru mesaje, atat clientul cat si serverul au nevoie de framework-ul .NET pentru a procesa mesajele. Sistemul de tipuri isi mentine starea in timpul executiei transmisiei folosind sinkul de formatare binara Deoarece sinkul de formatare binara se bazeaza pe framework-ul .NET, acesta poate pastra informatia despre sistemul de tipuri serializand sau deserializand obiectul.

Sinkul de formatare binara are performante mai bune decat sinkul de formatare SOAP deoarece se trimit mai putine date pe retea si deoarece necesita mai putin timp pentru serializare si deserializare.

Sinkul de formatare SOAP bazat pe XML. Sinkul de formatare SOAP urmareste specificatiile SOAP. Acest lucru permite interoperabilitatea cu alti clienti sau servere. Sinkul de formatare SOAP, putand include diferite implementari in diferite limbaje, nu poate pastra informatie despre sistemul de tipuri.

Deoarece sinkul de formatare SOAP este proiectat mai mult pentru interoperabilitate si mai putin pentru performata, are in general performante scazute pentru sinkul de formatare binara.

CAPITOLUL 3

Arhitectura si descrierea funtionala a aplicatiei

3.1 Prezentarea aplicatiei

In capitolele anterioare au fost prezentate conceptele de programare distribuita si facilitatile pe care le prezinta tehnologia .NET in acest sens. O ilustrare practica a acestor facilitati este necesara pentru a completa partea teoretica.

Lucrarea de fata propune o implementare practica a unei aplicatii distribuite bazata pe tehnologia Microsoft .NET, care sa permita gestionarea unor conturi bancare. Aplicatia propune existenta a doua tipuri de operatii:

Operatii de administrare; aceste operatii sunt specifice functionarilor bancii si permit urmatoarele tipuri de functii:

Operatii asupra clientilor, in aceasta categorie intrand urmatorarele functii:

Adaugarea unui client nou.

Stergerea unui client.

Modificarea cu acordul clientului a parolei acestuia

Operatii asupra conturilor si facturilor corespunzatoare unui client, aceste functii rezumadu-se la urmatoarele:

Adaugarea unui cont nou

Stergerea unui cont

Alimentarea unui cont

Extragerea unei sume de bani din cont

Blocarea unui cont

Deblocarea unui cont

Adaugarea unei facturi noi

Operatii de utilizare; acestea sunt accesibile clientilor bancii si implementeaza urmatorele functii:

Conectare la serverul bancii prin intermediul numelui si a unei parola

Deconectarea de la serverul bancii in cazul in care clientul este conectat

Transferul unei sume de bani intre conturile personale

Plata facturilor emise pe numele clientului respectiv

Vizualizarea extrasului de cont pentru un anumit cont al clientului

Toate informatiile referitoare la aceste conturi, facturi si la evidenta transferurilor efectuate sunt stocate intr-o baza de date de tip relational. Conexiunea intre nivelul business-logic si nivelul de date se va face prin intermediul ODBC (Open Databases Conectivity).

Interfata grafica a aplicatiei este realizata folosind Windows Forms care sunt clase special destinate interfetelor grafice (in assembly-ul System.Windows.Forms) , aceste interfete fiind implementate in limbajul de programare C#.

3.2 Structura aplicatiei

Fiind o aplicatie distribuita de tipul three-tier (trei straturi), se pot observa cu usurinta trei parti importante ale aplicatiei: partea de client sau asa numitul nivel de prezentare (partea de prezentare a aplicatiei, atat functionarul cat si clientul), partea de server sau nivelul de business-logic (partea ce se ocupa de implementarea operatiilor invocate de clienti sau functionari) si o parte de date denumita nivelul de date (baza de date relationala folosita de aplicatie).

Partea de client este compusa din doua module care implementeaza functionalitatile unui client, respectiv ale unui functionar.

Fig.7 Arhitectura aplicatiei

In figura 7 este prezentata arhitectura aplicatiei. Nivelul de prezentare este reprezentat de catre modulele client , respectiv functionar. Nivelul de business-logic este reprezentat de modulul server iar nivelul de date este reprezentat de baza de date.

3.3 Comunicatia intre clienti si server

Comunicatia intre clienti server se face prin intermediul .NET Remoting dupa principiul urmator: clientul obtine un proxy pentru obiectul de pe server si prin intermediul acestuia apeleaza metode, ca si cum ar fi un obiect local. Acest principiu este reprezentat in fig. 5. In cadrul sistemului .NET Remoting, comunicatia se face prin asa numitele canale de comunicatie (channels) , canale care sunt furnizate in doua variante : canale http si canale tcp. Canalul tcp foloseste o formatare binara care confera performanta sporita , acest tip de canal, impreuna cu formatarea binara fiind cea mai buna varianta d.p.d.v. al performantei. Canalul http foloseste protocolul SOAP (Simple Object Access Protocol) , toate mesajele fiind trecute printr-o formatare SOAP si transformate in mesaje XML(eXtensible Markup Language).

In lucrarea de fata am folosit pentru comunicatia intre clienti si server un canal de tip http , bazat pe o formatare SOAP.

3.4 Baza de date

Sistemul de gestiune a bazelor de date folosit este MySQL server, impreuna cu un driver pentru ODBC folosit la comunicatia intre server si SGBD. Baza de date se numeste “Banca” si este inregistrata ca sursa pentru userul curent in ODBC Data Source Administrator cu denumirea de “Banca-MySQL”.

Baza de date relationala contine patru tabele denumite Client, Cont, Factura, Extras, denumiri sugestive in ceea ce priveste continutul. Mai jos sunt detaliate tabelele:

Client

Aceasta tabela se refera la clientii bancii si contine urmatoarele informatii:

Un identificator al clientului (ID_client); este un camp de tip autonumber, adica un camp al carui continut este gestionat automat de catre SGBD. Trebuie mentionat ca acest camp constituie cheia primara a tabelei.

Numele clientului.

Prenumele clientului.

Parola clientului.

Un bit care desemneaza stadiul clientului (conectat/deconectat).

Cont

Aceasta tabela se refera la conturile pe care un client le detine, fiecare client putand detine mai multe conturi. Contine urmatoarele informatii:

Un identificator al contului (ID_cont); este un camp de tip autonumber, fiind in acelasi timp si cheia primara a tabelei.

Un identificator al posesorului contului (ID_client); este cheie straina in aceasta tabela, el facand legatura intre un cont si un client.

Numarul contului.

Suma disponibila in cont (soldul contului).

Un bit care desemneaza starea contului (blocat/deblocat).

Factura

Aceasta tabela se refera la facturile asociate unui client si contine urmatoarele informatii:

Un identificator al facturii (ID_factura); este un camp de tip autonumber si joaca rolul de cheie primara a tabelei.

Un identificator al clientului caruia ii este asociata factura; acest camp este cheie straina in aceasta tabela, el facand legatura intre o factura si clientul caruia ii apartine.

O descriere a facturii

Emitatorul facturii

Data emisiei facturii

Suma facturii

Extras

Aceasta tabela contine informatii referitoare la operatiile efectuate, operatii care au implicat un anumit cont. Contine urmatoarele informatii:

Un identificator al operatiei efectuate (ID_operatie); este un camp de tip autonumber fiind si cheie primara pentru aceasta tabela.

Un identificator al contului la care se raporteaza operatia (ID_cont); acest camp este cheie straina pentru acesata tabela, el facand legatura intre un cont si extrasul de cont corespunzator.

Codul operatiei; acesta este un camp care ia valoarea 1,2,3 sau 4, valori ce au urmatoarea semnificatie: 1 semnifica alimentarea contului cu o suma de bani, 2 semnifica extragerea unei sume de bani din cont, 3 semnifica o operatie de transfer din contul respectiv sau catre contul respectiv iar 4 semnifica plata unei facturi.

Descrierea operatiei.

Suma care a fost implicata in operatia respectiva.

Data la care s-a efectuat operatia respectiva.

Relatiile intre tabele sunt dupa cum urmeaza:

intre Client si Cont exista o relatie de tip one to many (Un client poate avea mai multe conturi)

intre Client si Factura exista o relatie de tip one to many, adica un client poate avea mai multe facturi

intre Cont si Extras exista o relatie de tip one to many, fiecare avand mai multe operatii asociate in tabela Extras.

3.5 Modulul server

Modulul server este destul de simplu in lucrarea de fata, el beneficiand din plin de avantajele tehnologiei .NET Remoting pentru a usura sarcina programatorului in ceea ce priveste scrierea codului pentru realizarea comunicarii. Astfel, prin intermediul unui fisier de configurare, denumit “Serve.config”, se specifica ansamblul si tipurile de obiecte publicate de server (de tip well-known), assembly-urile din care fac parte , precum si portul pe care serverul asculta cererile pentru obiectele respective, tipul canalului folosit si indentificatorul resursei respective (URI). Ar mai trebui metionat ca serviciul este de tip “singleton” care inseamna ca va exista o singura instanta pentru obiectul respectiv, indiferent cati clienti au nevoie de acel obiect (pentru modul “singlecall”, la fiecare invocare de metoda a tipului respectiv, se va crea o instanta noua) . Codul acestui fisier este prezentat mai jos:

<configuration>

<system.runtime.remoting>

<application>

<service>

<wellknown

mode="Singleton"

type="banca.Client_banca, banca"

objectUri="Client_banca.rem"

/>

<wellknown

mode="Singleton"

type="banca.Functionar_banca, banca"

objectUri="Functionar_banca.rem"

/>

</service>

<channels>

<channel ref="http" port="8989"/>

</channels>

</application>

</system.runtime.remoting>

</configuration>

3.6 Modulul client

Modulul client implementeaza functionalitatile specifice unui client al bancii, el obtinand o referinta la obiectul remote, referinta pe care o utilizeaza pe parcurs, in scopul adresarii de cereri. Interfata grafica este simpla si intuitiva fiind realizata in Microsoft Visual C#, cu ajutorul Windows Forms.

Clientul este configurat si el prin intermediul unui fisier, pentru a accesa obiectele remote. Iata codul fisierului WinClient.config:

<configuration>

<system.runtime.remoting>

<application>

<client>

<wellknown

type="banca.Client_banca , banca"

url="http://localhost:8989/Client_banca.rem"

/>

</client>

</application>

</system.runtime.remoting>

</configuration>

In continuare voi prezenta pe scurt interfata grafica a clientullui, cu cele mai importante ferestre, continutul fiind extrem de intuitiv:

Fig.8 Fereastra de login

In fig. 8 este prezentata fereastra de conectare la server.

In figura 9, este prezentata fereastra principala a clientului:

Fig.9 Fereastra principala

In fig. 10 este prezentata fereastra de transfer de fonduri:

Fig. 10 Fereastra de transfer de fonduri

In figura 11 este prezentata fereastra pentru plata facturilor:

Fig.11 Fereastra pentru plata facturilor

3.7 Modulul functionar

Modulul functionar implementeaza functionalitatea unui functionar, obtinand o referinta la obiectul remote de tip functionar_banca, aceasta referinta fiind folosita pentru adresarea de cereri. Interfata grafica a fost realizata pe aceleasi principii ca si cea a modulului client, tot prin intermediul Windows Forms si Visual C#.

In cazul functionarului, nu este necesara autentificarea, deoarece acest modul se presupune a fi accesibil numai functionarilor, in cadrul bancii.

Se foloseste si in acest caz un fisier de configurare asemanator cu cel al clientului si in acelasi scop. Mai jos prezint codul fisierului WinfFunctionar.cs:

<configuration>

<system.runtime.remoting>

<application>

<client>

<wellknown

type="banca.Functionar_banca , banca"

url="http://localhost:8989/Functionar_banca.rem"

/>

</client>

</application>

</system.runtime.remoting>

</configuration>

In continuare vor fi prezentate pe scurt, ca si in cazul clientului ferestrele principale, fara a fi descrise, deoarece nu este necesar, ele fiind intuitive.

In figura 12 este prezentata fereastra principala a aplicatiei functionar:

Fig. 12 Fereastra principala a aplicatiei functionar

In figura 13 este prezentata fereastra asociata conturilor unui client:

Fig. 13 Dialogul asociat conturilor unui client

In figura 14 este prezentata fereastra asociata facturilor unui client:

Fig.14 Dialogul asociat facturilor unui client

CAPITOLUL 4

Rularea aplicatiei

4.1 Compilarea si rularea aplicatiei

Compilarea aaplicatiilor se poate face fie din cadrul mediului integrat de dezvoltare Microsoft Visual Studio, fie cu ajutorul compilatorului oferit de SDK-ul (Software Development Kit) .NET. In ambele cazuri trebuie tinut cont de cateva aspecte:

in primul rand se compileaza tipul remote din directorul banca(banca.cs) sub forma de biblioteca dinamica (banca.dll).

se copiaza biblioteca banca.dll in directoarele unde se afla server.cs , WinClient.cs, respectiv WinFunctionar.cs

atat serverul cat si cei doi clienti se compileaza referentiand biblioteca banca.dll

Rularea aplicatiei trebuie sa se faca in felul urmator:

mai intai trebuie lansat in executie serverul , altfel se vor genera exceptii in momentul lansarii clientilor.

se lanseaza in executie aplicatia client / functionar.

CONCLUZII

Aplicatia realizata a avut ca scop gestiunea unor conturi bancare. Implementarea acesteaia s-a facut sub forma unei aplicatii de tip three-tier , pe baza tehnologiei .NET si cu ajutorul limbajului de programare C#.

Tehnologia .NET, tehnologie dezvoltata de corporatia Microsoft® incearca o imbinare intre puterea limbajelor ca C++, avantajele oferite de limbajul de programare Java, avantajele middleware-urilor de gen CORBA si ofera facilitati importante in ceea ce priveste urmatoarele aspecte:

portabilitatea aplicatiilor; astfel, orice aplicatie realizata in conformitate cu tehnologia .NET poate fi rulata pe orice sistem de operare si orice arhitectura hardware care suporta CLR (Common Language Runtime), asemanator masinii virtuale Java (JVM).

independenta de limbaj; din acest punct de vedere, orice componenta dezvoltata cu tehnologia .NET si care este CLS-compliant (in conformitate cu specificatia limbajului comun) poate fi folosita de catre alte aplicatii suportate de catre runtime.

Prin biblioteca de clase .NET Framework. tehnologia .NET ofera acces la un numar impresionant de clase si interfete care asigura functionalitati dintre cele mai variate, pornind de la procesarea sirurilor de caractere pana la servicii care tin de CLR (Common Language Runtime).

Suport pentru aplicatiile distribuite.

Unul dintre atuurile tehnologiei .NET care se poate observa si din aceasta aplicatie este usurinta dezvoltarii pe baza claselor oferite de framework-ul .NET, usurinta pe care personal am observat-o la nivelul implementarii comunicatiei intre clienti si server prin intermediul tehnologiei .NET Remoting.

Bibliografie

Programarea retelelor de calculatoare; Ioan Jurca; Editura de Vest; Timisoara; 2000

Principiile calculului paralel; Felicia Ionescu; Editura Tehnica; Bucuresti; 1999

A detailed comparison of CORBA, DCOM AND Java/RMI; Gopalan Suresh Raj; 1998

MSDN (Microsoft Developer Network); Microsoft; 1998

What is CORBA; www.whatis.com

Developing Professional Applications in Windows 95 and NT using MFC; Marshall Brain, Lance Lovette; Prentice Hall PTR; 1996

.NET Remoting; Hemshell Vagal; www.dotnetextreme.com; 2001

.NET Framework SDK Documentation; Microsoft Corporation; 2001-2002