Proceduri stocate in Java

Proceduri stocate în Java

Solutii de dezvoltare a aplicatiilor de interactiune cu baze de date

Ce sunt procedurile stocate si cum sunt implementate în Oracle 8i procedurile stocate Java. Avantajele utilizarii acestei tehnologii, câteva detalii despre implementarea masinii virtuale Java realizata în serverul Oracle 8i si un exemplu concret de dezvoltare si punere în exploatare a unei proceduri stocate scrise în Java.

Bogdan Costinescu

Va mai aduceti aminte de primele aplicatii ale limbajului Java? Imagini animate, sunet, interactivitate, si toate prin intermediul unui simplu program de navigare WWW, pe orice platforma si sistem de operare. Istoria Java a început în 1995, iar în cei patru ani care au trecut s-au produs foarte multe schimbari, datorate mai ales implicarii în universul Java a unor colosi din industria calculatoarelor: SUN, IBM, Oracle. Platforma Java a evoluat dintr-un mediu interesant pentru mediile academice într-un adevarat mediu de întreprindere, evolutia datorându-se atât calitatilor intrinseci ale platformei, cât si noilor oportunitati de afaceri pe care le ofera.

Acest articol nu-si propune sa descrie calitatile limbajului si platformei Java. S-au scris destule materiale de calitate despre asa ceva, drept care acest articol îsi propune sa descrie una din cele mai elegante si performante (da, nu va mirati, performanta a început sa apara si în lumea aplicatiilor Java!) solutii de dezvoltare a aplicatiilor de interactiune cu baze de date: procedurile stocate Java (Java Stored Procedures).

Motivatie

Procedurile stocate Java sunt o urmare fireasca a efortului de îmbunatatire a calitatii solutiilor pentru mediile industriale. Aplicatiile client/server au permis separarea logicii programului si alegerea sistemului de operare cel mai potrivit pentru fiecare sectiune a aplicatiei: mediile Windows pentru preluarea si afisarea informatiilor si mediile Unix pentru gestiunea si protectia informatiilor. Problemele de portabilitate si costurile ridicate ale întretinerii variantelor aplicatiilor folosite de clienti au fost rezolvate 929n1311j o data cu aparitia platformei Java si a applet-urilor. Acelasi cod poate sa ruleze pe orice platforma hardware, iar aplicatia poate fi descarcata direct de pe server, deci se va folosi întotdeauna ultima versiune a aplicatiei client. Asadar, 100% Java.

Introducerea conceptului de server de aplicatii si dezvoltarea arhitecturii pe trei niveluri au reprezentat pentru Java noi rampe de lansare. La ora actuala, nu mai exista server de aplicatii care sa nu ofere suport pentru servluri, aceste mini-aplicatii care ruleaza în cadrul serverului de aplicatii si genereaza pagini HTML pentru clientii universali: programele de navigare. În curând vom auzi si de implementari de Java Server Pages, o replica la mai cunoscutele Active Server Pages, care reprezinta o modalitate foarte simpla de a încapsula cod Java în cadrul unei pagini HTML. Aceste doua tehnologii trebuie puse în conjunctie cu tehnologiile de obiecte distribuite (CORBA) sau componente Java (Enterprise Java Beans), care sunt si ele prezente în cele mai noi servere de aplicatii. Pâna acum, 200% Java.

Dar producatorii de sisteme de baze de date nu s-au oprit aici. Oracle, prin ultima versiune a sistemului de gestiune a bazelor de date, Oracle 8i, împinge mai departe platforma Java: direct în baza de date! Sunt implementate nu numai conceptele legate de proceduri stocate în Java, ci si componente Java pentru întreprindere (EJB). Toate acestea, pentru ca noul mare val de aplicatii va fi reprezentat de cele bazate pe tehnologiile Internet si Intranet. În total, 300% Java, asa cum este unul din sloganurile corporatiei Oracle.

Aceasta scurta enumerare de solutii si posibilitati trebuie sa va faca sa va gânditi la cel putin doua aspecte. Mai întâi, Java exista si este folosit pentru implementarea de mari proiecte informatice datorita multiplelor avantaje si standarde adoptate în jurul platformei. Al doilea aspect, poate mai important, este ca un singur limbaj de programare poate fi folosit pentru dezvoltarea tuturor tipurilor de programe de care este nevoie într-o întreprindere: aplicatii client, comunicatii, securitate, module pentru serverul de aplicatii, accesul la baze de date, multimedia, gestiunea retelei si lista ar putea continua. Decizia de migrare spre Java poate lua un pic de timp, dar avantajele sunt clare. As dori sa subliniez, în afara de cele deja clasice, crearea unei expertize de programare într-un singur limbaj în cadrul întreprinderii care va îmbunatati calitatea tuturor aplicatiilor scrise. Nu mai este nevoie de C/C++, VB, Perl, PL/SQL, COBOL, ci doar de Java si de API-urile ei.

Revenind la subiectul articolului, în cadrul articolului voi prezenta modalitatea prin care sunt implementate în Oracle 8i procedurile stocate Java. Prezentarea se va axa pe particularitatile aceste solutii, incluzând avantajele, restrictiile, modul de dezvoltare, testare si de apel.

Prima întrebare la care trebuie dat un raspuns este ...

Ce sunt procedurile stocate Java?

Pot fi date mai multe definitii, fiecare dintre ele surprinzând un anume aspect al procedurilor stocate. Primul aspect care merita atins este cel algoritmic. Procedura stocata, fie ea în Java sau în traditionalul PL/SQL, reprezinta o implementare a unui algoritm, o extensie a limbajului SQL. Limbajul SQL este foarte bun pentru definirea, manipularea si interogarea datelor dintr-o baza de date, dar este lipsit de unele constructii necesare pentru crearea de programe. Din acest motiv, este necesara utilizarea unui limbaj extern, de preferat de nivel înalt, pentru a putea descrie usor algoritmii folositi în prelucrarea datelor. Aici intervin procedurile stocate care extind functionalitatea motorului bazei de date.

Înainte de a trece la alte caracteristici ale procedurilor stocate, trebuie mentionat ca termenul se refera atât la proceduri (constructii de programare care primesc parametrii, dar nu întorc o valoare), cât si la functii, pentru care este importanta valoarea întoarsa.

Al doilea aspect al procedurilor stocate în Java este legat de modul de executie. Codul procedurii, deci aplicatia în final, foloseste o implementare de masina virtuala foarte performanta, complet integrata în SGBD. Aceasta masina virtuala este o implementare scalabila si de nivel întreprindere a platformei Java. Asadar, procedura stocata Java este o modalitate de a beneficia de avantajele oferite atât de Java, cât si de implementarea performanta din serverul bazei de date Oracle 8i. Masinii virtuale Java oferite de Oracle, numita Aurora, îi voi dedica o sectiune speciala datorita caracteristicilor ei particulare.

O alta caracteristica importanta a procedurilor stocate este faptul ca este reprezinta o modalitate de a centraliza logica aplicatiei, cu toate avantajele de întretinere si usurinta în distributie a aplicatiei.

Ultima definitie care poate fi data procedurilor stocate este ca ele definesc porti de acces la date. Ca orice poarta, ea poate controla cine si la ce are acces. Controlul accesului se face pe baza utilizatorilor din baza de date, motiv pentru care este mult mai simplu sa se gestioneze o astfel de aplicatie, comparativ cu solutia în care utilizatorul trebuie sa se autentifice cu serverul de aplicatii, apoi cu serverul bazei de date.

Din definitiile de mai sus se pot desprinde deja unele avantaje ale procedurilor stocate Java, dar le vom discuta separat, în cadrul sectiunii ...

Avantajele procedurilor stocate Java

Problema de care se plâng multi utilizatori ai limbajului Java este slaba performanta. Toti acestia sunt invitati sa citeasca paragrafele urmatoare, pentru ca ele releva masurile pe care Oracle le-a luat pentru a crea si oferi avantajul major al folosirii procedurilor stocate Java: înalta performanta.

• Mai rapide decât aplicatiile Java cu JDBC Procedurile stocate Java ruleaza acolo unde sunt stocate datele, deci este evident faptul ca sunt mai rapide. În plus, driverul JDBC al masinii Aurora este special optimizat si acordat pentru o comunicatie prin memorie partajata cu sistemul de gestiune al bazei de date.
• Lipsa întârzierilor din retea. Solutia clasica de prelucrare a datelor este obtinerea lor în cadrul aplicatiei client, modificarea lor si restocarea lor în baza de date. Toata aceasta activitate implica transferuri în retea. Deoarece datele sunt prelucrate acolo unde sunt stocate întârzierile de transmisie sunt eliminate. De exemplu, procedurile de analiza si sinteza a datelor ofera doar rezultatul final, mult mai mic decât volumul de date prelucrat.
• Lipsa proceselor suplimentare. Prin constructia serverului Oracle 8i, masina virtuala Java este tot timpul pornita. Asadar, apelul unei proceduri stocate nu va însemna lansarea în executie a unor noi procese.
• Gestiunea inteligenta a codului. Codul procedurilor stocate este optimizat prin intermediul unui compilator just-in-time. Acest lucru înseamna ca, o data încarcat, codul procedurii este executat la viteza maxima. Mai mult, sistemul gestioneaza bytecode-ul în mod partajat, permitând mai multor utilizatori care folosesc aceeasi procedura stocata sa foloseasca varianta optimizata. Acest mod de gestiune a codului, cu memorii cache si spatii partajate, este benefic si pentru noile tipuri de optimizoare de cod Java (a se vedea HotSpot), deoarece codul este rulat continuu, si nu încarcat la fiecare apel.
• Abstractizarea actiunilor. De obicei, în cadrul unei proceduri stocate sunt înglobate mai multe fraze de selectie si manipulare a datelor. Acest mod de structurare permite abstractizarea actiunilor pe care aplicatia le efectueaza, precum si reutilizarea procedurilor din mai multe locuri.
• Exploatarea performantelor serverului. Acest avantaj se bazeaza pe o observatie de bun simt. În cadrul unei întreprinderi, resursele sunt centralizate pe server. Acesta dispune, de obicei, de cel mai rapid procesor, daca nu chiar de mai multe procesoare, de memorie, de un sistem de stocare performant. Toata aceasta putere de calcul sta si la dispozitia masinii virtuale Java si, prin extensie, si procedurilor stocate Java.
• Centralizarea regulilor afacerii. Acest avantaj este global pentru toate procedurile stocate si reprezinta unul din marile motive de folosire a procedurilor stocate. Cuvintele cheie ce trebuie subliniate sunt întretinerea usoara a clientilor (fiecare client, când va apela procedura, va apela ultima varianta, deci va beneficia de îmbunatatirile aduse între timp, fara modificarea aplicatiei client), reutilizarea (de catre mai multe aplicatii sau utilizatori, evitând duplicarea scrierii de cod), asamblarea procedurilor verificate în proceduri mai complexe.
• Productivitate si usurinta în folosire. Procedurile stocate extind functionalitatea SGBD-ului. De exemplu, o functie stocata poate fi folosita în cadrul unei fraze SQL. Apelul unei proceduri stocate Java este foarte simplu, fiind disponibile în Java numeroase modalitati standard de apel la nivelul clientului: JDBC, SQLJ, CORBA, EJB. În plus, o procedura stocata Java poate fi apelata din PL/SQL, din Forms, din triggere sau din metodele obiectelor din baza de date, fara a epuiza modurile în care se poate folosi o procedura stocata.
• Controlul accesului. Mecanismele SGBD-ului permit gestiunea drepturilor de acces la procedurile stocate. În acest mod, putem decide cine are acces la proceduri si cine nu. În plus, se poate activa un mecanism de acces care sa permita folosirea unei proceduri de actualizare a unei tabele din baza de date, cu toate ca utilizatorul nu are drept de modificare asupra tabelei respective. Astfel se reimpune logica afacerii, controlându-se cine si cum efectueaza modificarile.
• Dezvoltare rapida. Prin intermediul mediilor vizuale ce permit asamblarea componentelor Java este posibila crearea unei proceduri stocate pe baza unor componente deja verificate, totul realizându-se în mod vizual. Testarea functionalitatii procedurii se poate face în cadrul unui program client, urmând ca apoi sa se faca punerea în exploatare în cadrul serverului Oracle.
• Scalabilitatea. Datorita grijii în implementarea masinii virtuale Aurora, Oracle a reusit sa pastreze foarte bunele caracteristici de scalabilitate pe care le au SGBD-urile firmei. Astfel, experimentele au demonstrat faptul ca necesarul suplimentar de memorie per conexiune este de numai 28KB, fiind deci posibila gestiunea multor utilizatori simultan, exact cazul sistemelor pentru Internet.
• Portabilitatea. Nu în ultimul rând, trebuie avut în vedere ca procedura stocata scrisa în Java poate fi utilizata pe orice platforma hardware. Mai mult, o procedura stocata poate rula, cu mici modificari, în cadrul unei aplicatii client (sau applet) ori într-un server de aplicatii.

Dupa toate aceste avantaje, mai trebuie clarificata o mica nedumerire: de ce Java si nu PL/SQL? Articolul de fata nu doreste sa minimizeze importanta PL/SQL. Merita mentionat în acest sens produsul WebDB, tot al firmei Oracle, care permite gestiunea unei baze de date si crearea unui sit WWW populat cu informatii dintr-o baza de date folosind ca instrument de dezvoltare un program de navigare obisnuit. Desigur, greul este dus de procedurile stocate, scrise integral în PL/SQL. Ceea ce doreste însa sa sublinieze acest articol sunt caracteristicile procedurilor stocate Java, astfel încât un proiectant sau dezvoltator sa cunoasca toate posibilitatile ce i se ofera.

Avantajul PL/SQL este o corespondenta perfecta între tipurile de date din baza si cele ale limbajului, zona în care Java are multe conversii de facut. Din acest motiv, recomandarea firmei Oracle este de a se scrie proceduri PL/SQL pentru sarcini de manipulare intensiva a datelor, procedurile Java fiind destinate zonei în care se efectueaza calcule intense combinate cu accesuri rare la informatii.

Masina virtuala Java din Oracle 8i

Masina virtuala Java implementata în Oracle 8i, cunoscuta sub numele de Aurora, ofera un mediu de executie conform cu JDK 1.1.6. Evident, masina virtuala nu are implementata partea de grafica, dar în rest ofera un mediu complet Java. Aurora este proiectata sa ruleze în acelasi spatiu de adrese cu nucleul bazei de date, motiv pentru care consumul de memorie este redus, iar performantele ridicate.

Trebuie remarcat ca codul poate fi lansat în executie atât prin intermediul unor apeluri din SQL, PL/SQL sau alt cod Java, cât si prin intermediul unor apeluri IIOP, în cazul obiectelor Java/CORBA care ruleaza în cadrul serverului. Codul compilat joaca o mare importanta în Aurora, majoritatea claselor de sistem fiind gata compilate, deci se executa la viteza maxima. Exista, de asemenea, posibilitatea de a compila nativ si codul procedurilor stocate, deci timpul de executie se reduce mult.

Gestionarul de biblioteci este cel care încarca sursele, clasele sau fisierele resursa Java în baza de date, ca rezultat al comenzii SQL CREATE JAVA. Nu este posibila accesarea directa a acestor obiecte; doar masina virtuala poate sa le foloseasca.

Gestionarul de memorie este cel care se ocupa de colectarea memoriei disponibile. Mecanismul de colectare se bazeaza pe tehnici de alocare a memoriei adaptate la timpul de viata a obiectelor. Astfel, obiectele care supravietuiesc în afara scopului functiei care le-a creat sunt migrate în alte zone de memorie. Pentru reducerea necesarului de memorie, gestionarul de memorie partajeaza starea constanta a obiectelor, cum ar fi definitiile de clase si variabilele statice finale.

Compilatorul Aurora are rolul de a compila sursele care sunt introduse în baza de date prin intermediul unei fraze CREATE JAVA SOURCE. Rezultatul este un bytecode compatibil JDK.

Interpretorul este si el compatibil JDK 1.1.6 si se executa pe componenta MultiThreaded Server (MTS) a serverului Oracle, cea care gestioneaza sesiunile si planifica executia programelor Java. Sistemul de asistenta la executie (runtime) permite apelul de metode native si comunicatii din interior sau exterior, dar aceste actiuni se pot executa doar daca utilizatorul are privilegiile corespunzatoare.

Încarcatorul de clase este cel care localizeaza, încarca si initializeaza clasele Java stocate în baza de date. El citeste clasa, si apoi genereaza structurile de date de care este nevoie pentru executie. Constantele sunt plasate, pentru eficienta, într-o zona de memorie partajata cu alte sesiuni. De asemenea, el invoca compilatorul de Java automat, daca se constata ca este nevoie de recompilarea surselor si sursele sunt disponibile. Verificatorul este cel care verifica daca bytecode-ul Java respecta regulile si formatul predefinit, împiedicând astfel violarea restrictiilor de acces. Verificatorul este parte integrata în sistemul de securitate, asigurat atât de securitatea Java cât si de cea a bazei de date Oracle.

Din punct de vedere al performantelor, scopurile principale ale proiectantilor Aurora a fost scalabilitatea si executia rapida pentru cod care ruleaza mult timp. Asadar, orice test aplicat acestei masini virtuale trebuie sa aiba în vedere si aceste aspecte particulare. Pentru moment, JVM clasica, de la Sun, este mai rapida pentru activitatile foarte scurte (de exemplu, proceduri stocate care efectueaza calcule de tipul 2+2), dar devine mai slaba în performante o data cu timpul de rulare. De asemenea, trebuie tinut cont si de faptul ca scopul acestei implementari este de a sustine, în final, cât mai multe cereri simultan, iar aici testele au aratat ca Aurora este de cel putin 4 ori mai scalabila decât orice alta masina virtuala. Pentru cei pe care timpul de executie îi nemultumeste, Oracle pune la dispozitie JServer Accelerator, care realizeaza translatarea codului Java în cod C ce poate fi compilat pe masina server si executat ulterior prin intermediul unei biblioteci partajate care este încarcata de Aurora. O alta crestere de viteza este data de furnizarea, alaturi de clasele de sistem, a unor packag-uri ORB si JDBC ce au asociate versiuni compilate nativ.

Evident, partea de legatura cu baza de date este de înalta calitate. Driverul JDBC ruleaza chiar în interiorul serverului, oferind cel mai rapid acces posibil la date. El este conform cu specificatiile JDBC 1.22 de la Sun si suporta tipurile specifice bazelor de date Oracle, seturi de caractere nationale si apelul de proceduri stocate. Conformitatea cu standardul JDBC face posibila punerea în executie a aceluiasi cod atât în baza de date, cât si într-un applet sau aplicatie la client. În mod similar, la nivelul serverului exista si o implementare de SQLJ, care permite integrarea mult mai usoara a codului SQL cu cel Java.

Câteva cuvinte si despre restrictiile care sunt impuse codului care se executa pe Aurora JVM, deci si procedurilor stocate. În primul rând, se permite folosirea tuturor claselor din partea de grafica, cu conditia de a nu se încerca materializarea unei ferestre.

Programele cu mai multe fire de executie se executa pe server fara modificari, dar ele trebuie sa tina cont de faptul ca implementarea este cu fire de executie gestionate în spatiul utilizator. Cu alte cuvinte, în mediul serverului firele de executie nu sporesc concurenta, pentru ca acest lucru este guvernat de catre MTS si metode de optimizare specifice serverului. Asadar, diferentele importante sunt ca firele de executie pe server:

• ruleaza secvential, nu concurent;
• sunt cooperative, si nu preemptive, deci daca un fir intra într-o bucla infinita nu mai poate rula nici un alt fir;
• daca sunt create în interiorul unui apel, firele mor la terminarea apelului.

Practic, în terminologia Oracle, mutithreading se refera la sesiuni utilizator concurente, si nu la mai multe fire de executie în sensul Java. Planificarea executiei Java pentru atingerea scopului de tratare a cât mai multi utilizatori simultan este realizata de sistemul de gestiune, si nu de catre masina virtuala Aurora.

Contextul de rulare al procedurilor stocate

Înainte de prezentarea modului în care se face dezvoltarea unei proceduri stocate, este utila mentionarea locurilor în care pot fi întâlnite aceste proceduri, sau asa numitele contexte de rulare.

Prima utilizare este cea clasica, data chiar de nume, si anume proceduri (sau functii) apelabile explicit din SQL sau PL/SQL. Ele pot primi parametri, iar functiile pot fi apelate si din fraze SQL de manipulare a datelor (DML), cum ar fi INSERT, UPDATE, DELETE si SELECT.

A doua utilizare este de componenta logica în cadrul unui trigger. În acest caz, procedura stocata este asociata cu o tabela sau o vedere anume. SGBD-ul declanseaza automat triggerul atunci când o anumita operatie DML modifica tabela sau vederea. Declansarea triggerului se traduce printr-un apel CALL al procedurii stocate. Rolul principal al triggerelor este de a completa mecanismele oferite de baza de date, prin impunerea unor reguli de afaceri mai complexe, cum ar fi prevenirea tranzactiilor invalide, înregistrarea si auditul evenimentelor.

Cea de-a treia utilizare este cea de metoda pentru obiectele stocate în baza de date si create cu fraza CREATE OBJECT. În acest context, procedura stocata devine o metoda a unui obiect si ajuta, o data în plus, la extinderea lucrului cu obiectele din Oracle8.

Dezvoltarea unei proceduri stocate

Primul pas pe drumul crearii si utilizarii unei proceduri stocate este cel de dezvoltare. Pentru dezvoltare, se recomanda folosirea unui mediu vizual, care sa stie sa automatizeze si unii din pasii urmatori. Cel mai potrivit este Oracle JDeveloper, fiind foarte bine integrat cu restul gamei de produse Oracle, oferind si multe utilitare de control.

Procedura stocata din baza de date se obtine dintr-o metoda a unei clase Java. Atunci când se apeleaza o procedura stocata nu se creeaza un obiect; clasa din care face parte metoda transformata în procedura stocata nu este instantiata. Implicatiile acestui fapt sunt ca:

• nu exista constructor al clasei;
• toate variabilele si metodele sunt statice;
• fiecare metoda care are nevoie de o conexiune la baza de date trebuie sa verifice conexiunea si sa o stabileasca, daca nu era deja. O solutie este declararea unui obiect static de tip conexiune, care sa fie initializat cu null si verificat la începutul fiecarei metode.

Alte diferente fata de o clasa normala sunt la modul de transmitere al parametrilor. O procedura stocata poate avea parametri din intrare si/sau de iesire. Variabilele de iesire sunt declarate ca vectori. Acest lucru este necesar pentru a putea pasa parametri de iesire ca referinte la obiecte, si nu ca variabile primitive.

Ultima caracteristica este folosirea unei conexiuni JDBC speciale, cea implicita pentru driverul JDBC din baza de date. Modul de obtinere al acestei conexiuni poate fi remarcat în codul sursa al exemplului de procedura stocata. Driverul JDBC din baza de date nu suporta modul de lucru autocommit, deci este necesar ca utilizatorul sa gestioneze explicit tranzactiile.

Pentru ilustrarea fazelor prin care trebuie trecut pentru a utiliza o procedura stocata, se va considera cazul unei proceduri care face inserarea unui obiect într-o magazie. Metoda care va fi transformata în procedura stocata se numeste addStockItem, iar clasa din care face parte este StockManager.

Încarcarea unei proceduri stocate

Cel de-al doilea pas spre utilizarea finala a unei proceduri stocate este încarcarea procedurii stocate în baza de date. În acest scop, Oracle 8i ofera un utilitar numit loadjava, care permite automatizarea procesului de încarcare. JDeveloper, de la versiunea 2.0 în sus, permite ca o optiune de distributie si punere în exploatare a unei clase si încarcarea de proceduri stocate. La momentul încarcarii trebuie definite toate metodele care se doresc a fi transformate în proceduri stocate, pentru ca pentru acestea trebuie generate specificatori de apel (call specs) în dictionarul de date Oracle. Aceasta activitate poarta numele de publishing (publicare). Succesiunea de evenimente si entitatile implicate în cele doua activitati sunt ilustrate în figurile: "Modul de lucru al utilitarului loadjava" si "Utilizarea specificatorilor de apel".

Trebuie facuta o distinctie clara între un învelis SQL sau PL/SQL si un specificator de apel. În primul caz, se creeaza o procedura PL/SQL care apeleaza, din interior, procedura stocata Java. În cel de-al doilea caz, se genereaza doar o declaratie de procedura, pe baza careia procedura poate fi identificata si îsi poate primi parametri. Rolul specificatorului de apel este deci de a permite asocierea numelor de metode Java, a tipurilor parametrilor si a rezultatelor cu echivalentele din SQL.

Un exemplu de rulare a utilitarului loadjava, în care cerem ca sa se produca compilarea codului si rezolvarea referintele externe din clase (optiunea -v) si conectarea la baza de date prin driverului JDBC de tip thin (optiunea -t), este:

Crearea package-ului în care sta procedura stocata si declararea ei se face prin urmatoarele doua comenzi SQL, generate automat daca se foloseste asistentul de distributie (Deployment Wizard) din JDeveloper.

Verificarea cu SQL*Plus a functionarii procedurii stocate se poate face prin simpla comanda:

CALL stock_manager.add_stock_item(2000, "speakers", 10);

Utilizarea unei proceduri stocate

Daca toti pasii au fost parcursi corect, procedura este deja în baza de date si deja putem sa o folosim din programe. De exemplu, o secventa de cod Java/SQLJ care sa faca apel la o procedura stocata este:

Aspecte de securitate

În mod normal, procedurile stocate Java sunt executate cu privilegiile celui care invoca procedura. Toate obiectele care nu sunt calificate sunt cautate în schema celui care invoca procedura. Pentru a schimba acest comportament implicit, se poate utiliza un parametru (definer) al utilitarului loadjava.

Folosirea unei proceduri ce se executa cu drepturile celui care o invoca (invoker rights) este utila pentru crearea unui depozit central de proceduri stocate. De exemplu, o firma cu mai multe sucursale poate sa plaseze o procedura de analiza pe un server central. Fiecare filiala, când va vrea sa faca analiza, o va face pe propria baza de date. Daca se doreste ca procedura centralizata sa faca modificari pe baza centrala (de exemplu auditul analizelor), atunci procedura de analiza va trebui sa apeleze alta procedura, de înregistrare, care sa se execute cu drepturile celui care a definit-o. Cele doua cazuri sunt ilustrate în figura "Metodele de executie a codului Java".

Executia unei proceduri se poate face doar daca utilizatorul are drept de executie. Un utilizator poate capata drepturi de modificare a unei tabele, prin executia unei proceduri stocate, chiar daca el nu are drepturi de modificare a tabelei.

În plus, nu trebuie uitate si restrictiile impuse de masina virtuala. Astfel, o procedura stocata nu are acces la discul serverului si nu poate comunica în retea decât daca se specifica explicit anumite privilegii.

Concluzii

Caracteristicile platformei Java o fac ideala pentru programarea la nivelul serverului bazei de date, iar optimizarile specifice Oracle 8i creeaza un mediu de productie pentru aplicatiile Java. Java permite asamblarea aplicatiilor folosind componente software prefabricate (off-the-shelf). Siguranta tipurilor si gestiunea automata a memoriei permit integrarea strânsa cu SGBDR-urile moderne. În plus, Java permite distribuirea transparenta a componentelor aplicatiilor în retea.

Astfel, Java si SGBDR permit asamblarea rapida a aplicatiilor bazate pe retea si componente software, aplicatii care pot evolua lin pe masura ce se schimba cerintele afacerii. Codul aplicatiei si depozitul de date poate fi mutat de pe calculatorul de pe birou în cadrul unei retele inteligente sau pe servere de sprijin pentru arhitectura NCA (Network Computing Architecture). Ceea ce este cel mai important este ca aceste aplicatii pot fi accesate de la orice program de navigare.

Performantele implementarii Oracle de masina virtuala din cadrul serverului Oracle 8i cresc atractivitatea dezvoltarii de aplicatii Java. Astfel, dupa cucerirea sectorului aplicatiilor client, Java trece la atac si în domeniul bazelor de date. Iar surprizele nu se vor opri aici: urmatoarea versiune de Oracle 8i (8.1.6) va oferi suport pentru alte tipuri de componente Java, pe aceeasi masina virtuala. JSP (Java Server Pages), si servlet-urile vor fi tehnologiile Java implementate alaturi de EJB, CORBA, proceduri stocate Java.

Tehnologiile care vor modela viitorul apropiat sunt cele legate de portabilitate, standardizare si universalitate. Java este solutia care îndeplineste aceste conditii pentru continut executabil, asa cum UML (Unified Modelling Language) si XML (eXtensible Markup Language) o fac pentru modelarea sistemelor, respectiv reprezentarea datelor. Combinatia dintre cele trei forte nu poate duce decât la lucruri bune, iar firmele puternice de software, printre care si Oracle, pregatesc surprize placute prin produse ce se bazeaza pe toate aceste tehnologii. Integrarea în produsele de dezvoltare a acestor tehnologii permite dezvoltarea în timp mai scurt a unui software de calitate si deschis interactiunilor cu alte sisteme.

Bazele de date si mediile de dezvoltare asociate sunt deja pregatite sa sprijine aplicatii bazate pe tehnologiile Internet. Sunteti pregatiti sa le exploatati? Sper ca vocea din reclama a maestrului stefan Iordache sa vorbeasca si în numele dumneavoastra ...