1.

Verteilte Datenbanken - Eigenschaften

BDD = colectie de BD legate intre ele intr-o retea de calculatoare.
Datele sunt impartite fizic pe m.m calculatoare, dar aplicatiile nu cunosc aceasta
impartire vad doar o BD = principiul transparentei.
SDBD = sistem distribuit de BDate = sistem prin care se pot dezvolta aplicatii cu
cerinte mari dpdv al prelucrarii datelor.

Face posibila folosire in acelasi timp a puterii de procesare a m.multor calculatoare

Alcatuit din BDDistribuite + sistem distribuit de management al bazelor de date
(SMBD)
Face impartirea sa fie transparenta

Avantaje:
1. Independenta datelor fata de suportul fizic de memorare
2. Transparenta distributiei in retea u.nu stie detalii distr. date in retea: localizare,
nume E
3. Transparenta privind replicarea + fragmentarea datelor
4. Volum de stocare a datelor crescut
5. Siguranta de functionare, siguranta de disponibilitate
6. Date+sistem de gestiune: distribuite in m.multe site-uri => caz defectare un site:
alte site-uri pot sa continue sa functioneze + u. pot sa acceseze cel putin o parte din
date
Dezavantaje;
1. Complexitate mai ridicata privind: proiectarea, administrarea, intretinerea
2. Dificultati: necesitate de
a. prelucrare distribuita a interogarilor +
b. control al tranzactiilor distribuite
3. Securitatea necesita mecanisme speciale de protective: autentificare + criptare date
datorita comunicatiilor prin retea
4. Dificultati de mentinere a integritatii datelor:
a. Necesita operatii in retea,
b. Pot incarca mult capacitatea retelei

2. Verteiltes Datenbanksystem - Schema / Lokale Schema

BDD = multime de BD stocate pe multiple servere
O aplicatie:
o vede o singura BD
o poate modifica simultan diferite BD in retea
Fiecare BD din sistem:
o e controlata de pe un server
o coopereaza si cu alte BD pentru a mentine consistenta BD Globala
server de BD = soft pentru administrarea unei BD
client = aplicatie care da un request pentru informatii de pe server
Fiecare computer dintr-un sistem (SBDD) este un NOD
o se comporta precum:
un client
un server
sau amandoua, in functie de situatie.
Schema locala:
-

fiecare statie poate sa :

o lucreze cu datele autonomy
o comunice global cu alte calculatoare
schema locala:
o nu e integral adusa in schema globala, iar autonomia locala e data
doar partial
o contine informatii despre:
nodurile fragmentelor stocate
alocarea + replicarea fragmentelor relationale

Transparenta Schemei Locale dicteaza ca toate calculatoarele folosesc acelasi model

de date si acelasi sistem de gestiune problema: acest lucru nu e posibil cand se leaga
diferite SMBD-uri.

3. Fragmentierung einer Relation, Fragmentierung: Korrektheits-Anforderungen

Fragmentare = partitionarea unei relatii globale.
3 tipuri de F: Orizontala, Verticala, Mixta.
Fragmentarea Orizontala = F.O presupune multimi de date disjuncte.
Fragmentarea Verticala = F.V coordoneaza punerea impreuna a A2 cu acelasi mod
de accesare.
Fragmentarea Mixta = F.M combina F.O si F.V

Cerinte de corectitudine: fragmentarea trebuie sa respecte anumite cerinte.

Reconstructia
o Este posibila reconstructia relatiei fragmentate, bazandu-ne pe fragmentele
acesteia.
Integritatea
o Fiecare fisier trebuie sa corespunda unui fragment.
Disjunctivitatea
o F2 nu se suprapun = un fisier nu poate sa apartina mai multor fragmente.

4. Horizontale Fragmentierung + Abgeleitete H. Fragmentierung

F.O = tip de fragmentare
o Presupune impartirea multimii de date pe m.multe tabele
o Se mai numeste si regionalizare
o Exemplu: corporatie cu reprezentante in SUA si Europa. Putem fragmenta
datele prin: memorare date aferente reprezentantelor
din SUA intr-un server din SUA,
din Europa pe un server din Franta.
F.O Derivata
o este definita pe relatia membru a unei legaturi dupa o operatie de selectie
specificata de proprietarul legaturii.
o legatura dintre relatiile proprietar si membru e definite ca un equi-join. Un
equi-join poate fi implementat cu ajutorul semi-join-urilor.
Vertikale Fragmentierung = F.V

F.V = tip de fragmentare consta in separarea dupa coloana

Fiecare tabel rezultat dintr-o F.V contine o parte din A2 care nu sunt Chei + toate
A2 Cheie, care sunt repetate in fiecare tabel nou.

Kombinierte Fragmentierung = F.M

F.M = tip de fragmentare

o combina F.O si F.V.
o consta in aplicarea F.V la un F.O sau invers
o in practica este bine sa existe cel mult 2 divele de fragmentare
exemplu: tabelul cu studentii universitatii:
o dpdv vertical: fragmentarea va imparti datele dpdv al functionalitatii =>
tabelul cu datele personale StudPers (CNP, nume..)
tabelul cu datele specifice facultatii StudFac (nr grupa,
specializare..)
apartinand celor 2 tabel e: Cheia Primara = numarMatricol
o dpdv al F.O - putem s fragmentm datele studenilor din tabelul StudFac,
pentru a memora studenii de la faculti diferite n locaii diferite.
Astfel am avea o fragmentare mixta.

5. Baumdarstellung der Fragmentierung

exemplu: tabelul cu studentii universitatii:
a. dpdv vertical: fragmentarea va imparti datele dpdv al functionalitatii =>
1.tabelul cu datele personale StudPers (CNP, nume..)
2.tabelul cu datele specifice facultatii StudFac (nr grupa, specializare..)
3.apartinand celor 2 tabel e: Cheia Primara = numarMatricol
b. dpdv al F.Orizontale - putem s fragmentm datele studenilor din tabelul
StudFac, pentru a memora studenii de la faculti diferite n locaii diferite.
Astfel am avea o fragmentare mixta.
Fragmentarea efectuat mai sus poate fi reprezentat astfel:

6. Allokation einer Relation

Alocarea intr-o baza de date distribuita arata unde sunt salvate datele. Fiind cunoscuta
alocarea, se pot efectua operatii impotriva redundantei, sau a incorectidudinii datelor,
deoarece stim unde se afla fizic datele.

Proiectarea BDDistribuite implica doua activitati specifice, care iau in considerare

natura distribuita a datelor: fragmentarea si alocarea datelor.

Problema alocarii resurselor in sistemele distribuite poate fi definita astfel:

Fiind date un set de Fragmente F= {F1, F2, .., Fn} si o retea formata din mai multe
Noduri N ={N1, N2, .., Nn}, in care ruleaza un set de Aplicatii A= {A1, A2, .., An}
Trebuie gasita o solutie optima de distribuire a fragmentelor F pe nodurile N.

Solutia optima de distribuire poate fi definita prin intermediul a 2 obiective:

Minimizarea costurilor. Cost total = costuri de comunicatie + costuri de prelucrare a

operatiilor de interogare si actualizare a fiecarui fragment de pe fiecare nod + costuri
de stocare a fiecarui F pe fiecare N.
Maximizarea performantelor. Performante apreciate prin timpii de raspuns aferenti
operatiunilor de accesare si prelucrare a datelor. Timp de raspuns al unei T = timp de
transmisie prin retea + timp de accesare locala a datelor + timpul de prelucrare locala a
datelor.

Alocare in 2 etape: definirea strategiei de alocare + alegerea metodei de alocare ce va fi

utilizata.
Concluzie: alocarea datelor are ca obiectiv gasirea solutiei optime de plasare a fragmentelor
in conditiile minimizarii costurilor si maximizarii performantelor.
Atingerea acestui obiectiv impune
1. Definirea atenta a strategiei de alocare, in functie de care
2. Se va alege apoi metoda de lucru adecvata.
Definirea strategiei de alocare implica analiza atenta a cerintelor privind:

consistenta datelor, ponderea operatiunilor de actualizare in raport cu cele de

interogare, timpii de raspuns planificati, etc

in functie de care se poate opta pentru distribuire sau replicare.

7. Transparenz in verteilten Datenbanken

Un sistem distribuit de gestiune a bazelor de date (SGBDD) este un sistem de

programe care permite gestionarea bazei de date distribuite i face distribuirea
transparent pentru utilizatori.

Obiectivul transparenei este de a face ca un sistem distribuit s apar ca unul

centralizat. Acesta fiind denumit uneori principiul fundamental al SGBDD.

Exist trei tipuri de transparen:

-

de fragmentare
o presupune c utilizatorul vede doar schema global, fr s vad fragmentarea
sau alocarea.
de alocare
o utilizatorul vede fragmentarea bazei de date, dar nu si alocarea ei.

de schema locala
o utilizatorul vede i fragmentarea i alocarea, vede doar un model de date,
nefiind vizibil cuplarea mai multor SGBD-uri.

8. Anfragebersetzung und Anfrageoptimierung.

Algebraische Optimierung, Optimierung bei vertikaler Fragmentierung

Prelucrarea cererilor = interpretarea i optimizarea cererilor la F.O si F.V

Interpretarea cererilor = pp. generarea unui plan de evaluare pe fragmente

Optimizarea cererilor = are rolul de a genera un plan ct mai eficient pe ct posibil.

Plan eficient ia in calcul:

o alocarea datelor
o costurile de tranfer
o puterea de prelucrare a unitatilor

n cazul prelucrarii cerinelor, trebuie ct mai multe operaiuni s fie prelucrate local.

F.Orizontala pp. efort mare de unificare a datelor, de aceea pe ct posibil trebuie evitat o
reconstrucie global a tabelului.
n cazul fragmentrii verticale, trebuie nti stabilit ce date sunt necesare pentru ca cererea
s fie efectuat. Pentru ca algoritmul s fie optim, trebuie selectate cu cat mai puine
fragmente

9. Join-Auswertung Moeglichkeiten in VDBMS, Join-Auswertung mit Filterung,

Alternative

Auswertungungsplne

Parameter

fr

die

Kosten

eines

Auswertungsplan
Problema procesrii cererilor este mult mai complex n mediile distribuite. n sistemele
cu mai multe staii, timpul de raspuns va crete considerabil dac cererea implic operaii de
tip JOIN pe tabelele de dimensiuni mari. Unul dintre cei mai costisitori costisitori operatori
relaionali este operatorul join ( compunere ).
Pentru a optimiza eficient o comanda SQL care utilizeaz operatori join, trebuie s se in
cont de ordinea de execuie a join-urilor, astfel nct la fiecare pas s fie obinute ct mai pune
nregistrri ce vor fi utilizate n urmtoarea operaie join. De asemenea, este important i
alegerea metodei de procesare a join-ului, astfel nct aceasta s fie adecvat numrului de
tupluri care intr in join.
Cele mai multe sisteme de baze de date utilizeaz pentru implementarea join-ului diverse
forme ale algoritmilor Nested Loops, Sort Merge i Hash-Join.
Procesarea de instruciuni join cu filtrare presupune folosirea operatorului de semijoin
pentru filtrare. Ideea de baz este trasferul (...) tuplurilor care au un partener-join asociat.
Problema optimizrii execuiei interogrilor distribuite are scopul de a obine un timp de
rspuns al sistemului ct mai mic posibil n condiiile minimizrii costului total de execuie.
Costul total de execuie al unei interogri const n costul de prelucrare (CCPU) + costurile de
accesare a discurilor (CI/O) + costul comunicaiei ntre noduri.

10. Transaktionskontrolle in VDBMS

o tranzacie se poate ntinde pe mai multe maini fizice conectate ntre ele => controlul
tranzaciilor este foarte dificil, pentru a reconstrui datele unei operaiuni care a fost
ntrerupt.

Pentru recuperare ( recovery ) exist operaiunile UNDO i REDO.

Dupa cum spune i numele,

o UNDO anuleaz schimbrile efectuate, iar
o REDO repet schimbrile de la capt atunci cnd o tranzacie a fost ntrerupt.

tranzaciile trebuie sa nu fie executate incomplet => exist operaiuni de tip end-oftransaction, precum COMMIT i ABORT.
o COMMIT presupune ncheierea complet a unei tranzacii, iar
o ABORT este apelat atunci cnd o tranzacie global este ntrerupt, astfel toate
prile locale sunt aduse n starea de dinaintea tranzaciei.

11. Zweiphasen-Commit-Protokoll
protocol care asigur integritatea datelor cu privire la operaia end-of-transaction.

n acest protocol se presupune c exist un coordonator C i mai muli ageni ( A1, A2,
... An) care iau parte la o tranzacie.

Interaciunea ntre coordonator i ageni se poate urmri n schema urmtoare:

C trimite tuturor mesajul PREPARE;

agenii primesc acest mesaj i ori trimit napoi READY sau FAILED, dac nu pot face
COMMIT-ul mai departe.

Dac toi agenii trimit rspunsul READY, C trimite comanda COMMIT i asteapt
confirmarea ACK.

Dac nu sunt toate READY sau nu rspund n timpul stabilit, C trimite comanda de
ABORT i ateapt ACK c au anulat tranzacia.

12. Fehlersituationen des 2PC-Protokolls

Situatii de erori in 2PC:

ntreruperea coordonatorului
-

nainte de o comanda tip COMMIT => se trimite un ABORT

nainte de trimiterea unei comenzi de tip READY => se blocheaz agenii

ntreruperea unui agent

-

cnd un agent la o comand de tip PREPARE nu rspunde n timpul stabilit

nseamn c agentul este deranjat temporar => coordonatorul vede i trimite
ABORT

fiierul log al agentului:

o nu conine READY => trimite FAILED napoi
o conine READY dar nu COMMIT => agentul ntreab coordonatorul i
ateapt comanda COMMIT sau ABORT
o conine COMMIT => agentul tie c o comunicare este necesar, nu poate
primi doar aceast comand

Pierderea unui mesaj

o Se pierde un mesaj de tip PREPARE sau READY/FAILED. Dup impulsul de
timeout C trimite ABORT
o De data asta nu se pierde un PREPARE ci un aget rspunde i nu primete
niciun rspuns de COMMIT/ABORT => agentul trimite lui C un reminder

13. Mehrbenutzersynchronisation in VDBMS

Deoarece datele trebuie s fie accesate de mai muli utilizatori n acelai timp, se creeaz
anumite probleme cu privire la accesul simultan asupra datelor.
Acest lucru este posibil prin serializare, ns nu ar putea funciona rapid o serializare pe
fiecare dintre calculatoare, de aceea sincronizarea mai multor utilizatori trebuie s se bazeze
pe serializarea global.
Protocolul de blocare n dou faze ( 2 phase locking protocol )
local
-

pe fiecare calculator tranzaciile locale trebuie s comunice cu propriul administrator

tranzaciile locale sunt favorizate, ns recunoaterea aa-numitelor deadlocks este

mult m??

global
-

exist un coordonator de blocare central

acest coordonator respect autonomia calculatoarelor, ns pentru a avea drepturi de

blocare, fiecare computer trebuie s le cear coordonatorului central

14. Deadlocks in VDBMS, Zentralisierte Deadlock-Erkennung,

Deadlock-Vermeidung
Deadlocks in SGBDD
Deadlock - descrie o stare n care unul sau mai multe procese ateap eliberarea unor resurse
care deja sunt ocupate de unul sau mai multe dintre ele.
Identificarea centralizat a Deadlock-urilor
Un Deadlock este mai uor de identificat i procesele s fie restartate, dect de prevenit,
deoarece trebuie doar inute minte alocrile de resurse. ( Astfel cnd se identific un
Deadlock, procesele sunt restartate pentru a nceta Deadlock-ul. Recunoaterea Deadlockurilor se poate folosi de un graf de ateptate, fie global sau local. ntr-un graf local, se
consider un nod Extern, n care se duc toate arcele de ateptare ctre alte maini fizice. )
n acest tip de identificare, se numete un nod de control. Acesta servete ca un hub central
pentru activitile de detecie a activitilor Deadlock. Activitatea primar a acestui nod de
control este de a nregistra grafurile de ateptare i de a cuta cicluri tip Deadlock. Restartarea
proceselor i eliberarea resurselor se poate face doar pe acest nod.
Transmiterea continu de mesaje pentru meninerea actualitii grafului de ateptare
presupune un efort de transmisie. O mbunatire la acest algoritm ar fi dac fiecare nod i-ar
executa propriul graf de ateptare, care doar periodic ar fi trimis nodului de control.
Evitarea Deadlock-urilor
Exist algoritmi care se folosesc de date de tip timestamp. Astfel se cunoate care process
ruleaz de mai mult timp i se poate prioritiza care proces primete acces la resurse i care
proces ateapt sau este nchis.
Exist dou tipuri de algoritmi de evitare a unui Deadlock: Wait/Die i Wound/Wait. Dac
V ar fi procesul vechi i T cel tnr, sistemul s-ar comporta astfel:
Wait/Die

Wound/Wait

V are nevoie de o resurs de la N

V ateapt ( wait )

N - moare

N are nevoie de o resurs de la V

N moare ( die )

N ateapt

15. Synchronisation bei replizierten Daten

Exist cazuri n care o informaie este repetat n SGBDD.

O tranzacie de citire necesit doar o copie, ns atunci cnd schimbm ceva, trebuie
actualizate toate copiile.

De aici rezult un timp ndelungat de execuie.

Exist dou tipuri de replicare: activ i pasiv.

Replicarea activ = procesm aceeai tranzacie la fiecare copie, iar

cea pasiv presupune c fiecare tranzacie este executat doar pe o singur copie, dup
care informaia este trasferat celorlalte replici.

Dac n cazul replicrii pasive se alege o copie central pentru a fi procesat de toate
tranzaciile, vorbim de o schem primary-backup sau master-slave.

n cazul opus, cnd orice copie poate procesa cererile, atunci schema este multiprimary sau multi-master.

De obicei ntr-o BDD se folosete relaia de tip master-slave.

n cazul n care se folosete relaia de multi-master, exist conflicte atunci cnd mai
multe copii sunt schimbate aproximativ simultan, iar acestea sunt tratate prin dou
moduri.

Un sistem ce dorete s previn astfel de conflicturi nu execut commit-uri pn la

capt i ar renuna la una dintre tranzacii. Un astfel de sistem ar atepta pn la
resincronizare pentru a actualiza datele i ar alege copia cu timestamp-ul cel mai nou.

16. Phasen des Data Warehouse

1. Monitorizarea: Aceasta faza presupune tinerea sub observatie a surselor, descoperirea
schimbarilor de date, care sunt relevante pentru Data Warehouse
2. Extragerea: Se extrag date din surse diferite. Aceasta selectie de surse de date depinde
de relevanta acestor date pentru evaluarea planificata, precum si de calitatea datelor.
3. Transformarea: Este faza in care se integreaza datele, pentru a forma un stoc unitar de
date, pentru Data Warehouse.
4. Incarcarea: Exista doua faze de incarcare: initializarea, si actualizarea datelor. Cea
dintai vizeaza toate datele din Data Warehouse iar actualizarea priveste numai acele
date din Data Warehouse care au fost schimbate.
5. Analizarea: Aceasta faza poate fi impartita in Data Access, OLAP si Data Mining
Un depozit de date furnizeaz o surs integrat i centralizat de date, aparte fa de sistemul
tranzacional, care conine datele eseniale despre activitatea companiei din multitudinea de
surse de date existente. Rapoartele obinute pe baza acestor date sunt utilizate ca un
instrument de analiz strategic i competitiv. Analizele rapide i corecte pot influena deciziile
privind evoluia organizaiei pe termen mediu i lung.
un depozit de date este o colecie de date orientate pe subiecte, integrate, istorice i nevolatile
destinat sprijinirii procesului de luare a deciziilor manageriale William Inmon
Caracteristici:

Depozitul de date asigura accsul la datele organizatiei. Acces: imediat, la cerere,

performant.
Datele dintr-un depozit trebuie sa fie consistente. Consistenta: atunci cnd dou
persoane solicit acelai set de informaii s primeasc aceleai date, chiar dac ele au
fost cerute la momente de timp diferite
Datele ntr-un depozit de date pot fi separate i combinate pentru a oferi un acces ct
mai rapid i un timp de rspuns ct mai mic sistemului
Depozitele de date nu reprezint doar datele, ci i un set de utilitare pentru a interoga,
analiza, prezenta informaiile
Datele din depozite sunt utilizate direct n analize, fr alte prelucrri suplimentare.
Datele nu sunt doar acumulate la un loc i pstrate ci sunt asamblate dintr-o varietate
de surse, sunt corectate de erori, li se asigur calitatea necesar i abia apoi devin
utilizabile
Calitatea datelor din depozitele de date este un factor determinant pentru procesul de
reculegere a datelor.

17. SQL

18. Maven
Produs Apache
Instrument de gestiune a unui proiect software
Prin gestiune se intelege construirea, raportarea si documentarea proiectului bazata pe
conceptul de POM (Project Object Management)
POM unitate fundamentala de lucru in Maven, fisier XML contine informatii
despre proiect + detalii de configurare.
Unul dintre cele mai cunoscute builder-e. Capabilitati:
o Procesare, compilare, impachetare, testare, distributie
o Ruleaza/ genereaza rapoarte
o Faciliteaza comunicarea intre membrii unei echipe de lucru
Un fiier XML descrie proiectul care urmeaz s fie build-uit, dependenele acestuia
sau alte module i componente de care depinde, ordinea n care se execut build-ul,
directoarele i plug-in-urile necesare.

Maven descarc dinamic bibliotecile Java i plug-in-uri necesare, din unul sau mai
multe repository-uri.

19. Jboss
JBoss Enterprise Application Platform - o platforma de baza pentru aplicatiile Java.

face deosebit de facila dezvoltarea, implementarea si administrarea aplicatiilor Java.

Contine tehnologii de varf open source pentru crearea si gazduirea de aplicatii Java si
servicii in Service Oriented Architecture.
face enterprise Java simpla, deschisa si accesibila.
realizeaza un echilibru intre inovatie si stabilitate. JBoss EAP imbunatateste
productivitatea dezvoltatorilor, elimina complexitatea dezvoltarii in Java si simplifica
dezvoltarea aplicatiilor critice.

Application Platform contine JBoss Application Server, serverul de aplicatii Java si servicii
web si integreaza: Jboss Hibernate si JBoss Seam.
Beneficii

Foloseste standarde open

Imbunatateste productivitatea utilizatorului
Inovatie cu stabilitate
Performanta de nivel enterprise

JBoss Aplication Server: cel mai folosit server de aplicatii de pe piata.

O platforma Java certificata pentru dezvoltarea si implementarea de aplicatii

enterprise.
Suporta API-urile traditionale cat si Java EE API si contine performanta si
scalabilitate imbunatatita.
Contine suport extins pentru facilitate Java EE 5 cum ar fi: EJB, Java Persistence API,
Servlet, JSP JSP/EL, JSTL, JSF, Java mail, JAF, SAAJ, JTA.

Sisteme de operare suportate.

JBoss Rules este 100% Java => interopereaza cu majoritatea sistemelor de operare
capabile sa ruleze Java Virtual Machine (JVM):
o Windows, UNIX, Red Hat Enterprise Linux, alte distributii Linux.

Baze de date suportate.

JBoss EAP lucreaza cu orice baza de date conforma JDBC:

o IBM DB2, Microsoft SQL Server, MySQL, Oracle, PostgreSQL, Sybase.

20. EJB + Hibernate

Hibernate
Lucrul cu software orientat obiect si baze de date relationale poate fi time-consuming si poate
cauza diverse erori datorita diferentelor dintre reprezentarea datele in baza de date si
modelarea lor in obiecte.

Este un framework free si open-source pentru limbajul Java, util pentru maparea
modelului orientat pe obiecte peste bazele de date relationale.
ofera o solutie rapida, de inalta performanta, independenta de tipul bazei de date
folosite pentru modelarea obiectelor unei baze relationale.
principala caracteristica: maparea intre clasele Java si tabelele bazelor de date precum
si intre tipurile de date Java si SQL
pune la dispozitie posibilitatea redactarii de query-uri si data-retrieval
permite concentrarea asupra obiectelor si particularitatilor (features) aplicatiei, fara a fi
preocupat de modul in care sunt salvate/ memorate si cum pot fi gasite mai tarziu
de ce Hibernate:
o cost effective
o se invata f. usor in comparatie cu EJB
o nu mai este nevoie de JDBC API pentru prelucrarea setului de rezultate
o migrarea unei aplicatii Java care foloseste Hibernate pentru lucrul cu baze
relationale la un alt timp de baza(eg. Oracle Postgresql), presupune putine
schimbari in fisierul de configurare pentru lucrul cu Hibernate.
avantaje: aplicatie independenta de BD, este evitat complet JDBC API, generare de
chei automata, dezvoltare aplicatii in timp scurt.
suporta diferite Baze de Date: DB2, MySQL, PostgreSQL, Oracle, SAP DB si altele
arhitectura: 3 componente majore Connection Management, Transaction
Management, Object Relational Mapping (ORM)
furnizeaza 3 facilitari de query:
o Hibernate Query Language
o Hibernate Criteria Query API
o Hibernate Native
implementare:
o configurare Hibernate,
o setare referinte intre BD si clasele Java,
o build: fisiere xml si java,
o mapare Obiecte la tabelele din DB,
o configurare/ setare tranzactie.

EJB = Enterprise Java Beans

Platforma Java EE are o serie de interfete de programare (API) specifice: RMI, JDBC, JNDI,
Servlets si JSP, JMS (Java Messaging Service), EJB.
EJB
-

defineste un model bazat pe componente reutilizabile pentru partea de server (business

logic) a aplicatiilor,
implementand automat o serie de servicii si
asigurand portabilitatea intre diverse servere de aplicatii.

Exista EJB sesiune, EJB bazate pe mesaje si entitati de persistenta.

Arhitectura EJB
-

permite realizarea unor aplicaii distribuite prin combinarea de componente dezvoltate

independent, de diferii programatori.
Componentele se dezvolt o singur dat i pot fi utilizate (instalate) de cte ori e
necesar.

n cadrul oferit de EJB se deosebesc 7 roluri pe parcursul ciclului de via al unei aplicaii:
1.
2.
3.
4.
5.
6.
7.

Furnizorul de EJB.
Asamblorul de aplicaii
Instalatorul (Deployer)
Furnizorul serverului EJB
Furnizorul containerului
Furnizorul de persisten
Administratorul de sistem