[An]

Sinteza

[SUBTITLU DOCUMENT]
WWW.REGIELIVE.RO
Cuprins
INTRODUCERE..........................................................................................................................................2
1. NOŢIUNI GENERALE DESPRE PROGRAMAREA ÎN INTERNET............................................2
1.1 Despre Internet şi WWW...............................................................................................................2
1.1.1 Clienţi Web................................................................................................................................3
1.1.2 Servere Web...............................................................................................................................4
1.1.3 Cookie........................................................................................................................................4
1.1.4 Despre HTML............................................................................................................................5
1.2 PROTOCOLUL HTTP........................................................................................................................6
1.3 GENERAREA DINAMICĂ A CONŢINUTULUI UNEI PAGINI.................................................8
2.1 APLICAŢII WEB ÎN PHP..................................................................................................................9
2.1.1 Elemente de PHP.......................................................................................................................9
2.1.2 Gestiunea unei aplicaţii Web în PHP........................................................................................9
2.1.3 Accesul componentelor software din PHP..............................................................................10
3.1 CERINŢELE SISTEMULUI............................................................................................................11
3.1.1 Descrierea cerinţelor...............................................................................................................11
3.1.2 Analiza cerinţelor....................................................................................................................11
3.2 Proiectarea sistemului................................................................................................................11
3.2.1 Proiectarea aplicaţiei de gestiune a materialelor...................................................................11
3.2.2 Proiectarea celor două aplicaţii Web......................................................................................11
3.2.3 Comunicarea între aplicaţii.....................................................................................................11
3.3 IMPLEMENTAREA APLICAŢIILOR...........................................................................................12
3.4 TESTAREA APLICAŢIILOR WEB...............................................................................................12
3.5 UTILIZAREA APLICAŢIILOR WEB............................................................................................12
Bibliografie.................................................................................................................................................13

1
 Introducere

Această lucrare prezintă câteva noţiuni generale despre tehnologiile server-side CGI,
PHP, ASP şi PHP dar şi despre modul în care acestea pot fi folosite pentru a interacţiona
cu sisteme existente în scopul de a le crea o interfaţă Web. În ultimul capitol este
prezentată analiza, proiectarea şi implementarea unei aplicaţii de gestiune a materialelor
căreia i s-a adăugat o interfaţă Web, pentru o parte din cazurile de utilizare, folosind
tehnologiile JSP şi ASP.NET.
Structura acestei lucrări este următoarea:
Primul capitol tratează câteva probleme generale legate de Internet cum ar URL-urile
(Uniform Resource Locators), paşii în comunicarea dintre un browser şi un server Web,
tipuri MIME (Multipurpose Internet Mail Extensions), plug-in-uri şi aplicaţii ajutătoare
pentru un browser, cookie-uri, limbajul HTML şi evoluţia acestuia, despre protocolul
HTTP şi alte protocoale cunoscute. Tot în primul capitol se tratează istoricul tehnologiilor
de generare a conţinutului dinamic într-o pagină Web. Sunt trecute în revistă atât
tehnologii client-side precum JavaScript şi Applet, dar şi tehnologiile server-side cum ar fi
CGI, Server-Side JavaScript, Servlet şi JSP, dar şi ISAPI, ASP, ASP.NET şi următoarea
versiune de ASP.NET denumită ASP.NET "Whidbey".
Al doilea capitol precizează câteva noţiuni fundamentale despre CGI, PHP, JSP şi ASP
şi felul în care acestea pot interacţiona cu limbaje de nivel înalt. Deoarece ultima versiune
a tehnologiei ASP este ASP.NET, am tratat această versiune în acest capitol.
Al treilea capitol prezintă modul de proiectare şi implementare al unei aplicaţii reale
pentru gestiune a stocurilor de materiale şi modul în care acesteia i s-a extins
funcţionalitatea astfel încât să suporte clienţi Web. Am realizat două aplicaţii Web, una în
Java unde am folosit tehnologia JSP şi alta în C# unde am folosit tehnologia ASP.NET.
Anexate sunt codul sursă Java folosit în paginile JSP ale primei aplicaţii Web, codul
sursă C# folosit în pagina ASP a celei de-a doua aplicaţie Web, şi o parte din codul sursă
Object Pascal al aplicaţiei de gestiune a stocurilor de materiale.

1. Noţiuni generale despre programarea în Internet

1.1 Despre Internet şi WWW

Programarea în Internet este un domeniu nou şi interesant în ceea ce priveşte

dezvoltarea aplicaţiilor. Aceasta ridică anumite probleme, unele dintre ele sunt legate de
implementarea protocoalelor standard, altele de faptul că se folosesc diverse platforme, dar
o bună parte dintre acestea sunt legate de extinderea aplicaţiilor stand-alone existente în
aplicaţii care să "ruleze într-un browser". Alte probleme sunt legate de performanţa şi
disponibilitatea site-urilor Web care primesc un număr impresionant de cereri şi de
gestionarea eficientă a datelor dinamice [Iye].
World Wide Web reprezintă un cadru ce permite accesarea documentelor legate între
ele, documente aflate pe milioane de calculatoare prin tot Internetul. Totul a început în
1989 la CERN (Centrul European de Cercetare Nucleară) unde echipe mari de fizicieni din
mai multe ţări trebuiau să colaboreze folosind o serie de documente ce se aflau în continuă
schimbare, printre acestea se aflau grafice, rapoarte şi fotografii. Prima propunere de
structură de documente legate între ele a venit din partea fizicianului Tim Barners-Lee în
martie 1989, iar primul prototip de browser a devenit operaţional 18 luni mai târziu şi a
fost prezentat la conferinţa HyperText ’91 din San Antonio, statul Texas . Acest browser
permitea vizualizarea documentelor în mod text. În februarie 1993 a fost lansat primul
2
browser cu capabilitaţi grafice pe nume Mosaic. În 1994 CERN şi MIT au pus bazele a
ceea ce azi se numeşte World Wide Web Consortium (W3C) o organizaţie al cărei scop
este dezvoltarea Web-ului, standardizarea protocoalelor, şi încurajarea interoperabilitaţii
între site-uri. De atunci câteva sute de universităţi şi companii au intrat în componenţa
acestei organizaţii .

1.1.1 Clienţi Web

Din punctul de vedere al unui utilizator, Web-ul este format dintr-o colecţie vastă de
documente sau pagini Web, orice pagină poate conţine legături spre alte documente aflate
oriunde în lume. Ideea ca o pagină să conţină referinţe spre o alta, ceea ce numim
hypertext, a apărut cu mult înaintea Internetului şi anume în 1945. Această idee aparţine
unui profesor de inginerie electrică de la MIT pe nume Vannevar Bush . Un browser este
un program ce poate afişa o pagină Web. Navigarea de la o pagină la alta se efectuează cu
ajutorul hyperlink-urilor, astfel este nevoie de o metodă de a numi şi identifica alte pagini.
Această problemă se rezolvă cu ajutorul URL-urilor (Uniform Resource Locators). Un
URL are trei părţi: numele protocolului, numele DNS al maşinii unde pe care se află
fişierul şi numele fişierului care conţine obiectul cerut (un document hypertext, o imagine,
un fişier audio, de animaţie sau video). Paşii în comunicarea dintre un browser şi un server
Web sunt următorii: browser-ul determină URL-ul, cere serverului de nume (DNS) adresa
internet (IP) a maşinii cu care va comunica, după ce obţine această adresă deschide o
conexiune TCP prin care trimite cererea pentru un anumit fişier, server-ul Web îi trimite
fişierul cerut apoi închide conexiunea iar în final browser-ul afişează conţinutul fişierului .
Pentru a putea afişa o pagină un browser trebuie să cunoască formatul acesteia. Acest lucru
este posibil datorită limbajului comun în care sunt scrise aceste pagini şi anume limbajul
HTML. Obiectele accesibile au mai multe formate, de exemplu o imagine poate fi GIF sau
JPEG, unele documente pot fi PDF-uri, altele pot fi fişiere Microsoft Word. O pagină
HTML poate să refere un fişier de orice tip pe care browser-ul nu este întotdeauna capabil
să îl interpreteze. Soluţia la această problemă o constituie faptul că serverele Web oferă
informaţii adiţionale despre un anumit fişier cum ar fi tipul MIME (Multipurpose Internet
Mail Extensions) al acestuia . Fişierele de tip text/html şi de alte tipuri care sunt direct
recunoscute de către browser (built-in types) şi sunt afişate direct, dar dacă tipul fişierului
nu este printre acestea atunci browser-ul foloseşte un tabel de tipuri MIME pentru a vedea
cum să trateze fişierul respectiv. Acest tabel asociază un tip MIME cu un program capabil
să afişeze resurse de tipul respectiv. Sunt două posibilităţi: plug-in-uri şi aplicaţii
ajutătoare.
Un plug-in este un modul care se instalează ca o extensie a browser-ului şi rulează în
interiorul acestuia. Are acces la pagina curentă ce conţine obiecte pe care ştie să le afişeze
corespunzător. După ce afişarea nu mai este necesară plug-in-ul este eliberat din memoria
browser-ului. Browser-ul oferă un set de proceduri pe care toate plug-in-urile trebuie să le
implementeze pentru a putea fi apelate de către acesta. Acest set de proceduri reprezintă
interfaţa plug-in-ului şi sunt specifice diferitelor tipuri de browsere. La rândul lui şi
browser-ul oferă anumite proceduri pe care plug-in-ul le poate apela, acestea fac parte din
interfaţa browser-ului şi se referă la alocare şi dealocare de memorie, afişarea unui mesaj
în status-bar-ul browser-ului, sau la aflarea diferitor parametri .
Alt mod de a extinde funcţionalitatea unui browser îl reprezintă aplicaţiile ajutătoare,
acestea sunt programe diferite care rulează separat de browser. Ele nu oferă o interfaţă
browser-ului şi de obicei sunt apelate pentru a afişa conţinutul unui fişier aflat într-un
anumit loc. Aplicaţii de acest gen sunt Adobe Acrobat Reader sau Microsoft Word, unele
au şi un plug-in a cărui scop este să invoce aplicaţia atunci când este cazul (de exemplu
Acrobat).

3
 Multe dintre aceste aplicaţii folosesc tipul MIME "application" iar ca subtipuri
folosesc ceva specific cum ar fi "pdf" sau "msword", astfel un URL poate să refere un
fişier PDF sau DOC fară nici o problemă pentru că aplicaţia corespunzătoare îi va afişa
corect conţinutul. Alte tipuri MIME ce pot fi folosite de către acest fel de aplicaţii sunt
"audio" sau "image", depinde de aplicaţie.
Browser-ele pot afişa şi fişiere locale, pentru care nu este disponibilă informaţia
referitoare la tipul MIME corespunzător (aceasta fiind oferită de server-ul Web) pentru a
face posibilă vizualizarea acestor pagini se verifică extensia fişierului. Astfel, de exemplu
Internet Explorer se bazează mai mult pe extensia fişierului decât pe tipul MIME
corespunzător. O problemă ar putea fi atunci când un fişier cu extensia "exe", un astfel de
fişier ar trebui executat direct, dar având în vedere că ar putea fi un virus, browser-ele au
opţiuni referitoare la executarea unor programe străine.

1.1.2 Servere Web

În ceea ce priveşte server-ul Web, acesta acceptă conexiunea deschisă de browser,

preia cererea din care obţine numele fişierului cerut, caută şi trimite acest fişier apoi
eliberează conexiunea. În acest caz o problemă o reprezintă faptul că trebuie făcut un acces
la disc de fiecare dată când se solicită un fişier, numărul de cereri pe care un server le poate
rezolva fiind limitat de acest lucru. Pentru a rezolva această problemă se foloseşte o
memorie cache în care sunt ţinute fişierele care sunt cel mai des cerute. Serverele Web
moderne sunt multithreading şi folosesc eventual mai multe discuri pentru a face faţă cu
succes numărului mare de cereri. Acestea fac mai mult decât să primească nume de fişiere
şi să trimită conţinutul acestora, un thread după ce primeşte o cerere poate efectua unele
dintre următoarele operaţii, depinde de tipul cererii: găseşte fişierul cerut (sau determină
acest fişier în sensul că sunt cereri care nu conţin un nume de fişier şi trebuie luat unul
implicit, se mai pune şi problema găsirii unui fişier tradus în limba clientului deoarece
browserele moderne includ şi acest lucru în cerere), autentifică clientul, verifică accesul
clientului respectiv la resursa cerută (în funcţie de identitatea şi locaţia clientului), verifică
dacă resursa cerută are anumite restricţii de securitate, verifică memoria cache apoi caută
eventual resursa pe disc, determină tipul MIME al acesteia pentru a putea fomula
răspunsul, mai poate efectua anumite statistici, apoi trimite răspunsul clientului după care
scrie în log-ul serverului.
Din cele prezentate până acum se poate observa o lipsă de stare, în sensul că un client
face o cerere pe care server-ul o onorează şi se închide conexiunea, astfel nici un fel de
informaţie despre clientul respectiv nu este păstrată. Pe vremea când Web-ul era folosit
doar pentru vizualizarea documentelor acest lucru nu era o problemă, în prezent anumite
site-uri Web cer autentificarea clienţilor şi eventual efectuarea unor plăţi pentru a putea
vizualiza conţinutul lor. Comerţul electronic este un alt exemplu din care reiese nevoia
păstrării la server a unor informaţii despre utilizatori.

1.1.3 Cookie

Compania Netscape a dezvoltat o tehnică controversată numită "cookie". Pe lângă

pagina cerută, server-ul poate trimite şi alte informaţii în care poate include un cookie ce
reprezintă un fişier de dimensiuni reduse (cel mult 4Kb) sau un şir de caractere.
Browserele păstrează aceste cookie-uri într-un director special pe discul clientului. Cookie-
urile sunt privite ca date şi chiar dacă conţin un program executabil acesta teoretic nu
ajunge să fie rulat, dar există posibilitatea ca cineva să exploateze un bug al browser-ului
astfel încât să provoace activarea unui virus aflat într-un cookie . Un cookie poate conţine
cinci proprităţi: numele domeniului – domain (de unde vine acest cookie), o cale – path (ce
reprezintă o cale în structura de directoare a server-ului şi specifică ce fişiere pot folosi
4
cookie-ul respectiv) un conţinut – content (cu înregistrări de forma nume = valoare), o dată
de valabilitate – expires (dacă această proprietate lipseşte, cookie-ul este sterş imediat ce
browser-ul părăseşte site-ul cu pricina, un astfel de cookie este non-persistent, iar dacă o
dată apare ca valoare a acestei proprietăţi atunci cookie-ul este persistent şi se păstrează
până la data specificată).Tot ca şi proprietate a unui cookie este nivelul de siguranţă –
secure (specifică browser-ului că poate returna acest cookie numai unui server securizat,
aceasta este folosită în comerţ electronic şi în sisteme bancare) . Înainte ca un browser să
trimită o cerere către un server, verifică directorul cu cookie-uri şi dacă găseşte cookie-uri
de la domeniul respectiv acestea sunt incluse în cerere.
Cookie-urile se pot folosi în multe scopuri dintre care unele sunt mai puţin etice având
în vedere că se poate determina prin ce pagini navighează un utilizator. O altă problemă
mai interesantă este că teoretic cookie-urile trebuie să se trimită tot la site-ul de unde
provin dar au fost exploatate bug-uri existente în browsere şi astfel puteau fi redirectate,
ceea ce este o problemă având în vedere informaţia conţinută (de exemplu numere de cărţi
de credit) . Oricum, browser-ele moderne conţin mecanisme prin care utilizatorul este
întrebat dacă doreşte sau nu acceptarea unor cookie-uri specificând domeniul de
provenienţă al acestora.

1.1.4 Despre HTML

HTML 1.0 permitea destul de multe lucruri dar în esenţă era unidirecţional în sensul că
utilizatorilor le era permis doar să trimită o cerere pentru o anumită pagină dar nu exista
posibilitatea trimiterii altor informaţii. Când acest lucru a devenit o necesitate s-au introdus
în HTML 2.0 aşa numitele Web forms ce conţin butoane, cutii de text şi alte controale utile
ce permit utilizatorului să introducă informaţii în scopul de a le trimite către server. O
importanţă mai mare o are butonul pentru "submit" (acceptare şi trimitere a informaţiei).
Când se apasă acest buton browser-ul colectează informaţia din forme şi o trimite la server
pentru ca acesta să o poată procesa.
Cu sau fară Web forms HTML-ul în sine nu oferă o structură paginilor Web în sensul
că formatarea unei pagini este amestecată cu conţinutul acesteia. Cum aplicaţiile pentru
comerţ electronic au devenit din ce în ce mai complexe a devenit necesară o mai bună
structurare a paginilor şi o separare a conţinutului acestora de formatare. De exemplu un
program ce caută pe Web cel mai mic preţ pentru un anumit produs trebuie să analizeze
multe pagini pentru a determina existenţa produsului precum şi preţul acestuia, dacă pagina
este formată cu HTML acest lucru este destul de dificil. W3C a dezvoltat un mecanism
prin care procesarea automată a paginilor Web să se realizeze mult mai uşor. Au fost
creeate două noi limbaje, mai întâi XML (eXtensible Markup Language) pentru a structura
conţinutul unei pagini Web şi XSL (eXtensible Style Language) pentru a formata
independent de conţinut. XML se foloseşte acum în mult mai multe scopuri decât pentru a
structura conţinutul unei pagini Web, unul dintre acestea este comunicarea între aplicaţii.
De exemplu SOAP (Simple Object Access Protocol) este o metodă prin care un client
construieşte o cerere în forma unui mesaj XML şi o trimite unui server folosind protocolul
HTTP, server-ul la rândul lui răspunde tot cu un mesaj XML, astfel aplicaţii de pe diferite
platforme pot comunica.
HTML evoluează pentru a face faţă noilor cerinţe. Urmaşul limbajului HTML 4.0 este
XHTML (eXtended HyperText Markup Language) şi nu se numeşte HTML 5.0 pentru că
în esenţă este HTML 4.0 reformulat în XML, astfel tag-uri precum <h1> nu au nici un
înţeles anume, pentru a obţine efectul pe care acesta îl are în HTML 4.0 este necesar un
fişier XSL. XHTML este un nou standard Web ce ar trebui folosit pentru o bună
portabilitate între platorme şi browsere.

5
1.2 Protocolul HTTP
Exemple de protocoale sunt: http (protocolul Web, HyperText Transfer Protocol), ftp
(File Transfer Protocol, folosit în Internet pentru a efectua transfer de fişiere), file (pentru
acces local al unor pagini Web), news (înaintea Internetului exista sistemul news
"USENET", există mai multe subiecte de discuţie; astfel se pot plasa şi citi articole
referitoare la câte un subiect, protocolul news foloseşte la vizualizarea acestor articole un
mod similar celui în care sunt vizualizate paginile Web), gopher (protocol folosit de
sistemul Gopher care obţinea informaţii similar Web-ului, doar că suportă doar text nu şi
imagini), mailto (oferă posibilitatea utilizatorilor să trimită mail-uri dintr-un browser) .
Protocolul HTTP (HyperText Transfer Protocol) este folosit pentru comunicarea între
un browser şi un server Web. Acesta specifică ce mesaje pot trimite clienţii către server şi
ce răspunsuri pot primi. Clientul de obicei deschide o conexiune TCP pe portul 80 al
maşinii pe care rulează serverul. Conform protocolului HTTP 1.0 după ce o conexiune se
deschidea, o singură cerere şi un singur răspuns se puteau trimite folosind această
conexiune, care apoi se închidea. Dacă pagina conţine doar text HTML această metodă era
suficientă dar în câţiva ani o pagină Web a ajuns să conţină un număr impresionant de
imagini, sunete şi alte resurse astfel încât a deschide o conexiune TCP pentru a primi o
resursă de dimensiuni reduse este prea costisitor. Acest lucru a dus la existenţa
conexiunilor persistente în HTTP 1.1, conexiuni care se pot folosi pentru a trimite şi primi
mai multe cereri şi răspunsuri . Protocolul a fost făcut mai general astfel o parte din
operaţiile suportate fac mai mult decât cererea unei pagini Web, tocmai aceste lucruri au
permis existenţa unor tehnologii ca SOAP de exemplu. Metodele pentru a efectua cereri
prin protocolul HTTP sunt:
Metodă Descriere
GET Cerere pentru a obţine o resursă
HEAD Cerere pentru a citi header-ul unei pagini Web
PUT Cerere pentru a stoca o resursă
POST Cerere de adăugare la o anumită resursă
DELET Ştergerea unei anumite resurse
E TRACE Afişarea cererii curente
CONNE Rezervat
CT OPTION Interogarea anumitor opţiuni
S
Metoda GET se foloseşte pentru a obţine o anumită resursă, majoritatea cererilor fiind
de tip GET. Metoda HEAD cere header-ul unei pagini fără pagina respectivă. Se foloseşte
pentru a obţine data şi ora ultimei modificări a unei pagini, pentru a colecta informaţie
pentru indexări sau pentru a testa validitatea unui URL. Metoda PUT este inversul metodei
GET: în loc să citească pagina aceasta o scrie. Prin această metodă se poate crea o colecţie
de pagini Web pe un anumit server la distanţă. Corpul cererii PUT conţine resursa
respectivă, dacă resursa este codificată cu MIME atunci liniile ce urmează după PUT
conţin content-type-ul resursei şi headere de autentificare. Metoda POST este într-un fel
asemănătoare metodei PUT numai că nu se înlocuieşte resursa ci se adaugă la ea într-un
mod mai general (de exemplu POST se face cu un mesaj într-un newsgroup). Metoda
DELETE şterge o anumită resursă, asemănător metodei PUT; autentificarea şi drepturile de
acces apar ca parametri. Această metodă nu garantează faptul că fişierul respectiv va fi
şters. Metoda TRACE este mai mult pentru debugging şi îi spune serverului să trimită
înapoi cererea. Metoda CONNECT este rezervată pentru utilizări viitoare. Metoda
OPTIONS permite interogarea serverului despre anumite proprietăţi ale sale sau ale unei
anumite resurse. Fiecare cerere primeşte un răspuns format dintr-o linie ce reprezintă starea
şi posibil alte informaţii (conţinutul unei pagini Web, sau doar o parte a acestuia). O linie

6
ce reprezintă starea conţine de fapt un număr format din trei cifre al cărui rol este de a
specifica succesul sau insuccesul operaţiei. Prima cifră a acestui număr este folosită pentru
a împărţi răspunsurile în cinci categorii majore. Codurile care încep cu 1 sunt rar folosite,
cele care încep cu 2 înseamnă că cererea s-a rezolvat cu succes şi conţinutul (dacă este
cazul) urmează a fi returnat, cele care încep cu 3 au rolul de a anunţa clientul să caute în
altă parte. Codurile care încep cu 4 reprezintă coduri de eroare, şi anume faptul că cererea
nu a putut fi rezolvată din cauza unei erori datorată clientului (pagină inexistentă sau cerere
invalidă). Codurile care încep cu 5 reprezintă erori interne ale serverului .

Cod Semnificaţie Exemple

1xx Informaţie 100 = serverul acceptă să rezolve
cererea clientului
2xx Succes 200 = cererea a fost rezolvată cu
succes; 204 = nu există conţinut
3xx Redirectare 301 = pagina a fost mutată
4xx Eroare la client 403 = acces interzis la pagină; 404
= pagină nu a fost găsită
5xx Eroare la server 500 = eroare internă a serverului;

O cerere poate conţine şi alte linii de text cu alte informaţii acestea se numesc
request headers. Aceste linii pot fi comparate cu parametrii unei proceduri, iar răspunsurile
pot avea şi ele response headers. Cele mai importante headere sunt descrise în tabelul
următor:

Header Tip Conţinut

User-Agent Cerere Informaţii despre browser şi
platformă
Accept Cerere Tipul de resurse cu care ştie lucra
clientul
Accept-Charset Cerere Tipuri de caractere pe care le poate
accepta un client
Accept-Encoding Cerere Codările paginii pe care le poate
accepta clientul
Accept-Language Cerere În ce limbă să fie documentele pe
care clientul le acceptă
Host Cerere Numele DNS al serverului
Authorization Cerere O listă a acreditărilor pe care le
deţine clientul
Cookie Cerere Trimite un cookie setat anterior la
server
Date Ambele Data şi ora la care a fost trimis
mesajul
Upgrade Ambele Protocolul la care emiţătorul
acestui mesaj vrea să treacă
Server Răspuns Informaţii despre server
Content-Encoding Răspuns Cum este codat conţinutul (ex.
gzip)
Content-Language Răspuns Limba folosită în conţinutul paginii
Content-Length Răspuns Lungimea resursei în octeţi
Content-Type Răspuns Tipul MIME al paginii
Last-Modified Răspuns Data şi ora la care a fost ultima
7
 dată modificată pagina
Location Răspuns Anunţă clientul să trimită cererea
în altă parte
Accept-Ranges Răspuns Anunţă faptul că serverul acceptă
cereri parţiale
Set-Cookie Răspuns Serverul doreşte salvarea unui
cookie

Header-ul User-Agent permite clientului să ofere serverului informaţii despre browser,

sistem de operare şi alte proprietăţi. Cele patru headere Accept anunţă serverul ce tipuri de
resurse poate prelucra clientul. Primul specifică tipurile MIME ce pot fi acceptate. Al
doilea oferă un character set (de exemplu Unicode-1-1), al treilea se ocupă de metode de
compresie (de exemplu gzip), al patrulea indică limba preferată de client (de exemplu
română sau engleză). Dacă serverul are mai multe versiuni ale paginilor atunci poate folosi
aceste informaţii pentru a oferi clientului ceea ce caută. Dacă nu poate rezolva cererea
atunci un mesaj de eroare corespunzător este returnat. Header-ul Authorization este necesar
pentru paginile care sunt protejate, în acest caz clientul va trebui să dovedească faptul că
are dreptul să vadă pagina cerută. Header-ul upgrade este folosit pentru a face mai uşoară
tranziţia spre o viitoare versiune a protocolului HTTP. Header-ele folosite de către server
care încep cu Content- oferă posibilitatea serverului să descrie proprietăţile paginii pe care
o trimite. Last-Modified joacă un rol important pentru gestionarea memoriei cache.
Header-ul Accept-Ranges anunţă că serverul acceptă cereri parţiale pentru o pagină (astfel
o pagină va fi trimisă în mai multe părţi mai mici) .

1.3 Generarea dinamică a conţinutului unei pagini

O bună parte a conţinutului paginilor Web actuale este generat la cerere mai degrabă
decât să fie stocat pe disc. Generarea acestui conţinut poate avea loc atât pe maşina client
cât şi pe maşina server. De exemplu atunci când un client trimite serverului date dintr-un
Web form, server-ul oferă aceste informaţii unui program specializat care ştie să proceseze
o asemenea cerere şi stie să creeze o pagină Web personalizată care este apoi este trimisă
clientului.
Metoda tradiţională pentru a procesa informaţii din Web forms şi a genera conţinutul
unei pagini Web este CGI (Common Gateway Interface). CGI este o interfaţă standard ce
permite serverelor Web să comunice cu aplicaţii care acceptă date (de exemplu din Web
forms) şi generează pagini HTML ca răspuns.

2. Aplicaţii Web

2.1 Aplicaţii Web în PHP

2.1.1 Elemente de PHP

PHP este o tehnologie interesantă care îmbină caracteristici dintre cele mai complexe
cu simplitatea în utilizare. Este un instrument pentru dezvoltarea aplicaţiilor Web. Este un
limbaj de scriptare server-side comod pentru începători. Este Open Source şi este proiectat
să ruleze pe mai multe sisteme de operare şi să coopereze cu mai multe tipuri de servere şi
baze de date şi servere Web. Tag-urile pentru cod PHP sunt <?php … ?> sau <? … ?>.
Interpretorul de PHP ignoră orice se află înafara acestor tag-uri.
Programele PHP execută trei categorii de operaţii elemetare: obţin date de la un
utilizator, execută prelucrări ale datelor, respectiv obţin accesul la date stocate la server şi
le manipulează; afişează date astfel încât un utilizator să le poată vizualiza [McC].
8
 Din punct de vedere sintactic PHP-ul este o mixtură din mai multe limbaje. Se poate
observa o influenţă puternică din C. Deşi sintaxa este asemănătoare cu cea a limbajului C
semantica diferă. PHP este interpretat şi astfel tipurile variabilelor nu sunt stricte. Când
este referită o variabilă tipul acesteia este determinat pe moment şi variabila este tratată ca
fiind ceea ce se cere în contextul dat. Codul PHP este evaluat şi executat pas cu pas astfel
nesiguranţa tipurilor unei variabile este o sursă foarte bogată de erori. Programele PHP
folosesc două categorii principale de date: numere şi şiruri de caractere. Numerele sunt
întregi sau cu virgulă flotantă. Pentru a defini o variabilă se foloseşte o notaţie de forma:
$nume_variabilă. Tipul unei variabile se determină în funcţie de contexul în care este
folosită. De exemplu unei variabile i se poate atribui succesiv un număr întreg apoi un
număr real fară să fie vreo problemă. Tablourile sunt asociative, astfel se pot indexa nu
numai după numere ci şi după şiruri de caractere. PHP-ul include o diversitate de operatori
şi funcţii utile pentru prelucrarea tablourilor, şirurilor de caractere şi a numerelor .

2.1.2 Gestiunea unei aplicaţii Web în PHP

Datele dintr-o formă sunt disponibile prin intermediul variabilelor globale care sunt
gestionate automat de PHP şi sunt accesibile prin şirul asociativ $GLOBALS sau direct.
Unele dintre acestea sunt: $HTTP_USER_AGENT, $REMOTE_ADDR,
$REQUEST_METHOD, $QUERY_STRING, $PATH_INFO şi altele. Există variabilele
globale $HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_COOKIE_VARS,
$HTTP_ENV_VARS, $HTTP_SESSION_VARS, $HTTP_SERVER_VARS. Acestea sunt
şiruri asociative ce permit accesul la datele trimise dintr-o formă .
Există o bibliotecă cu funcţii pentru gestiunea unei sesiuni. O sesiune este creată în
momentul apelului funcţiei session_start() sau implicit când se înregistrează o variabilă ca
fiind legată de o sesiune cu funcţia session_register(). Aceste funcţii au rolul de a oferi
utilizatorului un identificator unic de sesiune, care apoi poate fi apoi folosit pentru a accesa
informaţii legate de acest identificator. Când un utilizator accesează o pagină care face
parte dintr-o sesiune atunci acestui utilizator i se va asocia un identificator nou sau i se va
reasocia unul care deja a fost stabilit într-un acces anterior. Variabilele globale asociate
sesiunii devin disponibile în codul paginii. Există module ce persistă starea unei sesiuni în
baze de date. După apelul funcţiei session_start() se poate accesa identificatorul de sesiune
prin funcţia session_id(). Când o sesiune nu mai este necesară se poate apela funcţia
session_destroy() care şterge datele asociate cu o sesiune. Variabilele asociate sunt
disponibile în script-ul care apelează session_destroy() până la reîncărcarea acestuia.
Pentru a elimina variabilele de sesiune există funcţia session_unset() .
În ceea ce priveşte interacţiunea cu serverul, există funcţii pentru a executa comenzi
shell (exec()) şi pentru a comunica între procese (de exemplu prin pipe sau prin socket).
Pentru a apela CGI-uri se poate folosi funcţia virtual(); singura problemă este ca CGI-ul
respectiv să trateze corect informaţiile de header HTTP [Sæt].
În PHP se pot folosi mai multe biblioteci ce oferă funcţii pentru prelucrarea
documentelor XML, pentru acces la diverse surse de date (MySQL, Oracle, prin ODBC,
PostgreSQL etc.), pentru comunicare în reţea, pentru prelucrarea arhivelor, pentru accesul
la memorie partajată şi semafoare, pentru criptare şi multe altele [Sæt].

2.1.3 Accesul componentelor software din PHP

PHP 4.0 spre deosebire de versiunile anterioare oferă suport mai bun pentru accesul
altor componente software. Astfel accesul unei componente COM în Windows sau accesul
unor metode Java pe orice sistem ce suportă un JVM devine posibil. Arhitecturile standard
pentru componente la nivel de întreprindere sunt (D)COM de la Microsoft, JavaBeans/RMI
de la Sun şi CORBA de la Object Management Group.
9
 COM (Component Object Model) este o arhitectură software dezvoltată de Microsoft
ce permite abstractizarea unui obiect sau grup de obiecte în componente binare
reutilizabile. Componente situate pe maşini diferite pot comunica prin DCOM. Astfel
COM permite construirea de aplicaţii din componente software binare. Această tehnologie
este independentă de limbajul de programare.
Pentru a invoca serviciile unei componente COM în PHP 4.0 există clasa COM care se
instanţiază pasând numele componentei COM constructorului [Rat]. Astfel se obţine o
instanţă a obiectului COM ale cărui metode se pot executa. Pentru a crea o instanţă a unei
componente DCOM se foloseşte un alt constructor al clasei COM din PHP 4.0 dar cu alţi
parametri: $comp = new COM("Nume.Componentă","adresă.server.com"). În PHP 3.0 nu
se poate folosi clasa COM dar există funcţiile ajutătoare: com_load("Nume.Componentă),
com_invoke($comp, "nume.metodă", "param1", "param2"), com_set($comp,
"Nume.Proprietate", "valoare") şi com_get($comp, "Nume.Proprietate"), aici $comp este
rezultatul întors de com_load() [Rat].
PHP 4.0 poate fi compilat să suporte apelul de metode Java. Asemănător unei
componente COM se utilizează şi o clasă Java: $system = new Java("java.lang.System").
Pentru accesul proprietăţilor există funcţiile ajutătoarea getProperty() şi setProperty(), de
exemplu: printf("Java version = %s \n", $system->getProperty("java.version")).
Accesul obiectelor Java şi a componentelor COM este posibil datorită motorului de
interpretare a PHP-ului. Acesta foloseşte o tehnică denumită object overloading .

3. Extinderea unei aplicaţii pentru a suporta interfaţă Web

În acest capitol voi prezenta trei module dintr-o aplicaţie de gestiune a stocurilor de
materiale realizată în cadrul Societăţii Comerciale Zus Software S. R. L, aplicaţie la a cărei
dezvoltare am participat, precum şi modul în care această aplicaţie a fost extinsă pentru a
suporta clienţi Web.
Aplicaţia "Gestiunea stocurilor de materiale" are scopul de a fi utilizată de către o
societate comercială cu mai multe filiale aflate la distanţă.
Din punct de vedere economic,aceasta rezolvă atât partea de urmărire a stocurilor,
cât şi cea de contabilizare a gestiunii.
Pe baza documentelor de intrare (facturi, avize de însoţire a mărfurilor) aplicaţia
generează nota de intrare-recepţie, document de intrare în gestiunea materialelor. Ieşirea
din gestiune (respectiv nota de descărcare) este generată de operarea bonurilor de consum
sau a fişelor limită.
Pe baza datelor introduse se pot obţine situaţii parţiale sau cumulative la nivel de
societate, cu privire atât la stocurile existente de materiale, cât şi la necesarul de
aprovizionare al unităţii.
Situaţii obtinuţe:
 situaţia mişcărilor de materiale
 fişa gestionarului şi contului
 balanţa conturilor de materiale
 situaţia stocurilor, inclusiv fişa de magazie
 situaţia stocurilor cu mişcare lentă
 situaţii privind consumul de materiale
 situaţii centralizatoare

3.1 Cerinţele sistemului

3.1.1 Descrierea cerinţelor

10
 Voi prezenta într-o pagină Web situaţia mişcărilor de materiale accesibilă prin
intermediul fişei unui material aflat în catalogul de materiale al unei societăţi comerciale.
Accesibile vor mai fi catalogul notelor de recepţie şi cel al bonurilor de consum. Un alt caz
de utilizare pe care doresc să-l prezint este acela al introducerii unităţilor de măsura în
scopul de le asocia materialelor existente în catalog, liniilor unei note de recepţie şi ale
unui bon de consum.

3.1.2 Analiza cerinţelor

Deoarece scopul acestei lucrări sunt aplicaţiile Web am să detaliez proiectarea şi

implementarea celor două aplicaţii Web care comunică cu sistemul de gestiune, dar şi
modulele din acest sistem ce sunt necesare pentru buna funcţionare a acestor aplicaţii.

3.2 Proiectarea sistemului

Sistemul este format dintr-o aplicaţie de gestiune a materialelor şi două aplicaţii Web
care comunică cu aplicaţia de gestiune. În cele ce urmează voi prezenta structura
aplicaţiilor, din cea de gestiune a materialelor voi prezenta doar atât cât este folosit în cele
două aplicaţii Web.

3.2.1 Proiectarea aplicaţiei de gestiune a materialelor

Această aplicaţie are o arhitectură pe trei nivele, care propune separarea în trei straturi :
cel care realizează accesul la date, cel care se ocupă de logica a aplicaţiei şi stratul care
reprezintă interfaţa cu utilizatorul.

3.2.2 Proiectarea celor două aplicaţii Web

Aplicaţiile Web vor folosi un modul de comunicare cu aplicaţia de gestiune. Acest

modul va fi responsabil cu instanţierea unor obiecte înlocuitor (proxy) ale celor reale.
Obţinerea datelor necesare pentru a crea obiecte înlocuitor este complet ascunsă modulului
responsabil cu prezentarea datelor.

3.2.3 Comunicarea între aplicaţii

3.3 Implementarea aplicaţiilor

3.4 Testarea aplicaţiilor Web

3.5 Utilizarea aplicaţiilor Web

Concluzii
Un mare avantaj al aplicaţiilor Web este acela că sunt foarte uşor de livrat. Singurul
produs de care are nevoie un client este un browser, restul se lasă pe seama aplicaţiei şi a
server-ului care o găzduieşte.
PHP-ul este un limbaj de scriptare; nu se deosebeşte cu mult de restul din punct de
vedere al facilităţilor pentru gestiunea de cereri HTTP, menţinerea stării clientului şi
construirea unui răspuns. În opinia mea PHP este o opţiune în cadrul aplicaţiilor simple sau
medii care comunică direct cu o bază de date. Este dificil de folosit în cazul unor aplicaţii
mari pe mai multe nivele care folosesc diverse tehnologii şi sunt executate conform mai
multor şabloane de proiectare.
11
 Bibliografie

[1] Ahmed M., Garrett C., Faircloth J., Payne C. "ASP.NET Web Developer’s Guide",
Syngress Publishing, 2002
[2] Armstrong E., Ball J., Bodoff S., Bode Carson D., Evans I., Green D., Haase K.,
Jendrock E. "The J2EE™ 1.4 Tutorial", Sun Microsystems, 2004"
[3] Calvert C., Calvert M., Kaster J., Swart B. "Kylix Developer’s Guide" , Sams 2002
[4] Iyengar A., Jim Challenger, Daniel Dias, Paul Dantzig "High-Performance Web
Site Design Techniques" IEEE Internet Computing Martie-Aprilie 2000
[5] Martin J., Tomson B. "Introducere în ASP.NET", Teora 2002
[6] McCarty B."PHP 4", Teora 2002
[7] Trifu B.E."Programarea Dinamică a Paginilor Web cu Active Server Pages",
Editura Albastră 2001

12