Elementele definitorii pentru integrarea datelor [310586]

Licență

Elementele definitorii pentru integrarea datelor [310586]

Byadmin ianuarie 1, 2024

Introducere

Lucrarea își propune să prezinte principalele modalități de integrare a [anonimizat]. [anonimizat], [anonimizat], [anonimizat], [anonimizat], iar pentru date semistructurate XML. [anonimizat]: Servlet, JSP, JSF, Taglibs, Struts, etc., [anonimizat] (bean-uri ce au starea sincronizată cu elemente din baza de date pe care se face maparea), EJB Beans (bean-[anonimizat]), ADF JavaBeans (bean-[anonimizat] ([anonimizat], [anonimizat])). [anonimizat], [anonimizat]-response.

Pe parcursul lucrării vor fi prezentate și alte limbaje de programare utilizate în construirea aplicațiilor Web precum: PHP, C#, Perl, [anonimizat]. [anonimizat]-un format unic de către o [anonimizat]-uri pot realiza transformarea datelor structurate în baze de date relaționale în fișiere de acest tip.

[anonimizat]-[anonimizat], [anonimizat] a [anonimizat], [anonimizat] 10g, etc.

[anonimizat]-uri, metadate, [anonimizat], sau încărcarea lor completă în câmpuri permanente ale unei baze de date. Lucrarea va avea în vedere prezentarea unor modalități moderne de construire a [anonimizat] a diverse tipuri de date prin conexiuni Java.

[anonimizat], [anonimizat] (Service Oriented Architecture), utilizarea limbajului JavaScript în cadrul paginilor Web.[anonimizat] (JavaServer Pages), JSF (JavaServerFaces), JSTL (JavaServer Pages Tag Library) [anonimizat], de formatare a datelor, de procesare a [anonimizat] ([anonimizat]/Servlet), Spring (Application Framework pentru ansamblarea componentelor unei aplicații prin intermediul fișierelor de configurare) și Hibernate (librărie JAVA pentru ORM – object-relational mapping): injectarea dependențelor, programarea orientată pe aspect; fișiere de mapare, sesiuni și tranzacții, operații CRUD (create, read, update and delete), limbaj interogare HQL (Hibernate Query Language), reprezintă baza aplicațiilor Web ce fac posibilă interacțiunea dintre utilizatori și bazele de date.

Elemente definitorii pentru aplicații Web

Pentru conceperea aplicațiilor Web se întocmesc scheme relaționale, diagrame, documentații detaliate, specificații tehnice, etc ce pot fi organizate și structurate prin UML (Unified Modeling Language) – limbaj universal pentru software design ce crează pattern-uri în folosirea obiectelor de către dezvoltatori software si prin UBL (Universal Business Language) – limbaj universal de business ce cuprinde biblioteci XML ce modelează documente specifice de business (facturi, comenzi, etc.). Un rol important în construirea aplicațiilor Web îl au fișierele XML. Prin adăugarea de constrângeri semantice, limbajele pentru construirea aplicațiilor pot fi implementate în XML. În mod special XML este folosit ca limbaj de specificație pentru alte limbaje de construire a aplicațiilor Web. Există tehnici tradiționale de procesare a fișierelor XML, precum: folosirea limbajelor de programare și SAX API (Simple API for XML – un API Java), limbaje de programare și DOM API (Document Object Model – o componentă API a Java API for XML), utilizarea motoarelor de transformare și filtrare.

Tehnici mai recente pentru procesarea fișierelor XML sunt: Pull Parsing, Non-Extractive Parsing și Data binding. SAX este o interfață pentru lexical, event-driven, în care un document este citit în modul serializat și conținutul său este raportat ca “callbacks” către handler-e de obiecte utilizate de către design-ul pentru utilizator. În cazul în care datele sunt structurate în fisiere XML, acestea prin limbajul Java pot fi transformate în clase Java. Generarea claselor este realizată pe baza regulilor de validare xs prin intermediul unui compilator Marshalling, Unmarshalling, astfel că datele ce sunt prezente în clase Java pot fi utilizate cu ușurință în cadrul aplicațiilor Web, în activități de afișare, modificare, ștergere și adăugare a datelor. Pentru utilizarea fișierelor XML în cadrul aplicațiilor Web este importantă activitatea de transformare a fișierelor XML.

Ca și motoare de transformare și filtre se pot enumera: XSL (Extensible Stylesheet Language) ce pot transforma fișiere XML pentru afișare și printare. XSL-FO (XSL–Formatting Objects) este un limbaj declarativ pentru page-layout bazat pe XML. Un procesor XSL-FO poate fi utilizat pentru convertirea unui document XSL-FO într-un document ce nu are format XML, de exemplu PDF. XSLT (Extensible Stylesheet Language Transformations) este un limbaj declarativ de transformare a documentelor XML. Un procesor XSLT poate folosi un stylesheet XSLT ca șablon pentru conversia arborelui de date reprezentat de un document XML într-un alt arbore ce poate fi serializat ca XML, HTML, TEXT sau orice alt format suportat de procesor. Xquery este un limbaj W3C de interogare, construire și transformare a datelor XML. XPath este asemănător unui arbore DOM (Document Object Model) pentru modele de date și path expression, limbaj folosit pentru selectarea datelor din interiorul documentelor XML. XSL-FO, XSLT și Xquery folosesc Xpath. XPath include o librărie funcțională necesară selectării datelor XML.

Integrarea datelor în cadrul aplicațiilor Web pentru SGBD-uri

Scopul cercetării este de a găsi noi modalități de accesare a diferitelor tipuri de date prin intermediul aplicațiilor WEB. Ca element de noutate lucrarea de cercetare își propune definirea unui driver general de accesare a diferitelor tipuri de date, în limbajul Java. Acest driver va fi inclus într-un pachet Java, ce va extinde capacitățile și posibilitățile pachetelor existente în domeniul accesării datelor structurate sau semistructurate. O modalitate de realizare a acestui driver ar putea fi transformarea datelor din baze de date în fișiere XML și transformarea acestora în clase Java, utile în cadrul aplicațiilor Web. Aceste clase vor fi bean-uri ce vor mapa entități prezente în baze de date, astfel încât orice modificare asupra lor se va reflecta automat în baza de date. O altă modalitate de accesare a datelor prin limbajul Java este de a testa ce tipuri de date vor fi utile aplicației Web și includerea driverelor specifice în driverul general de accesare și conectare la baza de date.

Conexiunea permanentă de la nivelul aplicației Web va fi în funcție de tipul de date utilizat în logica de business. În general transformarea diferitelor tipuri de date într-un singur tip de date gestionat de un SGBD ce conține multiple facilități permite accesarea facilă a acestora, minimizând costurile și optimizând modul de funcționare al aplicațiilor Web construite cu Java. Pentru date semistructurate sau prezente în SGBD-uri de generație veche este utilă transformarea acestora în fișiere XML ce pot fi ușor accesate și gestionate de limbajul Java și astfel fiind posibile construirea de aplicații Web ce oferă facilități superioare utilizatorilor în comparație cu aplicații de generație anterioară.

Pe piața IT din țara noastră există puține aplicații WEB ce accesează date din diverse SGBD-uri. Există firme ce au datele constituite în fișiere de tip XML sau în baze de date de tip Fox, Microsoft Acces (SGBD-uri de generație veche). Aceste firme doresc să implementeze noi sisteme informatice ce fac posibilă accesarea, manipularea și utilizarea datelor prin intermediul rețelei Internet. Limbajul Java oferă un bun suport pentru realizarea de aplicații complexe pentru Web, fiind apreciat pentru ușurința dezvoltării, întreținerii și actualizării aplicațiilor. Un aspect foarte important al acestui limbaj este independența lui față de platformă. În același timp mulțimea de unelte gratuite pentru dezvoltare, reutilizarea facilă a codului, documentațiile online, precum și un număr mare de site-uri specializate cu topicuri și forumuri de discuții pentru comunitatea de programatori Java, fac posibile crearea de aplicații Web stabile și robuste pentru diferite tipuri de servere și SGBD-uri.

Componentele aplicațiilor Web

Elemente foarte importante pentru aplicații Web sunt: autentificarea și administrarea utilizatorilor, trimiterea unor diverse tipuri de conținut către browser-ul clienților, managementul sesiunilor, implementarea, stocarea și gestionarea cererilor client, asigurarea ergonomiei site-ului. Pentru lucru cu baze de date în PHP se folosește SGBD-ul MySQL prin intermediul aplicației phpMyAdmin folosit în activitățile de editare a structurii și conținutului bazelor de date. Un alt aspect important al aplicațiilor Web îl are contorizarea utilizatorilor, urmată de autentificarea acestora și gestionarea sesiunilor pentru utilizatori autentificați. O altă modalitate de construire a unei aplicații Web o reprezintă limbajul WML (Wireless Markup Language) pentru dispozitive WAP de accesare a datelor prin intermediul interfețelor Web, utilizând limbajul JavaScript pentru operații de validare a formularelor sau operațiuni drag-and-drop.

De asemenea PHP poate fi utilizat în lucru cu documente XML, atât pentru interfețe grafice, cât și pentru accesarea datelor semistructurate și utilizarea lor în cadrul aplicațiilor Web. Pentru aplicații ce au componente grafice complexe (2D, 3D) se folosesc limbaje de redare a graficii Web precum SVG (Scalable Vector Graphics) și X3D (reformulare în termenii XML a limbajului VRML (Virtual Reality Modeling Language)).

Formatul SVG este unul dintre formatele standardizate de Consorțiul Web, destinate realizării de grafică vectorială pentru Web. Pentru implementarea etapelor de creare a arhitecturii interfeței Web și modul de implementare a structurii de date sunt folosite standarde PHP, MySQL, SVG, VRML, XML și JavaScript. PHP poate utiliza facilitățile oferite de biblioteca GD (Graphics Dynamic Library), pentru generarea dinamică a chart-urilor, folosind paradigma programării orientate-obiect.

Capitol 1 – Identificarea principalelor tipuri de date

1.1. Specificarea tipurilor de fișiere – Fișiere de tip XML

Fisierele de tip XML au urmatoarele caracteristici: structurarea datelor: ceea ce permite modelarea datelor pentru orice nivel de complexitate; asigura schimburile de date prin Internet între aplicatiile informatice sau între bazele de date; XML completeaza HTML: datele XML pot fi utilizate în paginile HTML; identificarea rapidă a documentelor prin motoare de căutare: crește relevanta căutarii prin includerea informației contextuale; facilitatea de reactualizare: structurile DOM (Document Object Model) permit accesul și reactualizarea la nivelul elementelor individuale; accesul selectiv la date: conținutul poate fi publicat în multiple formate; autodescrierea documentului: nu sunt necesare cunoștiinte anterioare despre aplicatie; extensibilitatea – se pot defini noi marcatori daca este nevoie; validitatea – se verifică corectitudinea structurală a datelor [6], [23], [76].

XML va revolutiona aplicatiile prin Internet în mod similar limbajului Java. Prin Java se realizează aplicații independente de platforma, ceea ce reprezintă un mare avantaj pentru dezvoltarea aplicatiilor Web distribuite.XML oferă utilizatorilor posibilitatea de a-și reprezenta datele într-un mod independent de aplicatie. Figura următoare prezintă schimbul datelor între aplicații utilizând XML :

Fig. 1.1.1 – Schimbul de date între aplicații utilizând XML

De la HTML la XML :

Cele doua limbaje au fost create în scopuri diferite: XML a fost proiectat pentru descrierea datelor și se concentreaza asupra structurii acestora; HTML a fost proiectat pentru afișarea datelor și se concentreaza asupra aspectului acestora.

Translatarea din format XML în format HTML:

Translatarea se poate realiza în urmatoarele moduri: datele XML de pe server sunt transmise la client, iar navigatorul utilizează informațiile externe – foi de stil – pentru a realiza translatarea în formatul HTML ce asigură afișarea; datele XML rezidente pe server vor fi convertite în format HTML înainte de a fi transmise către navigator (browser) [11], [34], [79].

Fig. 1.1.2 – Translatarea din format XML în format HTML

Exemplul de cod html: ex1.htm

<HTML>

<HEAD>

<TITLE> Depozit produse </TITLE>

</HEAD>

<BODY>

<H2>Produse</H2>

<UL>

<LI>Produs1<I>Descriere produs1</I>Pret produs1</LI>

<LI>Produs2<I>Descriere produs2</I>Pret produs2</LI>

<LI>Produs3<I>Descriere produs3</I>Pret produs3</LI>

</UL>

</BODY>

</HTML>

Exemplul de cod XML: ex2.xml

<?xml version="1.0" encoding="ISO-8859-2"?>

<DEPOZIT_PRODUSE>

<TITLUL>Depozit de produse</TITLUL>

<PRET>Pret produs1</PRET>

<DESCRIERE_PROD>Descriere produs1</DESCRIERE_PROD>

</PRODUS>

……..

<PRET>Pret produs1</PRET>

<DESCRIERE_PROD>Descriere produs1</DESCRIERE_PROD>

</PRODUS>

</DEPOZIT_PRODUSE>

Facilități și cerințe XML:

– simplu de utilizat pe Internet;

– suportă o mare varietate de aplicații;

– compatibil cu SGML;

– ușor de scris programe care să prelucreze documente XML;

– numărul elementelor opționale din XML este redus la minimum;

– documente XML sunt clare și interpretabile de către utilizatori

– documentul XML să poată fi pregătit rapid ;

– documentul XML trebuie să fie concepute rapid, formal și concis.

Caracteristici ale limbajului XML :

– XML este un limbaj de marcare extins, similar limbajului HTML;

– XML a fost proiectat pentru descrierea datelor;

– Tag-urile XML nu sunt predefinite – în acest sens există un set de reguli pentru crearea tag-urilor proprii, utilizate în descrierea datelor;

– XML utilizează definirea tipului de document (DTD) – pentru a descrie modul de formatare a datelor;

– XML se folosește cu un DTD pentru a fi auto-descriptibil [5], [6], [71].

Utilizarea XML:

– Prin XML se separă datele care reprezintă continutul unui document de cele care se referă la prezentarea acestuia;

– Prin XML datele pot fi schimbate între sisteme incompatibile;

– Prin XML informația din domeniul afacerilor poate fi schimbata prin Internet;

– Prin XML fișierele text pot fi utilizate ca date partajate, independent de platformele software și hardware;

– XML poate fi utilizat pentru memorarea datelor în fișiere sau baze de date;

– Prin XML datele vor fi disponibile mai multor utilizatori;

– XML poate fi utilizat pentru generarea de noi limbaje.

Elementele de bază ale limbajului XML:

– XML limbaj de marcare

– Elementele

– Tag vid

– Atributele

– Comentariile

– Date analizabile

– Codificarea în documentele XML

– Erori posibile în documentele XML

Structura logica a unui document XML :

Un document XML trebuie sa fie compus din:

– un prolog – conține un anumit număr de declaratii;

– un arbore al elementelor (cu atributele lor) – există un element

rădăcina, care este unic;

– comentariile, instrucțiunile de prelucrare si referințele – a căror prezenta este facultativă.

Prologul poate fi compus din trei componente:

– Declaratia XML;

– Instructiunile de prelucrare;

– Declaratia tipului de document [14], [34], [78].

Sintaxa generala pentru declaratia XML este:

<?xml version="nr_versiune"

encoding="declarare_cod" standalone="stare" ?>

Exemplu:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

– version – versiunea limbajului XML utilizată în document;

– encoding – codificarea caracterelor utilizată în documentul XML;

– standalone – existența sau nu a unor declarații exterioare documentului, de care se va ține seama (dacă atributul standalone are valoarea "yes", declarațiile necesare prelucrării documentului sunt

incluse; daca acest atribut are valoarea "no", declarațiile sunt în fisiere externe).

Instrucțiunile de prelucrare sunt declarate în cadrul documentului sub forma:

<?Nume_aplicatie instructiune ?>

De exemplu, pentru afișarea unui document XML cu ajutorul unei foi de stil XSL, se va utilize următoarea instrucțiune de prelucrare:

<?xml:stylesheet type="text/xsl"?>

Iar pentru afișarea unui document XML cu ajutorul unei foi de stil CSS, se va utiliza următoarea instrucțiune de prelucrare:

<?xml:stylesheet type="text/css"?>

Declararea notațiilor :

Notațiile identifică, prin numele lor, formatul entităților care nu sunt XML. Sintaxa generală pentru declararea unei notații este :

<!NOTATION nume_notatie SYSTEM "URI">

sau

<!NOTATION nume_notatie PUBLIC "public_ID">

sau

<!NOTATION nume_notatie PUBLIC "public_ID" "URI">

unde:

– URI: este un URL unde notația externă poate fi găsită;

– public_ID: poate fi utilizată de un procesor XML pentru a genera un URL alternativ, unde notația externă poate fi găsită [71], [111], [77].

1.2. Arhitecturi și facilități oferite de SGBD-uri

Sisteme de baze de date

Un sistem de baze de date este un sistem computerizat de păstrare a înregistrărilor al cărui scop principal este să stocheze informațiile și să permită utilizatorului să consulte și să actualizeze la cerere aceste informații.Un system de baze de date este format din patru componente principale: date, hardware, software și utilizatori.

Componenta de date: este formată din baza de date sau bazele de date ale sistemului.

Componentele hardware sunt formate din: mediile de stocare secundare care sunt utilizate pentru păstrarea datelor și procesoare folosite pentru prelucrarea datelor și memorii RAM, etc.

Componenta software este formată din Sistemul de gestiune a bazelor de date, programe utilitare, editoare de rapoarte, etc.

Utilizatorii: există trei clase mari de utilizatori – programatorii de aplicații, utilizatorii finali care accesează baza de date prin intermediul unei aplicații, și administratorul BD.

In domeniul bazelor de date este important să se facă o distincție clară între noțiunile de dată și informație [15], [23], [82].

Datele, materia primă a sistemelor informatice, sunt „fapte culese din lumea reală pe bază de observații și măsurători”. Datele pot lua mai multe forme: date alfanumerice (formate din litere, cifre și caractere speciale), date de tip text (propoziții și fraze folosite în comunicarea scrisă), date de tip imagine (forme grafice și figuri geometrice) și date audio (vocea umană și alte sunete). În sistemele informatice datele sunt stocate în baze de date [72], [75].

Informația este rezultatul interpretării datelor de către un anumit subiect și conferă acestuia capacitatea de a lua decizii. Datele devin informații doar în momentul în care acestea interacționează cu un sistem capabil să le interpreteze. Informația are un caracter subiectiv deoarece aceeași dată poate fi interpretată diferit de către subiecți diferiți. Informațiile sunt date prelucrate și prezentate într-o formă (context) care să aibă o anumită semnificație pentru utilizatorul final și reprezintă ieșirile sistemului informatic. În concluzie, se poate afirma faptul că sistemele informatice prelucrează date nu informații [42], [117], [124].

Informația reprezintă produsul final al sistemelor informatice și, în funcție de cele patru dimensiuni, timp, conținut, forma de prezentare și locație, aceasta trebuie să îndeplinească următoarele cerințe pentru a fi utilă:

A. În funcție de elementul timp:

– să fie oportună: informația trebuie să fie furnizată atunci când este nevoie de ea, să fie disponibile în timp util;

– să fie nouă: informația nouă descrie cel mai bine prezentul situației sau ultima verigă a evoluției unui fenomen;

– să fie furnizată cu o anumită frecvența: informația trebuie să fie furnizată cu un ritm care să sprijine interesele utilizatorilor;

– se facă referire la o anumită perioada de timp: informația poate să conțină elemente care să descrie evenimente din trecut, prezent sau viitor.

B. În funcție de conținut:

– să reducă gradul de incertitudine: cu cât informațiile fac referire mai clară asupra unui fenomen, cu atât viziunea de ansamblu și de amănunt a decidenților asupra respectivului fenomen va fi mai bună și, pe cale de consecință, decizia va fi luată în cunoștință de cauză.

– să fie corectă: informația nu trebuie să conțină erori; trebuie să facă

referiri exacte asupra oricărui fenomen fără doze de relativism.

– să fie pertinentă: informațiile trebuie să facă referire la un anumit fapt, situație, eveniment și în același timp să descrie realitatea de facto;

– să fie relevantă: informația trebuie să satisfacă nevoile de informare ale utilizatorului cu privire la o anumită situație.

– să fie necontradictorie sau noncontradictorie – informațiile

descriptive care fac referire la o anumită situație trebuie să aibă

aceeași valoare de adevăr în același moment temporal.

– să fie neredundantă sau nonredundantă: de obicei o informație face

referire la un anumit aspect. Dacă aceeași informație se repetă ea nu

aduce nimic nou în raport cu aspectul descris.

– să fie completă: informația trebuie să conțină toate elementele de

care utilizatorul are nevoie;

– să aibă caracter succint: vor fi furnizate doar acele informații de

care este nevoie într-o anumită situație decizionala;

C. În funcție de forma de prezentare informația trebuie respecte următoarele

caracteristici:

– să fie clară: informația trebuie să fie prezentată într-o formă ușor de înțeles;

– să fie furnizată în formă detaliată sau sintetizată în funcție de

necesități;

– să fie prezentată într-o anumită succesiune, într-o anumită ordine;

– să aibă o formă adecvată necesităților factorului de decizie – forma

de prezentare a mesajelor poate să atragă sau nu atenția decidenților.

Informația poate fi furnizată sub forma unei relatări (expuneri), sub formă numerică, grafică, sub formă de tabel etc. Informația poate fi prezentată pe suport de hârtie, pe ecranul computerului sau folosind alte medii [11], [13].

D. În funcție de locație:

– informația trebuie să fie disponibilă indiferent de locația în care se află utilizatorul (fie disponibilă oriunde).

Informațiile solicitate la nivel strategic și tactic au următoarele caracteristici:

– sunt neprogramate, ad hoc, sunt determinate de apariția unor evenimente care necesită luarea unor decizii;

– sunt sintetizate: informațiile trec prin procese de selecție și sintetizare pentru a putea fi folosite de nivelele manageriale superioare;

– vizează orizonturi mari de timp – informațiile se referă la trecut, prezent, viitor;

– aria de cuprindere a informațiilor este largă;

– au caracter previzional;

– provin din interiorul și exteriorul firmei (concurența, clienți, furnizori).

Pe de altă parte, informațiile solicitate la nivel operațional îndeplinesc următoarele caracteristici:

– sunt programate, se obțin la intervale de timp bine stabilite;

– au un conținut prestabilit care acoperă nevoia de informații determinată de deciziile de rutină cu care se confruntă managerii de la acest nivel;

– aria de cuprindere este restrânsă și bine definită;

– au grad de detaliere ridicat;

– provin cu preponderență din mediul intern al organizației;

– se referă la evenimente din trecut;

– sunt cerute cu frecvență mare, și sunt exacte, precise.

Bază de date.

Baza de date este o colecție de date persistente, care sunt folosite de către sistemele de aplicații ale unei întreprinderi”. Prin persistență înțelegem intuitiv că datele din baza de date diferă, ca tip, de alte date efemere, cum ar fi datele de intrare, datele de ieșire, rezultatele intermediare, și în general, orice date care sunt de natură trecătoare. Se poate spune că datele din BD persistă deoarece, odată ce au fost acceptate de SGBD pentru introducerea în BD „ele nu pot fi șterse din baza de date numai printr-o cerere explicită adresată sistemului SGBD”. Termenul “întreprindere” desemnează orice organizație independentă de natură comercială, științifică, tehnică sau de alt tip. Întreprinderea poate fi o singură persoană sau o întreagă corporație [58], [60]. Exemple: un hotel, o fabrică, o bancă, o facultate, etc. Exemple de date persistente: date despre clienți, date despre conturi, date despre studenți, date despre rezervări, etc.

„Baza de date este un ansamblu structurat de date coerente, fără redundanță inutilă, astfel încât acestea pot fi prelucrate eficient de mai mulți utilizatori într-un mod concurent”. Baza de date este un sistem integrat, coerent și partajat de fișiere [41].

– Integrat: unificare a mai multor fișiere distincte;

– Partajat: parți distincte din BD pot fi folosite de către mai mulți utilizatori;

– Coerent: se asigura caracterul neredundant și coerent al datelor;

Utilitatea și avantajele bazelor de date

Sistemul de baze de date oferă întreprinderii un control centralizat asupra datelor sale. Centralizarea datelor prezintă o serie de avantaje, cum ar fi:

– Reducerea redundanței datelor memorate: în situația în care fiecare aplicație informatică folosește fișiere proprii pentru stocarea datelor sale e posibil ca aceleași date să apară de mai multe ori în fișiere diferite aparținând unor aplicații diferite. Dacă acea dată este modificată într-un fișier aceasta trebuie modificată și în restul fișierelor pentru a nu apărea diferențe. Este recomandabil ca aplicații diferite având aceleași date să utilizeze, în comun, un singur fișier pentru memorarea acestora. Redundanța este proprietatea unor date de a se repeta fără să fie necesar [23], [42].

– Evitare inconsistenței datelor: atunci când există mai multe copii ale aceleași date este posibil, prin actualizarea doar a unora dintre ele, să avem valori diferite pentru una și aceeași dată, ceea ce atrage după sine inconsistența bazei de date.

– Posibilitatea partajării datelor: se referă la posibilitatea utilizării în comun a datelor de către mai multe aplicații precum și la posibilitatea dezvoltării unor aplicații noi folosind datele deja existente în baza de date.

– Încurajarea introducerii standardelor: administratorul bazei de date poate impune alinierea la anumite standarde, ceea ce are un rol important la transferul datelor de la o bază de date la alta.

– Posibilitatea aplicării constrângerilor de securitate: administratorul bazei de date poate introduce verificări de autorizare a accesului la date. Se pot impune restricții diferite pentru fiecare tip de acces la date, pentru fiecare dată, pentru fiecare utilizator.

– Menținerea integrității datelor: integritatea datelor reflectă cerința ca baza de date să conțină date corecte. Aceasta presupune atât consistența datelor cât și plauzibilitatea lor prin introducerea unor proceduri de validare corespunzătoare.

– Oferă suport pentru tranzacții: tranzacția este o unitate logică care presupune mai multe operații în baza de date, in particular, o serie de operații de actualizare. Ex: transferul unei sume de bani din contul A in B.

Arhitectura sistemelor de baze de date

Deoarece datele sunt reprezentate în calculator sub forma de biți iar utilizatorii bazelor de date lucrează cu concepte mai mult sau mai puțin abstracte se impune utilizarea unor nivele de abstractizare [17], [88]. Pentru asigurarea independenței fizice și logice a datelor se impune adoptarea unor arhitecturi de baze de date organizate pe trei nivele:

– Nivelul intern: este nivelul care se află cel mai aproape de mediul de stocare fizică, se referă la modul în care sunt stocate datele în sistem;

– Nivelul extern: este nivelul aflat cel mai aproape de utilizatori, se referă la modul în care sunt vizualizate datele de către utilizatori;

– Nivelul conceptual: este un nivel intermediar dintre cele două.

Independenta fizică a datelor este o măsura a imunității aplicațiilor față de modificările în structura fizică de memorare a datelor. O modificare a structurii nu va afecta aplicația iar modificările efectuate asupra aplicației nu vor afecta structura fizica de date. Pentru ca o aplicație să fie independenta față de structura fizică de date aceasta nu trebuie să conțină referiri la tipul fișierelor folosite pentru memorarea datelor, la dispozitivele de stocare a datelor sau la strategia de acces la date [42], [82].

Independența logică a datelor: se referă la imunitatea modelului propriu al fiecărui utilizator față de modificări în structura logică globală a bazei de date. Dacă se respectă independența logică a datelor se poate modifica structura bazei de date prin adăugarea unor noi unități logice (cum ar fi câmpuri, înregistrări) și se pot modifica relațiile existente între ele fără a afecta utilizatorii care nu au nevoie de aceste date. Fiecare utilizator poate să folosească datele fără a influența alți utilizatori care folosesc aceleași date.

Nivelul intern: poartă numele de bază de date fizică și este o colecție de fișiere care conțin datele fizice, la care se adaugă diverse structuri auxiliare menite să asigure accesul operativ la date (de ex. Indecși, pointeri, etc). Vederea internă este descrisă prin intermediul schemei interne [11], [126].

Nivelul conceptual: este o abstractizare a unei părți din lumea reală și constă din descrierea structurii logice a datelor dintr-o bază de date. Fiecare bază de date are un model conceptual propriu prin care sunt numite și descrise toate unitățile logice din BD, împreună cu legăturile dintre acestea. Unitățile logice sunt concepte asemănătoare celor cu care operează utilizatorii bazei de date. Ex: în descrierea unei bd a unui hotel se lucrează cu următoarele concepte: client, camera, rezervări, etc.; iar pentru o BD a unei facultăți: studenți, profesori, discipline, plan de învățământ, note, etc.

Modelul conceptual integrează viziunile tuturor utilizatorilor asupra BD și specifică constrângerile asupra datelor (ce poate face parte din bd, ce nu poate face parte din BD). Tot în modelul conceptual sunt specificate masuri de securitate și integritate referitoare la anumite unități logice. Vederea conceptuală conține o reprezentare abstractă a întregii baze de date iar vederea internă reprezintă baza de date așa cum este stocată intern. Vederea conceptuală este definită prin intermediul schemei conceptuale. Nivelul extern se referă la percepțiile utilizatorilor individuali asupra BD. Majoritatea utilizatorilor nu sunt interesați de întreaga bază de date ci doar de o parte a acesteia. Termenul tehnic folosit pentru modelul extern este acela de vedere externă. Vor exista mai multe vederi externe diferite, fiecare vedere reprezentând o anumită porțiune a bazei de date. Fiecărui utilizator sau grup de utilizatori îi corespunde un model extern propriu – ceea ce vede utilizatorul din BD sau modul în care vede acesta baza de date. Prin utilizarea vederilor se asigură securitatea bazelor de date prin limitarea accesului la date a anumitor categorii de utilizatori.

Utilizatorii au acces doar la parți bine definite din BD, existând posibilitatea ascunderii anumitor parți din baza de date pe care utilizatorii nu au voie sa le vadă. Un utilizator poate avea diferite drepturi de acces definite în cadrul a mai multe vederi. Prin unele vederi poate avea doar drept de consultare, in timp ce prin altele ar putea avea și drepturi de modificare. Prin vederi se oferă utilizatorilor o viziune individualizată și simplificata asupra bazei de date. Fiecare vedere externă este definită prin intermediul unei scheme externe. Ex: baza de date cu clienții unui hotel. Vârsta clienților este o informație care poate fi folosita pentru realizarea unor statistici, etc. Daca se memorează in baza de date vârsta clienților atunci acest câmp trebuie sa fie actualizat zilnic, de aceea se va crea o vedere in care apare definit conceptul de vârsta calculate ca diferență dintre data curentă si data nașterii. Într-o bază de date cu studenți se va defini conceptul bursier [11], [120].

Sistemul de gestiune a bazelor de date

Sistemul de gestiune a bazelor de date (SGBD) – este software-ul care tratează toate cererile de acces la baza de date.

Funcțiile pe care le îndeplinește un SGBD sunt următoarele:

– Definiția datelor: Sistemul SGBD trebuie sa fie capabil sa accepte definițiile datelor (schemele externe, schema conceptuala, schema internă) în forma-sursă și să le transforme în forma-obiect adecvata. Descrierea datelor se realizează prin intermediul limbajul de descriere a datelor – LDD.

– Manipularea datelor: sistemul SGBD trebuie sa fie capabil să manipuleze cererile de consultare, actualizare sau ștergere a datelor existente în BD sau să adauge date noi in BD. Această funcție poate fi realizată prin intermediul Limbajelor de manipulare a datelor.

– Optimizarea cererilor de acces;

– Asigurarea securității și integrității datelor;

– Refacerea datelor își asigurarea accesului concurent la date;

– Trebuie să pună la dispoziție o funcție pentru dicționarul de date.

Dicționarul conține date despre datele din BD, (denumite si metadate) – adică definiții ale unor obiecte din sistem. SGBD trebuie să îndeplinească toate sarcinile într-un mod cat mai eficient posibil. Scopul general al unui SGBD este de a furniza interfața cu utilizatorul pentru sistemul de baze de date. Interfața cu utilizatorul poate fi definită ca o graniță a sistemului, dincolo de care totul este invizibil pentru utilizator. Cele mai cunoscute SGBD-uri la ora actuală sunt: Oracle, Microsoft Sql Server, Visual FoxPro, DB2, dBase, MySql (opensource), PostgreSQL [41], [117].

Evoluția SGBD

Istoria SGBD poate fi rezumată în trei generații:

– Sisteme ierarhice și rețea;

– Sisteme relaționale;

– Sisteme avansate (orientate obiect, relaționale OO, distribuite, multimedia, etc.)

În cazul modelelor ierarhice și rețea datele sunt reprezentate la nivel de articol prin legături ierarhice sau de tip graf. Administrarea și manipularea datelor este dificilă datorită dependenței fizice a datelor. A doua generație de SGBD-uri este legată de apariția modelelor relaționale care tratează entitățile ca niște relații. S-a conturat in două articole publicate de E. F. Codd în 1969, 1970. Se poate defini printr-o serie de structuri de date (relații alcătuite din tupluri), operații aplicate asupra structurilor de date (selecție, proiecție, join), și reguli de integritate care să asigure consistența datelor (chei primare, restricții referențiale..). SGBDOO au apărut ca urmare a îmbinării tehnicii limbajelor orientate obiect cu a bazelor de date [82].

Sisteme de Gestiune a Bazelor de Date Relaționale (SGBDR)

Definirea SGBDR

SGBDR este un sistem software complet care implementeză modelul de date relațional, precum și cel puțin un limbaj relațional.

Teoria relațională este un ansamblu de concepte ,metode și instrumente care a dat o fundamentare riguroasă realizării de SGBDR performante.

Regulile lui Codd

E.F. Codd (cercetător la IBM) a formulat 13 reguli care exprimă cerințele maximale pentru ca un SGBD să fie relațional.

Regulile sunt utile pentru evoluarea performanțelor unui SGBDR.

R0. Gestionarea datelor la nivel de relație: limbajele utilizate trebuie să opereze cu relații (unitatea de informație).

R1. Reprezentarea logică a datelor: toate informațiile din BD trebuie stocate și prelucrate ca tabele.

R2. Garantarea accesului la date: LMD trebuie să permită accesul la fiecare valoare atomică din BD (tabelă, coloană, cheie).

R3. Valoarea NULL: trebuie să se permită declararea și prelucrarea valorii NULL ca date lipsă sau inaplicabile.

R4. Metadatele: informațiile despre descrierea BD se stochează în dicționar și tratează ca tabele, la fel ca datele propiu-zise.

R5. Limbajele utilizate: SGBD trebuie să permită utilizarea mai multor limbaje, dintre care cel puțin unul să permită definirea tabelelor (de bază și virtuale), definirea restricțiilor de integritate, manipularea datelor, autorizarea accesului, tratarea tranzacțiilor.

R6. Actualizarea tabelelor virtuale: trebuie să se permită ca tabelele virtuale să fie și efectiv actualizabile, nu numai teoretic actualizabile (exemplu atributul “valoare” dintr-o tabelă virtuală nu poate fi actualizat).

R7. Actualizările în baza de date: manipularea unei tabele trebuie să se facă prin operații de regăsire dar și de actulizare.

R8. Independența fizică a datelor: schimbarea stucturii fizice a datelor (modul de reprezentare (organizare) și modul de acces) nu afectează programele.

R9. Independența logică a datelor: schimbarea structurii de date (logice) a tabelelor nu afectează programele.

R10. Restricțiile de integritate: acestea, trebuie să fie definite prin LDD și stocate în dicționarul (catalogul) BD.

R11. Distribuirea geografică a datelor: LMD trebuie să permită ca programele de aplicație să fie aceleași atât pentru date distribuite cât și petru date centralizate (alocarea și localizarea datelor vor fi în sarcina SGBD-ului).

R12. Prelucrarea datelor la nivel de bază (scăzut): dacă SGBD posedă un limbaj de nivel scăzut (prelucrarea datelor se face la nivel de înregistrare), acesta nu trebuie utilizat pentru a evita restricțiile de integritate.

Caracterizarea SGBDR

Sistemele relaționale îndeplinesc funcțiile unui SGBD cu o serie de aspecte specifice care rezultă din definirea unui SGBDR.

Caracterizarea SGBDR se poate face pe două niveluri :

– Global, unde sistemele relaționale sunt privite ca o categorie distinctă de SGBD.

– Particular, unde fiecare SGBDR are aspecte individuale comparativ cu altele similare [11], [41].

Caracterizarea globală a SGBDR:

Câteva dintre mecanismele și instrumentele care, după modul cum sunt implementate, ajută la caracterizarea globală a SGBDR-urilor sunt:

a) Limbajele relaționale

b) Protecția datelor

c) Optimizarea cererilor de regăsire

d) Utilitarele specializate

Limbajele relaționale

SGBDR oferă seturi de comenzi pentru descrierea și manipularea datelor. Acestea pot fi incluse într-un singur limbaj relațional (cazul cel mai întâlnit) sau separate în LDD și LMD. În ambele situații, comenzile pentru definirea datelor sunt distincte de cele pentru manipularea datelor [63], [64].

Exemple de limbaje relaționale: SQL (Structured Querry Language-standarde începând cu 1985), QUEL, QBE, SQUARE, ALPHA, ISBL.

Limbajele relaționale de definire a datelor (LDD)

– Aceste limbaje sunt simplificate, cu puține comenzi.

– Descrierea datelor este memorată în BD, sub formă de tabele, în dicționarul (metabaza) bazei de date.

– Facilități de descriere sunt prezente în SGBDR prin comenzi, care definesc anumite operații, la nivelurile: conceptual, logic, fizic [42], [56].

La nivel conceptual

• Crearea unei BD: CREATE DATABASE

Unele sisteme suportă noțiunea explicită de BD (Oracle, VFP, Ingres) altele nu

• Ștergerea unei BD: DROP DATABASE

• Crearea tabelelor de bază: CREATE TABLE

• Ștergerea tabelelor de bază: DROP TABLE

• Crearea de sinonome: CREATE SYNONYM

Sinonimele sunt alternative (de obicei prescurtate) la numele unor tabele.

• Ștergerea sinonimeleor : DROP SYNONYM

• Actualizarea structurii unei tabele : ALTER TABLE cu opțiunile ADD, MODIFY (nu are opțiuni de ștergere)

• Adăugarea restricțiilor de integritate : ASSERT ON

Restricțiile de integritate se declară la cererea tabelelor .Ele pot fi ulterior actualizate în sens de adăugare (comanda ASSERT) sau ștergere (opțiunea DROP din comanda ALTER TABLE). În Oracle restricțiile sunt: NULL, CHECK, pe cheie (PRIMARY , UNIQUE, REFERENTIAL -cheie externă) [120].

La nivel logic

• Crearea tabelelor virtuale: CREATE VIEW

Tabelele virtuale (viziunile) reprezintă, la nivel logic, modul cum “vede” un utilizator, la un moment dat, o bază de date. O viziune este de fapt o comandă SELECT memorat în dicționarul BD și apelată apoi de utilizator.

• Ștergerea tabelelor virtuale: DROP VIEW.

• Acordarea drepturilor de acces la BD:

GRANT CONNECT – conectarea la BD a unui utilizator.

GRANT drepturi – acordarea unor drepturi de acces (pentru regăsire, actualizare etc).

• Retragerea drepturilor de acces la BD:

REVOKE drepturi – retragerea unor drepturi

REVOKE CONNECT – deconectarea unui utilizator de la BD

La nivel fizic

• Crearea indecșilor: CREATE INDEX

Indexarea se folosește în BD pentru accesul la date ordonate și pentru accesul direct după cheie. În unele sisteme (exemplu Oracle), dacă la creare s-a declarat cheie primară atunci sistemul creează automat index.

• Ștergerea indecșilor: DROP INDEX

• Controlul alocării spațiului fizic al BD:

CREATE PARTITION –crearea unei partiții

ALTER PARTITION –actualizare a unei partiții cu fișiere.

CREATE SPACE –creează un model de alocare a spațiului fizic pentru o BD (bun pentru optimizări)

ALTER SPACE –actualizarea modelului de alocare

DROP SPACE –șterge un model de alocare

• Regruparea fizică a datelor dintr-o BD (clustere pentru acces rapid la date):

CREATE CLUSTER – creează un cluster dintr-o BD

ALTER CLUSTER– actualizează un cluster

DROP CLUSTER – șterge un cluster

Limbajele relaționale de manipulare a datelor (LMD)

Aspectele care pot caracteriza LMD sunt diverse și din acest motiv, le putem grupa în trei categorii:

– generale

– funcționale

– calitative

Caracterizarea generală a LMD:

Modul de tratare a datelor – toate LMD relaționale realizează o tratare la nivel de ansamblu a datelor: unitatea de informative pentru lucru este tabela. Avantajele sunt date de :

– posibilitatea gestionării automat a tuplurilor duplicate;

– prelucrarea paralelă a asamblurilor.

La comunicarea unui LMD relational cu un limbaj universal, avantajele se pierd deoarece comunicarea se poate face doar tuplu cu tuplu și nu la nivel de ansamblu. Deoarece limbajele universale oferă alte avantaje legate de proceduralitate, soluția este de a integra în acestea un limbaj relațional [23], [30], [65].

Cursorul este soluția în SGBDR pentru a face trecerea de la tratarea la nivel de ansamblu la cea la nivel de înregistrare (tuplu).

CURSOR crs1 is …– se crează un pointer spre tuplurile ansamblului (tabelei).

FETCH – transmite un tuplu indicat printr-un cursor, către program și deplasează cursorul spre urmatorul tuplu.

Operatorii relaționali implementați – SGBDR s-au dezvoltat, din punct de vedere relațional, având la bază:

• calculul relațional orientat pe tuplu (ALPHA, QUEL).

• calculul relațional orientat pe domeniu (QBE).

• algebra relațională (ISBL)

• transformarea (mapping) (SQL, SQUARE)

Limbajele bazate pe calculul relațional sunt neprocedurale, cele bazate pe algebra relațională sunt procedurale, celelalte sunt combinații.

Realizatorii limbajelor relaționale s-au orientat pe domenii precise din teoria relațională. Astfel, au rezultat: limbaje relaționale standardizate internațional (exemplu SQL – ANSI), limbaje cu standard de utilizare impus de constructor (exemplu QUEL), limbaje nestandardizate (celelalte limbaje relaționale).

Utilizatorii limbajelor relaționale sunt mult diversificați. SGBDR oferă atât elemente procedurale (pentru specialiști) cât și neprocedurale (pentru nespecialilști) [94], [98], [104].

Caracterizarea funcțională a LMD:

Facilități de interogare a datelor. Acestea sunt puternice și oferite prin comenzi pentru:

• Interogarea tabelelor de bază (exemlu SELECT)

• Interogarea tabelelor virtuale (exemplu SELECT)

Facilităti de actualizare a datelor.

• Actualizarea tabelelor de bază

INSERT INTO – adaugă rânduri la sfârșitul unei tabele.

UPDATE – modifică rânduri dintr-o tabelă.

DELETE FROM – șterge rânduri dintr-o tabelă.

• Actualizarea tabelelor virtuale (la fel ca mai sus).

Unele SGBDR nu permit actualizarea tabelelor virtuale (ex. Foxpro 2.x), altele permit acces lucru cu o serie de restricții pentru ca operația să se propage spre tabelele de bază fără ambiguități (exemplu DB2, Oracle) [11].

Alte facilități funcționale – la facilitățile relaționale de mai sus, SGBDR-urile oferă și alte facilități pe care le au toate limbajele de programare procedurale:

• Calculul aritmetic prin operatorii specifici: +, -, *, /, **

• Agregarea: prin funcții standard (exemplu SUM), prin comenzi (exemplu COMPUTE OF expr ).

• Comenzi de intrare/ieșire standard: ACCEPT…PROMPT…

Caracterizarea calitativă a LMD:

Puterea selectivă a LMD relaționale este dată de posibilitatea selectării datelor după criterii (filtre) complexe (exemplu comanda SELECT).

Ușurința de învățare și utilizare este nuanțată în funcție de tipul LMD-ului relațional

• Cele bazate pe calculul relațional sunt neprocedurale (descriptive), deci ușor de învățat și utilizat (apropiat, ca stil, de limbajul natural) (exemplu QUEL).

• Cele bazate pe algebra relațională sunt procedurale (algoritmice), deci mai greu de învățat și utilizat (exemplu ISBL).

• Cele intermediare promovează stilul neprocedural dar acceptă și elemente de control procedural (exemplu SQL).

• Cele bazate pe grafică oferă primitive grafice pentru machetarea cererilor de regăsire, deci ușor de utilizat (exemplu QBE).

Eficacitatea utilizării este determinată de posibilitatea optimizării cererilor de regăsire.

– LMD bazate pe calculul relațional lasă compilatorul să aleagă ordinea de execuție a operațiilor, deci rezultă o eficiența mare.

– LMD bazate pe algebra relațională au o ordine impusă pentru execuția operațiilor, deci rezultă o eficiență mica [42], [56].

Protecția datelor

Aspectele privind protecție a datelor sunt foarte importante pentru un sistem de bază de date și ele trebuie asigurate (implementate) de către SGBD. Protecția bazei de date se referă la integritatea datelor (integritatea semantică, concurența la date, salvarea/restaurarea) și securitatea datelor (autorizarea accesului, viziunile, procedurile speciale, criptarea). Dintre toate aceste aspecte, ne vom ocupa aici, pe scurt, doar de integritatea semantică și de concurența la date.

Integritatea semantică

Definirea restricțiilor de integritate se face, conform cerințelor modelului relațional, în LDD (exemplu CREATE TABLE, ALTER TABLE).

Utilizarea restricțiilor de integritate se face cu ajutorul unor mecanisme care controlează validitatea regulilor pentru fiecare nouă stare a BD. Aceste mecanisme sunt:

• metode de detectare a inconsistenței datelor (se verifică restrcițiile de integritate) la sfârșitul tranzacțiilor, care se realizează automat de SGBDR;

• puncte de verificare a integrității fixate de utilizator, acolo unde dorește el în program.

Concurența la date (coerența)

Unitatea de lucru pentru asigurarea coerenței datelor este tranzacția. Aceasta este un ansamblu de comenzi tratate unitar. Tranzacția se execută în totalitate sau deloc.

Coerența poate fi afectată la actualizarea concurentă sau la incidente. Mecanismele utilizate de SGBDR pentru asigurarea coerenței datelor (controlul accesului concurent) sunt:

• blocarea la diferite niveluri: bază de date, tabelă, tuplu, atribut;

• definirea unor puncte de salvare în interiorul tranzacțiilor (exemplu comanda SAVEPOINT);

• tranzacții explicite (exemplu, Begin și End Tranzaction ) și implicite (exemplu, comenzile de actualizare);

• fișiere jurnal.

Optimizarea regăsirii

Cererile de regăsire se exprimă în SGBDR în diferite limbaje relaționale. Pentru a se obține un rezultat optim, se utilizează interfețe automate de rescriere a cererilor de regăsire, prin parcurgerea a doi pași:

Exprimarea cererilor de regăsire sub forma unor expresii algebrice relaționale, care are la bază echivalența dintre calculul și algebra relațională .

• Aplicarea unor transformări algebrice relaționale asupra expresiilor construite în pasul anterior, pentru a se obține expresii relaționale echivalente și eficiente.

Transformarea se poate realiza prin doua strategii de optimizare: generale, specifice.

– Generale, care sunt independente de modul de memorare a datelor. Ele se bazează pe propietățile operațiilor din algebra relațională (comutativitatea, asociativitatea, compunerea). Astfel de strategii sunt:

– Selecția înaintea joncțiunii

– Proiecția înaintea joncțiunii

– Selecția înaintea proiecției

– Combinarea selecției multiple

– Specifice, care țin cont de modul de memorare a datelor și ele sunt caracteristice unui SGBDR. Elementele care influențează executarea operațiilor ce intervin la o cerere de regăsire sunt: accesul direct, reguli de ordonare a expresiilor algebrice specifice unui SGBDR [66], [95], [117].

Utilitarele specializate

Posibilitatile de utilizare ale unui SGBDR sunt influențate de utilitarele specializate pe care le are, pentru diferitele categorii de utilizatori (exemplu în Oracle: Developer pentru dezvoltatori, Designer pentru analiști, Administration Tools și Utilities pentru administrator etc.).

Caracterizarea particulară a SGBDR:

Pentru a putea caracteriza un anumit SGBDR particular, vom lua în considerare o serie de criterii de comparație. Aceste criterii se vor urmări, grupate pe anumite categorii, pentru câteva SGBDR-uri. După această analiză va exista un argument serios pentru a putea alege un SGBDR în scopul dezvoltării unei aplicații cu baze de date. Gruparea caracteristicilor particulare de comparație a SGBDR-urilor o vom face funcție de:

– Facilitățile de descriere a datelor ;

– Facilitățile de manipulare a datelor ;

– Facilitățile de utilizare și administrare a datelor.

Se obeservă că gruparea caracteristicilor s-a facut după funcțiile oricărui SGBD

a) Caracteristici funcție de facilitățile de descriere:

• modul de implementare a modelului relațional;

• conceptul de bază de date utilizat în schema;

• definirea metadatelor;

• definirea relațiilor virtuale;

• actualizarea schemei relației;

• restricții de integritate ce pot fi declarate.

b) Caracteristici funcție de facilitățile de manipulare:

• LMD relațional implementat ;

• calcul aritmetic și funcții agregate ;

• moduri de acces la date;

• programare orientată pe obiecte/vizuală;

• tratarea valorii null;

• optimizarea cererilor de regăsire ;

• actualizarea relațiilor de bază și virtuale.

c) Caracteristici funcție de facilitățile de utilizare și administrare:

• dezvoltatoare (generatoare) de diferite tipuri (ecrane, rapoarte, aplicații etc.);

• elemente de CASE (proiectare);

• analize statistice;

• acces de la distanță ;

• utilitare de întreținere;

• mecanisme pentru autorizarea accesului la date.

Exemple de SGBDR

ORACLE – realizat de firma Oracle Corporation USA. Produs complet relațional, robust, bazat pe SQL standard extins, extensie orientată obiect, arhitectura client/server, lucrul distribuit, BD Internet, optimizator de regăsire.

DB2 – realizat de firma IBM, bazat pe SQL, optimizator de regăsire, respectă teoria relațională, lucrul distribuit, robust.

INFORMIX – realizat de firma Informix, respectă teoria relațională, lucru distribuit, robust.

PROGRESS – realizat de firma Progress Software, are limbaj propiu (Progress 4GL), suportă SQL, rulează pe o gamă largă de calculatoare sub diferite sisteme de operare.

SQLServer – realizat de firma Microsoft, bazat pe SQL, rulează în arhitectura client/server.

INGRES II – realizat de firma Computer Associates, este un SGBDR complet, implementează două limbaje relaționale (întâi Quel și apoi SQL), este suportat de diferite sisteme de operare (Windows, VMS, UNIX), lucrează distribuit în arhitectura client/server, extensie cu facilități orientate obiect, permite aplicații tip Internet, protecția ridicată a datelor, organizarea fizică a tabelelor se face prin sistemul de operare, are numeroase componente.

VISUAL FOXPRO – realizat de firma Microsoft, are un limbaj procedural propiu foarte puternic, extensie orientată obiect, programare vizuală, nucleu extins de SQL.

ACCESS – realizat de firma Microsoft, bazat pe SQL, are limbajul procedural gazdă (Basic Access), are generatoare puternice.

PARADOX – realizat de firma Borland, are limbaj procedural propiu (PAL) și suportă SQL [41], [96], [120].

Avantajele și limitele sistemelor relaționale:

Avantaje

– Simplitatea conceptelor și a schemei .

– Teoria relațională oferă un solid suport teoretic și o bază pentru cercetări ulterioare.

– Un grad mare de independență a datelor față de programe.

– Limbajele relaționale declarative (de nivel înalt) cu o mare putere de regăsire.

– Ameliorarea semnificativă a protecției datelor, sub toate aspectele.

– Optimizarea semnificativă a accesului la date, precum și a alocării datelor.

– Manipularea de ansambluri de date prin operatorii din calculul sau algebra relațională, cu implicații importante pentru regăsirea datelor.

Limite

– Prea marea simplitate a modelului relațional, care pentru tipurile noi de apllicații (Internet, sisteme deschise etc.) conduce la:

• Pierderea unor informații semantice utile (prin multiplicarea tabelelor la normalizare );

• Operațiile relaționale, chiar optimizate, sunt costisitoare (noile aplicații generează multe operații relaționale) din punct de vedere al resurselor de calcul.

LMD relaționale sunt prea limitate, ceea ce generează disfuncționalități :

• Programatorul trebuie să cunoască două tipuri de limbaje (declarativ – relațional și procedural – universal). De aici rezultă necesitatea conversiilor, o fiabilitate scăzută, necesitatea comunicării, productivitatea scăzută [11], [23], [97].

• Mecanismele de optimizare privesc doar LMD relațional, deci ceea ce este scris în limbaj procedural trebuie optimizat de către programator.

1.3. Prezentarea SGBD-ului ORACLE

Oracle este un sistem de gestiune a bazelor de date complet relațional, extins, cu facilități din tehnologia orientată obiect (OO). Sistemul Oracle este realizat de firma Oracle Corporation care a fost înființată în anul 1977 în SUA – California și acum este cel mai mare furnizor de software de gestiunea datelor. Acesta este operațional pe toată gama de calculatoare (micro, mini, mainframe) sub diverse sisteme de operare. Prima versiune de SGBD Oracle a fost realizată la sfârșitul anilor '70 respectând teoria relațională. În cadrul sistemului a fost implementat de la început limbajul relațional SQL pe care l-a dezvoltat ulterior față de versiunea standard rezultând SQL*Plus. Începând cu versiunea 5.0 SGBD Oracle are următoarele facilități suplimentare: funcționează în arhitectura client/server; are limbaj procedural propriu PL/SQL; are precompilatoare ca interfață cu limbajele universale. În iunie 1997 s-a lansat SGBD Oracle versiunea 8.0, care a marcat o nouă generație de baze de date Oracle deoarece inițiază trecerea de la arhitectura client/server la arhitectura NC (Network Computing), are o mare deschidere, are optimizări performante și pune accent mai mare pe analiză (modelare-funcționalitate) față de programare (codificare) [7], [22], [31]. În noiembrie 1998 s-a lansat SGBD Oracle 8i ca sistem de baze de date pe Internet. Această versiune are următoarele caracteristici:

• Este reproiectat arhitectural în mod fundamental și se încadrează în tendința de trecere de la arhitectura client/server la arhitectura NC;

• Permite dezvoltarea unei baze de date de orice dimensiune, în mod centralizat sau distribuit;

• Are facilități de salvare/restaurare automate și inteligente;

• Permite partiționarea integrală pentru tabele și indecși;

• Are mesagerie integrală, prin comunicarea între aplicații și procesare offline (chiar dacă aplicațiile nu sunt conectate);

• Prelucrarea paralelă pentru: replicare, cereri de regăsire, actualizare;

• Oferă facilități din tehnologia OO, prin care se permite definirea și utilizarea de obiecte mari și complexe;

• Optimizează cererile de regăsire prin reutilizarea comenzilor SQL identice lansate de utilizatori diferiți și prin realizarea unui plan de execuție a instrucțiunilor SQL;

• Are un grad de securitate sporit prin: server de criptare, control trafic rețea, niveluri de parolare etc.;

• Permite lucrul cu depozite de date (Data Warehouse) care conțin date multidimensionale (cu tehnologia OLAP);

• Conține foarte multe produse ceea ce-l face să fie o platformă pentru baze de date: servere (Oracle 8, Application, Security, Internet Commerce etc), instrumente (Designer, Developer, Express, WebDB etc), aplicații (Financials, Projects, Market Manager, Manufacturing etc);

• Este primul SGBD pentru Internet cu server Java inclus;

• Reduce drastic costurilor pentru realizarea unei aplicații(de cca 10 ori față de versiunea anterioară);

• Este o platformă multiplă permițând lucrul pe orice calculator, orice sistem de operare, orice aplicație, orice utilizator;

• Are instrumente diverse pentru dezvoltarea aplicațiilor: bazate pe modelare (Designer, Developer, Application Server), bazate pe componente (Java), bazate pe HTML (browsere, editoare Web) și XML, prin programare: proceduri stocate (PL/SQL, Java), obiecte standard, obiecte ODBC, obiecte JDBC, fraze SQL etc., tip internet (WebDB);

• Oferă servicii multiple de Internet (Web, E_mail, e_bussines, etc) integrate cu servicii Intranet [16], [23].

Ulterior a fost lansat sistemul Oracle 9i care a marcat trecerea la o nouă generație de servicii internet. El este mai mult decât un suport pentru baze de date deoarece oferă o infrastructură completă de software pentru afaceri electronice (e-business) și rulează pe o varietate de sisteme de calcul și de operare: SUN-SOLARIS, HP-UX, IBM-AIX, PC_WINDOWS, XX-LINUX. Componenta Oracle WebDB a evoluat în Oracle Portal. Oracle 9i DATABASE are față de versiunea anterioară asigură o protecție ridicată și automatizată iar costul administrării bazei de date scade în mod drastic. Oracle 9i REAL APPLICATION CLUSTERS (RAC) se bazează pe o nouă arhitectură de BD numită îmbinare ascunsă (Cache Fusion). Aceasta este o nouă generație de tehnologie de clustere. Conform acestei arhitecturi la adăugarea unui calculator înr-o rețea cu BD Oracle, clusterele se adaptează automat la noile resurse, fără să fie necesară redistribuirea datelor sau rescrierea aplicației. Posibilitatea apariției unei erori la o configurație cu 12 calculatoare sub Oracle 9i RAC este foarte mică, esimată ca durată în timp la cca 100.000 de ani. În Oracle 9i APPLICATION SERVER se pot creea și utiliza aplicații Web care sunt foarte rapide și permit integrarea serviciilor de Internet. Oracle 9i DEVELOPER SUITE este un mediu complet pentru dezvoltarea aplicațiilor tip afaceri electronice (e-business) și tip Web. El se bazează pe tehnologiile Java și XML și permite personalizarea (Oracle Personalization). În anul 2003 a fost lansată versiunea Oracle 10g care adaugă noi facilități sistemului Oracle 9i [25], [26].

Arhitectura Sistemului ORACLE

Componentele care formează arhitectura de bază Oracle sunt dispuse într-o configurație client/server. Aceste componente sunt plasate pe calculatoare diferite într-o rețea asigurând funcționalități specifice, astfel: serverul asigură memorarea și manipularea datelor, precum și administrarea bazei de date iar clientul asigură interfața cu utilizatorul și lansează aplicația care accesează datele din baza de date.

Fig. 1.3.1 – Arhitectura Oracle

Arhitectura Oracle se încadrează în tendințele actuale și anume este structurată pe trei niveluri: nucleul, interfețele și instrumentele de întreținere [16], [27], [31].

Nucleul Oracle conține componentele care dau tipul relațional pentru SGBD Oracle: limbajul relațional de regăsire SQL și limbajul procedural propriu PL/SQL.

Sistemul Oracle creează și întreține automat dicționarul de date. Acesta face parte din baza de date Oracle și conține un set de tabele și viziuni (vederi) accesibile utilizatorilor doar în consultare. Dicționarul conține informații de tipul: numele utilizatorilor autorizați, drepturile de acces, numele obiectelor din baza de date, structurile de date, spațiul ocupat de date, chei de acces etc.

Interfețele sunt componentele care permit dezvoltarea aplicațiilor cu BD, astfel:

• DEVELOPER SUITE este componenta destinată dezvoltatorilor (programatorilor) de aplicații. Conține generatoarele FORMS (meniuri și videoformate), REPORTS (rapoarte și grafice), JDEVELOPER;

• DESIGNER este componentă destinată analiștilor/proiectanților de aplicații. Oferă elemente de CASE pentru proiectarea aplicațiilor cu BD;

• PRO*C este componenta destinată programatorilor în limbajele de programare universale (FORTRAN, COBOL, Pascal, C, ADA, PL1);

• DATAWAREHOUSE BUILDER este destinat analizei datelor multidimensionale, folosind tehnologia de tip OLAP (On Line Analitical Processing);

• ORACLE APPLICATIONS permite dezvoltarea unor aplicații de întreprindere (Financials, Manufacturing, Projects etc.);

Instrumentele sunt componente destinate întreținerii și bunei funcționări a unei BD Oracle. ENTERPRISE MANAGER CONSOLE conține mai multe utilitare destinate administratorului BD (deschidere/închidere BD, autorizarea accesului, refacerea BD, conversii de date, etc.).

ORACLE Server

Oracle Server (OS) permite managementul informațiilor organizate în baze de date, astfel încât se asigură accesul mai multor utilizatori în mod concurențial la același date, oferind facilități de prevenire a accesului neautorizat și de restaurare a datelor după producerea unor erori. OS are următoarele facilități:

• Client/server permite ca prelucrările să fi împărțite între serverul de baze de date și programele de aplicație ale utilizatorilor aflate pe stațiile conectate la server;

• Suportă lucrul cu baze de date foarte mari;

• Permite utilizarea concurențială a bazelor de date;

• Oferă securitate sporită și integritatea datelor;

• Permite lucrul distribuit;

• Conferă portabilitate aplicațiilor;

• Permite ca mai multe tipuri de calculatoare și sisteme de operare să coexiste pe aceeași rețea.

Oracle Server este un sistem relațional-obiectual de management a bazelor de date, care permite o abordare deschisă, integrată și cuprinzătoare a managementului informațiilor. OS constă dintr-un cuplu format dintr-o bază de date și o instanță Oracle. O bază de date Oracle este o colecție unitară de date, având o structură logică și una fizică putând avea două stări: open (accesibilă) și close (inaccesibilă).

Structura logică ale unei baze de date este formată din tabelele spațiu (tablespaces), schema de obiectelor bazei de date, blocurile de date, extensiile și segmentele.

Tabelele spațiu sunt unitățile logice de memorie în care este împărțită o bază de date și pot fi tabele spațiu de sistem și tabele spațiu de utilizator. Din punct de vedere al accesibilității aceste pot fi on line și off line.

Fișierele de date sunt structurile de memorie specifice unui sistem de operare pe care rezidă tabelele spațiu ale unei baze de date.

Schema este o colecție de obiecte, iar schema de obiecte este o structură logică ce se referă direct la datele unei baze de date(tabele, vederi, secvențe, proceduri memorate, sinonime, indecși, clustere și link-uri de bază de date) [25], [45], [99].

Blocurile de date, extensiile și segmentele sunt elemente de control eficient al spațiului de memorie externă pe disc aferent unei baze de date.

Blocul de date este unitatea de memorie cea mai mică manipulată de SGBD Oracle, iar mărimea acestuia măsurată în bytes se definește la momentul creerii bazei de date.

Extensia este format din mai multe blocuri de date contigue. Segmentul este format din mai multe extensii. Segmentele pot fi: segmente de date (pentru memorarea datelor unei tabele), segmente de indecși, segmente roollback (folosite pentru memorarea informațiilor necesare pentru recuperarea datelor unei baze de date sau anularea unei tranzacții) și segmente temporare (folosite pentru prelucrarea instrucțiunilor SQL) [37], [122].

Structura fizică este definită de un set de fișiere specifice sistemului de operare pe care rezidă SGBD Oracle, folosite pentru memorarea structurilor logice ale bazei de date și pentru păstrarea unor informații tehnice de control. Aceste fișiere sunt: fișiere de date (Data files), fișiere Redo log (Redo Log files) și fișiere de control (Control files).

Fișierele de date (Data files) conțin datele unei baze de date, sub forma structurilor logice ale acesteia (tabele, vederi, secvențe, proceduri memorate, sinonime, indecși, clustere și link-uri de bază de date). Fișierele de date au următoarele caracteristici: un fișier de date poate aparține unei singure baze de date, pot fi extinse automat în anumite momente specifice ale funcționării bazei de date, unul sau mai multe fișiere de date pot memora o tabelă spațiu.

Fișierele Redo Log (Redo Log files) sunt folosite pentru memorarea tuturor schimbărilor de date produse asupra unei baze de date, astfel încât dacă se întâmplă o cădere de curent să se prevină distrugerea datelor bazei de date. Se pot folosi simultan mai multe fișiere de acest fel care să rezide pe discuri diferite.

Fișierele de control (Control files) sunt folosite pentru memorarea informațiilor necesare pentru controlul structurii fizice a unei baze de date (numele bazei de date, numele și locațiile fișierelor de date, data creerii bazei de date etc).

Instanța Oracle (Oracle instance) este combinația logică dintre structurile de memorie internă (SGA – system global area, PGA – program global area) și procesele Oracle de bază activate la momentul pornirii unei baze de date.

SGA este o regiune partajabilă de memorie care conține datele și informațiile necesare unei instanțe Oracle și conține:

• Database Buffer Cache (conține blocurile de date cele mai recent utilizate pentru a reduce utilizarea discului);

• Redo Log Buffer (conține datele despre blocurile modificate);

• Shared Pool (pentru prelucrarea instrucțiunilor SQL);

• Cursorii (Statement Handles or Cursores) folosiți pentru manipularea instrucțiunilor unui limbaj gazdă folosind facilitatea Oracle Call Interface [26], [117].

PGA este zona de memorie care conține datele și informațiile de control ale unui proces server.

Procesul este un mecanism al sistemului de operare care poate executa o serie de pași (instrucțiuni). Este cunoscut și sub numele de job sau task. Procesul are propria sa zonă de memorie în care se execută. Un server Oracle are două tipuri de procese: procese utilizator și procese Oracle.

Procesul utilizator (user proces) este creat și menținut pentru a executa codul de program aferent unui anumit limbaj (C++) sau un produs Oracle (Oracle tool), SQL*Forms, Sql*Graphics etc.

Procesul Oracle este apelat de către un alt proces pentru a executa funcția cerută de către acesta. Procesele Oracle sunt Procese server și procese background.

Procesele server (Server Processes) sunt utilizate de Oracle pentru a prelucra cererile proceselor utilizator. Oracle poate fi configurat astfel încât să permită unul sau mai multe procese utilizator. Din acest punct de vedere avem servere dedicate care au un singur proces utilizator și servere multi prelucrare (multi-threaded server configuration). Pe anumite sisteme procesele utilizator și procesele server sunt separate, iar în altele sunt combinate într-unul singur. Dacă folosim sistemul multi prelucrare sau dacă procesele utilizator și procesele server se află pe mașini diferite atunci aceste procese trebuie să fie separate. Sistemul client/server separă procesele utilizator de către procesele server și le execută pe mașini diferite.

Procesele background (Background processes) sunt create pentru fiecare instanță Oracle pentru a executa asincron anumite funcții. Acestea sunt:

• Database Writer (DBWR) scrie datele modificate în baza de date;

• Log Writer (LGWR) scrie înregistrările redo log pe disc;

• Checkpoint (CKPT) scrie înregistrările checkpoint la timpul potrivit ;

• System Monitor (SMON) execută recuperarea unei instanțe la momentul pornirii, colectează spațiul liber etc;

• Process Monitor (PMON) recuperează procesele utilizator dacă acestea cad accidental;

• Archiver (ARCH) copiază în mod online fișierele Redo Log în fișiere de arhivă atunci când acestea se umplu cu datei;

• Recoverer (RECO) rezolvă tranzacțiile suspendate în sistemul cu baze de date distribuite;

• Dispacher (Dnnn) folosit în sistemul multithreaded;

• Lock (LCKn) blocheză procesele în sistemul Parallel server [16].

Legătura dintre procesele utilizator și procesele Oracle este prezentată în figura următoare:

Fig. 1.3.2 – Legătura dintre procesele utilizator și procesele Oracle

Interfața program este mecanismul de comunicare dintre un proces utilizator și un proces server. Este metoda standard de comunicare între o aplicație sau un instrument Oracle și Oracle Server.

Concurența, consistența și securitatea datelor

Într-un sistem de baze de date de tip multiutilizator o preocupare principală este asigurarea accesului concurențial al mai multor utilizatori la aceleași date. Pentru această funcție Oracle folosește diverse mecanisme ca blocarea înregistrărilor și păstrarea mai multor versiuni consistente de date.

Consistența la citire garantează că setul de date văzut de către o instrucțiune nu se schimbă în timpul executării acesteia (consistență la nivel de instrucțiune). Asigură faptul că un utilizator care accesează baza de date nu așteaptă ca alt utilizator să scrie date sau să citească date și că scrierea unor date în baza de date nu implică un timp de așteptare pentru utilizatorii care doresc să citească aceste date. De asemenea, asigură faptul că un utilizator va aștepta la momentul scrierii în baza de date numai dacă încearcă să modifice același rând dintr-o tabelă (tranzacții concurente).

Mecanismul de blocare a rândurilor dintr-o tabelă a bazei de date asigură ca datele văzute de un utilizator sau modificate de acesta să nu poată fi modificate de către alt utilizator până când primul nu termină accesul la date. Datele și structurile unei baze de date reflectă corect toate modificările efectuate într-o anumită secvență logică. Blocarea se poate executa automat sau manual [16], [23], [100].

Securitatea unei baze de date presupune asigurarea unor facilități care să permită controlul asupra modului în care o bază de date este accesată și utilizată. Ea poate fi: securitatea sistemului (System security) și securitatea datelor (Data security).

Securitatea sistemului include mecanisme care controlează accesul și utilizarea bazei de date la nivel de sistem (validează combinațiile username/password, spațiul pe disc alocat pentru un anumit utilizator, limitele de resurse pentru un utilizator).

Utilizatorii bazei de date și schemele.

Fiecare bază de date are o listă de nume de utilizatori. Pentru a accesa baza de date un utilizator trebuie să folosească o aplicație și să se conecteze cu un nume potrivit. Fiecărui nume de utilizator îi este asociată o parolă. Orice utilizator are un domeniu de securitate care determină privilegiile și rolurile, cota de tabelă spațiu alocată (spațiul pe disc alocat) și limitele de resurse ce le poate utiliza (timp CPU etc).

Privilegiul este dreptul unui utilizator de a executa anumite instrucțiuni SQL. Privilegiile pot fi: privilegii de sistem și privilegii de obiecte. Privilegiile de sistem permit utilizatorilor să execute o gamă largă de instrucțiuni SQL, ce pot modifica datele sau structura bazei de date. Aceste privilegii se atribuie de obicei numai administratorilor bazei de date. Privilegiile de obiecte permit utilizatorilor să execute anumite instrucțiuni SQL numai în cadrul schemei sale, și nu asupra întregii baze de date. Acordarea privilegiilor reprezintă modalitatea prin care acestea pot fi atribuite utilizatorilor. Există două căi de acordare explicit (privilegiile se atribuie în mod direct utilizatorilor) și implicit (prin atribuirea acestora unor roluri, care la rândul lor sunt acordate utilizatorilor) [25], [26].

Rolurile sunt grupe de privilegii, care se atribuie utilizatorilor sau altor roluri. Rolurile permit:

• Reducerea activităților de atribuire a privilegiilor. Administratorul bazei de date în loc să atribuie fiecare privilegiu tuturor utilizatorilor va atribui aceste privilegii unui rol, care apoi va fi disponibil utilizatorilor;

• Manipularea dinamică a privilegiilor. Dacă se modifică un privilegiu de grup, acesta se va modifica în rolul grupului. Automat modificarea privilegiului se propagă la toți utilizatorii din grup;

• Selectarea disponibilităților privilegiilor. Privilegiile pot fi grupate pe mai multe roluri, care la rândul lor pot fi activate sau dezactivate în mod selectiv;

• Proiectarea unor aplicații inteligente. Se pot activa sau dezactiva anumite roluri funcție de utilizatorii care încearcă să utilizeze aplicația.

Setarea cotelor de memorie ce pot fi folosite de către utilizatori se realizează folosind opțiunile:

• Default tablespace. Un utilizator poate crea obiecte ale bazei de date fără a specifica numele tabelei spațiu în care să fie create obiectele;

• Temporary tablespace. Unui utilizator i se alocă tabele spațiu proprii în care să-și creeze obiectele;

• Tablespace quotas. Se pot seta limite fizice de memorie pentru tabelele spațiu proprii utilizatorilor.

Profilurile și limitarea resurselor.

Un profil este un element de securitate care permite manipularea resurselor ce pot fi alocate utilizatorilor. Resursele ce pot fi alocate sunt: numărul sesiunilor concurente, timpul CPU, timpul de utilizare a unei sesiuni, restricții în utilizarea parolelor. Se pot crea diferite tipuri de profile care apoi vor fi atribuite fiecărui utilizator.

Auditarea permite monitorizarea activităților executate de către utilizatori astfel încât să se poată efectua investigații referitoare la utilizările suspecte ale bazei de date. Auditarea se poate efectua la nivel de instrucțiune, privilegiu sau obiect.

Dicționarul de date (DATA DICTIONARY)

Fiecare bază de date Oracle are un dicționar de date, care este un set de tabele și vederi folosite în modul read-only pentru a referi datele bazei de date. Dicționarul de date este actualizat automat de către Oracle ori de câte ori intervin modificări în structura bazei de date. Dicționarul de date este alcătuit din tabele de bază și vederi create pe aceste tabele. Tabelele de bază nu sunt accesibile datorită faptului că memorează datele criptic. Proprietarul dicționarului de date este utilizatorul SYS. Nici un utilizator nu poate altera obiecte din schema SYS. Dicționarul de date (DD) este accesat în două situații: ori de câte ori Oracle prelucrează o instrucțiune DDL sau de către orice utilizator pentru consultarea informațiilor despre baza de date. DD este adus în memoria SGA. Este recomandat să nu se obiecte care să aparțină utilizatorului SYS. Nu se vor modifica niciodată date din DD. Singura tabelă care face excepție este tabela SYS.AUDIS. Această tabelă poate crește mult în dimensiune, administratorul bazei de date putând șterge datele inutile [26], [89].

Vederile DD sunt prefixate cu USER, ALL sau DBA. Vederile prefixate cu USER furnizează informații despre obiectele utilizatorilor, cele ALL despre toate obiectele din baza de date la care un utilizator are acces, iar cele cu DBA dau informații despre toată baza de date.

Tabelele ce păstrează informații despre activitățile Oracle sunt tabele speciale care pot fi accesate numaide către administrator pentru a vedea performanțele Oracle. Utilizatorul SYS este proprietarul acestor tabele. Numele lor este prefixat cu V_$, iar sinonimele lor cu V$.

Categoriile de informații ce se pot obține din dicționarul de date sunt:

• Informații despre fișierele Online Redo Log;

• Informații despre tabelele spațiu;

• Informații despre fișierele de date (Data Files);

• Informații despre obiectele bazei de date;

• Informații despre segmentele bazei de date;

• Informații despre extensii ale bazei de date;

• Informații despre pachetele Oracle cu valoare de dicționar (Dictionary Storage).

• Informații despre utilizatorii bazei de date și profilele acesteia;

• Informații despre privilegiile și rolurile din baza de date

Accesul la date

Accesul la datele unei baze de date se realizează folosind instrucțiunile SQL (Structured Query Language) sau PL/SQL (Procedural Language).

Instrucțiunile SQL se împart în:

• Instrucțiuni de definire a datelor – DDL (Data Definition Statements). Acestea permit definirea, întreținerea și ștergerea unor obiecte ale bazei de date;

• Instrucțiuni de manipulare a datelor – DML (Data Manipulation Statements), care permit regăsirea, inserarea, actualizarea și ștergerea unor rânduri de date din tabele;

• Instrucțiuni de control a tranzacțiilor (Transaction Control Statements) permit controlul instrucțiunilor DML (COMMIT, ROLLBACK, SAVEPOINT etc);

• Instrucțiuni de control a sistemului Oracle (System Control Statements) permit utilizatorului să controleze proprietățile sesiunii curente prin activarea sau dezactivarea rolurilor sau setarea limbii;

• Instrucțiuni imprimate într-un limbaj gazdă (Embeded SQL Statements) și încorporează instrucțiuni DDL, DML și de control al tranzacțiilor.

O tranzacție este o unitate logică de lucru care cuprinde una sau mai multe instrucțiuni SQL executate de către un singur utilizator. Tranzacția începe cu prima instrucțiune SQL executabilă și se termină în mod explicit cu finalizarea (commit) sau, după caz, anularea tranzacției (rollback). Finalizarea unei tranzacții face ca modificările efectuate de intrucțiunilor SQL în baza de date să fie permanente, iar anularea (roll back) unei tranzacții duce la renunțarea la actualizările efectuate de instrucțiunile SQL până la un moment dat. Tranzacțiile mari pot fi marcate cu puncte intermediare de salvare. Acest lucru permite ca activitățile efectuate între punctele de salvare să fie considerate finalizate, iar la momentul anulării (rollback) acest lucru să se execute până la un anumit punctul de salvare specificat [16], [25].

PL/SQL este un limbaj procedural Oracle care combină instrucțiunile SQL cu instrucțiunile de control a prelucrării (IF … THEN, WHILE și LOOP). Utilizarea procedurilor PL/SQL memorate în baza de date duce la reducerea traficului pe rețea. În baza de date pot fi stocate proceduri, funcții, pachete, triggeri.

Triggerii (declanșatorii) sunt blocuri de instrucțiuni scrise de programatori pentru a adăuga funcții suplimentare unei aplicații. Fiecare trigger are un nume și conține una sau mai multe instrucțiuni PL/SQL. Un trigger poate fi asociat cu un eveniment și poate fi executat și întreținut ca un obiect distinct. Numele unui trigger corespunde unui eveniment (runtime events) care se produce la momentul execuției unei aplicații [16], [23].

Capitol 2 – Integrarea aplicațiilor Web prin limbajul de programare Java

2.1. Facilități Java în procesarea fișierelor XML – JAXB și generarea rapoartelor de tip PDF

În construirea aplicațiilor Web sau a aplicațiilor de tip business este foarte important să se utilizeze tipuri diferite de date structurate în baze de date sau în fișiere XML. În prezent multe corporații stochează datele în fișiere de tip XML deoarece aceste tipuri de fișiere sunt ușor de stocat și manipulat oferind multe facilități în stocarea datelor importante, pot fi utilizate în diverse API-uri (Application Programming Interface) specifice unor anumite limbaje de programare și nu în ultimul rând sunt disponibile pe diferite sisteme de oparare (Windows, Linux, Solaris, etc.).

Limbajul de programare Java este foarte bine orientat în lucru cu asemenea tipuri de fișiere și oferă multiple facilități pentru extragerea datelor din fișiere XML în clase Java sau pentru obținere de rapoarte dintr-un ResultSet Java (set de date rezultat Java) bazat pe fișiere XML ce este rezultatul unui statement SELECT-SQL. JAXB (The Java Architecture for XML Binding) este o tehnologie ce permite generarea claselor Java ce corespund anumitor elemente prezente în fișiere XML.

Rapoartele obținute din fișiere XML obținute din aceste tipuri de fișiere pot fi obținute ca rezultat al unei interogări SELECT-SQL, folosind tehnologia Java și lansând aplicația Apache FOP pentru transformarea unui fișier XML într-un document de tip PDF [23], [54].

Facilități Java în procesarea fișierelor XML – JAXB

JAXB (The Java Architecture for XML Binding) este utilizat pentru extragerea datelor dintr-un fișier de tip XML în clase Java și din acest punct, obiectele pot fi integrate în diferite tipuri de aplicații.

Principalele facilități JAXB sunt:

Ascunde detalii neimportante în timpul procesării datelor;

Oferă modalități orientate obiect în lucru cu fișiere XML;

Generarea claselor Java se bazează pe regulile xs prin intermediul compilatorului Marshalling, Unmarshalling;

Permite separarea activităților specifice programatorilor de cele ale web design-erilor.

În continuare este prezentat un fișier XML ce conține date despre entitatea Clienți. Acesta este codul sursă al fișierului XML:

<?xml version="1.0" encoding="UTF-8"?>

xmlns:od="urn:schemas-microsoft-com:officedata" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="fis_clienti.xsd" generated="2008-05-18T21:23:26">

<id_client>1</id_client>

<nume_client>Popescu Ion</nume_client>

<data_nastere>1968-05-18T00:00:00</data_nastere>

<client_cnp>1723482374823</ client_cnp>

<adresa_client>Bucuresti, Str. Florilor</adresa_client>

</Clienti>

<id_client>2</id_client>

<nume_client>Vasilescu Gheorghe</nume_client>

<data_nastere>1978-05-10T00:00:00</ data_nastere>

<client_cnp>1343245346456</client_cnp>

<adresa_client>Constanta, Str. Rozelor</adresa_client>

</Clienti>

</dataroot>

Principalii pași pentru JAXB sunt:

Legarea structurii XML cu clase Java.

Acest pas conține următoarele activități

scrierea documentului xs ce conține reguli de validare;

crearea/generarea documentelor XML ce respectă schema creată;

definirea unei scheme de mapare a unităților XML și a unităților Java;

generarea claselor Java din schema XML;

compilarea claselor generate.

Legarea datelor XML cu obiectele.

Acest pas este realizat prin intermediul unei aplicații client ce conține o interfață cu utilizatorul și va conține următoarele activități:

Unmarshalling: crearea obiectelor Java ce correspond cu documentul XML, eveniment cu validare;

Modificarea datelor din arborele de obiecte prin aplicația corespondentă;

Marshalling: salvarea informației înapoi în documentul XML și validarea acestei activități.

JAXB API – este un API pentru JAXB.

Tehnologia JAXB este inclusă în JWSDP (Java Web Services Developer Pack) ce are următoarea structură:

jwsdp

jaxb

bin <– utilities for generating classes (xjc)

docs <– documentation

samples <– applications examples

lib <– jar archives for JAXB:

jaxb-api.jar, jaxb-xjc.jar, jaxb-impl.jar, jaxb-libs.jaxp

lib <– jaxp-api.jar

endorsed <– archives for processing XML:

sax.jar, dom.jar, xercesImpl.jar, xalan.jar

jwsdp-shared

lib <– jax-qname.jar, namespace.jar, xslib.jar, relaxngDatatype

apache-ant

lib <– ant.jar

Generarea claselor

Generarea claselor este realizată prin xjc – un compilator de schemă.

xjc [-options …] <scheme_xs>

-nv: disable the validation of the document;

-b <file>: specifying a mapping file;

-p <package>: specifying the name of the package which will be generated;

-classpath <file>: specify where are the user classes;

-b <file>: specify a mapping file;

-xml schema: the file with rules is a XML Schema file type (default);

-relaxng: the file file with rules is a RELAX NG file type (not implemented);

-dtd: the file file with rules is a DTD file type (not implemented);

De examplu acesta este codul sursă pentru fișierul clienti.xsd:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="clienti" type="ClientiDef"/>

<xs:complexType name=" ClientiDef ">

<xs:sequence>

<xs:element name="pers" type="Person" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:complexType name="Persoana">

<xs:sequence>

<xs:element name="nume" type="xs:string"/>

<xs:element name="data_nasterii" type="xs:date"/>

<xs:element name="cnp" type="xs:string"/>

<xs:element name="adresa" type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:schema>

Compilarea schemei:

Compilarea se realizează în modul următor:

xjc catalog.xsd -p exemplu_jaxb

și va avea ca rezultat crearea unui director examplu_jaxb ce va conține:

interfața Clienti, interfața ClientsDef, interfața Persoana [11], [12], [34].

Directorul impl ce include clasele

ClientiImpl, PersoanaImpl – clase specifice JAXB

Interfețe generate:

package examplu_jaxb;

public interface Persoana {

java.lang.String getNume();

void setNume(java.lang.String value);

java.sql.Date getData_nastere();

void setData_nastere (java.sql.Date value);

java.lang.String getCnp();

void setCnp(java.lang.String value);

java.lang.String getAdresa();

void setAdresa(java.lang.String value);

}

package examplu_jaxb;

public interface ClientiDef {

java.util.List getPersoana();

}

package examplu_jaxb;

public interface Clienti

extends javax.xml.bind.Element, example.ClientsDef

{}

Clase generate:

Clasa PersoanaImpl corespunzătoare pentru tag-ul XML pers:

protected java.lang.String _Nume;

protected java.sql.Date _Data_nastere;

protected java.lang.String _Cnp;

protected java.lang.String _Adresa;

java.lang.String getNume() {…};

void setNume(java.lang.String value) {…};

java.sql.Date getData_nastere() {…};

void setData_nastere(java.sql.Date value) {…};

java.lang.String getCnp() {…};

void setCnp(java.lang.String value) {…};

java.lang.String getAdresa() {…};

void setAdresa(java.lang.String value) {…};

Clasa ClientiImpl corespunzătoare tag-ului XML clienti:

protected ListImpl _Persoana = new ListImpl(new java.util.ArrayList());

public java.util.List getPersoana() {…}

Există o mapare implicită între tipurile de date XSD și tipurile de date Java.

Compilarea claselor:

@echo off

set JAXB_LIBS=%JAXB_HOME%\lib

set JAXP_LIBS=%JWSDP_HOME%\jaxp\lib

set JWSDP_LIBS=%JWSDP_HOME%\jwsdp-shared\lib

set LIBS=%JAXB_LIBS%\jaxb-api.jar;%JAXB_LIBS%\jaxb-ri.jar;

%JAXB_LIBS%\jaxb-xjc.jar;%JAXB_LIBS%\jaxb-libs.jar;

%JAXP_LIBS%\jaxb-api.jar;%JAXP_LIBS%\endorsed\xercesImpl.jar;

%JAXP_LIBS%\endorsed\xalan.jar;%JAXP_LIBS%\endorsed\sax.jar;

%JAXP_LIBS%\endorsed\dom.jar;

%JWSDP_LIBS%\jax-qname.jar;%JWSDP_LIBS%\namespace.jar

javac -classpath %LIBS%;. exemplu\*.java exemplu\impl\*.java

javac -classpath %LIBS%;. Main.java

java -classpath %LIBS%;. Main

Unmarshalling: din fișiere XML în Java.

De exemplu acesta este codul sursă a unui fișier XML numit test.xml ce corespunde cu următoarea schemă:

<nume>Popescu Ion</nume>

<data_nastere>1968-05-18T00:00:00</ data_nastere >

<cnp_client>1723482374823</cnp_client>

<adresa_client>Bucuresti, Str. Florilor</adresa_client >

</person>

<nume>Vasilescu Gheorghe</nume>

<data_nastere>1978-05-10T00:00:00</data_nastere>

<cnp_client>1343245346456</cnp_client>

<adresa_client>Constanta, Str. Rozelor</adresa_client>

</persoana>

</clienti>

Unmarshalling

import java.io.*;

import java.sql.*;

import java.util.*;

import javax.xml.bind.*;

import exemplu_jaxb.*;

public class Main {

public static void main( String[] args ) {

try {

//1. Crearea unui obiect JAXBContext pentru manipulare

// clasele utility din package examplu_jaxb

JAXBContext jc = JAXBContext.newInstance("exemplu_jaxb");

//2. Crearea unui obiect Unmarshaller

Unmarshaller u = jc.createUnmarshaller();

//3. Unmarshall: transferul datelor din XML in obiecte

Clienti c = (Clienti)u.unmarshal(

new FileInputStream("clienti.xml"));

//4. Vederea pentru information

viewing(c);

} catch(JAXBException e) {

e.printStackTrace();

} catch(IOException e) {

e.printStackTrace();

}

viewing (Clienti c) {

for(Iterator it = c.getPersoana().iterator(); it.hasNext(); ) {

Persoana p = (Persoana)it.next();

System.out.println( p.getNume() + ": " + p.getData_nastere() + ":" +

p.getCnp() + ":" + p.getAdresa() + ".");

}}}

Validarea datelor de intrare XML:

Această activitate este realizată prin intermediul metodei setValidating(true) pentru obiectul Unmarshaller, înainte de a face această acțiune și tratarea excepțiilor UnmarshallException ce pot fi generate dacă datele XML nu corespund schemei specifice.

try {

//2.1 Activarea validarii

u.setValidating(true);

….

} catch(UnmarshalException e) {

System.out.println("Invalid Data: " + e);

}

Marshalling: din Java în XML

Actualizarea datelor. Utilizarea claselor create ce pot fi accesate și modificate prin obiectele ce reprezintă date XML.

//5. Procesarea/Actualizarea datelor

ObjectFactory obj = new ObjectFactory();

Persoana p = obj.createPersoana();

p.setNume("Popescu Ion");

p.setData_nastere(“18.05.1968”);

p.setCnp("1723482374823");

p.setAdresa("Bucuresti, Str. Florilor");

List pers = c.getPersoana();

pers.add(p);

afiseaza(c);

Marshalling

Transferul datelor în format XML către o destinație externă reprezentată de un șir de bytes.

//6. Marshall: transferul datelor in format XML

Marshaller m = jc.createMarshaller();

m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);

m.marshal(c, System.out);

Validarea obiectelor Java

Obiectele Java pot fi verificate dacă se potrivesc unei transformări XML și dacă corespund cu schema specificată.

Această activitate este realizată printr-un obiect numit Validator :

try {

//5.1 Procesarea/Actualizarea datelor

…

//5.2 Validation

Validator v = jc.createValidator();

boolean valid = v.validateRoot(c);

System.out.println(valid);

//6. Marshalling

…

} catch( ValidationException e) {

System.out.println( "Date invalide:" + e );

}

Facilități Java în procesarea fișierelor XML – generarea rapoartelor PDF.

Rezultatul reprezintă un fișier PDF bazat pe un fișier XML ce este rezultatul unei interogări SELECT-SQL, folosind tehnologia Java. Pașii pentru obținerea unui fișier PDF sunt:

definirea unei structuri XML pentru înregistrările unei surse de date;

construirea unui fișier de formatare XSL-FO pentru reprezentarea datelor într-un formular tabelar;

elaborarea sursei Java pentru extragerea înregistrărilor într-un obiect ResultSet ce va fi iterat și va genera un fișier XML corespunzător structurii definite în pasul anterior;

lansarea aplicației Apache FOP pentru transformarea fișierului XML în document PDF.

Definirea unei structuri XML pentru înregistrări prezente într-o sursă de date:

<Title>Vizualizare Clienti</Title>

<HeadData>Id Client</HeadData>

<HeadData> Nume Client </HeadData>

<HeadData>Data nastere</HeadData>

<HeadData>Cnp Client</HeadData>

<HeadData>Adresa Client</HeadData>

</Header>

<Line>

<CellDataLeftAlign>id_client</ CellDataLeftAlign>

<CellDataCenterAlign> nume_client</ CellDataCenterAlign>

<CellDataCenterAlign>data_nastere</ CellDataCenterAlign>

<CellDataRightAlign>cnp_client</ CellDataRightAlign>

<CellDataLeftAlign>adresa_client</ CellDataLeftAlign>

</Line>

</Report>

Elaborarea codului sursă Java pentru extragerea înregistrărilor într-un obiect ResultSet ce va fi iterat și care va genera un fișier XML corespunzător structurii ce a fost definită în pasul anterior:

Codul sursă Java pentru clasa ce va genera fișierul XML cu structura corespunzătoare folosită ca bază pentru documentul formatPDF.xsl. O comandă SQL va fi executată și va fi obținut un resulset ce va fi iterat iar liniile acestuia vor fi scrise într-un fișier pe disk (prin intermediul java.io package) [91], [117], [119].

Codul sursă Java:

package proiect_xml.reports.pdfreports;

import java.sql.*;

import java.io.*;

public class ReportClientiPDF {

static String directory_path=”C:/PROIECT_XML/REPORTS/PDFREPORTS”;

public static void main(String[] args) throws Exception {

Connection conn=project_xml.jdbc.Utility.getConexiune();

Statement stmt=conn.createStatement();

ResultSet rs=stmt.executeQuery(“select id_client, nume_client, data_nastere, cnp_client, adresa_client from clienti”);

//initializarea FileOutputStream

File fisRaport=new File(directory_path + “/reportData.xml”);

FileOutputStream fisStream=new FileOut[utStream(fisRaport);

OutputStreamWriter inscriptor=new OutputStreamWriter(fisStream);

BufferedWriter bfInscriptor=new BufferdWriter(inscriptor);

// Lansarea FOP

Org.apache.fop.apps.CommandLineOptions options=null;

String[] params={“-xml”,directory_path+”/reportData.xml”,

”-xsl”,directory_path+”/formatPDF.xsl”,

”-pdf”,directory_path+”/report.pdf”};

options = new org.apache.fop.apps.CommandLineOptions(params);

org.apache.fop.apps.Starter starter = options.getStarter();

starter.run();

}}

Raportul rezultat în format PDF:

Fig. 2.1.1. Clients Report

În multe aplicații sursele de date sunt foarte diferite și o mare varietate de fișiere trebuie incluse în logica acestor aplicații. Fișierele XML sunt des întâlnite în majoritatea corporațiilor și includ date semistructurate ce pot fi utilizate în diferite tipuri de aplicații [1].

Limbajul de programare Java oferă multe facilități în lucru cu fișiere XML precum extragerea datelor din aceste fișiere în clase Java și astfel reprezintă surse de date pentru multe aplicații sau se pot obține rapoarte specifice precum documentele PDF. În primul caz Java utilizează tehnologia JAXB (The Java Architecture for XML Binding) ce generează clase Java prin intermediul regulilor xs și prin intermediul compilatorului Marshalling, Unmarshalling [110].

În al doilea caz documentul PDF ce este prezentat ca raport este construit dintr-un fișier XML și utilizează fișierul de formatare XSL-FO și un obiect Java ResultSet. Fișierul XML poate fi unul deja existent sau poate fi obținut ca rezultat a unei interogări SELECT-SQL, iar prin utilizarea tehnologiei Java și lansarea aplicației Apache FOP pentru transformarea fișierului XML în document PDF reprezintă o modalitate facilă de a obține date într-un raport standard.

2.2. Java Management Extensions pentru aplicații de business

Java Management Extensions (JMX) este rezultatul activității Java Community Process (JCP) și Java Specification Request (JSR) 3 și este proiectat să ajute la dezvoltarea unui număr cât mai mare de aplicații distribuite. Obiectivul major al aplicațiilor de business este să evolueze de la secvențe de programe ce rulează pe un singur calculator la componente de business ce rulează pe diferite mașini distribuite într-o rețea. Dificultatea managerierii sistemelor distribuite a crescut alături de complexitatea acestor sisteme.

Când se ia în considerare o soluție de management pentru aplicații enterprise, apar ceva probleme precum, care este cea mai bună soluție de management pentru aplicație, ce standard ar trebui să aleagă soluția de management și cât efort este necesar pentru activarea și managerierea componentelor aplicațiilor. JMX a fost proiectat astfel încât instrumentarea resurselor să fie pusă sub controlul managementului aplicațiilor.

O resursă este o entitate în sistem ce necesită monitorizarea și/sau controlul de către managementul aplicației, astfel încât resursele ce pot fi monitorizate și controlate pot fi numite manageriabile. Managementul aplicației este un software ce poate fi utilizat la monitorizarea și controlul resurselor manageriabile. Conducerea unui sitem de resurse manageriabile se numește în limbaj de specialitate management de sistem [3], [53], [86].

Arhitectura JMX permite aplicațiilor Java (sau sistemelor) să devină manageriabile. Arhitectura JMX este compusă din trei nivele, fiecare dintre ele răspunzând la următoarele întrebări: cum se pot face resursele manageriabile, odată ce devin manageriabile, cum se pot face vizibile (disponibile) pentru management și odată ce devin disponibile pentru management, cum poate managementul aplicațiilor să le acceseze [9], [30], [34].

Arhitectura JMX

Arhitectura JMX conține trei nivele. Nivelul cel mai apropiat de aplicație se numește nivelul instrumental. Acest nivel consistă din patru abordări pentru instrumentarea aplicațiilor și transformarea resurselor sistem pentru a deveni manageriabile (a le face bean-uri (componente software reutilizabile) manageriabile, sau MBeans), precum și ca modelul să poate trimite și primi notificări.

Nivelul de mijloc al arhitecturii JMX se numește nivelul agent. Acest nivel conține registrii pentru manipularea resurselor manageriabile (serverul MBean) precum și servicii agent, ce ele însele sunt Mbean-uri și deci manageriabile. Combinarea unei instanțe a serverului Mbean, înregistrarea Mbean-urilor și orice servicii agent în folosință în cadrul unei singure mașini virtuale Java (JVM) este referită de obicei ca agent JMX [8], [85].

Al treilea nivel al arhitecturii JMX este numit nivelul serviciilor distribuite. Acest nivel conține componente middleware (de mijoc) ce conectează agenții JMX cu aplicațiile ce îi manageriază (aplicații de management). Nivelul de mijloc este împărțit în două categorii: adaptoare protocol și conectori. Prin intermediul unui adaptor de protocol, o aplicație precum un web browser se poate conecta la unul sau mai mulți agenți JMX și să managerieze Mbean-uri ce sunt înregistrate în cadul acestuia. Cât timp managementul aplicației poate înțelege obiectele conținute în fluxul de protocol, poate manageria Mbean-uri ce le reprezintă, astfel încât adaptoarele de protocol nu necesită să fie scrise în Java.

Serverul ca jumătate a conectorului pereche este în mod normal colocat cu agentul JMX ce îl reprezintă, în timp ce o parte din componenta client rulează în JVM (mașina virtuală Java) a managementului aplicației.

Arhitectura JMX este reprezentată în Fig. 2.2.1.

Fig. 2.2.1 – Arhitectura JMX

Nivelul de Instrumentare

Nivelul de instrumentare JMX este nivelul ce reprezintă preocuparea principală a dezvoltatorilor de aplicații, deoarece acest nivel pregătește resursele să fie manageriabile. Fig. 2.2.1. arată cele două arii de preocupare a nivelului de instrumentare a arhitecturii JMX:

Resursele aplicației, sau aplicația în sine;

Strategia de instrumentare ce este utilizată pentru instrumentarea resurselor aplicației.

Resursele unei aplicații ce pot fi manageriate prin intermediul JMX trebuie să pună la dispoziție date despre cinci caracteristici ale sale:

Atribute, ce conțin starea resursei;

Constructori, ce sunt utilizați de managementul aplicațiilor și alți agenți JMX pentru crearea instanțelor acestor resurse;

Operații, ce pot fi invocate de managementul aplicațiilor sau alți agenți JMX pentru a face ca resursele să performeze o anumită acțiune;

Parametrii pentru constructori și operații;

Notificări, ce sunt emise de către resurse și trimise prin infrastructura de notificări JMX către agenții interesați.

Combinarea acestor piese de date sau metadate, despre facilitățile resurselor este cunoscut ca interfață de management. Doar prin intermediul acestei interfețe managementul aplicațiilor sau alt agent JMX poate interacționa cu resursele. Există patru abordări instrumentale definite de JMX ce pot fi utilizate pentru descrierea interfeței de management a resurselor: standard, dinamic, model și deschis.

O facilitate importantă este Mbean. Un Mbean este o resursă a unei aplicații sau a unui sistem ce a fost instrumentat pentru a fi manageriat prin intermediul JMX. Instrumentarea unei resurse implică scrierea de cod sursă Java. Acest cod trebuie să urmeze patru reguli. Prima regulă este ca starea unei resurse să fie complet descrisă prin intermediul unor getters și setters (metode de obținere și setare). Este obligatoriu ca, câștigarea numelui de “bean” (componente software reutilizabile) a unei resurse, să se realizeze prin menținerea stării de JavaBean. A doua regulă presupune ca resursa să fie instrumentată (codată) în acord cu unul din tipurile JMX Mbean (standard, dinamic, model sau deschis) [62].

Urmărind aceste cerrințe o resursă poate câștiga denumirea de "M" (adică manageriabil) ca parte a denumirii Mbean. A treia regulă presupune ca un Mbean să pună la dispoziție cel puțin un constructor public. Ultima regulă spune că un Mbean să fie concret (să nu fie declarat abstract). De exemplu dacă o resursă ce se numește ResursaExempluJMX este disponibilă, atunci aceasta are următoarele atribute:

Versiunea: versiunea pentru ResursaExempluJMX;

Timpul de procesare: numărul de millisecunde a timpului de procesare ce a fost consumat de această instanță a ResursaExempluJMX;

Numărul de excepții: numărul total de excepții ce au fost generate de această instanță a ResursaExempluJMX în timpul procesării sale.

O implementare a stării ResursaExempluJMX este descrisă în Exemplul 1.

Ex 1: Atributele unei resurse

public class ResursaExempluJMX {

// Version : read-only

private String version_ex = "1.0.1";

public String getVersion() {

return version_ex;

}

// ProcessingTime : read-only

private long processingTime_ex;

public long getProcessingTime() {

return processingTime_ex;

}

// NumberOfExceptions : read-write

private short numberOfExceptions_ex;

public short getNumberOfExceptions() {

return numberOfExceptions_ex;

}

public void setNumberOfExceptions(short value) {

numberOfExceptions_ex = value;

} }

Acest exemplu demonstrează fundamentele instrumentării atributelor unei resurse în acord cu starea modelului de JavaBeans. Fiecare atribut are în spate un număr de variabile membru, astfel încât parte a stării resursei reprezentată de acel atribut să nu poată fi accesată în mod direct. Toate atributele din acest exemplu sunt accesibile și au metodele corespunzătoare de getters (metode de obținere). Atributul numărul de excepții este modificabil, și pune la dispoziție un setter (metodă de setare) în acest scop [37], [57].

Mbean-uri standard

Standard MBeans sunt cel mai simplu tip de cod pentru MBean. Este necesară definirea unei interfețe și implementarea acesteia în resursa MBean. Dacă instrumentul este ResursaExempluJMX (din exemplul anterior), ca standard MBean, atunci trebuie definită o interfață ca în codul sursă următor:

public interface ResursaExempluJMX {

// Version : read-only

public String getVersion();

// ProcessingTime : read-only

public long getProcessingTime();

// NumberOfExceptions : read-write

public short getNumberOfExceptions();

public void setNumberOfExceptions(short value);

}

După aceasta trebuie implementată interfața pentru clasa ResursaExempluJMX:

public class ResursaExempluJMX implements ResursaExempluJMXMBean {

// …………

}

Numele asignat acestei interfețe este important (trebuie să fie numele clasei ce o implementează), urmat de MBean. Acesta este codul de instrumentare ce trebuie scris pentru a face ResursaExempluJMX capabilă de a fi manageriată. Pentru a adăuga o metodă, reset(), pentru a reseta starea atributelor ProcessingTime și NumberOfExceptions. Trebuie adăugată această metodă la interfața Mbean, ca în codul următor:

public interface ResursaExempluJMXMBean {

// Version : read-only

public String getVersion();

// ProcessingTime : read-only

public long getProcessingTime();

// NumberOfExceptions : read-write

public short getNumberOfExceptions();

public void setNumberOfExceptions(short value);

// reset() operation

public void reset();

}

După aceasta trebuie implementată metoda ResursaExempluJMX în clasă, ca în Exemplul 2.

Ex 2 : Bean-ul manageriabil ResursaExempluJMX

public class ResursaExempluJMX {

// Version : read-only

private String version_ex = "1.0.1";

public String getVersion() {

return version_ex;

}

// ProcessingTime : read-only

private long processingTime_ex;

public long getProcessingTime() {

return processingTime_ex;

}

// NumberOfExceptions : read-write

private short numberOfExceptions_ex;

public short getNumberOfExceptions() {

return numberOfExceptions_ex;

}

public void setNumberOfExceptions(short value) {

numberOfExceptions_ex = value;

}

public void reset() {

processingTime_ex = 0;

setNumberOfExceptions(0);

}

// …………

}

Metadata necesar pentru fiecare Mbean este creat în mod automat de către infrastructura JMX pentru standard MBeans. Înainte ca un MBean să fie manageriat, el trebuie înregistrat cu un agent JMX. Când un standard MBean este înregistrat, este inspectat și clasele de alocare a metadatelor sunt create și menținute de către agentul JMX în numele Mbean-ului. API-ul Java corespunzător este folosit pentru descoperirea constructorilor din clasa MBean, precum și pentru alte facilități. Atributele și metadatele operații provin din interfața MBean și sunt verificate de către agentul JMX [28], [73].

Facilități importante ale JMX

Java Management Extensions este o facilitate importantă a API-ului JMX de la Sun Microsystem este noul instrument de manageriere a aplicațiilor enterprise. Arhitectura JMX (atât nivelul de instrumentare cât și nivelul agent) este des folosită în exemplele reale de implementare a Management Extensions. JMX ajută managerii tehnici și arhitecții de aplicații care evaluează diverse abordări de management al aplicațiilor.

2.3. Java și SOAP – lucru cu WSDL

Simple Object Access Protocol, sau SOAP, este o tehnologie pentru calcul distribuit. Aceasta diferă de alte tehnologii pentru calcul distribuit prin faptul că se bazează pe XML și astfel nu încearcă să redefinească domeniu de calcul. Specificațille SOAP descriu aspecte importante legate de conținutul de date și structură deoarece are legături cu modele familiare de programare precum apeluri de proceduri remote (la distanță) – RPC și transmiterea de mesaje sistem.

Pentru a evita problemele de interoperabilitate, folosind soluțiile bazate pe serviciile SOAP se poate folosi un limbaj structural pentru descrierea de servicii, locațiile lor, metodele serviciilor, parametrii și tipuri de date. Web Services Definition Language (WSDL) face acest lucru. WSDL este un limbaj XML pentru descrierea serviciilor web. Sistemele pot determina interfețele programatice a serviciilor web consultând documentul WSDL asociat cu acel serviciu. Documentul descrie metodele serviciilor alături de parametrii lor și returnează tipuri, dar pot include adrese sau puncte terminale ale serviciilor [42], [127].

Unul din marile beneficii ale WSDL este acela că este singular, acceptă standarde pentru descrierea serviciilor web și motivează dezvoltatorii SOAP să evite folosirea propriului mecanism pentru acest task. Acest lucru înseamnă că descrierea serviciilor sunt mai puțin ambigue decât dacă nu ar avea un standard, iar pe de altă parte WSDL are o specificație proprie și această specificație are potențial să fie interpretate diferit de părți multiple [32], [35].

Descrierea WSDL

Unele implementări SOAP, precum GLUE, încorporează WSDL ca parte integrantă a propriilor operații. GLUE folosește utilitarul wsdl2java ce citește documentul WSDL ce descrie servicii pentru a crea interfața Java și fisierele class.

Documentul conține un element rădăcină XML numit definitions; acest element conține definițiile de servicii. Elementul definitions poate de asemenea să conțină un atribut opțional numit targetNamespace, ce specifică URI (identificatorul uniform de resurse) asociat cu definițiile serviciilor. WSDL folosește spații de lucru și ID-uri în același mod cum SOAP împachetează, deci este comun să fie găsite un număr de spații de lucru la nivelul elementului definitions din document.

WSDL definește serviciile ca și colecții de puncte terminale de rețea. Aceste puncte terminale în terminologia WSDL, sunt cunoscute ca porturi. WSDL separă porturile servicii și mesajele lor asociate de protocoalele de rețea de care serviciile sunt legate. Combinarea de legături și adrese de rețea rezultate într-un port, iar un serviciu este o colecție de astfel de porturi. Specificația WSDL care definește documentul principal are următoarele secțiuni document:

tipurile – un container pentru definirea tipurilor de date folosind unele tipuri sistem (precum XSD);

mesajul – un abstract, definit ca tip al datelor ce vor fi comunicate;

operație – o descriere abstractă a unei acțiuni suportată de serviciu;

portType – un set de operații abstracte compatibile cu unul sau mai multe puncte terminale;

legătură – un protocol concret și un format specificat de date pentru un anume tip de port;

port – un singur punct terminal definit ca o combinație de legături și adrese de rețea;

serviciu – o colecție de puncte terminale cu legături între ele.

Pentru exemplificare putem considera un serviciu ce pune la dispoziție acțiunile întârziate pentru clasa StockHolder_profits și ultimele știri bazate pe simbolul acțiune. Serviciul se numește ex:Example1. Acesta are o metodă numită getHeadlines care primește un singur parametru șir pentru simbolul acțiune și returnează un vector String[] ce conține ultimele știri legate de companie reprezentată de simbolul acțiune [19], [38], [39].

Serviciul conține o metodă numită getStockHolder_profit ce preia simbolul acțiune ca parametru. Metoda returnează o instanță a tipului de date custom (specific) numit StockHolder_profit ce conține simbolul acțiune, ultimul preț de tranzacționare, prețul de schimb în comparație cu prețul de deschidere, numărul de părți al acțiunilor tranzacționate până la data curentă, momentul de timp al primirii noutăților. Următorul cod Java implementează tipul specific StockHolder_profit [21], [34], [37]. Această clasă este plasată în pachetul de servicii.

Clasele pe partea de server sunt separate de partea client deoarece logica de business cere să nu fie comune clasele între client și server; există un alt pachet numit clienti pentru clasele de pe partea client. Există tehnici folosite pentru maparea oricărui tip specific pentru utilizarea codului client.

package Ex_soap;

import java.io.*;

import java.util.*;

import java.net.*;

public class StockHolder_profit_ex {

String symbol1;

float lastPrice1;

float change1;

String timeStamp1;

long volume1;

public String getSymbol( ) {

return symbol1;

}

public void setSymbol(String symbol) {

symbol1 = symbol;

}

public float getLastPrice( ) {

return lastPrice1;

}

public void setLastPrice(float lastPrice) {

lastPrice1 = lastPrice;

}

public float getChange( ) {

return change1;

}

public void setChange(float change) {

change1 = change;

}

public String getTimeStamp( ) {

return timeStamp1;

}

public void setTimeStamp(String timeStamp) {

timeStamp1 = timeStamp;

}

public long getVolume( ) {

return volume1;

}

public void setVolume(long volume) {

volume1 = volume;

}}

Acesta este singurul tip specific necesar în aplicație; restul de date utilizează tipuri predefinite. În continuare este prezentat codul sursă a clasei Java ce implementează serviciul:

package Exempl_soap;

import java.util.Vector;

public class Exempl_Service {

public StockHolder_profit_ex getStockHolder_profit (String symbol)

throws Exception {

StockHolder_profitParser qp1 = new StockHolder_profitParser( );

return qp1.getStockHolder_profit (symbol);

}

public String[] getHeadlines_ex(String symbol)

throws Exception {

HeadlineParser hp1 = new HeadlineParser( );

Vector v = hp1.getHeadlines(symbol);

int len = v.size( );

String[] result = new String[len];

for (int i = 0; i < len; i++) {

result[i] = (String)v.elementAt(i);

}

return result;

}}

Metoda getStockHolder_profit_ex( ) din clasa Exempl_soap utilizează o clasă numită StockHolder_profitParser. Clasa parsează șirul de date a serviciului web numit StockHolder_profit service și pachetele rezultate în instanța Exempl_soap, StockHolder_profit_ex; Similar metoda getHeadlines_ex() utilizează o clasă numită HeadlineParser ce va colecta ultimele știri ca șiruri și le returnează într-o instanță a java.util.Vector. Metoda getHeadlines_ex() creează un vector String[] bazat pe conținutul unui vector și returnează un vector către apelant. În continuare este prezentată clasa Ex_soap.ExServices utilizată pentru publicarea serviciului:

package Ex_soap;

import electric.util.Context;

import electric.server.http.HTTP;

import electric.registry.Registry;

public class ExServices {

public static void main(String[] args)

throws Exception {

String ns = "ex:ExServices";

Context context = new Context( );

context.addProperty("activation", "application");

context.addProperty("namespace", ns);

context.addProperty("description", "Example Services");

Registry.publish(ns,Exempl_soap.ExServices.class, context);

}}

După ce ExServices este rulat, acesta trebuie cerut de documentul WSDL asociat cu publicarea serviciilor [68], [73]. Legarea proceselor cerute de WSDL vor fi generate de către server. Cel mai facil mod de a folosi WSDL pentru serviciul GLUE este prin intermediul unui browser web. WSDL-ul generat pentru serviciul ex:ExServices are două metode serviciu și un singur tip de date specific. În Fig. 2.3.1 este ilustrată structura de nivel înalt a documentului WSDL pentru acest serviciu exemplu [74]. Simbolul (n) după anumite nume de elemente indică că există mai mult de un element a tipului particular de date [20], [34], [44].

Fig. 2.3.1 – Structura de nivel înalt a documentului WSDL

Elementul definitions este rădăcina documentului și tot ce se află în acesta. Atributul name conține numele defințiilor serviciu conținute în interior, ce în acest caz este ExService. Acesta nu este numele serviciului, ex:ExServices și este numele dat definițiilor acestui serviciu. Acest nume este derivat din numele clasei Java ce implementează serviciu, Ex1.ExService. Atributul targetNamespace declară spațiile de lucru asociate cu definiția serviciului.

Numele implicit este creat automat prin adăugarea numelui definiției la http://www.examplelectric.com/package/Ex1. Elementul definitions include un număr de declarații identificator a spațiilor de lucru, care are proprietatea de descriere proprie. Ultimul atribut setează toate spațiile de lucru la http://schemas.xmlsoap.org/wsdl, ce reflectă spațiile de lucru pentru WSDL însuși. Următorul este elementul types. Acest element definește tipurile specifice folosite de serviciu. Fiecare tip specific este definit utilizând elementul schema, unde fiecare schemă este copil direct al tipurilor. Prima schemă este folosită pentru definirea unui vector șir returnat de metoda serviciu getHeadlines. Acest șir este un vector de complexType și chiar un vector este considerat un tip complex deoarece conține valori multiple.

Atributul nume are valoarea asignată "ArrayOfstring". În interiorul complexType, este un element numit complexContent, ce specifică că tipul este restricționat la un vector de șiruri. Al doilea element schema are valoarea atributului nume "StockHolder_profit". Acesta este tipul specific utilizat pentru a returna acțiunea StockHolder_profit din cadrul serviciului, de asemenea definit utilizând elementul complexType. În acest caz complexType conține un element secvență, în schimb, conține câmpuri de date pentru tipul de date specific StockHolder_profit. Fiecare câmp este definit utilizând un tag (etichetă) element și conține atributul nume ce specifică numele câmpului de date. GLUE utilizează membrul actual names din clasa Ex1. StockHolder_profit. Fiecare element are de asemenea tipul său definit. Elemetele message urmează în schemă. Aceste elemete definesc datele pasate între client și server. Fiecare message conține un atribut nume, format prin pornirea metodei serviciu name și adăugarea unui număr pentru a asigura faptul că numele este unic.

2.4. Construirea aplicațiilor Enterprise cu Java pentru SAP

SAP a fost fondat în anul 1972 ca Systemanalyse und Programmentwicklung – "System Analysis and Protocol Development" de către cinci foști ingineri IBM în Mannheim. SAP este a doua companie pentru produse software la nivel mondial și al treilea provider independent de software. Aceasta operează în trei zone geografice regions – EMEA, ce reprezintă Europa, Middle East și Africa. SAP se focusează pe șase sectoare de industrie: industrii procesasoare, industrii discrete, industrii consumator, industrii servicii, industrii financiare și servicii publice.

SAP și Enterprise Service-Oriented Architecture: Service-oriented architecture mută domeniul ERP spre software și servicii web bazate pe activități business. Acest fapt face ca să crească adaptabilitatea. Flexibilitatea, deschiderea și eficiența. Deplasarea către E-SOA ajută companiile să reutilizeze componentele software și să nu se bazeze mult pe dezvoltări proprii ale planificării resurselor software și hardware, fapt ce ajută la adaptarea ERP în mod mai atractiv pentru companii mici și mijlocii. SAP este singurul vendor de aplicații software enterprise ce construiește atât servicii orientate direct în soluțiile sale și pune la dispoziție o platformă tehnologie – SAP NetWeaver și ghidaj pentru a ajuta companiile în dezvoltarea propriilor arhitecturi orientate servicii, atât cu soluții SAP, cât și cu alte soluții. Produsele SAP se focusează pe Enterprise Resource Planning – ERP.

Deoarece Java continuă să evolueze în multe domenii, cererea pentru programatori cu multe aptitudini necesară creșterii cerințelor aplicațiilor Java Enterprise, va crește exponențial. Cererea imediată pentru dezvoltatori Java provine din nivelul enterprise. Corporațiile au realizat că implementarea pe scară largă de software este costisitoare și deseori ineficientă și astfel au început să migreze către aplicații și framework-uri mai flexibile, ce au un viitor garantat. Fără abilitatea de a adăuga cu ușurință noi funcționalități la aceste soluții monoilitice și centralizate, companiile trebuie să rezolve problema proprietății limbajelor de programare, a unui număr mare de consultanți de proiect și specializarea/instruirea proprilor angajați, pentru a face față creșterii suportului tehnic al companiei [40], [83], [106].

Cu Enterprise Java, dezvoltatorii pot accesa puterea produselor software incluse, menținând totuși libertatea unei platforme de dezvoltare deschise. Folosind Java, dezvoltatorii pot ușor construi componente middleware ce pun la dispoziție tranzacționări sigure și integre între diferite sisteme enterprise, precum SAP și diferite tipuri de SGBDR-uri – Sisteme de gestiune a bazelor de date relaționale. Platforma Enterprise Java pune la dispoziție trei componente pentru integrarea middleware (nivel de mijloc):

Flexibilitate – datorită independenței de platformă, dezvoltările Java pot fi desfășurate în cadrul unei varietăți de sisteme de operare și configurări hardware. Aceasta permite dezvoltatorului să construiască aplicații pe o platformă la alegere și să le desfăsoare pe aproape orice sistem în cadrul enterprise. Enterprise Java pune la dispoziție o platformă consistentă pentru aplicații către companii. Această consistență reduce mult activitatea de administrare a rețelei în privința faptului de a gestiona variabile de limbaj la momentul execuției.

Scalabilitate – aplicațiile server Enterprise Java pot fi desfășurate pe aproape orice configurare sistem hardware/operare. O desfășurare inițială a unei aplicații server se poate realiza pe câteva computere de nivel jos și mediu. Pe măsură ce traficul de rețea și nivelul de încărcare a serverului crește, aceste aplicații sever sunt migrate pe mașini mai puternice. Deseori, aplicații server Java adiționale pot fi adăugate pentru a produce clusterizare și suport pentru încărcare. În esență, aplicațiile scrise în Java sunt desfășurate într-o aplicație server ce poate fi scalată pentru a îndeplini cererile din ce în ce mai multe ale end user-ilor.

Bazate pe standarde – specificațiile J2EE descriu un set de standarde ce permit dezvoltatorilor să implementeze de-a lungul unui set comun de componente tehnice. Aceasta înseamnă că nici o companie nu deține drepturi asupra Enterprise Java; abilitatea de a modifica și adăuga funcționalități este bazată pe Java Community Process (JCP). Java nu este un mediu închis, arhitectură proprietar și acest lucru înseamnă că orice dezvoltator poate revizui cod sursă Java fundamental și că o singură companie nu poate în mod arbitrar dicta viitorul acestei platforme de programare. Numărul de companii care suportă și oferă aplicații Java, aplicații server și instrumente adiacente este în creștere.

Menținut de JCP, JSR se ocupă atât cu propuneri cât și cu variante finale de specificații Java [43], [81]. Varaianta revizuită a JSR pune la dispoziție o radiografie completă a viitorului imediat al Java. SAP crede că Enterprise Java ar trebui să formeze baza în jurul unei strategii corporative de integrare middleware. Participarea SAP-ului ajută la garantarea faptului că viitoarele specificații Java vor ține cont de necesitățile unice ce apar în dezvoltarea aplicațiilor pentru sisteme Enterprise Resource Planning (ERP) și clienți. Majoritatea organizațiilor enterprise rulează pe multiple sisteme de baze de date de generație mai veche. Deși este foarte probabil ca o companie să standardizeze aplicațiile de business SAP, sistemele adiționale de baze de date sunt deseori cerute pentru suport de bază sau funcționalități de nișă.

Indiferent de situație, Java poate fi folosită pentru a lega împreună sisteme disparate. Pentru a rula o aplicație Java, platforma aleasă trebuie să aibă acces la JVM. JVM este un interpretor la momentul execuției ce preia cod Java precompilat și îl execută ca o aplicație nativă. Din nou, idea de abstract este cheia deoarece JVM efectiv abstractizează logica de programare în mod complet de platforma hardware. Oricum, JVM este dependent de configurarea sistemul hardware/operare, fapt ce înseamnă că, conține interfețe sistem specifice acelei platforme [42], [121].

Utilizarea JCo în aplicație Java pentru SAP

Java Connector – JCo este o facilitate importantă în cadrul aplicațiilor Java pentru SAP, deoarece poate da acces utilizatorului la resursele de business. Librăria pentru aplicații SAP JCo încapsulează un set complex de componente conexiune ce permit comunicarea pe două căi cu sistemul SAP. Deoarece JCo se bazează pe metodologia tranzacțională a SAP, trebuie folosit când translatează cod Java către funcționalitate SAP pentru a garanta integritatea datelor. În această situație, JCo cere ca următorii pași să fie urmați, începând cu reprezentarea Java a Business Application Programming Interface – BAPI și a Remote Function Call – RFC structuri de date.

Înainte de a face apelul către interfața BAPI/RFC, aplicația trebuie întâi autentificată și autorizată pentru folosirea sistemului SAP. Un apel RFC sau BAPI este alcătuit din serii de parametrii ce au legături între ei, structuri și tabele. Acestea pot fi codate manual sau aplicația poate inițializa un JCo bazat pe un catalog interfață deja existent. O aplicație are nevoie să creeze un set de date pentru fiecare sistem SAP la care are nevoie să se conecteze. Conexiunea SAP creată anterior este utilizată aici pentru a extrage date din SAP.

Aplicația extrage metadata pentru o interfață specifică RFC sau BAPI. Metadata nu reprezintă datele în sine și containerele de definiții de date, indiferent dacă sunt tipuri de câmpuri, structuri sau relații. JCo facilitează extragerea acestor metadate din cadrul unei interfețe funcționale SAP precum un RFC sau BAPI. În acest punct aplicația are un model de interfață funcțional ce este necesară pentru apelarea cu succes a RFC sau BAPI.

Aceste înregistrări pot fi utilizate în diferite scopuri, inclusiv pentru a determina dacă apelul a fost realizat cu succes, precum și pentru extragerea de date pertinente trimise de sistemul SAP. După aceasta, aplicația decide ce date vor fi afișate înapoi la utilizatorul final, le formatează și încheie execuția [81], [90].

În continuare este prezentată o aplicație utilizată pentru a completa o listă de produse de către un client.

Definiția clasei este:

import com.sap.mw.jco.*;

public class Products_ex {

public static void main(String[] args) {

System.out.println("This class looks up products");

}

Definirea variabilelor Java:

public static void main(String[] args) {

// The Java String variables

final String SAP_CLIENT_EX ="175";

final String USER_ID ="username";

final String PASSWORD = "password";

final String LANGUAGE = "EN";

final String HOST_NAME = "hostname";

final String SYSTEM_NUMBER = "00";

String matSearch;

// The JCo specific variables

JCO.Client aConnection;

IRepository aRepository;

Conectarea la SAP:

try {

Connection_ex = JCO.createClient(SAP_CLIENT_EX,

USER_ID,

PASSWORD,

LANGUAGE,

HOST_NAME,

SYSTEM_NUMBER);

Connection_ex.connect();

}

catch (JCO.Exception ex) {

System.out.println("Call to SAP failed.");

ex.printStackTrace();

}

Inițializarea resurselor SAP:

Repository_ex = new JCO.Repository("SAPRep_ex", Connection_ex);

Extragerea interfeței RFC Metadata:

IFunctionTemplate functionTemplate_ex =

Repository.getFunctionTemplate_ex("BAPI_PRODUCTS_EX");

JCO.Function function_ex = new JCO.Function(functionTemplate_ex);

Adăugarea datelor la apelul funcției SAP:

JCO.ParameterList tabParams_ex = function_ex.getTableParameterList_ex();

JCO.Table products = tabParams_ex.getTable_ex("PRODUCTSSELECTION");

Toate produsele sau o listă de produse:

if (args.length == 0)

matSearch = "*";

else

matSearch = args[0];

Adăugarea datelor la tabela PRODUCTSSELECTION:

products.appendRow();

products.setRow(0);

products.setValue("INCLUDE", "SGN");

products.setValue("CP", "OPTION");

products.setValue(matSearch, "PRODNR_LOW");

Valoare CP înseamnă – contains pattern.

Apelul către SAP:

Connection_ex.execute(function_ex);

Înregistrările produse, apeluri de obiecte și metode pentru a include tabela SAP în aplicație:

JCO.ParameterList resultParams_ex = function.getExportParameterList_ex();

JCO.Table productsList =

function.getTableParameterList_ex().getTable("PRODUCTSLIST");

Parcurgerea rândurilor din tabelă și afișarea valorilor fiecărui câmp din fiecare rând:

if (ProductsList.getNumRows() > 0) {

do {

System.out.println("< List of Client’s Products >");

for (JCO.FieldIterator fldI_ex = productsList.fields();

fldI_ex.hasMoreElements();)

{

JCO.Field tabField_ex = fldI_ex.nextField();

System.out.println(tabField_ex.getName() +

(":\t") +

tabField_ex.getString());

}

System.out.println("\n");

}

while(productsList.nextRow() == true);

}

else {

System.out.println("Products couldn't be found");

}

Rezultatul aplicației:

< List of Client’s Products >

PRODUCT: Product1

PROD_DESC: The first product in SAP system

PRODUCT_EXTERNAL:

PRODUCT_VERSION:

< List of Client’s Products >

PRODUCT: Product2

PROD_DESC: The second product in SAP system

PRODUCT_EXTERNAL:

PRODUCT_VERSION:

….

Construirea aplicațiilor pentru SAP este un mod optim de reutilizare a resurselor de business și încapsularea lor în obiecte. SAP oferă Business Software Solutions Applications și servicii în multe domenii economice precum relații cu clienții, marketing, ciclul de viață al produselor, etc. Și de asemenea îmbunătățește procesele de business precum aprovizionarea, producția și vânzările [4].

Prin intermediul limbajului de programare Java, sistemele SAP sunt îmbunătățite, deoarece acest limbaj orientat obiect este independent de platformă, foarte flexibil în construirea și extinderea unor aplicații noi sau deja existente și astfel prin intermediul JCo Java poate accesa resurse de business plasate în cadrul unui sistem SAP. Conectarea la SAP prin JCo face posibilă customizarea propriilor aplicații, crearea de clase proprii și lucrul cu resurse SAP ce sunt construite conform logicii de business.

Prin intermediul limbajului Java este posibilă adăugarea de date la un sistem SAP sau se pot afișa date existente din acesta conform cerințelor utilizatorilor finali.

2.5. Facilități Java pentru nivelul de Business – design și implementare

Componentele Java pentru nivelul de Business include diferite părți precum business delegate, service locator, session façade, application service, business object, composite entity, transfer object, transfer object assembler, etc. Limbajul de programare Java poate separa principalele nivele pentru căi mai bune și mai facile de construire a aplicațiilor de business. Principalele nivele ale unei aplicații de business sunt: nivelul de prezentare, nivelul de Business și nivelul de integrare.

Prin separarea acestor nivele se pot disocia procesele de lucru ale interfețelor designerilor, web designerilor, programatorilor java, consultanților de business și a arhitecților de integrare software, și astfel logica de business a aplicațiilor poate fi separată de activitatea de design, iar diferite părți ale aplicațiilor pot fi integrate mult mai ușor și durata îndeplinirii a acestor activități este mult mai scurtă [47], [54], [55]. Nivelul de business se referă la accesul componentei client la diferite componente ce sunt structurate în clase java ce sunt customizate pentru fiecare tip de aplicații business și conține descrieri pentru acțiuni precum cereri, aprovizionare, achiziții, livrare, etc.

Principalele componente ale nivelului de Business

Nivelul de business este un nivel important al unei aplicații și este construit pentru a răspunde la principalele cerințe ale unuia sau a mai multor procese de business. Dezvoltatorii de software implementează specificațiile create de specialistul de business din diferite departamente precum contabilitate, financiar, aprovizionare, relații clienți, etc., iar ei construiesc clase java pentru fiecare tip de acțiune și de asemenea aceste clase trebuie să corespundă cu interfețele construite de designeri. Prima componentă a nivelului de business este business delegate [49], [56], [122].

Business Delegate

O activitate importantă este ascunderea clienților de complexitatea comunicării la distanță cu componente business service. Când clienții accesează de la distanță componente de business service în mod direct, pot să apară probleme. Clienții interacționează direct cu interfața de business service. Aceasta înseamnă că atunci când codul de business service se schimbă, codul client necesită să fie schimbat, de asemenea. Acest lucru face ca, cantitatea de mentenanță să crească și să descrească flexibilitatea sistemului. O altă problemă este legată de performațele rețelei [2], [10], [102].

Când clienții interacționează direct cu API-ul serviciilor de business, o singură acțiune în partea client poate necesita multe interacțiuni de nivel mic cu serviciile de business. Aceasta duce la legarea logicii de business în partea de clienți fără un caching pentru partea de client sau agregarea serviciilor, astfel reducânduse mentenanța. Deoarece acest lucru se întâmplă într-o rețea, de asemenea este scăzută performanța rețelei. O altă problemă este interacțiunea apropiată cu API-ul serviciului de business, ceea ce înseamnă că, codul client are nevoie de cod infrastructură pentru a interacționa la distanță cu nivelul de mijloc [109], [134].

O cerință este de a accesa componentele din nivelul de business de la componentele și clienții din nivelul de prezentare, precum devices, servicii web și clienți consistenți. Alte cerințe sunt: minimizarea cuplării clienților și a serviciilor de business, astfel ascunzând detallile de implementare a serviciilor, precum lookup (căutare) și acces; pentru a evita invocări nenecesare de servicii de la distanță; pentru a translata excepțiile de rețea în aplicație sau excepții utilizator; pentru a ascunde detaliile de creare a unui serviciu, reconfigurare și invocare reîncercate de către clienți. Pentru a rezolva aceste probleme se poate folosi un Business Delegate pentru a încapsula accesul la serviciul de business. Business Delegate ascunde detaliile de implementare al serviciului de business, precum lookup și mecanisme de acces [24], [114], [131].

Un Business Delegate acționează ca o abstractizare a părții client, iar acesta abstractizează și ascunde detalii de implementare a serviciilor de business. Utlizarea unui Business Delegate reduce cuplarea între client și serviciile sistem de business. În funcție de strategia de implementare, Business Delegate poate proteja clienți de posibile volatilități ce apar în procesul de implementare a API-ului serviciului de business [41], [58]. Acesta reduce numărul de schimbări ce trebuie efectuate asupra codului client, când API-ul serviciului de business sau implementarea sa de bază se schimbă. Metodele interfeței în Business Delegate pot necesita modificări, dacă API-ul serviciului business de bază se schimbă.

Este probabil ca schimbările făcute la serviciul de business și nu la Business Delegate. Utilizarea unui Business Delegate are următoarele beneficii:

Principalul beneficiu este ascunderea detaliilor de serviciul de bază. De exemplu, prin folosirea Business Delegate, clientul devine transparent pentru numire și serviciide lookup;

un Business Delegate de asemenea gestionează excepțiile venite de la serviciile de business, precum excepții java.rmi.Remote, excepții JMS, etc. Business Delegate poate intercepta excepții la nivel de servicii și poate genera în locul lor excepții la nivel de aplicații. Excepțiile la nivel de aplicații sunt mai ușor de gestionat de către clienți și de asemenea sunt mai prietenoase cu utilizatorul;

Un Business Delegate poate de asemenea să realizeze operații de recuperare, dacă este necesar, în cazul în care un serviciu eșuează, fără a expune clientului problema, decât dacă această problemă nu se poate rezolva. Acest fapt duce la raționamentul de a folosi un șablon;

Business Delegate poate stoca rezultatele în cache și poate face referințe către servicii business de la distanță. Caching-ul poate în mod semnificativ îmbunătăți performanțele, deoarece el poate limita transmisii dus-întors în cadrul rețelei.

Un Business Delegate folosește un Service Locator pentru a localiza serviciile de business. Service Locator este responsabil pentru ascunderea detaliilor implementării de bază a codului de lookup pentru serviciul de business. Când un Business Delegate este folosit cu un Session Façade, în mod tipic există o relație unu-la-unu [49], [91], [121].

Clientul cere componentei BusinessDelegate să pună la dispoziție acces la serviciul de business de bază. BusinessDelegate folosește un ServiceLocator pentru a localiza componenta de BusinessService necesară.

Fig. 2.5.1 – Diagrama de clasă a Business Delegate

Rolul unui Business Delegate este de a pune la dispozișie control și protecție pentru serviciul de business. Business Delegate poate expune două tipuri de constructori pentru clienți: un constructor implicit pentru instanțierea de Business Delegate; un constructor pentru a instanția Business Delegate cu un ID ca argument, unde ID este o reprezentare șir a referinței către un obiect aflat la distanță, precum un as EJBHome sau EJBObject.

Când este creat fără un ID, Business Delegate cere un serviciu de business de la ServiceLocator, tipic implementat ca Service Locator, ce returnează un obiect service factory, precum un EJBHome. Business Delegate utilizează service factory pentru a localiza, creea sau înlătura un BusinessService, precum un enterprise bean (componentă software reutilizabilă) [67], [87].

Când este inițializat cu un șir ID, Business Delegate folosește șirul ID pentru reconectare la BusinessService, ascunzând clientului detaliile de bază ale implementării BusinessService, anume căutare și numire. Clientul nu face niciodată o invocare la distanță a unui BusinessService; în loc, clientul utilizează BusinessDelegate. Rolul ServiceLocator este îndeplinit de implementarea Service Locator. ServiceLocator încapsulează detaliile de implementare ale localizării componentei BusinessService [6], [25].

Un Business Delegate expune o interfață ce pune la dispoziție clienților acces la funcționalități de bază a API-ului de business service. Caching-ul poate include referințe la distanță pentru locația de bază a unui session bean (bean sesiune) sau obiecte la distanță pentru a îmbunătăți performanța prin reducerea numărului de căutări. Business Delegate poate de asemenea converti referințe la reprezentări de șiruri (ID-uri) și vice versa, folosind un Service Locator. Pentru a ilustra un model Business Delegate, poate fi folosit următorul exemplu:

Ex 1 : Implementarea modelului Business Delegate.

public class Ex1 {

// Referinte pentru Session Facade

private ResourceSession session;

// Clasa pentru locația de bază a obiectului Session Facade

private static final Class cls1 =

corepatterns.apps.psa.ejb.ResourceSessionHome.class;

// Constructorul implicit.

public Ex1() throws ResourceException {

try {

ResourceSessionHome home =

(ResourceSessionHome) ServiceLocator.getInstance().

getRemoteHome("Resource", cls1);

session = home.create();

} catch (ServiceLocatorException ex) {

// Move Service Locator exception into

// application exception

throw new ResourceException(…);

} catch (CreateException ex) {

throw new ResourceException(…);

} catch (RemoteException ex) {

throw new ResourceException(…);

}

// Constructor ce acceptă un ID (Handle id) și

// reconectează la anteriorul session bean

public Ex1(String id)

throws ResourceException {

// reconectarea la session bean pentru id-ul dat

reconnect(id);

}

…

}

Serviciu Aplicație

Fațadele de serviciu, precum Session Façade sau fațate POJO, conțin puțin sau deloc logică de business și expune o interfață de nivel jos. Obiectele de business expun o interfață prin comportament de încapsulare ce este specific unui set de operații business ce au legătură. Aplicațiile implementează utilizările case ce coordonează multiple obiecte de business și servicii.

Ar trebui implementat comportamentul de utilizare case-coordonare specific în cadrul obiectelor de business, deoarece crește cuplarea și reduce coeziunea între aceste obiecte business. Nu este recomandată adăugarea de logică de business unui serviciu fațadă, deoarece logica de business obține în mod potențial duplicări între diferite fațade, reducând reutilizarea și mentenanța codului comun.

În aplicațiile J2EE ce nu utilizează componente EJB, componentele nivelului de business precum obiectele de business și alte servicii ce sunt implementate ca POJO-uri. Deși aceste obiecte sunt obiecte locale, este recomandat să se evite expunerea lor directă către clienți, deoarece această expunere introduce cuplarea și dependințele între clienți și aceste componente din nivelul business. Chiar și în aplicații ce nu folosesc obiecte business este recomandat să fie încapsulată logica de business în nivelul de business în locul încapsulării în fațade sau clientți.

Serviciile aplicații pot include toate procedurile logicii de aplicații necesară pentru implementarea diferitelor servicii în aplicații și poate folosi accesul la obiecte date când este necesară gestionarea datelor persistente. În aplicații non-EJB unde este nevoie să fie redusă cuplarea între componente ale nivelului presentation și componente nivel business precum obiecte business și alte servicii, serviciile aplicație asigură funcții intermediare între cele două niveluri.

Serviciul aplicație expune o interfață de nivel jos în locul unei fațade serviciu. Serviciile aplicație pun la dispoziție infrastructura background pentru fațadele serviciu. Aceste fațade devin mai simplu de implementat și conțin mai puțin cod deoarece pot delega procesări business către servicii aplicație [132], [133]. Serviciile aplicație conțin logică de business și fațade servicii ce, în mod tipic, nu conțin logică de business. Serviciile fațadă utilizează servicii aplicație și obiecte business ce conțin logică de business. Serviciul aplicație este folositor pentru aplicații cu interacțiuni ce depind de factori externi. În mai multe aplicații interacțiunile cu un obiect de business pot varia de la un caz la altul.

Aplicația poate să aibă nevoie de diferite tipuri de clienți. În timp ce logica de procesare de-a lungul tuturor tipurilor de cereri este cel mai bine încapsulată în obiecte business pentru facilitarea reutilizării, logică specifică de procesare pentru fiecare tip de cerere precum și cu diferite interacțiuni pentru fiecare case sau tip de client, este cel mai bine încapsulată într-un serviciu aplicație. Figura 2.5.2 arată diagrama de clase ce reprezintă modelul Serviciu Aplicație.

Fig. 2.5.2 – Diagrama de clase pentru Serviciu Aplicație

Clientul este un rol ce este în mod tipic îndeplinit de o fațadă serviciu implementată ca un POJO sau un Session Façade. Clientul poate fi de asemenea un alt serviciu aplicație sau un obiect ajutător POJO. Serviciu aplicație reprezintă rolul principal în acest model și încapsulează logică de business necesară pentru a pune la dispoziție un serviciu specific.

Acestea pot fi funcții de bază sau utilități ce sunt în mod frecvent utilizate pentru a ajuta procesarea cererilor serviciilor nivelului business. Pentru a ilustra un model serviciu aplicație poate fi folosit următorul exemplu:

Ex 2 : Implementarea Serviciului Aplicație

import javax.ejb.SessionContext;

import javax.ejb.EJBException;

import java.rmi.RemoteException;

import java.util.Date;

public class Ex_3

implements javax.ejb.SessionBean {

public void setSessionContext(

SessionContext sessionContext)

throws EJBException, RemoteException {

}

public void addAccount(AccountTO account) {

CompanyAppService cas = new CompanyAppService();

cas.addAccount(account);

}

public void createCompany( CompanyTO company) {

CompanyAppService cas = new CompanyAppService();

cas.addCompany(company);

}

Serviciu client aplicație

public class CompanyAppService {

public void addCompany(CompanyTO companyTO) {

Company customer = new Company(companyTO);

}

public void addAccount(String companyId,

AccountTO accountTO) {

throws AccountException {

Company company = null;

if (company == null)

throw new AccountException(

"Company Id: " + companyId + " do not exist");

Account account = new Account(accountTO);

company.addAccount(account);

AccountManager accountManager = null;

accountManager = getAccountManager(company.getZip());

account.addAccountManager(accountManager);

// Trimite email către Account Manager

EmailAppService emailAppService =

new EmailAppService();

emailAppService.notifyAccountManager(accountManager,

account);

}

Principalul beneficiu în utilizarea unui design și a unei implementări adecvate este disocierea între nivelul presentation, nivelul de business și nivelul integration. Limbajul de programare Java îmbunătățește modalitățile de construire a noi aplicații de business și reutilizarea resurselor vechi din aplicații precedente, astfel încât sunt ușor de îndeplinit cererile clienți. Aplicațiile Java sunt mai adaptive și mai robuste dacă sunt construite pe logica de business ce implementează design-ul de bază și implementarea în funcție de diagramele UML.

Capitol 3 – Facilități avansate ale limbajul de programare Java în domeniul aplicațiilor web

3.1. JDBC (Java Database Connectivity) – modalități Java în accesarea diferitelor tipuri de date

JDBC este un API (Application Programming Interface) la nivel SQL (Structured Query Language – Limbaj structurat de interogare) ce permite programatorilor să încapsuleze statement-uri SQL ca argumente la metode în interfețe JDBC. JDBC necesită ca vendorii de baze de date să furnizeze o implementare runtime (momentul execuției) a acestei interfețe. Aceste implementări rutează apeluri SQL către baze de date pe care le recunosc. Programatorii sunt ajutați de JDBC ce dă libertate totală față de orice aspect legat de particularități ale bazei de date; ei pot rula același cod indiferent ce bază de date este prezentă. Managementul tranzacției implică pachete legate de tranzacții ale bazei de date într-o singură componentă și gestionarea oricărei erori condiționează acel rezultat.

API-ul JDBC diferă de driverul JDBC. API-ul definește interfețe și metode implementate de vendori când este scris un driver. Înainte de scrierea unei aplicații JDBC, trebuie obținut și instalat un driver JDBC, ce implementează interfețele. Un singur driver JDBC nu permite accesarea diferitelor branduri de baze de date. Cu alte cuvinte, trebuie folosit un driver specific focusat pe diferite tipuri de baze de date. Toate comunicările cu o bază de date trebuie să treacă printr-un driver JDBC. Driver-ul convertește statement-uri SQL într-un format pe care serverul bazei de date îl înțelege și face apelul prin rețea folosind protocolul adecvat. Driverul JDBC abstractizează detaliile specifice comunicării cu data de baze de utilizatori [32], [50].

Facilități ale JDBC

Java pune la dispoziție aplicațiilor client acces direct la date locale pentru clienții pe care rulează. Aplicațiile Java pot utiliza în mod automat date locale pentru a pune la dispoziție modalități adecvate de afișare a șirurilor senzitiv-locale precum dată calendaristică, monedă și șiruri numerice. Java face formatarea automat și astfel accesibilitatea este mult mai simplă pentru dezvoltatori. Un dezvoltator Java are nevoie să facă o aplicație accesibilă printr-o bună interfață utilizator rezultată din practica de programare. Java utilizează indicii bine dezvoltate pentru interfața utilizator astfel încât aceasta devine foarte accesibilă. JDBC necesită ca vendorii bazelor de date să furnizeze implementări runtime pentru interfețele sale.

Exemple de astfel de vendori sunt: BEA WebLogic Enterprise Intersoft Recital Corporation, Borland International, Inc. Intersolv RogueWave Software Bulletproof Object Design SAS Institute Inc., Cyber SQL Corporation Open Horizon SCO, DataRamp OpenLink Software Sybase, Dharma Systems Inc. Oracle Symantec, Gupta Corporation Persistence Software Thunderstone, IBM Presence Information Design XDB Systems, Inc.

Arhitectura JDBC

JDBC îndeplinește task-urile proprii printr-un set de interfețe, fiecare implementată diferit de către vendorii individuali. Seturile de clase ce implementează interfețele JDBC pentru un anumit motor al unei baze de date se numesc driver JDBC. Idea este ca JDBC să ascundă specificitățile fiecărei baze de date și să lase posibilitatea programatorilor să se concentreze pe aplicațiile proprii. Figura 3.1.1 ilustrează arhitectura JDBC.

Fig. 3.1.1 – Arhitectura JDBC

O interogare a bazei de date pentru orice motor al bazei de date necesită o conexiune la baza de date, construirea unui statement SELECT și procesarea setului de rezultate. În continuare este prezentat un exemplu a unui SELECT simplu aplicație ce utilizează un driver fictiv JDBC, m1SQL. Această aplicație este o singură clasă ce obține toate rândurile dintr-o tabelă într-o bază de date M1SQL localizată pe un Solaris. Un obiect ResultSet pune la dispoziție aplicației câmpuri cheie și valoare din tabela test1. M1SQL este o mică bază de date ce suportă un subset de SQL și este ideală pentru sisteme ce au nevoie de o bază de date ce poate opera cu puține resurse sistem.

Codul sursă pentru ex:

import java.sql.*;

public class cls1 {

public static void main(String args[]) {

String url = "jdbc:m1sql://test_db.com/sql1";

Connection con = null;

try {

String driver = "com.test_domain.sql.m1sql.M1sqlDriver";

Class.forName(driver).newInstance( );

}

catch( Exception e ) {

System.out.println("Failed to load m1SQL driver.");

return;

}

try {

con = DriverManager.getConnection(url, "user_name", "");

Statement sel1 = con.createStatement( );

ResultSet result1 = sel1.executeQuery

("select t_f1, t_v1 from test1");

System.out.println("the results:");

while(result.next( )) { // process results one row at a time

int key1;

String val1;

key1 = result.getInt(1);

if( result.wasNull( ) ) {

key1 = -1;

}

val1 = result.getString(2);

if( result.wasNull( ) ) {

val1 = null;

}

System.out.println("key1 = " + key);

System.out.println("val1 = " + val);

}

catch( Exception e ) {

e.printStackTrace( );

}

finally {

if( con != null ) {

try { con.close( ); }

catch( Exception e ) { e.printStackTrace( ); }

}}}}

Șirul ce încarcă driverul m1SQL-JDBC specifică clasele motorului bazei de date este:

String url = "jdbc:m1sql://test_db.com/sql1". Codul utilizează interfețe JDBC pentru a pune la dispoziție o fațadă pentru implementarea specifică SGBD-ului. Implementarea JDBC efectuează accesul la baza de date actuală în spatele codului sursă al programatorilor. Figura 3.1.2 este o diagramă UML de clase pentru interfețele și clasele de bază JDBC.

Fig. 3.1.2 – Clasele de bază și interfețele unui API JDBC

Baze de date și Drivere

Ca SGBD-uri pot fi utilizate Microsoft SQL Server, MySQL, Sybase, etc. Dacă un motor de bază de date este instalat și o bază de date este setată, poate fi utilizat un driver JDBC pentru motorul respectiv. Motoarele bazelor de date comerciale au drivere comerciale JDBC. Pentru a exemplifica ce tipuri diferite de drivere sunt necesare, Sun a definit un sistem de categorizare a driverelor, precum în Figura 3.1.3.

Fig. 3.1.3 – Diferite tipuri de drivere JDBC

Aceste drivere folosesc o tehnologie de legături pentru a accesa o bază de date. Puntea JDBC-ODBC ce este inclusă în JDK este un bun exemplu a acestui tip de driver. Acesta pune la dispoziție un gateway pentru ODBC API. Implementările acestui API efectuează accesul la baza de date. Acest tip de driver este flexibil și nu necesită instalare de cod pe partea de client și un singur driver poate pune la dispoziție acces la multiple baze de date. Utilizând protocoalele de rețea integrate în motorul bazei de date, tipul 4 de drivere comunică direct cu baza de date folosind sockeți Java. Aceasta este cea mai directă și pură soluție Java. Deoarece aceste protocoale de rețea nu sunt niciodată documentate, acest tip de driver va fi întotdeauna disponibil alături de vendorul bazei de date.

Clasele JDBC necesare pentru crearea conexiunii

Așa cum reiese din exemplul următor, JDBC utilizează clasa (java.sql.DriverManager) și două interfețe (java.sql.Driver and java.sql.Connection) pentru conectarea la baza de date. Dacă nu este scrisă o implementare custom a JDBC, programatorul nu ar trebui să utilizeze clasa (java.sql) în aplicația sa. Acesta crează un punct de lansare a JDBC pentru conectarea la baza de date prin răspunderea la cererea conexiunii DriverManager și punerea la dispoziție a datelor referitoare la implementarea respectivă. Spre deosebire de alte părți ale JDBC, DriverManager este o clasă și nu o interfață. Principala sa responsabilitate este de a menține o listă de implementări Driver și răspunde aplicației cu cea corespunzătoare conform URL-ului cerut [69], [92].

DriverManager pune la dispoziție metodele registerDriver() și deregisterDriver( ), ce permit unei implementări Driver să se înregistreze cu DriverManager sau să fie înlăturată din lista respectivă. Clasa Connection class (java.sql.Connection) reprezintă o singură conexiune logică la baza de date. Aceasta poate fi utilizată pentru trimiterea unei serii de statement-uri SQL către baza de date și gestionează salvarea sau nu a acestor statement-uri [70].

Exemplu de mai jos descrie în mod concret procesul de conectare la baza de date.

Ex: O simplă conexiune la baza de date

import java.sql.Connection;

import java.sql.DriverManager;

import java.sql.SQLException;

public class Ex {

static public void main(String args_ex[]) {

Connection connection_ex = null;

// Procesarea liniei de comandă

if( args_ex.length != 4 ) {

System.out.println("Syntax: java Ex " +

"driver url uid password");

return;

}

try { // încărcarea driverului

Class.forName(args[0]).newInstance( );

}

catch( Exception e ) { // eroare la încărcarea driverului

e.printStackTrace( );

return;

}

try {

connection_ex = DriverManager.getConnection(args_ex[1], args_ex[2], args_ex[3]);

System.out.println("Conectare cu succes!");

}

catch( SQLException e ) {

e.printStackTrace( );

}

finally {

if( connection_ex != null ) {

try { connection_ex.close( ); }

catch( SQLException e ) {

e.printStackTrace( );

}}}}}

În conectarea la baza de date, acest exemplu captează o excepție SQLException. Aceasta este un tip de excepție prinde toate excepțiile pentru erori în lucru cu baza de date. În orice moment în care ceva nu funcționează în lucru JDBC cu baza de date, JDBC transmite o excepție SQLException. În plus de datele găsite în mod comun în excepții Java, SQLException pune la dispoziție date despre erorile specifice în lucru cu baza de date, precum SQLState. În cazul în care apar mai multe erori, driverul JDBC leagă toate excepțiile împreună.

3.2. Utilizarea Java în aplicații business – construirea unui driver specific și

modalități de obținere a rapoartelor complexe

În acest subcapitol sunt prezentate facilitățile limbajului de programare Java în aplicații de Business și cuprinde aspecte precum: conectarea la baze de date, implementarea logicii de business, realizarea diferitelor task-uri, încapsularea obiectelor și afișarea rezultatelor către utilizatorul final. Majoritatea aplicațiilor au principalele componente structurate în module ce reprezintă logica de business, iar limbajul de programare Java prin intermediul claselor, interfețelor și serviciilor pot fi implementate foarte ușor. Deoarece logica de business și design-ul sunt foarte importante pentru grupurile de programatori, arhitecți software și useri finali, alegând Java ca platformă de programare, reprezintă o bună opțiune cu privire la costuri, împărțirea sarcinilor, îmbunătățirea codului sursă și independența față de sistemul de operare. De asemenea, limbajul de programare Java permite crearea claselor customizate pentru construirea unor drivere personale de conectare, dă posibilitatea de a alege diverse căi pentru construirea rapoartelor și deploy-erea pe diferite tipuri de servere [44], [61], [108].

Java face posibilă afișarea de conținut dinamic în pagini Web prin intermediul instrumentelor specializate precum JSP (JavaServer Pages), JSF (JavaServer Faces), servlets, etc. și prin afișarea datelor din baze de date. Altă facilitate a Java este posibilitatea accesării datelor semi-structurate din fișiere XML. Datele structurate în fișiere XML sunt foarte populare în aplicații de business deoarece managementul acestor fișiere este facil, iar tehnologia open-source este mult apreciată în comparație cu tradiționalele SGBDR-uri. Un trend al producătorilor de SGBDR-uri este de a face disponibile posibilitățile de transformare a diferitelor tipuri de date în fișiere XML ce sunt mai ușor de gestionat, de stocat și de utilizat în cadrul limbajelor de programare orientate obiect.

Posibilități Java de conectare la diferite tipuri de date

Limbajul de programare Java oferă multe posibilități de conectare la diferite tipuri de date prin intermediul unui driver predefinit numit JDBC (Java Database Connectivity) ce oferă acces la bazele de date ale diferiților producători și pot manipula date structurate în tabele prin intermediul comenzilor SQL ce reprezintă argumente pentru metode cuprinse în interfețe Java. Java pune la dispoziția programatorilor bazelor de date facilități precum acces la obiecte facil și de mapare relațională, independență față de baza de date, calcul distribuit, etc. Rezultatele din bazele de date sunt returnate ca obiecte Java, iar problemele de acces sunt afișate ca excepții, astfel încât aceste obiecte pot fi utilizate în multe tipuri de aplicații.

Cea mai eficientă cale de customizare a aplicațiilor este de a construi un driver propriu de conectare ce poate fi utilizat pentru accesarea de diferite tipuri de date din diferite locații. Propria soluție este de aconstrui o clasă proprie customizată Java pentru conectarea unui client la server prin intermediul sockețiilor. Sockeții reperezintă o cale de comunicare cu alte programe utilizând standardul de descriere a fișierelor Unix/Linux. Un descriptor de fișier este un întreg asociat cu un fișier deschis. Acel fișier poate fi o conexiune rețea, un canal de comunicare, un terminal, un fișier real aflat pe disk, etc. Când este apelată rutina sistem socket(), este returnat un descriptor socket și programul comunică prin intermediul său utilizând apeluri specializate socket numite send() și recv(). Există două tipuri de sockeți. Un tip reprezintă stream sockeți și alt tip este datagram sockeți ce pot fi referiți ca SOCK_STREAM și SOCK_DGRAM. Sockeții datagram sunt numiți sockeți fără conexiune. Steam sockeții sunt căi de comunicare de bază two-way (două căi). Aceștia sunt de asemenea liberi de erori [29], [36], [119].

Stream sockeții ating un înalt nivel de calitate a transmisiei datelor prin intermediul unui protocol numit Transmission Control Protocol, cunoscut ca TCP. TCP asigură că datele ajung secvențial și liber de erori. Sockeții datagram sunt numiți fără conexiune deoarece dacă este trimisă o datagramă, poate ajunge și poate ajune într-a ordine aleatoare. Dacă ajung la destinație, datele din pachet vor fi libere de erori. Sockeții datagram folosesc protocolul IP (Internet Protocol) pentru rutare, dar nu utilizează TCP, ci utilizează User Datagram Protocol, sau UDP. Sunt fără conexiune deoarece nu trebuie să mențină o conexiune deschisă precum sockeții stream. Un pachet poate fi construit utilizând un header IP asupra sa cu informații destinație și trimis în acest fel. Nu este nevoie astfel de conexiune. Acestea sunt în general utilizate pentru transfer pachet cu pachet a datelor [128], [130].

Cea mai importantă proprietate în construirea unui driver de conectare este arhitectura client-server. Clientul se conectează la server, iar serverul așteaptă pentru conexiuni. Principalele diferențe sunt în momentul inițializării și nu în timpul funcționării normale. Sockeții fac posibilă comunicarea în cadrul rețelei și conține o adresă de IP, un protocol (TCP, UDP) și un număr de port ce permite separarea a mai multor conexiuni [59], [93], [114].

Codul sursă pentru partea de client a unui driver customizat este:

package con_cl_serv;

import java.io.*;

import java.lang.*;

import java.util.*;

class he {

byte[] hostent_intr;

}

class cntr_addr {

byte[] sockaddr_intr; // adresa connectorului

}

class prog_client

{

int PORT; // the port client will be connecting to

int MAXDATASIZE = 100; // numarul maxim de bytes ce poate fi obtinut odata

int con_client(String cl_hostname, String serv_adr, String serv_port) {

int sock_intr, numbytes;

String buf[MAXDATASIZE];

String[] hostent_intr, he;

String[] sockaddr_intr, cntr_addr; // adresa connector

if (cl_hostname.compareTo("") == 0) {

System.out.println("error usage: client hostname" + stderr);

return 1;

}

if ((he=gethostbyname(serv_adr)) == NULL) { // obtinerea host info

System.out.println("error gethostbyname");

return 1;

}

if ((sock_intr = socket(AF_INET, SOCK_STREAM, 0)) == -1) {

System.out.println("error socket");

return 1;

}

byte[] cntr_addr_in_family = AF_INET; // ordinea host byte

byte[] cntr_addr_in_port = htons(PORT); // ordine short, network byte

String[] cntr_addr_in__addr = he(hostent_intr);

memset((cntr_addr_in_zero), ’\0’, 8);

if (connect(sock_intr, sockaddr_intr,sizeof(sockaddr)) == -1) {

System.out.println("error connect");

return 1;

}

if ((numbytes=recv(sock_intr, buf, MAXDATASIZE-1, 0)) == -1) {

System.out.println("error recv");

return 1;

}

buf[numbytes] = "/0";

System.out.println("Received: ",buf);

close(sock_intr);

return 0;

}

Codul sursă pentru partea de server a unui driver customizat:

package con_cl_serv;

import java.io.*;

import java.lang.*;

import java.util.*;

class addr_intr {

byte[] sockaddr_intr;

}

class contr_addr {

byte[] sockaddr_intr;

}

class sa {

byte[] saction;

}

class prog_serv

{

void singlechild_handler(int s)

{

while(wait(NULL) > 0);

}

int con_serv() {

int sockdb1, new_db1; // listener pentru sockdb1, conexiune noua new_db1

String sockaddr_intr, addr_intr; // addresa informatiei

String sockaddr_intr, contr_addr; // adresa connectorului

int s_size;

String saction, sa;

int ok=1;

if ((sock_db1 = socket(AF_INET, SOCK_STREAM, 0)) == -1) {

System.out.println("error socket");

return 1;

}

if (setsockopt_db1(sock_db1,SOL_SOCKET,SO_REUSEADDR,ok,sizeof(int)) == -1) {

System.out.println("error set socket opt");

return 1;

}

byte[] addr_intr_in_family = AF_INET; // ordinea host byte

byte[] addr_intr_in_port = htons(PORT); // ordinea short, network byte

String addr_intr_in_addrs = INADDR_ANY; // completarea automata a IP

memset((addr_intr_in_zero), ’\0’, 8); // completarea cu zero a addr

if (bind(sockdb1, addr_intr, sizeof(sockaddr_intr))== -1) {

System.out.println("error bind");

return 1;

}

if (listen(sockdb1, BACKLOG) == -1) {

System.out.println("error listen");

return 1;

}

String sa_handler = singlechild_handler(1); // distrugerea proceselor inactive

sigemptyset(sa);

String sa_flags = SA_RESTART;

if (sigaction(SIGCHLD, sa, NULL) == -1) {

System.out.println("error sigaction");

return 1;

}

while(1) { // main accept() loop

int sin_size = sizeof(sockaddr_intr);

if ((new_intr = accept(sockdb1, (sockaddr_intr)their_addr,sin_size)) == -1) {

System.out.println("error accept");

continue;

}

System.out.println("server: conexiune de la " + inet_ntoa(their_addr.sin_addr));

if (!fork()) { // procesul copil

close(sockfd); // copilul nu are nevoie de listener

if (send(new_intr, "Message first", 14, 0) == -1) {

System.out.println("error send");

close(new_intr);

return 1;

}

close(new_intr);

}

return 0;

}

Codul sursă pentru programul talker listener ce este parte a driverului customizat:

package con_talker_listener;

import java.io.*;

import java.lang.*;

import java.util.*;

class addr_intr {

byte[] sockaddr_intr; // date despre adresa

}

class contr_addr {

byte[] sockaddr_intr; // adresa conectorului

}

class prog_listen

{

int PORT; // portul la care user-ul se va conecta

int MAXBUFLEN = 100;

int con_listener(String cl_hostname, String serv_adr, String serv_port) {

int sockdb1;

int addr_len, numbytes;

char buf[MAXBUFLEN];

if ((sockdb1 = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {

System.out.println("error socket");

return 1;

}

byte[] addr_intr_in_family = AF_INET; // ordinea host byte

byte[] addr_intr_in_port = htons(PORT); // ordinea short, network byte

String addr_intr_in_addrs = INADDR_ANY; // completarea automata a IP

memset((addr_intr_in_zero), ’\0’, 8); // completarea cu zero a addr

if (bind(sockdb1, addr_intr, sizeof(sockaddr_intr))== -1) {

System.out.println("error bind");

return 1;

}

addr_len = sizeof(sockaddr_intr);

if ((numbytes=recvfrom(sockdb1,buf, MAXBUFLEN-1, 0,(sockaddr_intr), addr_len)) == -1) {

System.out.println("error recvfrom");

return 1;

}

System.out.println("got packet from " + addr_intr_in_addrs);

System.out.println("packet is bytes long " + numbytes);

buf[numbytes] = "/0";

System.out.println("packet contains " + buf);

close(sockdb1);

return 0;

}

Codul sursă pentru talker:

class he {

byte[] hostent_intr;

}

class cntr_addr {

byte[] sockaddr_intr; // adresa connectorului

}

class prog_talker

{

int PORT; // portul la care user-ii se vor conecta

int con_talk(String cl_hostname, String serv_adr, String serv_port) {

int sock_intr, numbytes;

if (cl_hostname.compareTo("") == 0 && serv_adr.compareTo("") == 0 && serv_port.compareTo("") == 0) {

System.out.println("error usage: talker hostname message" + stderr);

return 1;

}

if ((he=gethostbyname(serv_adr)) == NULL) { // obtinerea host info

System.out.println("error gethostbyname");

return 1;

}

if ((sock_intr = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {

System.out.println("error socket");

return 1;

}

byte[] cntr_addr_in_family = AF_INET; // ordinea host byte

byte[] cntr_addr_in_port = htons(PORT); // ordinea short, network byte

String[] cntr_addr_in_addr = he(hostent_intr);

memset((cntr_addr_in_zero), ’\0’, 8);

if ((numbytes=sendto(sock_intr, serv_adr, strlen(serv_adr), 0,sockaddr_intr,sizeof(sockaddr)) == -1) {

System.out.println("error sendto");

return 1;

}

System.out.println("sent " + numbytes + " bytes to " + cntr_addr_in__addr);

close(sock_intr);

return 0;

}

În codul prezentat mai sus în programul server socket-ul este specificat, protocolul este sock stream, metoda bind asociază socket listen cu variabila serv_addr, metoda bzero completeaza cu zero variabila serv_addr. Programul server nu necesită inițializarea explicită a adresei IP, numai clientul necesită acest lucru și metoda listen construiește specificațiile server. Cele mai importante metode pentru programul server sunt: socket(), bind(), listen(), accept(), read and write. În programul client metodele corespondente sunt: socket(), bind(), connect(), read and write. Avantajul utilizării unui driver custom este acela că programatorul are control total asupra design-ului și a implementării aplicațiilor, cu puține schimbări se pot accesa orice tip de date și de asemenea acest driver poate fi îmbunătățit și utilizat de către un număr sporit de dezvoltatori software deoarece reprezintă o clasă Java, deci este open-source. În codul sursă al acestui driver se pot implementa diferite metode pentru gestionarea datelor în cadrul bazelor de date cu ajutorul comenzilor (select, insert, update, delete, create, etc.) sau din fișiere XML [68], [105].

JDBC îndeplinește task-urile sale prin intermediul unui set de interfețe Java, fiecare implementată diferit de vendori individuali. Setul de clase ce implementează interfețele JDBC pentru un motor particular al unei baze de date este denumit driver JDBC. Scopul unui JDBC este de a ascunde specificurile fiecărei baze de date și lasă programatorii să se concentreze asupra propriilor aplicații. O interogare a bazei de date pentru orice motor al unei baze de date este necesară o conexiune la baza de date, se emite un statement SELECT și se procesează setul de rezultate. În continuare este prezentat un exemplu de aplicație pe baza unei comenzi SELECT din cadrul unui JDBC driver fictive pentru m1SQL. Această aplicație este o singură clasă ce preia toate înregistrările dintr-o tabelă din baza de date m1SQL. În prima fază, are loc conectarea la baza de date prin obținerea unei conexiuni folosind un user id, din clasa JDBC DriverManager. În următoarea fază este utilizată conexiunea la baza de date pentru a crea un obiect de tip Statement ce poate executa o interogare SELECT. Un obiect ResultSet pune la dispoziția aplicației o cheie și o valoare a câmpurilor din tabela test1.

Codul sursă pentru utilizarea unui driver JDBC:

import java.sql.*;

public class cls1 {

public static void main(String args[]) {

String url = "jdbc:m1sql://test_db.com/sql1";

Connection con = null;

try {

String driver = "com.test_domain.sql.m1sql.M1sqlDriver";

Class.forName(driver).newInstance( );

}

catch( Exception e ) {

System.out.println("Failed to load m1SQL driver.");

return;

}

try {

con = DriverManager.getConnection(url, "user_name", "");

Statement sel1 = con.createStatement( );

ResultSet result1 = sel1.executeQuery

("select t_f1, t_v1 from test1");

System.out.println("the results:");

while(result.next( )) { // procesarea rezultatelor

int key1;

String val1;

key1 = result.getInt(1);

if( result.wasNull( ) ) {

key1 = -1;

}

val1 = result.getString(2);

if( result.wasNull( ) ) {

val1 = null;

}

System.out.println("key1 = " + key);

System.out.println("val1 = " + val);

}

catch( Exception e ) {

e.printStackTrace( );

}

finally {

if( con != null ) {

try { con.close( ); }

catch( Exception e ) { e.printStackTrace( ); }

}}}}

O fază când este dificil de a obține portabilitate este primul pas de obținere a conectivității, deoarece necesită un driver specific. O aplicație utilizează JDBC ca interfață ce transmite toate cererile către baza de date. Când este scris un applet Java pentru baze de date sau o aplicație, singura cerință specifică driver-ului JDBC este URL-ul bazei de date. Procesul conectării la o bază de date prin intermediul JDBC-ului este partea cea mai dificilă a utilizării unui JDBC. API-ul în sine este foarte direct, dar multe aspecte se ascund sub această suprafață. Noua extensie standard a JDBC va pune la dispoziție o cale simplificată de a crea conexiuni la bazele de date pentru a evita numeroasele probleme anterioare. Dacă apare o problemă în procesul creării unei conexiuni trebuie văzut dacă nu face parte din una din categoriile următoare:

Conexiunea eșuează cu mesajul "Class not found". Acest mesaj rezultă de obicei din faptul că driver-ul JDBC nu se găsește în CLASSPATH. Pentru a rezolva această problemă trebuie introduse fișierele .zip și .jar explicit în CLASSPATH.

Conexiunea eșuează cu mesajul "Driver not found". În acest caz trebuie înregistrat driver-ul JDBC în cadrul clasei DriverManager. Când este folosită metoda Class.forName() pentru înregistrarea driver-ul JDBC, poate fi întâlnită o inconsistență între specificațiile JDBC și unele implementări ale JVM (Java Virtual Machine). În acest caz poate fi utilizată metoda Class.forName().newInstance() pentru rezolvarea acestei probleme.

Folosind URL-ul bazei de date și alte proprietăți necesare driver-ului JDBC (în general un user id), aplicația va cere inițial implementarea java.sql.Connection din cadrul clasei DriverManager. DriverManager în schimb va căuta prin toate implementările cunoscute de java.sql.Driver pe aceea care conectează cu URL-ul pus la dispoziție. Dacă sunt epuizate toate implementările fără a găsi una potrivită este afișată o excepție și transmisă către aplicație. Dacă un driver recunoaște URL-ul, acesta construiește o conexiune la baza de date folosind proprietățile ce au fost specificate anterior. În pasul următor pune la dispozitia clasei DriverManager o implementare a obiectului java.sql.Connection ce reprezintă o conexiune la baza de date. DriverManager transmite apoi obiectul Connection înapoi aplicației. O altă parte importantă a unei aplicații de business este de a prezenta datele către utilizatorul final [33], [35], [112].

Utilizarea unui driver customizat, un driver propriu prezintă multe avantaje precum accesarea diferitelor tipuri de date, crearea propriilor obiecte, gestionarea diferitelor structuri de date inclusiv a fișierelor XML și deoarece acest driver este construit cu ajutorul limbajului de programare Java, acesta este open-source, ușor de customizat de către alți dezvoltatori de software și poate fi îmbunătățit prin implementarea de metode și clase Java. Utilizând Java pentru aplicații business, face posibilă împărțirea sarcinilor pentru designeri, dezvoltatorii de software prin utilizarea obiectelor de business încapsulate în clase și deci ușor de gestionat, de îmbunătățit și de creat noi module pentru diferite tipuri de utilizatori finali. Java face posibilă upgradarea vechilor aplicații de business și construirea de aplicații noi ce sunt mai stabile și mai ușor de utilizat de către un număr mai mare de utilizatori, iar nu în ultimul rând sunt independente din punct de vedere al sistemelor de operare [36], [44].

3.3. Utilizarea Enterprise JavaBeans în aplicații Web

Acest subcapitol prezintă facilitățile și avantajele utilizării Enterprise JavaBeans în cadrul aplicațiilor Web și subliniază aspecte precum simplicitate, portabilitatea aplicațiilor, reutilizarea componentelor, abiltatea de a construi aplicații complexe, separarea logicii de business de partea de prezentare, ușoara dezvoltare a serviciilor Web, deployerea în cadrul mai multor medii, deployerea distribuită, interoperabilitatea aplicațiilor, integrarea cu sisteme non-Java și instrumente de dezvoltare performante. Enterprise JavaBeans – EJB reprezintă o arhitectură de dezvoltare, deployere și gestionare a aplicațiilor enterprise în medii diferite. Deoarece Internetul și mediul Web este în plină dezvoltare, tot mai multe aplicații enterprise dedicate pentru intranet sau extranet devin disponibile pentru mediul Web. Platforma Java Enterprise Edition și arhitectura EJB pun la dispoziție support superior pentru aplicații Web și facilitează construirea interfețelor customizate pentru utilizatorul final.

Un enterprise bean în mod tipic comunică cu managerii de resurse precum SGBD-uri, alte enterprise bean-uri și alte aplicații enterprise. Clienții unui bean enterprise pot fi alte bean-uri enterprise, servicii Web și aplicații enterprise sau clienții unei aplicații [18]. La momentul rulării, un enterprise bean rezidă într-un container EJB.

Principalele facilități ale Enterprise JavaBeans

Enterprise bean-urile nu sunt în întregime obiecte remote (ce pot fi gestionate la distanță). Dacă un client dorește să utilizeze o interfață a unei clase enterprise bean, atunci clientul nu invocă metoda în mod direct asupra unei instanțe a bean-ului actual. Invocarea este interceptată de către un container EJB și apoi deleagă către o instanță a bean-ului. Acesta este conceptul interceptării pentru enterprise bean-uri. Prin interceptarea cererilor, containerul EJB îndeplinește în mod implicit rolul de nivel de mijloc (middleware) [112], [115]. Pentru dezvoltatorii de software există mai multă avantaje dacă utilizează enterprise bean-uri: dezvoltarea rapidă a componentelor fără scriere, depanare sau asigurarea mentenaței de cod sursă ce apelează API-uri middleware (nivel de mijloc). O parte din serviciile obținute la momentul interceptării includ:

Managementul distribuit al tranzacțiilor. Tranzacțiile permit realizarea de operații robuste deterministe într-un mediu distribuit prin setarea atributelor asupra bean-urilor enterprise. Containerul EJB pune la dispoziție un serviciu de tranzacționare, o implementare de nivel mic pentru managementul tranzacțiilor și coordonare. Serviciul de tranzacționare este expus prin Java Transaction API – JTA. JTA este o interfață de nivel înalt utilizată pentru controlul tranzacțiilor;

Partea de securitate este o considerație majoră pentru deployment-uri multi nivel. Platforma Java Enterprise Edition are un serviciu robust de securitate ce poate autoriza și autentifica utilizatori, securizând deploymenturile de vizitatori nedoriți. EJB adaugă la această securizare transparentă faptul că permite componentelor să beneficieze de un deployment securizat fără a fi necesar scrierea de cod pentru un API securizat;

Managementul resurselor și ciclul de viață al componentelor. Containerul EJB implicit manageriază resursele pentru bean-urile enterprise, precum fluxuri de date, sockeți și conexiuni la bazele de date. Ciclul de viață al bean-urilor enterprise în sine sunt manageriate, permițând containerului EJB refolosirea instanțelor enterprise bean dacă este necesar;

Persistența este o cerință naturală pentru orice deployment ce necesită storage permanent. EJB oferă asistență prin salvarea automată a obiectelor persistente de date într-un storage definit ce permite extragerea datelor la un moment ulterior;

Accesibilitate remote (la distanță). Clasa Enterprise bean nu poate fi apelată prin rețea direct deoarece o clasă a enterprise bean nu este accesibilă prin intermediul unei rețele. Obiectele disponibile prin intermediul rețelei primesc apeluri din partea clienților și delegă aceste apeluri către instanțe a clasei bean-ului. În acest mod EJB convertește automat componente standalone și nevizile prin intermediul rețelei în componente distribuite și accesibile prin intermediul rețelei;

Suport implicit. Containerele EJB în mod automat gestionează cereri concurente de la diferiți clienți. Containerele EJB pun la dispoziție suport pentru fire de execuție, instanțierea copiilor multiple a componentelor necesare prin instanțierea unei mulțimi de instanțe a unui enterprise bean și trimiterea unui fir de execuție prin intermediul fiecărei instanțe. Dacă mai mulți clienți invocă în mod simultan metodele unui bean, invocațiile sunt serializate sau este execut un pas de blocare. Containerul va permite doar unui client să apeleze un bean la un moment dat de timp. Alți clienți sunt rutați către alte instanțe ale bean-ului ale aceleași clase sau sunt forțați să aștepte. Containerul utilizează sincronizarea firelor de execuție Java pentru a rezolva această problemă. Actualul algoritm utilizat este container specific;

Transparența locațiilor componentelor. Clienți ai componentelor sunt decuplați de la datele despre locațiile specifice a componentelor ce sunt utilizate;

Monitorizarea – containerul EJB poate identifica ce metode sunt invocate, afișează un grafic de utilizare în timp real în interfața administratorului de sistem, adună date pentru o balanță de încărcare inteligentă a datelor. Un container EJB nu este necesar pentru a efectua aceste task-uri; Containerele EJB realizează aceste task-uri la momentul intercepției.

Un aspect important este acela că atât stub-ul cât și obiectul implementat pentru partea de server implementează aceeași interfață numită interfață remote (la distanță). Acest lucru înseamnă că stub-ul clonează semnăturile metodelor incluse în obiectul distribuit. Un client care apelează o metodă prin stub crede că el apelează în mod direct obiectul distribuit, dar clientul apelează un stub gol ce cunoaște cum să fie transmis prin rețea. Acest lucru se numește distribuție transparentă. Obiectul distribuit este o abstracție ce este creată prin cooperarea între stub, skeleton și implementarea obiectelor. Nici o entitate în această structură nu este obiect distribuit [18], [80]. Fig.3.3.1 ilustrează o parte din multele posibilități a interacțiunii clienților cu componenta de system EJB.

Fig. 3.3.1 – Interacțiunea clienților cu componenta sistem EJB

Un session bean reprezintă codul sursă ce se execută pentru clientul care-l apelează. Session bean-urile sunt obiecte pentru procese de business ce implementează logica de business, regulile de business, algoritmi și fluxuri. Un session bean poate executa procentul de preț, o cerere de produse, tranzacții bancare, tranzacționarea de acțiuni, operații pentru baze de date, calcule complexe și multe altele. Acestea sunt componente reutilizabile ce conțin logică pentru procesele de business. O diferență majoră între session bean-uri și alte tipuri de bean-uri este scopul pentru care acestea există. O instanță a unui session bean este un obiect cu timp de viață relativ mic. Acesta are timpul de viață echivalent cu al unei sesiuni sau al codului client ce apelează session bean-ul. Instanțele session bean-ului nu sunt share între clienți multipli. Un cod client contactează un session bean pentru a executa logica unei cereri de produse, iar containerul EJB este responsabil pentru crearea unei instanțe a acelei componente de session bean. Când clientul se deconectează mai târziu, severul de aplicații poate distruge instanța de session bean [113], [129].

Când un client invocă o metodă asupra unui bean, clientul pornește conversația cu bean-ul și starea conversațională stocată în bean trebuie să fie disponibilă pentru cererile viitoare ale aceluiași client. De aceea, containerul nu poate face pool pentru bean-uri și dinamic le asignează pentru a gestiona cereri pentru metode client, deoarece fiecare bean stochează starea în numele unui anume client. Totuși trebuie să atingă efectul de pooling pentru stateful session beans, deci trebuie să conserve resursele și să îmbunătățească scalabilitatea sistemului. Există doar un număr finit de resurse disponibile, precum memoria, conexiunile cu bazele de date și conexiunile socket. Dacă starea conversațională pe care bean-urile este mare, serverul EJB poate rămâne ușor fără resurse. Acest fapt nu era o problemă cu with stateless session beans deoarece containerul poate face pool pentru puține bean-uri necesare servirii a mii de clienți [48], [52], [116].

Dacă un bean nu a fost invocat între timp, conatinerul îl scrie pe disk. Pasivarea poate interveni atât timp cât bean-ul nu este invocat într-un apel de metodă. Containerul decide când pasivarea are sens. Există o excepție la această regulă: orice bean implicat într-o tranzacție nu poate fi pasivat până când tranzacția nu se încheie. Pentru a activa bean-uri, majoritatea containerelor folosesc în mod uzual un algoritm just-in-time. Just in time înseamnă că bean-urile ar trebui activate la cerere, pe măsură ce cererile clienților apar.

Utilitățile Enterprise JavaBeans în componente Web

Enterprise JavaBeans pot fi incluse în componente Web și cea mai importantă utilizare a lor este în cadrul serviciilor Web. Serviciile Web pun la dispoziție căi deschise și interoperabile pentru comunicarea între business-uri prin intermediul Internetului. Tehnologia serviciilor Web reprezintă o nouă paradigmă pentru aplicații enterprise pentru a integra cu alte aplicații în cadrul unei firme și care se aplică și pentru clienți, furnizori, etc. Tehnologia serviciilor Web reprezintă o facilitate importantă pentru Internet ca fiind un mediu deschis, interoperabil în care clienții și afacerile interacționează în modalități ce nu erau posibile în trecut. Aceste tehnologii Internet permit aplicațiilor software dezvoltate de vendori diferiți sau indivizi să interopereze indiferent de sistemele software sau hardware folosite pentru implementarea aplicațiilor. Componentele de bază a tehnologiilor serviciilor Web sunt are Extensible Markup Language (XML) și HyperText Transfer Protocol (HTTP), ce pun la dispoziție o cale către flexibilitate în reprezentarea structurată a informației și transferul acesteia prin intermediul rețelei [48], [118]. Alte standarde contribuie la punerea în practică a serviciilor Web, inclusiv standarde pentru descriere, accesare și publicare a serviciului:

Service description este o aplicație software ce pune pune la dispoziție servicii Web faptul că trebuie să fie o modalitate standard de descriere a serviciilor sale astfel încât alte aplicații să le poată utiliza.

Web Services Description Language – WSDL este standardul pentru descrierea unui serviciu. WSDL consistă într-un set specific de elemente XML. Dezvoltat de W3C, acest standard permite unui serviciu să fie descris de o colecție de tipuri de porturi ce consistă într-un set de operații. Operațiile pot fi sincrone – o cerere urmată de un răspuns sau asincrone – expeditorul trimite un mesaj și continuă procesarea fără să aștepte un răspuns. Fiecare operație conține o descriere a inputului și al outputului mesajelor ce descriu informația ce este așteptată și returnată de către o operație. Mesajele pot fi procedurale în mod natural descriind parametrii operației sau un document orientat ce conține un document XML, precum o cerere de produse. Tipurile de port sunt legate de porturi. Porturile pot fi accesate prin intermediul unui protocol specific și formatul de date la capătul rețelei consistând într-un host name și un număr de port TCP/IP, toate acestea fiind specificate printr-un binding. Un document WSDL are toate elementele necesare pentru a pune la dispoziție o descriere completă a unui serviciu Web într-o manieră independentă de platformă.

Service access este esențial pentru servicii Web interoperabile pentru a avea un protocol standard de rețea și formatul de date pentru schimb de informații. Simple Object Access Protocol – SOAP alături de formatele de date și tipuri system descris de schema XML standard, pune la dispoziție tehnologia pentru un protocol standard de rețea și format de dată. SOAP transmite documentelor XML documente ce conțin informația header necesară ce permite unui mesaj să fie transmis corespunzător de la server la receiver, precum și un body ce conține serviciul cerere sau mesajul răspuns. Standardul SOAP include un standard de binding HTTP, ce permite mesajelor SOAP să fie schimbate prin intermediul HTTP;

Service publishing and discovery pentru servicii Web, pentru a iniția interacțiuni cu servicii Web, trebuie să fie un mod standard pentru ca un serviciu să-i fie cunoscută existența într-un domeniu și pentru alte servicii să caute și să descopere informația sa de contact, precum un punct de rețea, protocol și operațiile pe care le suportă. Standardul Universal Description, Discovery, and Integration – UDDI face ca serviciul de publishing și discovery posibil. Standardul UDDI dezvoltat de UDDI Project, definește cum să publice și să descopere servicii Web prin intermediul regiștrilor publici sau prin directory. Utilizând această informație, serviciile pot începe interacțiunea unul cu altul într-o manieră standard.

Standardele WSDL, SOAP și UDDI formează principalele componente a tehnologiilor serviciilor Web. Aplicațiile enterprise folosesc aceste tehnologii pentru interacțiunea cu alte aplicații la client, furnizor, etc. Asemenea interacțiuni permit aplicațiilor să schimbe informații de business și conduc tranzacții rapid.

Arhitectura EJB definește cum să fie utilizat un enterprise bean pentru implementarea serviciilor Web endpoint. Serviciile Web pentru specificații J2EE descriu cum se dezvoltă și deployază serviciile Web clienți și servere într-un mediu J2EE [48], [80]. Pentru a face o utilizare clară a Enterprise JavaBeans pot fi detaliate exemple ale Entity Beans și Details Object ce modelează o parte a sistemului de producție și care suportă vederi client remote (la distanță). Această parte a sistemului are atributele număr componentă, descriere componentă, numele furnizorului și prețul componentei. Următorul cod sursă descrie o interfață home a Enterprise Bean Part:

package ejb.ex1;

import java.rmi.RemoteException;

import javax.ejb.EJBHome;

import javax.ejb.CreateException;

import javax.ejb.FinderException;

public interface PartExHome extends EJBHome {

public Part create(String partNumber)

throws CreateException, RemoteException;

public Part findByPrimaryKey(String partNumber)

throws FinderException, RemoteException;

}

O componentă este identificată cu un număr de înregistrare. Acesta este asignat când este generată o nouă intrare. Numărul de înregistrare a componentei servește ca cheie de înregistrare și este posibil de a identifica o anumită componentă cu numărul de înregistrare respectiv. Următorul cod sursă descrie interfața remote (la distanță) a bean-ului PartEx:

package ejb.ex1;

import java.rmi.RemoteException;

import javax.ejb.EJBObject;

public interface PartEx extends EJBObject {

public void setPartDetails(PartDetails pd)

throws RemoteException;

public PartDetails getPartDetails()

throws RemoteException;

}

Cu un număr mare de metode get/set pentru fiecare atribut al unui entity bean, interfața remote descrie o metodă get și o metodă set. Ca parametru și valoare returnată există un tip PartDetails, ce conține toate atributele unui entity bean. Toate atributele unui Enterprise Bean sunt transmise în mod bundled (implicit), ce are ca efect o eficiență mărită, deoarece pentru transmiterea atributelor este necesar accesul printr-o rețea. Următorul cod sursă descrie implementarea clasei PartDetails:

package ejb.ex1;

public class PartDetailsEx implements java.io.Serializable {

String partNumber;

String partDescription;

String supplierName;

float price;

public PartDetails() {

}

public String getPartNumber() {

return partNumber;

}

public void setPartDescription(String desc) {

partDescription = desc;

}

public String getPartDescription() {

return partDescription;

}

public void setSupplierName(String name) {

supplierName = name;

}

public String getSupplierName() {

return supplierName;

}

public void setPrice(float p) {

price = p;

}

public float getPrice() {

return price;

}

Enterprise JavaBeans sunt cele mai importante componente ale unei aplicații de business J2EE și acestea include logică de business și pot fi utilizate prin intermediul interfețelor din Presentation Tier. Aceste tipuri de bean-uri sunt specifice pentru Business Tier și pun la dispoziție obiecte java ce reprezintă rezultatele din cererile clienți ce sunt procesate în accord cu logica de business a aplicațiilor [48], [116]. Clienții EJB lucrează cu o componentă interfață expusă și cererile lor sunt gestionate de containerul EJB ce poate conține părți ale aplicațiilor enterprise și accesul la resursele system precum obiecte din bazele de date sau alte enterprise bean-uri. Astfel enterprise bean-urile sunt ușor de utilizat, independente de platforme (sisteme de operare) și pot fi utilizate în diferite componente ale aplicațiilor de business.

3.4. Arhitectura și design-ul dependințelor obiectelor Java în aplicații Web

Acest subcapitol prezintă avantajele utilizării Spring Framework și Hibernate pentru Java Web Applications având ca platformă Java EE (Enterprise Edition) care pune la dispoziție serviciile system esențiale prin intermediul arhitecturii bazate pe container. Acest fapt permite separarea clară a rolurilor și astfel programatorii sistem se pot concentra pe dezvoltarea serviciilor de nivel jos și programatorii de aplicații se pot concentra asupra dezvoltării logicii de business și a prezentării. Spring Framework reprezintă o aplicație framework open sorce ce este compatibilă cu platforma Java și a fost portată pe platforma .NET de asemenea. Spring pune la dispoziție un framework multi nivel cuprinzător ce poate fi utilizat în toate nivelele unei aplicații Java enterprise. Aceasta ajută la structurarea aplicațiilor cu componente de tipul out-of-the-box (în afara aplicației) precum și integrarea cu cel mai bun framework single-tier (nivel singular) și pune la dispoziție un model simplu de programare bazat pe POJOs (Plain Old Java Object) și le face ușor de testat deoarece aceste componente pot rula în afara containerelor server. Cu Hibernate pot fi construite aplicații înalt performante Java pentru baze de date ce sunt flexibile, persistente rapid obiect/relațional și cu servicii de interogare. Hibernate relaționează cu sistemul de mapare obiect, sistem avansat de interogare și suport tranzacțional.

Principalele facilități ale Spring Framework

Spring Framework este un framework aplicație open source proiectată pentru platforma Java și este portată pe platforma .NET de asemenea. Platforma Java EE a atins un mare succes în standardizarea serviciilor middleware (nivel de mijloc) de nivel jos prin diverse API-uri ca EJB, JTA și JMS. Acest lucru a fost posibil deoarece atât vendorii comerciali cât și comunitatea open source vin împreună, realizând imensul potențial al platformei bazate pe standardul Java. Chiar dacă platforma Java EE este larg răspândită, dezvoltarea aplicațiilor multi tier (multi nivel) pe această platformă încă necesită un efort susținut.

EJB-urile au fost proiectate pentru a ușura dezvoltarea aplicațiilor tranzacționale și distribuite. Deși chiar și cea mai mică aplicație pentru baze de date necesită tranzacții, dar nu necesită sa fie distribuită. Suprautilizarea EJB-urilor, în special session bean-urile pentru a simplifica logica de business, duce la distribuția inclusă în modelul component al aplicației. Aplicațiile distribuite sunt complexe și consumatoare mari de cicluri CPU pentru procesare. Acestea duc la construirea de cod excesiv și duplicat alături de metadate. Accesare unei componente aplicație distribuită necesită trafic rețea și activități de marshalling și unmarshalling a unor largi seturi de date. Neutilizarea obiectelor distribuite conduce deseori la situații în care simple aplicații nu performează la nivelul dorit. Java EE include multă tehnologie și API-uri ce sunt deosebit de complexe. Entity bean API, de exemplu necesită un efort semnificativ de învățare și în schimb oferă beneficii limitate pentru o aplicație. Deoarece componentele Java EE rulează în interiorul containerului serverului de aplicație, ele sunt dificil de testat. Acest lucru previne dezvoltarea test-driven [46], [84], [125].

În cazul în care echipa de dezvoltare este mai productivă în Struts, poate fi folosit în locul lui Spring MVC în timp ce restul aplicației utilizează componente Spring și facilități precum JDBC și tranzacții, astfel încât dezvoltatorii nu necesită să deploy-eze întregul framework Spring. Ei necesită doar modulele relevante precum Spring DAO alături de containerul Spring IOC și librăriile Struts. Figura 3.4.1 prezintă cele mai importante module ale Spring Framework.

Fig. 3.4.1 – principalele blocuri ale Spring Framework

Modulele Core (miez) formează esențialul pentru framework-ul Spring. Toate celelalte module Spring sunt dependente de acest modul. Este de asemenea numit containerul IOC (Inversion of Control) și este suportul central pentru Spring al dependency injection (DI). IOC este important în dezvoltatrea de software precum și pentru controlul fluxului aplicațiilor în timp ce asigură o înaltă coeziune și cuplare joasă. IOC este fundamental pentru orice framework. Cu IOC, un obiect aplicație este în mod tipic înregistrat cu framework-ul ce preia responsabilitatea invocării metodelor asupra obiectului înregistrat la momentul potrivit sau eveniment. Controlul este inversat deoarece în loc ca, codul aplicației să invoce framework API, procesul se întâmplă în mod opus, astfel încât IOC este principalul ce permite altui obiect sau framework să invoce metode asupra obiectelor aplicațiilor în funcție de evenimentele potrivite [51], [55], [123].

Instanțierea directă cea mai simplă formă de DI. Obiectul dependent este direct instanțiat folosind operatorul new, așa cum este arătat în codul de mai jos.

Ex.1 Products.java: Folosind Direct Instantiation

public class Products{

public Product getProduct(){

Product it_product = new LCD_monitor();

return it_product;

}}

Direct instantiation mărește cuplajul și imprăștie codul de creare al obiectelor în cadrul unei aplicații, făcând dificilă menținerea unei unități de test. Factory helper este o strategie pentru injectarea dependințelor comună și utilizată pe scară largă. Este bazată pe modelul de design al metodei GOF factory. Metoda factory consolidează utilizarea operatorului new și pune la dispoziție instanțierea obiectului potrivit bazat pe un anumit input. Acest lucru este demonstrat în următorul cod.

Ex.2 Products.java: Folosind Factory Helper

public class Products{

public Product getProduct(){

Product it_product = ProductFactory.getInstance("LCD_monitor");

return it_product;

}}

Folosind un factory se promovează un design obiect de cea mai bună practică numită program to interface (P2I). Acest pricipiu stipulează faptul că obiectele concrete trebuie să implementeze o interfață ce este utilizată în programul apelant și nu în cadrul obiectului însuși. De aceea, acesta poate ușor substitui o implementare diferită cu puțin impact asupra codului client și astfel nu există dependință directă asupra implementării concrete conducănd la cuplaj de nivel mic. Următorul cod arată interfața Product.

Ex. 3. Product.java

public interface Product{

public Price getPrice();

//other methods

}

Produsul LCD_monitor pune la dispoziție o implementare concretă a interfeței Product, precum în codul următor.

Ex. 4. LCD_monitor.java

public class LCD_monitor implements Product{

//…implementation of methods defined in Product

// …implementation of other methods

}

Acest model consolidează crearea obiect într-un număr limitat de clase factory, este ușor de menținut. Cu un factory helper, este posibil să fie făcută crearea de obiecte configurabilă. Poate fi definită o implementare concretă ce dorește să pună la dispoziție în anumite proprietăți sau fișiere de configurare XML, făcându-le interschimbabile [101], [103], [107].

Soluții Hibernate

Hibernate facilitează construirea de aplicații performante și robuste pentru baze de date cu Java. Hibernate pune la dispoziție sistemul său de mapare, cu mecanismul său avansat de interogare și suport tranzacțional. Hibernate pune la dispoziție soluții ce pot fi integrate cu Swing, JSP și chiar EJB-uri utilizând persistența bean-managed. Principalele facilități ale Hibernate sunt:

Construirea aplicațiilor case study: pornind de la fișierele de mapare obiect/relațional, cod Java și scheme existente;

Scrierea interogărilor Hibernate folosind HQLHibernate o extensie a SQL orientat-obiect;

Utilizarea Hibernate cu criterii Java-based și exemple sau nativ SQL;

Fișierul de mapare Hibernate în detaliu: o referință completă;

Hibernate gestionează clase și relații din bazele de date;

Manageriază sesiuni și tranzacții la nivelul bazelor de date;

Urmărește și optimizează performanța cu p6spy și IronTrack SQL;

În mod automat generează scripturi DDL ce crează, modifică și dropează tabele.

Prin combinarea claselor obișnuite Java cu descriptori XML, Hibernate pune la dispoziție o vedere orientată-obiect a bazei de date relaționale. Majoritatea aplicațiilor Java accesează o bază de date relațională via JDBC (Java Database Connectivity). Prin utilizarea Hibernate, un dezvoltator nu trebuie să scrie cod de integrare custom JDBC și se poate concentra pe scrierea părții de prezentare și a logicii de business a aplicației. Aceasta nu trebuie să fie o activitate absolute necesară; poate fi utilizată o aplicație existentă JDBC în conjuncție cu Hibernate, migrând accesul pe parcursul aplicației.

În tehnologia obiect/relațional sunt disponibile pentru o varietate mare de medii de programare, Hibernate este un sistem Java-based. Pentru dezvoltatorii care au construit aplicații Java utilizând JDBC au experimentat dificultăți datorită nepotrivirilor dintre Java și SQL. În continuare este prezentat un simplu cod JDBC pentru o aplicație:

package ex_app1;

import java.sql.*;

public class JDBCClient

{

static void printColumn(String in)

{

System.out.print(in);

System.out.print(" | ");

}

public static void main(String[] args)

{

Driver myDriver = null;

Connection myConnection = null;

try

{

Driver1 = (Driver)Class.forName("com.mysql.jdbc.Driver").newInstance();

Conn1 = DriverManager.getConnection(

"jdbc:mysql://localhost/sample_app1", "root","");

Statement Statement1 =

Conn1.createStatement();

ResultSet Results1 = Statement1.executeQuery(

"SELECT product_id, quantity, product_name FROM Products");

while (Results1.next())

{

printColumn(Results1.getLong("product_id") + "");

printColumn(Results1.getInt("quantity") + "");

printColumn(Results1.getString("product_name"));

System.out.println();

}

} catch (Exception e)

{

e.printStackTrace();

} finally

{

try

{

if (Conn1 != null)

Conn1.close();

} catch (Exception e)

{

}

Extragerea datelor individuale este supusă erorilor și este consumatoare de timp. Este ușor să faci greșeli în orice șir de cod scris, iar cod complex SQL poate conduce la cod specific bazelor de date. În comparație este prezentat un cod similar pentru extragere ce utilizează Hibernate, prezentat în continuare:

package ex_hibernate_app1;

import net.sf.hibernate.*;

import net.sf.hibernate.cfg.*;

public class HibernateClient

{

static String[] props =

{

"hibernate.connection.driver_class",

"com.mysql.jdbc.Driver",

"hibernate.connection.url",

"jdbc:mysql://localhost/ sample_app1",

"hibernate.connection.username", "root",

"hibernate.connection.password", "",

"hibernate.dialect",

"net.sf.hibernate.dialect.MySQLDialect",

"hibernate.show_sql", "true"

};

static void printColumn(String in)

{

System.out.print(in);

System.out.print(" | ");

}

public static void main(String[] args)

{

try

{

// One-time only configuration code, run only

// during application initialization.

Configuration Configuration1 = new

Configuration();

Configuration1.addClass(

ex_hibernate_app1.Products.class);

for (int i = 0; i < props.length; i = i + 2)

Configuration1.setProperty(props[i], props[i+1]);

SessionFactory sessionFactory =

Configuration1.buildSessionFactory();

Session hibernateSession =

sessionFactory.openSession();

Criteria query = hibernateSession.createCriteria(

ex_hibernate_app1.Products.class);

// loop over the results

java.util.Iterator results =

query.list().iterator();

while (results.hasNext())

{

// the result set is cast to the

// Products

// object directly – no manual binding

// required.

Products Products1 = (Products)results.next();

printColumn(Products1.getId_product() + "");

printColumn(Products1.getQuantity() + "");

printColumn(Products1.getProduct_name());

}

} catch (Exception e)

{

e.printStackTrace();

}

După examinarea codului de mai sus, este evident că nu există șiruri codate SQL în interogare. În plus, nu este necesară extragerea de date utilizând interogări JDBC result set; acesta lucrează cu obiecte returnate Products. În acest caz, atât codul sursă Java pentru clasa Products și schema pentru tabela corespondentă Products sunt generate automat de Hibernate. Este posibil să fie exprimate relații complexe, inclusiv unu-la-mulți și chiar mulți-la-mulți, utilizând Hibernate, cu modul intelligent de încărcare Hibernate și de cache al datelor, automat generând join-ere complexe pentru a extrage în mod optim date. Această legare a codului Java și schema bazei de date este cunoscută ca maparea obiect/relație [121].

3.5. Elemente de noutate în domeniul aplicațiilor Web pentru SGBD-uri, analiză costuri, implementare și funcționalități pentru diverse soluții software implementate în acest domeniu

Principalele caracteristici cuprinse în aplicațiile Web pentru SGBD-uri

Pentru conceperea aplicațiilor Web se întocmesc scheme relaționale, diagrame, documentații detaliate, specificații tehnice, etc ce pot fi organizate și structurate prin UML (Unified Modeling Language) – limbaj universal pentru software design ce crează pattern-uri în folosirea obiectelor de către dezvoltatori software si prin UBL (Universal Business Language) – limbaj universal de business ce cuprinde biblioteci XML ce modelează documente specifice de business (facturi, comenzi, etc.). Un rol important în construirea aplicațiilor Web îl au fișierele XML. Prin adăugarea de constrângeri semantice, limbajele pentru construirea aplicațiilor pot fi implementate în XML. În mod special XML este folosit ca limbaj de specificație pentru alte limbaje de construire a aplicațiilor Web. Există tehnici tradiționale de procesare a fișierelor XML, precum: folosirea limbajelor de programare și SAX API (Simple API for XML – un API Java), limbaje de programare și DOM API (Document Object Model – o componentă API a Java API for XML), utilizarea motoarelor de transformare și filtrare.

Stadiului actual în domenuiul aplicațiilor Web pentru SGBD-uri

În momentul actual, domeniul aplicațiilor Web pentru SGBD-uri este puțin cunoscut și foarte puțin dezvoltat în țara noastră. În general firmele românești folosesc SGBD-uri de generație veche precum Microsoft Access, Visual FoxPro, etc., acestea oferind foarte puține facilități în domeniul Web și oferind performanțe scăzute atât pentru utilizatori, cât și pentru dezvoltatori. În general firmele din țara noastră adoptă soluții Microsoft ce nu sunt gratuite, dar oferă o relativă ușurință în dezvoltarea aplicațiilor. Aceste aplicații au probleme de scalabilitate, se bazează pe SGBD-uri cu performanțe medii, nu oferă o protecție bună a datelor și rulează pe platforme Windows. Aceste soluții sunt costisitoare și oferă puține beneficii firmelor ce le achiziționează.

Pe termen lung sunt greu de modificat, trebuie reactualizate licențele de funcționare și nu separă activitățile dezvoltatorilor de aplicații de cei care se ocupă cu design-ul aplicațiilor. Există serioase incompatibilități între versiuni diferite de Windows sau de SGBD-uri sau de framework-uri de dezvoltare, astfel încât schimbarea unei astfel de componente implică schimbarea celorlalte componente pentru a rezolva problemele de compatibilitate.

Elemente de noutate în domeniul aplicațiilor Web pentru SGBD-uri (contribuții personale)

Ca element de noutate lucrarea de cercetare își propune definirea unui driver general de accesare a diferitelor tipuri de date, în limbajul Java. Acest driver va fi inclus într-un pachet Java, ce va extinde capacitățile și posibilitățile pachetelor existente în domeniul accesării datelor structurate sau semistructurate.

O modalitate de realizare a acestui driver ar putea fi transformarea datelor din baze de date în fișiere XML și transformarea acestora în clase Java, utile în cadrul aplicațiilor Web. Aceste clase vor fi bean-uri ce vor mapa entități prezente în baze de date, astfel încât orice modificare asupra lor se va reflecta automat în baza de date.

O altă modalitate de accesare a datelor prin limbajul Java este de a testa ce tipuri de date vor fi utile aplicației Web și includerea driverelor specifice în driverul general de accesare și conectare la baza de date.

Conexiunea permanentă de la nivelul aplicației Web va fi în funcție de tipul de date utilizat în logica de business.

În general transformarea diferitelor tipuri de date într-un singur tip de date gestionat de un SGBD ce conține multiple facilități permite accesarea facilă a acestora, minimizând costurile și optimizând modul de funcționare al aplicațiilor Web construite cu Java.

Pentru date semistructurate sau prezente în SGBD-uri de generație veche este utilă transformarea acestora în fișiere XML ce pot fi ușor accesate și gestionate de limbajul Java și astfel fiind posibile construirea de aplicații Web ce oferă facilități superioare utilizatorilor în comparație cu aplicații de generație anterioară.

Limbajul Java separă logica de business (modificări asupra entităților din baza de date) de partea ce reprezintă interfața cu utilizatorii finali ai aplicațiilor Web, prin utilizarea CMP Beans și EJB Beans.

Aplicațiile Web pot fi construite cu ajutorul unei game largi de limbaje de programare precum Java, PHP, C#, Perl, etc ce fac posibil accesul la date stocate în baze de date gestionate de SGBD-uri precum Oracle, MySQL, Microsoft SQL Server, Microsoft Access, Microsoft Visual Fox, dar și date semistructurate ce se regăsesc în fișiere XML. Printre avantajele aplicațiilor Web se pot enumera: un număr mai mare de utilizatori, accesul prin Internet la date stocate în baze de date, avantaje multiple atât pentru clienți cât și pentru producători.

Aplicațiile Web pentru SGBD-uri construite pe baza unor soluții free sau open-source sunt ușor de modificat, upgradat și separă activitățile desfășurate de programatori de activitățile celor care se ocupă cu design-ul sau grafica acestor aplicații. Utilizarea în cadrul acestor aplicații a limbajului de programare orientat obiect Java, face posibilă accesarea unor surse mari de date aflate în diferite SGBD-uri sau în fișiere de tip XML. Limbajul Java oferă posibilitatea refolosirii codului sursă existent în diverse aplicații, reutilizarea claselor și obiectelor, precum și modificarea codului sursă deja existent.

Acest tip de aplicații oferă beneficii majore și permit accesarea diverselor tipuri de date aflate în SGBD-uri diferite și în locații diferite, în timp real și le face disponibile unei game largi de utilizatori și beneficiari. Pe baza lor se pot face analize pertinente, se pot efectua activități de tip data mining, sau pot fi create grafice, situații statistice necesare în luarea deciziilor economice. Adoptarea limbajului Java împreună cu SGBD-uri de ultimă generație, oferă aplicațiilor Web flexibilitate, acuratețe, timpi de răspuns mici, stabilitate, ușurință în utilizare și posibilități multiple de modificare și upgradare a acestora.

Trebuie să ținem cont de faptul că aceste soluții sunt free și open-source, fapt ce permite acces la surse de cod larg răspândite și des utilizate de o comunitate dezvoltată de programatori ce utilizează forumuri și blog-uri ce permit rezolvarea în timp util a unor probleme apărute în procesul de dezvoltare sau în procesul de utilizare a acestor aplicații. Stabilitatea și performanțele oferite de aceste aplicații sunt net superioare celor de tip stand-alone, iar adoptarea unor astfel de soluții conduce la îmbunătățirea activităților economice, reducerea timpilor de răspuns necesari pentru obținerea diverselor rapoarte, oferă facilități unei game largi de utilizatori și permite integrarea datelor aflate în locații și surse diferite, gestionate de SGBD-uri diferite. Aceste aplicații Web pentru SGBD-uri fac posibile dezvoltarea relațiilor economice între clienți și parteneri de afaceri prin inermediul rețelei Web.

Construirea și implementarea unui driver general de conectare bazat pe limbajul de programare orientat obiect Java, asigură accesul la surse de date diferite, aflate în SGBD-uri diferite, de către aplicații Web. Avantajul major al acestui driver general este că surse neomogene de date devin disponibile acestor tipuri de aplicații, iar transformarea lor în clase și obiecte Java permite prelucrarea într-un mod unitar, afișarea, interogarea și actualizarea acestora. În acest mod Java devine platforma comună pentru SGBD-uri diferite, cât și pentru date semistructurate aflate în fișiere de anumite tipuri. În plus limbajul de programare Java este nativ pentru mediul Web, iar aplicațiile Web pot astfel accesa în mod direct date structurate în baze de date, le pot modifica, actualiza, afișa, devenind disponibile unei game largi de utilizatori.

Încapsularea datelor în bean-uri Java conduce la ușurința construirii și îmbunătățirii aplicațiilor Web, permite accesul la diverse servicii Web și nu în ultimul rând pune la dispoziție surse diverse de date utilizatorilor aflați în locații diferite.

O altă modalitate de accesare a datelor neomogene aflate în SGBD-uri diferite sau a datelor semistructurate aflate în fișiere este prin intermediul fișierelor XML ce oferă un standard unic de structurare a datelor, practic pune la dispoziție șabloane de date, structurare sub formă de înregistrări sau perechi descriere câmpuri – valori. Majoritatea SGBD-urilor pun la dispoziție transformarea datelor în fișiere XML, ce reprezintă un standard internațional în domeniul informaticii, astfel datele devenind disponibile unei game largi de limbaje de programare. Legătura între aplicațiile Web și aceste tipuri de fișiere se poate realiza prin intermediul limbajului Java, ce conține pachete dedicate pentru accesarea acestor fișiere și transformarea datelor în clase Java. Limbajul de programarea Java lucrează nativ cu fișiere de tip XML și prezintă diverse plug-inuri ce permit interogarea, modificarea, actualizarea datelor, dar și posibilitatea transformării datelor din clase Java în fișiere tip XML ce diferă ca format și conținut de fișierele inițiale.

De asemenea, o altă posibilitate de a accesa date aflate în SGBD-uri diferite sau date semistructurate aflate în fișiere este prin transformarea și încărcarea acestora într-un SGBD unic de generație nouă, prin intermediul instrumentelor ETL și construirea depozitelor de date (data warehouse). Avantajul construirii de data warehouse este imens, chiar dacă procesele de încărcare și transformare a datelor necesită un efort de programare considerabil, dar reunirea acestora în cadrul unui SGBD unic permite integrarea acestora în aplicații complexe și oferă posibilități multiple de interogare și data mining în timpi net superiori altor aplicații. Structurarea acestora în cuburi și dimensiuni face posibilă stocarea datelor într-un mod unic după ce datele au fost validate, corectate și transformate prin procedee specifice, iar agregarea lor în comparație cu dimensiunea timp permite construirea unor rapoarte comparative foarte performante. Această modalitate de integrare a datelor este foarte utilă și des aplicată în practică de către diverse firme, datorită avantajelor evidente.

Construirea unui driver specific de conectare (contribuție personală)

Limbajul de programare Java oferă multe posibilități de conectare la diferite tipuri de date prin intermediul unui driver predefinit numit JDBC (Java Database Connectivity) ce oferă acces la bazele de date ale diferiților producători și pot manipula date structurate în tabele prin intermediul comenzilor SQL ce reprezintă argumente pentru metode cuprinse în interfețe Java. Java pune la dispoziția programatorilor bazelor de date facilități precum acces la obiecte facil și de mapare relațională, independență față de baza de date, calcul distribuit, etc. Rezultatele din bazele de date sunt returnate ca obiecte Java, iar problemele de acces sunt afișate ca excepții, astfel încât aceste obiecte pot fi utilizate în multe tipuri de aplicații.

Cea mai eficientă cale de customizare a aplicațiilor este de a construi un driver propriu de conectare ce poate fi utilizat pentru accesarea de diferite tipuri de date din diferite locații. Propria soluție este de aconstrui o clasă proprie customizată Java pentru conectarea unui client la server prin intermediul sockețiilor. Sockeții reperezintă o cale de comunicare cu alte programe utilizând standardul de descriere a fișierelor Unix/Linux. Un descriptor de fișier este un întreg asociat cu un fișier deschis. Acel fișier poate fi o conexiune rețea, un canal de comunicare, un terminal, un fișier real aflat pe disk, etc. Când este apelată rutina sistem socket(), este returnat un descriptor socket și programul comunică prin intermediul său utilizând apeluri specializate socket numite send() și recv(). Există două tipuri de sockeți. Un tip reprezintă stream sockeți și alt tip este datagram sockeți ce pot fi referiți ca SOCK_STREAM și SOCK_DGRAM. Sockeții datagram sunt numiți sockeți fără conexiune. Steam sockeții sunt căi de comunicare de bază two-way (două căi). Aceștia sunt de asemenea liberi de erori.

Stream sockeții ating un înalt nivel de calitate a transmisiei datelor prin intermediul unui protocol numit Transmission Control Protocol, cunoscut ca TCP. TCP asigură că datele ajung secvențial și liber de erori. Sockeții datagram sunt numiți fără conexiune deoarece dacă este trimisă o datagramă, poate ajunge și poate ajune într-a ordine aleatoare. Dacă ajung la destinație, datele din pachet vor fi libere de erori. Sockeții datagram folosesc protocolul IP (Internet Protocol) pentru rutare, dar nu utilizează TCP, ci utilizează User Datagram Protocol, sau UDP. Sunt fără conexiune deoarece nu trebuie să mențină o conexiune deschisă precum sockeții stream. Un pachet poate fi construit utilizând un header IP asupra sa cu informații destinație și trimis în acest fel. Nu este nevoie astfel de conexiune. Acestea sunt în general utilizate pentru transfer pachet cu pachet a datelor.

Fig. 3.5.1 – Structura socket conectare

Cea mai importantă proprietate în construirea unui driver de conectare este arhitectura client-server. Clientul se conectează la server, iar serverul așteaptă pentru conexiuni. Principalele diferențe sunt în momentul inițializării și nu în timpul funcționării normale. Sockeții fac posibilă comunicarea în cadrul rețelei și conține o adresă de IP, un protocol (TCP, UDP) și un număr de port ce permite separarea a mai multor conexiuni.

Codul sursă pentru partea de client a unui driver customizat este:

package con_cl_serv;

import java.io.*;

import java.lang.*;

import java.util.*;

class he {

byte[] hostent_intr;

}

class cntr_addr {

byte[] sockaddr_intr; // adresa connectorului

}

class prog_client

{

int PORT; // the port client will be connecting to

int MAXDATASIZE = 100; // numarul maxim de bytes ce poate fi obtinut odata

int con_client(String cl_hostname, String serv_adr, String serv_port) {

int sock_intr, numbytes;

String buf[MAXDATASIZE];

String[] hostent_intr, he;

String[] sockaddr_intr, cntr_addr; // adresa connector

if (cl_hostname.compareTo("") == 0) {

System.out.println("error usage: client hostname" + stderr);

return 1;

}

if ((he=gethostbyname(serv_adr)) == NULL) { // obtinerea host info

System.out.println("error gethostbyname");

return 1;

}

if ((sock_intr = socket(AF_INET, SOCK_STREAM, 0)) == -1) {

System.out.println("error socket");

return 1;

}

byte[] cntr_addr_in_family = AF_INET; // ordinea host byte

byte[] cntr_addr_in_port = htons(PORT); // ordine short, network byte

String[] cntr_addr_in__addr = he(hostent_intr);

memset((cntr_addr_in_zero), ’\0’, 8);

if (connect(sock_intr, sockaddr_intr,sizeof(sockaddr)) == -1) {

System.out.println("error connect");

return 1;

}

if ((numbytes=recv(sock_intr, buf, MAXDATASIZE-1, 0)) == -1) {

System.out.println("error recv");

return 1;

}

buf[numbytes] = "/0";

System.out.println("Received: ",buf);

close(sock_intr);

return 0;

}

Codul sursă pentru partea de server a unui driver customizat:

package con_cl_serv;

import java.io.*;

import java.lang.*;

import java.util.*;

class addr_intr {

byte[] sockaddr_intr;

}

class contr_addr {

byte[] sockaddr_intr;

}

class sa {

byte[] saction;

}

class prog_serv

{

void singlechild_handler(int s)

{

while(wait(NULL) > 0);

}

int con_serv() {

int sockdb1, new_db1; // listener pentru sockdb1, conexiune noua new_db1

String sockaddr_intr, addr_intr; // addresa informatiei

String sockaddr_intr, contr_addr; // adresa connectorului

int s_size;

String saction, sa;

int ok=1;

if ((sock_db1 = socket(AF_INET, SOCK_STREAM, 0)) == -1) {

System.out.println("error socket");

return 1;

}

if (setsockopt_db1(sock_db1,SOL_SOCKET,SO_REUSEADDR,ok,sizeof(int)) == -1) {

System.out.println("error set socket opt");

return 1;

}

byte[] addr_intr_in_family = AF_INET; // ordinea host byte

byte[] addr_intr_in_port = htons(PORT); // ordinea short, network byte

String addr_intr_in_addrs = INADDR_ANY; // completarea automata a IP

memset((addr_intr_in_zero), ’\0’, 8); // completarea cu zero a addr

if (bind(sockdb1, addr_intr, sizeof(sockaddr_intr))== -1) {

System.out.println("error bind");

return 1;

}

if (listen(sockdb1, BACKLOG) == -1) {

System.out.println("error listen");

return 1;

}

String sa_handler = singlechild_handler(1); // distrugerea proceselor inactive

sigemptyset(sa);

String sa_flags = SA_RESTART;

if (sigaction(SIGCHLD, sa, NULL) == -1) {

System.out.println("error sigaction");

return 1;

}

while(1) { // main accept() loop

int sin_size = sizeof(sockaddr_intr);

if ((new_intr = accept(sockdb1, (sockaddr_intr)their_addr,sin_size)) == -1) {

System.out.println("error accept");

continue;

}

System.out.println("server: conexiune de la " + inet_ntoa(their_addr.sin_addr));

if (!fork()) { // procesul copil

close(sockfd); // copilul nu are nevoie de listener

if (send(new_intr, "Message first", 14, 0) == -1) {

System.out.println("error send");

close(new_intr);

return 1;

}

close(new_intr);

}

return 0;

}

Codul sursă pentru programul talker listener ce este parte a driverului customizat:

package con_talker_listener;

import java.io.*;

import java.lang.*;

import java.util.*;

class addr_intr {

byte[] sockaddr_intr; // date despre adresa

}

class contr_addr {

byte[] sockaddr_intr; // adresa conectorului

}

class prog_listen

{

int PORT; // portul la care user-ul se va conecta

int MAXBUFLEN = 100;

int con_listener(String cl_hostname, String serv_adr, String serv_port) {

int sockdb1;

int addr_len, numbytes;

char buf[MAXBUFLEN];

if ((sockdb1 = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {

System.out.println("error socket");

return 1;

}

byte[] addr_intr_in_family = AF_INET; // ordinea host byte

byte[] addr_intr_in_port = htons(PORT); // ordinea short, network byte

String addr_intr_in_addrs = INADDR_ANY; // completarea automata a IP

memset((addr_intr_in_zero), ’\0’, 8); // completarea cu zero a addr

if (bind(sockdb1, addr_intr, sizeof(sockaddr_intr))== -1) {

System.out.println("error bind");

return 1;

}

addr_len = sizeof(sockaddr_intr);

if ((numbytes=recvfrom(sockdb1,buf, MAXBUFLEN-1, 0,(sockaddr_intr), addr_len)) == -1) {

System.out.println("error recvfrom");

return 1;

}

System.out.println("got packet from " + addr_intr_in_addrs);

System.out.println("packet is bytes long " + numbytes);

buf[numbytes] = "/0";

System.out.println("packet contains " + buf);

close(sockdb1);

return 0;

}

Codul sursă pentru talker:

class he {

byte[] hostent_intr;

}

class cntr_addr {

byte[] sockaddr_intr; // adresa connectorului

}

class prog_talker

{

int PORT; // portul la care user-ii se vor conecta

int con_talk(String cl_hostname, String serv_adr, String serv_port) {

int sock_intr, numbytes;

if (cl_hostname.compareTo("") == 0 && serv_adr.compareTo("") == 0 && serv_port.compareTo("") == 0) {

System.out.println("error usage: talker hostname message" + stderr);

return 1;

}

if ((he=gethostbyname(serv_adr)) == NULL) { // obtinerea host info

System.out.println("error gethostbyname");

return 1;

}

if ((sock_intr = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {

System.out.println("error socket");

return 1;

}

byte[] cntr_addr_in_family = AF_INET; // ordinea host byte

byte[] cntr_addr_in_port = htons(PORT); // ordinea short, network byte

String[] cntr_addr_in_addr = he(hostent_intr);

memset((cntr_addr_in_zero), ’\0’, 8);

if ((numbytes=sendto(sock_intr, serv_adr, strlen(serv_adr), 0,sockaddr_intr,sizeof(sockaddr)) == -1) {

System.out.println("error sendto");

return 1;

}

System.out.println("sent " + numbytes + " bytes to " + cntr_addr_in__addr);

close(sock_intr);

return 0;

}

În codul prezentat mai sus în programul server socket-ul este specificat, protocolul este sock stream, metoda bind asociază socket listen cu variabila serv_addr, metoda bzero completeaza cu zero variabila serv_addr. Programul server nu necesită inițializarea explicită a adresei IP, numai clientul necesită acest lucru și metoda listen construiește specificațiile server. Cele mai importante metode pentru programul server sunt: socket(), bind(), listen(), accept(), read and write. În programul client metodele corespondente sunt: socket(), bind(), connect(), read and write. Avantajul utilizării unui driver custom este acela că programatorul are control total asupra design-ului și a implementării aplicațiilor, cu puține schimbări se pot accesa orice tip de date și de asemenea acest driver poate fi îmbunătățit și utilizat de către un număr sporit de dezvoltatori software deoarece reprezintă o clasă Java, deci este open-source. În codul sursă al acestui driver se pot implementa diferite metode pentru gestionarea datelor în cadrul bazelor de date cu ajutorul comenzilor (select, insert, update, delete, create, etc.) sau din fișiere XML.

Fig. 3.5.2 – Utilizarea driverului general de conectare

JDBC îndeplinește task-urile sale prin intermediul unui set de interfețe Java, fiecare implementată diferit de vendori individuali. Setul de clase ce implementează interfețele JDBC pentru un motor particular al unei baze de date este denumit driver JDBC. Scopul unui JDBC este de a ascunde specificurile fiecărei baze de date și lasă programatorii să se concentreze asupra propriilor aplicații. O interogare a bazei de date pentru orice motor al unei baze de date este necesară o conexiune la baza de date, se emite un statement SELECT și se procesează setul de rezultate.

Fig. 3.5.3 – Arhitectura driverului general de conectare

Scopul cercetării este de a găsi noi modalități de accesare a diferitelor tipuri de date prin intermediul aplicațiilor WEB. Ca element de noutate lucrarea de cercetare își propune definirea unui driver general de accesare a diferitelor tipuri de date, în limbajul Java. Acest driver va fi inclus într-un pachet Java, ce va extinde capacitățile și posibilitățile pachetelor existente în domeniul accesării datelor structurate sau semistructurate. O modalitate de realizare a acestui driver ar putea fi transformarea datelor din baze de date în fișiere XML și transformarea acestora în clase Java, utile în cadrul aplicațiilor Web. Aceste clase vor fi bean-uri ce vor mapa entități prezente în baze de date, astfel încât orice modificare asupra lor se va reflecta automat în baza de date. O altă modalitate de accesare a datelor prin limbajul Java este de a testa ce tipuri de date vor fi utile aplicației Web și includerea driverelor specifice în driverul general de accesare și conectare la baza de date.

Conexiunea permanentă de la nivelul aplicației Web va fi în funcție de tipul de date utilizat în logica de business. În general transformarea diferitelor tipuri de date într-un singur tip de date gestionat de un SGBD ce conține multiple facilități permite accesarea facilă a acestora, minimizând costurile și optimizând modul de funcționare al aplicațiilor Web construite cu Java. Pentru date semistructurate sau prezente în SGBD-uri de generație veche este utilă transformarea acestora în fișiere XML ce pot fi ușor accesate și gestionate de limbajul Java și astfel fiind posibile construirea de aplicații Web ce oferă facilități superioare utilizatorilor în comparație cu aplicații de generație anterioară.

Pe piața IT din țara noastră există puține aplicații WEB ce accesează date din diverse SGBD-uri. Există firme ce au datele constituite în fișiere de tip XML sau în baze de date de tip Fox, Microsoft Acces (SGBD-uri de generație veche). Aceste firme doresc să implementeze noi sisteme informatice ce fac posibilă accesarea, manipularea și utilizarea datelor prin intermediul rețelei Internet. Limbajul Java oferă un bun suport pentru realizarea de aplicații complexe pentru Web, fiind apreciat pentru ușurința dezvoltării, întreținerii și actualizării aplicațiilor. Un aspect foarte important al acestui limbaj este independența lui față de platformă. În același timp mulțimea de unelte gratuite pentru dezvoltare, reutilizarea facilă a codului, documentațiile online, precum și un număr mare de site-uri specializate cu topicuri și forumuri de discuții pentru comunitatea de programatori Java, fac posibile crearea de aplicații Web stabile și robuste pentru diferite tipuri de servere și SGBD-uri.

Prezentarea principalelor aspecte referitoare la costuri, durate și riscuri

În domeniul aplicațiilor Web pentru SGBD-uri, costurile se reflectă în calitatea produselor (aplicațiilor) software și sunt calculate în funcție de limbajul de programare ales, a SGBD-ului ce conține datele necesare aplicațiilor cât și a platformei OS (sistem de operare). Beneficiile în raport cu costurile sunt enorme, iar cele mai importante sunt: un bun management al datelor din interiorul unei companii, o mai bună colaborare între departamentele companiei, posibilitatea obținerii de rapoarte clare, eficiente, realiste, cu multe elemente grafice (grafice de comparație) – destinate conducerii manageriale și nu în ultimul rând dezvoltarea afacerii în mediul www, prin prezentarea ofertelor unei game largi de clienți, dar și găsirea de noi parteneri de afaceri sau furnizori.

Din punct de vedere al costurilor, cele mai eficiente se dovedesc tehnologiile LAMP (Linux – sistem de operare, Apache – Web server, MySQL – SGBD și Perl, PHP sau Python ca limbaj de programare). Aceste tehnologii sunt free, open source, tehnologii fiabile, robuste, ușor de utilizat și pun la dispoziția dezvoltatorului soluții simple pentru rezolvarea unor probleme complexe, dar și documentații cuprinzătoare și forumuri de discuții, blog-uri, etc.

O altă soluție free și foarte des folosită de către companii ce au un nivel ridicat de dezvoltare este combinația Linux – sistem de operare, Apache – Web server și limbajul de programare Java ce poate conlucra foarte eficient cu toate SGBD-urile performante existente la ora actuală. Limbajul de programare Java, prin driverele sale de conectare poate accesa multiple surse de date și oferă suport nativ pentru mediul Web prin intermediul paginilor dinamice de genul servleți, JSP-uri, JSF-uri, struts, etc. Beneficiul acestor soluții free și open source sunt imense și oferă posibilități multiple de dezvoltare a unor aplicații Web robuste, sigure, ușor de upgradat, ușor de modificat și foarte utile pentru dezvoltarea afacerilor în mediul Internet.

Pentru SGBD-uri de generație mai veche, sau în cazul soluțiilor Microsoft, costurile nu sunt de neglijat, majoritatea produselor necesită cumpărarea de licențe, stabilitatea aplicațiilor este scăzută, iar beneficiile sunt destul de mici în comparație cu costurile. Pentru upgradarea acestor aplicații este necesară cumpărarea de noi licențe, eliminarea problemelor de compatibilitate, precum și rescrierea unor porțiuni importante de cod sursă.

În momentul actual sunt foarte utile soluțiile de Business Intelligence și data warehouse, ce oferă multiple avantaje atât clienților cât și companiilor, prin integrarea datelor din mai multe surse de date, tipuri diferite de SGBD-uri, fișiere XML și integrarea lor în cuburi și dimensiuni de date, ce fac posibile obținerea unor rapoarte complexe, data mining, etc. Costurile unui data warehouse sau a unui data mart sunt mici în comparație cu beneficiile aduse (interogări complexe, timpi de execuție a interogărilor net superiori în comparație cu timpii de execuție a unei interogări SQL clasice, extragerea, taransformarea și încărcarea datelor din surse de date neomogene, etc.).

Din punct de vedere al timpilor de execuție se poate spune că pentru aplicațiile Web sunt net superiori pentru accesarea datelor de la distanță în comparație cu aplicații clasice ce au în vedere SGBD-uri de generație mai veche ce necesită diverse protocoale de accesare a datelor din baze de date aflate la distanță. De asemenea timpii necesari pentru dezvoltarea aplicațiilor Web pentru SGBD-uri sunt mai mici în comparație cu aplicațiile clasice, deoarece cod sursă scris într-un limbaj orientat pe obiecte precum Java, poate fi încapsulat în bean-uri, clase și interfețe ce pot fi refolosite în mai multe aplicații, dar și oferă o modularitate excelentă, astfel încât echipe de dezvoltatori pot lucra la module separate.

În plus aplicațiile Web pentru SGBD-uri permit separarea activităților de dezvoltare a programatorilor de activitățile specifice Web design-erilor, fapt ce reduce timpul de proiectare și dezvoltare a acestor aplicații. De asemenea prin intermediul aplicațiilor Web sunt obținute într-un timp mult mai rapid rapoarte complexe obținute din surse de date aflate în diverse locații prin intermediul rețelei Internet. Legat de riscuri se poate spune că soluțiile bazate pe tehnologiile LAMP sunt cele mai sigure și stabile, oferind avantaje net superioare în domeniul protejării datelor, a canalelor de comunicație, a grupurilor de utilizatori, etc. Aplicațiile de generație mai veche oferă o stabilitate mai mică, o protecție a datelor slabă și riscuri diverse generate de platformele de dezvoltare sau a sistemelor de operare.

În continuare sunt prezentate principalele caracteristici ale diverselor SGBD-uri existente și a framework-urilor de dezvoltare aferente, din punct de vedere al performanțelor, costurilor, riscurilor și a duratelor într-un tabel comparativ.

Tabel 3.5.1 – Caracteristici comparative ale principalelor SGBD-uri și a framework-urilor aferente

Tabel 3.5.2 – Centralizator caracteristici comparative ale principalelor SGBD-uri și a framework-urilor aferente

În concluzie, alegerea instrumentelor de dezvoltare trebuie să aibă în vedere costurile, portabilitatea, independența față de sistemele de operare, nivelul de performanță al limbajelor de programare, posibilități de modificare ulterioară a aplicațiilor și a mentenanței acestora, disponibilitatea pentru mediul Web, ușurința utilizării acestor instrumente, protecția datelor, portabilitatea aplicațiilor, facilitățile oferite mediului de business. Construirea unui driver propriu în limbajul de programare Java oferă facilități importante precum independența față de mediul de programare, portabilitate mărită pentru diverse platforme de dezvoltare, posibilitatea dezvoltării acestei clase Java de către o comunitate largă de programatori prin introducerea de noi metode specifice logicii de business implementată în aplicații. De asemenea transformarea fișierelor XML în clase proprii Java reprezintă o bună metodă de a accesa date stocate în medii diferite și de a le utiliza în aplicații Web prin intermediul limbajului de programare Java. O altă metodă de integrare a datelor aflate în medii diferite este de a utiliza instrumentele ETL (Extract, Transform, Load) a Data Warehouse, punând la dispoziție programatorului instrumente puternice de data mining, OLAP, raportare, etc.

Rezultate obținute și relevanța acestora.

Tema aleasă își propune să prezinte principalele modalități de construire a aplicațiilor Web pentru SGBD-uri. Un rol important în cadrul aplicațiilor Web îl are limbajul orientat-obiect Java, ce permite accesarea datelor din baze de date gestionate de SGBD-uri precum Oracle, Microsoft SQL Server, MySQL, Microsoft Access, Visual Fox, iar pentru date semistructurate XML. Limbajul Java extinde capacitățile serverelor Web, stă la baza instrumentelor Web precum: Servlet, JSP, JSF, Taglibs, Struts, etc., este limbajul utilizat pentru construirea bean-urilor CMP Beans (bean-uri ce au starea sincronizată cu elemente din baza de date pe care se face maparea), EJB Beans (bean-uri Enterprise JavaBeans folosiți în tranzacții, comenzi utilizator), ADF JavaBeans (bean-uri utilizate în modele de tip ADF – Application Development Framework (pentru tranzacții, interfețe utilizator, session bean-uri). Limbajul Java leagă interfețele Web de bazele de date prin drivere specifice fiecărui SGBD, gestionează sesiunile utilizator, manageriază conexiunile utilizatorilor, transmite și tratează evenimente request-response.

Pe parcursul lucrării sunt prezentate și alte limbaje de programare utilizate în construirea aplicațiilor Web precum: PHP, C#, Perl, limbaje ce fac posibilă accesarea datelor din baze de date gestionate de SGBD-uri sau date semistructurate prezente în fișiere XML. Fișierele XML, fac posibile accesările datelor dintr-un format unic de către o mulțime de limbaje de programare, în timp ce tot mai multe SGBD-uri pot realiza transformarea datelor structurate în baze de date relaționale în fișiere de acest tip.

Alături de prezentarea componentelor Web, sunt puse în evidență și funcționalitățile SGBD-urilor precum gestionarea metadatelor, utilizarea procedurilor stocate, asigurarea protecției datelor, crearea și grantarea grupurilor de utilizatori pentru a asigura accesul la date, precum și prezentarea unor instrumente software precum Oracle Olap, Oracle Warehouse Builder, Oracle Business Intelligence 10g, etc.

Proiectul de cercetare științifică are la bază în prima etapă identificarea principalelor tipuri de date, stocate în baze de date și gestionate de SGBD-uri, metadate, cuburi de date, date semistructurate în fișiere XML și date nestructurate de tip Office ce pot suferi transformări în formate de tip XML, sau încărcarea lor completă în câmpuri permanente ale unei baze de date. Lucrarea va avea în vedere prezentarea unor modalități moderne de construire a aplicațiilor Web prin identificarea și utilizarea de tehnologii web, utilizarea limbajului Java în cadrul acestor aplicații și specificarea modalităților de accesare a diverse tipuri de date prin conexiuni Java.

Elemente importante în cadrul aplicațiilor Web reprezintă formatele de date, modelele de date, transformarea documentelor XML în clase Java, serviciile Web XML pentru SOA (Service Oriented Architecture), utilizarea limbajului JavaScript în cadrul paginilor Web.Instrumentele Web precum Servlet, JSP (JavaServer Pages), JSF (JavaServerFaces), JSTL (JavaServer Pages Tag Library) cu facilități precum biblioteca core, biblioteci de funcții, de formatare a datelor, de procesare a fișierelor XML și pentru baze de date, Struts (Framework open-source pentru JSP/Servlet), Spring (Application Framework pentru ansamblarea componentelor unei aplicații prin intermediul fișierelor de configurare) și Hibernate (librărie JAVA pentru ORM – object-relational mapping): injectarea dependențelor, programarea orientată pe aspect; fișiere de mapare, sesiuni și tranzacții, operații CRUD (create, read, update and delete), limbaj interogare HQL (Hibernate Query Language), reprezintă baza aplicațiilor Web ce fac posibilă interacțiunea dintre utilizatori și bazele de date.

Conectarea utilizatorilor la bazele de date nu ar fi posibilă fără implementarea driverelor de conectare ce sunt specifice pentru fiecare dintre SGBD-uri, tehnologia inclusă în acestea fiind foarte complexă. Printre cele mai performante drivere sunt cele implementate în tehnologia Java, ce oferă facilități multiple și posibilități de customizare necesare diferitelor tipuri de aplicații Web. Un rol important în cadrul acestor aplicații îl au bean-urile Java ce reflectă entități ale bazei de date, realizează tranzacții, execută comenzi utilizatori, utilizarea lor în tehnologii precum Java RMI (Java Remote Method Invocation – este un API (Application Programming Interface) ce realizează acțiuni echivalente de remote procedure calls), CORBA (Common Object Requesting Broker Architecture – este un standard definit de Object Management Group ce permite componentelor software scrise în limbaje diferite și care rulează pe mașini diferite, să funcționeze împreună).

Bean-urile Java permit separarea interfeței utilizator de logica aplicației (partea nevăzută – modelul de business) și implicit permit separarea activităților realizate de Web designeri de activitățile desfășurate de programatori. Programul de cercetare analizează accesul la date prin servicii Web: standarde RPC (Remote Procedure Call) și XML-RPC (crearea unui client cu xmlrpc_client, crearea unui server cu xmlrpc_server), SOAP (Simple Object Access Protocol – un protocol XML-based), biblioteca PHP ADOdb (database abstraction library pentru PHP, bazat pe conceptul ActiveX Data Objects de la Microsoft).

Analizând Limbajul C# pentru Microsoft SQL Server, XML, HTML se pot detalia aspectele privind crearea de HTML din Transact-SQL și din sp_makewebtask, scheme XML, transformări XSLT (Extensible Stylesheet Language Transformations), Document Object Model, interogări HTTP, Tehnologia .NET, proceduri stocate extinse (Open Data Services), tranzact- SQL, comenzi DBCC (Database Console Commands pentru Microsoft SQL Server) nedocumentate, vederi information_schema.

Teza de doctorat aduce un aport important în domeniul construirii aplicațiilor Web pentru SGBD-uri, prin punerea în evidență a celor mai bune soluții de construire a acestor aplicații luând în considerare costurile, riscurile, robustețea SGBD-ului ales, puterea limbajului de programare, facilitățile oferite de diferite framework-uri, capacitatea aplicațiilor de a oferi clienților interfețe Web pentru accesarea, introducerea și modificarea datelor. Recomandarea mea este de a utiliza ca SGBD, un SGBD de generație nouă ce cuprinde puternice facilități de stocare, manipulare, conectare, protecție, etc (un SGBD precum Oracle), ca limbaj de programare Java – deoarece este un limbaj orientat obiect, ușor de utilizat, cuprinde puternice facilități pentru mediul Web, clase specifice pentru conectarea la baze de date, nu depinde de sistemul de operare și permite o portabilitate mărită precum și posibilitatea de a împărți sarcinile între Web design-eri, programatori Java, arhitecți software, analițti software și specialiști în domeniul business și un framework open-source precum Eclipse sau JDeveloper. Recomandarea mea este de a utiliza tehnologii LAMP (Linux , Apache HTTP Server, MySQL (database software) and PHP – programming language) ca soluții open-source, free și ușor de utilizat și de implementat de către o mulțime de firme mici și mijlocii. Pentru firme de dimensiuni globale sunt recomandate tehnologii precum SGBD – Oracle, Linux – sistem de operare, server de aplicații – OAS (Oracle Application Server) și Java ca limbaj de programare, pentru a construi aplicații Web robuste, stabile, ce pot fi accesate și utilizate de un număr mare de utilizatori prin intermediul unui browser Web.

Ca și actualitate, teza de doctorat dezvoltă un domeniu de ultimă generație (domeniul aplicațiilor Web pentru SGBD-uri), un domeniu ce este în prezent în continuă dezvoltare, open-source și ce permite dezvoltări și îmbunătățiri de către o comunitate largă de dezvoltatori. Aplicabilitatea acestor aplicații cuprinde domenii largi de interes pentru mediul de business, sănătate, învățământ, etc.

Scopul cercetării este de a găsi soluții de integrare a datelor prezente în SGBD-uri, fișiere XML, etc. pentru a fi utilizate într-un mod optim în mediul Web. Soluțiile propuse sunt: construirea unui driver general de conectare cu ajutorul limbajului de programare Java (o clasă proprie ce este inclusă într-un pachet general, o clasă ce poate fi extinsă prin metode specifice lucrului cu bazele de date și care poate fi dezvoltată ulterior și de alți programatori, o clasă ce permite conectarea unui client la orice tip de server de baze de date prin intermediul socket-ilor); o altă soluție este de a utiliza fișiere XML ce conțin date structurate și fișiere XML de descriptori necesare serviciilor Web pentru a accesa date. Această soluție este ușor de implementat deoarece majoritatea SGBD-urilor de generație nouă permit transferul datelor în fișiere XML sau importul acestora din aceste fișiere. Platforma fișierelor XML reprezintă viitorul în lucru cu datele în domeniul Web și va fi dezvoltat și adoptat de majoritatea producătorilor de soluții software; o altă soluție este de a construi soluții data warehouse ce poate cuprinde date de tipuri diferite, aflate în SGBD-uri diferite sau în fișiere semistructurate. Aceste date pot fi integrate în depozite de date prin intermediul instrumentelor ETL (Extract, transform and load). Extragerea datelor din surse exterioare, transformarea acestora pentru a corespunde arhitecturii data warehouse și încărcarea acestora într-o bază de date de acest tip, permite utilizarea acestor date la nivel superior putând fi interogate prin instrumente superioare de data mining, OLAP (Online analytical processing) și nu în ultimul rând pot fi reprezentate în rapoarte și grafice semnificative pentru procesul de business. În acest domeniu lider este Oracle cu tehnolgia Oracle Warehouse Builder și ca instrument de interogare, raportare, data mining este Oracle Business Intelligence Suite Enterprise Edition.

Cadru teoretic și cercetări anterioare

Odată cu creșterea explozivă a popularitatii Internetului, tot mai multe companii își îndreaptă atenția înspre extinderea afacerii și în spatiul virtual. Cel mai bun exemplu îl reprezinta companiile din domeniul IT, care sunt practic motorul dezvoltarii acestui segment.

Comertul electronic vine în intampinarea clienților și a comerciantilor cu atuuri ce nu pot fi neglijate: pentru comercianți: costul de "deschidere" este foarte mic, timpul lansării afacerii este mic, costul de intreținere este aproape nul, numărul de angajati este mai mic, formulare interactive, nu necesită un spatiu amenajat, este valabil 24/7, reclamă ieftină si eficientă, atragerea de clienți si din afara segmentului țintă (ex: din orașe vecine, cartiere îndepărtate); pentru clienți: posibilitatea de a studia în amănunt oferta, timpul lansării afacerii este mic, timp si costuri de deplasare nule, posibilitatea de a studia oferta mai multor comercianți, acces la părerile altor cumpărători si ale revistelor online de specialitate legat de un anumit produs sau magazin, posibilitatea achiziționarii de produse din orice punct al țării sau chiar al lumii fără nevoia de deplasare. Cum un magazin, o companie sau un brand nu sunt profitablie dacă nu sunt cunosctute, la fel este și în cazul unei aplicații web. În ambele cazuri această problema se poate rezolva printr-o promovare intensivă si adresată segmentului țintă.

Facilități de bază ale aplicațiilor Web, actualitatea publicațiilor ce descriu stadiul actual, metode și rezultatele cercetărilor anterioare

În concluzie, aplicațiile Web pentru business ajută dezvoltarea afacerilor pentru firmele ce adoptă aceste tehnologii, astfel datele companiei ce se află în diverse formate pot fi utilizate în mod integrat. Tehnologiile actuale sunt orientate către tipurile de date existente în cadrul firmelor, acestea incluzând și tehnologii mai vechi, SGBD-uri de generație anterioară, date nestructurate, aplicații vechi ce nu mai corespund standardelor actuale.

Publicațiile ce descriu domeniul aplicațiilor Web pentru SGBD-uri sunt numeroase, majoritatea sunt articole cotate ISI și există în reviste incluse în baze de date internaționale precum EI Compendex, ACM, IET (IEE), SCOPUS, ASM, ACM, ACS, CSA, ELSEVIER, ZENTRALBLATT, MATHSCINET, DPP, EI, CSBA,Ulrigh, DEST, EBSCO, EMBASE, GEOBASE, BIOBASE, BIOTECHNOBASE, FLUIDEX, ScienceDirect, JStor, ProQuest, SpringerLink, etc. În plus există o comunitate largă de dezvoltatori în acest domeniu, există comunități de programatori ce expun prin intermediul site-urilor de specialitate, forumuri și a blog-urilor de specialitate unde sunt împărtășite idei, soluții la unele probleme ce pot apare în momentul dezvoltării aplicațiilor, etc. De asemenea există pentru acest domeniu o documentație bogată ce cuprinde cărți de specialitate, news letter-uri, tutoriale, etc.

Metodele și rezultatele anterioare în acest domeniu au condus la soluții multiple în acest domeniu, dar încă sunt probleme de rezolvat în privința integrării datelor ce provin din diverse surse. Există în momentul actual diverse drivere de conectare ce sunt dedicate pentru anumite tipuri de date, depind de implementarea vendorilor de software (de exemplu driverul JDBC sau driverul ODBC – Open Database Connectivity). În ce privește modalitatea de a construi interfețe Web ce facilitează interacțiunea utilizatorilor cu date prezente în baze de date, este bine pusă la punct și are la bază o mulțime de framework-uri de dezvoltare ce pot fi independente sau incluse în suite de programe specifice anumitor SGBD-uri (ex. Visual Studio de la Microsoft). Soluția construirii unui driver general de conectare la serverele de baze de date (soluție proprie) aduce beneficii imense în domeniul construirii aplicațiilor Web, deoarece este free, open-source și are la bază limbajul de programare orientat-obiect și utilizează conexiunea prin socketi. Este o soluție ce permite integrarea acestei clase Java în orice tip de aplicație și permite includerea de noi metode de lucru cu bazele de date. În plan național acest domeniu este puțin răspândit și în general se bazează pe aplicații de generație anterioară sau de soluții software cumpărate de la vendori specializați ce sunt greu de modificat și customizat conform cerințelor actuale din business-ul autohton. Pe plan internațional acest domeniu este bine dezvolotat, este utilizat de un spectru larg de clienți, dezvoltatori software și arhitecți software, dar depinde de soluțiile integrate oferite de marii producători de software. Rezultatele cercetării în acest domeniu sunt incluse în produse software ce nu permit vizualizarea codului sursă și în consecință este greu de modificat și utilizat în propriile aplicații. De asemenea literatura de specialitate se axează mai mult pe facilitățile oferite de diferite drivere de conectare și nu prezintă modul explicit de creare a acestora, dar nici nu lasă posibilitatea de modificare sau îmbunătățire a acestora.

Obiective, Caracterul inovativ al cercetării și Metodologia de cercetare

Obiectivele principale ale temei de cercetare sunt axate pe modalitățile principale de integrare a datelor aflate în diverse surse precum bazele de date sau semistructurate în fișiere de tip XML. Alte obiective se referă la găsirea celor mai bune modalități de construire a aplicațiilor Web pentru SGBD-uri, astfel încât problema alegerii SGBD-ului potrivit, a limbajului de programare și a framework-ului de dezvoltare, reprezintă un pas important în decizia de a construi și implementa un astfel de sistem. Soluția alegerii instrumentelor potrivite trebuie să aibe în vedere problema costurilor, a facilităților oferite, a ușurinței implementării și dezvoltării, a utilizării de către un număr mare de utilizatori, a mentenanței viitoare sau a integrării acestora în aplicații complexe, etc.

Ca element de noutate lucrarea de cercetare își propune definirea unui driver general de accesare a diferitelor tipuri de date, în limbajul Java. Acest driver va fi inclus într-un pachet Java, ce va extinde capacitățile și posibilitățile pachetelor existente în domeniul accesării datelor structurate sau semistructurate.

Limbajul de programare Java oferă multe posibilități de conectare la diferite tipuri de date prin intermediul unui driver predefinit numit JDBC (Java Database Connectivity) ce oferă acces la bazele de date ale diferiților producători și pot manipula date structurate în tabele prin intermediul comenzilor SQL ce reprezintă argumente pentru metode cuprinse în interfețe Java. Java pune la dispoziția programatorilor bazelor de date facilități precum acces la obiecte facil și de mapare relațională, independență față de baza de date, calcul distribuit, etc. Rezultatele din bazele de date sunt returnate ca obiecte Java, iar problemele de acces sunt afișate ca excepții, astfel încât aceste obiecte pot fi utilizate în multe tipuri de aplicații.

Cea mai eficientă cale de customizare a aplicațiilor este de a construi un driver propriu de conectare ce poate fi utilizat pentru accesarea de diferite tipuri de date din diferite locații. Propria soluție este de aconstrui o clasă proprie customizată Java pentru conectarea unui client la server prin intermediul sockețiilor. Sockeții reperezintă o cale de comunicare cu alte programe utilizând standardul de descriere a fișierelor Unix/Linux. Un descriptor de fișier este un întreg asociat cu un fișier deschis. Acel fișier poate fi o conexiune rețea, un canal de comunicare, un terminal, un fișier real aflat pe disk, etc. Când este apelată rutina sistem socket(), este returnat un descriptor socket și programul comunică prin intermediul său utilizând apeluri specializate socket numite send() și recv(). Există două tipuri de sockeți. Un tip reprezintă stream sockeți și alt tip este datagram sockeți ce pot fi referiți ca SOCK_STREAM și SOCK_DGRAM. Sockeții datagram sunt numiți sockeți fără conexiune. Steam sockeții sunt căi de comunicare de bază two-way (două căi). Aceștia sunt de asemenea liberi de erori.

Stream sockeții ating un înalt nivel de calitate a transmisiei datelor prin intermediul unui protocol numit Transmission Control Protocol, cunoscut ca TCP. TCP asigură că datele ajung secvențial și liber de erori. Sockeții datagram sunt numiți fără conexiune deoarece dacă este trimisă o datagramă, poate ajunge și poate ajune într-a ordine aleatoare. Dacă ajung la destinație, datele din pachet vor fi libere de erori. Sockeții datagram folosesc protocolul IP (Internet Protocol) pentru rutare, dar nu utilizează TCP, ci utilizează User Datagram Protocol, sau UDP. Sunt fără conexiune deoarece nu trebuie să mențină o conexiune deschisă precum sockeții stream. Un pachet poate fi construit utilizând un header IP asupra sa cu informații destinație și trimis în acest fel. Nu este nevoie astfel de conexiune. Acestea sunt în general utilizate pentru transfer pachet cu pachet a datelor.

Cea mai importantă proprietate în construirea unui driver de conectare este arhitectura client-server. Clientul se conectează la server, iar serverul așteaptă pentru conexiuni. Principalele diferențe sunt în momentul inițializării și nu în timpul funcționării normale. Sockeții fac posibilă comunicarea în cadrul rețelei și conține o adresă de IP, un protocol (TCP, UDP) și un număr de port ce permite separarea a mai multor conexiuni.

O altă modalitate de realizare a acestui driver ar putea fi transformarea datelor din baze de date în fișiere XML și transformarea acestora în clase Java, utile în cadrul aplicațiilor Web. Aceste clase vor fi bean-uri ce vor mapa entități prezente în baze de date, astfel încât orice modificare asupra lor se va reflecta automat în baza de date.