1

UNIVERSITATEA BABE-BOLYAI CLUJ-NAPOCA

FACULTATEA DE MATEMATIC I INFORMATIC

SPECIALIZAREA INFORMATIC ROMN






LUCRARE DE DIPLOM

E-mail i mesagerie multiplatform






Conductor tiinific
Lect. Dr. Cobrzan Claudiu Absolvent
Morovan Loredana-
Alina
2

Cuprins

Introducere .................................................................................................................................................. 4
Motivaia dezvoltrii acestei lucrri .......................................................................................................... 4
Structura lucrrii ....................................................................................................................................... 4
Capitolul 1: Cercetare n domeniu ............................................................................................................ 6
1.1 Cteva concepte de baz despre interaciunea om-calculator ....................................................... 6
1.1.1 Utilizatorii nceptori i utilizatorii experimentai ................................................................ 6
1.1.2 Adaptabilitate i adaptarea utilizatorului .............................................................................. 7
1.2 Sistemele de pot electronic i proiectarea ...................................................................................... 7
1.2.1 Funcionalitatea potei electronice ............................................................................................... 7
1.2.2 Istoricul potei electronice ........................................................................................................... 9
1.2.3 Proiectarea interfeei potei electronice .................................................................................... 10
1.2 Pota electronic i utilizatorii de calculatoare ........................................................................... 12
1.2.1 Adaptarea interfeei la utilizator.......................................................................................... 12
Capitolul 2: IMAP i alte tehnologii asociate ......................................................................................... 14
2.1 Concepte de baz .............................................................................................................................. 14
2.2 IMAP atribute specifice ................................................................................................................. 15
2.3 MIME ................................................................................................................................................ 16
2.3.1 Mesajul ca un container ............................................................................................................. 17
2.3.2 Caractere internaionale n mesaje ............................................................................................. 18
2.3.3 Susinerea MIME n IMAP ........................................................................................................ 18
2.4 Flow-ul protocolului IMAP .............................................................................................................. 19
2.4.1 Comenzi i rspunsuri ................................................................................................................ 21
2.4.2 Strile serverului IMAP ............................................................................................................. 24
2.4.3 Sincronizarea mailbox................................................................................................................ 25
2.4.4 Schimbri n mailbox ................................................................................................................. 26
2.4.5 Preluarea i manipularea mesajelor ............................................................................................ 27
2.4.6 Interogri asupra altor mailbox-uri ............................................................................................ 27
2.4.7 Cutare, sortate i threading ....................................................................................................... 28
3

2.4.8 Manipularea mailbox ................................................................................................................. 28
2.4.9 Terminarea sesiunii .................................................................................................................... 29
2.4.10 Extensii IMAP ......................................................................................................................... 29
2.5 Alte protocoale de accesare ale mesajelor stocate pe server ............................................................. 29
2.5.1 POP3 .......................................................................................................................................... 29
2.5.2 Webmail ..................................................................................................................................... 30
2.5.3 IMAP, POP3 sau Webmail ........................................................................................................ 31
Capitolul 3: Proiectarea aplicaiei Smart E-mail Client ................................................................... 33
3.1 Tehnologii utilizate ........................................................................................................................... 33
3.1.1 Arhitecturi i abloane de proiectare .......................................................................................... 33
3.1.1 Model-View-Controller ............................................................................................................. 33
3.1.2 Struts 2 ....................................................................................................................................... 34
3.1.3 Hibernate i BD .......................................................................................................................... 38
3.1.4 JavaMail API ............................................................................................................................. 50
Concluzii .................................................................................................................................................... 54
Referine i Bibliografie ............................................................................................................................ 55
Anex .......................................................................................................................................................... 57











4

Introducere

Motivaia dezvoltrii acestei lucrri

Deoarece pota electronic este des folosit de ctre majoritatea utilizatorilor de
calculator i joac un rol important n schimbul de informaii, am dorit s fac o lucrare despre
sistemul e-mail care poate fi folosit pe diferite platforme, i de a arta importana acesteia n
viaa oricrei persoane care intr n contact cu tehnologia. Pe lng interfaa tot mai
soficticat pe care o are un astfel de sistem, tehnologiile care stau la baz sunt cruciale n
funcionarea ct mai eficient a potei electronice. Aceasta ofer o mai mare securitate i
confidenialitate dect scrisorile obinuite cu care oamenii erau obinuii nainte de apariia
unei astfel de aplicaii bazat pe Internet.
Un sistem e-mail multiplatform ofer utilizatorilor o mai mare mobilitate n a trimite i
primi mesaje, dar i de a gestiona mesajele deja primite.

Structura lucrrii

Capitolul 1 reprezint o cercetare n domeniu pentru a afla cum este influenat viaa
utilizatorilor de pota electronic. Sunt prezentate cteva aspecte referitoare la utilizatorii
nceptori, dar i la cei experimentai, care sunt diferenele majore dintre acetia, cum se
adapteaz unui sistem e-mail i cum un sistem e-mail se adapteaz n funcie de tipul de
utilizator. Mai departe, capitolul 1 prezint un istoric pe scurt referitor la modul n care a evoluat
sistemul e-mail, dar i care sunt funcionalitile unui astfel de sistem i cum ar trebui s fie
proiectat astfel nct s satisfac nevoile utilizatorilor.

Capitolul 2 prezint modul de funcionare a unor protocoale care stau la baza unui sistem e-
mail bine definit. Fr aceste protocoale i standarde, nu poate fi dezvoltat o aplicaie web
bazat pe comunicarea ntre clieni prin intermediul potei electronice. Capitolul 2 pune n
lumin, de asemenea, care sunt diferenele majore dintre aceste protocoale i n ce contexte sunt
utilizate, care este scopul i funciile lor majore n funcionarea potei electronice.

5

Capitolul 3 prezint modul n care aplicaia Smart E-mail Client este proiectat i care
sunt tehnologiile importante care stau la baza dezvoltrii acesteia. Tehnologiile, abloanele de
lucru i instrumentele utilizate sunt descrise n detaliu i exemplificate pe baza aplicaiei
dezvoltate. Acestea sunt: Model-View-Controller, Struts 2, Hibernate, JavaMail.

ncheiera reprezint cteva scurte concluzii la care am ajuns n urma parcurgerii i finalizrii
studiului legat de aceast tem.
















6

Capitolul 1: Cercetare n domeniu


Exist o larg cercetare cu privire la e-mail (pota electronic), iar prile descrise aici
acoper numai cteva aspecte ale acestuia. Capitolul este divizat n mai multe seciuni care vor
cuprinde trsturi de baz legate despre interaciunea om-calculator, funcionaliti de baz ale
potei electronice i de asemenea vor fi date i cteva exemple de sisteme.
1.1 Cteva concepte de baz despre interaciunea om-calculator

1.1.1 Utilizatorii nceptori i utilizatorii experimentai

Exist, probabil, attea moduri de a utiliza pota electronic ci utilizatori ale acesteia
exist, i nu ar fi corespunztor s se vorbeasc despre utilizatorii potei electronice ca i cum ar
fi un grup omogen. Aadar, vor fi definite dou grupuri: nceptori i experimentai. Cele dou
categorii sunt doua extreme pe o scar continu unde utilizatorii care au n timp trec de la
nceptori la experimentai. Utilizatorii nceptori sunt cei care abia au nceput s nvee s
utilizeze pota electronic i nu cunosc dect puine comenzi, cele de baz. n schimb, cei
experimentai cunosc foarte bine comenzile i nu au nicio problem de nelegere. Cu timpul,
fiecare poate s devin experimentat, dar numai aceeia care i dezvolt cunotine de nelegere
ale task-urilor pot deveni experi.

Fig. 1.1.1.1
Fig. 1.1.1.1 nceptorii i experimentaii sunt dou valori extreme pe scara timpului n timp ce
naivii i experii sunt dou extreme pe scara cunotinelor. Colurile rotunde reprezint
imposibilitatea de a deveni un expert fr experien i de a rmne utilizator naiv cu mult
experien.
7

1.1.2 Adaptabilitate i adaptarea utilizatorului

Utilizatorul i sistemul pot s se adapteze unul celuilalt. Exist trei termeni legai de
adaptare care trebuie definii: adaptabilitatea pasiv, adaptarea pro-activ i adaptarea
utilizatorului.
Adaptabilitatea pasiv este atunci cnd programul este tolerabil-utilizator. Un exemplu ar
fi atunci cnd utilizatorul decide s utilizeze o interfa n englez sau n romn n aplicaia sa.
Adaptarea pro-activ este atunci cnd programul singur se adapteaz utilzatorului. De
exemplu, dac o persoan terge constant mesajele de la cineva fr s le deschid, programul e-
mail ar putea s ntrebe dac trebuie s tearg ntotdeuna mesajele de la persoana respectiv. O
astfel de adaptare este dificil, i trebuie implementat cu grij. Adaptarea poate fi administrat
de ctre ageni inteligeni care ajung la concluzii din modul n care utilizatorul manevreaz
mesajele i s ncerce presupuneri inteligente legate de cum vrea utilizatorul s aib mesajele
organizate, spre exemplu. Adaptatea utilizatorului este atunci cnd utilizatorul unui sistem i
adapteaz comportamentul sistemului. De exemplu, cnd o funcie de cutare n e-mail necesit
ca utilizatorul s specifice n ce folder s caute, utilizatorul s-ar putea adapta sistemului nu prin
folosirea folderelor cu scopul de a simplifica cutrile prin toate mesajele.

1.2 Sistemele de pot electronic i proiectarea

1.2.1 Funcionalitatea potei electronice

Pota electronica este un sistem de comunicare bazat pe calculator unde mesajele pot fi
scrise de ctre un exepeditor pe un calculator. Aceste mesaje sunt apoi transmise prin
calculatoare la adresa serverului de mail unde pot fi deschise i citite de ctre destinatar. Original
aceste mesaje puteau s conin doar text, dar n zilele noastre tot ce e stocabil pe un calculator
poate fi transmis prin mesajele potei electronice. Mesajele care conin alte informaii dect text
sunt considerate mesaje cu ataamente (attachments). Aceste ataamente sunt de obicei fiiere
create cu alte programe dect programul potei electronice. Exist sisteme e-mail care pot
manipula informaii cum sunt imagini, sunete i video fr asistena altor aplicaii.
8

Pota electronic se deosebete de alte servicii de comunicare, cum este chat sau talk,
prin caracterul su asincron. Asincronizarea se refer la posibilitile pe care le au expeditorul i
destinatarul unui mesaj de a trimite i de a citi mesajele n timpi diferii. Acest timp este divizat
n trei pri: timpul dintre crearea mesajului i timpul transmisiei (permind expeditorului s
modifice mesajul), timpul dintre transmisie i deschiderea mesajului de ctre expeditor, i nu n
ultimul rnd, timpul dintre deschiderea i raspunderea la mesaj.
Sistemul asincron necesit ca mesajele s fie stocate pe calculator. Dac numrul
mesajelor stocate devine mare, muli utilizatori prefer s grupeze aceste mesaje n dosare
(folders). n unele sisteme, dosarele pot conine i alte dosare. Un dosar poate fi numit, de
asemenea, director, catalog sau categorie. n majoritatea sistemelor de pot electronica doar
coninutul unui dosar este vizibil la un moment dat. Pentru a vizualiza coninutul altui dosar,
acest dosar trebuie manual selectat. Dosarul unde toate mesajele noi sunt primite se numete
inbox. Acest dosar i alte dosare sunt individuale: fiecare utilizator al potei electronice are
propriile dosare, iar mesajele nu pot fi citite, n mod normal, de ctre alii. Dosarul inbox este
singurul dosar vizibil atunci cnd utilizatorul pornete un sistem de pot electronic.
Mesajele potei electronice sunt compuse din dou pri: o list de antete (headers) i un
coninut (body). Coninutul este folosit pentru mesajul actual. Antetele sunt formate dintr-o
etichet (tag) i un cuprins (content) care definete, spre exemplu, ctre cine trebuie trimis
mesajul (antetul ctre, To:, ca etichet i adresa sau adresele ca i coninut), i subiectul
mesajului (antetul Subject). Cteva dintre aceste antete sunt obligatorii, dar majoritatea sunt
opionale. Acceptate pe scar larg n Internet sunt antetele definite n RFC 822, dar antetele noi
pot fi adaugate la fel ca antetele definite n RFC 1800.
Toate sistemele de pot electronica au funcionalitatea de a raspunde la mesaje prin
comanda reply, pentru mesajele care au fost primite. Aceast comand umple automat cmpul de
adres (cu adresa expeditorului a mesajului primit) i cmpul pentru subiectul mesajului ( cu
acelai subiect ca al mesajului primit). Des, cuprinsul subiectului este precedat de un Re:
pentru a identifica mesajul la o replic.
Cnd sunt adugate noi antete, vor fi instrumente (mail tools) care nu vor putea interpreta
aceste antete, dar n sistemul experimental de pot electronic aceastea vor fi utilizate pentru a
aduga noi funcionaliti. Antetele pot, de exemplu, s fie folosite pentru a confirma trimiterea
9

mesajului. Sunt sinteme care au posibilitatea confirmrii livrrii mesajelor, de exemplu: COM,
Memo i Lotus Notes.
Utilizatorii au nevoie de a stoca adresele altor utilizatori. Aceste adrese pot fi stocate n
cartea de adrese (address book), n scopul de a trimite acelai mesaj ctorva destinatari n acelai
timp prin folosirea a scurtturilor (short-cut) de nume.
Exist, n multe cazuri, o linie subire ntre sistemele de pot electronica i sistemele de
conferin informatic care, de asemenea, manipuleaz mesaje asincrone scrise. Diferena dintre
pota electronica i sistemul de conferin pur, este c mesajele potei electronice sunt
direcionate la adrese cu nume, n timp ce mesajele postate n sistemul de conferin pot fi citite
de toat lumea (oricine care are acces la conferin pe timpul perioadei n care mesajul este
postat). n listele de distribuie ale potei electronice, doar aceeia care sunt membrii ai listei la
timpul trimiterii mesajului vor primi o copie.
n zilele noastre, cteva sisteme de pot electronic au fost extinse la sisteme groupware
pentru colaborare care sunt integrate cu baze de date, procesoare de text, instrumente de desenat
i foi de calcul (spreadsheets). Groupware poate fi definit ca: program care a fost proiectat ca
s fie utilizat de mai mult dect o persoan.
1.2.2 Istoricul potei electronice

n anii trzii 1960, primul sistem de pot electronic a fcut posibil trimiterea de
mesaje de ctre utilizatori de pe acelai calculator. n 1970, multe calculatoare din SUA au
devenit conectate printr-o reea numit ARPAnet (Advanced Research Projects Agency). Pota
electronic a devenit curnd una dintre cele mai folosite aplicaii , iar definiii ale antetelor
obinuite au devenit necesare.
O sut de ani mai trziu, LAN (Local Area Network) au fcut posibil dezvoltarea de
sisteme de pot electronic pentru utilizarea prin LAN. Pe parcursul ultimului deceniu, LAN i
WAN (Wide Area Network) au fost conectate pentru a forma Internetul.
Dou viziuni ale evoluiei potei electronice au urmat: cea a utilizatorului i un punct de
vedere tehnic. Pliskin (1989) a dat descrierea avantajelor un vis minunat a devenit realitate;
pentru a fi accesibil zilnic i gratuit i problemelor potei electronice. Ea a reportat din propria
sa experien urmatoarele probleme ale potei electronice:

10

1. Dificuti n adresare
Cnd oamenii comunic sunt probleme dese cu gsirea adreselor.
2. Probleme de fiabilitate
Nu exist posibilitatea de a ti dac un mesaj a ajuns la destinaie sau nu, pn cnd
destinatarul nu rspunde.
3. Limitri ale mediului
Este imposibil s se trimit orice n afar de texte simple, i nu sunt posibiliti de a
trimite semnturi ( de exemplu ntr-un contract).
4. Probleme cu interfaa
Utilizatorii trebuie des s se recalifice atunci cnd csua potal este transferat la o alt
combinaie de calculatoare gazd i reea.
De cnd studiul lui Pliskin a fost fcut, a trecut mult timp, iar problemele pe care ea le-a
descris au fost rezolvate. Antetele sunt definite pentru a permite confirmarea recepionrii
mesajelor, dar funcionalitatea de a manipula acest lucru nc lipsete n majoritatea recepionrii
mesajelor. Mesajele cu alt cuprins dect textele simple sunt posibil de trimis n zilele noastre prin
MIME (Multipurpose Internet Mail Extensions) care definete modul n care cuprinsul mesajelor
trebuie interpretat.
1.2.3 Proiectarea interfeei potei electronice

nainte s se neleag discuiile despre interfa i proiectare, trebuie definii doi termeni:
feedback i manipulare direct.
Feedback-ul poate fi definit ca trimiterea napoi utilizatorului informaii despre ce aciune a
fost executat i ce rezultate s-au obinut. Feedback-ul este important aa nct utilizatorul tie
ce face calculatorul. Feedback-ul poate fi divizat n trei tipuri diferite unde informaia arat
urmatoarele lucruri:
1. Calculatorul a neles instruciunea utilizatorului.
2. Instruciunea a fost executat i cum.
3. Execuia ar putea s ia timp.
Un exemplu este adugarea unui ataament mesajului. Ar trebui s existe o diferen vizual
ntre un mesaj cu ataament i unul fr ataament.
11

Manipularea direct poate fi definit ca un stil de comunicare n care obiectele sunt
reprezentate pe ecranul calculatorului, i pot fi manipulat de ctre utlizator n mod analog ca i
cum utlizatorul ar manipula obiecte reale. O parte din succesul manipulrii directe a interfeelor
const n abilitatea acestora de a constrnge interaciunea utilizatorului cu aciuni care sunt
sintactic corecte i care corespund sarcinilor utilizatorului. Prin urmare, probabilitatea erorilor
descrete.
Sistemele de manipulare direct ar fi mai bune pentru utilizatori dect sistemele bazate pe
comand. Cteva motive ar fi urmtoarele:
1. Utilizatorii nceptori pot nva rapid, de obicei printr-o demostraie facut de un
utlizator mai experimentat.
2. Experii pot lucra extrem de rapid pentru a efectua o gam larg de activiti, chiar
definind noi funcii i caracteristici.
3. Mesajele de eroare sunt rareori necesare.
4. Utilizatorii pot s vad imediat dac aciunile lor i ndeplinesc scopul, i dac nu, ei pot
simplu s schimbe direcia activitii lor.
5. Utilizatorii au anxietatea redus, deoarece sistemul este uor de neles i aciunile sunt
uor reversibile.
Manipularea direct necesit aciune incremetal pe obiecte vizibile n interfa cu un
feedback rapid. Cnd se proiecteaz un sistem tradiional de manipulare direct textele
comenzilor sunt nlocuite cu aciuni pentru a manipula obiecte vizibile direct. Majoritatea
aciunilor ar trebui s fie reversibile, fiecare aciune a utilizatorului ar trebui s fie o operaie
legal i s nu rezulte ntr-un mesaj de eroare.
Un exemplu este mutarea unui mesaj dintr-un dosar ntr-altul i fixarea lui. Mesajul i
folderul sunt obiecte vizibile (reprezentate prin iconie). Cnd mesajul este selectat, interfaa
transmite un feedback, de exemplu prin schimbarea cursorului la iconia mesajului. Pe parcursul
mutrii de la poziia original la dosarul nou, inconia mesajului este vizibil pe ecran i mutat
rapid n pai mruni. Dac utilizatorul se rzgndete este posibil mutarea inconiei mesajului
napoi la poziia original. Dac mutarea este complet ctre noul dosar, inconia dosarului
rspunde n cteva moduri (de exemplu nghiind iconia mesajului).


12

1.2 Pota electronic i utilizatorii de calculatoare

Aceast seciune raporteaz cteva diferene n uitilizarea calculatorului ntre utilizatorii
nceptori i cei experimentai. Utilizarea potei electronice s-a rspndit de la grupuri omogene
de utilizatori orientai tehnic la locuri de munc, n general. Iniial, pota electronic a fost
folosit cel mai des la locul de munc, de ctre angajaii care au avut calculator. Mai trziu,
posibilitile de comunicare pe care le-a adus calculatorul i accesul la pota electronic au
reprezentat un motiv de a introduce calculatoarele la locul de munc. Astzi, accesul la pota
electronic a devenit comun n locuinele oamenilor. Aceast dezvoltare va include noi grupuri
de utilizatori n comunitatea potei electronice, n rndul utilizatorilor nceptori de calculator.
1.2.1 Adaptarea interfeei la utilizator

Este important s se fac potrivire ntre interfa, abilitile i experiena utilizatorului. A
fost fcut un studiu n anul 1991, unde 32 de utilizatori experimentai au fost pui fa n fa cu
dou interfee care ndeplineau aceeai sarcin. O interfa a fost fcut pentru nceptori
folosindu-se meniuri de dialog, culori, valori implicite, mesaje lungi de eroare, i un transfer
automat la funcia de ajutor cnd apreau erorile. Cealalt interfa a fost fcut pentru utilizatori
experimentai, cu dialog de comand, fr culori, cu mesaje de eroare foarte scurte, fr valori
implicite, i cu o funcie de ajutor care poate fi activat manual i care conine mesaje de ajutor
scurte.
Jumtate dintre utilizatorii experimentai au efectuat simularea cu o interfa pentru
nceptori, i cealalt jumtate cu interfaa pentru experi. Utilizatorii nceptori au fost divizai
n acelai fel. Experimentul a dat performane semnificativ mai bune n ceea ce privete rata de
eroare i profit atunci cand interfeele au fost potrivite cu experiena utilizatorului. Utilizatorii
experimentai s-au descurcat mai bine cu interfaa proiectat pentru cei experi, comparativ cu
interfaa pentru nceptori. Analog a fost n cazul utilizatorilor nceptori. Nicio diferen
semnificativ nu a fost gsit raportat la timpul de rspuns.
Divizarea n utilizatori nceptori i experimentai este static i nu se va potrivi acelora
care sunt n traziie de la un grup la cellalt. n loc de adaptarea doar utilizatorului la interfa,
este posibil, de asemenea, adaptarea interfeei la utilizator. Versiunea adaptat iniial a fost ca i
cea pentru utilizatorii nceptori, dar cnd un utlizator a ndeplinit o sarcin fr erori, interfaa s-
a schimbat ntr-o versiune intermediar, iar dup o alt perioad fr erori, n versiunea pentru
13

cei experimentai. n concluzie, interfeele care se adapteaz ar putea reduce timpul de
antrenament i pot s produc o performan n cretere.





























14

Capitolul 2: IMAP i alte tehnologii asociate

Pota electronic (e-mail), sau SMTP-mail (Simple Mail Transfer Protocol), este un
serviciu public potrivit pentru schimbul automat de mesaje ntre entiti conectate.
Interoperabilitatea este garantat prin cteva standarde ale Internetului, de obicei codificate sub
forma documentelor RFC. Diferite protocoale specific regulile de comunicare dintre entiti, la
fel i definiia formatului tututor mesajelor transmise. n aceast seciune, se prezint numeroase
strandarde care au de a face cu acest nalt subiect de discuie.
2.1 Concepte de baz

Un mesaj e-mail, sau un mesaj RFC-822, este compus din trei pri: Envelope, Header i
Body. Envelope este singura parte relevant pentru schimbul de mesaje ntre gazdele de
Internet; include informaii de baz cum sunt adresele expeditorului i destinatarului. Header-ul
ofer mai mult metadata detaliat despre mesaj, de la adresa expeditorului i ruta mesajului la
cmpurile definite pentru utilizator. Cteva pri din aceste informaii sunt folosite cnd
trimiterea mesajului electronic eueaz din diferite motive, cum este header-ul de Return-Path.
Header-ul servete, de asemenea, ca i baz pentru IMAP envelope data. n final, un message
body este ceea la ce un utilizator tipic se refer ca fiind propriu-zis e-mail-ul. Ar putea s conin
doar un simplu text US-ASCII, un mesaj HTML cu imagini ncorporate , sau ar putea fi o entitate
definit recursiv cu o structur rich tree.
Un server IMAP este o gazd n Internet care ofer acces la depozitul local de mesaje e-
mail prin intermediul unui protocol standard, IMAP4rev1 n acest caz. Serverul IMAP ar putea fi
localizat n centrul de date al unui angajat sau n calculatorul unui utilizator, de exemplu.
Un server MTA (Mail Transfer Agent) sau SMTP este o gazd Internet a crei scop este
de a livra mail-ul RFC 2822. MTA-urile n Internet comunic ntre ele, determinnd rutarea
informailor de la MX-records n DNS (Domain Name System). MX-record (Mail eXchange
record) este o nregistrare n DNS care specific responsabilitile serverelor pentru acceptarea
tuturor mesajelor e-mail care sosesc pentru un domeniu particular. Ca o comun practic n zilele
noastre , aceste servere accept, de asemenea, mesaje e-mail trimise de ctre proprii utilizatori,
cu condiia ca autentificarea sa fie facut corespunztor, fie prin simplul fapt c provine de la o
reea de ncredere sau de la un utilizator acreditat.
15

Mailbox sau Mail Folder este un loc pe serverul IMAP unde mesajele sunt logic stocate.
Mailbox-ul ar putea conine un numr de child mailboxes dac implementarea serverului permite
acest lucru.
2.2 IMAP atribute specifice

Un mesaj n sensul IMAP este invariabil, coninutul (header, body etc) su neputnd fi
modificat. Fiecare mesaj are, de asemenea, atribute variabile, cele mai importante fiind flag-
urile.
Mesajele, ntr-un mailbox izolat, sunt identificare prin intermediul a dou numere parial
independente, sequence number (numr de ordine) i UID (User ID). Numerele de ordine ncep
de la 1 i sunt consecutive, asta nsemnnd c se schimb dinamic cnd un mesaj este ters din
mijlocul mailbox-ului, de exemplu. Asta nseamn c un mesaj poate avea mai multe numere de
ordine asignate de-a lungul timpului, i c un numr de ordine poate referi mesaje fr nici o
legtur, pe parcurs ce numerotarea se schimb.
Pe de alt parte, UID lucreaz diferit. Cnd un mesaj este livrat n mailbox, primete un
UID cu 1 mai mare dect cel de dinainte. Dup ce UID este asignat, nu se va schimba niciodat
pentru un mesaj particular, i mailbox-ul amintete cel mai mare UID asignat pn la momentul
respectiv. Asta nseamn c UID-urile nu sunt niciodat reciclate i pot fi utilizate ca
identificatori persisteni pentru mesajele din mailbox.
Cteodat, situaii nestandard se pot ntmpla, de exemplu, cnd a treia parte ncearc s
acceseze datele din mailbox din spatele serverului IMAP. n astfel de cazuri, garania naturii
invariabile a mesajelor nu mai este valabil, iar un server compatibil IMAP trebuie s comunice
problema tuturor clienilor. Atributul UIDVALIDITY al mailbox-ului servete acestui scop. Chiar
i in cazul n care UIDVALIDITY se schimb, un client compatibil este necesar pentru a arunca
orice informaie cache legat de mailbox, pentru c asignarea UID ncepe din nou.
UID i UIDVALIDITY combinate mpreun formeaz un ntreg pe 64 de bii care este un
absolut unic identificator pentru orice mesaj ntr-un mailbox dac n cazul n care un client a
recuperat vreodat o parte invariabil dintr-un mailbox cu acest identificator pe 64 de bii,
interogri ulterioare pentru partea identificat prin acelai numr pe 64 de bii n acelai mailbox
pot fi satisfcute de cache-ul clientului.
16

Trebuie precizat c numerotarea UID/UIDNEXT este strict pentru mailbox i nu pentru
server, i dac diferii utilizatori acceseaz acelai server, s-ar putea s vad acelai numr pe 64
de bii pentru un mesaj total fr nici o legatur. n timp ce RFC 3501 recomand ca
UIDVALIDITY s fie constant pe ct posibil, un client IMAP compatibil are de a face cu
schimbrile UIDVALIDITY, cu toate acestea.
IMAP envelope este o structur de date care reine valori determinate, cel mai adesea din
diverse message headers (antetele mesajelor). Nu este acelai lucru ca SMTP envelope, care de
obicei stocheaz mai puin informaie.
Internal date reine o marc de timp despre cnd a fost livrat mesajul la serverul IMAP.
Atributul size este numrul de octei necesar pentru stocarea unei copii ntregi n format RFC
2822. Body structure reprezint structura tree-like al mesajului MIME.
IMAP flags este un atribut care reine o mulime de zero sau mai multe token-uri asociate
mesajului. Un flag poate fi permanent sau de sesiune. Flag-urile permanente sunt stocate n
mailbox-ul propriu-zis, n timp ce flag-urile de sesiune dispar la o reconectare ulterioar la
mailbox. Unele dintre flag-uri sunt definite de ctre standardul RFC 3501, altele sunt adugate de
ctre diferite recomandri i extensii standard. Un server IMAP ar putea permite clienilor IMAP
s stocheze propriile flag-uri de mesaje.
n final, coninutul mesajului propriu-zis este distribuit n forma mesajelor text. Clienii
sunt liberi s aleag de la preluarea separat a prilor de mesaj MIME sau totul ca un ntreg.
2.3 MIME

Multipurpose Internet Mail Extentions, sau simplu zis MIME, este o mulime de
standarde pentru extinderea vechiului SMTP mail de la texte ASCII pe 7 bii la coninut bogat
multimedia. Pri din aceste standarde au de a face cu ncapsularea caracterelor non-ASCII n
header-ele mesajelor, la fel de bine ca i furnizarea instruciunilor despre cum trebuie
ncorporate datele non-textuale n mesajele e-mail.





17

Antete RFC 822 adugate de MIME:

Tipuri i subtipuri MIME definite n RFC 2045

2.3.1 Mesajul ca un container

Un aspect important al MIME este introducerea structurii interne n body-ul mesajelor e-
mail. Anterior, body era un text simplu, iar odat cu codificarea acestui standard, a devenit
posibil schimbarea de mai multe informaii structurate. Utilizatorii contemporani sunt, probabil,
familiarizai cu e-mail-urile HTML care conin imagini incorporate i ataamente PDF pentru
imprimare fr sudur. Utilizatorii trimit n mod obinuit e-mail-uri cu fotografii ataate din
vacane, sau o arhiv care conine documente legate de business.
Standardele MIME ating acest lucru prin definirea unui content type pentru body-urile
mesajelor. Acest content type, de obicei setat de ctre un header RFC 2822 al unui mesaj,
18

determin n ce mod un client compatibil expune mesajul. Vechile tipuri de mail-uri non-MIME
au un tip text/plain implicit MIME, un text pe 7 bii US-ASCII neformatat.
Alt fragment din standard definete containere cu scop generic, tipuri de coninut
abstracte care conin alte pri de mesaje. Multe dintre aceste containere sunt definite n RFC
2045 si 2046, unul fiind adugat n RFC 2387.
Codarea multipart/alternative ofer o semnificaie transmiterii unui mesaj care este
primat n cteva diferite formri, dar fiecare dintre ele coninnd aceleai date. MUA (Mail User
Agent) alege una dintre prile subliniate i le afiseaz, probabil permind utilizatorului s
suprascrie ceea ce e subliniat.
Multipart/mixed este un tip MIME generic catch-all pentru mesaje multipart. Dac un
MUA compatibil vede un tip de coninut multipart pe care nu l poate recunoate, ar trebui s se
comporte ca i cum ar fi mixed multipart. O aciune tipic este dispunerea tuturor prilor
ncorporate una lnga cealalt.
2.3.2 Caractere internaionale n mesaje

Mail-ul original SMTP definit de RFC 822 este potrivit doar pentru transferul de date pe
7 bii. n zilele noastre, canalele de transport pe 8 bii sunt mult mai comune pentru reprezentarea
caracterelor internaionale i pentru transferul binar de date. Prin urmare, MIME definete
transfer encodings pentru conversia de date binare generice pe 8 bii ntr-un stream de caractere
pe 7 bii i un mod portabil de a exprima caracterele naionale folosind doar caractere ASCII pe 7
bii.
Dou codri standard sunt valabile, Quoted printable i Base64, cel din urm fiind
susinut de o abordare similar, cum este cea definite in RFC 2047.
2.3.3 Susinerea MIME n IMAP

O mare parte din lucrul care implic susinerea MIME poate fi efectuat de ctre serverul
IMAP. Acest fapt este n special adevrat pentru parsarea structurii mesajelor, unde specificrile
IMAP prevd moduri de a explora tree-ul mesajului, la fel de bine ca i metodele pentru
recuperarea parilor din coninutul mesajului care rezult separate (chiar incluznd serii de octei
pentru descrcare mai uoar).
Cu toate acestea, protocolul IMAP nu trateaz restul susinerii MIME, sau alte parsri de
headere. n timp ce e normal s se interogheze serverul pentru un subset de headere RFC 2822,
19

datele returnate nu sunt pre-parsate n orice mod. Aadar, o mare parte din munca contopirii a
ctorva pri din headere pentru a decoda caractere internaionale este lsat ca un exerciiu
clientului.
Din fericire, diverse atribute ale mesajelor n protocolul IMAP pot s serveasc ca un
substitut pentru parsarea header-elor RFC 2822.
2.4 Flow-ul protocolului IMAP

Dup conectarea cu succes la un server IMAP, clientul ar putea alege s se autentifice
dac serverul nu a fcut acest lucru deja cu un cont de utilizator particular. Dup aceasta sau n
caz c autentificarea nu e necesar, conexiunea intr n starea authenticated. n aceast faz,
niciun mailbox nu este selectat i doar un subset de comenzi este valid. Clienii pot, de exemplu,
s cear listarea arborelui de la mailbox, s obin informaii despre numrul mesajelor dintr-un
mailbox particular sau altfel s gestioneze mailbox-urile ca un ntreg. Ei trebuie, totui, s
selecteze mailbox-ul pentru a putea face orice altceva, cum ar fi preluarea mesajelor sau pentru a
le marca ca fiind citite.
Mailbox-ul poate fi accesat ca read-only sau pentru citire i scriere, cu condiia ca
utilizatorul autentificat s aib suficiente privilegii. Preluareaa de mesaje se poate face n dou
moduri, dar opeariile de scriere (cum sunt stocarea unui mesaj nou n mailbox sau manipularea
flag-urilor mesajului) necesit acces read-write.
Urmtoarea diagram, cea din figura Fig. 3.4.1, ilustreaz modul n care serverul IMAP
manipuleaz mesajele venite la serverul SMTP:
20


Fig.2.4.1 Flow-ul IMAP

1- Mesajul ajunge la serverul SMTP
2- Serverul SMTP livreaz toate mesajele care sunt destinate pentru un utilizator local,
la serverul IMAP
3- Clienii IMAP se conecteaza la serverul IMAP pe portul IMAP 143 i i acceseaz
mesajele folosind protocolul IMAP
4- Serverul IMAP folosete utiliti asincrone SFS la interfaa cu depozitul de mesaje
(stocheaz i obine mesaje, creaz i terge dosare, etc.)
5- Administratorii autorizai utilizeaz IMAPADM EXEC pentru a emite comenzi
administrative la serverul IMAP. Comenzile sunt trimise ntr-o coad CMS. Serverul
IMAP primete comanda, o proceseaz, i apoi rspunde napoi pe coada de
administrator.
21

2.4.1 Comenzi i rspunsuri

IMAP este un protocol de text line-oriented. Orice serverul trimite la clientul su se
numete rspuns (response), n timp toate datele care circul n partea opus sunt cunoscute ca
fiind comenzi (commands). Fiecare comand generate de ctre client ncepe cu un identificator
unic numit tag care este urmat de identificatorul actual al comenzii. Majoritatea comenzilor
accept de asemenea (sau necesit) un parametru (parameter) care ar putea fi un string literal, un
numr, un atom, o list de alte tipuri, etc. Transmisia de string-uri necesit o confirmare explicit
de la server numai dac extensia LITERAL+ este ativ. Suportul pentru aceast extensie este
crucial pentru o performan bun, iar dac ar fi absent, majoritatea comenzilor ar fi ntrziate.
Clienii sunt liberi s emit cteva comenzi, fr s atepte executarea acestora. Fiecare
comand, de obicei, conduce la rspunsul unui server, tagged reply. Acest rspuns conine
acelai tag ca i cel trimis de client n comanda original, permind clientului s i dea seama
dac comanda a fost executat cu succes sau nu. Unele comenzi pot duce la trimiterea de
rspunsuri viitoare numite rspunsuri neetichetate (untagged replies). Un detaliu important al
protocolului este ca aceste rspunsuri neetichetate sunt premise s apar n aproape orice
moment pe parcusul conversaiei i nu numai ca un rezultat al unei comenzi. Un client
compatibil trebuie sa fie pregtit pentru acest gen de situaie i s ii fac fa correct, deoarece nu
exist nicio diferen ntre raspunsurile generate unilateral si cele solicitate (requested
replies).
Fiecare rspuns etichetat indic o completare a unei comenzi particulare. Dac comanda
este executat cu succes, un status OK este primit, iar dac nu a fost executat cu succes, serverul
returneaza NO. n cazul n care serverul nu nelege intenia clientului, returneaz rspunsul cu
statusul BAD. Un control mai bun asupra rezultatelor este realizat prin intermediul codurilor de
rspuns (response codes), care sunt entiti textuale cu un neles strict definit. Exemple de
asemenea coduri de rspuns sunt mailbox opened in read-only mode, specied character set
no supported sau please show this error message to the user.





22

Comenzile protocolului IMAP:
LOGIN permite folosirea idetificatorilor de utilizator i parol n procesul de
nregistrare a clienilor noi. Referitor la serverul IMAP, nu este cea mai buna metod, dar uneori
este singura cale de a se face conexiune la server.
AUTHENTICATE permite clientului s foloseasc metode alternative de verificare a
datelor personale n procesul de nregistrare/autentificare pe serverul IMAP. Verificarea
individual a datelor personale nu este obligatorie i nu este suportat de toate serverele IMAP.
Mai ales executarea acestei metode difer n funcie de versiunea serverului. Cnd se execut
comanda AUTHENTICATE, serverul rspunde n cod n baza 64. Mai departe clientul trebuie s
trimit raspuns la cererea legat de verificarea datelor personale, tot n cod n baza 64. Dac
serverul nu suport metoda de validare propus de client, el va rspunde la orice comand prin
NO. Dup aceea, clientul trebuie sa continue comunicarea pentru verificarea autentificrii.
Dac toate ncercrile de a se autentifica au auat, clientul ncearc s se nregistreze la server
prin comanda LOGIN.
CLOSE nchide cutia potal. Cnd cutia ptal este nchis, toate mesajele marcate cu
\DELETE sunt terse. Aceast comand nu are parametrii.
LOGOUT termin sesiunea pentru utilizatorul actual, nchide toate cutiile potale
deschise. Dac sunt mesaje marcate cu flag-ul \deleted, cu ajutorul acesteo comenzi ele vor fi
automat terse din cutia potal.
CREATE creaz o cutie potala nou. Numele i locul lor se stabilesc conform
specificaiilor serverului.
DELETE se folosete la cutii potale. La primirea acestei comenzi, serverul IMAP
terge cutia potal cu numele dat ca parametru. Mesajele sunt terse i ele din cutia potal
respectiv.
RENAME redenumete numele cutiei potale. Are doi parametrii: numele care trebuie
schimbat, i numele nou.
SUBSCRIBE - adaug o cutie potal n lista celor active. Are numai un parametru:
numele cutiei potale care trebuie adugat n list, dar care nu trebuie neaprat s existe.
UNSUBSCRIBE terge cutia potal din lista celor active. Are aceeasi parametrii ca i
SUBSCRIBE.
LIST returneaz lista cu toate csuele potale ale clientului. Are doi parametrii.
23

LSUB fa de comanda LIST, LSUB se folosete pentru accesarea liste cu cutii potale
activate prin comanda SUBSCRIBE. Parametrii sunt la fel ca la LIST.
STATUS formeaz cerero legate de starea curent a cutiei potale. Primul parametru
este numele cutiei potale, al doilea este lista cu criterii cu ajutorul crora clientul vrea s obin
informaia necesar. Comanda STATUS poate fi folosit pentru obinerea informaiei despre
starea cutiei potale fr executarea comenzilor SELECT i EXAMINE.
Clientul poate s obin informaia dup criteriile:
MESSAGES numrul total de mesaje din cutia potal;
RECENT numrul de mesaje cu flag-ul \recent;
UIDNEXT identificator ID, care va fi dat la un nou mesaj;
UIDVALIDITY identificator unic pentru cutia potal;
UNSEEN numrul de mesaje fr flag-ul \seen.
APPEND adaug un mesaj n captul listei unei anumite cutii potale. Ca argumente
are numele cutiei potale, flag-ul mesajului (care nu e obligatoriu), titlul i coninutul mesajului.
Are anumite flag-uri:
\seen citit;
\answered pentru rspuns;
\flagged important;
\deleted pentru tergere;
\draft pentru ciorn;
\recent pentru mesaj nou, poate fi utilizat numai dup terminarea sesiunii.
CHECK pune checkpoint n mailbox. Orice operaie, de exemplu scrierea datelor din
memoria serverului pe hardDisk, trebuie executat conforma strii cutiei potale. Pentru
verificarea funcionrii cutiei potale dup operaiile de scriere sau altele, se folosete comanda
CHECK. Nua are parametrii.
EXPUNGE terge din cutia potal toate mesajele marcate cu flag-ul \deleted, dar cutia
potal nu se nchide. Rspunsul la aceast comand este sb forma unui raport despre starea nou
a cutiei potale.
SEARCH cutarea mesajlor bazate pe criterii n cutia potal activ, cu un rspuns
detaliat. Cutarea mesajelor se face dup anumite cuvinte, dup data primirii sau dup flag-uri.
24

FETCH trimite coninutul mesajului. Comanda se folosete numai pentru afiarea
mesajelor. Fa de POP3, clientul IMAP nu salveaz copiile mesajelor pe PC-ul.
STORE stocheaz informaia despre mesaj.
COPY copiaz mesajul dintr-o cutie potal n alta.
UID se folosete legat cu comenzile FETCH, COPY, STORE, SEARCH. Cu ajutorul
ei, comezile precedente pot folosi ID n loc de enumerarea simpl.
CAPABILITY cerere de la client despre informaiile i posibilitile serverului IMAP.
NOOP aceast comand nu face nimic. Poate fi folost ca suport n timpul sesiunii. Cu
ajutorul ei nu se inchide sesiunea n limita timpului. Rspunsul serverului la comanda NOOP
ntotdeauna trebuie sa fie pozitiv.
2.4.2 Strile serverului IMAP

Serverul IMAP se afl n una dintre cele patru stri: fr autentificare, cu autentificare, de
alegere (Choose) i de ieire (Exit). Majoritatea comenzilor pot fi folosite n anumite stri. n
starea fr autentificare clientul trebuie s i introduc numele de utilizator i parola pentru a
accesa majoritatea comenzilor. Trecerea n starea de funionare se face pe baza conexiunii fr
autentificare.
n starea de autentificare clientul trebuie identificat. n plus, el este obligat s aleag o
csu potal (mailbox), dup ce are acces la mesajele din pota electronic. Trecerea n aceast
stare se face prin stabilirea conexiunii urmat de autentificare. Dup aceea, clientul va avea acces
la date sau mesaje de erori legate de csua sa potal.
n starea de alegere Choose sistemul ajunge numai dup o autentificare reuit i dup
ce a fost aleas cu succes cutia potal.
25

n starea de "ieire" sistemul ajunge prin nchiderea conexiunii de ctre client sau ca o
urmare a unei soluii independente a serverului.
Fig. 2.4.2.1 Strile serverului IMAP

Explicarea figurii Fig. 2.4.2.1:
1- Conexiune fr pre-autentificare.
2- Conexiune cu pre-autentificare.
3- Conexiune respins.
4- Finalizare cu succes a comenzii LOGIN sau AUTHENTICATE.
5- Finalizarea cu succes a comenzii SELECT sau EXAMINE.
6- Executarea comenzii CLOSE sau euarea comenzii SELECT sau EXAMINE.
7- Executarea comenzii LOGOUT, nchiderea serverului sau ntreruperea conexiunii.
2.4.3 Sincronizarea mailbox

Din motive eficiente, fiecare client, de obicei, reine cteva date in cache-ul su
persistent. Buni candidai pentru cache sunt mesajele text, o copie a strusturii coninutului
mesajului, sau posibil chiar i flag-urile din sesiunea anterioar. Deoarece cteva rspunsuri ale
serverului, i anume EXPUNGE, care informeaz clientul dac mesajul a fost ters din csua
potal, se refer la mesaje doar prin numrul de ordine i clienii de obicei identific mesajele
26

prin UID, un client compatibil trebuie s rein maparea UID la numrul de ordine. Fcnd n
acest fel doar pentru o parte vizibil n interfa a mailbox-ului poate prea tentant, dar riscurile
implicate sunt majore si, de obicei, depesc posibilele salvri iniiale.
Un server IMAP care se conformeaz n totalitate la RFC 3501 este necesar s trimit
cteva rspunsuri sub form de status-uri cnd un mailbox este selectat. Domenii de interes
pentru sincronizarea mailbox-ului sunt actualizri pe UIDVALIDITY, UIDNEXT i EXISTS.
Dup primirea tuturor celor trei, clientul are destule infotmaii ca s decid ce aciuni sunt
necesare ca s aduc mailbox-ul napoi la o stare complet sincronizat. Clienii au doar de a face
cu attribute variabile ale mesajului, i anume, numrul de ordine, numrul UID i flag-urile
mesajului.
Dac valoarea UIDVALIDITY s-a schimbat, clientul ar trebui s nlture orice date din
cache-ul local care se refer la mailbox. Unele UID e posibil s se fi schimbat sau pri din
mesajl s-au modificat. Aceasta situaie este n acest caz identic cu forma de sicronizare a strii
iniiale n care clientul nu are nici o cunotin despre mailbox-ul destinaie.
n cele ce urmeaz. Se presupune c valoarea UIDVALIDITY este aceeai ca i n
sincronizarea anterioar. Dac valoarea UIDNEXT nu s-a schimbat, niciun mesaj nu a fost trimis
la mailbox de la ultima oar. Dac numrul EXISTS s-a schinbat, cteva mesaje au fost terse
permanent. n cazul n care UIDNEXT s-a schimbat (poate doar s creasc deoarece numerele
UID sunt scrict cresctoare) iar UID este acelai ca EXISTS, nseamn c noi mesaje au fost
primite, dar nici unul nu a fost ters i clientul trebuie s cear UID-ul noilor mesaje (i flag-urile
pentru toate msajele din mailbox). Dac incrementarea UIDNEXT i EXISTS difer, o rezerv a
abordrii generice sincronizate, unde clientul preia UID-urile de la toate mesajele din mailbox,
este necesar. De asemenea este rezonabil s se transfere flag-urile ca i parte din acest pas.
Dac nu exist nicio informaie cache sau a aprut o modificare UIDVALIDITY, clienii
preiau o mapare complet UID i flag-urile mesajelor.
Dup executarea acestor pai i primirea unor rspunsuri relevante, clientul este pe deplin
ntr-o stare sincronizat i gata s primeasc actualizri ale mailbox-ului.
2.4.4 Schimbri n mailbox

Originalul IMAP RFC specific c toi clienii trebuie s fie pregtii pentru primirea
actualizrilor legate de numrul de mesaje coninute, tergerea celor vechi i trimiterea celor noi,
27

dar n ciuda lipsei de support din partea clienilor la timpul respectiv, aceast caracteristic a fost
foarte puin utilizat. n schimb, comanda NOOP a fost utilizat la scar larg ca o verificare
polling check a noilor mesaje. Cu toate aceastea, a avut toate dezavantajele unei abordri polling-
based, n special creterea inutil a traficului n reea, trimiterea ntrziat a mesajelor mail etc. O
soluie la aceast problem este prezentat n RFC 2177, unde clientul acceseaz un mod special
pentru a preciza serverului c poate trimite n timp real notificri clientului.
Schimbarea numrului de mesaje n mailbox este comunicat n principal prin dou tipuri
de rspunsuri neetichetate, EXISTS i EXPUNGE. Rspunsul EXPUNGE conine un numr de
ordine al mesajului care a fost permanent ters din mailbox i cauzeaz imediat decrementarea cu
o unitate a celorlalte numere de ordine ale mesajelor care au avut numrul de ordine mai mare
dect mesajul ters. Acest fapt nseamn c clienii trebuie s lucreze cu numere de ordine, altfel
se pregtesc s i actualizeze UID la fiecare tergere, acest proces putnd fi destul de costisitor.
Rspunsul EXISTS este folosit pentru a informa clientul c un mesaj a fost livrat, sau ar putea
urma EXPUNGE pentru a oferi informaii redundante clienilor, despre numrul de mesaje
stocate. Sub nicio circumstan ar putea fi utilizat pentru a descrete numrul de mesaje in
mailbox-ul current, dar acest lucru este deja fcut de ctre EXPUNGE.
2.4.5 Preluarea i manipularea mesajelor

Odat selectate, mesajele din mailbox pot fi accesate i descrcate de ctre client.
Comanda FETCH servete la obinerea datelor din structura coninutlui (body) i din IMAP
envelope ale prilor mesajelor actuale. Flag-urile mesajelor sunt actualizate de comanda STORE
i variantele acesteia. Mesajele existente pot fi copiate n alte mailbox-uri cu comanda COPY, iar
noile mesaje pot fi stocate ntr-un folder mail utiliznd comanda APPEND.
2.4.6 Interogri asupra altor mailbox-uri

Deoarece grafica MUA dorete s afieze utilizatorului mai mult de un mailbox n acelai
timp, cel puin ntr-o fereastr unde s se gaseasc mesajele noi sau necitite, IMAP pune la
dispoziie o comand pentru determinarea strii a altor mailbox-uri dect cel selectat, comanda
STATUS. Folosind aceast comand ,pentru interogarea strii a mailbox-ului current selectat, este
explicit interzis de ctre RFC. Un motiv pentru interzicerea folosirii comenzii STATUS pe
mailbox-ul curent este acela c n anumite implementri ale serverului, aceast operaie ar putea
28

cauza un proces care s deschid mailbox-ul nc o dat, ceea ce duce la producerea de rezultate
inconsistente i s deruteze clientul.
2.4.7 Cutare, sortate i threading

Chiar i specificaia de baz al protocolului IMAP ofer faciliti pentru cutarea
mesajelor n mailbox-ul curent. Majoritatea clienilor nu au nevoie de toate coninuturile
mesajelor i de headerele preluate i disponibile n scopul de a permite utilizatorilor s caute prin
mesaje. Cu toate acestea, cutarea i sortarea nu este valabil n cazul n care clienii nu sunt
conectai sau autentificai. Acetia trebuie sa-i implementeze propriul cod pentru un aa scop,
sau s dezactiveze aceste operaii cnd accesul n reea este nepermis.
Urmtoarele revizuiri specific cu siguran extensii legate de internaionalizarea
traficului e-mail. De exemplu, cutnd caractere non-ASCII n mesaje ar putea fi foarte dificil
folosind doar comanda SEARCH, deoarece fiecare mesaj din mailbox poate fi stocat sub forma
uneia dintre codificrile disponibile n standardul MIME. Revizuirile anterioare pentru IMAP
definite, prin urmare, suport cutarea unificat printer mesajele care au fost primite n seturi de
caractere diferite.
2.4.8 Manipularea mailbox

Conform unor motive istorice (n special versiunea veche al protocolului SMTP pe 7 bii),
IMAP nu folosete nicio codare standard pentru numele mailbox-urilor. n schimb, o versiune
modificat a UTF-7 sau simplu numit modified UTF-7 este mandatat. Standardul nu specific
ce decizii s se ia n cazul n care cealalt parte folosete date pe 8 bii n numele mailbox-ului,
dar cele mai multe implementri n zilele noastre recurg la UTF-8, care este, fr ndoial, un
lucru bun de fcut.
Mailbox-urile pot fi create, terse sau redenumite de ctre clienii IMAP. Dac serverul
permite, pot s formeze o ierarhie sub form de arbore. Unele servere fac diferena ntre
mailbox-uri pentru stocarea mesajelor i cele care conin doar alte mailbox-uri, n timp ce alte
implementri permit combinarea celor dou. Din pcate, nu exista un mod sigur de a specifica n
ce clas se incadreaz serverul destinaie, dar prevederi sunt date despre cum s se creeze un
folder pentru mesaje i cum s se creeze unul pentru mailbox-uri. Dac mailbox-urile formeaz
un arbore, implementarea serverului specific ce caracter este folosit pentru delimitarea ierarhiei.
Cele mai multe alegeri n acest scop sunt punctul (.) care este comun n rndul serverelor care
29

export foldere Maildir, i slash (/) pentru exportarea tradiionalului mbox UNIX. Aceast
inconsisten ar putea duce la derutarea utilizatorului, dar nu poate fi evitat fr a anula
compatibilitatea invers.
2.4.9 Terminarea sesiunii

Sesiunea IMAP se termin atunci cnd serverul trimite clientului un rspuns neetichetat
BYE. Aceast aciune poate fi produs de ctre cererea clientului prin comanda LOGOUT sau
printr-un timer de auto-delogare din partea serverului. Implementrile serverului sunt necesare s
permit cel puin 30 de minute de inactivitate naintea trimiterii acestui rspuns.
2.4.10 Extensii IMAP

Protocolul IMAP permite extinderea de nou funcionaliti. Extensiile pot aduga
comenzi noi, coduri de rspuns i chiar schimbri ale aspectelor de baz ale protocolului.
Suportul pentru aceste extensii este strict voluntary, i fiecare entitate compatibil a protocolului
IMAP trebuie s funcioneze corespunztor.
2.5 Alte protocoale de accesare ale mesajelor stocate pe server

IMAP nu este singurul protocol pentru accesarea mesajelor stocate pe un server izolat. n
aceast seciune vor fi prezentate cteva dintre alternativele existente i se va discuta avantajele
i dezavantajele acestora n comparaie cu IMAP.
2.5.1 POP3

Diferena major ntre IMAP i POP3 (Post Office Protocol version 3) este folosofia
acestora. IMAP a fost proiectat pentru scenario unde utilizatorul i las e-mail-urile ntr-un loc
central care are un rspuns autoritar legat de ce mesaje trebuie s fie acolo, n timp ce POP3
ateapt ca utilizatorii s descarce toate mesajele pe un calculator unde clientul POP3 ruleaz i
apoi terge permanent mesajul original de pe server. La fiecare reconectare, clientul POP3
descarc i terge toate mesajele noi din nou. Aceast diferen fundamental duce la problem
cnd utilizatorul dorete s foloseasc POP3 n situaii pentru care nu a fost proiectat un
exemplu clasic este accesarea mailbox-ului din dou locuri n acelai timp, cum ar fi de pe
calculatorul de la locul de munc sau de acas.

30


Avantajele sistemului POP3:
Mesajele sunt afiate foarte repede dup ce sunt descarcate de pe server;
Dup ce sunt descrcate mesajele se gasesc pe calculatorul personal. Pe majoritatea
serverelor spaiul este limitat, deoarece mesajele sunt descrcate pe calculator spaiul
pentru mesaje este limitat doar de hard-disk-ul propriu, nu este limitat de spaiu existent
pe server;
Este un sistem care se regsete pe majoritatea serverelor de pe Internet;
Toate programele de email suport acest protocol.
Dezavantajele sistemului POP3:
Trebuie folosit un program pentru a descrca mesajele de pe server;
Mesajele sunt stocate pe calculatorul propriu i nu sunt accesibile de la alte calculatoare;
Mesajele trimise si mesajele n curs de scriere nu sunt accesibile de la alte calculatoare;
Mesajele sunt terse de pe server i dac exist o problem cu calcualtorul este posibil sa
se piard mesajele;
Mesajele sunt stocate n fisiere care nu sunt compatibile cu toi clienii de email, daca se
dorete s se schimbe clientul de e-mail poate fi dificil s se recupereze mesajele
anterioare;
Este destul de dificil de copiat e-mail-urile pe un alt calculator (calculatorul de la birou,
de acasa, de la scoala, laptop, etc.)
Utilizatorii, de obicei, nu ii fac back-up la e-mail-uri, iar cnd se stric ceva la calculator
sunt anse mari s se piard e-mail-urile.
2.5.2 Webmail

Webmail-ul este folosit, la fel ca i protocolul IMAP, pentru a verifica mesajele de pe
server, fr a le descarca pe calculatorul gazd.
Cu civa ani n urm, multe servicii online de la companii cunoscute cum este Google sau
portale regionale de Internet i-au crescut popularitatea. n ciuda limitrilor inerente ale
interfeei utilizator bazat pe web, majoritatea e-mail-urilor sunt accesate i gzduite prin
interfaa webmail. Dei, cu greu aceste servicii ofer o garanie cu privire la disponibilitatea
sau efectuarea de back-up-uri, utilizatorii obinuii nu sunt preocupai de aceste aspect.
31

Fiabilitatea acestor servicii este, pe de alt parte, de obicei mai mare dect a unui PC de
acas.
Avantajele webmail:
Mesajele sunt inute pe server i sunt accesibile de la orice calculator de oriunde din
lume;
Mesajele care sunt verificate pe webmail rmn sincronizate cu un eventual calculator;
Mesajele trimise i cele n curs de scriere sunt inute pe server;
Filtrarea spamurilor se face pe server;
De obicei se face back-up-ul automat al mesajelor de ctre administratorul serverului;
Este uor s schimbi clientul de e-mail sau calculatorul;
Daca se schimb calculatorul este foarte usor s se recupereze e-mail-urile, nu este
necesar nici mcar copierea fiierelor ntre calculatoare;
Pentru a accesa e-mail-ul nu trebuie deca-t un browser, nu trebuie un program special
pentru asta.
Dezavantajele webmail:
Mesajele se incarc mai ncet;
De obicei pe server exist un spaiu limitat, iar pentru a nu ocupa acest spaiu rapid, o
tergere a mesajelor este necesar;
Mesajele nu pot fi vizualizate cnd calculatorul nu este conectat la Internet.
2.5.3 IMAP, POP3 sau Webmail

IMAP este folosit atunci cnd este nevoie de acces la e-mail-uri de oriunde i n orice
moment. Chiar dac calculatorul personal nu este la ndemana, de la un alt calculator se pot
vedea e-mail-urile trimise/primite de la calculatorul de acas. IMAP necesit un spaiu mare pe
server deoarece mesaje rmn pe server, n momentul n care spatial este limitat atunci POP este
recomandat. Protocolul IMAP necesit un program care s cunoasc acest protocol i setarea
acestuia s acceseze serverul respectiv. Mesajele descrcate prin IMAP sunt disponibile (doar
mesajele care au fost deschise) unui utilizator care nu este conectat la Internet.
POP este folosit pentru utilizatorii care folosesc un singur calculator pentru a verifica e-
mail-ul sau pentru utilizatorii care nu au pe server un spaiu mare. Protocolul POP3 necesit un
32

program care s cunoasc acest protocol i setarea acestuia s acceseze serverul respectiv. Dup
ce mesajele sunt descrcate pe calculator ele sunt disponibile i fr o conexiune la Internet.
Webmail este folosit de utilizatorii pentru care e-mail-urile sunt doar o metod de a
comunica cu prietenii i pentru care mesajele nu sunt foarte importante. Dac nu au acces la
mesaje nu este mare problem. Este singura metod de a accesa e-mail-ul de la orice calculator
conectat la Internet i configurarea este minim. Tot ce trebuie de tiut este un nume de utilizator
i o parol.
















33

Capitolul 3: Proiectarea aplicaiei Smart E-mail Client

n acest subcapitol sunt prezentate tehnologiile care stau la baza aplicaiei Smart E-mail
Client ct i modul n care este proiectat i arhitecturat. Aplicaia despe care se discut n
acest capitol a fost implementat folosind limbajul de programare Java i tehnologiile asociate
acestui limbaj. Smart E-mail Client folosete servicii Web care sunt proiectate pentru a oferi
suport la interanciunea calculatorului cu reeaua de Internet. Platforma Java EE ofer API-uri
Java pentru serviciile web XML folosite pentru comunicarea clienilor printr-un protocol bazat
XML.
3.1 Tehnologii utilizate
3.1.1 Arhitecturi i abloane de proiectare

Framework vs. pattern
Un framework este un set integrat de componente care colaboreaz pentru a oferi o arhitectur
reutilizabil pentru o familie de aplicaii. Framework-urile sunt aplicaii semi-complete.
Aplicaiile complete sunt dezvoltate prin motenirea sau instanierea componentelor unui
framework parametrizat.
Un patern suport reutilizarea arhitecturii software. Reprezint soluiile la problemele dezvoltrii
unei aplicaii ntr-un anumit context.
Aadar, modul n care aplicaia este arhitecturat se numete pattern, iar ceea ce ajut la
urmarea unui pattern se numeste framework.
3.1.1 Model-View-Controller

Aplicaia Smart E-mail Client este construit folosind ablonul de proiectare Model-
View-Controller.
Model-View-Controller (MVC) este un ablon de proiectare (design pattern) folosit de
multe aplicaii web i nu numai. Ideea principal din spatele arhitecturii MVC este de a separa
funcionalitatea modelului de reprezentarea datelor i de logica controlului. Aceast separare
permite dezvoltatorilor s ofere multiple vizualizri asupra acelorai date pentru clieni diferii i
mbuntete ntreinerea aplicaiei. Cu toate acestea, ablonul MVC crete complexitatea
34

proiectrii aplicaiei. Modelul reprezint datele aplicaiei i metode corespunztoare de business
pentru accesarea i modificarea datelor. n aplicaiile Java EE, componentele EJB sunt des
folosite pentru e reprezenta modelul i modelele de business. View-ul este responsabil pentru
prezentarea datelor din model utilizatorului. Tehnologiile Java Server Pages (JSP) sau Java
Server Faces (JSF) pot fi folosite n acest scop. Controller-ul proceseaz interaciunile
utilizatorului cu view-ul i le interpreteaz ca aciuni specifice efectuate de model. n aplicaiile
web, interaciunile utilizatorului sunt cereri HTTP care duc la schimbri n starea modelului sau
la invocarea metodelor din model. Bazat pe rezultatele aciunilor efectuate, controller-ul
selecteaz un view adecvat pentru afiare. Controllerul este reprezentat, de obicei, de un servlet
sau de un filtru. n figura Fig.3.1.1.1 este repezentat Schema dup care funoneaz MVC.

Fig.3.1.1.1 Diagrama MVC
3.1.2 Struts 2

Struts 2 este un framework open-source care ajut la construirea aplicaiilor web ntr-un mod
rapid i uor. Se bazeaz pe tehnologii standard cum sunt Java beans, Java servlets, Java Server
Pages (JSP) i XML. Piesa de centru a Struts este MVC, care se integreaz cu alte tehnologii care
ofer model i view.
Model 1 i Model 2 sunt arhitecturi care se difereniaz prin coninut i prin generaiei, de la
logica business la coninut de prezentare prin format HTML. Model 2 difer de Model 1 prin
locaia unde cererea este procesat: de un controller (Model 1) sau de pagini JSP (Model 2).
35

n arhitectura din Model 1, pagina JSP proceseaz singur cererile primite i rspunde clientului,
as cum este prezentat n figura Fig.3.1.2.1

Fig.3.1.2.1 Model 1
1. Browser-ul trimite cererea ctre servlet.
2. Servletul instaniaz un Java bean care este conectat la baza de date.
3. Servletul comunic cu o pagin JSP.
4. Pagina JSP comunic cu Java bean.
5. Pagina JPS rspunde browser-ului.

Implementarea Model 2 de ctre Struts folosete tipuri specifice de servleturi, numite action
servlet, i una sau mai multe aciuni i mapri de pentru a implementa controller-ul. De
asemenea, folosete tipuri specifice Java Bean, numite form bean. Aa cum este ilustrat n figura
Fig.3.1.2.2, serverul Web la timpul rulrii conine componentele view i controller, n timp ce al
treilea nivel (care este de obicei n afara serverului Web) conine modelul.
36


Fig.3.1.2.2 Model 2
Flow-ul Struts2:
1. Request: Clientul face o cerere.
2. Filter Dispatcher: acesta reprezint controller-ul i este prima component care intr n
joc n ciclul de procesare a cererii. La baz este un servlet filter. Funcia sa principal este
de a inspecta fiecare cerere primit i de a determina care aciune ar trebui executat n
funcie de cerere.
3. Action Mapper: aceast clas este utilizat de FilterDispatcher pentru a determina dac
cererea ar trebui s invoce o aciune sau nu. ActionMapping este clasa care reine
informaiile despre maprile aciunilor folosite pentru a invoca o aciune Struts.
4. ActionProxy: dac ActionMapper determin c o aciune trebuie s fie invocat pentru o
respectiv cerere, FilterDispatcher trimite controlul ctre ActionProxy. ActionProxy
consult ConfigurationManager i apoi creaz un ActionInvocation.
5. ConfigurationManager: aceasta este reprezentarea obiectului Java pentru fiierul
struts.xml care este ncrcat la nceperea aplicaiei i conine toate informaiile referitoare
la configurarea framework-ului. Interfaa ConfigurationProvider descrie configurarea
framewoek-ului. Implicit, framewrok-ul ii ncarc propria configurare prin intermediul
unui document xml folosind StrutsXmlConfigurationProvider.
37

6. Struts.xml: acesta este fiierul de configurri ce conine mapri definite pentru fiecare
aciune, interceptori, rezultate, etc. n contextul aplicaiei Smart E-mail Client, acest
fiier are forma urmtoare, cea prezentat n figura Fig.3.1.2.3. Fiecare aciune este
mapat la clasa Java corespunztoare. Dac metoda din interiorul clasei nu este
specificat pentru a fi executat, atunci se va executa metoda implicit execute() a
aciunii. Aceast metod va returna un cod definit: Succes sau Error. n funcie de aceste
rezultate, utilizatorul va fi redirecionat ctre pagini sau alte aciuni diferite. Aciunile
sunt definite n interiorul tag-ului <action>, iar rezultatele aciunii ntre tag-urile
<result>.

Fig.3.1.2.3 Struts.xml
7. ActionInvocation: odat ce aciunea returneaz un rezultat, ActionInvocation este
responsabil pentru gsirea rezultatelor asociate cu codul rezultat (Succes sau Error) al
aciunii ce este mapat in Struts.xml.
38

8. Interceptor: interceptorii sunt invocai dup i inainte ca o aciune s fie executat, i
permit ca anumite sarcini s fie executate fr probleme i s fie transformate n
componente reutilizabile.
9. Action: modelul MVC este implementat de ctre componenta action. O aciune este o
incapsulare de apeluri la logica business ntr-o singur unitate de lucru.
10. Result: rezultatele trasnlateaz starea aplicaiei ntr-o reprezentare vizual cu care
utilizatorul poate interaciona. Aciunea este responsabil pentru alegera rezultatului care
va rspunde la o anumit cerere. Un tip de rezultat este JSP sau altele.
11. Template: este pagina de vizualizare care red de fapt rspunsul la utilizator.
12. ObjectFactory: este unul dintre cele mai importante clase din framework. Toate
obiectele create sunt instaiate cu ObjectFactory.
Aadar, Struts 2 folosete mecanismul de tag. Aceast caracteristic promoveaz rutilizarea
codului i abstractizeaz codul Java din fiierele JSP. Permite integrarea n instrumentele de
dezvoltare JSP. Struts 2, este, de fapt, un framework aplicat peste tag-urile de JSP.
3.1.3 Hibernate i BD

Hibernate este o librrie ORM (object-relational mapping) pentru limbajul Java, oferind
un schelet pentru maparea obiectului din model la o baz de date relaional. Este puternic, de o
performan ridicat n persistena obiectelor relaionale i n serviciul de interogri pentru orice
aplicaie Java.
Hibernate mapeaz clasele Java din model la tabelele din baza de date. Hibernate st ntre
obictele tradiionale i serverul de baze de date pentru a manipula toat munca n persistena
acelor obiecte bazate pe un mecanism adecvat O/R i pattern-uri.

Fig. 3.1.3.1 Hibernate
39

Avantajele Hibernate:
Hibernate are grij de maparea claselor la tabele corespunztoare din baza de date
folosind fiiere XML i fr scriere de cod.
Ofer API-uri simple pentru stocarea i obinerea obictelor direct ctre i de la baza
de date.
Dac este vreo schimbare n baza de date sau n orice table, atunci este nevoie doar de
schimbarea proprietilor din fiierul XML.
Abstractizeaz tipurile nefamiliare SQL i ofer un lucru n jurul obiectelor Java.
Hibernate nu necesit un server de aplicaii ca s opereze.
Manipuleaz asociaii complexe ale obicetelor din baza de date.
Minimalizeaz accesul la baza de date.
Ofer interogri simple de date.
Arhitectura Hibernate:
Arhitectura Hibernate este stratificat, i nu este nevoie s se cunoasc API-urile care stau la
baz. Hibernate face folosirea bazei de date i a configurrii de date s ofere servicii persistente
(i obiecte persistente) aplicaiei.
Figura Fig.3.1.3.2 este o perspectiv la nivel nalt a arhitecturii aplicaiei Hibernate.




Fig. 3.1.3.2 Arhitectura
Hibernate




40

Figura Fig. 3.1.3.3 este o perspectiv mai detaliat privind arhitectura unei aplicaii
Hibernate, cu cteva clase importante.
Hibernate utilizeaz o varietate de API-uri Java existente, Java Transaction API (JTA), Java
Naming and Directory Interface (JNDI). JDBC ofer un nivel de abstractizare a
funcionalitilor obinuite la bazele de date relaionale, permind acceptarea de ctre
Hibernate a oricrei baze de date cu JDBC. JNDI i JTA permit ca Hibernate s fie integrat
cu serverele de aplicaie J2EE.






Fig. 3.1.3.3 Stratificare
Hibernate






Urmtoarea seciune red o descriere a fiecrei clase de obiecte implicat n
arhitectura aplicaiei Hibernate.
Configuration Object:
Configuration Object este primul obiect Hibernate care se creaz n orice aplicaie
Hibernate i, de obicei, este creat o singur dat pe parcursul iniializrii aplicaiei.
Reprezint o configuraie sau proprieti de fiier necesare. Configuration object ofer dou
componente cheie:
Database Connection: aceasta este manipulat prin intermediul uneia sau mai multor
fiiere de configurri suportate de ctre Hibernate. Aceste fiiere sunt
hibernate.properties i hibernate.cfg.xml.
41

Class Mapping Setup
Aceast component creaz conexiunea ntre clasele Java si tabelele din baza de date.
SessionFactory Object:
Configuration Object este folosit pentru a crea un obiect SessionFactory care
configureaz Hibernate pentru aplicaie folosind fiierul de configurare furnizat i permite ca
un Session object s fie instaniat. SessionFactory este un obiect thread safe i este folosit de
ctre fierele de execuie unei aplicaii. Este creat pe parcursul pornirii aplicaiei i este pstrat
pentru a fo folosit mai trziu. Este necesar un obiect SessionFactory per baz de date,
folosindu-se un fiier separat pentru configurare. Aadar, dac se utilizeaz baze de date
multiple, atunci se vor crea obiecte multiple SessionFactory.
Session Object:
O sesiune este utilizat pentru a crea o conexiune fizic cu o baz de date. Session
object este proiectat pentru a fi instaniat de fiecare dat cnd o interaciune cu o baz de date
este necesar. Obiectele persistente sunt salvate i obinute prin Session object.
Obiectele de sesiune nu ar trebui inute deschise pentru o perioad lung de timp,
deoarece nu sunt thread safe i ar trebui create i distruse doar la nevoie.
Transaction Object:
O tranzacie reprezint o unitate de lucru cu baza de date, iar majoritatea RDBMS
suport funcionalitatea tranzaciei. Tranzaciile sunt gestionate de un manager de tranzacii
care st la baz i tranzacii (din JDBC sau JTA).
Acesta este un obiect opional iar aplicaiile Hibernate pot s aleag s nu foloseasc
aceast interfa ci administrnd tranzaciile n propriul lor cod din aplicaiei.
Criteria Object:
Obiectele Criteria sunt utilizate pentru a crea i executa interogri criteria orientate
obiect pentru a obine obiecte.
Instalarea Hibernate:
Dup instalarea ultimei versiuni a fiierului de instalare, trebuie s se execute civa
pai simpli. Setarea variabilei CLASSPATH trebuie fcut corespunztor, altfel vor exista
probleme la compilarea aplicaiei.
Se copiaz toate fiierele cu librrii din /lib n CLASSPATH, i se schimb variabila classpath
pentru a include toate JAR-urile;
42

La final se copiaz fiierul hibernate3.jar n CLASSPATH; acest fiier se gsete n
directorul rdcin al instalrii i este JAR-ul principal de care Hibernate are nevoie pentru a
funciona.
Configurarea Hibernate:
Hibernate necesit cunoaterea n avans legat de unde s gseasc informaia de
mapare care definete cum sunt legate clasele Java de tabelele din baza de date
corespunztoare. De asemenea, mai necesit un set de setri de configurare asociate bazei de
date i altor parametrii. Toat aceast informaie este furnizat ca un fiier de proprieti Java
standard numit hibernate.properties,, sau ca un fiier XML numit hibernate.cfg.xml.
n aplicaia dezvoltat Smart E-mail Client este folositfiierul formatat
hibernate.cfg.xml pentru a specifica proprietile necesare Hibernate. Majoritatea
proprietilor au valori implicite i nu este necesar specificarea lor n fiierul de proprieti,
numai dac trebuie. Acest fiier este pstrat n directorul rdcin \src.
Proprietile Hibernate:
Urmtoarea list conine cele mai importante propriti necesare pentru configurarea
bazei de date:
1. hibernate.dialect aceast proprietate genereaz face ca Hibernate s
genereze SQL corespunztor pentru baza de date aleas.
2. hibernate.connection.drive_class clasa driver JDBC.
3. hibernate.connection.url URL JDBC pentru instana bazei de date.
4. hibernate.connection.username numele utilizatorului bazei de date.
5. hibernate.connection.password parola bazei de date.
6. hibernate.connection.pool_size limiteaz numrul conexiunilor.
Hibernate cu baza de date MySQL:
MySQL este una dintre cele mai populare baze de date open-source disponibil n
ziua de azi.
n imaginea Fig.3.1.3.4 se gsete fiierul aplicaiei Smart E-mail Client
hibernate.cfg.xml i configurrile don acesta, ce conine proprietile menionate n lista de
mai sus, plasat n directorul \src. Baza de date ctre care se face conexiunea trebuie s fie
creat i populat cu tabele, i trebuie s existe un nume de utilizator i parol.
43


Fig.3.1.3.4 hibernate.cfg.xml
Configurarea prezentat conine tag-urile <mapping> care sunt asociate fiierelor
hibernate-mapping, despre care se va discuta n rumatoarele subseciuni.
Hibernate Sessions:
O sesiunea este folosit pentru a se face o conexiune fizic cu baza de date. Obiectele de
sesiune nu ar trebui pstrate pentru mult timp, pentru c nu sunt thread safe. Funcia principal a
sesiunii este de a oferi, de exemplu, operaii de creare, citire i scriere a claselor entitilor
mapate. Instanele pot exista n una dintre cele trei stri:
transient o nou instan a clasei persistente, care nu este asociat cu o sesiune i nu
are o reprezentare n baza de date i nici o valoare idenificator, este considerat trazitorie
de ctre Hibernate.
44

persistent se poate face o instan tranzitorie prin asociera ei cu o sesiune; o instan
persistenta are o reprezentare n baza de date, o valoare identificator i este asociat cu o
sesiune.
detached o dat ce s-a nchis sesiunea Hibernate, instana persistent va deveni o
instan detaat.
O instan de sesiune este serializabil dac clasele ei persistente sunt serializabile. Un
exemplu de tranzacie din aplicaia Smart E-mail Client arat n felul urmtor, ca n figura
Fig.3.1.3.5, unde se gasete codul metodei de inserare a unui utilizator n baza de date .
Dac sesiunea arunc o excepie, tranzacia trebuie anulat (roll back) i sesiunea trebuie
descrcat.
Fig.3.1.3.5 tranzacie Hibernate

Clasele persistente Hibernate:
ntregul concept Hibernate este de a lua valorile din atributele claselor Java i de a le persista
ntr-un tabel din baza de date. Un document de mapare ajut Hibernate cum s extrag valori din
clase i s le mapeze la un tabel i la cmpurile asociate din acesta. Clasele Java a cror obiecte
sau instane vor fi stocate n tabelele din baza de date, sunt numite clase persistente n Hibernate.
Hibernate lucreaz cel mai bine dac aceste clase urmeaz cteva reguli simple, cunoscute ca
45

model de programare POJO (Plain Old Java Object). Exist cteva reguli principale ale claselor
persistente, dar cu toate acestea, nici una dintre aceste reguli nu sunt cerine obligatorii.
Toate clasele Java care vor persista au nevoie de un constructor implicit.
Toate clasele ar trebui s conin un ID pentru a permite identificarea mai uoar a
obiectelor n Hibernate i baza de date; aceast proprietate mapeaz la coloana care
conine cheia primar a tabelei din baza de date.
Toate atributele care vor fi persistate trebuie declarate folosind modificatorul de acces
private, i trebuie s aib metode get i set definite n stilul JavaBean.
Caracteristic central Hibernate, proxie-urile, depind de clasele persistente care sunt
non-finale, sau de implementatea unei interfee care declar toate metodele publice.
Toate clasele care nu motenesc sau implementeaza clase specializate sau interfee
recomandate de EJB.
Numele POJO este folosit pentru a evidenia dac un obiect dat este un obiect Java, i nu un
obiect special i n particulat nu un Enterprise JavaBean.
Un exemplu POJO este dat n exemplul din figura Fig.3.1.3.6, care este o clas din aplicaia
Smart E-mail Client. Bazat pe cteva reguli menionate mai sus se poate defini clasa
UserDO care este o clas POJO, dup cum urmeaz:

46

Fig.3.1.3.6 clasa model UserDO
47

Fiierele de mapare Hibernate:
Maparea unui obiect relaional este, de obicei, definit ntr-un document XML. Acest
fiier instruiete Hibernate cum s mapeze clasele definite la tabelele din baza de date.
Majoritatea utilizatorilor aleg s scrie fiierul XML manual, dar exist multe instrumente de
generare a fiierului de mapare. Clasa prezentat n figura Fig.3.1.3.6, definit ca i clas POJO
ale crei obiecte vor persista n tabelele definite n figura Fig.3.1.3.8. Va exista un tabel
corespunztor pentru fiecare obiect pentru care se dorete persisten. Obiectul va fi stocat i
obinut dup aceea n i din tabela RDBMS, prezentat n figura Fig.3.1.3.7.














Fig.3.1.3.7 Tabela BD

48















Fig.3.1.3. Fiier de mapare Hibernate

Documentul de mapare va fi salvat ntr-un fiier cu formatul <classname>.hbm.xml, n
cazul de fa user.hbm.xml. Cteva detalii despre maparea elementelor folosite n fiierul de
mapare:
Documentul de mapare este un document XML care are <hibernate-mapping> ca
element rdcin, ce conine toate elementele <class>.
Elementele <class> sunt utilizate pnetru a defini mapri specifice din clasele Java ctre
tabelele din baza de date. Numele clasei Java e specificat folosind atributul name al
clasei element, iar numele tabelului din baza de date este specificat folosind atributul
table.
49

Elementul <meta> este opional i poate fi folosit pentru a crea descrierea clasei.
Elemetul <id> mapeaz atributul unic ID din clas la cheia primar din tabela din baza de
date. Atributul name al elementului id se refer la proprietatea din clas, iar atributul
column se refer la coloana din tabela din baza de date. Atributul type reine tipul de
mapare Hinernate, aceste tipuri de mapare vor fi convertite din tipurile de date SQL.
Elemetul <generator> cu care elementul id este folosit pentru a genera valoarea cheii
primare.
Elementul <property> este utilizat pentru a mapa proprietatea clasei Java la coloana din
tabela din baza de date. Atributul name al elementului se refer la proprietatea din clas,
iar atributul column se refer la coloana din tabela din baza de date. Atributul type reine
tipul de mapare Hinernate, aceste tipuri de mapare vor fi convertite din tipurile de date
SQL.
Interogrile Hibernate Criteria:
Hibernate ofer moduri alternative de manipulare a obiectelor i ntoarce date disponibile n
tabelele RDBMS. Una dintre metode este Criteria API care permite construirea unui obiect
Criteria unde se pot aplica reguli de filtrare i condiii logice. Interfaa Hibernate Session ofer
metoda createCriteria() care este utilizat pentru crearea unui obiect Criteria care returneaz o
instan a clasei persistente atunci cnd aplicaia execut interogarea Criteria.
Restricii cu Criteria:
Se poate folosi metoda add() valabil pentru obiectul Criteria pentru a aduga restricii
interogrilor. Urmtorul exemplu, cel din figura Fig. 3.1.3.9, reprezint modul n care Criteria i
restriciile sunt folosite.




Fig.3.1.3.9
Tranzacie cu
restricii

50

3.1.4 JavaMail API

Tehnologia cea mai important care este folosit la baza proiectrii aplicaiei Smart E-
mail Client este J avaMail API.
JavaMail este un API folosit pentru a compune, scrie i citi mesaje electronice. Ofer un
framework protocol-independent i platform-independent pentru trimiterea i primirea de mesaje.
Pachetele javax.mail i javax.mail.activation conin clasele JavaMail API. Facilitatea JavaMail
poate fi aplicat asupra multo evenimente. Poate fi folosit la momentul nregistrrii
ultilizatorului (trimind diferite notificri), pentru parola uitat, trimind notificri pentru
actualizri importante. Aadar pot fi multiple ntrebuinri ale JavaMail API.
JavaMail este proiectat pentru a face mai uoar adugarea capabilitii potei electronice
la o aplicaie, n timp ce suport crearea de interfee utilizator foarte sofisticate. Include clase
adecvate care ncapsuleaz funcii i protocoale de mail obinuite. Este compatibil cu ale pachete
pentru platforma Java, cu scopul de a facilita utilizarea sa cu alte API-uri Java, i folosete
modele familiare de programare. JavaMail API este proiectat, prin urmare, pentru a satisface
diferite cerine de dezvoltare i de rulare.
JavaMail ofer elemente care sunt folosite pentru a construi o interfa ctre un sistem de
mesagerie, incluznd componente de sistem i interfee. Include cteva clase care implementeaz
RFC 822 i standardele mesageriei MIME. Aceste clase sunt livrate ca i parte din pachetul de
clase JavaMail.
Componentele arhitecturale ale JavaMail sunt stratificate dup cum urmeaz, i sunt
prezentate n figura Fig.3.1.4.1 :
Abstract Layer declar clase, interfee i metode abstracte cu intenia de a
suporta manipularea funciilor de mail pe care toate sistemele de mail le suport.
Elementele API care cuprind Abstract Layer sunt extinse cu scopul de a suporta
tipuri de date standard.
Implementation layer implementeaz o parte din abstract layer folosind
standarde internet, RFC 822 i MIME.
JavaMail folosete JavaBeans Activation Framework (JAF) cu scopul de a
ncapsula datele despre mesaj, i de a manipula comenzi intenionate s
interacioneze cu aceste date. Interaciunea cu datele despre mesaj ar trebui s
51

aib loc prin intremediul JAF-Aware JavaBeans, care nu sunt oferite de
JavaMail API.
Proiectarea arhitecturii stratificate
permite clienilor s foloseasc aceleai
apeluri JavaMail API pentru a trimite,
primi sau stoca o varietate de mesaje
utliznd diferite tipuri de date de la diferite
stocri de mesaje, i utiliznd diferite
protocoale de transport ale mesajelor.




Fig.3.1.4.1 Arhitectura JavaMail

Ierarhia de clase JavaMail:
Figura Fig.3.1.4.2 ilustreaz clasele majore i interfeele din JavaMail API.
Fig.3.1.4.2 Clase JavaMail
52

Clasa Message este o clas abstract care definete un set de atribute i un coninut
pentru mesaj. Atributele clasei Message specific informaii de adresare i definesc structura
coninutului, incluznd tipul coninutului. Implementeaz interfaa Part care definete atribute
necesare pentru a defini i formata datele coninutului din obiectul Message. Clasa Message are
atributele From, To, i altele necesare pentru rutarea mesajului prin sistemul de stransport.
JavaMail API suport obiectele Message multipart, unde fiecare Bodypart i definete propriul
su set de atribute i coninut.
Stocarea mesajelor i obinerea mesajele sunt stocate n obiecte Folder. Un obiect
Folder poate conine subfoldere la fel de bine ca mesaje, acestea oferind o ierarhie tree-like.
Clasa Store definete o baza de date care reine ierarhia folder mpreun cu mesajele sale. De
asemenea, specific protocolul de accea care acceseaz dosarele i obine mesajele din ele. Ofer
metode de stabilire a conexiunii cu baza de date.
Compunerea mesajelor i transportul un client creeaz un mesaj nou prin instanierea
unei sublase adecvate Message. Mesajele sunt trimise prin invocarea metodei Transport.send.
Clasa Transport modeleaz agentul de transport care ruteaz mesajul catre adresa destinaie.
Clasa Session definete proprieti globale care definesc la rndul lor interfaa dintre un
client de mail i reea. Componentele din sistemul JavaMail folosesc obiectul Session pentru a
seta i a primi proprieti specifice. Clasa Session ofer, de asemenea, un obiect de sesiune
autentificat implicit pe care aplicaiile desktop pot s le partajeze.
Figur Fig.3.1.4.3 ilustreaz procesul de manipulare JavaMail al mesajelor.
Fig.3.1.4.3 Procesul de manipulare al mesajelor
53

JavaMail este destinat s ndeplineasc umtoarele funcii care cuprind procesul de
manipulare standard pentru o aplicaie client tipic. Creeaz un messaj coninnd o colecie de
atribute antet i un bloc de date care au tipul de dat specificat n cmpul antetului Content-
Type. JavaMail folosete interfaa Part i clasa Message pentru a medini mesajul. Creeaz un
obiect Session, care autentific utilizatorul i controleaz accesul la stocarea mesajului i la
transport. Trimite mesajul la lista destinatarului. Obine mesajul de unde este stocat. Execut o
comand de nivel nalt pentru obinerea mesajului, cum este view sau print care sunt destinate s
fie implementate prin JAF-Aware JavaBeans.























54

Concluzii

Pota electronic sau e-mail este unul dintre cele mai importante instrumente de
comunicare n toate domeniile, ncepnd de la locul de munc, pan la uzul personal. Viitorul
potei electronice este promitor, deoarece este un sistem indispesabil comunicrii, iar
caracterul su asincron l face s se diferenieze de alte mijloace de comunicare. Se va ncerca o
dezvoltare ct mai avansat pentru a asigura o securitate maxim, deoarece, chiar dac n prezent
sistemele de pot electronic sunt destul de sigure, la un moment dat, tot se gsete o
vulnerabilitate care poate fi atacat. Deoarece contactul cu utilizatorul este foarte important,
interfaa joac un rol bine definit i de multe ori aceasta atrage cel mai mult, mai ales utilizatorii
neexperimentai.
n concluzie, pota electronic este nc un mediu tnr de comunicare, iar ntrebarea
legat de ct de mult va evolua acest sistem, cum se va schimba pe viitor i cum va influena
interaciunea i comunicarea n rndul oamenilor, rmne n minile cercettorilor,
proiectanilor, dezvoltatorilor i nu n ultimul rnd, n minile utilizatorilor.
















55

Referine i Bibliografie

Capitolul 1
- http://www.supermemo.com/articles/e-mail.htm
- Borenstein N. & Freed N. (1992): MIME-Mechanisms for Specifying and Describing the
Format of Internet Message Bodies;
- Blter O. (1995): Electronic mail from a user perspective: Problems and remedies;
- Blter O. (1997b): Strategies for organising email messages;
- Dimbleby R. & Burton G. (1995): More than words. An introduction to communication;
- Dix A., Finlay J., Abowd G. & Beale R. (1993): Human-Computer Interaction;
- Dumais S. T. & Landauer T. K. (1983): Using examples to describe categories;
- Fisher J. (1991): Dening the novice user;
- Grudin J. (1988): Why CSCW applications fail: problems in the design and evaluation of
organisational interfaces;
- Hjalmarsson A., Oestreicher L. & Wrn Y.: Human Factors in Electronic Mail System
Design;
- Jakobs K., Procter R. & Williams R. (1996): Electronic messaging;
- Jones S., Bock G. & Brassard A.(1990): Using Electronic Mail: Themes Across Three User
Interface Paradigms;
- Pliskin N. (1989): Interacting with electronic mail can be a dream or a nightmare: a users
point of view;
- Mackay W. (1988): More Than Just a Communication System: Diversity in the use of
Electronic Mail;
- Maes P. (1993): Learning Interface Agents;
- Palme J. (1998): Email conversation;
Capitolul 2
- Crispin, M.: Internet Message Access Protocol
http://tools.ietf.org/html/rfc3501
- Crispin, M.: Ten Commandments of How to Write an IMAP client
http://www.washington.edu/imap/documentation/commndmt.txt.html
56

- Freed, N., Borenstein, N.: Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies
http://tools.ietf.org/html/rfc2045
- Freed, N., Borenstein, N..: Multipurpose Internet Mail Extensions (MIME)
http://tools.ietf.org/html/rfc2046
- Crispin, M., Murchison, K.: Internet Message Access Protocol
http://tools.ietf.org/html/rfc5256
- Gray, T.: Message Access Paradigms and Protocols
ftp://ftp.cac.washington.edu/mail/imap.vs.pop
- IMAP: https://ru.wikipedia.org/wiki/IMAP
http://ham.elcom.pub.ro/asi/slides/smtp-pop-imap-rev1.5.pdf
http://derivat.ro/cursuri/automatica/an2/an2_derivat.ro_protocoale-de-
comunicatii_9%203%20Email.pdf
Capitolul 3
- Struts 2:
http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=%2Fcom.ibm.etool
s.struts.doc%2Ftopics%2Fcstrdoc001.html
http://tapas4web.blogspot.ro/2011/04/struts2-architecture-at-glance.html
http://www.dzone.com/tutorials/java/struts-2/struts-2-tutorial/struts-2-tutorial.html
- Hibernate:
http://www.tutorialspoint.com/hibernate/hibernate_quick_guide.htm
- JavaMail API
http://www.oracle.com/technetwork/java/javamail-1-149769.pdf








57


Anex

IMAP Internet Mail Access Protocol
SMTP Simple Mail Transfer Protocol
RFC Request For Comment
HTML - HyperText Markup Language
MTA Mail Transfer Agent
MUA Mail User Agent
DNS Domain Name System
MX-Record - Mail eXchage Record
UID User ID
MIME - Multipurpose Internet Mail Extentions
JSF Java Server Faces
JSP Java Server Pages
HTTP Hypertext Transfer Protocol
Java EE Java Enterprise Edition
EJB - Enterprise JavaBeans
MVC Model View Controller
XML - Extensible Markup Language
POJO - Plain Old Java Object