Program de Editare Si Prezentare Orar pe Internet

Program de editare și prezentare orar pe Internet

Introducere

Tema proiectului este realizarea unui program de editare și prezentare orar pe Internet. Toate acestea în vederea îmbunătățirii actualului sistem de informare privitor la orarul studenților și profesorilor dintr-o instituție școlară, în cazul de față Secția Calculatoare din cadrul Facultăți de Inginerie, Universitatea „Lucian Blaga”, Sibiu.

Pentru început trebuie menționat că nu am dorit a face un program de generare al orarului, program care rămâne în continuare o provocare pentru cei ce vor dori să implementeze un algoritm care permite soluționarea acestei probleme.

În lucrarea de fata am renunțat la abordarea tuturor problemelor legate de generarea și m-am axat pe editarea și prezentarea orarului, pe suportul tehnologiei Internet.

Pentru implementare am ales mediul de dezvoltare Java Builder6. Alegerea acestuia

s-a bazat pe aptitudinile pe care le-am dobândit de-a lungul celor cinci ani de facultate și dorinței de a-mi aprofunda cunoștințele în domeniul gestionării bazelor de date, cu ajutorul lui.

Pentru a-mi atinge obiectivele am ales o modalitate, dacă nu cea mai rapidă, poate cea mai clară din punct de vedere al programării în Java, și anume folosirea simultană a JSP-urilor (JavaServer Page) și servlet-ilor.

Am ales această modalitate datorită avantajelor pe care mi le oferă: în primul rând sunt mai bine familiarizat din punct de vedere al programării în Java cu servletii si JSP-urile, iar în al doilea rând astfel am avut posibilitatea ca în servleti să folosesc numai cod Java, iar în JSP-uri numai cod HTML. Aceasta tehnica, după părerea mea, ajută la parcurgerea mai ușoara a codului servlet-ilor si a JSP-urilor folosite, fără a crea dificultăți în depanarea programului.

Baza de date folosită este deja creată, ea fiind utilizata actualmente de un alt program numit „Stat de funcții”. Informațiile preluate sunt verificate si corecte. Pentru a-mi atinge scopul propus, uneia dintre tabelele acestei baze de date i-au fost introduse mai multe câmpuri în continuarea celor existente, câmpuri care nu afectează cu nimic buna funcționare a programului menționat; de asemenea a mai fost necesară crearea câtorva tabele, necesare propriei aplicații.

Acesta bază de date nu este completă deoarece în ea se rețin informații legate doar de Catedra de Calculatoare. Materiile de genul „Matematica”, „ Management”, materiile din modulul pedagogic, și multe altele , nu există deoarece acestea sunt predate de profesori care nu aparțin catedrei de calculatoare, ci altor catedre sau facultăți.

Lucrarea de față este împărțită în cinci capitole, fiecare având un obiectiv bine definit:

– Capitolul I : „Java Builder. Prezentare generală” – își propune descrierea pe scurt a mediului de programare Java Builder, servlet-ilor, JSP-urilor și serverului Web Tomcat.

– Capitolul II : „Baze de date. SQL. MySQL server” – se prezintă câteva noțiuni generale pentru lucrul cu baze de date și proiectarea acestora, o mică introducere în limbajul SQL (Structured Query Language), precum și prezentarea serverului de baze de date MySQL.

– Capitolul III : „Java Builder. Proiectarea aplicațiilor de baze de date” – descrie modalitatea de lucru cu baze de date puse la dispoziție de Java Builder, și driverul JDBC.

– Capitolul IV : „Proiectarea bazei de date” – se descriu pe scurt tabelele din baza de date „Orar”, folosite pentru realizarea demersului propus.

– Capitolul V : „Descrierea aplicației” – se descrie programul realizat, începându-se cu o prezentare a modului în care acesta poate fi utilizat, după care se prezintă implementarea propriu-zisă.

Motivație

Dorința de a veni în sprijinul modalităților actuale de editare și vizualizare a orarului, a fost primordială în alegerea acestei teme.

De asemenea cu atât mai mult cu cât programul rulează pe Internet, mi s-a părut mult mai accesibil profesorilor si studenților, decât vechea metoda de afișare a orarului. Modificarea sălilor aferente grupelor de studiu, este posibilă tot prin Internet, deoarece în cazul in care trebuie făcută o modificare urgent, profesorul responsabil cu programul să nu fie condiționat de locația în care are posibilitatea de a o remedia.

Cu toate că nu am avut în vedere chiar toate problemele care pot apărea în timpul editării și afișării acestuia, eu consider că primul pas a fost făcut.

Sper ca facilitățile pe care le oferă această aplicație să fie un ajutor binevenit tuturor celor care sunt interesați de orarul Catedrei de Calculatoare si Automatizări din cadrul Facultății de Inginerie.

Capitolul I

Java Builder. Prezentare generală

JBuilder este de fapt o familie de unelte de dezvoltare menite să producă aplicații performante și independente de platformă. El este proiectat pentru realizarea de proiecte pentru orice nivel din Information Networks, pornind de la simple apleturi și până la aplicații client / server, aplicații ce accesează baze de date sau aplicații distribuite. Codul sursă generat este 100% Java și nu conține marcaje sau scripturi ascunse, caracteristice mediului.

Intern, JBuilder-ul este realizat din componente, arhitectura sa deschisă permițând adăugarea de noi componente, produse de către alte companii. Mai pot fi adăugate și aplicații plug-ins și componente JavaBeans, ce pot fi utilizate apoi în aplicațiile dezvoltate.

Datorita diferitelor nivele la care pot fi realizate aplicațiile, JBuilder poate fi găsit în trei ediții distincte: Standard, Professional, Client / Server.

În continuare se va prezenta varianta Client / Server, variantă cu ajutorul căreia au fost implementate programele acestui proiect.

1.1 JBuilder Client / Server

După cum îi spune și numele, în JBuilder se pot realiza aplicații client / server și aplicații distribuite. Ea cuprinde toate facilitățile din versiunea Professional, la care se mai adaugă suport complet pentru RMI.

1.1.1 Interfața utilizator

Pentru cei ce au lucrat în Delphi sau C++ Builder, lucrul în JBuilder li se va părea ușor, deoarece interfața utilizator este extrem de familiară: același design, aceleași ferestre de lucru și așa mai departe. Fereastra principală este asemănătoare cu cea din Visual Café de la Symantec, prin faptul că ocupă doar partea de sus a ecranului, lăsând partea de jos liberă pentru ferestrele de lucru. Ea conține, pe lângă un meniu și o bară de unelte și o paletă cu componente JavaBeans, organizate pe categorii. Aici programatorii, vor putea adăuga propriile componente, pe care să le utilizeze apoi în fereastra utilizator a aplicațiilor Java.

Începerea unei noi aplicații, se face întotdeauna prin apelul galeriei de obiecte, cu ajutorul comenzii File|New. De aici, pot fi apelați diferiți vrăjitori, ce vor putea crea de la simple schelete de cod sursă, până la aplicații sau componente complet funcționale. Tot aici, utilizatorul are posibilitatea de a alege realizarea unei aplicații sau a unui proiect nou, adăugarea unui meniu, a unei ferestre de dialog, a unor module de date sau poate apela BeansExpress pentru a crea o nouă componentă JavaBeans și așa mai departe. Mai pot fi găsite bucăți de aplicații gata finisate, cum ar fi ferestre de dialog cu butoanele uzuale sau componente JavaBeans simple.

Lucrul efectiv la o aplicație Java, se face prin intermediul ferestrei AppBrowser, ce este asociată automat fiecărui proiect deschis în JBuilder. Aceasta a fost concepută pentru a reduce la minimum numărul de ferestre cu care se lucrează la un moment dat. Astfel, poate fi realizată o întreagă aplicație, oricât de complexă, fără a mai deschide nici o altă fereastră. AppBrowser este împărțită, în majoritatea timpului de lucru, în trei părți. Prima este destinată navigării prin fișierele unui proiect. De aici, poate fi ales fișierul asupra căruia se lucrează la un moment dat și afectează și conținutul celorlalte părți. A doua parte, ce ocupă și cel mai mult spațiu, este destinată vizualizării și editării fișierelor alese în prima parte. Astfel, pe lângă fișiere Java, în această parte programatorul poate să vadă sau să editeze fișiere HTML, de text sau poze (pentru acestea se asigură numai vizualizare). Dacă este utilizată pentru a vizualiza fișiere HTML, atunci fereastra primește funcționalitatea unui navigator. Tot în această fereastră, pot fi realizate vizual și ferestrele utilizator ale aplicaților, ce sunt convertite apoi în cod sursă Java. Pentru facilitarea lucrului, această parte poate fi extinsă pe toată suprafața ferestrei AppBrowser, printr-o combinație rapidă de taste. În ultima parte a ferestrei AppBrowser, poate fi văzută structura internă a fișierului ales în prima parte. Dacă este vorba despre un fișier Java, aici poate fi văzută ierarhia claselor, metodele și variabilele utilizate.

În funcție de contextul în care se află un anumit proiect, AppBrowser își poate schimba numărul de părți componente sau introduce noi utilități asociate părților. Astfel, pot fi văzute fișierele utilizate într-un proiect direct pe structura de directoare de pe discul hard sau poate fi văzută ierarhia de clase utilizate în întregul proiect, pot fi văzute alte părți repartizate pentru mesajele de eroare și pentru depanarea unei aplicații sau pot fi văzute rezultatele unei căutări date pe întregul proiect.

Un lucru demn de menționat, este posibilitatea trecerii din proiectarea vizuală a interfeței utilizator, al viitoarelor aplicații, la editarea codului sursă Java și invers, fără pierderi de informații și fără că mediul JBuilder să introducă marcaje speciale în codul sursă. Designul interfeței utilizator îl poate ajuta pe programator să realizeze întregi aplicații, fără a scrie nici măcar o linie de cod sursă, prin simpla tragere a componentelor utilizate din paleta din fereastra principală în AppBrowser și prin utilizarea ferestrei Component Inspector, ce conține toți parametri legați de componenta selectată la un moment dat.

O altă facilitate a interfeței utilizator din JBuilder, este dată de arhitectura internă a acestuia. Astfel, pot fi introduși oricând noi vrăjitori, componente JavaBeans sau aplicații pentru controlul versiunilor sau pentru testarea aplicațiilor. Un astfel de vrăjitor este și Wrap Applet Wizard ce poate converti un applet Java într-o componentă JavaBeans.

Executabilele Java rulează într-o așa numita JVM (Java Virtual Machine). Acesta este practic un interpretor care interpretează codul Java compilat. Ne putem gândi la JVM că la un procesor virtual. De fapt specificațiile mașinii virtuale Java sunt chiar că ale unui procesor, și exista și implementări hardware. Avantajul mașinii Virtuale Java este că codul odată compilat poate fi rulat în orice sistem de operare. Dezavantajul este că un executabil Java este executat mai lent decât un executabil obișnuit.

1.2 Servleți

1.2.1 Generalități

În ultimii ani, Sun a pus la dispoziția utilizatorilor o mulțime de noi tehnici de dezvoltare: Servlets, RMI, JNDI , JSP fiind doar câteva dintre ele.

CGI este probabil cea mai des utilizată metodă pentru generarea dinamică a paginilor de Web. Dar principala problemă în cazul utilizării CGI-urilor constă în faptul că fiecare nouă cerere de la un client (în general un browser web) implică lansarea de către serverul HTTP a unei noi instanțe a CGI-ului respectiv. Aceasta conduce la un consum considerabil de resurse în cazul unor situri cu un număr mare de hit-uri. S-au găsit mai multe soluții la această problemă, majoritatea concentrându-se asupra menținerii executabilului persistent între cererile client. Aceasta are și beneficiul menținerii deschise a unor resurse mari, cum ar fi conexiuni la baza de date.

Servleții sunt clase java, încărcate și menținute rezidente de către daemon-ul HTTP. Când servletul este încărcat, el este inițializat prin apelul unei metode. În acest punct se pot deschide conexiuni la bazele de date, conexiuni ce pot fi menținute între apelurile clienților. În plus, există și un număr de clase care facilitează interacțiuni mai complexe îase care facilitează interacțiuni mai complexe între server și browser, cum ar fi cookie-urile. Un servlet extinde funcționalitatea unui server. Clasele și interfețele necesare pentru a defini servleți sunt încapsulate în pachetele javax.servlet și javax.servlet.http.

Cea mai uzuală implementare a modelului cerere-răspuns este cea utilizată în relația dintre un browser de web și un server de web. Când utilizatorul selectează un sit web în browser (aplicația client), cererea este transmisă serverului web (aplicația server). În mod normal, serverul web răspunde clientului trimițând pagina cerută (în general HTML).

Tehnologia servlet-ilor a fost creată în mare parte pentru a folosi protocolul HTTP, dar și pentru alte tehnologii. Servlet-ii sunt utilizați și pentru a dezvolta așa numitele soluții „Web-based”, pentru a asigura un acces securizat la un sit Web, pentru a interacționa cu baze de date în beneficiul clientului, pentru a genera dinamic pagini HTML, pentru a manipula informații care să identifice unic un client pe parcursul unei sau mai multor sesiuni etc.

În principiu, orice CGI poate fi rescris ca servlet. Mulți proiectanți sunt de părere că servleții sunt soluția optimă pentru aplicațiile care utilizează intensiv baze de date, pentru a comunica cu așa numiții „thin-client” – aplicații care necesită un minim de suport în partea de client. Serverul este responsabil pentru accesul la baza de date. Clienții se conectează la baza de date utilizând protocoale standard suportate de toate platformele client. De aceea, partea de cod este scrisă o singură dată și stocată în partea de server. Acesta constituie un avantaj și datorită faptului că distribuirea unei noi versiuni se face simplu, prin înlocuirea codului într-un singur loc – pe server – și nu la fiecare utilizator în parte.

Cea mai des folosită utilizare a servlet-ilor implică comunicarea dintre un client și un server prin protocolul HTTP. Clientul trimite o cerere HTTP serverului. Serverul primește cererea și o redirectează servletului pentru a fi procesată. Servletul procesează cererea (care cel mai adesea implică și acces la o bază de date), apoi returnează răspunsul clientului, în mod normal sub forma unei pagini HTML, dar și alte formate de date sunt posibile, cum ar fi imagini, date binare, etc.

Multe situri țin o urmă (trace) a clienților, pentru a putea avea informații despre un anumit utilizator, informații utilizate pentru a putea oferi un conținut cât mai aproape de preferințele utilizatorului respectiv. Două dintre tehnicile utilizate în acest scop sunt cookie-urile și session tracking-ul. Cookie-urile sunt fișiere de dimensiuni mici trimise de către server clientului că parte a header-ului HTTP. Acestea conțin informații despre sesiunea curentă și pot fi salvate pe disc, în vederea accesării lor pentru sesiuni ulterioare. Când un browser emite o cerere către un server, cookie-urile anterioare primite de către client de la serverul respectiv sunt trimise din nou la server (daca nu au expirat) ca parte a cererii formulate de browser. Cookie-urile sunt șterse automat în momentul în care au expirat.

Unii clienți nu permit ca cookie-urile să fie memorate. În mod normal, când este refuzată memorarea cookie-urilor, utilizatorul este informat că aceasta ar putea duce la imposibilitatea accesării paginilor din situl respectiv. Implicit, cookie-urile sunt utilizate doar pentru sesiunea curentă de browsing (până când utilizatorul închide browser-ul). Când un servlet este apelat dintr-o pagină HTML, browserul este cel care trimite cookie-urile în header-ul cererii HTTP și tot el este responsabil cu citirea și memorarea cookie-urilor din header-ul răspunsului HTTP. Când servletul este apelat dintr-un applet, programatorul applet-ului trebuie să adauge cookie-urile la hederul cererii HTTP și tot el trebuie să citească și să memoreze cookie-urile din headerul răspunsului HTTP.

De asemenea servlet poate indica browser-ului să afișeze conținutul unui anumit URL. De exemplu, după ce un servlet procesează cu succes datele trimise de utilizator, o pagină în care se menționează că datele au fost procesate corect (sau una care ar urma firesc după procesarea datelor – de exemplu în cazul unui login) ar trebui afișată. Aceasta ar fi o pagină html situată la o anumită locație (de pildă http://www.test.com/OK.html). O soluție ar fi citirea acestei pagini de la locația respectivă și trimiterea ei ca text prin stream-ul de ieșire al servletului. Dar apare cazul în care pagina html are un tag "img", caz în care servlet-runner-ul afișează un mesaj de eroare "servlet img not found". Pentru aceasta se apelează metoda „sendRedirect()” din obiectul „response” primit că parametru.

1.2.2 API-ul

Din punct de vedere arhitectural, toți servleții trebuie să implementeze interfața „javax.servlet.Servlet”. Majoritatea metodelor interfeței Servlet sunt invocate în mod automat de către serverul de pe care servletul este rulat. Această interfață definește următoarele cinci metode:

void init( ServetConfig config )

Este automat apelată o singură dată în ciclul de execuție pentru a inițializa servletul. Argumentul „ServletConfig” este pasat automat de către serverul care execută servletul.

ServletConfig getServletConfig()

Întoarce o referință la un obiect care implementează interfața „ServletConfig”, și care asigură accesul la informații legate de configurații cum ar fi parametrii de inițializare și de context – prin „ServletContext” – care asigură accesul la informații de mediu, cum ar fi informații despre serverul pe care se execută servletul.

void service( ServletRequest request, ServletResponse response )

Este prima metodă apelată pentru fiecare servlet pentru a răspunde unei cereri client.

String getServletInfo()

Această metodă este definită pentru a permite programatorului să returneze un String în care să se menționeze autorul servletului, versiunea acestuia, etc.

void destroy()

Această metodă de "curățire" este apelată în momentul în care un servlet este terminat de către serverul pe care se execută. În această metodă se vor elibera resursele folosite de servlet, cum ar fi fișiere deschise, conexiuni deschise la baze de date etc.

Toți servleții extind clasa HttpServlet, care definește capabilități extinse de procesare pentru servleți, extinzând funcționalitatea serverelor Web. Metoda cheie în orice servlet este „service”, care primește că parametru un obiect de tip „ServletRequest” și unul de tip „ServletResponse”. Aceste obiecte asigură accesul la stream-urile de intrare și ieșire care permit servletului să citească date de la client și să trimită date către client. Aceste stream-uri pot fi fie de tip byte sau de tip caracter. Dacă apar probleme în execuția servletului, este generată o excepție de tip „ServletException” sau „IOException”.

Clasa HttpServlet suprascrie metoda service pentru a face distincție între cererile tipice recepționate de la clienți (de exemplu browsere Web). Două dintre cele mai des întâlnite tip de cereri HTTP sunt GET și POST. O cerere de tip GET extrage informații de pe server. În general printr-o cerere de tip GET sunt trimise spre client documente HTML sau imagini. O cerere de tip POST e folosită pentru a trimite date de la client spre server. Cea mai uzuală utilizare a cererilor de tip POST este de a trimite către server informații dintr-un form HTML în care clientul (utilizatorul) introduce date pentru a căuta pe Internet, sau pentru a interoga o bază de date, sau pentru a trimite serverului informații de autentificare etc. Majoritatea browser-elor salvează pe disc (în cache) paginile web accesate, pentru a fi încărcate mai rapid la o eventuală re-apelare. De regulă, cererile de tip POST fac excepție, datorită faptului că răspunsul unui server la o cerere de tip POST nu e, în general, identic cu răspunsul anterior.

Clasa „HttpServlet” definește două metode „doGet” și „doPost” pentru a răspunde cererilor client de tip GET, respectiv POST. Aceste metode sunt apelate automat de către metoda service (care este apelată când o cerere client ajunge la server). Metoda service determină tipul cererii, apoi apelează metoda corespunzătoare. Desigur, mai sunt și alte tipuri de cerere în afară de aceste două tipuri.

La orice apel al metodelor doGet și doPost, câte un obiect de tip „HttpServletRequest” și „HttpServletResponse” este primit că parametru. Serverul Web care execută servletul creează aceste obiecte, pe care le pasează metodei service, care, după ce identifică tipul cererii, le pasează mai departe metodei corespunzătoare.

Obiectul „HttpServerRequest” conține cererea de la client. Un set de metode sunt prevăzute pentru a permite servletului să proceseze cererea clientului. Câteva din aceste metode provin din interfața „ServletRequest” (interfață pe care clasa „HttpServletRequest” o extinde). Câteva dintre metodele-cheie sunt:

String getParameter( String name )

Întoarce valoarea asociată parametrului trimis servletului că parte a cererii GET sau POST. Argumentul „name” trimis reprezintă numele parametrului.

HttpSession getSession( boolean create)

Întoarce un obiect de tip „HttpSession” asociat cu sesiunea curentă de browsing a clientului. Prin această metodă se poate crea un obiect de tip „HttpSession” prin trimiterea unui argument create = true, dacă un obiect de acest tip nu există deja pentru clientul respectiv. Obiectele de tip „HttpSession” pot fi folosite similar cu cookie-urile pentru a identifica unic un client.

Pentru a detecta numele și versiunea browserului de unde a venit cererea către servletul curent, se poate apela metoda „req.getHeader”si la fel si pentru a afla de la ce URL a venit cererea.

Prin intermediul obiectului „HttpServerResponse”, servletul trimite răspunsul către client. Clasa „HttpServerResponse” extinde interfața „ServletResponse”, deci metodele definite în această interfață vor fi implementate în această clasă.

PrintWriter getWriter()

Este apelată pentru a obține un stream de tip caracter și pentru a permite trimiterea de text către client.

1.2.3 Cererile de tip GET

Scopul principal al cererilor de tip GET este de a primi conținutul unui URL specificat – în mod normal o pagină HTML. Prima linie setează tipul conținutului ce va fi trimis spre browser (astfel browserul va ști cum să interpreteze conținutul primit). Apoi se obține din obiectul „HttpServletResponse” un obiect de tip „PrintWriter”, următoarele două instrucțiuni tipărind, respectiv, headerul fișierului HTML și corpul acestuia.

1.2.4 Cererile de tip POST

O cerere de tip POST are că scop, în principal, trimiterea de date dintr-un form HTML către un server pentru procesare. Un form HTML permite clientului să trimită informații către server. Atributul „action” specifică aplicația rezidentă pe server care va fi apelată pentru a rezolva cererea. Utilizatorul este cel care decide momentul în care acțiunea este trimisă spre rezolvare, apăsând un control de tip „submit”. Atributul „method” specifică tipul cererii ce este trimisă spre rezolvare. Permite serverului să ia decizia referitoare la modul în care va fi rezolvată cererea. De asemenea, specifică browserului dacă să atașeze sau nu argumente în coada URL-ului prezent la atributul „action”. În metoda „init” se preia din fișierul de configurări valoarea parametrului 'nume', valoare ce va fi folosită în cazul în care clientul nu completează nimic în câmpul 'nume' din form. În codul HTML, la atributul „method” este specificat "post", deci metoda apelată din servlet va fi doPost. În această metodă, în prima linie se setează tipul conținutului, iar apoi se preia valoarea parametrului "nume" trimis de client. În cazul în care nu s-a trimis nici un parametru cu acest nume, valoarea lui va fi null. În acest caz, am ales că soluție inițializarea lui cu valoarea implicită (default) – cea citită din fișierul de configurații. În continuare este preluat un stream de ieșire din obiectul de tip „HttpServletResponse”, în acest stream fiind tipărite apoi antetul și corpul fișierului HTML rezultat.

Servlet-urile sunt componente independente de platformă și protocol care extind într-o manieră dinamică un (super) server cu suport Java. Servlet-urile reprezintă pentru server, ceea ce applet-urile sunt pentru client (browser) – obiecte (bytecode) ce pot fi încărcate dinamic din rețea (Internet) și executate pe mașina locală. Diferența constă în faptul că servlet-urile sunt obiecte lipsite de interfață sau componente grafice (GUI).

Servlet-urile rulează că module în interiorul unui serviciu orientat cerere-răspuns (un serviciu implementează un protocol la nivel de aplicație, de exemplu FTP, HTTP, SMTP) pentru a-l extinde că funcționalitate. De exemplu, un serviciu HTTP răspunde unui client prin trimiterea documentului HTML cerut; un servlet care extinde capabilitățile serviciului HTTP poate genera dinamic un document HTML, că răspuns la un formular (form) completat de un client și, în același timp, să actualizeze o bază de date cu datele primite (asemănător cu un script CGI). Dacă este necesar, un servlet poate invoca alte servicii sau servlet-uri pentru a satisface o cerere.

1.2.5 Caracteristicile unui servlet

– portabilitatea – poate rula pe diverse platforme, fără a necesita o rescriere (independența de platformă este o caracteristică a limbajului Java);

– încărcarea dinamică – poate fi încărcat și invocat de pe discul local sau de la distanță (prin rețea);

– configurabilitatea – instalarea, pornirea/oprirea, specificarea parametrilor de start și a caracteristicilor unui servlet sunt realizate într-un mod simplu și sugestiv, prin intermediul unui sistem de administrare ce dispune de o interfață grafică;

– siguranța în funcționare – modelul de securitate și încapsulare protejează servlet-ul de atacuri, chiar și în momentul când este apelat la distanță;

– posibilitatea de înlănțuire – un servlet poate invoca unul sau mai multe servlet-uri într-o secvență;

– execuția dinamică – poate fi apelat direct din paginile HTML, utilizând tag-uri recunoscute de server;

– existența unui API standard – utilizează Servlet API, care este o extensie a API-ului standard Java; astfel, un servlet este independent de protocolul de rețea utilizat, de modul în care este încărcat sau de server-ul care-l rulează;

– ușurința în dezvoltare – mediul de dezvoltare JSDK pune la dispoziția programatorului instrumente ce facilitează scrierea de noi servlet-uri;

– persistența și configurarea "on-the-run" – pentru crearea de servlet-uri se poate utiliza tehnologia JavaBeans.

1.2.6 Arhitectura unui servlet

Orice servlet implementează interfața Servlet, fie direct, fie, cel mai adesea, extinzând o clasă care o implementează (de exemplu, HttpServlet). Când un servlet acceptă o conexiune din partea unui client, primește două obiecte: „ServletRequest” și „service()”, care încapsulează comunicația de la client la server și, respectiv, de la server înapoi la client.

Interfața „ServletRequest” permite accesul la o serie de informații ca: numele parametrilor trimiși de client, protocolul (schema) utilizat de client, numele (adresa) server-ului care a furnizat cererea și stream-ul de intrare, „ServletInputStream”, prin intermediul căruia servlet-ul primește date de la clienți.

Serviciile încarcă, rulează și, dacă este necesar, termină execuția servlet-urilor. Aceste etape reprezintă ciclul de viață al unui servlet și sunt controlate de trei metode principale.

Un servlet este activat prin invocarea metodei „init()”; această metodă este chemată o singură dată, cu excepția cazului în care servlet-ul este reîncărcat (aceasta este posibil doar după ce servlet-ul a fost mai întâi oprit); în această metodă se efectuează inițializările de care este nevoie pentru funcționarea servlet-ului. Dacă există calcule costisitoare care trebuie să se repete la fiecare cerere, este de preferat să se execute o singură dată la inițializare.

După ce a fost încărcat și inițializat, servlet-ul este capabil să răspundă cererilor, pe care le procesează cu metoda „service()”; fiecare cerere din partea unui client este tratată concurent, printr-un apel „service()”, într-un fir de execuție servlet separat.

Așadar, la un moment dat, pot exista mai multe metode „service()” în execuție; acestea pot utiliza date în comun (câmpuri globale, asociate clasei utilizând atributul static) dar accesul la ele trebuie realizat în sistem de excludere mutuală (folosind modelul „synchronized”) pentru păstrarea consistenței datelor. Cererile sunt procesate până în momentul în care execuția servlet-ului este terminată explicit de către server, prin apelul metodei „destroy()”.

1.2.7 Invocarea unui servlet

Odată ce servlet-ul este gata de execuție, se pune problema execuției efective, care poate fi soluționată folosind un server cu suport Java (de exemplu „Java Web Server” de la Sun) sau, mai nou, cu „servletrunner” (utilitar inclus în distribuția JDK 1.2). Indiferent de varianta aleasă, un servlet poate fi invocat în următoarele moduri:

– Indirect, pentru generarea dinamică de fișiere HTML; se utilizează când un client cere un document gestionat de un servlet: server-ul primește cererea, caută în parametrii de configurare și, când descoperă că nu este vorba de un document static (aflat pe disc), ci de unul generat, trimite cererea către servlet-ul respectiv, care o execută. Tehnica este asemănătoare cu cea folosită de către server-ele web tradiționale pentru a invoca script-uri CGI;

– Direct, din directorul „servlets/”; un servlet aflat în directorul „servlets/” (relativ la directorul rădăcină al server-ului) poate fi invocat prin numele clasei (fără extensie), utilizând protocolul și portul corespunzător. De exemplu, pentru un servlet HTTP, apelul va fi de forma: Dacă se dorește transmiterea unor parametri inițiali, aceștia trebuie plasați într-un fișier cu numele servlet-ului și extensia .initArgs, utilizând sintaxa "nume=valoare". Când un servlet este recompilat în acest director, noua versiune este încărcată automat de către server;

– Indirect, utilizând filtre înlănțuite; pentru satisfacerea anumitor cereri, poate fi necesară invocarea mai multor servlet-uri (înlănțuite ordonat). Datele de la client sunt transmise că intrare primului servlet din lanț, iar ieșirea ultimului servlet este întoarsă clientului. Fiecare servlet din lanț are ieșirea redirectată către intrarea următorului;

– Indirect, printr-un tag SSI; orice fișier cu extensia .shtml va fi analizat sintactic de către server. Dacă un „tag” SSI este găsit, server-ul va rula servlet-ul corespunzător și va insera ieșirea generată de acesta în locul tag-ului.

– Indirect, folosind un "alias"; modul de apel în acest caz este același că în cazul direct, doar că locul unde se află servlet-ul poate fi diferit de cel unde rulează server-ul. Server-ul va transfera local clasa, o va instanția și apoi o va rula.

1.2.8 Servlet-uri HTTP

Deoarece majoritatea servlet-urilor sunt extensii ale unui server Web, care utilizează protocolul HTTP pentru a interacționa cu clienții, metoda cea mai uzuală folosită pentru dezvoltare este de a utiliza clasa specializată javax.servlet.HttpServlet. Un astfel de servlet poate suporta orice metodă HTTP (GET, POST, HEAD, etc.), poate redirecta o cerere către altă locație, poate trimite mesaje specifice protocolului, poate accesa parametrii trimiși prin formulare (forms) HTML (metoda HTTP, URL destinație al cererii).

Clasa „HttpServlet” implementează interfața Servlet prin extinderea clasei „GenericServlet”. Metoda „service()” oferă suport pentru standardul HTTP 1.1 prin trimiterea cererilor către metode specializate de tratare.

În mod implicit, un servlet scris prin extinderea clasei „HttpServlet” permite existența mai multor fire de execuție (threads) care execută concurent metoda „service()”. Dacă se dorește accesul exclusiv (cel mult o metodă service() se poate afla în execuție la un moment dat), servlet-ul trebuie să implementeze interfața „SingleThreadModel” (nu este necesară scrierea unor metode noi).

În funcție de interacțiunea HTTP conținută în cerere, metoda „service()” va invoca metoda corespunzătoare. Astfel, este suficient că un servlet să implementeze doar metoda sau metodele specifice destinației sale. Un obiect „HttpServletRequest” oferă acces la datele conținute în header-ul HTTP, că de exemplu la cookie-uri prezente în cerere și tipul operației.

Pentru obținerea argumentelor trimise de client, se pot utiliza mai multe metode, în funcție de operația HTTP solicitată:

– pentru orice tip de cerere, se poate folosi metoda „getParameterValues()”, care întoarce valoarea parametrului transmis că argument; lista de parametrii se află cu metoda „getParameterNames()”.

– pentru cererile de tip GET, metoda „getQueryString()” întoarce șirul cu datele trimise de client.

– pentru cererile HTTP POST, PUT și DELETE, există două variante de citire: dacă se așteaptă date de tip text, se folosește un obiect „BufferedReader” întors de metoda „getReader()”; altfel, pentru date binare, se utilizează un obiect „ServletInputStream” obținut printr-un apel al metodei „getInputStream()”.

În cadrul aceleiași cereri, poate fi folosită doar una dintre cele trei metode.

Pentru a răspunde clientului, obiectul „HttpServletResponse” furnizează două metode de transmitere a datelor în funcție de tipul lor: pentru text cu un „PrintWriter” obținut cu metoda „getWriter()” sau pentru date binare cu un „ServletOutputStream” întors de metoda „getOutputStream()”.

Înainte însă de a avea acces la „writer” sau „stream” trebuie configurat antetul documentului HTTP, specificând tipul și lungimea conținutului, precum și modul de codificare. Un răspuns este considerat terminat în momentul în care writer-ul sau stream-ul sunt închise.

1.2.9 Siguranța unui servlet

Servlet-urile fac că violările de acces la memorie și de tip imposibile, astfel că un servlet cu erori nu va afecta buna funcționare a server-ului.

Dacă pentru comunicație este folosit un protocol sigur (de exemplu SSL), identificarea clienților poate fi făcută cu precizie suficientă. O politică de securitate strictă controlează acțiunile servlet-urilor (politica este implementată cu ajutorul unui manager de securitate).

În mod implicit, toate servlet-urile încărcate din rețea sunt considerate nesigure și nu au dreptul de a executa anumite operații, că accesul la serviciile de rețea sau la fișierele locale. Doar servlet-urile interne și cele locale (controlate de administratorul server-ului) sunt considerate sigure și au acces nelimitat la resurse. Este totuși posibil, că un servlet care a fost semnat digital și apoi pus intr-o arhivă Java (JAR), să fie considerat sigur și să primească anumite privilegii din partea manager-ului de securitate.

1.2.10 Performantele unui servlet

Utilizând mecanismul de fire de execuție pus la dispoziție de către Java, un avantaj clar oferit de către servlet-uri constă din faptul că nu este necesară crearea unui nou proces pentru fiecare cerere. În cele mai multe cazuri, mai multe servlet-uri rulează în paralel în cadrul aceluiași proces server.

Datorită timpului scurt necesar comutării contextelor firelor de execuție, servlet-urile au performanțe superioare tehnologiei CGI (și chiar FastCGI), care necesită operații costisitoare (pornirea și comutarea proceselor, precum și inițializarea datelor pentru fiecare cerere). Servlet-urile pot procesa concurent mai multe cereri de îndată ce au fost inițializate (costul operației scade cu creșterea numărului de cereri).

Proiectarea și implementarea unui script CGI este adesea o acțiune destul de dificilă, în timp ce scrierea servlet-ului corespunzător este mult mai simplă (mai ales dacă se utilizează un mediu de proiectare adecvat).

Portabilitatea (limbajului Java) face că scrierea unui servlet să fie independentă de sistemul de operare folosit. Totodată, datorită scalabilității mașinii virtuale Java (JVM), un servlet va profita automat (fără a necesita cod suplimentar) de un număr mai mare de procesoare, îmbunătățindu-și considerabil timpul de răspuns.

1.3 Java Server Page (JSP)

1.3.1 Tehnologia Java Server Pages

Programarea CGI, apărută la începutul anului 1995, a transformat Web-ul dintr-un simplu sistem de aducere de fișiere într-o platformă în care diferitele organizații pot instala aplicații Web de mare utilitate. Înainte de introducerea CGI Web-ul era, de fapt, folosit pentru distribuirea de documente statice: text și imagini. Odată cu apariția acestuia, serverele de Web au putut fi conectate pentru a procesa informația în mod dinamic.

Alte soluții există, dar nu sunt ușor de folosit de către proiectantul obișnuit de pagini de Web. Tehnologia Java Servlets (specificată de API-ul Servlet de la Sun), de exemplu, permite folosirea limbajului Java că mediu de dezvoltare pentru crearea dinamică a paginilor Web, pentru execuția unor calcule în funcție de specificul aplicației sau pentru comunicarea cu surse de date de nivel „third-tier”. Aceste trei activități diferă foarte mult una de cealaltă și necesită diverse aptitudini de programare. Un servlet Java este un program ce rulează pe server (spre deosebire de applet-uri ce rulează în browser); el preia cereri HTTP de la browser-ul Web și generează dinamic un răspuns HTML (sau XML). Întreaga pagină Web trebuie astfel să fie conținută în servlet-ul Java. Dacă un Web designer sau un Web master dorește să schimbe imaginea paginii respective, ar trebui să editeze și să recompileze servlet-ul chiar dacă modul de funcționare ce stă în spatele acestuia rămâne același.

JavaServer Pages este tehnologia platformei Java pentru construirea de aplicații ce cuprind pagini de Web cu conținut dinamic precum HTML, DHTML, XHTML și XML. Sun a încercat să depășească limitările soluțiilor actuale pentru generarea de pagini cu conținut dinamic prin dezvoltarea unei tehnologii care:

– să funcționeze pe orice server Web sau de aplicații;

– să separe logica ce stă în spatele aplicației de aspectul paginii;

– să permită dezvoltare și testare rapidă;

– să simplifice procesul de dezvoltare de aplicații interactive Web.

Tehnologia JSP a fost creată să satisfacă aceste cerințe, fiind rezultatul unei cooperări la nivelul industriei software dintre producătorii de servere Web, servere de aplicații, sisteme tranzacționale și unelte de dezvoltare. Astfel, procesul dezvoltării de pagini de Web dinamice este accelerat de către JSP din următoarele considerente:

1.3.2 "Write once, run anywhere"

Tehnologia JSP este complet independentă de platformă atât în ceea ce privește paginile de Web dinamice, cât și serverele de Web și componentele acestora. Aceasta este explicabil deoarece limbajul de scripting pentru paginile JSP se bazează pe Java și în special pe modul de manipulare a obiectelor în acest limbaj.

1.3.3 Pagini JSP

O pagină JSP (*.jsp) este o pagină HTML sau XML ce cuprinde elemente adiționale (tag-uri, declarații, scriplet-uri) pe care motorul JSP le procesează și le elimină returnând o pagină standard HTML/XML. Ea corespunde unui document ce descrie procesarea unei cereri pentru a crea un răspuns.

O pagină JSP cuprinde în structura sa:

– cod HTML/XML standard – cod ce rămâne neinterpretat de motorul JSP;

– directive JSP – directive ce furnizează informații globale independente conceptual de o anumită cerere adresată paginii JSP;

– tag-uri JSP – spre deosebire de directive, tag-urile depind de fiecare cerere în parte adresată paginii JSP;

– elemente de scripting – acestea putând fi: declarații, scriplet-uri și expresii.

O pagină JSP poate crea și/sau accesa, la procesarea unei cereri, anumite obiecte Java. Obiectele astfel create pot deveni vizibile elementelor de scripting prin variabile în limbajul de scripting. Acestea vor conține, în timpul etapei de procesare a cererilor (vezi "Server Web cu funcționalitate JSP"), referințe către obiectul respectiv. Obiectele create au un atribut numit scope ce definește domeniul de vizibilitate al acestora: când există o referință la acest obiect și când aceasta va fi înlăturată. Valorile pe care le poate avea atributul scope sunt:

– page – accesibil doar în cadrul paginii în care a fost creat obiectul;

– request – accesibil din paginile ce procesează aceeași cerere în care a fost creat obiectul;

– session – accesibil din paginile ce se sunt în aceeași sesiune în care a fost creat obiectul;

– application – accesibil din paginile de procesează aceeași aplicație în care a fost creat obiectul. Toate referințele la acesta sunt eliberate când mediul runtime solicită ServletContext-ul

Numele atașat unui obiect este unic pe tot timpul execuției, toate domeniile de vizibilitate comportându-se că unul singur în cadrul unei secvențe cerere/ răspuns. Lipsa transmiterii variabilelor de stare prin HTTP este suplinită în mod automat de către motorul JSP prin cele două modalități cunoscute: cookie-uri, respectiv rescrierea URL-urilor. Cât timp sunt făcute cereri procesate de către motorul JSP, rescrierea URL-urilor este făcută în mod automat.

Orice pagină JSP conține o serie de obiecte create implicit :

– request – cererea ce a solicitat pagina respectivă;

– response – răspunsul la cerere;

– pageContext – contextul paginii curente;

– session – obiect de tip sesiune pentru clientul solicitat (valabil doar pentru HTTP);

– application – contextul servlet-ului generat (getServletConfig().get Context();

– config – obiect de tip ServletConfig pentru această pagină;

– page – instanță a clasei create pentru această pagină (pentru Java: this);

– exception – excepția declanșată anterior putând fi folosită doar în pagina de eroare invocată;

– config – obiect de tip JspWriter ce scrie în stream-ul de ieșire.

1.3.4 Tipuri de aplicații pentru JavaServer Pages

Un client Web poate face o cerere direct către un servlet Java, care generează conținutul dinamic, stochează rezultatul într-un Bean și invocă pagina JSP. Pagina JSP accesează conținutul dinamic din Bean și trimite răspunsul (HTML) browser-ului.

1.4 Serverul Tomcat

1.4.1 Generalități

Motorul de servleți Tomcat 3.1 poate fi integrat în spațiul de adrese al serverului web, comunicarea realizându-se în cadrul aceluiași proces prin intermediul JNI. Această abordare oferă performanțe superioare soluțiilor bazate pe procese comunicante.

Platforma Java 2 pentru întreprindere, J2EE, definește trei nivele pentru o aplicație:

– nivelul client,

– nivelul sistemului de stocare al informației

– nivelul intermediar, de implementarea căruia se ocupă efectiv J2EE. Din nivelul intermediar fac parte containerul EJB și containerul web. Containerul EJB încapsulează logica aplicației în componente reutilizabile (Enterprise Java Beans), iar containerul web încapsulează elementele de generare dinamică a paginilor HTML sau XML: servleții și paginile dinamice Java (JSP).

Tomcat este implementarea de referință a versiunii curente a specificațiilor pentru servleți și JSP. Tomcat 3.x implementează versiunea 2.2 a specificațiilor pentru servleți și versiunea 1.1 a specificațiilor JSP.

1.4.2 Modul de funcționare integrat în proces

Modul în care este implementată comunicare între Tomcat 3.1 și serverul web în cazul integrării în proces este cât se poate de direct. Totul se petrece pe un singur fir de execuție, care este chiar firul serverului web ce tratează cererea în cauză. Acesta apelează succesiv modulul de integrare cu Tomcat și apoi lucrătorul JNI. Pentru a putea apela metode ale obiectelor din mașina virtuală, acest fir de execuție este atașat temporar la mașina virtuală, devenind fir de execuție Java, supus rigorilor mașinii virtuale, inclusiv eventuala suspendare pentru colectarea memoriei disponibile. După atașarea la mașina virtuală, se apelează o metodă din conectorul JNI ce are că efect servirea cererii de către Tomcat, după care nu mai rămâne altceva de făcut decât să se detașeze firul de la mașina virtuală și să predea controlul înapoi serverului web.

Procesul de tratare efectivă a cererii se execută integral sub controlul Tomcat. Pentru aceasta este necesar că nucleul Tomcat să poată citi informații despre cerere, cum ar fi antetele cererii sau datele trimise de client în cazul unei cereri POST. Aceste operații se realizează apelând metodelor native ale gestionarului de conexiune, ceea ce conduce indirect la apelarea primitivelor oferite de serverul web. Metodele native ale gestionarul de conexiune sunt încărcate dintr-o bibliotecă nativă care este scrisă în C.

Se pune evident întrebarea dacă o soluție Java pură nu este preferabilă unei coexistențe în același proces a unei mașini virtuale cu codul nativ al unui server web clasic. Există mai multe motive care fac că integrarea unui motor de servleți să fie soluția mai avantajoasă. În primul rând, această formă de integrare oferă confortul de a utiliza serverul web favorit, ceea ce constituie un aspect important în majoritatea siturilor "în producție". Cu toate progresele realizate în domeniul mașinilor virtuale Java, codul nativ va consuma întotdeauna mai puțin timp de procesor pentru servirea paginilor statice, permițând un trafic mai ridicat cu același hardware.

În cazul Tomcat, modul în care face integrarea în codul actual are că principal avantaj simplitatea, nefiind însă din cale afară de eficient. Există câteva posibilități semnificative de reducere a overhead-ului, bazate pe evitarea atașării repetate a firelor de execuție la mașina virtuală.

Capitolul II

Baze de date. SQL. Serverul MySQL

2.1 Generalități

Pentru început trebuie știut ca termenul “dată” a fost folosit pentru prima dată în 1646 așa cum se precizează în WebsterDictionnary on-line și are următoarele sensuri:

– Informație faptică, rezultată în urma unor măsurători sau statistici, folosită că bază pentru raționamente, discuții sau calcule

– Informație percepută că un organ de simț sau preluată cu un dispozitiv specializat care include, pe lângă informații utile, informații inutile și/sau informații redundante, informație ce trebuie prelucrată pentru a dobândi un înțeles

– Informație în formă numerică ce poate fi transmisă digital sau procesată

Se observă că ultimele două definiții sunt cele mai apropiate de contextul în care vom folosi de aici înainte noțiunea de dată. Datele conțin, pe lângă informații utile, și informații inutile și redundante ce trebuie procesate pentru a deveni relevante, adică transformate de o manieră care să le facă utile și să poată fi structurate încât să permită obținerea informațiilor dorite. Datele trebuie culese, procesate, curățate și rafinate înainte de a putea fi utilizate, astfel încât să facă cât mai comod de extras informațiile care interesează.

Consultarea bazelor de date a devenit astăzi ceva trivial. Practic, de la apariția Internetului, în goana după informații, accesăm zilnic baze de date fără a realiza faptul că lucrăm cu o bază de date. În scopul introducerii aspectelor teoretice legate de bazele de date considerăm un sistem de baze de date că fiind un sistem computerizat de păstrarea a articolelor, sistem care cuprinde pe lângă datele propriu-zise și utilizatorii acestora, software și hardware.

Baza de date este un program care stochează sau regăsește și regăsește date intr-un mod eficient și simplu. Datele pot fi numere, șiruri de caractere sau obiecte mai complexe, cum ar fi bazele de date video.

O tabela este formată din rânduri și coloane. În terminologia bazelor de date, tabela este denumită fișier (fapt pentru care inițial au sisteme de gestiune a fișierelor „SGF” care realizau prelucrări asupra fișierelor independent de datele memorate în acestea), rândul este denumit înregistrare iar coloana câmp.

De asemenea una din caracteristicile bazelor de date este regăsirea datelor după conținutul acestora.

2.1.1 Tehnologia relațională

La început, procesarea informației a fost făcută de sisteme foarte mari și accesul la date a fost limitat la profesioniști IT. Pentru accesarea datelor erau necesare cunoștințe privind structura lor. Dacă se dorea un raport mai deosebit acesta nu putea fi generat în timp util de către oficiul de calcul.

Odată cu evoluția calculatoarelor personale au fost necesare modificări în aplicații pentru a deservi mai mulți clienți care doreau să genereze rapoarte și interogări proprii, așa a fost dezvoltată tehnologia relațională.

Tehnologia relațională a introdus limbajul SQL, limbaj care permite interogări pe o varietate de date. SQL afișează datele standardizat și simplu – o tabelă în două dimensiuni cu coloane și rânduri. Limbajul SQL a devenit baza multor unelte de dezvoltare și interogare de baze de date.

Acest model de date simplu a permis crearea unui limbaj elegant dar a venit cu multe lipsuri. Relațiile complexe între date nu se potrivesc în coloane și rânduri așa că datele sunt fragmentate pe mai multe tabele și trebuie legate. Din această cauză apar două probleme:

– interogările pot fi foarte dificil de scris pentru că trebuie legate mai multe tabele.

– necesarul tehnologic pentru a face față la interogări pe structuri de date foarte mari, este enorm.

SQL a devenit un standard pentru interogarea bazelor de date, dar trebuie înțeles că SQL nu este dependent de tehnologia relațională. Serverul Caché suportă SQL că și limbaj de interogare pe o tehnologie multidimensională mult mai puternică.

2.2 Baze de date

2.2.1 Sistem de Gestiune de Bazelor de Date

Un sistem de gestiune a bazelor de date (SGBD) este un mecanism al cărui principiu fundamental constă, la modul cel mai general, în așa zisa abstractizare a datelor stocate pe suport. Există trei nivele de abstractizare, corespunzând celor trei modele ale datelor: fizic, conceptual și logic.

– Modelul fizic (sau intern) privește datele așa cum sunt ele stocate pe suport și reprezintă nivelul zero al abstractizării;

– Modelul conceptual privește datele prin semnificația lor reală;

– Modelul logic (sau extern) privește datele prin prisma utilizatorului final.

Pentru o bază de date pot exista mai multe modele logice, în funcție de diversele categorii posibile de utilizatori finali; Mecanismele de "proiecție" între aceste nivele (mapping) asigură ceea ce se cheamă de obicei independența de date, adică stabilitatea aplicațiilor la modificări în modul fizic de stocare a datelor. Proiectarea aplicațiilor de baze de date implică din această perspectivă două etape inițiale extrem de importante: proiectarea logică și respectiv implementarea fizică a modelului de date. Modelul de date formează fundația întregului sistem de aplicații ce va exploata baza de date.

Proiectarea logică (logical design) de referă la stabilirea modelului conceptual al bazei de date care este în mare măsură independentă de SGBD-ul particular care va fi utilizat. Rezultatul acestei etape a proiectării este un document care va cuprinde definiția detaliată a structurilor de date ce vor fi implementate împreună cu toate elementele de semantică asociate acestor structuri.

Implementarea fizică (phisical implementation) constă în transpunerea pe SGBD-ul specific a modelului conceptual realizat în etapa anterioară. Concretizarea acestei etape constă într-un script realizat în limbajul de descriere a datelor (DDL – Data Description Language) utilizat de SGBD-ul ales. Rolul acestuia este să creeze și să inițializeze baza de date cu structurile corespunzătoare celor descrise în etapa anterioară. Acest script se mai numește schema bazei de date și va fi utilizat ca referință în proiectarea aplicațiilor propriu-zise. Deoarece ne referim cu precădere la arhitecturi de tip client/server, se poate face și o altfel de divizare a activității de proiectare a unei aplicații de baze de date: proiectarea la nivelul serverului și proiectarea la nivelul clienților. Aceste etape se referă în principal la serverul de date. Este important de subliniat faptul că o parte (pe cât posibil mai substanțială) din semantica datelor va fi implementată la nivelul serverului, în funcție de posibilitățile acestuia (reguli de validare, reguli de intergritate relațională, etc). Ceea ce nu poate fi implementat la acest nivel va rămâne în sarcina front-end-urilor.

În ultimii ani, sistemele de gestiune a bazelor de date (SGBD) s-au încetățenit ca mijloace principale de stocare a datelor pentru sisteme informatice de la aplicații de procesare a tranzacțiilor comerciale până la aplicații pentru PC-uri. În centrul majorității sistemelor informatice se află un SGBD. SGBD-urile și-au început dezvoltarea cu o decadă în urmă și continuă să evolueze și să se maturizeze, oferind funcții sofisticate de stocare, regăsire și distribuție a informației pentru sisteme de management al informației (MIS) și sisteme de procesare a datelor. Spre deosebire de sistemele de fișiere, sistemele de gestiune a bazelor de date oferă organizațiilor capacitatea de a integra și manipula ușor cantități imense de date operaționale. Evoluția motoarelor bazelor de date, a permis dezvoltarea unor noi tehnologii, cum ar fi client/server, data warehousing, analiza online a datelor, toate constituind nucleul sistemelor de management al informațiilor.

Datorită volumului mare de informații stocate a devenit imperios necesară dezvoltarea unor tehnici de stocare și regăsire a informațiilor într-un timp cât mai scurt. Fiecare mediu are caracteristicile sale de stocare, și deci de regăsire a informațiilor, neexistând o tehnică generală care să poată fi aplicată pentru orice SGBD.

2.2.2 Concepte generale în optimizarea bazelor de date

Optimizarea unei baze de date presupune două nivele distincte de ameliorare a performanței: nivelul aplicației și nivelul bazei de date. Acestea reprezintă zone de expertiză diferite și de multe ori sunt manipulate de oameni diferiți. Administratorul bazei de date ar trebui să aibă cel puțin o privire de ansamblu asupra importanței și tipurilor de optimizare, în cazul în care nu este direct implicat în procesul de îmbunătățire a performanțelor bazei de date.

La baza tuturor se află sistemul de operare, care guvernează funcționalitatea fizică, cum ar fi modul de acces la discurile fizice. Pe următorul nivel se află SGBD-ul, care interacționează cu sistemul de operare pentru stocarea fizică a informației, în timp ce aplicațiile comunică cu SGBD-ul pentru a executa funcționalitatea dorită.

2.2.3 Optimizarea aplicațiilor

Optimizarea aplicațiilor se referă la modul în care interacționează cu baza de date diferitele aplicații – forme, rapoarte, etc. O aplicație este, de fapt, un program care lansează cereri către baza de date, cereri care sunt interpretate ca citiri și scrieri fizice din fișierele fizice de date. Optimizarea aplicațiilor înseamnă controlul frecvenței și a cantității de date cerute sau trimise de aplicații către baza de date.

2.3 SQL

SQL este un limbaj de nivel înalt care ascunde implementarea unei baze de date. De asemenea, SQL limbajul standard folosit pentru manipularea și regăsirea datelor în baze de date relaționale,el fiind non-procedural și nedeclarativ. Utilizând SQL, programul nu este dependent de anumit SGBD. Ideal ar fi să se facă trecerea de la un SGBD la altul fără schimbarea aplicației. în realitate, insa, fiecare implementare SQL a producătorilor de software este ușor diferit astfel incit trecerea de la un SGBD la altul necesita un anumit efort.

Prin SQL un programator sau un administrator de baze de date poate efectua trei operații principale: manipularea, definirea, administrarea; în cadrul acestora se pot face următoarele lucruri:

– să modifice structura unei baze de date;

– să schimbe valorile de configurare pentru securitatea sistemului;

– să adauge drepturi utilizatorilor asupra bazelor sau tabelelor;

– să interogheze o baza de date asupra unor informații;

– să actualizeze conținutul unei baze de date.

În mod curent exista trei metode de folosire a SQL intr-un program aplicativ:

-SQL încapsulat (EMBEDDED SQL);

– Interfața de nivel apel pentru SQL (CALL LEVEL INTERFACE);

– Apelul direct (DIRECT INVOCATION).

SQL încapsulat utilizează proceduri în cadrul programului. Ele pot fi apelate de programul aplicației și pot returna valori în program prin transmiterea parametrilor. SQL încapsulat utilizează instrucțiuni încapsulate în codul de program. Acest lucru necesita adesea utilizarea unui recompilator pentru procesarea instrucțiunilor SQL. A fost cea mai utilizata forma de SQL. El folosește SQL static, ceea ce rezulta că instrucțiunea SQL este compilata în cadrul aplicației și nu poate fi schimbata în timpul execuției programului.

Apelul direct este lăsat la alegerea persoanelor care implementează programul.

O integrare SQL poate fi o comanda pentru execuția uneia din următoarele acțiuni:

– să construiască sau să șteargă o baza de date;

– să insereze, să modifice sau să șteargă înregistrări;

– să caute în câteva tabele o anumita informație și să returneze rezultatele intr-o anumita ordine;

– să modifice securitatea informațiilor;

– poate fi o simpla întrebare a bazei de date.

Se va prezenta în continuare câteva instrucțiuni din SQL cu ajutorul cărora se poate manipula o baza de date:

SELECT <lista de selecții> FROM <lista de tabele> WHERE <condiții de căutare>

Cuvântul cheie FROM precizează lista de tabele în care se face căutarea, iar cuvântul cheie opțional WHERE precizează condițiile de căutare. De asemenea instrucțiunea SELECT accepta mai multe linii. Daca este nevoie de toate înregistrările din baza de date, se utilizează caracterul de înlocuire asterisc (*)

UPDATE <tabel> SET <coloana>=<expresie> WHERE <condiție de căutare>

Unde în loc de „tabel”, „coloana”, „expresie” se va indica numele tabelei, coloanei și expresia atribuita. Daca s-a optat pentru cuvântul cheie „WHERE”, trebuie indicate criteriile de căutare.

Lista de comenzi ale limbajului SQL poate continua, ținând cont de complexitatea acestuia, dar pentru aplicația noastră numai cele doua comenzi au fost folosite.

2.4 Serverul MySQL

Marea majoritate a aplicațiilor bazate pe Web utilizează informații extrase din baze de date, pe baza cărora sunt generate în mod dinamic pagini HTML care sunt trimise clienților. Deși în continuare se va prezenta serverul MySQL, majoritatea considerațiilor sunt în egală măsură aplicabile și altor SGBD-uri.

MySQL este un produs rapid, cu caracteristici foarte potrivite pentru multe dintre aplicațiile care folosesc suportul de baze de date pentru Web.

MySQL operează în baza unui model client/server. Orice mașină care dorește să proceseze interogări asupra unei baze de date MySQL trebuie să ruleze MySQL server (mysqld), care este responsabil de tot traficul de tip incoming/outgoing cu baza de date. Ca orice alt server, mysqld "ascultă" pe un port particular (3306) eventualele cereri de conexiune ale unui "client" – orice aplicație care trimite cereri către o bază de date via mysqld. Acest client poate fi un simplu script în Perl care – grație modulului DBI – poate trimite o cerere către baza de date prin intermediul serverului MySQL, sau chiar clientul "command-line" mysql. Clientul mysql este o interfață interactivă pentru trimiterea de comenzi către server.

Doritorii de mai mult control pot desigur alege varianta compilării din surse. În funcție de opțiunea aleasă pentru scrierea aplicațiilor care lucrează cu MySQL (în cazul nostru Perl) sunt necesare alte câteva module.

Conexiunea la baza de date este nevoie de driverul „org.gjt.mm.mysql.Driver” aflat în „java.sql”

2.4.1 Modelul de securitate

Modelul folosit de MySQL se bazează pe username / password, hostname și alte privilegii. Prin privilegii se înțeleg în cazul MySQL operațiunile ce vor fi permise asupra bazei / bazelor de date, tabelelor sau indecșilor, cum sunt de exemplu SELECT, INSERT, UPDATE, DELETE, CREATE, DROP.

2.4.2 Utilitatea serverului MySQL

Utilitatea publicării pe WWW din baze de date apare, printre altele, pentru companiile care au sedii, depozite sau puncte de lucru dispuse în diverse locații geografice distincte, unde accesul la Internet este totuși disponibil pe baza unui cont de dial-up. Aceste companii pot dori, de exemplu, că o bază de date centrală a firmei să fie accesibilă pe web angajaților săi, care să introducă și să extragă unele date aferente operațiunilor zilnice.

Raportarea sau introducerea datelor se poate face diferențiat, în funcție de privilegiile per utilizator, și într-o manieră sigură, împiedicând furtul de date confidențiale, dacă se aleg soluții de securizare potrivite.

Capitolul III

Proiectarea aplicațiilor de baze de date

Suportul pentru baze de date oferit de Java este completat și cu suport pentru ODBC. Există și o licență pentru DataGateway for Java, ce cuprinde drivere pentru toate serverele de baze de date de la principalele companii: Oracle, DB2, Sybase, MS SQL Server, Informix, InterBase, MS Access, FoxPro, Paradox și dBase. Pentru realizarea și testarea interogărilor SQL, sunt utilizate uneltele SQL Builder, ce generează pe cale grafică interogări SQL, pe care apoi le transpune în cod ANSI SQL-92, SQL Explorer, ce poate crea și organiza tabele și SQL Monitor, o unealtă pentru testarea și depanarea interogărilor, ce ne asigură de performanța și de corectitudinea interogărilor SQL, formulate manual sau cu ajutorul primelor două unelte.

3.1. Driverul JDBC

3.1.1 Conceptul de aplicație multi-tier

Conceptul acesta nu e nou, însă adevărata sa utilitate a devenit clară odată cu apariția aplicațiilor bazate pe Web. Acestea necesită o așa-numită arhitectură thin-client, care să suporte clienți bazați pe browser și încărcarea rapidă a appleturilor. Într-o abordare multi-tier, cea mai mare parte a lucrului efectuat de aplicație rezidă în componente server, nu în componente aflate pe mașina client (noțiunea de componentă e mai veche; vom discutat mai detaliat despre ea în continuare)

Într-o aplicație tradițională client/server, clientul conține partea de prezentare (afișarea folosind o interfață prietenoasă), lucrul efectuat de aplicație (calcule, algoritmi) și manipularea datelor (conectivitatea cu bazele de date). Acesta este ceea ce se numește un "client gras" (fat client), iar aplicațiile cu această structură se numesc aplicații cu două straturi (two-tier), straturi reprezentate de client și respectiv de server. Serverul este în general un RDBMS .

În opoziție, a apărut noțiunea de client subțire (thin client), anume aplicația client constă numai din partea de prezentare. Partea de lucru efectiv (business logic) și partea de acces la date sunt reprezentate de programe separate, aflate pe unul sau mai multe servere. Aceste servere fac acces la baze de date situate pe discuri locale sau în rețea. În acest caz, putem vorbi deci despre aplicații cu trei straturi (three-tier sau multi-tier)

Java reprezintă în momentul de față nu numai un simplu limbaj de programare ci însumează o serie de tehnologii ce pot fi folosite pentru a crea aplicații complexe structurate pe mai multe nivele și care să implice resurse variate. Una dintre aceste tehnologii oferite de JavaSoft (creatorul limbajului Java) este interfață API, JDBC și oferă suportul pentru conectarea unei aplicații Java la o baza de date.

Driverul JDBC este în cele mai multe cazuri o arhiva ".jar" care trebuie doar copiata și setata variabila CLASSPATH prin adăugarea caii către ea. Folosirea ODBC necesita că driverele să fie instalate manual pe fiecare mașină client.

JDBC este o interfață de programare a aplicațiilor pentru execuția de interogări SQL și este compus dintr-o serie de clase și interfețe scrise 100% în Java. JDBC oferă un standard pentru dezvoltarea de aplicații ce folosesc baze de date. Folosind JDBC se pot trimite foarte ușor interogări SQL către un sistem de gestiune al bazelor de date virtual în sensul că nu este necesara scrierea unui program Java care să acceseze o bază de date MySQL și a unui alt program pentru a accesa o bază de date Oracle. Se poate scrie un singur program Java folosind JDBC care se poată trimite interogări SQL către un anumit sistem de gestiune al bazei de date (SGBD).

Aceasta facilitează conectarea la o baza de date, executa instrucțiunile SQL și preia rezultatele. Un driver JDBC specific pentru o anumita baza de date este de fapt o serie de clase ce implementează interfețele din pachetul java.sql lucru ce duce la standardizarea driverelor JDBC acesta fiind construit în straturi, stratul cel mai de sus fiind aplicația Java.

Aplicațiile Java utilizează JDBC API pentru comunicarea cu JDBC Manager, care retransmite informațiile de la aplicația Java la driverul JDBC. Bineînțeles că produse software diferite de SGDB pot avea drivere diferite. Driverul convertește instrucțiunile SQL intr-un protocol de acces, specific unui anumit SGDB; dar, în ceea ce ne privește, interfața API este consecventa indiferent de driverele SGDB sau JDBC. Interfața JDBC API și JDBC Manager izolează aplicația de implementarea SGBD. în figura 3.1 se prezintă straturile care alcătuiesc un protocol JDBC.

Figura 3.1

Driverul JDBC conține la rândul lui un protocol de conexiune. Un astfel de protocol este și ODBC-ul , primind numele de la JDBC de sub-protocolul odbc.

După cum URL-urile indica resurse aflate pe internet, tot așa JDBC-ul poate, prin propria să sintaxa să indice o baza de date la care se dorește conexiunea. Sintaxa este foarte asemănătoare cu a unui URL, adică prima parte din acesta specifica prefixul de protocol. în cazul JDBC-ului, acesta îl definește pe jdbc că prefix de protocol.

jdbc:<subprotocol>:<subnume>

Un sub-protocol specifica modul în care un driver JDBC realizează conexiunea și comunicarea cu un anumit sistem de gestiune a bazelor de date. Sub protocolul utilizează un șir subnume pentru a se conecta la o anumita bază de date, unde sintaxa sub-numelui diferă în funcție de sub-protocolul specificat.

3.1.2 Pachetele și interfețele de programare a aplicațiilor:

– java.sql.DriverManager

– java.sql.Driver

– java.sql.Connection

– java.sql.Statement

– java.sql.ResultSet

– java.sql.Date

– java.sql.Time

– java.sql.Timestamp

– java.sql.Types

– java.sql.DataTruncation

3.2 Conectarea la o bază de date în Java

Natura persistentă a servlet-ilor îi face ideali pentru aplicații de baze de date în Web. Servleții pot comunica cu baze de date via JDBC. JDBC-ul oferă un mod uniform de conectare din Java la o mare varietate de baze de date într-un mod general, fără a ține cont de specificul fiecărei baze de date în parte.

Pentru a realiza conexiunea la o baza de date, se utilizează metoda getConnection definită de clasa java.sql.DriverManager. Metoda getConnection are că argumente un obiect URL și două șiruri de caractere. Cele două șiruri precizează numele de cont și parola de acces la baza de date. În mod normal utilizatorii au diferite niveluri de acces la o bază de date.

Stabilirea conexiunii se face un felul următor:

//se încărcă driverul MySQL

Class.forName("org.gjt.mm.mysql.Driver");

// se obține conexiunea la baza de date

Connection con = DriverManager.getConnection

("jdbc:mysql://localhost/epress?user=root");

Pentru a face o interogare în JDBC, trebuie mai întâi să construiți o instrucțiune SQL prin crearea unui obiect „Statement”. Java definește clasa „Statement” în cadrul pachetului „java.sql”. După crearea obiectului „Statement”, se executa șirul SQL prin apelarea metodei „executeQuery” din clasa „Statement”.

Pentru a efectua o operație în baza de date, transmite-ți un sir SQL la constructorul „executeQuery”, iar de reținut este faptul că acesta returnează un obiect „ResultSet”. După executarea unei interogări SQL, se prelucrează rezultatul și se obține conținutul obiectului „ResultSet”.

Acum pentru o mai buna înțelegere a modului în care se realizează o interogare a unei baze de date cu ajutorul JDBC-ului, trebuiesc a fi prezentate metodele getxxx, metode ce se găsesc în clasa „ResultSet” și anume:

Tabelul 3.1

Pentru a obține diferitele câmpuri din înregistrarea curenta, ele găsindu-se în obiectul „ResultSet”, se parcurge bucla acestuia și se apelează una dintre metodele getxxx pana când metoda „next” returnează „false”.

După obținerea rezultatelor, procesarea lor se face astfel:

while(rs.next()) {

int id = rs.getInt(1);

String name = rs.getString(2);

}

3.2.1 Conversia tipurilor de date SQL la tipurile Java

Metodele getxxx au fost prezentate mai sus, acestea efectuând conversia tipurilor de date SQL la tipurile Java, dar deoarece prin metodele respective se indica ce câmp să fie convertit, trebuie avut grija că nu cumva să se apeleze o metoda care nu poate converti un tip de date SQL.

O conversie eronata la apelarea metodei getxxx va avea loc că efect lansarea unei excepții „SQLException”. în continuare se va prezenta conversia câtorva tipuri SQL la tipurile Java recomandate de specificația JDBC:

Tabelul 3.2

3.2.2 Concluzii

În termeni simpli, un driver JDBC ne oferă trei facilitați în lucrul cu o baza de date și anume:

– Stabilește o conexiune cu sursa de date

– Trimite cererile la sursa de date

– Întoarce rezultatele la aplicația user

– Formatează erorile în coduri standard de eroare JDBC

Capitolul IV

Proiectarea bazei de date

La proiectarea bazelor de vizualizarea și verificarea din timpul conceperi programului s-a folosit un program numit MySQLFront. Acesta, că și driverul JDBC, se conectează la baza de date tot cu ajutorul MySQL-ului. Modelul de securitate este identic că cel al serverului căruia îi poartă numele, și anume se bazează pe username / password și hostname.

Trebuie menționat faptul că baza de date este creata, și momentan ea este folosită de către alt program numit „Stat de funcții” realizat că proiect de diploma de către un fost student al acestei facultății, acesteia adăugându-i-se câteva tabele, necesare scopului în care a fost făcut programul, și anume următoarele:

Tabela „Formații_grupe”

– conține informații referitoare la formațiile din unitatea de învățământ precum și legăturile dintre acestea.

Câmpurile acestei tabele sunt:

– An (Smallint 5) – anul din care face parte formația

– Specializarea (Longtext) – specializările specifice aferente fiecărui an

– Formatia (Longtext) – un simbol utilizat pentru a reprezenta formația.

Valorile acestui câmp sunt de genul:

– s1,s2 – pentru reprezentarea serilor;

– gr1, gr2 …- pentru reprezentarea grupelor;

– sgrL1,sgrP1…- pentru reprezentarea semi-grupelor;

– Grupa (Longtext) – grupa din care face parte formația. în cazul seriilor sau folosit

notațiile: s1 – „I-C seria 1” pentru anul 1, specializarea StSC

s1 – „III-IA” pentru anul 3, specializarea IA…….

– Tip (Smallint 5) – câmp cu ajutorul căruia se memorează tipul unei ore

– înregistrările sunt 1 – curs, 2- seminar, 3 – laborator, 4 – proiect.

Tabela „Ziua”

– conține toate zilele din săptămână.

Câmpurile acestei tabele sunt:

– Id (Smallint 5) – identifica în mod unic fiecare zi. Este folosit pentru referirea acesteia în tabele;

– Ziua (Longtext) – numele zilei;

Tabela „Ora”

– conține toate orele dintr-o zi.

Câmpurile acestei tabele sunt:

– Ora (Longtext 5) – identifica în mod unic fiecare ora. Este folosit pentru referirea acesteia în alte tabele.

– Id (Smallint 5) – este de tipul „08”, „09”, ……, și este folosit că text pentru anumite controale ale aplicației.

Tabela „Săli”

– conține informațiile referitoare la sălile disponibile în care urmează să se desfășoare orele în unitatea de învățământ.

Câmpurile acestei tabele sunt:

– Tip (Longtext) – specifica dacă în sala dată se pot ține cursuri, laboratoare, seminarii sau proiecte;

– Sala (Longtext) – conține numele sălilor („IE101”)

– ContorSala (Smallint 3) – se contorizează sălile care au fost repartizate grupelor.

Dacă am presupune că într-o săptămâna în care zile de studiu sunt de luni până vineri (adică 5 zile ) și maximul de ore intr-o zi este de la 08 la ora 21, și ținând cont că între orele 14-15 nu există activități școlare, rezulta maxim 60 de ore care pot fi ținute într-o sală pe săptămâna.

Ultimul câmp a fost adăugat tocmai în urma acestui considerent, acesta contorizând de câte ori o sală este folosita pe săptămâna. În cazul în care se atinge pragul de 60 ore, sala devine indisponibila.

Tabela „Admin”

Tabela de față a fost creată deoarece o parte a programului este disponibilă numai profesorului care se ocupa cu realizarea programului, iar oricine altcineva nu are dreptul de a o utiliza.

Aceasta are câmpurile următoare:

– Utilizator (Longtext) – în acest câmp se reține numele celui care are drepturi de administrator asupra programului.

– Parola (Longtext) – în acest câmp se reține parola, care împreuna cu „Utilizator”- ul formează un grup de date folosit pentru a accesa partea administrativă a programului.

Celelalte tabele folosite, cum am mai spus, sunt deja create dar totuși uneia dintre ele i sau mai adăugat unele câmpuri. De menționat este faptul că aceste adăugări nu afectează cu nimic funcționalitatea programului pentru care a fost creată inițial, și cu atât mai puțin tabela, câmpurile respective fiind adăugate la sfârșitul acesteia.

În continuare am decis să prezint această tabelă, dar din aceasta numai câmpurile care au fost adăugate:

Tabela „Catalog_ore”

Este cea mai mare dintre tabele și conține informații legate de materia, anul, secția,

etc. aferente anilor de studiu. Ea este și cea mai folosita în interogările SQL. Câmpurile folosite în proiect sunt:

– Materia (Longtext) – câmp din baza de date în care se găsește numele tuturor materiilor care sunt predate de profesorii Catedrei de Calculatoare. De specificat este faptul că aici nu se găsesc toate materiile care se studiază în cadrul acestei catedre. Materiile de genul „Matematica”, „ Management”, materiile din modulul pedagogic, etc., nu exista deoarece acestea sunt predate de profesori care nu aparțin Catedrei de Calculatoare, ci altor catedre. Acesta este un inconvenient în cazul în care se face afișarea orarului în funcție de an, specialitate, grupa, deoarece orarul afișat nu o să fie complet.

– An (Smallint) – se reține anul de studiu;

– Sectia (Longtext) – specifică specializările catedrei de calculatoare;

– Semestrul (Smallint) – specifica semestrele; în cazul de față semestrul 1 și 2;

– Tip (Smallint) – conține tipul orei, și anume : 1-curs, 2 – seminar, 3 – laborator, 4 – proiect;

– Curs (Smallint) – conține numărul de ore de curs;

– Seminar (Smallint) – conține numărul de ore de seminar;

– Laborator (Smallint) – conține numărul de ore de laborator;

– Proiect (Smallint) – conține numărul de ore de proiect;

– Formatia (Smallint) – conține formația de studiu;

Următoarele câmpuri sunt cele de care a mai fost nevoie, și anume:

– Sala_p (Longtext) – valorile acestui câmp sunt modificabile din program și semnifică numerele sălilor în care au loc activitățile didactice din săptămâna pară;

– Sala_i (Longtext) – valorile acestui câmp sunt modificabile din program și reține sala

în care au loc activitățile didactice din săptămâna pară;

– Ora_startp (Longtext) – valorile acestui câmp sunt modificabile din program și

rețin ora de start a activităților didactice în săptămâna pară.

– Ora_starti (Longtext) – valorile acestui câmp sunt modificabile din program și

rețin ora de start a activităților didactice în săptămâna impară.

– Ziua (Longtext) –se reține ziua;

Celelalte doua tabele sunt aceleași cu cele care sunt folosite de programul mai sus menționat, câmpurile la care face referire programul acestui proiect fiind:

Tabela „Formații_studiu”

– din aceasta tabela, câmpurile care au folosit programului sunt:

– An (Smallint) – conține anul de studiu;

– Sectia (Longtext) – conține secțiile din cadrul catedrei de calculatoare;

De asemenea tabela mai conține informații despre numărul de serii, grupe, semigrupe și altele.

Tabela „Personal”

– conține informațiile referitoare la profesorii care a țin ore în unitatea de învățământ.

– Legom (Float) – se identifica în mod unic fiecare profesor. Este folosit pentru referirea profesorului în alte tabele;

– Nume (Longtext) – conține numele profesorului;

De-asemenea, celelalte câmpuri nu sunt folositoare aplicației proiectate.

Capitolul V

Descrierea aplicației

De la început trebuie spus că programul pe cale l-am implementat este destinat mai ales profesorilor în scopul ușurării modalității, pană acum laborioase, de a-și consulta orarul, dar și studenților specializării „Calculatoare și Automatizări” din cadrul Facultății de Inginerie, care vor beneficia de o cale de acces mai ușoara la programul activităților școlare, față de orarul existent în prezent.

Mare parte din aceste facilități se bazează pe prezumția mea că folosirea Internetului ca suport pentru accesarea acestui program își dovedește eficiența prin rapiditatea accesării și eliminarea oricăror probleme tehnice în legătura cu orarul respectiv.

Ușurința și rapiditatea programului pe care l-am implementat au fost condițiile de bază pe care le-am urmărit, și vor putea fi puse în aplicare de pe orice calculator care beneficiază de o conexiune la Internet și folosind orice browser existent la ora actuala.

Scopul principal al acestei aplicații este acela de a crea o modalitate vizuală de editare și vizualizare a orarului.

Pentru accesarea orarului trebuie vizitat site-ul universității „Lucian Blaga” din Sibiu pe adresa „http://vectra.ulbsibiu.ro:9000\index.htm” . În cadrul acestui site se va utiliza link-ul „Facultăți” pentru a intra în următoarea pagina care va afișa lista cu facultățile aferente universității, printre care se afla și un link către „Catedra de Calculatoare și Automatizări”.

În următoarea fereastra în cadrul rubricii „Studenți” apare un link către „Orar”, care odată activat, permite vizualizarea orarului prin intermediul aplicației dezvoltate în proiect.

Pentru toate cele de mai sus este nevoie de un calculator pe care să fie instalat un browser de Internet. La conceperea acestui program am folosit Internet Explorer sau Opera.

5.1 Descrierea programului

După accesarea ultimului link către orar, pagina încărcată este cea în care se va putea alege între editarea sălilor aferente grupelor și semigrupelor specializărilor catedrei ce calculatoare, facilitate după cum am mai spus accesibila numai profesorului responsabil cu generarea orarului, precum și posibilitatea vizualizării acestuia.

5.1.1 Partea de editare

Pentru a intra în pagina de introducere a sălilor, se cere introducerea unui „utilizator” și a unei „parole”, personalizate pentru profesorul responsabil. După introducerea corecta a acestora, pagina următoare care apare v-a afișa inițial unei căsuțe de selectare a semestrului. După ce s-a făcut alegerea semestrului, aceasta va determina apariția unei alte căsuțe de selectare pentru „specializare”. La rândul ei selectarea „specializării” va fi urmata de apariția căsuței de selectare a „anilor” aferenți semestrului și specializării alese. După selectarea anului va apărea o căsuța în care sunt afișate materiile, în funcție de semestrul, specializarea și anul selectat anterior. Următoarea și ultima căsuța care va apărea este cea în care trebuie selectat tipul orei, opțiunile posibile fiind „curs”, „seminar”, „laborator” și „proiect”.

La finalul acestei succesiuni de alegeri, rezultatul va fi afișarea unui tabel.

Tabelul este format din următoarele câmpuri:

– Formatia – afișează grupele și semigrupele în funcție de specializarea și anul ales mai înainte; valorile acestui câmp nu sunt modificabile;

– Nr.Ore – afișează numărul de ore pe care grupa sau semigrupa respectiva il au de efectuat; valorile acestui câmp nu sunt modificabile;

– Ziua – afișează căsuțe de selecție în care administratorul va alege ziua în care se va avea loc activitățile;

unele grupe pot avea „proiecte” doar o singura ora pe săptămâna. Din acest considerent s-a ales ca acea ora de proiect sa fie comasata cu ora din săptămâna viitoare, iar proiectul sa se țină odată la două săptămâni. Din acest motiv si nu numai au apărut săptămânile pare si impare.

– Sala săptămâna impara – afișează căsuțe de selecție în care administratorul va alege sala în care se va avea loc activitățile școlare în săptămâna impara;

– Ora săptămâna impara – afișează căsuțe de selecție în care administratorul va alege ora de începere a activităților școlare;

– Sala săptămâna para – afișează căsuțe de selecție în care administratorul va alege sala în care se va avea loc activitățile școlare în săptămâna para;

– Ora săptămâna para – afișează căsuțe de selecție în care administratorul va alege ora de începere a activităților școlare;

Cum greșeala este omeneasca, și exista posibilitatea alegerii greșite a unei opțiuni din multitudinea de căsuțe de selecție, exista un buton numit „Reinițializare” care oferă posibilitatea reluării ciclului de selectări.

După ce toate datele au fost introduse corect și verificate, butonul “Salvare” din pagina oferă posibilitatea actualizării bazei de date „catalog_ore”.

5.1.2 Partea de afișare

Odată ce bazele de date au fost actualizate, și în acestea se găsesc toate informațiile necesare, orarul devine accesibil deopotrivă profesorilor și studenților.

Programul oferă posibilitatea afișării orarului după trei criterii:

În funcție de profesor

După apăsarea butonului „Intrare” pagina care se va încărca, conține opțiunile de selectare pentru profesor și semestru strict necesare afișării orarului. Odată ce să ales profesorul și semestrul dorit apăsarea butonului „Afișează orar” va afișa orarul propriu-zis în funcție de cele doua criterii.

În funcție de săli

Apăsarea butonului „Intrare” al acestei opțiuni, va încărca pagina ce conține posibilitatea de selectare a sălii. După ce s-a optat pentru o anumită sală, se apasă butonul „Afișează orar” care va afișa orele ce se vor desfășura în această pe perioada pe două săptămâni, pară și impara, începând cu cea impară.

În funcție de specialitate, an, grupa

Apăsarea butonului „Intrare” al acestei opțiuni, va încărca pagina ce conține posibilitatea de selectare a semestrului, specializării, anului și grupei dorite. După ce s-au făcut alegerile dorite, se apăsa butonul „Afișează orar” care va determina afișarea orarului în funcție de acestea.

5.1.3 Concluzii

De menționat este faptul că în cadrul părții de editare și a celei de afișare a orarului în funcție de specialitate, an și grupa, opțiunile din căsuțele de selectare apar în mod dinamic, în funcție de alegerile precedente. Exemplificativ am putea menționa că odată ce am selectat semestrul „2”, specializarea „C” (calculatoare), nu vom putea selecta anul „5”, deoarece activitățile didactice pentru anul cinci de studiu se termina odată cu terminarea sesiuni de examene din semestrul I.

Aceasta descriere sumara a proiectului are ca scop familiarizarea profesorilor și studenților cu acest program.

5.2 Implementarea programului

Pentru început în funcționarea programului avem nevoie de un server Web, în cazul de față am folosit serverul Tomcat-Apache (versiunea 4.0.1), server care va trebui să funcționeze pe toată durata rulării programului.

De asemenea mai este nevoie și de serverul de baze de date MySQL, care va comunica cu serverul Tomcat prin intermediul driverului JDBC. Accesul la acest server se face prin introducerea unei parole și a unui utilizator, conexiunea realizându-se pe portul 3306.

Pentru implementarea programului am folosit servleți în combinație cu JSP-uri, din motive proprii, și anume în primul rând deoarece sunt mai bine familiarizat din punct de vedere al programării în Java cu acestea, iar în al doilea rând deoarece astfel am avut posibilitatea ca în servleți să folosesc numai cod Java, iar în JSP-uri numai cod HTML. Aceasta tehnică folosită de mine ajuta la parcurgerea mai ușoara a codului servlet-ilor și a JSP-urilor folosite, fără a crea dificultăți în depanarea programului.

5.2.1 Servlet-urile

In continuare se va prezenta codul unuia dintre servleții si anume „materia_servlet” care se implementează, codul acestuia fiind in mare parte asemănător cu al celorlalți servleți.

Pentru rularea servletilor este necesar sa importam la început clase predefinite:

„import javax.servlet.*;

import javax.servlet.http.*;

import java.io.*;

import java.util.*;

import java.sql.*;”

Se definesc de asemenea și clase proprii care extind altele existente:

„public class materia_servlet extends HttpServlet {

private static final String CONTENT_TYPE = "text/html;

charset=windows-1250";”

După cere se inițializează variabilele globale:

„ArrayList mat=new ArrayList();”

Prima metoda folosită este „int()”:

„public void init() throws ServletException {

}”

Cu ajutorul clasei „HttpServlet” am definit metoda „doPost” pentru a răspunde cererilor client de tip POST. Aceste metode sunt apelate automat de către metoda service (care este apelată când o cerere client ajunge la server). Metoda service determină tipul cererii, apoi apelează metoda corespunzătoare.

Definirea metodei „doPost” sa realizat in felul următor:

„public void doPost(HttpServletRequest request, HttpServletResponse

response) throws ServletException, IOException {

response.setContentType(CONTENT_TYPE);

if(mat==null) mat=new ArrayList();

String an_selectat=request.getParameter("select3");

String sectia_selectat=request.getParameter("select2");

HttpSession session=request.getSession();

session.setAttribute("an_selectat",an_selectat);”

La orice apel al metodelor doPost, câte un obiect de tip „HttpServletRequest” și „HttpServletResponse” este primit ca parametru. Serverul Web care execută servletul creează aceste obiecte.

În prima fază am elaborat clasele ce vor lucra cu baza de date. Fiind vorba de MySQL am folosit un driver JDBC, prin care aplicația va accesa baza de date.

Principiul de lucru cu baza de date este următorul: la fiecare accesare a acesteia deschidem o conexiune care este menținută atâta timp cât facem interogări în bază. La terminarea interogărilor închidem conexiunea cu baza de date.

Pentru fiecare tabelă din baza de date am creat câte un obiect în care înmagazinăm informația din tabela respectivă (fiecare câmp din acea tabelă se va regăsi ca proprietate în acel obiect).

Conexiunea la baza de date se realizează în felul următor pe portul 3306 al serverului MySQL :

„Class.forName("org.gjt.mm.mysql.Driver");

Connection conexiune_la_baza_date = DriverManager.getConnection

("jdbc:mysql://localhost:3306/orar");

Statement st = conexiune_la_baza_date.createStatement();”

Odată ce conexiunea la serverul MySQL a fost realizată, majoritatea interogările făcute bazei de date au fost cu ajutorul lui ”SELECT”. În continuare voi prezenta o astfel de selectare, pe care am folosit-o în scopul aflării tipul orelor care exista pentru un semestru,specializare, an și materie selectate anterior:

„String select="SELECT DISTINCT materia from catalog_ore WHERE

semestrul="+sem+" AND sectia='"+sectia_selectat+"' AND

an="+an_selectat+" ORDER BY materia";

ResultSet rs=st.executeQuery(select);”

Pentru această operație în baza de date, se transmite un șir SQL la constructorul „executeQuery”, iar acesta returnează un obiect „ResultSet”. După executarea acestei interogări SQL, se prelucrează rezultatul și se obține conținutul obiectului „ResultSet” care în cazul nostru este „rs”.

Pentru a obține diferitele câmpuri din înregistrarea curenta, ele găsindu-se în obiectul „ResultSet”, se parcurge bucla acestuia („while” în cazul de față) și se apelează una dintre metodele getxxx, în cazul de față „getString” până când metoda „next” returnează „false”.

Altă interogare este „UPDATE” folosită în cazul scrierii în baza de date, a datelor din căsuțele de editare aflate în tabelul pentru introducerea zilelor, sălilor și orelor de începerea activităților școlare. Ea este apelata in cadrul servlet-ului ”salvare”:

„ sql = "UPDATE catalog_ore SET sala_p = '" + sala_para[i] +

"', sala_i = '" + sala_impara[i] +

"', ora_startp = '" + ora_para[i] +

"', ora_starti = '" + ora_impara[i] + "', ziua = '" +

zile[i] +

"'" + " WHERE (semestrul = " + semestrul + ") AND " +

"(sectia = '" + sectia_selectat + "') AND " +

"(an = " + an_selectat + ") AND " +

"(materia = '" + materia_selectata + "') AND " +

"(tip = " + ora_selectata + ") AND " +

"(formatia = '" + form[i] + "')"; ”

In principiu JSP-urile au fost create pentru a ușura realizarea designul paginilor web iar acestea au fost apelate în cadrul servlet-ilor cu ajutorul metodei „gotopage”, apel care s-a făcut în felul următor:

„gotopage("/profesor3.jsp",request,response);”

In continuare voi prezenta implementarea acestei metode:

„private void gotopage(String pagina,HttpServletRequest request,HttpServletResponse response)

throws IOException,ServletException{ RequestDispatcher rd=getServletContext().getRequestDispatcher(pagina);

rd.forward(request,response);}”

După obținerea rezultatelor, procesarea lor se face astfel:

while(rs.next()) {

String s=rs.getString(1);

mat.add(s);

}

Conectarea la MySQL, interogările făcute, bucla „while” și până la apelarea medodei „gotopage” au fost prinse într-un „try” și unul sau mai multe „catch”-uri, acestea tratând excepțiile ce pot apărea.

Excepțiile tratate sunt:

„try{ }

catch(ClassNotFoundException e){

}

catch(SQLException e){

System.out.println(e.getMessage());

}

catch(Exception orice ){

System.out.println(orice);

}

unde:

– „ClassNotFoundException” apare în cazul în care o aplicație încearcă să încarce o clasa, dar nu se găsește nici o referire la numele clasei respective.

– „SQLException” apare de exemplu în cazul unei conversii eronate la apelarea unei metodei getxxx.

– „Exception” în aceasta se prinde orice fel de excepție care poate apărea.

La final folosirea metodei „void destroy()” este apelată în momentul în care servletul este terminat de către serverul pe care se execută. În această metodă se elibereaza resursele folosite de servlet, cum ar fi fișiere deschise, conexiuni deschise la baze de date etc.

5.2.2 JSP-urile

Valorile obiectelor din cadrul servleti au fost trimise JSP-urilor cu ajutorul creat pe sesiunii curenta deschisa de metoda „doPost”. In continuare voi exemplifica cu servletul „materia_servlet” si cu JSP-ul „profesor3”.

– din servlet acestea au fost exportate astfel:

„session.setAttribute("an_selectat",an_selectat);

session.setAttribute("Materia_citita" ,mat);”

– iar in JSP au fost importate în felul următor:

„<%=session.getAttribute("an_selectat")%>

<%java.util.ArrayList materia=(java.util.ArrayList)

session.getAttribute("Materia_citita");>”

Odată ce au fost primite valorile, acestea pot fi folosite în JSP în scopurile dorite.

Se observa folosirea codului HTML si anume:

<%= > se foloseste pentru introducerea de cod Java.

Pentru casutele de selectare se foloseste codul urmator:

<select name="select3" size="1">

<option><%=session.getAttribute("an_selectat")%></option>

</select>

5.2.3 Fisierul web.xml

Ultimul pas pe care l-am făcut în atingerea scopului dorit este, și ca aplicația să poată rula pe Internet, este editarea unui fișier web.xml, prin care serverul Tomcat știe care servlete trebuiesc acceptate. Acesta este în principiu un fișier în care este scris cod xml, foarte asemănător cu cel html. In continuare voi prezenta formatul fișierului web.xml, folosit in cadrul acestui proiect, aferent servlet-ului „materia_servlet”:

„<web-app>

<servlet>

<servlet-name>

materia_servlet

</servlet-name>

<servlet-class>

materia_servlet

</servlet-class>

</servlet>”

„<servlet> </servlet>”- indica numele servletului si clasa definita de acesta.

<servlet-mapping>

<servlet-name>

materia_servlet

</servlet-name>

<url-pattern>

/materia_servlet

</url-pattern>

</servlet-mapping>

</web-app>”

„<servlet-mapping> <\ servlet-mapping>”- arata unde se afla servletul, conține numele si calea acestuia.

5.2.4 Concluzii

In urma compilării servlet-ilor și după editarea fișierului web.xml, ce mai rămâne de făcut este verificarea ca serverul MySQL sa fie pornit, pentru a avea acces la baza de date si că, conexiunea la Internet este încă active.

Concluzii

De-a lungul acestui proiect am încercat (si reușit, zic eu) sa realizez un program fiabil care sa ajute studenții si profesorii in accesarea mai ușoara informaților cu privire la orarul zilnic al Catedrei de Calculatoare din cadrul Facultății de Inginerie.

Deocamdată se afișează numai orarul Catedrei de Calculatoare, fapt pentru care materii de genul „Matematica”, „ Management”, materiile din modulul pedagogic, etc., nu exista deoarece acestea sunt predate de profesori care nu aparțin acesteia , ci altor catedre.

Suportul tehnologiei Internet l-am folosit de asemenea si pentru a obține facilitatea de introducere a sălile, cea ce face munca profesorului responsabil cu orarul mult mai ușoara, prin faptul ca nu va mai fi condiționat de locația programului respectiv, acum modificările putând fi făcute de oriunde exista un calculator conectat la Internet.

Cu toate ca programului i se mai pot aduce îmbunătățiri, sunt convins ca așa cum este în stadiul actual, va fi privit ca un ajutor bine venit celor care-l vor utiliza.

Ca dezvoltări ulterioare ar fi necesară introducerea în baza de date și a datelor referitoare la celelalte materii și profesori, care nu apar în momentul de față, pentru ca orarul afișat să fie complet.

Unele verificări în cazul introducerii sălilor precum și crearea unui contor pentru sălile introduse, ar fi de asemenea o dezvoltare ulterioara.

Având in vedere ca este realizat programele care realizează crearea și afișarea orarului, s-ar putea încerca o generare a acestuia.

Anexe

SERVLET-ul „materia-servlet”:

import javax.servlet.*;

import javax.servlet.http.*;

import java.io.*;

import java.util.*;

import java.sql.*;

public class materia_servlet extends HttpServlet {

private static final String CONTENT_TYPE = "text/html; charset=windows-1250";

//Initialize global variables

ArrayList mat=new ArrayList();

public void init() throws ServletException {

}

//Process the HTTP Post request

public void doPost(HttpServletRequest request, HttpServletResponse

response) throws ServletException, IOException {

response.setContentType(CONTENT_TYPE);

if(mat==null) mat=new ArrayList();

String an_selectat=request.getParameter("select3");

String sectia_selectat=request.getParameter("select2");

HttpSession session=request.getSession();

session.setAttribute("an_selectat",an_selectat);

try{

Class.forName("org.gjt.mm.mysql.Driver");

String sem=(String)session.getAttribute("Sectia");

Connection conexiune_la_baza_date=DriverManager.getConnection(

"jdbc:mysql://localhost:3306/orar");

Statement st=conexiune_la_baza_date.createStatement();

String select="SELECT DISTINCT materia from catalog_ore WHERE

semestrul="+sem+" AND sectia='"+sectia_selectat+"' AND

an="+an_selectat+" ORDER BY materia";

ResultSet rs=st.executeQuery(select);

while(rs.next()) {

String s=rs.getString(1);

mat.add(s);

}

session.setAttribute("Materia_citita" ,mat);

mat=null;

gotopage("/profesor3.jsp",request,response);

} catch(ClassNotFoundException e){

}

catch(SQLException e){

System.out.println(e.getMessage());

}

catch(Exception orice ){

System.out.println(orice);

}

}

//Clean up resources

public void destroy() {

}

private void gotopage(String pagina,HttpServletRequest request,HttpServletResponse response)

throws IOException,ServletException{

RequestDispatcher rd=getServletContext().getRequestDispatcher(pagina);

rd.forward(request,response);

}

}

JS-ul „profesor3.jsp”:

<html>

<head>

<script> function doMat(form) {form2.submit(); } </script>

<script> function ver() {return true; } </script>

</head>

<body>

<form name="form1" method="post" action="Profesor">

<div align="center">Semestrul

<select name="select" size="1">

<option><%=session.getAttribute("sem_selectat")%></option>

</select>

&nbsp; &nbsp; &nbsp;

<input type="submit" name="reinitializare" value="Reinitializare" >

</div>

</form>

<form name="form2" method="post" action="tip_servlet" onSubmit="return ver();">

<p>Specializarea

<select name="select2" size="1">

<option><%=session.getAttribute("sectia_selectat2")%></option>

</select>

&nbsp; &nbsp; &nbsp; Anul

<select name="select3" size="1">

<option><%=session.getAttribute("an_selectat")%></option>

</select>

&nbsp; &nbsp; &nbsp; Materia

<select name="select4" size="1" onChange="doMat();">

<option>Alegeti</option>

<%java.util.ArrayList materia=(java.util.ArrayList) session.getAttribute("Materia_citita");

for(int i=0;i<materia.size();i++){

try{%>

<option value="<%=(String)materia.get(i)%>"><%=(String)materia.get(i)%></option>

<%}

catch(Exception e)

{

System.out.println(e);

}

}%>

</select>

</p>

</form>

</body>

</html>

Bibliografie

[1] NORTON P., STANEK W. – Ghid de programare în Java, Editura Teora, București, 1997.

[2] BLOCH J.‚ – Java ghid practic pentru programatorii avansați,

Editura Teora, 2002.

[3] MARK C., STEVEN W., ANTHONY F. – Java 1001 secrete pentru

programatori, Editura Teora, 2001.

[4] LEMAY L., CADENHEAD R. – Java 2, Editura Teora, București,

2000.

[5] DuBOIS P. – MySQL, Editura Teora, București, 2001

[6] MOISIL I. – Baze de date, Sibiu, 2000.

[7] http://stil.virtualave.net/java.htm

[8] http://www.bluedog.ro/it_channel/article

[9] http://www.netreport.ro/pcrep87/05.shtml

[10] http://www.netreport.ro/pcrep94/051.shtml

[11] http://www.netreport.ro/pcrep73/023.htm

[12] http://www.netreport.ro/pcrep69/051.htm

[13] http://www.java.sun.com