FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT IOAN SLAVICI [608311]
FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN SLAVICI”
TIMIȘOARA
UNIVERSITATEA “IOAN SLAVICI” TIMIȘOARA
FACULTATEA DE INGINERIE
DOMENIUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT – ZI
PROIECT DE DIPLOM Ă
CONDUCĂTOR ȘTIINȚIFIC
prof./conf./ ș.l.. dr . ………
ABSOLVENTA
POPA DANIELA
– 2017 –
FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN SLAVICI”
TIMIȘOARA
UNIVERSITATEA “IOAN SLAVICI” TIMIȘOARA
FACULTATEA DE INGINERIE
DOMENIUL CALCULATO ARE ȘI TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT – ZI
Dezvoltarea aplicaț iilor folosind
Mecanismul RMI
CONDUCĂTOR ȘTIINȚIFIC
prof./conf./ ș.l.. dr . ………
ABSOLVENTA
POPA DANIELA
– 2017 –
UNIVERSITATEA DIN ORADEA
FACULTATEA de Ingi nerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
TEMA
Proiectul de Finalizare a studiilor a stu dentei:
Popa Daniela
1). Tema proiectului de finalizare a studiilor :
Dezvoltarea aplicațiilor folosind mecanism ul RMI
2). Termenul pentru predarea proiectului de diplomă : 15 Iunie 2017
3). Elemente inițiale pentru elaborarea proiectului de finalizare a studiilor :
?
4). Conținutul proiectului de finalizare a studiilor :
Capitolul I – JAVA RMI
Capitolul II – SERVI CII RMI
Capitolul III – CARACTERISTICI GENERALE
Capitolul IV – TIPARE DE PROGRAME
Capitolul V – AVANTAJELE R
Capitolul VI – SOFTWARE
Capitolul VII – CONCLUZII
5). Material grafic:
CAP. III: Fig. 3.1 – Baza de dat; Fig. 3.2 – Realizarea bazei de date; Fig. 3.3 – Realizarea tabelelor; Fig. 3.4 –
Vizualizarea tabelelor din baza de date; Fig. 3.5 – Tabela conturi; Fig. 3.6 – Tabela clienti; Fig. 3.7 – Tabela login; Fig.
3.8 – Tabela tranzacții;
CAP.V: Fig. 5.1 – Diagrama tranzacții;
CAP.VI: Fig.14.1 – Autentificarea clienților; Fig.14.2 – Autentificarea reușită; Fig.14.3 – Autentificarea nereușită;
Fig.14.4 – Date personale; Fig.14.5 – Vizualizare sold; Fig.14.6 – Afișare sold; Fig.1 4.7 – Plăți; Fig.14.8 – Fonduri
insuficiente; Fig.14.9 – Tranzacție efectuată (server); Fig.14.10 – Tranzacție efectuată (client); Fig.14.11 – Formular
transfer; Fig.14.12 – Transfer reușit; Fig.14.13 – Formular tranzacții
6). Locul de documentare pentru elaborarea proiectului de diplomă:
Universitatea Ioan Slavici – Facultatea de Ingine rie Electrică și Tehnologia Informației
Departamentul Calculatoare și Tehnologia Informației
7). Data emiterii temei: Noiembrie 2016
Coordonatori științifici
(titlul șt iințific și numele) ,
– 2017 –
REFERAT PRIVIND LUCRAREA DE LICENȚĂ A ABSOLVENT: [anonimizat]:
Popa Daniela
DOMENIUL / PROGRAMUL DE STUDIU:
Calculatoare și ingineria informației/Calculatoare
PROMOȚIA 2017
1. Titlul lucrării: Dezvoltarea aplicațiilor folosind mecanismul RMI
2. Structura lucrării:
• Capitolul I – JAVA RMI
• Capitolul II – SERVICII RMI
• Capitolul III – CARACTERISTICI GENERALE
• Capitolul IV – TIPARE DE PROGRAME
• Capitolul V – AVANTAJELE RMI
• Capitolul VI – SOFTWARE
• Capitolul VII – CONCLUZII
• Bibliografie
• Anexe
3. Aprecier i asupra conținutului lucrării de LICENȚĂ ( finalizare a studiilor ), mod de
abordare, complexitate, actualitate, deficiențe
4. Aprecieri asupra lucrării (se va menționa: numărul titlurilor bibliografice consultate,
frecvența notelor de subsol, calitatea și diversitatea surselor consultate; modul în care
absolventul a prelucrat informațiile din surse teoretice)
(se va menționa: opțional locul de documentare și modul în care absolventul a realizat cercetarea
menționându -se contribuția autorului)
5. Concluzii (coordonatorul lucrării trebuie să aprecieze valoarea lucrării întocmite,
relevanța studiului întreprins, competențele absolventului, rigurozitatea pe parcursul UNIVERSITATEA DIN OR ADEA
FACULTATEA DE INGINERIE ELECTRICĂ
ȘI TEHNOLOGIA INFORMAȚIEI
Adresa Oradea, Cod 410087, Bihor, România, Strada Universității,
nr. 1,
Tel/Fax :+40 259/408412, Tel:+40 259/408104; +40
259/408204
elaborării lucrării, consecvența și seriozitatea de care a dat dovadă absolventul pe
parcurs)
6. Redactarea lucrării respectă toate cerințele academice de redactare (părți, capitole,
subcapitole, note de subsol și bibliografie).
7. Consider că lucrarea îndeplinește/ nu îndeplinește condițiile pentru susținere în sesiunea
de Examen de LICENȚĂ ( finalizar e a studiilor ) din IULIE 2017 și propun acordarea
notei ………………
Oradea,
Data Conducător științific,
nume coordonator proiect diploma
– 2017 –
CUPR INS
Capitolul I – JAVA RMI ……………………………. ……………………………………………………. 8
I.1. Introducere ……………………………………………………………………………………………. 8
Capitolul II – SERVICII RMI …………………………. ………………………………………………. 9
II.1. Model RMI …………………………………………………………………………………………… 9
II.2. Procedura de la distanță ……………………………………………………………………….. 9
II.3. Identificarea serviciului ………………………………………………………………………… 9
II.4. Accesul la server …………………………………………………………………………………… 10
II.5. Apelarea de la distanță …………………………………………………………………………. 10
Capitolul III – CARA CTERISTICI GENERALE ……………………………………………… 12
III.1. Arhitectura sistemului RMI ………………………………………………………………… 14
III.2. Descrierea claselor și a interfețelor RMI …. …………………………………………… 17
2.a. Clasele accesibile programelor client ……………………………………………. … 17
2.b. Clasele accesibile programelor server ………………… …………………………… 18
2.c. Ser viciul de înregistrare a obiectelor de la distanță ……………………….. …. 22
2.d. Clasele și interfețele pentru surogate și schelete …………………………….. … 23
2.e. Clasele și interfețele pentru col ectorul de deșeuri ………………………….. …. 25
Capitolul IV – TIPARE DE PROGRAME ………………………………………………………… 26
IV.1. Fabricarea obiectelor …………………………………………………. ……………………….. 26
IV.2. Apel invers ………………………………………………………………………………………….. 26
IV.3. Activarea obiectelor de la distanță ……………………………………. …………………. 27
Capitolul V – AVANTAJELE RMI …………………………………………………………………… 29
Capitolul VI – SOFTWARE …………………………………………………………………………….. 30
VI.1. Prezentare aplicație …………………………………………………………………………….. 30
VI.2. Tehnologii implementate ……………………………………………………………………… 30
VI.3. Implement area serverului MySQL ………………………………………………………. 31
VI.4. Conectarea bazei de date ……………………………………………………………………… 34
VI.5. Interogarea bazei de date …… ……………………………………………………………….. 35
VI.6. Procesarea rezultatelor ……………………………………………………………………….. 37
VI.7. Deconectarea bazei de date ……………. ……………………………………………………. 37
VI.8. Serviciul de la distanță ………………………………………………………………………… 37
VI.9. Interfața de la distanță ……………………….. ………………………………………………. 37
VI.10. Implementarea de la distanță …………………………………………………………….. 38
VI.11. Obiecte Stub și Skeleton folosind utilitarul RMIC …………….. ……………….. 38
VI.12. Rularea utilitarului de înregistrare …………………………………………………….. 39
VI.13. Pornirea serviciului de la distanță ………………………………………………………. 39
VI.14. Lansarea clientului ……………………………………………………………………………. 39
14.a. Autentificarea cliențiilor ………………. …………………………………………… … 39
14.b. Vizualizarea datelor personale ………. …………………………………………… … 41
14.c. Vizualizarea soldului disponibil …….. …………………………………………… … 41
14.d. Efectuarea plățiilor ……………………… …………………………………………… … 42
14.e. Transfer către alte conturi ……………. …………………………………………… … 44
14.f. Vizu alizarea tranzacțiilor ……………………………………………………………….. 45
Capitolul VII – CONCLUZII ……………………………………………………………………………. 46
VII.1. Implementarea cloud … ………………………………………………………………………. 47
VII.2. Interfața inteligentă …………………………………………………………………………… 48
BIBLIOGRAFIE ……………………… ……………………………………………………………………… 49
ANEXE ……………………………………………………………………………………………………….. ….. 50
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
CAP. I. – JAVA RMI
II.1 – INTRODUCERE
Realizarea unei aplicații care să folosească serviciul Java RMI presupune dezvoltarea unei
aplicații care să per mită apelarea metodelor la distanță, adică implementarea unei aplicații client -server.
Aplicațiile client -server sunt aplicații distribuite care partajează procesarea între furnizorii de servicii
numiți servere și elementele care solicită servicii, numite clienți.
Clienții și serverele comunică printr -o rețea de calculatoare, de multe ori prin Internet. Serverele
așteaptă conexiuni din partea aplicației client. Aplicațiile server și client pot rula pe același calculator
sau pot, la fel de bine, rula pe ca lculatoare diferite. Folosind serviciul Java RMI, pentru a realiza un
apel către un obiect aflat la distanță, clientul caută mai întâi o referință la obiectul respectiv în registru.
Dacă această referință la obiectul de pe server există, registrul o pune la dispoziția clientului,
care poate apela orice metodă care face parte din interfața publică a obiectului.
Înainte ca RMI să apară însă, existau deja câteva metode bine cunoscute și cercetate de
comunicare inter -proces: comunicarea prin socket și RPC (R emote Procedure Call).
Tehnologia RMI este un descendent direct al RPC. Astfel, dacă folosim o platformă orientată
obiect și în RPC înlocuim subrutinele cu metode ale obiectelor ceea ce obținem este o implementare
RMI. Vedem astfel că trecerea de la RPC la RMI a fost necesară din cauza introducerii paradigmei de
programare orientată obiect.
Serviciul RMI oferă anumite avantaje față de RPC. Prin RMI este posibilă transmiterea de
obiecte ca parametri actuali și valori de retur, ca de exemplu tabele de disp ersie, față de tehnologiile
RPC clasice, care necesită descompunerea în tipuri primitive a structurilor și apoi reconstrucția lor pe
server. Un alt avantaj este acela că serviciul RMI utilizează mecanismele de securitate implementate în
platforma Java.
O aplicație care folosește mecanismul Java RMI poate avea ca scop simularea unui serviciul
bancar online, dar trebuie să utilizeze și o bază de date.
În fiecare domeniu există aplicații care folosesc baze de date pentru a păstra informații care vor fi
ulteri or folosite. Bazele de date fac parte și din domeniul informaticii, ajutând programatorii să țină
evidența datele pe care le prelucrează.
Pentru sistemele bancare bazele de date sunt văzute asemănător unor dosare. Pentru fiecare
client există un dosar în care se găsesc informații despre el. În baza de date se păstrează datele cele mai
importante
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 8 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
CAP. II. – SERVICII RMI
II.1 – MODEL RMI
Multe dintre aplicațiile distribuite se bazează pe modelul client -server. În acest model, un
proces, numit server , oferă servicii mai multor procese, denumite clienți. În fiecare stație se pot
executa mai multe procese server, multiple procese client precum și combinații ale acestora. Acest
model se bazează pe transferul de mesaje: clientul trimite un mesaj către server, conținând o cerere de
serviciu, iar serverul răspunde clientului, căruia îi trimite de asemenea un mesaj.
Acest model de programare este de stul de incomod, deoarece programul trebuie să prevadă
operații de transfer de mesaje explicite (operații sendreceive ), sincronizarea acestora, tratarea erorilor,
etc. De aceea a fost dezvoltată și o altă metodă de programare distribuită care, deși foloseș te tot
transferul de mesaje între stații, oferă o interfață de programare mai simplă; această metodă se numește
apelul de procedură la distanță (RPC – Remote Procedure Call ).
II.2 – PROCEDURA DE LA DISTANTA
Între dificultățile scrierii aplicațiilor clie nt-server cu ajutorul soclurilor se remarcă necesitatea
de a introduce cod specific pentru conectare atât în client, cât și în server, precum și necesitatea de a
ține cont de arhitecturile potențial diferite ale calculatoarelor pe care rulează clientul și serverul.
O modalitate de a evita aceste dificultăți a fost propusă sub denumirea de apel de procedură la
distanță ( Remote Procedure Call – RPC ) și implementată ulterior în mai multe variante comerciale.
Conceptual, RPC se situează deasupra nivelului transport din familia de protocoale TCP/IP, utilizată
în cele mai cunoscute implementări de RPC. Aceasta înseamnă că și activitatea proiectanților de
aplicații va fi mai abstractă, o serie de detalii fiind preluate de suportul de execuție care însoțește
implementările RPC.
II.3 – IDENTIFICAREA SERVICIULUI
O procedură la distanță este identificată prin 3 numere: număr program, număr versiune și
număr procedură. Toate aceste numere sunt întregi și trebuie remarcat că programatorii unei aplicații
bazate pe RPC vor utiliza aceste numere doar la specificarea părții de server a aplicației. Primele două
numere au rolul de a identifica un anumit program server, iar ultimul număr identifică o procedură
apelabilă de la distanță a acelui program. Fiecare calculator pe care pot rula aplicații RPC trebuie să
ruleze un portmapper, el însuși un serviciu bazat pe RPC, la care sunt înregistrate toate serverele RPC
de pe acel calculator. Când se pornește serverul unei aplicații, acesta va crea un port la care acceptă
conex iuni și va trimite spre portmapper un mesaj, prin care anunță numerele sale de identificare
(număr de program și de versiune), precum și portul la care va accepta cereri. Când un client dorește să
apeleze o procedură la distanță, trebuie mai întâi să solic ite de la portmapper informații despre serverul
care conține acea procedură. Concret, clientul trebuie să furnizeze numerele de identificare ale
serverului și va obține de la portmapper numărul de port.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 9 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
II.4 – ACCESUL LA SERVER
Dezvoltarea aplicațiilor distribuite a condus și la introducerea unor metode de autorizare a
cererilor de la clienți, bazate de regulă pe un credențial și un verif icator, transmise de client serverului.
Credențialul este o precizare a identității clientului (de exemplu numele calculatorului pe care rulează
clientul și identificatorul utilizatorului), iar verificatorul este o informație pe care se presupune că
numai un utilizator „adevărat” o cunoaște (de exemplu o parolă). În alte situații este la fel de important
ca un utilizator să poată verifica identitatea serverului. De exemplu, dacă clientul urmează să trimită
date confidențiale spre server, trebuie să se asigu re mai întâi că serverul este cel care pretinde a fi.
Protocolul RPC nu definește nici un mecanism de autentificare, dar pune la dispoziție un câmp
în pachetele de cereri RPC în care ar putea fi introduse date de autentificare. Majoritatea
implementărilor RPC oferă un anumit suport pentru trei forme de autentificare. Aceasta înseamnă că
există fișiere antet care definesc formatul datelor de autentificare și rutine în biblioteca RPC care
operează asupra acestor date. Cele trei forme de autentificare sunt:
1. AUTH_NONE: nu se verifică nici credențialul, nici autentificatorul.
2. AUTH_UNIX: credențialul constă din numele calculatorului, UID -ul și GID -ul utilizatorului
și o listă de grupuri cărora le aparține utilizatorul. Nu există verificator.
3. AUTH_DES: crede nțialul constă din „numele de rețea” al utilizatorului (de forma
user@machine), iar verificatorul este un marcaj de timp, criptat conform standardului DES
(Data Encryption Standard).
II.5 – APELAREA DE LA DISTANTA
Deși în Java operațiile cu sockets (ca și cele de introducere/extragere) sunt realizate ca operații
asupra obiectelor, se păstrează semantica de un nivel de abstractizare relativ redus a conceptului de
socket, așa cum este oferit acesta în sistemul de operare.
Programatorii de aplicații trebu ie să-și construiască propriile protocoale plecând de la nivelul
transport, specific pentru sockets, ceea ce în cazul unor aplicații mai complexe implică un efort
semnificativ.
Termenul de socket este unul relativ vechi, fiind definit prima dată prin RFC 147 în 1971. Este
imperativ să menționăm că implementând un sistem de comunicare inter -proces folosind socket -uri
beneficiem de cea mai mare flexibilitate. Astfel este posibil să utilizăm socket -uri ca alternativă la
RMI, fiind posibilă implementarea tutu ror posibilităților de comunicare ce pot fi obținute prin alte
metode. Desigur, asta cere un volum (mult) mai mare de lucru pe faza de implementar e și de testare a
comunicării.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 10 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTU L Calculatoare și tehnologia informației
În general, comunicarea prin socket este utilizată de aplicațiile ce au nevoie să schimbe
informație brută între procese, ca de exemplu un server de streaming audio/video. Dezavantajele unei
implementări bazate pe socket devin evidente în sistemele moderne: trebuie implementat un protocol
de comunicare inter -proces, trebuie create obiectele specifice comunicării prin socket și nu în ultimul
rând trebuie securizat și testat protocolul de comunicare dezvoltat, protoco l care de regulă nu va putea
fi utilizat la următoarea aplicație distribuită dezvoltată. Se poate imagina și pentru limbajele orientate
pe obiecte o modalitate de programare a aplicațiilor distribuite analoagă apelului de procedură la
distanță (RPC). Trans punerea se face chiar într -un mod mai natural decât în cazul RPC, existând de
fapt opinia că ”programarea distribuită pare să fie destinată a deveni orientată pe obiecte”. Există un
număr mare de aspecte care trebuie luate în considerare atunci când se re alizează un sistem de
programare distribuită orientat pe obiecte:
– Dacă obiectele sunt mobile sau staționare;
– Dacă obiectele se transmit (comunică) prin copiere sau prin referință;
– Ce dimensiuni (complexitate, granularitate) trebuie să aibă un obiect pen tru a fi satisfăcute
anumite criterii de eficiență;
– Ce nivel de verificare a tipurilor se oferă;
– Dacă obiectele sunt sau nu sunt active, persistente, replicate etc.
Începând cu JDK1.1 se oferă pentru limbajul Java un sistem de programare distribuită or ientat pe
obiecte sub numele de RMI (Remote Method Invocation), care trebuie considerat ca un punct posibil
în spațiul de proiectare a unor astfel de sisteme cu criteriile sugerate mai sus. Următoarele versiuni de
JDK au adus modificări și extinderi. Java RMI este o extensie firească a apelurilor RPC, permițând
apelul obiectelor la distanță. Probabil că și datorită acestui concept, proiectele de tip RPC au fost, încet
încet, abandonate. Din punct de vedere conceptual, RMI seamănă extrem de mult cu RPC, în sensul că
un obiect ”client” poate să apeleze o metodă a unui obiect aflat la distanță. Dar, așa cum vom vedea,
RMI permite mult mai multe facilități decât RPC și este o modalitate extrem de elegantă în constelația
”middleware” a conceptelor programării di stribuite. RMI furnizează o modalitate prin care se permite
execuția unei aplicații Java pe mai multe platforme JVM simultan. Acest mecanism este numai unul
dintre cele care permite ca două calculatoare să ”discute” între ele prin intermediul obiectelor.
RMI este o schemă TCP socket pentru implementarea obiectelor în rețea. Ideea acestei scheme este
aceea că există doi protagoniști, un client și un server. Server -ul găzduiește unul sau mai multe
obiecte, obiecte ce pot fi numite obiecte servant. Din punct d e vedere al aplicațiilor ar fi frumos ca
aceste obiecte să fie ”văzute” de către clienți la fel ca și obiectele locale. RMI oferă o infrastructură
care realizează exact acest lucru. Principala ”reclamație” legată de RMI este faptul că protocolul lui nu
este dezvoltat deschis și nici nu este public. Din această cauză, SUN a acceptat să introducă în IIOP
(Internet Inter -ORB) anumite facilități RMI. Implementarea curentă folosește API de serializare,
marshalling și TCP -sockets pentru infrastructura RMI. În dez voltarea aplicațiilor care doresc să invoce
metode ale obiectelor aflate la distanță, folosind Java RMI, trebuie parcurși trei pasi:
1. Găsirea obiectelor;
2. Comunicarea cu obiectele
3. Trimiterea codurilor de biți pentru obiectele cu rolul de parametru de int rare și recepționarea
codurilor de biți pentru obiectele returnate.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 11 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
CAP. I II. – CARACTERISTICI GENERALE
Un obiect la distanță (remote obj ect) este definit în Java ca un obiect ale cărui metode pot fi
apelate (invocate) dintr -o altă mașină virtuală Java, potențial situată pe un alt calculator. Mai precis,
obiectele la distanță sunt exemplare ale unor clase care implementează metodele unor in terfețe la
distanță și numai asemenea metode pot fi apelate de clienții unui obiect la distanță. Deci, RMI se poate
defini ca acțiunea de a apela o metodă a unei interfețe la distanță pe un obiect la distanță. Sintaxa unui
asemenea apel nu diferă de cea pe ntru apelarea metodelor locale.
Există însă câteva deosebiri care trebuie evidențiate:
– Clienții obiectelor la distanță interacționează cu interfețele la distanță și nu direct cu clasele care
implementează acele interfețe;
– Argumentele locale și rezult atele unui apel la distanță se transmit prin copiere și nu prin referință,
pentru că referirile la obiecte sunt valabile numai în cadrul aceleiași mașini virtuale;
– Obiectele la distanță se transmit prin referire și nu prin copierea implementării efective a
obiectului; în realitate, referirea este la un surogat al obiectului la distanță, care se află în aceeași
mașină virtuală cu apelantul;
– Clienții vor avea de a face cu noi tipuri de excepții, pentru că modalitățile în care pot eșua
apelurile la distanță sunt mai complexe și mai numeroase decât în cazul apelurilor locale.
A fost necesar să se definească puncte de start specifice pentru clasele, interfețele și excepțiile la
distanță, iar în cazul claselor apare de fapt o ierarhie, cu mai multe puncte de p lecare posibile
Din punctul de vedere al organizării în pachete, se precizează că:
– Interfața Remote este în pachetul java.rmi ;
– Clasele RemoteObject , RemoteServer și UnicastRemoteObject sunt situate în pachetul
java.rmi.server ;
– RemoteException face par te din pachetul java.rmi .
Alte interfețe și clase sunt colectate în încă două pachete distincte, java.rmi.registry și
java.rmi.dgc .
Interfața Remote nu conține nici o metodă, servind doar ca punct de plecare pentru RMI: public
interfae Remote {}.
Toate interfețele legate de lucrul cu obiecte la distanță trebuie să extindă Remote în mod explicit.
Clasa RemoteException este superclasa tuturor excepțiilor care pot fi generate de către suportul de
execuție RMI. Este obligatoriu ca toate metodele declarate î ntr-o interfață la distanță să specifice
java.rmi.RemoteException în clauza lor throws. Această excepție se generează, de exemplu, în caz de
eroare în rețea sau dacă obiectul server pentru un anumit apel nu poate fi contactat. Rolul clasei
RemoteObject este să re -implementeze metodele hashCode , toString și equals ale lui Object într -o
formă adecvată pentru RMI.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 12 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Funcțiile necesare pentru a c rea obiecte și a le face disponibile la distanță (a le exporta) sunt
prevăzute în clasa abstractă java.rmi.server.RemoteServer și vor fi implementate în subclasele
acesteia. Este rolul subclaselor, de exemplu, să stabilească dacă serverul este un obiect un ic sau este
replicat (necesitând astfel comunicarea cu locații multiple).
În JDK se oferă o singură variantă de semantică pentru servere, prin clasa
java.rmi.server.UnicastRemoteObject care definește un obiect la distanță unicat (ne -replicat) ale cărui
referiri sunt valabile numai cât timp procesul care l -a lansat este activ sau care poate fi activat la
cerere, în condiții speciale.
Pentru a ilustra o situație tipică de lucru cu RMI se consideră o interfață la distanță și schița
unei implementări a acesteia pentru o aplicație de baze de date, în care operațiile permise sunt:
adăugarea unui element, ștergerea unui element, căutarea unui element.
Interfața la distanță corespunzătoare va arăta astfel:
public interface BazaDate extends Remote {public void ad d (Element elem)throws
RemoteException;public void delete
(Element elem)
throws RemoteException;public Boolean search (Element elem)throws RemoteException; }
Iar schița unei implementări este:
import java.rmi.RemoteException;
import java.rmi.server.U nicastRemoteObject;
public class BazaDateImpl extends UnicastRemoteObject implements BazaDate
{public void add(Element elem)
throws RemoteException { … } public void
delete(Element elem)
throws RemoteException { … }
public Boole an search(Element elem)
throws RemoteException {… }
// alte metode}
Dacă implementarea conține și alte metode decât cele din interfața BazaDate, acele metode nu
pot fi apelate la distanță, ci numai din aceeași mașină virtuală. Este permis ca o clasă care
implementează o interfață la distanță să extindă o altă clasă decât U nicastRemoteObject, dar în cazul
acesta va fi responsabilitatea clasei să asigure semantica adecvată a operațiilor hashCode , equals și
toString , precum și a mecanismelor de comunicare.
După cum s -a menționat, obiectele client nu interacționează direct cu obiectele care
implementează o interfață la distanță (servere), ci cu surogate (”stubs”) ale acestora, care se vor găsi în
aceeași mașină virtuală cu clientul. Obiectele surogat au exact aceleași interfețe la distanță ca și
obiectele pe care le reprezintă , dar nu includ porțiunile ”locale” din graful care constituie ierarhia
tipului obiectului la distanță.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 13 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Un argument de apel sau o valoar e returnată de un obiect la distanță pot fi de orice tip Java
serializabil. Pentru applet -uri, dacă clasa unui argument sau valoare returnată nu este disponibilă local,
va fi încărcată dinamic prin AppletClassLoader .
Pentru aplicații, asemenea clase vor f i încărcate de către încărcătorul de clase al aplicației (fie
încărcătorul implicit care folosește calea de căutare locală pentru clase, fie de RMIClassLoader, care
folosește ”baza de cod” a serverului). Pentru ca un client să apeleze o metodă a unui obiec t la distanță,
clientul trebuie să dețină o referire la acel obiect. În acest scop, în RMI este inclus un server de nume
(prin clasa java.rmi.Naming ) la care obiectele server se înregistrează și de la care clienții pot obține
referiri, dacă știu numele sub care este înregistrat serverul:
//partea de înregistrare, prezentă în server
BazaDate bd = new BazaDateImpl ();
String url = …; //localizarea serverului (cu nume host inclus)
Java.rmi.Naming.bind (url, bd);
…
//partea de obtinere a unei referir i, in client
BazaDate bdref = (BazaDate)java.rmi.Naming.lookup(url);
Se observă că atât la înregistrare, cât și la obținerea referinței se lucrează cu numele interfeței la
distanță pentru a reda tipul. În server se poate însă lucra și cu numele clasei care face implementarea.
III.1 – ARHITECTURA SISTEMULUI RMI
În varianta din JDK, sistemul RMI este implementat în trei niveluri: a) surogat/schelet; b) referire la
distanță și c) transport. Nivelul surogat/schelet constituie interfața între nivelul apli cație și restul
sistemului RMI.
Responsabilitățile acestui nivel în partea clientului (surogat) sunt:
– Inițierea unui apel către obiectul la distanță (prin apelarea serviciilor din nivelul referire la
distanță);
– Transmiterea la distanță a datelor (argume ntelor) printr -un flux de ordonanțare (”marshal
stream”) obținut de la nivelul de referire la distanță, folosind mecanismul de serializare din Java;
– Anunțarea nivelului de referire la distanță că trebuie efectuat apelul;
– De-ordonanțarea valorii returnate sau a excepției primite din fluxul de ordonanțare;
– Anunțarea nivelului referire la distanță că s -a terminat apelul.
Responabilitățile în partea serverului sunt:
– De-ordonanțarea argumentelor din fluxul de ordonanțare;
– Efectuarea unui apel ascendent (” up-call”) spre implementarea propriu -zisă a obiectului la
distanță;
– Ordonanțarea valorii returnate (sau a excepției) în fluxul de ordonanțare.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./c onf./ș.l.. dr . …….. 14 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Surogatele și scheletele specifice unei aplicații se generează automat, pe baza implementării
obiectului la distanță, prin compilatorul numit rmic, inclus în JDK. Nivelul de referire la distanță are
două componente care cooperează, una destinată părții d e client și cealaltă pentru partea de server. La
acest nivel se stabilește dacă apelul se face ”unicast” sau replicat și eventual strategiile de replicare,
persistență și reconectare. Componenta din partea de client conține informațiile specifice despre se rver
și comunică, prin intermediul nivelului transport, cu componenta pentru server din calculatorul la
distanță (dacă, de exemplu, ar exista un server replicat, s -ar putea trimite apelul fiecăreia dintre
replicile serverului). Asemănător, componenta din p artea serverului implementează semantica
referirilor la distanță înainte de a trimite apelul spre nivelul schelet (de exemplu ar putea asigura
semantica de ”livrare atomică multicast”, prin comunicarea cu ceilalți serveri din grup).
Se reamintește că JDK oferă numai comunicare unicast, de regulă doar pe perioada cât serverul
este activ.Nivelul de referire la distanță transmite datele spre nivelul transport printr -o conectare
bazată pe flux. Este însă principial posibil ca la nivelul transport să se lucreze cu protocol fără
conexiune.
Nivelul transport este responsabil pentru:
– Stabilirea unor conexiuni spre spațiile de adrese la distanță (ale JVM) și gestionarea
conexiunilor;
– Așteptarea unor apeluri și stabilirea legăturilor pentru apelurile sosite;
– Gestionarea unor tabele de obiecte la distanță care se găsesc în spațiul de adrese;
– Localizarea dispecerului pentru destinația unui apel la distanță și transmiterea conexiunii către
acel dispecer.
Există 4 abstracții fundamentale cu care se operează la ace st nivel:
– Un punct final (endpoint) desemnează un spațiu de adrese sau o mașină virtuală Java (JVM). În
implementare, punctele finale sunt puse în corespondență cu nivelul lor transport, adică dacă se
dă un punct final se poate obține nivelul transport co respunzător;
– Un canal este abstracția pentru legătura dintre două spații de adrese și deci va fi responsabil
pentru gestionarea conexiunilor între spațiul de adrese local și un anumit spațiu de adrese la
distanță;
– O conexiune este abstracția pentru un tr ansfer de date (execuția unei operații de
introducere/extragere);
– Transportul este abstracția pentru gestionarea canalelor. În cadrul transportului există numai câte
un canal între spațiul local și un spațiu la distanță. Dându -i-se un punct final pentru u n spațiu de
adrese la distanță, un transport stabilește un canal spre acel spațiu de adrese. Abstracția
”transport” este, de asemenea, responsabilă pentru acceptarea apelurilor pe conexiunile de intrare
la spațiul de adrese, pentru stabilirea unui obiect c onexiune corespunzător apelului și pentru
dispecerizarea spre nivelurile mai înalte din sistem.
Proiectarea sistemului RMI permite să existe mai multe transporturi pentru un spațiu, ceea ce
înseamnă, de exemplu, că în aceeași mașină virtuală s -ar putea lucra atât cu TCP, cât și cu UDP.
Implementarea actuală este bazată pe TCP.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 15 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Reprezentarea concretă a unei referiri la un obiect la distanță cons tă dintr -un punct final și un
identificator de obiect și se numește referire vie (live reference). Dacă se dă o referire vie pentru un
obiect la distanță, transportul poate folosi punctul final pentru a stabili o conexiune cu spațiul de
adrese în care se a flă obiectul la distanță, iar în partea serverului transportul folosește identificatorul de
obiect pentru a căuta destinația apelului la distanță. Suportul de execuție RMI face uz de firele de
execuție ale limbajului Java pentru realizarea apelurilor de me tode la distanță. Astfel, suportul asigură
că apelurile de la mașini virtuale diferite se execută în fire diferite. Apelurile care provin de la aceeași
mașină virtuală client sunt executate când în același fir, când în fire diferite (datorită politicii de
reutilizare a socketurilor).
Se pune și în sistemele distribuite problema colectării automate a deșeurilor. În RMI a fost
implementat un algoritm bazat pe numărarea referințelor. În mașina virtuală client, algoritmul lucrează
astfel: când o nouă referire v ie apare în mașina virtuală, numărătorul de referințe al referirii vii este
incrementat.Prima referire la un obiect trimite serverului pentru obiectul respectiv un mesaj
”referenced”. Când se constată local că o referire vie nu mai este folosită, finalizar ea acesteia
decrementează numărătorul. Dacă aceasta a fost ultima referire (numărătorul devine nul), se trimite
serverului un mesaj ”unreferenced”. În mașina virtuală server, când un obiect la distanță nu este referit
de nici un client, obiectul este refer it în suportul de execuție printr -o ”referire slabă”, care permite
colectorului de deșeuri să elimine obiectul dacă acesta nu are referiri locale. Dacă însă există referiri
locale, obiectul poate fi transmis în apeluri la distanță sau poate fi returnat cli enților. Dacă se transmite
un obiect la distanță, identificatorul mașinii virtuale căreia i s -a transmis se adaugă la setul de referiri.
Obiectele la distanță sunt colectate numai atunci când nu mai au nici un fel de referiri (nici locale, nici
la distanță ). În cazul partiționării rețelei poate apare o colectare prematură (pentru că transportul
ajunge să considere că a a părut o ”cădere” a clientului). Se prezintă în continuare mai detaliat
problema încărcării dinamice a claselor. Regula fundamentală este a ceea că întotdeauna încărcătorul
de clase care încarcă o anumită clasă este folosit în continuare pentru încărcarea tuturor interfețelor și
claselor direct utilizate de acea clasă:
– Dacă este vorba de un applet, atunci se folosește AppletClassLoader pentru a aduce din rețea de
la locația specificată de atributul ”codebase” al paginii Web care conține marcajul <applet>,
clasele referite;
– Încărcătorul de clase implicit se folosește pentru a încărca o clasă (a cărei metodă main este
activată prin comanda java ) folosind pentru localizare valoarea variabilei de mediu locale
CLASSPATH;
– RMIClassLoader este folosit pentru a încărca acele clase care nu se folosesc direct de către
aplicație (client sau server): surogatele și scheletele obiectelor la distanță și clas ele extinse ale
argumentelor și valorilor returnate de apelurile RMI.
Asemenea clase sunt căutate în următoarele locații, în această ordine:
a) Variabila CLASSPATH locală. Clasele se încarcă întotdeauna local dacă există local;
b) Pentru obiectele (la distan ță sau nu) transmise ca parametri sau valori returnate, localizarea
se face folosing URL -ul codificat în fluxul de ordonanțare care conține obiectul serializat.
c) Pentru surogatele și scheletele obiectelor la distanță create în mașina virtuală locală se
folosește URL -ul specificat de proprietatea java.rmi.server.codebase .
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 16 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
O aplicație poate fi configurată cu proprietatea java.rmi.server.useCodebase -Only, care
dezautorizează încărcarea claselor din rețea și forțează ca toate clasele să se încarce numai din baza de
cod definită local. Dacă acest lucru nu este posibil, apelul metodei va eșua cu o excepție. Încărcarea
dinamică a claselor pune probleme de se curitate, dacă clasele nu sunt încărcate local. Pentru ca
RMIClassLoader să poată încărca clase din rețea este necesar să fie activ un manager de securitate,
astfel generându -se o excepție. Activarea managerului de securitate trebuie să fie prima acțiune a unui
program Java astfel încât să poată controla toate acțiunile următoare ale programului. Managerul de
securitate asigură că toate clasele încărcate satisfac cerințele de securitate Java (de exemplu, că vin de
la surse ”de încredere” și că nu încearcă s ă acceseze funcții speciale). În cazul applet -urilor se aplică
întotdeauna restricțiile clasei Applet Security, care asigură că clasele vin numai de la același calculator
ca și applet -ul sau de la calculatoar e desemnate pentru baza de cod.
Aplicațiile treb uie să -și definească propriul manager de securitate sau să folosească varianta
restrictivă RMISecurityManager . Dacă nu este activat nici un manager de securitate, aplicația nu -si
poate încărca clasele din rețea .
III.2 – DESCRIREA CLASELOR SI A INTERFETELO R RMI
III.2.a – Clasele accesibile programelor client
În dezvoltarea părții de client a unei aplicații, respectiv la scrierea unui applet destinat să
lucreze cu obiecte la distanță, se utilizează interfața Remote , deja prezentată, precum și clasele
Remot eException și Naming . Toate acestea formează pachetul java.rmi, împreună cu un număr de alte
excepții derivate din RemoteException și cu clasa
RMISecurityManager folosită la încărcarea claselor surogat în aplicații (nu și în applet -uri) și descrisă
separa t. Clasa Naming constituie mecanismul prin care clienții pot obține referiri la obiectele la
distanță (este folosită și în partea de server a programelor distribuite pentru înregistrarea obiectelor cu
rol de server la distanță). Localizarea obiectelor la d istanță se face prin URL.
Clasa are numai metode statice și nu definește constructori:
• public static Remote lookup (String name) throws
NotBoundException, MalformedURLException,UnknownHostException,
RemoteException – returnează o referire (de tipul general indicat prin interfața Remote) la
obiectul identificat prin name (care trebuie să fie un URL). Toate excepțiile generate sunt
derivate din RemoteException .
• public static String[] list (String name) throws
RemoteException, MalformedURLException , UnknownHostException – returnează
sub formă de tablou de șiruri URL -urile tuturor obiectelor la distanță momentan înregistrate în
mașina virtuală indicată prin argumentul name, care apare de regulă ca un nume de calculator
(suplimentat cu numărul de port , dacă acesta diferă de 1099). Se pot afla astfel numele tuturor
obiectelor la distanță înregistrate ca server pe un anumit calculator și apoi se poate selecta cel
dorit, dacă numele date serverelor sunt suficient de sugestive.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 17 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electric ă și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Următoarele 3 metode ale clasei Naming vor fi utilizate la înregistrarea serverelor, dar se prezintă
aici, pentru a întregi descrierea clasei.
• public static void bind (Str ing name, Remote obj) throws
AlreadyBoundException, MalformedURLException, UnknownHostException,
RemoteHostException – leagă un nou obiect, cu identitatea precizată prin obj sub numele
name în registrul de nume al mașinii virtuale din care se face apelul. Se presune că obiectul nu a
fost anterior legat.
• public static rebind (String name, Remote obj) throws RemoteException,
MalformedURLException, UnknownHostException – leagă din nou obiectul obj sub
numele name, înlocuind dacă este cazul o altă legătură existentă sub același nume.
• public static void unbind (String name) throws RemoteException,
NotBoundException, MalformedURLException – șterge o legătură existentă în registru
sub numele dat ca argument.
În afara numelor de excepții deja întâlnite mai apar în pachetul java.rmi următoarele:
AccessException, ConnectException, MarshalException, NoSuchObjectException,
RMISecurityException, ServerError, ServerException, ServerRuntimeException,
StubNotFoundException, UnexpectedException, UnmarshalException
Unele dintre excepții sunt prevăzute cu mai multe variante de constructori, pentru a permite
specificarea la generare a unor informații mai detaliate.
III.2.b – Clasele accesibile programelor server
Exceptând clasa RMISecurityManager care se află în p achetul java.rmi , celelalte clase și
interfețe utilizate de programele server RMI se găsesc în pachetul java.rmi.server .
Cum s -a menționat deja, clasa RemoteObject reimplementează metodele hashcode și
equals ale clasei Object pentru a permite memorarea r eferirilor la obiecte la distanță în tabele de
hashing și compararea acestor referiri. Metoda equals returnează true dacă două obiecte Remote
(referiri la surogate) referă același obiect la distanță (compară referirile la distanță). Metoda toString
returne ază un șir care descrie obiectul la distanță cu precizarea că acest șir, ca și conținut și sintaxă este
dependent de implementare și deci poate varia. Clasa RemoteObject are doi constructori: protected
RemoteObject() și protected RemoteObject(RemoteRef new ref) – creează un obiect la
distanță, inițializat cu referirea la distanță specificată ( RemoteRef este o interfață din pachetul
java.rmi.server ).
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof. /conf./ ș.l.. dr . …….. 18 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Clasa RemoteServer este superclasa comună tuturor implementărilor de servere și oferă
potențial o gamă variată de semantici pentru referirile la distanță, dar se reamintește că în JDK există
deocamdată suport pentru o singură semantică, prin clasa UnicastR emoteObject . O specificare a
clasei abstract RemoteServer arată astfel:
package java.rmi.server;
public abstract class RemoteServer extends RemoteObject {
protected RemoteServer(); protected
RemoteServer(RemoteRef ref); public static String
getClientHost() throws ServerNotActiveException;
public static void setLog(OutpuStream out);
public static PrintStream getLog();}
Se observă că, și în acest caz, toate metodele clasei sunt statice. Metoda getClientHost , când
este apelată dintr -un fir de execuție care este în cursul tratării unui apel de metodă la distanță,
returnează numele calculatorului pe care rulează clientul. Celelalte două metode stabilesc, respectiv
obțin (citesc) identitatea fluxului folosit pentru crearea unui jurnal de apeluri la server. Clasa
UnicastRemoteObject derivă din RemoteServer și oferă suport pentru referiri ”punct -la-punct”
la obiecte active, folosind fluxuri bazate pe TCP. Deci, serverele care derivă din
UnicastRemoteObject sunt ne -replicate, iar referirile la ele vo r fi valabile numai cel mult pe durata
de viață a procesului (firului) care crează acest server. Clasa are un singur constructor ”no -arg” în
regim de acces protected și două metode: clone și export.
Metoda: public Object clone() throws CloneNotSupporte dException
reimplementează metoda cu același nume din clasa Object și returnează o copie (clonă) a obiectului la
distanță pentru care este apelată, distinctă de original. Noul obiect este imediat exportat, adică
disponibil pentru a primi apeluri la distanț ă (dacă este înregistrat și poate fi identificat de clienți sau
dacă i se distribuie astfel de apeluri).
Metoda: public static RemoteStub exportObject (Remote obj) throws
RemoteException se folosește pentru a exporta un obiect la distanță unicast, care n u este
implementat prin extinderea clasei UnicastRemoteObject . Odată exportat, obiectul poate fi
transmis ca argument într -un apel RMI sau returnat ca rezultat al unui apel RMI. Când se transferă
obiectul, în timpul ordonanțării, se caută surogatul la dist anță corespunzător și acest surogat este de
fapt transmis sau returnat.
Informația dintr -un UnicastRemoteObject este transient și deci nu va fi salvată atunci când
un obiect de acest tip se scrie într -un ObjectoutputStream definit de utilizator. Dar un ob iect care
este exemplar al unei subclase definită de utilizator a clasei
UnicastRemoteObject poate avea date netranzitorii care în consecință vor fi memorate în fluxul de
obiecte atunci când un asemenea obiect se serializează. Când se citește un UnicastRe moteObject
dintr -un ObjectInputStream , el este automat exportat către suportul de execuție RMI pentru a
putea primi apeluri RMI. Dacă dintr -un motiv oarecare exportul eșuează, deserializarea obiectului se
va termina cu o excepție.
CONDUCĂTOR ȘTIINȚIFI C ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 19 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Elec trică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Clasa RMISecurityManager din pachetul java.rmi definește politica de securitate pentru
surogatele RMI în programele aplicații (nu și în applet -uri). Se poate folosi acest manager de securitate
în cazul în care aplicația nu necesită funcții de securitate specializate, fiindcă el este deosebit de
restrictiv: dezautorizează toate funcțiile, cu excepția definirii și accesului la clase astfel încât clasele
pentru obiectele la d istanță, argumentele lor și valorile returnate să poată fi încărcate când sunt
necesare. Specificarea unui manager de securitate se face în metoda main a aplicației în felul
următor: System.setSecurityManager(new RMISecurityManager); În lipsa unui manager de
securitate, RMI nu va putea încărca clasele surogat decât din sistemul local de fișiere, conform valorii
variabilei CLASSPATH. Se reamintește că un manager de securitate trebuie să implementeze
metodele clasei abstracte java.lang.SecurityManager , care p ermit unei aplicații să determine
înainte de a efectua o operație potențial periculoasă, dacă aceasta ar urma să fie făcută printr -o clasă
adusă de un încărcător de clase și nu instalată local. Aplicația poate autoriza sau dezautoriza apoi
operația. Majori tatea metodelor au nume care încep cu cuvântul check, iar utilizarea lor se face
conform următoarei scheme:
SecurityManager security = System.getsecurityManager();
if(security != null) {
security.checkXXX(argument, …); }
În acest mod, manager ul de securitate poate preveni efectuarea operației XXX prin generarea
unei excepții: rutinele managerului revin normal dacă operația este permisă sau generează excepția
SecurityException dacă operația nu este permisă. Singura abatere de la această regulă apare la
metoda checkTopLevelWindow care returnează o valoare boolean.
Câteva exemple de metode din RMISecurityManager sunt:
– public synchronized void checkAccess (Thread t) throws
RMISecurityException – surogatele nu au dreptul să modifice argumentul T hread;
– public synchronized void checkCreateClassLoader() throws
RMISecurityException – surogatele nu au dreptul să creeze încărcătoare de clase și nici să
execute metode ale clasei ClassLoader;
– public synchronized void checkPropertiesAccess() throws
RMISecurityException – surogatele nu pot accesa întreaga listă de proprietăți a
sistemului, ci numai pe cele explicit etichetate ca accesibile surogatelor;
– public synchronized void checkPropertyAccess (String key) throws
RMISecurityException – surogatele p ot accesa proprietatea sistem identificată prin key
numai dacă perechea acesteia, key.stub are valoarea true;
– public synchronized void checkListen (int port) throws
RMISecurityException – surogatele nu pot ”asculta” la nici un port;
– public synchronized void checkConnect (String host, int port, Object
context) throws RMISecurityException – clasele încărcate
(inclusiv surogatele) pot face conectări dacă sunt apelate prin transportul RMI.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 20 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Clasa RMIClassLoader este un utilitar care se poate folosi de către aplicații pentru a
încărca clase de la un URL (din rețea).
public class RMIClassLoader { public static Class loadClass
(String name) throws MalformedURLException,
ClassNotFoundException; public static synchronized Class
LoadClass (URL codebase,
String name) throws MalformedURLException,
ClassNotFoundException;
public static Object getSecurityContext
(ClassLoader lo ader); }
Prima metodă loadClass folosește proprietatea java.rmi.server.codebase pentru a determina
URL -ul de la care se face încărcarea. Contextul de securitate returnat de ultima metodă este obținut
prin apelarea metodei getSecurityContext a clasei LoaderHandler .
Suportul de execuție RMI folosește un încărcător de clase propriu pentru a încărca surogatele,
scheletele și alte clase necesare surogatelor și scheletelor. Procesele server trebuie să declare
suportului de execuție RMI localizarea claselor – surogate ș i parametri sau valori returnate – ce vor fi
disponibile clienților lor, prin proprietatea java.rmi.server.
codebase .
Interfața LoaderHandler cu o definiție analoagă lui RMIClassLoader trebuie să fie
implementată de o clasă numită tot LoaderHandler care este definită în pachetul specificat de
proprietatea java.rmi.loader.pachagePrefix . Metodele acelei clase sunt folosite de
RMIClassLoader pentru efectuarea operațiilor sale.
Clasa abstractă RMISocketFactory specifică modul în care transportul RMI treb uie
să obțină sockets. Specificarea clasei arată astfel:
public abstract class RMISocketFactory {
public abstract Socket createSocket (String h, int p) Throws
IOException;
public abstract ServerSocket createServerSocket (int p) Throws
IOExceptio n;
public static void setSocketFactory (RMISocketFactory fac)
Throws IOException;
public static RMISocketFactory getSocketFactory(); public static
void setFailureHandler (RMIFailureHandler fh); public static
RMIFailureHandler getFailureHandler(); }
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 21 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULT ATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Implementarea implicită a fabricii de sockets (în suportul de execuție RMI) lucrează în felul
următor când trebuie realizată o conexiune între două calculatoare:
– Se încearcă mai întâi o conectare directă prin sockets cu mașina virtuală de la distanță;
– Dacă eșuează conectarea directă (datorită protejării mașinii la distanță prin firewall), suportul de
execuție încearcă o conectare prin HTTP cu număr ul de port explicit al serverului;
– Dacă nici această conectare nu reușește, atunci se comunică prin HTTP cu un script cgi -bin pe
server, căruia i se transmite prin POST apelul RMI.
O aplicație poate apela (o singură dată) metoda statică setSocketFactory pentru a specifica un
RMISocketFactory propriu. O asemenea fabrică de sockets ar putea conține, de exemplu, filtre
asupra conectărilor solicitate sau ar putea returna propriile extensii pentru java.net.Socket sau
java.net.ServerSocket , cum ar fi cele care să furnizeze un canal de comunicare securizat.
Aplicația poate specifica o fabrică de sockets proprie numai dacă acest lucru este permis de
managerul de securitate momentan activ, astfel generându -se SecurityException când se încearcă
acest lucru.
Meto da setFailureHandler stabilește rutina care se apelează de către suportul de execuție
RMI atunci când eșuează crearea unui socket. Rutina respectivă returnează o valoarea booleană pentru
a indica dacă se fac reîncercări de conectare (implicit suportul de e xecuție RMI nu permite
reîncercări). Această rutină trebuie să implementeze interfața:
public interface RMIFailureHandler { public
boolean failure (Exception ex);}
Metoda failure este cea care se apelează din RMI, transmițându -i-se excepția care a interzis crearea
unui socket.
III.2.c – Serviciul de inregistrare a obiectelor la distanta
Pachetul java.rmi.registry conține două interfețe, Registry și RegistryHandler , precum și clasa
LoacateRegistry, prin care se realizează serviciul de înregistrare și regăsire a obiectelor la distanță,
bazat pe nume simple. Este posibil ca fiecare proces server să -și definească propriul registru de obiecte
sau să se folosească un singur asemenea registru pentru un anumit calculator. Registrul este la rândul
său un o biect la distanță. Interfața Registry specifică metodele de căutare, legare, re -legare, ștergere
și listare a conținutului unui registru. De fapt, clasa java.rmi.Naming folosește interfața Registry
pentru a pune la dispoziție clienților un serviciu de num e bazat pe URL. Operațiile bind, unbind
și rebind sunt permise numai dacă solicitanții sunt pe același calculator ca și serverul, dar lookup
poate veni de oriunde.
Clasa LoacateRegistry conține metode statice care returnează o referire la un registru,
precum și o metodă prin care se creează un registru. Referirile returnate sunt în realitate referiri la un
surogat la distanță al registrului.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./c onf./ș.l.. dr . …….. 22 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Specificarea clasei LocateRegistry este:
public final class LocateRegistry { public
static Registry getRegistry () throws
RemoteException;
public static Registry getRegistry (int port)
throws RemoteException; public static Registry getRe gistry
(String host) throws RemoteException,
UnknownHostException; public static Registry getRegistry
(String host, int port)
throws RemoteException, UnknownHostException; public
static Registry createRegistry (int port)
throws RemoteException;}
Cele 4 metode getRegistry vor returna referiri la registrul de pe calculatorul curent; de pe
calculatorul curent la portul specificat; de pe calculatorul cu numele dat; de pe calculatorul cu numele
dat, la portul dat. (Por tul implicit, specificat în interfața Registry este 1099.)
Metoda createRegistry creează și exportă un registru pe calculatorul local, la portul
specificat. Acest registru implementează un serviciu de nume simplu, în care numele unui obiect la
distanță ( String) este pus în corespondență cu o referire la distanță. Legăturile astfel create sunt
valabile numai pentru activarea curentă a registrului. Dacă acest server este repornit, trebuie refăcute
toate legăturile.
Interfața RegistryHandler se folosește p entru legătura cu o implementare particulară a
serverului de nume și are specificarea:
public interface RegistryHandler {
Registry registryStub (String host, int port) throws
RemoteException, UnknownHostException; Registry registryImpl
(int port ) throws RemoteException;}
Metoda registryStub returnează un surogat pentru a contacta un registru la distanță pe
calculatorul și la portul specificate. Metoda registryImpl construiește și exportă un registru la
portul specificat (diferit de zero). În JDK este inclus un registru de obiecte la distanță implicit, care
se activează prin comanda: $ rmiregistry &.
III.2.d – Clasele si interfetele pentru surogate si schelete
În pachetul java.rmi.server se găsesc câteva clase și interfețe utilizate de surog atele și scheletele
generate de compilatorul rmic .
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 23 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Clasa abstractă RemoteStub , derivată din RemoteObject , este superclasa comună pentru
toate suro gatele. Ea furnizează un cadru în care se pot realiza diferite semantici pentru referirile la
distanță. Specificarea acestei clase arată astfel:
public abstract class RemoteStub extends RemoteObject {
protected RemoteStub;
protected RemoteStub (Re moteRef ref); protected
static void setRef (RemoteStub stub,
RemoteRef ref);}
Interfața RemoteCall este folosită de surogate și schelete pentru efectuarea unui apel la un
obiect la distanță. Metodele getOutputStream() , releaseOutputStream() ,
getInput Stream() și releaseInputStream() se referă la fluxurile de obiecte prin care se
realizează ordonanțarea/de -ordonanțarea argumentelor sau rezultatelor apelului. De exemplu,
getInputStream returnează fluxul de intrare din care surogatul își extrage prin de -ordonanțare
rezultatele sau din care scheletul extrage argumentele. Metoda getResultStream (boolean
success) returnează un flux de ieșire (după ce scrie în acesta o informație -antet referitoare la succesul
apelului). Obținerea fluxului cu rezultate trebuie să reușească doar o dată pentru fiecare apel. Dacă
success este true, rezultatul este normal; în caz contrar, rezultatul este o excepție, de exemplu
StreamCorruptedException dacă fluxul a fost deja obținut o dată pentru acest apel. Metoda
executeCall() va conține ceea ce este necesar pentru efectuarea apelului, iar done permite o
”curățire” după ce s -a terminat apelul la distanță.
Interfața RemoteRef reprezintă un descriptor (”handle”) pentru un obiect la distanță. Fiecare
surogat conține câte un exemplar de RemoteRef care constă din reprezentarea concretă a referinței.
Metoda newCall (RemoteObject obj, Operation[] op, int opnum, long hash)
creează un obiect de apel adecvat pentru un nou apel de metodă la distanță obj. Tabloul de operații op
conține operaț iile disponibile asupra obiectului la distanță, iar opnum este un indice în tabloul de
operații prin care se indică operația pentru apelul curent.
Interfața ServerRef reprezintă descriptorul în partea serverului pentru implementarea unui
obiect la distan ță.
Metoda exportObject (Remote obj, RemoteServer server, Object
data) caută sau creează un obiect surogat client pentru implementarea de obiecte Remote obj.
Parametrul server este obiectul server la distanță pentru a exporta obiectul (de exemplu un nu măr de
port).
Interfața Skeleton este folostiă numai în implementarea scheletelor generate de
compilatorul rmic.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 24 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Metoda dispatch (Remote obj, R emoteCall call, int opnum, long
hash) de-ordonațează argumentele din fluxul de intrare obținut de la obiectul call, apelează metoda
(indicată de opnum) pe implementarea efectivă a obiectului obj și ordonanțează valoarea returnată sau
generează o excepție.
Clasa Operation păstrează o descriere a unei metode pentru un obiect la distanță. Un obiect
Operation se construiește de obicei cu semnătura metodei.
III.2.e – Clasele si interfetele pentru colectorul de deseuri
Interfața DGC (Distributed Garbage Co llector) este folosită în partea de server a
algoritmului distribuit de colectare a deșeurilor, care implementează cele două metode ale interfeței,
dirty (ObjID[] ids, long sequenceNum, Lease lease) și clean (ObjID[] ids,
longseqNum, VMID vmid, boolean str ong) .
Un client trebuie să apeleze metoda dirty când de -ordonanțează o referire la distanță (clientul
va fi indicat prin VMID – Virtual Machine Identifier). Când clientul nu mai are referiri pentru o
anumită referire la distanță, el apelează clean. După un apel eșuat la dirty trebuie făcut un apel clean
cu strong având valoarea true, astfel încât la server să se rețină numărul de secvență al apelului pentru
a se putea ulterior detecta apeluri primite altfel decât în ordinea normală.
Referirile la obiect ele la distanță sunt împrumutate (leased) de către clienți, pe perioade
specificate, care încep din momentul primirii apelului dirty. Este responsabilitatea clientului să
reînnoiască împrumuturile înainte de expirare; în caz contrar colectorul de deșeuri p resupune că
obiectul la distanță nu mai este referit de acel client.
Un astfel de obiect conține un identificator unic al clientului, prin VMID (Virtual Machine
Identifier). Pentru fiecare obiect la distanță exportat în mașina virtuală locală, colectorul de deșeuri
(CD) păstrează o listă de referiri – identificatorii clienților care dețin referiri la acel obiect. Când se
acordă un împrumut, CD adaugă VMID -ul clientului la lista fiecărui obiect indicat în tabloul ids.
Numărul de secvență trebuie să crească pentru fiecare apel la CD. Unii clienți nu pot genera un VMID
unic, pentru că acesta conține adresa efectivă a calculatorului și aceasta nu le este unora accesibilă din
motive de securitate. În acest caz clientul folosește VMID = null, dar CD îi va asigur a un VMID, care
va fi folosit la următoarele apeluri.
Este necesar un singur apel la dirty pentru fiecare obiect la distanță, chiar dacă clientul deține
mai multe referințe pentru acel obiect.
Clasa Lease conține un VMID și o durată de împrumut.
Clasa ObjID se folosește pentru identificarea unică a obiectelor la distanță în cadrul unei
mașini virtuale. Fiecare identificator conține un număr de obiect și un identificator al spațiului de
adrese, care este unic pentru un anumit calculator. Identificatorul o biectului se asignează atunci când
se exportă obiectul la distanță.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 25 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Clasa ObjID reimplementează metodele hashCode , equals și toString . Are doi
constructori: ObjID() și ObjID (int num). Al doilea constructor generează identificatori de
obiecte binecunoscuți, de exemplu, utilizați de serviciul de nume și de colectorul de deșeuri. Aceste
numere nu vor intra în conflict cu cele generate de primul constr uctor.
Clasa UID se folosește pentru a crea identificatori care sunt unici în raport cu calculatorul pe
care s -au generat. Acești identificatori se folosesc în ObjID ca partea c are indică un spațiu de adrese.
Clasa VMID furniezează identificatori unici un iversali, în raport cu toate mașinile
virtuale Java (constau dintr -un UID și o adresă de calculator).
CAP.IV . – TIPARE DE PROGRAMARE
Datorită limitărilor sistemului RMI și a cerințelor frecvente din aplicații, se impun două tipare
în utilizarea RMI: fa brica de obiecte și apelul invers.
IV.1. – FABRICAREA OBIECTELOR
Deoarece RMI nu asigură pentru servere decât semantica UnicastRemoteObject , un server
nu poate fi în mod obișnuit activat (pornit) de către un client. Există însă aplicații în care creare a
dinamică a serverelor poate fi deosebit de utilă. Se poate realiza această creare dinamică a serverelor
printr -un artificiu: aplicația dispune de o fabrică de obiecte, adică de un obiect la distanță, cu semantica
uzuală de UnicastRemoteObject care însă c reează, la solicitarea unor clienți, obiecte la distanță noi
în aceeași mașină virtuală ca și el și returnează clienților referiri la distanță la aceste obiecte. În
continuare clienții vor solicita serviciile noilor obiecte la distanță care apar astfel ca servere create
dinamic. De regulă, fabrica de obiecte dispune de o singură metodă, pentru crearea unui obiect la
distanță de o anumită clasă, nu este obligatoriu ca în orice aplicație fiecare apel al metodei fabricii de
obiecte să conducă la crearea unui o biect nou. Este posibil, de exemplu, să se returneze o referire la
distanță spre același server pentru mai mulți clienți și să se creeze servere noi numai dacă numărul
clienților pentru un server depășește o anumită limită. Ca de obicei, apelurile din clie nt se fac
întotdeauna prin nume de interfețe implementate de obiectele la distanță. Dacă două clase
implementează interfețe la distanță, acestea trebuie prelucrate folosind utilitarul rmic. Numai fabrica de
obiecte se înregistrează însă la serverul de nume .
IV.2. – APEL INVERS
Pentru aplicațiile în care clienții utilizează informații variabile în timp, gestionate de un server,
este important ca modificările de informații să devină accesibile clientului cât mai rapid. O modalitate
ar fi ca din clienți să se apeleze periodic metodele corespunzătoare din server, ceea ce însă poate
conduce la un trafic suplimentar în rețea inacceptabil. Soluția mai eficientă este ca însuși serverul să
anunțe clienții atunci când apar modificări. În felul acesta traficul în re țea apare numai când este strict
necesar și numai cu clienții care și -au manifestat explicit interesul pentru a fi anunțați de modificări. În
plus, și serverul va avea o solicitare mai redusă (număr mai mic de apeluri) și poate alege momentul
cel mai conve nabil pentru anunțarea modificărilor.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 26 POPA D ANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Serverul va anunța clienții tot prin efectuarea unor apeluri de metode. Astfel de apeluri, de la
server la cli ent, se numesc apeluri inverse (callbacks). În RMI pentru a putea realiza apelurile inverse
este necesar să se definească o nouă interfață la distanță și să se implementeze această interfață de
către clienți. Pe de altă parte, interfața la distanță impleme ntată de server va trebui să prevadă o
metodă prin care clienții își pot înregistra la server interesul pentru a fi anunțați de apariția unor
modificări. Implementarea serverului va conține informații și cod pentru a ține evidența clienților care
solicită apeluri inverse și pentru a efectua aceste apeluri.
IV.3. – ACTIVAREA OBIECTELOR DE LA DISTANTA
Este posibil ca în aplicațiile distribuite orientate pe obiecte să existe la un moment dat un
număr mare de obiecte (de ordinul miilor sau mai mare), astfel încât apare problema menținerii tuturor
acestor obiecte în stare activă pe perioade lungi de timp, ceea ce ar conduce la un consum mare de
resurse. O altă problemă este aceea de a permite clienților să dețină referințe persistente la obiectele la
distanță astfel încât să se poată restabili comunicarea cu acestea după o cădere de sistem (în mod
normal, referințele la obiectele distribuite sunt valide numai când obiectele sunt active).Prin activarea
obiectelor la distanță în Java 2 se oferă o facilitate pent ru gestionarea execuției obiectelor și pentru
lucrul cu referințe persistente.Se numește obiect activ un obiect la distanță instanțiat și exportat într -o
mașină virtuală Java pe un calculator oarecare. Un obiect este pasiv dacă nu a fost încă instanțiat (s au
exportat), dar ar putea fi adus în stare activă. Activarea implică asocierea obiectului cu o JVM (Java
Virtual Machine), ceea ce mai departe poate implica încărcarea clasei obiectului într -o JVM și
restaurarea stării sale persistente (dacă există).
În implementarea activării în RMI s -a optat pentru activarea leneșă (”lazy activation”) ceea ce
înseamnă că aceasta nu se produce decât în urma primei apelări a unei metode a obiectului.Pentru
fiecare obiect la distanță cunoscut în sistem, un client poate o bține un descriptor persistent
(identificator la activare) care alcătuiește, împreună cu o referință la distanță tranzitorie o referință la
distanță defectabilă (”faulting remote reference”). Inițial referința tranzitorie (numită și referință vie)
este nul ă, dar la apelarea unei metode se declanșează protocolul de activare prin care se obține o
referință vie validă. În continuare apelurile de metode se realizează prin această referință vie.
Protocolul de activare implică următoarele entități: referința defe ctabilă, activatorul, un grup de
activare într -o JVM și obiectul la distanță ce urmează a fi activat.
Activatorul (de regulă câte unul în fiecare calculator) supervizează activitatea, îndeplinind
simultan două roluri:
– Bază de informații pentru realizar ea corespondenței între identificatorii de activare și
informațiile de activare (clasa obiectului, localizarea acestuia etc);
– Manager de JVM care inițiază JVM când este necesar și dirijează cererile de activare spre grupul
de activare corespunzător din JV M.
Un grup de activare (câte unul pentru o JVM) este entitatea care recepționează o cerere de activare
și returnează activatorului obiectul activat.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 27 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Protocolul funcționează astfel:
Folosind identificatorul de activare, referința defectabilă apelează activatorul (care apare
ca o interfață internă a RMI). Activatorul caută în baza sa de date descriptorul de activare în care
se află identificatorul d e grup al obiectului (precizează în ce mașină virtuală va fi activat
obiectul), precum și datele de inițializare în formă ordonanțată (posibil numele unui fișier care
conține starea persistentă, dacă aceasta există) și clasa obiectului (nume și cod);
Dacă grupul de activare există, activatorul dirijează cererea de activare spre acel grup. În
caz contrar activatorul inițializează o JVM care să execute grupul de activare și apoi dirijează
cererea de activare la acel grup;
Grupul de activare încarcă clasa o biectului și instanțiază obiectul folosind un constructor
special cu mai multe argumente, inclusiv descriptorul de activare anterior înregistrat;
Când activarea obiectului s -a încheiat grupul de activare transmite activatorului o
referință la obiect ordo nanțată. Acesta înregistrează referința vie și o returnează referinței
defectabile. Referința defectabilă (care apare în stub -ul unui client) dirijează apelurile de metode
prin referința vie spre obiectul la distanță.
Pentru a putea utiliza activarea est e necesar ca pe sistemul unde se află obiecte distribuite (la
distanță) să ruleze o implementare a interfețelor sistemului de activare, cunoscută sub numele rmid
(demonul de activare RMI). Demonul de activare se pornește din linia de comandă sau dintr -un shell
script (la fel ca rmiregistry ) și rămâne activ pe toată durata funcționării sistemului. Pentru ca un obiect
distribuit să poată fi accesat printr -un identificator de activare, trebuie ca el să îndeplinească două
condiții:
– Să aibă înregistrat un desc riptor de activare;
– Să conțină un constructor special care va fi apelat de sistemul RMI atunci când activează
obiectul.
Înregistrarea unui descriptor de activare ( ActivationDesc ) se poate realiza în mai multe moduri:
Prin crearea unui obiect ”activabi l” dintr -o clasă ce extinde clasa Activatable (în loc
de UnicastRemoteObject ) cu un constructor special al acesteia;
Prin crearea unui obiect care extinde UnicastRemoteObject și apelul metodei statice
register a clasei Activatable ;
Prin exportarea explic ită a unui obiect ”activabil” cu ajutorul uneia dintre metodele
exportObject ale clasei Activatable, care au ca parametri un ActivationDesc ,
implementarea unui obiect Remote și un număr de port.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 28 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTA MENTUL Calculatoare și tehnologia informației
În toate cazurile înregistrarea este realizată într -un program separat (parte a aplicației, dar numai
cu rol de inițializare) care se rulează înainte ca primul client să facă apel la o metodă a obiectului la
distanță activabil. Un MashallObject este un container pentru un obiect, care permite ca acel obiect
să apară ca parametru într -un apel RMI, dar amână deserializarea obiectului la receptor până când
aplicația cere explicit acel obiect. Obiectul serializabi l conținut într -un MarshallObject poate fi un
obiect distribuit, un obiect local sau un întreg graf de obiecte locale sau distribuite.
Constructorul păstrează într -un flux de octeți o reprezentare ordonanțată a obiectului dat ca
argument. Această reprez entare este conformă cu semantica obiectelor transmise în apelurile RMI:
– Fiecare clasă din flux este adnotată cu un URL pentru a putea identifica baza de cod a clasei
când se reconstruiește obiectul (în urma unui apel la get) și a încărca acest cod;
– Obiectele la distanță se înlocuiesc prin stub -urile corespunzătoare.
Când se cere s crierea unui exemplar al clasei MarshalledObject într-un
ObjectOutputStream , ceea ce se serializează este de fapt fluxul de octeți al obiectului conținut. La
citirea unui MarshalledObject dintr -un ObjectInputStream obiectul conținut nu este deserializat
până la apelarea metodei get. Metoda get reconstruiește întotdeauna o copie nouă a obiectului conținut
din forma ordonanțată a acestuia. Codul de hashing al reprezentării ordon anțate este același cu cel al
obiectului conținut (transmis constructorului). Metoda equals returnează true dacă reprezentările
ordonanțate ale obiectelor sunt echivalente: se ignoră baza de cod din forma ordonanțată.
CAP. V. – AVANTAJELE RMI
Serviciul R MI oferă următoarele avantaje față de Remote Procedure Call și sockets:
Orientare obiect: Prin RMI este posibilă transmiterea de obiecte ca parametri actuali și valori de
retur, ca de exemplu tabele de dispersie, față de tehnologiile RPC clasice, care ne cesită descompunerea
în tipuri primitive a structurilor și apoi reconstrucția lor pe server.
Comportament dinamic: când apare nevoia unui apel, clientul ia obiectul necesar de la server și
execută metodele dorite. Dacă se dorește actualizarea soluției est e posibilă actualizarea clasei remote de
pe server fără a mai altera clienții, care data următoare vor folosi versiunea actualizată.
Securitate: RMI utilizează mecanismele de securitate implementate în platforma Java.
Portabilitate: Tehnologia RMI permi te comunicarea între mașini virtuale cu implementare
diferită.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 29 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
CAP.V I. – SOFTWARE
VI.1. – PREZENTARE APLICATIE
Apelarea metodelor la distanță folosind mecanismul Java RMI constă în dezvoltarea unei
aplicații care să fie alcătuită dintr -un client și un server. Aplicația dezvoltată folosind acest mecanism
constă în realizarea unui bancomat online.
Într-o aplicație bancară online un client trebui e să poată realiza următoarele operații:
autentificare folosind un username și o parolă;
verificare sold;
vizualizare date;
efectuare plăți c ătre servicii (Vodafone , T-mobile, Orange, Digi , UPC, EON, Enel);
transferare bani către alt cont;
vizualizarea ultimelor tranzacții efectuate;
vizualizarea tuturor tranzacților efectuate.
În cele ce urmează vom face o descriere detaliată a aplicației ce implementează mecanismele
descrise pe parcursul capitolului 1 (apelarea metodelor la distanță fol osind Java RMI), dar și a operațiilor
efectuate asupra unei baze de date și mecanismele tehnologiei Swing folosite pentru realizarea interfeței
grafice.
VI.2. – TEHNOLOGII IMPLEMENTATE
Deși prezentarea de noțiuni teoretice din primul capitol se referă s trict la modalități de apelare a
metodelor la distanță folosind mecanismul RMI, aplicația folosește, pe lângă acesta, și alte tehnologii,
cum ar fi Swing și MySQL.
Tehnologia Java RMI (prezentată în capitolul anterior) este folosită pentru a realiza
comun icarea dintre cele două entități ale aplicației, clientul și serverul. Clientul dezvoltat apelează
metodele impelementate în Server.
Biblioteca Swing este tehnologia care oferă componentele necesare programatorilor pentru
crearea de interfețe grafie moder ne și complexe. Cu ajutorul acestei tehnologii a fost dezvoltată
interfața grafică pentru modulul client al aplicației. Având în vedere că avem de -a face cu o bază de
date în care sunt memorate datele despre clienți, în implementare a fost necesară utiliza rea unui server
de baze de date, și anume am preferat MySQL. Acest sistem de gestiune a bazelor de date este foarte
rapid, permite mai multe fire de execuție (thread -uri), mai mulți utilizatori și dispune de un limbaj
robust SQL (Structured Query Language) .
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 30 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACU LTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Baza de date administrează entitățile aplicației: utilizatorii, conturile acestora, dar și tranzac țiile
efectuate de utilizatori. JDBC (Java DataB ase Connectivity) reprezintă API -ul (Application
Programming Interface) dezvoltat de Sun Microsystems, în colaborare cu diverși parteneri, pentru a
oferi utilizatorilor acces la bazele de date gestionate de diferite DBMS -uri (DataBase Management
System) .
Într-o arhitectură client -server, bazele de date se pot afla pe aceeași mașină sau pe altă mașină
cu care clientul este conectat dintr -un intranet sau chiar internet. Cele mai importante facilități ale
JDBC -ului sunt posibilitatea lucrului cu instrucțiuni SQL și procesarea eventualelor rezultate obținute
în urma interogărilor într -o manieră independentă și consistentă. Putem privi API -ul JDBC ca o
interfață standard între aplicații și diverse DBMSuri, creatorii aplicațiilor programând, conform acestui
API, într-un mod uniform și independent de DBMS. JDBC furnizează acces orientat pe obiecte la
bazele de date, prin definirea de clase și interfețe care înfășo ară diverse concepte abstracte. De
asemenea, standardul JDBC definește o serie de interfețe care trebui e implementate de creatorii
driverelor cu scopul de a oferi dezvoltatorilor informații despre baza de date interogată, DBMS -ul
folosit etc.
VI.3. – IMPLEMENTAREA SERVERULUI MySQL
3. a. Baza de date:
Pentru a ține evidența clienților împreună cu datele personale despre aceștia și tranzacțiile ce sunt
efectuate asupra contului, este necesară folosirea unei baze de date.
Fig. 3.1 – Baza de date
3. b. Crearea bazei de date:
Pentru a crea o bază de date nouă se lansează în execuție de p e serverul local pagina phpMyAdmin, se
introduc userul și parola și se crează o nouă bază de date prin acordarea unui nume valid. În cazul
nostru baza de date se numește ’bancomat’.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 31 POPA DANIELA
F
i
g
u
r
a
2
.
2
.
1
.
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calcul atoare și tehnologia informației
Fig. 3.2 – Realizarea bazei de date
3. c. Crearea tabelelor:
După ce baza de date a fost creată trebuie să creăm tabelele ce vor face parte din aceasta.Avem nevoie
de patru tabele, una pentru clienții băncii, una pentru con turile de logare, una pentru înregistrarea
conturilor bancare deschise și încă una pentru păstrarea tranzacțiilor efectuate. În figura următoare este
prezentat procesul de creare a tabelei login. Când creăm o tabelă trebuie să îi introducem și câmpurile
existente în aceasta. În cazul în care la creare se uită adăugarea unui anumit câmp, se poate adăuga și
ulterior. Pentru fiecare câmp avem o serie de caracteristici care trebuie speificate. Printre aceste
caracteristici se află și constrângerile pentru chei primare, unice, diferite de null. Câmpurile introduse
au un tip de dată și o lungime, pe lângă constrângeri.
Fig. 3.3 – Realizarea tabelelor
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf ./ș.l.. dr . …….. 32 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Elec trică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Pe lâ ngă aceste tipuri mai putem găsi și alte tipuri, cum ar fi SMALLINT, BIGINT și altele.
Dacă lungimea câmpului nu este setată de către utilizator, se va seta implicit valoarea. Fiecare tabel
trebuie să aibă un câmp setat ca și cheie primară pentru a putea f ace legăturile cu alte tabele. În tabela
’login’ câmpul ’nr’ este cheie primară deoarece reprezintă numărul înregistrării. Câmpul ’username’
trebuie să fie cheie unică pentru a nu permite crearea a doi useri cu același nume, dar parole diferite.
Fig. 3.4 – Vizualizarea tabelelor din baza de date
3. d. Vizualizarea tabelelor create:
În cazul în care vrem să ne asigurăm că am creat toate tabelele sau că am scris numele corect, putem
să vizualizăm toate tabelele create în baza de date selectată. În cazul de față sunt patru tabele: clienti,
conturi, login și tranzactii.
Fig. 3.5 – Tabela conturi
Fig. 3.6 – Tabela clienți
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 33 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Elec trică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informaț iei
Fig. 3.7 – Tabela login
Fig. 3.8 – Tabela tranzacții
3. e. Campurile unu tabel:
Fiecare tabel are un anumit număr de câmpuri specifice tabelului. Se poate vizualiza lista completă a
câmpurilor dintr -un tabel selectat, împreună cu caracteristicile s pecificate pentru fiecare în parte.
Pentru a putea realiza interogări SQL trebuie să specificăm numele câmpurilor exact cum sunt
memorate în baza de date. În caz contrar interogările nu se vor realiza și se va afișa un mesaj de eroare.
O altă eroare poate apărea în cazul în care nu corespund caracteristicile specificate în interogare cu
caracteristicile salvate în baza de date.
VI.4. – CONECTAREA BAZEI DE DATE
Pentru a putea avea acces la datele înregistrate în baza de date este necesară crearea unei
conexiuni la baza de date.
Procesul obținerii de informații dintr -o bază de date folosind JDBC implică în principiu cinci pași:
1. înregistrarea driverului JDBC folosind gestionarul de drivere DriverManager;
2. stabilirea unui conexiuni cu baza de date;
3. execuți a unei instrucțiuni SQL;
4. procesarea rezultatelor;
5. închiderea conexiunii cu baza de date.
Printr -o conexiune (sesiune) la o bază de date sunt trimise secvențe SQL și se primesc rezultate. Într -o
aplicație pot exista mai multe conexiuni simultan la baze d e date diferite sau la aceeași bază de date.
Rolul managerului de drivere este acela de a ține o referință la fiecare dintre obiectele driver disponibile
în aplicația curentă. Un driver JDBC este înregistrat automat de managerul de drivere atunci când clas a
driver este încărcată dinamic. Pentru încărcarea dinamică a unui driver JDBC, folosim metodele
Class.forName():
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 34 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Class.forName("com.mysql.jdbc.Driv er");
Class.forName() este o metodă statică.
Aceasta permite mașinii virtuale Java să aloce dinamic, să încarce și să facă o legătură la clasa
specificată ca argument printr -un șir de caractere. În cazul în care clasa nu este găsită, se aruncă o
excepți e ClassNotFoundException . Odată ce s -a încărcat un driver, putem să -l folosim pentru
stabilirea unei conexiuni cu baza de date. O conexiune JDBC este identificată printr -un URL JDBC
specific. Pentru aplicația p rezentată adresa corectă este:
jdbc:mysql:// localhost:3306/bancomat
Prima parte precizeză că pentru stabilirea conexiunii se folosește JDBC, urmat de un nume de
driver valid (MySQL). După specificarea driverului este un nume logic sau alias care corespunde bazei
de date fizice. Baza de date este ’ bancomat’ și este salvată pe mașina locală ce are numărul de port
specificat (3306). Pentru stabilirea unei conexiuni la o bază de date se folosește metoda statică
getConnection() din clasa DriverManager.
String url = "jdbc: mysql: //localhost: 3306/ ban comat";
Connection con=DriverManager.getConnection(url,user,parola);
VI.5. – INTEROGAREA BAZEI DE DATE
După ce s -a stabilit conexiunea, se pot trimite interogări SQL către baza de date. APIul JDBC
nu verifică dacă instrucțiunea este corectă și nici apa rtenența ei la un anumit standard SQL,
permițându -se astfel trimiterea chiar de instrucțiuni nonSQL. Programatorul este cel care știe dacă
DBMS -ul interogat suportă interogările pe care le trimite și, dacă nu, el este cel care va trata excepțiile
primite d rept răspuns. Dacă instrucțiunea este SQL, atunci aceasta poate face anumite operații asupra
bazei de date, cum ar fi căutare (folosind comanda SELECT), inserare (folosind INSERT), actualizare
(UPDATE) sau ștergere (DELETE). API -ul JDBC specifică trei inte rfețe (pe care dezvoltatorul
driverului trebuie să le implementeze) pentru trimiterea de interogări către bazele de date, fiecăreia
corespunzându -i o metodă specială în clasa Connection , de creare a instanțelor corespunzătoare.
Pentru execuția unei instruc țiuni SQL neparametrizate, se folosește metoda createStatement (),
aplicată unui obiect Connection . Această metodă întoarce un obiect din clasa Statement:
Statement c = con.createStatement();
Putem aplica apoi una dintre metodele executeQuery(), executeUp date() sau
execute() obiectului de tip Statement pentru a trimite DBMS -ului instrucțiunile SQL. Metoda
executeQuery() este folosită în cazul interogărilor care returnează mulțimirezultat (instanțe ale
clasei ResultSet ), așa cum este cazul instrucțiunilor S ELECT. Pentru operațiile de actualizare sau
ștergere, cum ar fi INSERT, UPDATE sau DELETE, se folosește metoda executeUpdate()
aplicată obiectului de tip Statement , rezultând un întreg care reprezintă numărul înregistrării
afectate.
CONDUCĂTOR ȘTIINȚIF IC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 35 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electri că și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Statement c = con.createStatement();
ResultSet r = c.executeQuery("SELECT clienti.nume FROM clienti, login
WHERE login.user='" + user + "' AND login.user = clienti.user");
Dacă se dorește realizarea de apeluri SQL având date variabile drept intrare, se va folosi clasa
PreparedStatement care moștenește clasa Statement :
PreparedStatement pst = con.prepareStatement ("SELECT * FROM login
WHERE user=? and parola=?");
După cu m se observă, prin construcție, obiectul de tip PreparedStatement primește ca
intrare o instrucțiune SQL (spre deosebire de cazul Statement ). În momentul construcției,
instrucțiunea SQL primită ca parametru este trimisă direct spre DBMS, unde este precompi lată.
Folosind metode setXXX() corespunzătoare tipurilor de date, vom da valori variabilelor și abia după
aceea vom executa interogarea:
pst.setString(1, user); pst.setString(2,
parola); rs=pst.executeQuery();
Această manieră de interogare este mai ra pidă decât folosirea clasei Statement, în cazul în care
dorim execuția repetată a unei instrucțiuni SQL. Instrucțiunea SQL este compilată o singură dată în
momentul creării instanței clasei PreparedStatement și folosită apoi în mod repetat, eventual cu
valori diferite ale parametrilor.
Fig. 5.1 – Diagrama tranzacții
În figura următoare este prezentată structura bazei de date ’bancomat’.
CONDUCĂTOR ȘTIINȚIFIC ABSOLV ENTA
prof./conf./ ș.l.. dr . …….. 36 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia inform ației
VI.6. – PROCESAREA REZULTATELOR
Pentru parcurgerea simplă a înregistrărilor unui obiect din clasa ResultSet folosind JDBC,
folosim metoda next(), ca în următoarea secvență de cod:
while (r.next()) {
return r.getInt("suma_disp"); }
VI.7. – DECONECTAREA BAZEI DE DATE
Atunci când este vorba despre resurse exterioare, așa cum este cazul accesului la DBMS -uri via
JDC, ”colectorul de gunoaie” nu știe nimic despre starea acestor resurse, dacă este sau nu cazul să le
elibereze. De aceea, este recom andat ca, după ce procesarea datelor s -a încheiat, programatorii să
închidă explicit conexiunile către baza de date.
Pentru aceasta se folosește metoda close() aplicată obiectului Connection . În plus, trebuie
închise (înaintea conexiunii) și obiectele Statement și RezultSet folosind metodele lor close().
pst.close(); rs.close();
con.close();
VI.8. – SERVICIU DE LA DISTANTA
Un obiect de la distanță este un obiect care a fost setat să accepte apeluri de metode de la un alt
obiect care rulează într -o mașină virtuală Java la distanță.
Pentru crearea serviciului la distanță, rulat de pe server, trebuie parcurse cinci etape:
1. crearea interfeței de la distanță (Remote Interface);
2. crearea unei implementări la distanță (Remote Implementation);
3. generarea obiectelor Stub și Skeleton folosind utilitarul rmic;
4. rularea utilitarului de înregistrare în registrul de nume (rmiregistry);
5. pornirea serviciului de la distanță.
VI.9. – INTERFATA DE LA DISTANTA
Interfața de la distanță trebuie să extindă interfața java.rmi.Remote, care este doar un
indicator ce identifică interfețele accesibile la distanță. Remote este o interfață de ”marcare” (marker
interface), adică nu are nici o metodă. Totuși, această interfață are o semnificație specială pentru RMI,
deoarece este superinterfața tuturor intefețelor de la distanță. Toți parametrii și rezultatul întors al unei
metode la distanță trebuie să fie serializabile de fluxul de obiecte.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 37 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculato are și tehnologia informației
Când un client RMI accesează un obiect la distanță, acesta va putea accesa obiectul doar prin
una sau mai multe interfețe la distanță. Beneficiul este că implementarea este separată de interfața
publică.
import java.rm i.*; public interface Bank_Interface
extends Remote { … }
Interfața astfel creată declară că va fi folosită pentru apelarea metodelor de la distanță. O
interfață nu poate să implementeze nimic, dar poate să extindă o altă interfață. Toate metodele
declarate în cadrul interfeței pot să lanseze excepții de tip RemoteException , deoarece interfața de
la distanță este cea care va fi folosită de client ca tip polimorf pentru serviciu. Cu alte cuvinte, clientul
apelează metode pentru stub -ul care implementeaz ă interfața de la distanță. Stub -ul se o cupă de partea
de rețea și I/O. Dacă metodele dintr -o interfață declară excepții, codul care apelează metode ale unei
referințe de tipul interfeței trebuie să trateze sau să declare excepțiile.
public Bank_Resul t vizualizare(String u)
throws RemoteException;
VI.10. – IMPLEMENTAREA DE LA DISTANTA
Serviciul trebuie să implementeze interfața de la distanță – cea care declară metodele pe care
urmează să le apeleze clientul.
public class Account extends Uni castRemoteObject implements Bank_Interface
{ … }
Pentru a funcționa ca serviciu la distanță, obiectul are nevoie de funcționalitate specială, legată
tocmai de faptul că se află ”la distanță”.
VI.11. – OBIECTE Stub si Skeleton FOLOSIND UTILITARUL RM IC
Clientul Stub și obiectul de la distanță Skeleton conțin tot codul implicat în detalii de
serializare a apelului metodei la distanță. Pentru serializare se utilizează clasa
ObjectOutputStream ; trimiterile se realizează prin conexiuni socket TCP/IP, iar pentru
deserializare se recurge la clasa ObjectInputStream . Trimiterea obiectelor are loc întotdeauna doar
prin valoare. Utilitarul rmic , furnizat în setul de dezvoltare Java, primește ca argument în linia de
comandă clasa de implementare a serviciului și creează două noi clase, racordul (stub) și scheletul
(skeleton). Utilitarul folosește o convenție de denumire, adăugând _Stub și _Skel la numele clasei de
implementare.
Există și alte opțiuni care pot fi folosite pentru utilitarul rmic, inclusiv omiterea clasei schelet,
furnizarea codului sursă al claselor generate și chiar folosirea protocolului IIOP. Clasele sunt salvate în
directorul curent, iar utilitarul rmic trebuie să poată vedea clasa de implementare, de aceea rulăm
utilitarul din directorul în ca re se află și clasa de implementare.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 38 POPA DA NIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
VI.12. – RULAREA UTILITARULUI DE INREGISTRARE
Pentru a pune la dispoziția clienților serviciul la distanță, cr eăm o instanță și o adăugăm în
registrul RMI (care trebuie să fie lansat în execuție, altfel se va afișa o e roare). Atunci când este
înregistrat obiectul de implementare, sistemul RMI pune în registru racordul (stub), deoarece acesta
este cel de care are n evoie, de fapt, clientul. Serviciul este înregistrat folosind metoda statică
rebind() din clasa java.rmi.Naming .
Account server = new Account();
System.out.println("Server> Serverul a fost creat…");
Naming.rebind("Server_Bank", server);
System.out.println("Server> Serverul a fost pornit…");
Un registru de nume poate fi pornit manual prin comanda rmiregistry sau programatic cu
ajutorul metodelor din clasa LocateRegistry . Obiectele de la distanță pot fi înregistrate utilizând
clasa java.rmi.Naming (ca în exemplul de mai sus) care folosește o schemă de numire asemănătoare
cu cea de la URL -uri. Un registru de nume este el însuși un client simplu RMI, deci acesta trebuie să
aibă acces la fișierele stub pentru toate clasele care sunt înregistra te. Când un obiect se înregistrează cu
registrul de nume, acesta specifică un nume stub care trebuie referit. Clienții pot utiliza clasa
java.rmi.Naming pentru a obține o referință la distanță a obiectului din registru. Obiectul este
simplu identificat ca un URL care conține numele gazdei pe care registrul de nume rulează și numele
sub care obiectul este referit.
VI.13. – PORNIREA SERVICIULUI DE LA DISTANTA
Lansarea în execuție a serviciului se poate face din metoda main a clasei de implementare sau
dintr-o clasă separată de pornire a serviciului.
VI.14. – LANSAREA CLIENTULUI
În cazul aplicației bancare interfața grafică a aplicației reprezintă clientul. Pentru a putea apela
metodele de la distanță clientul este nevoit să se autentifice.
14.a – AUTENTIFICAREA CLIENTILOR
Autentificarea clienților este principala operație pe care un client este nevoit să o realizeze.
Dacă un client nu are cont nu se poate loga și astfel nu poate face nimic.Conturile clienților se crează în
momentul deschiderii unui cont bancar. Folosind această aplicație nu se pot crea conturi deoarece nu ar
fi o situație reală ca un client să aibă cont pentru logare dar să nu aibă cont bancar. Procesul de
autentificare este destul de simplu. Clientul introduce username -ul și o parol ă în formular. Șirurile de
caractere introduse în cele două câmpuri sunt extrase și verificate cu datele introduse în baza de date.
Parola din baza de date este criptată și nu se poate decripta pentru a vedea valoarea efectivă a ei.
.
CONDUCĂTOR ȘTIINȚI FIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 39 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Ele ctrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
De aceea, parola introdusă de client este și ea criptată, folosind algoritmul de criptare Message
Digest Algorithm 5, și comparată cu parola în formă criptată salvată în baza de date. Dacă datele
introduse în formular corespund cu valorile din baza de date, se vor extrage datele din baza de date și
clientul va putea naviga prin aplicație. În caz contrar, un mesaj de eroare va fi afișat, iar clientul este
rugat să reintrod ucă username -ul și parola.
Fig.14.1 – Autentificarea clienților
Fig.14.2 – Autentificarea reușită
Fig.14.3 – Autentificarea nereușită
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 40 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
14.b – VIZUALIZAREA DATELOR PERSONALE
Vizualizarea datelor personale se poate face doar după autentificarea clienților. Datele
introduse în tabela ’clienti’ în baza de date sunt extrase prin interogări SQL folosind legăturile din
baza de date. Pentru a putea afișa datele din baza de date, ne folosim de câmpul cu cheie primară
’username’ din tabela ’login’. Acest câmp are și cheie străină în tabela ’clienti’, astfel fiind posibilă
extragerea datelor din tabelă
Fig.14.4 – Date personale
14.c – VIZUALIZAREA SOLDULUI DISPONIBIL
Fig.14.5 – Vizualizare sold
Pentru a vizualiza soldul disponibil este necesară o interogare a bazei de date. Pentru a realiza
această interogare se folosește butonul ”verifica” . După apăsarea acestui buton se va afișa suma
disponibilă în cont
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 41 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Fig.14.6 – Afișare sold
14.d – EFECTUAREA PLATILOR
În secțiunea pentru efectuarea de plăți clientul trebuie doar să introducă suma pe care vrea să o
achite și să selecteze serviciul care va urma să fie plătit. Serviciile sunt clasificate în felul următor:
– servicii de telefonie;
– servicii de gaz;
– servicii de electri citate;
– servicii de internet și televiziune;
Fig.14.7 – Plăți
Suma introdusă în formular este extrasă și comparată cu suma disponibilă în cont. În cazul în
care suma disponibilă în cont este mai mică decât suma introdusă, se va afișa un m esaj de informare și
se va solicita introducerea unei alte sume.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 42 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
În cazul în care suma introdusă se încadrează în soldul disponibil, clientul poat e alege un
serviciu, sau mai multe, pentru a -l/a le plăti.
Fig.14.8 – Fonduri insuficiente
Fig.14.8 – Plata efectuaă
După efectuarea plății se afișează un mesaj pentru confirmarea tranzacției clientului. După
închiderea mesajului de informare, în fereastra unde a fost pornit serverul va fi afișată tranzacția
efectuată. Tranzacția făcută (plătirea unui serviciu) va adăuga în tabela ’tranzactii’ o nouă înregistrare.
Data la care s -a realizat tranzacția este data luată de pe mașina virtuală pe care s -a executat clientul.
Fig.14.9 – Tranzacție efectuată (server)
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 43 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Fig.14.10 – Tranzacție efectuată (client)
În partea clientului se afișează și det alii despre tranzacția efectuată și câți bani au fost depuși în
ziua respectivă în contul pentru serviciul ales (în cazul acesta în contul Upc).
14.e – TRANSFER CATRE ALTE CONTURI
Transferarea banilor dintr -un cont în altul se poate realiza la fel de s implu ca și efectuarea
plăților. În formular trebuie introduse următoarele date: contul în care se transferă banii, numele
proprietarului și suma care se transferă.
Fig.14.11 – Formular transfer
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 44 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPA RTAMENTUL Calculatoare și tehnologia informației
Suma introdusă trebuie să fie mai mică decât suma disponibilă în cont. În caz contrar, se va
afișa un mesaj de eroare și clientul va fi rugat să re introducă datele în formular. După introducerea
datelor în formular se va afișa un mesaj de informare că transferul a fost efectuat cu succes.
Fig.14.12 – Transfer reușit
14.f –VIZUALIZAREA TRAN ZACTIILOR
Fig.14.13 – Formular tranzacții
Clientul are posibilitatea să vizualizeze tranzacțiile efectuate în zi ua curentă, dar și toate
tranzacțiile care au fost efectuate asupra contului.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 45 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Fig.14.14 – Toate tranzacții
CAP. V II. – CONCLUZII
În toată lum ea, pentru marea majoritate a oamenilor, salariile și pensiile sunt virate într -un cont
bancar personal. De obicei la acest cont se poate atașa și un card, dar sunt oameni care nu au atașat
câte un card pentru fiecare cont și de aceea este foarte folositoa re o aplicație bancară online pe care
oamenii o pot folosi pentru a -și verifica soldul existent într -un cont sau chiar ultimele tranzacții făcute.
O astfel de aplicație bancară, care seamănă cu un bancomat, este destul de complexă dacă
analizăm operațiil e care au loc în spatele interfeței grafice pe care o vede un client. Interfața grafică a
aplicației reprezintă de fapt o componentă a aplicației, adică clientul, care comunică cu cea de -a doua
componentă, serverul aplicației. Cu ajutorul tehnologiei Java RMI ( Remote Method Invocation ),
clientul poate apela la distanță metodele implementate în server. Metodele apelate la distanță sunt
metodele care se ocupă de administrarea contului bancar și anume: verificarea soldului, efectuarea de
plăți către anumite s ervicii (de telefonie fixă sau mobilă, de energie electrică, de gaz, de Internet –
Vodafone, Orange, Cosmote, RDS -RCS, EON, Enel…), dar și lista tranzacțiilor efectuate este afișată
tot în urma apelării unei metode la distanță.
Aplicația mai oferă o fac ilitate, și anume, aceea de transfera bani din contul curent (pe care este
logat clientul) către alt cont specificat. Cel de -al doilea cont poate fi un alt cont care îi aparține
clientului logat sau dacă nu, poate fi contul unui alt client. Acest lucru se poate realiza f oarte simplu și
foarte rapid. Pentru ca un client să poată folosi aplicația, acesta trebuie mai întâi să își deschidă un
cont bancar la o bancă (fie aceasta BRD, BCR, ING etc.). După ce contul este deschis, clientul
primește un username și o parolă. Username -ul este ales de către client în momentul în care specifică
și datele despre el. Parola este generată de către angajații băncii printr -un program de generare
aleatoare și apoi este înmânată clientului, într -un plic sigilat. În cazul uităr ii parolei, clientul este
nevoit să se prezinte la sediul băncii pentru a primi o altă parolă.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 46 POPA DANIELA
UNIVERSITATEA DIN ORADEA
FACULTATEA de Inginerie Electrică și Tehnologia Informației
DEPARTAMENTUL Calculatoare și tehnologia informației
Datele despre clienți, conturi sau tranzacții sunt me morate într -o bază de date care este
administrată folosind serverul de baze de date MySQL. Baza de date se numește ' bancomat ' și este
formată din patru tabele.
Tabela principală este tabela ' clienti '. În momentul în care un client este adăugat în această
tabelă vom putea să -i creăm un cont pentru logare și un cont bancar. În tabela ' login ' se vor memora
conturile pentru logare (se memorează un username, o parolă și numărul de înregistrare – parola
asociată user -ului este criptată folosind metoda de cripta re Message Digest Algorithm 5).
În interfața grafică, clientul introduce username -ul și o parolă. Pentru a verifica dacă parola
introdusă de client corespunde cu parola introdusă, la început, în baza de date, se extrage parola din
formular și se criptează folosind metoda de criptare Message Digest Algorithm 5. După aceea se
extrage din baza de date parola sub formă criptată și se compară cu rezultatul obținut după cripatarea
parolei introduse în formular. Cele două parole sunt de fapt două șiruri de caract ere care vor fi mai
apoi verificate, caracter cu caracter, pentru a putea decide dacă parolele corespund sau nu.
Pentru cazurile în care username -ul și parola introduse sunt exact ca în baza de date, se pot
vedea informații despre client, dar și despre con t. Cele două tabele, 'clienti' și 'login' sunt legate prin
câmpuri le 'id_client' și 'username'.
Într-o lume care este într -o continuă evoluție, este necesară o continuă modificare a aplicațiilor
dezvoltate. În acest caz ar fi câteva îmbunătățiri care ar putea fi aduse asupra aplicației. Probabil ar fi
mai eficient, și mai comod, ca fiecare client să aibă un singur username pentru fiecare cont. M -am
gândit că ar fi bine ca pentru fiecare cont să existe un username pentru a nu încurca conturile (de
exemplu contul ce are username1 este contul pentru credit, iar contul ce are username2 este contul
pentru s alariu – și așa mai departe). Pentru partea de efectuare a plaților serviciilor (de telefonie, de
gaz sau de electricitate) se cere doar suma care se transfe ră către firmele afișate în interfața grafică,
deci pentru a îmbunătăți acest serviciu ar trebui să avem în baza de date încă o tabelă care să conțină
toate facturile emise de aceste servicii. În momentul în care un client ar vrea să plătească un serviciu s-
ar putea face o interogare în baza de date și să se afișeze o listă cu facturile neplătite și suma care
trebuie plătită. În acest fel clientul poate fi sigur că a acoperit toată suma care a fost facturată și nu mai
puțin. Ar fi o metodă mai bună deoarece clientul știe în acest fel exact ce sumă are de plătit la un
anumit serviciu.
VII.1. – IMPLEMENTAREA CLOUD
Ca o mică concluzie, aș putea spune că o astfel de aplicație în domeniul bancar este foarte
complexă și în același timp folositoare. Știm bine cu toții că în ultimii ani multe aplicații gen desktop
s-au mutat pe CLOUD. Pentru a asigura o mai mare mobilitate a aplicațiilor se poate realiza chiar și
mutarea bazei de date pe CLOUD. Este mai simplă navigarea pe Internet și aflarea anumitor date în
câteva minute fără a fi necesară o deplasare până la un bancomat sau chiar până la o bancă. Pentru ca a
o aplicație asemănătoare să fie folosită de o bancă reală, ar trebui adăugate mai multe validări și
realizate metode pentru securizarea datelor.
Pentru log area clientului se poate face o metodă care generează automat o parolă de fiecare
dată când clientul dorește să folosească aplicația. După generarea parolei, aceasta ar trebui să fie
trimisă pe mail sau prin sms pentru a nu întâmpina probleme cu logarea. A stfel datele și banii ar fi în
siguranță.
CONDUCĂTOR ȘTIINȚIFIC ABSOLVENTA
prof./conf./ ș.l.. dr . …….. 47 POPA DANIELA
– BIBLIOGRAFIE –
1. Andrei Ștefan, Olaru Cristian, Tănasă Ștefan – Java de la 0 la expert , Polirom, 2003.
2. Bates Bert, Sierra Kathy – Atac la Java , Editura Teora, Bucuresti, 2006
3. Despi Ioan, Petrov Gheorghe, Reisz Robert – Teoria Generala A Ba zelor De Date ,
Editura Mirton, Timișoara, 2002.
4. Eckstein Robert , Elliott James , Loy Marc , Wood David – Java Swing, 2002
5. Grosso William – Java RMI , O’Relly, 2001
6. Ionescu Felicia – Baze De Date Relaționale și Aplicații , Editura Tehnică, București, 2004
7. Jurca Ioan – Programarea rețelelor de calculatoare , Editura de Vest, Timișoara, 2001.
8. McNiff Kathleen, Pi tt Esmond – java(TM).rmi: The Remote Method Invocation Guide , 2001.
9. Java Distributed Computing – Jim Farley – Oreilly – 1998
10. Enterprise Cloud Computing – Gautam Shroff – 2013
11. Java RMI – Remote Method Invocation – Addison -Wesley professional – 2011
12. Java Deep Learning Essentials – Yusuke Sugomori – Packt – 2016
13. http://control.aut.utcluj.ro/scd/lab4/distributedObjects.htm
14. http://docs.oracle.com/javase/1.5.0/docs/guide/rmi/relnotes.html
15. http://docs.oracle.com/javase/tutorial/onlineT raining/rmi/RMI.html
16. http://en.wikipedia.org/wiki/Java_RMI
17. http://en.wikipedia.org/wiki/Java_remote_method_invocation
18. http://liis.is.edu.ro/~doinah/informatica/RMI_CORBA
19. http://www. cs.swan.ac.uk/~csneal/InternetComputing/RM2.html
– ANEXE –
Fig. 3.1 – Baza de date
Fig. 3.2 – Realizarea bazei de date
Fig. 3.3 – Realizarea tabelelor
Fig. 3.4 – Vizualizarea tabelelor din baza de date
Fig. 3.5 – Tabela conturi
Fig. 3 .6 – Tabela clienti
Fig. 3.7 – Tabela login
Fig. 3.8 – Tabela tranzacții
Fig. 5.1 – Diagrama tranzacții
Fig.14.1 – Autentificarea clienților
Fig.14.2 – Autentificarea reușită
Fig.14.3 – Autentificarea nereușită
Fig.14.4 – Date personale
Fig.14.5 – Vizual izare sold
Fig.14.6 – Afișare sold
Fig.14.7 – Plăți
Fig.14.8 – Fonduri insuficiente
Fig.14.9 – Tranzacție efectuată (server)
Fig.14.10 – Tranzacție efectuată (client)
Fig.14.11 – Formular transfer
Fig.14.12 – Transfer reușit
Fig.14.13 – Formular tranzacții
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT IOAN SLAVICI [608311] (ID: 608311)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.