sabinburaga tehnologii web

Sabin Corneliu Buraga

TTeehhnnoollooggiiii WWeebb

2007

Sabin Corneliu Buraga – Tehnologii Web

Autorul acestei lucrări – Dr. Sabin Corneliu Buraga – este cadru didactic la Facultatea de Informatică a Universităţii „Alexandru Ioan Cuza” din Iaşi, România, fiind titula-rul cursurilor „Tehnologii Web”, „Semantic Web”, „Interacţiune om-calculator” şi „Reţele de calculatoare”. Este laureat al Premiului „Gheorghe Cârtianu” al Academi-ei Române (2005) şi coordonatorul seriei Web publicată de Editura Polirom.

Mai multe amănunte privitoare la activităţile sale sunt disponibile pe Web la adresa http://www.infoiasi.ro/~busaco/.

Materialul de faţă, inclusiv figurile, nu poate fi folosit sau reprodus sub nici o formă decât cu acordul autorului, fiind protejat de legile în vigoare privitoare la drepturile de autor.

De asemenea, autorul nu se face răspunzător pentru disponibilitatea şi/sau acurate-ţea informaţiilor de la adresele Web indicate pe parcursul lucrării.

2


3

CCuupprriinnss

În loc de prefaţă… ..................................................................................................5

Partea I – Internet şi Web .......................................................................................7 1. Fundamente şi istoric ..........................................................................................9 2. Localizarea resurselor Web ................................................................................18 3. Protocolul HTTP pe scurt .................................................................................23 4. Privire de ansamblu ...........................................................................................27

Partea II – Familia de limbaje XML ......................................................................29 1. Preambul ...........................................................................................................31 2. Caracterizare şi trăsături esenţiale ......................................................................32 3. Părţile componente ale unui document XML ....................................................34 4. Membrii constituenţi ai familiei XML ................................................................37 5. Spaţiile de nume XML.......................................................................................41 6. Validarea documentelor XML ...........................................................................43 7. Procesarea documentelor XML .........................................................................54 8. Transformări XML ............................................................................................62 Partea III – Programarea aplicaţiilor Web..............................................................71 1. Maniere de programare pe partea de server........................................................73 2. Standardul CGI (Common Gateway Interface) .........................................................76 3. PHP (PHP: Hypertext Preprocessor) .......................................................................85 4. Servicii Web ....................................................................................................110


Partea IV – Regăsirea informaţiilor pe Web.........................................................121

1. Preliminarii ......................................................................................................123 2. Motoare de căutare ..........................................................................................124 3. Meta-căutătoare ...............................................................................................135 4. Alte mijloace de regăsire a informaţiilor...........................................................137

Exerciţii şi teme propuse .....................................................................................143 Resurse bibliografice ...........................................................................................147

4


5

ÎÎnn lloocc ddee pprreeffaaţţăă……

„Este mai bine să ştii câteva întrebări decât toate răspunsurile.” James Thurber

Acest material realizează o trecere în revistă a principalelor trăsături referitoare la spaţiul World Wide Web, punctând anumite aspecte de interes privitoare la arhitectura Web-ului, la meta-limbajul XML (componente, spaţii de nume, validarea şi transformarea documen-telor XML), la proiectarea şi programarea aplicaţiilor Web (standardul CGI, serverul de aplicaţii PHP, serviciile Web bazate pe XML) şi la regăsirea informaţiilor disponibile pe Web via motoare de căutare şi alte mijloace.

Lucrarea reprezintă numai o introducere în domeniul tehnologiilor Web actuale, o par-te dintre subiectele menţionate fiind însoţite de prezentări şi exemple disponibile online la http://www.infoiasi.ro/~busaco/teach/courses/web/.

Pentru aprofundarea domeniului, cititorul este încurajat să consulte resurse prezentate în cadrul bibliografiei şi să viziteze periodic situl Web al autorului textului de faţă –http://www.infoiasi.ro/~busaco/.

Aşteptăm posibilele reacţii şi opinii pe adresa [email protected].


6


7

PPaarrtteeaa II –– IInntteerrnneett şşii WWeebb

„De la un anumit punct încolo, nu mai există cale de întoarcere. Acela este punctul ce trebuie atins.” Franz Kafka

1. Fundamente şi istoric 2. Localizarea resurselor Web 3. Protocolul HTTP pe scurt 4. Privire de ansamblu


8


1. Fundamente şi istoric

Conceptul esenţial al spaţiului World Wide Web îl reprezintă conceptul de comunicare, pe care de altfel se bazează orice reţea de calculatoare. Înainte de a defini spaţiul World Wide Web, trebuie precizat mai întâi ce înseamnă o reţea de calculatoare, respectiv Internetul.

O reţea de calculatoare reprezintă un ansamblu de calculatoare independente ca-pabile să comunice între ele prin intermediul unor canale de comunicaţie. Aşadar, o reţea poate fi privită drept colecţie de calculatoare autonome interconectate.

Luat în sine, Internetul este o reţea de reţele, prin care utilizatorii unui calculator sau ai unei reţele pot accesa diverse sisteme aparţinând altor reţele.

Precursorul Internetului, ARPAnet (Advanced Research Projects Agency network) a fost dez-voltat la sfârşitul anilor ’60 şi începutul anilor ’70 de către Departamentul de Apărare al Statelor Unite ca experiment în plin război rece, după lansarea primului satelit artificial, Sputnik. De la început, utilizarea reţelei în scopuri academice şi pentru comunicaţii ştiinţi-fice a condus la o oarecare îndepărtare de scopul iniţial – folosirea exclusivă în medii mili-tare. Prima demonstraţie publică a reţelei ARPAnet a avut loc în 1972, soldată cu un neaşteptat succes, în ciuda scepticismului dezvoltatorilor ei. Acest aspect a stimulat activi-tatea de cercetare, apărând curând noi reţele, iar programatorii fiind încurajaţi să adauge noi facilităţi sistemului de operare Unix folosit la interconectarea reţelelor. Astfel, în me-diul prielnic oferit de sistemul de operare Unix, au fost dezvoltate în această perioadă primele protocoale de comunicaţie, culminând în 1974 cu suita de protocoale TCP/IP (Transmission Control Protocol/Internet Protocol). Meritul acesteia este acela de a furniza o mo-dalitate universală şi standardizată de comunicare între reţelele de calculatoare, folosită şi în prezent pentru conectarea la Internet.

În anul 1980, NSF (National Science Foundation) reproiectează modelul ARPAnet, transformându-l într-o reţea modernă, noua arhitectura primind numele de Internet, in-terconectând la început super-calculatoare guvernamentale, instituţii academice şi centre de cercetare şi utilizând suita standard de protocoale de comunicaţie reprezentată de TCP/IP (Transmission Control Protocol/Internet Protocol). În anii care urmează, Internetul se dezvoltă spectaculos, într-o manieră exponenţială, poate şi datorită apariţiei unei varietăţi de furnizori de servicii Internet comerciale, la nivel mondial, mai ales în cursul anilor ’90. În România, o dezvoltare accentuată a Internetului, la toate nivelele, s-a produs începând cu anii 1993-1994, dar mai ales după 1996.

De reţinut faptul că Internul nu este proprietatea nici unei persoane sau organizaţii, aflându-se sub coordonarea unor societăţi independente, constituite din voluntari, dintre care se pot aminti ISOC (Internet Society) sau IETF (Internet Engineering Task Force).

Serviciile tradiţionale ale Internetului se rezumau în anii ’80 la poşta electronică (e-mail), accesul la grupuri de ştiri (usenet), conectare la distanţă (telnet) şi transfer de fişiere (FTP).

9


În 1990-1991 apar două noi servicii (acum dispărute): Archie utilizat pentru căutarea fişie-relor pe Internet şi Gopher, structură de meniuri ierarhizate facilitând organizarea docu-mentelor pe Internet.

De notat faptul că funcţionarea Internetului este reglementată de o serie de documente disponibile în cadrul colecţiei globale RFC (Request For Comments) – www.ietf.org/rfc/. O parte dintre aceste documente specifică arhitectura şi standardele protocoalelor de co-municaţie existente.

Începuturile Web-ului

Unul dintre cele mai importante şi de succes servicii ale Internetului, World Wide Web-ul – mai pe scurt, Web sau spaţiul WWW – a fost instituit la CERN (Centre European pour la Recherche Nucleaire – Centrul European de Cercetări Nucleare de la Geneva) în anul 1989, pe baza cercetărilor lui Tim Berners-Lee, Robert Caillau şi echipei acestora, scopul principal urmărit fiind facilitarea accesului rapid la informaţiile tehnice cuprinse în ma-nualele de utilizare a calculatoarelor. Robert Caillau accentuează faptul că istoria fiecărei mari invenţii se bazează pe multe evenimente anterioare. În cazul Web-ului, două mari direcţii precursoare trebuie menţionate: dezvoltarea hipertextului (sau a procesării compu-terizate a documentelor electronice complexe) şi dezvoltarea protocoalelor Internet care au făcut posibilă comunicarea globală dintre reţelele de calculatoare.

Data de 12 noiembrie 1990 este considerată drept ziua de naştere oficială a Web-ului. CERN devenea astfel cel mai dezvoltat nod Internet al Europei.

Web-ul reprezintă un sistem de distribuţie locală sau globală a informaţiilor hipermedia.

Din punct de vedere tehnic, spaţiul Web pune la dispoziţie un sistem global şi standar-dizat de comunicare multimedia, informaţiile fiind organizate asociativ şi fiind distribuite în funcţie de cererile utilizatorilor, funcţionând conform modelului client/server. Web-ul, cu toată dezvoltarea lui spectaculoasă, nu trebuie confundat cu Internetul, ci poate fi con-siderat drept cea mai dinamică şi spectaculoasă componentă software a acestuia, nepu-tând exista fără infrastructura hardware a reţelelor mondiale interconectate prin interme-diul protocoalelor TCP/IP.

Dezideratele principale ale sistemului propus de Tim Berners-Lee erau:

• accesul la distanţă într-o reţea, acceptându-se diverse tipuri de conexiuni;

• accesul la o multitudine de surse de informaţii stocate într-o varietate de forme (text, grafică, sunet etc.) cu ajutorul unor tipuri diferite de sisteme de operare situate pe diferite platforme hardware;

• capabilităţi de extindere şi dezvoltare în ceea ce priveşte aria de acoperire prin creşterea numărului de legături, fără existenţa unui control central.

Tim Berners-Lee concepe, de asemenea, prima aplicaţie Web – un server Web rulând pe calculatoare NeXT. În noiembrie 1990, Nicola Pellow începe să dezvolte un navigator

10


(browser) text care la sfârşitul aceluiaşi an va fi disponibil în cadrul CERN. Primul client grafic permiţând vizualizarea de documente WWW a fost WorldWideWeb.

Dezvoltarea ulterioară a Web-ului a fost facilitată de programul Mosaic (de la NCSA –Centrul Naţional pentru aplicaţiile supercalculatoarelor, Universitatea Urbana-Champaign), rulând sub mediul XWindow (Unix). Acest navigator – elaborat în principal de Marc Andreesen – era foarte simplu de folosit şi poseda facilităţi multimedia, fiind furnizat gratuit pe Internet începând cu anul 1993. Ulterior, Marc Andreesen fondează compania Netscape Communications, specializată în realizarea de aplicaţii destinate Web-ului, care – ulterior – a donat comunităţii open source codul-sursă al navigatorului, peste ani apărând astfel Mozilla Firefox.

În 1994 a fost constituit Consortiul Web, avându-l ca director pe Tim Berners Lee. Con-sorţiul Web este o organizaţie non-profit, principala sa activitate constând în elaborarea, dezvoltarea şi menţinerea standardelor destinate spaţiului WWW. Actualmente, Consor-ţiul Web însumează peste 500 de membri, atât organizaţii academice, corporaţii comercia-le, cât şi persoane particulare. Mai multe detalii sunt disponibile pe situl Web www.w3.org.

Clienţi şi servere Web

În prezent, pentru a avea acces la WWW, utilizatorii trebuie să folosească un program client – cunoscut sub denumirea de navigator – şi, bineînţeles, să cunoască localizarea fizi-că a documentelor dorite (adresa acestora). Există actualmente o multitudine de naviga-toare, alături de binecunoscutele Netscape Communicator, Mozilla Firefox şi Internet Explorer (rulând în medii grafice precum Windows, XWindow (Unix/Linux) sau Apple) numărându-se multe altele, chiar daca nu atât de populare: Opera, Konqueror, Lynx sau Links (ultimele două rulând doar în mod text, fiind disponibile mai ales sub Linux).

Principalele caracteristici ale navigatoarelor Web grafice sunt:

• posibilitatea de a realiza interogări multiple către serverele Web;

• asigurarea securităţii transmiterilor de date (de exemplu, în cazul comerţului electronic sau pentru accesarea unor informaţii pe bază de autentificare);

• suport pentru aplicaţii menite să extindă funcţionalitatea navigatorului. O astfel de extensie este denumită de cele mai multe ori plugin, putând fi configurată şi exploatată de către utilizator pentru accesarea unor tipuri speciale de date (e.g. lumi virtuale modelate în VRML, documente PDF sau animaţii Flash);

• stabilirea de liste de adrese ale unor situri Web favorite şi oferirea posibilităţii de a avea acces la istoricul navigării (mecanismul de history);

• posibilitatea de a folosi mai multe ferestre (independente sau nu) de navigare;

• suportul pentru cadre (frame-uri) sau vederi multiple în interiorul unei aceleaşi ferestre;

11


• posibilitatea configurării de către utilizator a unor caracteristici ale modurilor de afişare, navigare şi exploatare (stabilirea preferinţelor utilizatorilor);

• asigurarea suportului pentru diverse limbaje de programare folosite la realizarea de documente Web dinamice (i.e. Java sau JavaScript), pentru foi de stiluri ata-şate datelor (în vederea îmbunătăţirii modului de afişare) sau pentru stocarea datelor în mai multe limbaje de marcare (HTML, XHTML, limbaje bazate pe XML etc.);

• integrarea unor aplicaţii facilitând accesul la alte servicii Internet (poşta elec-tronică, transferul de fişiere, grupurile de ştiri) sau Web (precum căutarea de in-formaţii, afişarea de noutăţi, accesarea în timp-real a programelor de radio sau televiziune etc.).

O versiune a navigatorului Konqueror rulând în mediul XWindow (sub Linux)

După cum se poate observa, Web-ul se bazează pe modelul de programare cli-ent/server care divide aplicaţiile de reţea în două părţi: partea de client şi cea de server. Prin definiţie, clientul (în cazul nostru denumit şi navigator sau agent-utilizator Web) so-licită servicii (informaţii) de la componenta server. Serverul răspunde aşadar cererilor cli-enţilor.

12


Modul de dialogare între clienţi şi servere se realizează prin intermediul unei mulţimi de reguli de comunicare prin reţea denumită protocol.

În cazul Web-ului, acest protocol este HTTP (HyperText Transfer Protocol). HTTP repre-zintă un protocol bazat pe stiva de protocoale TCP/IP. HTTP a început să fie proiectat şi folosit din anul 1990, dezvoltându-se împreună cu spaţiul WWW. În prezent, este utili-zată versiunea HTTP/1.1 care oferă funcţionalităţi suplimentare, ca de exemplu suport pentru identificatori uniformi de resurse – URI (Uniform Resource Identifier). Aceşti identificatori specifică adresele Web ca locaţie (prin URL – Uniform Resource Locator) sau prin nume (URN – Uniform Resource Name). Identificatorii uniformi de resurse reprezintă o modalita-te flexibilă şi eficientă de accesare a oricărei resurse Internet, prin oricare protocol de comunicare. Încorporând suport pentru transferul de poştă electronică, transferul de fişi-ere sau accesul la grupuri de ştiri, HTTP este de asemenea utilizat şi ca protocol generic pentru comunicarea între agenţii utilizator (navigatoare, roboţi Web etc.) şi alte sisteme disponibile pe Internet. În acest mod, HTTP permite accesul la resurse disponibile din diverse aplicaţii.

Numeroase detalii privitoare la protocolul HTTP pot fi găsite consultând căr-ţile S. Buraga, Tehnologii XML, Polirom, Iaşi, 2006 şi S. Buraga et al., Programare Web în bash şi Perl, Polirom, Iaşi, 2002.

Ca orice serviciu Internet bazat pe modelul client/server, Web-ul trebuie să includă o multitudine de servere Web. Cele mai cunoscute servere Web sunt Apache, Netscape Enterprise Server, Sun Web Server, Microsoft Internet Information Services, Stronghold, Jigsaw (dis-ponibile pe diverse platforme, în special Unix).

Situri Web

Calculatorul pe care rulează un server Web şi care găzduieşte o serie de pagini (documente) WWW înrudite – ale unei organizaţii, companii sau persoane – se mai numeşte şi sit (site). Această colecţie este orientată de obicei către anumite in-formaţii unitare sau scopuri comune.

Există două tipuri majore de situri Internet:

• situri Web – seturi de pagini Web corelate şi resursele la care se referă acestea;

• situri FTP – servicii configurabile care furnizează acces la fişiere publice (do-cumentaţii, programe, informaţii) prin intermediul protocolului FTP.

Un sit Web are asociată în general o adresă vizibilă oricărui utilizator din Internet (de exemplu, www.info.uaic.ro este adresa sitului Facultăţii de Informatică din Iaşi).

Un server Web poate gestiona simultan mai multe situri, oferind aşa-numita găzduire virtuală (virtual hosting). Acest lucru este util în situaţia în care o anumită organizaţie îşi menţine situl Web pe un alt server (de exemplu, pe serverul unui distribuitor de servicii Internet – Internet Service Provider).

13


Un caz particular de disponibilitate a unui sit Web este în cadrul unui intranet, adică a unei reţele interne – proprii unei companii sau organizaţii – care foloseşte tehnologiile Internet. Situl Web dintr-un intranet nu este accesibil persoanelor din exteriorul organiza-ţiei proprietare, ci exclusiv membrilor acesteia. Din acest punct de vedere, intranetul poa-te fi privit ca fiind un mini-Internet, restrâns la nivelul unei reţele locale. Companiile care s-au slujit de facilităţile intranetului au înregistrat economii importante datorită accesului rapid la date şi aplicaţii, comparativ cu problemele şi costurile ce ar fi fost implicate de distribuirea în scris a acestora în interiorul corporaţiei.

Un sit Web poate fi disponibil şi în cadrul extranetului – o extindere a facilităţilor intra-netului prin mijlocirea comunicaţiilor între intraneturile a două sau mai multe organizaţii. Avantajele cele mai atrăgătoare sunt cele din domeniul afacerilor pe Internet, în sectorul business-to-business (B2B).

O aplicaţie Web reprezintă o colecţie interconectată de pagini Web cu conţinut dinamic menită a oferi o funcţionalitate specifică utilizatorilor.

Natural, interacţiunea dintre aplicaţie şi utilizatori are loc prin intermediul unei interfe-ţe Web. Deseori, termenii de sit şi aplicaţie Web sunt folosiţi unul în locul celuilalt, pen-tru a desemna acelaşi concept.

Drept exemple de aplicaţii Web pot fi enumerate Amazon, Basecamp, eBay, Expedia, Flickr, Google Maps, PHPMyAdmin, Wikipedia, Yahoo! şi multe altele.

Hipermedia

Alături de modelul client/server, al doilea concept important pe care s-a putut construi Web-ul este cel de multimedia.

În esenţă, multimedia reprezintă o sumă de diverse medii de comunicare: statice (text, imagini precum fotografii, diagrame sau grafice) şi dinamice (sunet, anima-ţie, filme). Dacă la acest conţinut informaţional se adaugă şi capabilităţi de a reali-za diverse legături (relaţii) între părţile componente ale documentelor multimedia, ceea ce rezultă se numeşte hipermedia sau hipertext (termen apărut în anul 1965, în urma cercetărilor întreprinse de personalităţi precum Vannebar Bush, Douglas Engelbart şi Ted Nelson).

În anul 1965, Ted Nelson inventează termenul hipertext (text non-linear), definindu-l drept „material scris sau grafic interconectat într-o manieră complexă care în mod con-venţional nu poate fi reprezentat pe hârtie. El poate conţine cuprinsuri ale propriului său conţinut şi relaţiile dintre diverse părţi componente; poate de asemeni conţine adnotări, adăugiri şi note de subsol pentru cei care doresc să-l examineze”.

Definiţiile hipertextului sunt diverse. O primă definiţie ar fi aceea că hipertextul repre-zintă o formă de document electronic. O alta, alternativă, specifică hipertextul ca repre-zentând o metodă de organizare a informaţiilor în care datele sunt memorate într-o reţea de noduri şi legături, putând fi accesată prin intermediul navigatoarelor interactive şi ma-nipulată de un editor structural.

14


Hipertextul semnifică o tehnică pentru organizarea informaţiei textuale printr-o meto-dă complexă neliniară în vederea facilitării explorării rapide a unei cantităţi mari de cunoş-tinţe. Conceptual, o bază de date hipertext poate fi gândită ca un (di)graf, unde fiecare nod poartă un fragment de text şi unde arcele grafului conectează unele fragmente de text cu altele înrudite. Pentru a vizualiza textul dintr-o astfel de bază de date, utilizatorul se va folosi de o interfaţă, traversând legăturile.

Conceptul esenţial prezent în cadrul hipertextului este cel al legăturilor (care apar în ca-drul aceluiaşi document şi/sau între documente diferite). Această caracteristică de legare permite organizarea non-lineară a informaţiilor.

O parte dintre avantajele hipertextului faţă de textul tipărit sunt:

– forma neliniară a hipertextului oferă facilităţi eficiente de parcurgere a conţi-nutului;

– mediile electronice pot stoca o cantitate impresionantă de informaţii;

– hipertextul oferă o mai bună vizualizare a conţinutului şi o navigare rapidă, oricât de complexe ar fi documentele, ţinând cont de specificaţiile utilizatori-lor;

– în cadrul sistemelor hipertext, interogările, filtrările, diversele preferinţe şi ad-notările utilizatorilor pot fi refolosite ori de câte ori este necesar, putând fi stocate în cadrul structurii hipertext a documentelor folosite.

Principalele probleme cu care se confruntă informaticienii în ceea ce priveşte hipertex-tul sunt cele legate de:

• conversie (în general automată) a textului liniar în formă hipertext şi liniarizare a hi-pertextului;

• proiectare (design) a documentelor hipertext;

• accesare concurentă a bazelor de date hipertext în context distribuit;

• construire a unor mecanisme optime pentru căutarea şi interogarea în manieră inteli-gentă a informaţiilor hipertext;

• suportare a extensiilor multimedia;

• prezentare a documentelor hipertext într-o formă uşor de parcurs de către utiliza-tori etc.

15


O structură hipertext compusă din mai multe noduri şi modul de vizualizare folosind un browser hipertext

În principiu, un sistem hipermedia este constituit din noduri (concepte) şi legături (rela-ţii). Un nod reprezintă, în mod uzual, un concept unic (o idee), putând conţine text, gra-fică, animaţie, audio, video, imagini sau programe. Un nod poate avea asociat un tip (de-taliu, propoziţie, colecţie, observaţie etc.) înglobând o informaţie semantică. Nodurile sunt conectate de alte noduri prin intermediul legăturilor. Nodul sursă al unei legături se numeşte referinţă, iar cel destinaţie referent, fiind denumite şi ancore. Conţinutul unui nod se afişează la activarea legăturii.

Legăturile sunt conexiuni între noduri (sau concepte) dependente unul de altul, putând fi bidirecţionale sau doar unidirecţionale. Legăturilor li se pot asocia tipuri, definind natura relaţiei dintre noduri. Legăturile pot fi referenţiale (non-ierarhice, utile pentru realizarea re-ferinţelor încrucişate, ele fiind cele care deosebesc cel mai bine hipermedia de celelalte forme de stocare a informaţiei) sau organizaţionale (denumite ierarhice sau structurale, ilus-trând relaţiile părinte-copil dintre noduri, folosite la organizarea nodurilor în manieră ie-rarhică într-o structură strictă). Legăturile organizaţionale sunt esenţiale pentru liniariza-rea hipertextului şi permit autorilor să verifice coerenţa structurii hipertext.

De asemenea, legăturile pot fi statice (stabilite de autorul documentului) sau dinamice (create în momentul rulării sistemului hipertext, în funcţie de context sau de cerinţele uti-lizatorilor). Ele pot fi utilizate, de exemplu, pentru a încorpora proceduri de securitate (o legătură poate fi disponibilă doar pentru un anumit utilizator autentificat) ori să permită utilizatorilor să-şi creeze legături personale între diverse noduri care în mod uzual nu sunt conectate direct.

Activarea marcajelor unei legături duce la vizualizarea (activarea) nodurilor.

Înţelegerea şi navigarea printr-un document de tip hipertext depind de abilitatea utili-zatorului de a construi o reprezentare mentală coerentă a structurii hipertextului, rămâ-nând în responsabilitatea creatorului documentului să asigure această coerenţă. Construi-rea unui document hipertext coerent poate fi considerată o problemă de design, fără a exista însă legi pentru conceperea de documente hipertext „corecte”, deşi unii cercetători au stabilit o serie de reguli pentru aceasta. Astfel, un document hipertext coerent constă

16


din trei componente: partea de conţinut, partea de organizare şi partea de prezentare a informaţii-lor.

Una dintre soluţiile de a crea documente hipertext este oferită de limbajul de marcare HTML (HyperText Markup Language), apărut încă de la începuturile Web-ului, în prezent regăsit sub versiunea XHTML. Marcajele HTML descriu structura logică a documentului, urmând a fi procesate de către programul client (de cele mai multe ori, un navigator). Un astfel de document poate cuprinde legături de tip hipertext, indicate prin zone de text sau imagini, conducându-l pe utilizator fie în alt punct al aceluiaşi document, fie într-un alt document, care poate să se găsească stocat local (pe serverul curent) sau la distanţă (pe oricare alt sit Web din lume). Un document marcat se numeşte pagină Web.

Documentele pot include elemente multimedia variate datorită facilităţilor puse la dis-poziţie de diferitele versiuni ale limbajului HTML care prevăd inserarea de imagini (for-mate grafice precum GIF, JPEG sau PNG), fişiere audio (MIDI, WAV ori MP3) şi video (AVI, ATF, MPEG), precum şi alte informaţii în formate proprietare sau nu (e.g., arhive, documente PDF, animaţii Flash, lumi virtuale VRML).

Îmbinarea dintre marcajele HTML şi diverse linii de cod scrise în alte limbaje de pro-gramare (JavaScript, VBScript – pe partea client; C/C++, C#, Perl, PHP, Python sau Java – pe partea server) conferă Web-ului interactivitate sporită şi dinamism, caracteristici exploatate mai ales în contextul e-business, dar nu numai.

Aceste legături încrucişate între sutele de mii de situri Web realizează o adevărată pân-ză de păianjen (web) planetară (world-wide) de unde provine şi denumirea WWW, iar utiliza-torul navighează prin ciberspaţiul reprezentat de această reţea complexă.

În ultimii zece ani, Web-ul s-a dezvoltat exploziv, asimilând şi un nou aspect: nu se mai limitează la schimbul de informaţii ştiinţifice între cercetători, ci a devenit domeniu pu-blic, extinzându-se foarte mult în lumea afacerilor. Astfel, Web-ul poate fi considerat segmentul Internet cu cea mai rapidă dezvoltare.

Dacă Internetul este o reţea de reţele, format din calculatoare şi medii de transmisie ca-re transportă pachete de date de la un calculator la altul, Web-ul reprezintă un spaţiu ab-stract de informaţie. Pentru Internet, conexiunile sunt reprezentate de canalele de comu-nicaţie (cu fir sau fără fir) între calculatoare, iar pe Web conexiunile sunt ilustrate prin legături hipertext. Web-ul există datorită aplicaţiilor care asigură comunicarea în cadrul Internetului şi a făcut din Internet un spaţiu public, liber de constrângeri, universal şi uşor de utilizat.

17


2. Localizarea resurselor Web

Localizarea informaţiilor în Internet se realizează apelându-se la aşa-numiţii identificatori uniformi de resurse – URI (Uniform Resource Identifiers).

Este considerată resursă orice entitate având identitate, de exemplu un docu-ment electronic, o imagine, un serviciu (i.e. serviciul de poştă electronică), o colec-ţie de alte resurse.

Nu toate resursele pot fi accesate direct pe Internet, de vreme ce pot fi considerate drept resurse (non-electronice) şi fiinţele umane, organizaţiile, volumele dintr-o bibliotecă etc. O resursă se poate menţine constantă în timp, deşi conţinutul ei – entităţile cărora ea le corespunde – se poate modifica. Pentru facila lor localizare, resursele sunt desemnate printr-un identificator (în cazul Internetului, identificatorii reprezintă o secvenţă de caracte-re având o sintaxă bine-definită, după cum vom vedea mai jos). Pentru ca diverse tipuri de identificatori de resurse să poate fi utilizate în acelaşi mod, s-a recurs la folosirea unor scheme uniforme de identificatori. Acest principiu adoptat asigură independenţa de meca-nismul (protocolul) folosit pentru accesarea resurselor, permiţându-se astfel interpretarea într-o manieră uniformă a mai multor convenţii sintactice desemnând identificatori ai unor resurse eterogene. Mai mult, pot fi introduse noi tipuri de identificatori de resurse fără a fi modificat modul de adresare a vechilor tipuri.

Identificatorii uniformi de resurse pot fi divizaţi în două categorii:

• localizatori uniformi de resurse – URL (Uniform Resource Locator) care identifică resursele printr-o reprezentare a mecanismului de accesare a lor (e.g. localizarea unor resurse prin intermediul adresei calculatorului pe care este stocată şi a reţelei din care face parte acel computer), nu prin nume sau alte atribute (vezi mai jos);

• nume uniforme de resurse – URN (Uniform Resource Name) ce permite specifi-carea unei resurse chiar dacă resursa a dispărut ori a devenit inaccesibilă, prin in-termediu unui nume care rămâne permanent şi unic. URN-ul se utilizează mai ales pentru a desemna entităţi folosite de anumite aplicaţii Web. Ca exemple de URN-uri putem menţiona:

– urn:mozilla:package:communicator

– urn:schemas-microsoft-com:datatypes

Drept exemple de URL-uri, le putem descrie pe următoarele:

• http://www.infoiasi.ro/~busaco/cv.html – se identifică resursa reprezentată de documentul Web cv.html prin intermediul acestui URL, via o schemă http asociată serviciilor protocolului de transfer a hipertextelor (HTTP –HyperText Transfer Protocol);

• ftp://ftp.uaic.ro/pub/Readme.txt – se utilizează o schemă ftp pen-tru serviciile protocolului de transfer de fişiere (FTP – File Transfer Protocol);

18


• mailto:[email protected] – contul unui utilizator Internet se speci-fică printr-o schemă mailto pentru poşta electronică.

Un URL este compus din următoarele componente principale:

protocol://domeniu/cale?şir_de_interogare

Componentele protocol (de cele mai multe ori http, specificând utilizarea protoco-lului HTTP pentru accesarea resurselor Web) şi domeniu sunt obligatorii.

Componenta domeniu reprezintă în mod uzual numele unui server Web de pe care dorim să accesăm o pagină WWW (a unui sit), identificând într-o manieră unică un calcu-lator conectat la Internet. Domeniul poate fi specificat printr-un şir de patru octeţi des-părţiţi de punct, şir denumit adresă IP (de exemplu: 193.231.30.225), sau prin numele simbolic – mai uşor de reţinut – corespunzător adresei IP, asociat unui calculator (adresei IP dată mai sus îi corespunde numele thor.info.uaic.ro). Numele simbolic reprezin-tă un şir de identificatori de domenii sau de sub-domenii şi de calculatoare ale unui (sub)domeniu.

Ierarhia de domenii de nume – primul nivel este cel al domeniilor primare

Domeniile primare (principale) sunt cele apărute la începuturile Internetului (de obicei localizate în Statele Unite ale Americii, dar nu obligatoriu):

• .com desemnează o companie sau organizaţie comercială – .ibm.com sau .jclark.com,

• .org reprezintă o organizaţie non-profit – de exemplu, .w3.org (Con-sorţiul Web) ori .oasis-open.org,

• .gov specifică domeniul unei organizaţii guvernamentale (americane) – .whitehouse.gov,

• .mil desemnează o organizaţie militară – .dmso.mil sau .navy.mil,

19


• .net reprezintă o organizaţie cu preocupări în domeniul reţelelor de cal-culatoare şi al Internetului – .uu.net ori .php.net,

• .int desemnează o organizaţie internaţională – .greenpeace.int,

• .edu specifică domeniul unei organizaţii din spaţiul academic, educativ (de origine americană) – .uiuc.edu ori .stanford.edu.

Tot domenii primare sunt considerate domeniile corespunzătoare statelor lumii, codi-ficate conform codului rutier. De exemplu, .ro corespunde României, .de este specific Germaniei, .jp asociat Japoniei etc. Mai recent, au apărut domenii primare noi precum .ws (denumire provenind de la World Site) specific siturilor Web comerciale, .biz dedicat activităţilor de afaceri Internet (e-business) sau .info pentru siturile Web informaţionale (de exemplu, www.schemaweb.info).

În România autoritatea care se ocupă cu înregistrarea şi reglementarea domeniilor .ro din ţara noastră este Reţeaua Naţională de Calculatoare (RNC) – www.rnc.ro. Înregistrarea unui domeniu .ro se poate realiza direct la RNC sau la unul dintre partenerii acestuia, persoana care a înregistrat domeniul purtând răspunderea pentru eventualele conflicte apărute. Instituţia RNC poate suspenda sau anula dreptul de folosinţă al unui domeniu, în condiţiile sesizării existenţei unor litigii pe rol, folosirii inadecvate a numelui de domeniu sau dacă datele despre organizaţia sau persoana care a înregistrat domeniul respectiv sunt false ori incorecte etc.

Fiecare domeniu primar va avea în jurisdicţie o serie de sub-domenii, corespunzând diverselor organizaţii, companii şi persoane care fac parte din acel domeniu. Un sub-domeniu poate fi compus din sub-sub-domenii sau din nume simbolice de maşini conec-tate la Internet. De exemplu, este uşor de înţeles că adresa www.infoiasi.ro corespun-de calculatorului www (serverul Web) din sub-domeniul infoiasi al domeniului .ro. Un calculator poate avea asociate mai multe nume simbolice (serverul thor are asociat şi numele www, denumit şi alias, pentru servicii de tip World-Wide Web, dar şi alias-ul ftp pentru servicii de transfer de fişiere via FTP). Aşadar, www.infoiasi.ro este identic cu thor.infoiasi.ro sau cu ftp.infoiasi.ro.

Pentru a vizita pagina principală a serverului (sitului) Web al Facultăţii de Informatică din Iaşi se va folosi URL-ul următor: http://www.infoiasi.ro. La fel de bine, se pu-tea utiliza http://193.231.30.225, dar se preferă numele simbolice pentru că sunt mult mai uşor de reţinut şi în plus sunt independente de adresa IP stabilită (mai mult, pot exista adrese IP multiple asociate cu acelaşi nume simbolic).

Corespondenţa dintre numele simbolic şi adresa IP a unui calculator este facilitată de un serviciu denumit DNS (Domain Name System) – sistemul numelor de domenii.

Mai multe detalii în cartea S. Buraga, Proiectarea siturilor Web (ediţia a II-a), Polirom, Iaşi, 2005.

Dacă se doreşte accesarea unei anumite resurse (fişier) memorată pe un server Web, va trebui ca în cadrul URL-ului, imediat după domeniu să fie specificată calea până la acea

20


resursă, adică şirul de nume de directoare, terminat eventual cu numele fişierului dorit. Directoarele vor fi despărţite de caracterul „/”, ca în exemplul următor: http://www.infoiasi.ro/eurolan/euro95.html. Acest URL indică resursa desem-nată de documentul HTML euro95.html, resursă aflată în directorul eurolan localizat în directorul rădăcină al sitului Web www.infoiasi.ro. Dacă la sfârşitul unei căi de di-rectoare nu este specificat numele unui fişier, va fi încărcată o pagină implicită (denumită şi pagină index) al cărui nume este dependent de serverul Web operaţional pe calculatorul accesat sau de modul de configurare a acestuia (ca exemple standard, pot fi menţionate index.html pentru un server Apache ori default.htm pentru Microsoft IIS). Dacă un nume de director sau de fişier include caracterul spaţiu sau un alt caracter rezervat, aces-tea vor fi substituite de codul în baza 16 al caracterului în cauză, precedat de „%” (de pil-dă, adresa www.infoiasi.ro/docs/Pagina Web.html va fi transformată în www.infoiasi.ro/docs/Pagina%20Web.html, ţinând cont că spaţiul are codul 32 în baza 10, adică 20 în baza 16).

Alte simboluri ce pot fi întâlnite în componenţa unui URL sunt:

• caracterul „#” (la finalul URL-ului) determină poziţionarea într-o anumită sec-ţiune a resursei. De exemplu:

http://www2002.org/CDROM/refereed/481/index.html#SunOne;

• caracterul „~” indică pagina personală a unui utilizator care posedă cont pe serverul precizat în URL (caracterul tilda semnifică directorul home al acestui utilizator pe o maşină Unix/Linux). De exemplu, http://www.infoiasi.ro/~busaco/teach/ va desemna pagina in-

dex.html stocată în directorul teach aflat în directorul Web al directorului home aparţinând utilizatorului cu numele busaco de pe maşina cu numele sim-bolic www.infoiasi.ro.

• caracterul „?” prefixează un şir denumit şir de interogare conţinând anumite in-formaţii transmise resursei accesate. De multe ori, URL-urile pot include refe-riri la resurse care nu reprezintă documente propriu-zise, ci programe (i.e., script-uri) executate de serverul Web. Aceste programe pot fi, de exemplu, script-uri CGI (Common Gateway Interface) având în mod uzual extensia .cgi, programe PHP cu extensia .php sau alte tipuri de aplicaţii executate pe server (i.e. servlet-uri Java, programe ASP.NET etc.). Şirul de interogare prefixat de „?” reprezintă tocmai datele de intrare transmise unui astfel de program. Ast-fel, pentru a căuta paginile Web conţinând cuvântul „Dali” vom putea scrie http://www.altavista.com/cgi-bin/query?pg=q&what=web&q=Dali, apelând la motorul de căutare Altavista. Acest şir de interogare nu poate conţi-ne caracterele ;, /, ?, :, @, &, =, +, , şi $, ele fiind codificate în baza 16 şi prefi-xate de simbolul %.

URL-urile pot fi utilizate, de asemenea, şi pentru accesarea fişierelor locale, aflate pe calculatorul pe care rulează şi navigatorul Web. În acest scop se va folosi schema file,

21


ca în exemplul următor: file:///C:/Temp (navigatorul va afişa conţinutul directorului Temp de pe discul C: al unui calculator rulând sub sistemul de operare Windows). Un URL similar, în cazul Unix (Linux), ar fi file:///tmp/.

De menţionat faptul că pot exista şi alte scheme URL nestandardizate, ca de exemplu man utilizată de navigatorul Nautilus pentru a accesa documentaţiile de sistem Linux pro-cesate în mod uzual de comanda man. Astfel, pentru a consulta paginile de manual ale shell-ulului bash, se poate folosi URL-ul man:bash, în locul comenzii man bash.

22


3. Protocolul HTTP pe scurt

Dată fiind importanţa protocolului HTTP, în continuare vom realiza o trecere în revistă a caracteristicilor sale importante.

Protocolul HTTP, standardizat de documentul RFC 2616, este folosit în special pentru hipertext, dar poate fi considerat drept protocol generic, baza comunicării într-un sistem distribuit de management al datelor, în cazul WWW fiind vorba în principal de facilitarea transferului de date între clienţii şi serverele Web. Fiind un protocol utilizat în Internet, HTTP se situează la nivelul de aplicaţii al stivei de protocoale TCP/IP (Transmission Con-trol Protocol/Internet Protocol), putând fi considerat fiabil (reliable).

Concepte fundamentale

Conceptele de bază sunt cererea şi răspunsul: un client Web trimite un mesaj (cererea) la un server. Mesajul conţine identificatorul resursei dorite, dat sub forma unui URI, metoda de acces folosită, versiunea protocolului, precum şi o serie de meta-informaţii care pot fi uti-le serverului. Răspunsul serverului cuprinde un cod indicând starea serverului după inter-pretarea cererii, un mesaj explicativ pentru codul de stare transmis, meta-informaţiile care vor fi procesate de către client şi, eventual, un conţinut (e.g., resursa solicitată).

În general, o sesiune de comunicare HTTP este iniţiată de către client şi constă din so-licitarea unei resurse (o pagină Web, uzual) identificate unic pe un server cunoscut. Aces-ta este numit şi server de origine datorită faptului că în comunicarea între client şi server pot să apară unul sau mai mulţi intermediari: proxy (numit şi server proxy), poartă (gateway) sau tunel (tunnel). Un proxy reprezintă un intermediar care retrimite un mesaj HTTP, eventual modificând o parte a sa. Poarta semnifică un intermediar care se poate situa înaintea unui server de origine şi să se identifice drept acesta, clientul Web necunoscând acest aspect. Tunelul este un intermediar care nu schimbă conţinutul mesajului, ci are rol exclusiv de retransmitere a lui; de exemplu, tunelul poate fi folosit pentru (de)criptarea mesajelor ve-hiculate între server şi client, în cadrul unui intranet/extranet.

Un alt concept important este cel de cache, desemnând un depozit local de stocare (în memorie, pe disc) a mesajelor (datelor) la nivel de server/client. Un proxy deţine obligato-riu un cache, denumit şi sistem de cache.

Un exemplu tipic de cerere-răspuns este următorul, în care cererea – formulată, intern, de un browser – are forma:

GET /catalog_produse.html HTTP/1.1 Host: www.portocale.info User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.5) Gec-ko/20060719 Firefox/1.5.0.5 Accept: text/html, image/gif, image/jpeg, */* Accept-Language: en-us Accept-Encoding: gzip, deflate, compress, identity Connection: Keep-Alive

23


Un posibil răspuns – obţinut din partea serverului Web – ar putea fi următorul (am omis conţinutul propriu-zis al documentului solicitat):

Date Tue, 22 Aug 2006 07:17:13 GMT : Server: Apache/2.0.54 (Win32) PHP/5.0.4 Accept-Ranges: bytes Content-Length: 201 Keep-Alive: timeout=15, max=74 Connection: Keep-Alive Content-Type: text/html; charset=ISO-8859-1 ...

Maniera de codificare a conţinutului

Pentru ca datele să fie corect interpretate de toate entităţile participante la conversaţia prin reţea, indiferent de platforma hardware şi software, ele trebuie să respecte aceeaşi codificare.

Astfel, se defineşte conceptul de set de caractere, pentru a putea interpreta corect datele schimbate via protocolul HTTP între două platforme diferite (e.g., un server rulând pe un sistem Linux cu un navigator Web de pe un dispozitiv mobil), având reprezentări diferite ale datelor. Informaţia e transmisă sub forma unui şir de caractere urmând ca entitatea de la celălalt capăt, folosind indicaţiile despre setul de caractere, să realizeze transformarea din şir de octeţi în şir de caractere. Setul de caractere implicit este ISO-8859-1, dar există o multitudine de alte seturi (de exemplu, ISO-8859-2 denumit şi Latin-2, care oferă prin-tre altele şi reprezentarea diacriticelor din limba română).

Protocolul HTTP respectă seturile de caractere definite de specificaţiile MIME (Multipurpose Internet Mail Extensions) descrise în documentele RFC 2045 şi 2046. Conform standardului MIME, pentru fiecare resursă în parte se specifică tipul şi subtipul acesteia. De exemplu, text/html pentru un document HTML, text/plain în cazul unui document text neformatat, image/png pentru o imagine în format PNG, application/soap+xml pentru mesajele SOAP etc.

De asemenea, mesajele pot fi codificate prin diverse metode precum gzip ori compress, în vederea comprimării sau asigurării identităţii şi/sau integrităţii.

Mesajele HTTP

Cererile şi răspunsurile HTTP sunt vehiculate prin intermediul mesajelor. Astfel, mesajele HTTP sunt considerate de două tipuri: cerere provenită de la un client către un server şi răspuns al serverului, trimis la acel client. Un mesaj e compus dintr-o succesiune de linii de text, delimitate de caracterele CRLF (Carriage Return şi Line Feed). Prima linie semnifică o cerere efectuată de un client sau un cod de stare obţinut de la server, urmată de un nu-măr de atribute de antet.

Un antet (header) conţine mai multe atribute care sunt folosite la completarea unei ce-reri sau a unui răspuns cu meta-informaţia necesară interpretării corecte a mesajului prin stabilirea unor valori specificate de către protocolul HTTP sau a unor protocoale definite

24


de utilizator (de exemplu, SOAP). Un atribut este furnizat printr-un nume urmat de „:” şi de o valoare (opţională, în unele cazuri).

O cerere este specificată de o metodă de acces, cele mai folosite fiind descrise în conti-nuare.

Metoda GET reprezintă o cerere de accesare a unor informaţii (reprezentări de resur-se). Un client HTTP (navigator, robot, program de descărcare, agregator de ştiri, player multimedia etc.) foloseşte metoda GET pentru a obţine o anumită resursă, fie că ea re-prezintă un fişier (document text, HTML, imagine PNG sau JPEG, aplicaţie, arhivă, do-cument XML etc.), fie că indică execuţia pe serverul Web a unui proces care va produce datele dorite (e.g., invocarea unui script CGI sau a unui program PHP);

HEAD este similară cu metoda GET, dar serverul va întoarce un mesaj având infor-maţii doar în antet. Meta-datele din anteturile HTTP din răspunsul la o cerere HEAD vor fi identice cu cele din răspunsul la o cerere GET. Utilitatea acestei metode constă în obţi-nerea meta-datelor asociate unei resurse Web fără a transfera efectiv întreaga entitate, în vederea – de exemplu – a testării existenţei resursei, a obţinerii datei ultimei modificări sau furnizarea drepturilor de acces;

Metoda POST este utilizată pentru a identifica dacă serverul acceptă o entitate îngloba-tă în cadrul cererii. POST este proiectată să implementeze o metodă uniformă pentru funcţii precum adnotarea resurselor, trimiterea datelor unui formular Web către server, extinderea unei baze de date printr-o operaţiune de inserare, invocarea unui serviciu etc.

În cadrul unei cereri, pot fi specificate diverse atribute, utilizate pentru a transmite ser-verului informaţii suplimentare privitoare la acea cerere şi la client. Se poate face o analo-gie între trimiterea unei metode HTTP cu apelul unei funcţii dintr-un limbaj de progra-mare, unde atributele reprezintă parametrii de intrare.

După primirea şi interpretarea unui mesaj de tip cerere şi interpretarea lui, un server HTTP răspunde cu un mesaj denumit răspuns. Prima linie conţine versiunea protocolului HTTP implementat de către server şi continuă cu un cod de stare reprezentând un numă-rul asociat de către specificaţia HTTP unei anumite situaţii a serverului în urma tratării unei cereri. Urmează un text explicativ pentru codul de stare, menit să clarifice situaţia exprimată de codul de stare.

Codul de stare este format din trei cifre organizate în categorii de stări; codurile din ace-eaşi categorie se referă la stări similare.

Ele se disting după prima cifră în modul de mai jos.

Codurile de informare (1xx) furnizează informaţii privitoare la o anumită acţiune (cererea a fost primită, comunicaţia continuă). De exemplu: 100 Continue (clientul poate continua cererea, trebuind să trimită următoarea parte a unui mesaj parţial).

Codurile de succes (2xx) raportează efectuarea cu succes a unei operaţiuni (cererea a fost primită, interpretată şi acceptată de către server). Un cod tipic din această categorie este

25


200 OK (cererea a fost rezolvată cu succes). Alt exemplu este 204 No Content (serverul a rezolvat cererea, dar nu are ce returna clientului).

Codurile de redirecţionare (3xx) indică o redirecţionare a cererii spre altă locaţie ori alt ser-ver. Drept exemple, menţionăm codurile 301 Moved Permanently (resursa solicitată a fost asociată unui URI nou şi orice referinţă viitoare la ea trebuie să se realizeze prin acest URI furnizat) şi 302 Moved Temporarily (resursa cerută are asociat un alt URI, dar pentru o perioadă temporară).

Codurile de eroare provocate de client (4xx) specifică apariţia unei erori pe partea clientului (fie cererea este incorectă din punct de vedere sintactic, fie nu poate fi satisfăcută din varii motive). Ca exemple, furnizăm 401 Unauthorized (cererea necesită autentificarea utilizato-rului – e.g., via unui nume de cont urmat de o parolă) şi 403 Forbidden (serverul a recepţio-nat o cerere corectă, dar refuză să o satisfacă din diverse motive legate de restricţionarea accesului). Un alt cod tipic, des întâlnit, este 404 Not found (serverul nu găseşte resursa specificată).

Codurile de eroare generate de server (5xx) desemnează coduri semnificând o eroare pe par-tea serverului (cererea este aparent corectă, dar serverul nu o poate îndeplini din anumite motive). Ca exemplificare, menţionăm 503 Service Unavailable (serverul Web nu poate sa-tisface cererea – e.g., din cauza supraîncărcării temporare sau din raţiuni de administrare).

26


4. Privire de ansamblu

Din cele ce am văzut mai sus, spaţiul World-Wide Web funcţionează în practică datorită:

• unei scheme consistente de identificare a resurselor, prin intermediul identificatori-lor universali de resurse (URI);

• unui mecanism flexibil de transfer de date, reprezentat de protocolul HTTP; • unei descrieri logice a structurii documentelor hipertext, prin intermediul limbajelor

de adnotare (marcare) HTML şi XHTML.

Web-ul poate fi considerat un veritabil sistem hipermedia distribuit, utilizând ca infrastruc-tură Internet-ul. De asemenea, Web-ul poate fi privit ca un mediu eterogen pentru dez-voltarea şi exploatarea de sisteme distribuite menite a manipula componente multimedia.

Interacţiunile dintre server, client şi utilizator din prisma unei aplicaţii Web

Iniţial, spaţiul WWW era compus din pagini (documente) statice – incluzând text şi imagini, apoi elemente multimedia –, interconectate prin intermediul legăturilor hipertext. Aplicaţii de tip client (precum navigatoarele Web) erau folosite pentru accesarea – via adrese (URI) – a reprezentării acestor resurse, stocate pe servere Web. Programe supli-mentare (plug-in-uri), incluse în navigatoarele Web, erau menite să redea tipuri de conţinu-turi nestandardizate, ca fişiere Word, PostScript, PDF (Portable Document Format), Flash etc. Pentru a oferi conţinut dinamic utilizatorilor, sunt adoptate diverse modalităţi pro-gramatice, reprezentate pe partea de server de programe CGI (Common Gateway Interface), servere de aplicaţii precum PHP (PHP: Hypertext Processor), JSP (Java Server Pages), ASP (Active Server Pages) sau ASP.NET, iar pe partea de client de programe JavaScript sau applet-uri Java.

De remarcat faptul că o serie de elemente programabile funcţionează drept componen-te middleware (generând de fapt o arhitectură 3-tier ori N-tier), reprezentând interfeţe pen-tru accesarea unor servicii aflate la distanţă (e.g.: sisteme relaţionale de baze de date).

27


Unul dintre paşii importanţi ai evoluţiei spaţiului WWW îl reprezintă serviciile Web baza-te pe meta-limbajul XML (Extensible Markup Language). Serviciile Web permit ca elemente programabile să fie plasate pe siturile Web, alţi programatori/aplicaţii putând accesa func-ţionalităţile acestor programe, în manieră distribuită şi directă, pentru orice potenţial nu-măr de sisteme independente, prin folosirea unor standarde precum XML şi HTTP.

Calculatoarele sunt şi vor fi incluse în diferite tipuri de dispozitive, pe diverse scale, precum telefoane celulare, palmtop-uri, notebook-uri, laptop-uri şi alte viitoare dispozitive portabile. Aceasta implică adoptarea unor noi mijloace de interacţiune şi comunicare atât între maşini, cât şi între calculatoare şi utilizatori, cercetările concentrându-se în prezent pe studierea comunicaţiilor fără fir (wireless), în medii distribuite precum Web-ul, folosindu-se diverse paradigme (peer-to-peer, sisteme de agenţi etc.).

Identificatorii uniformi de resurse, protocolul HTTP şi limbajul (X)HTML au reuşit să îndeplinească practic scopurile principale ale Web-ului:

independenţa de dispozitiv (aceleaşi informaţii pot fi accesate via o multitudine de dis-pozitive ca mainframe-urile, calculatoarele personale, dispozitivele mobile etc.),

independenţa de software (forme diferite de software – clienţi (navigatoare, roboţi Web etc.) şi servere Web – oferă şi extrag informaţii într-o manieră universală, fără ca nici un produs-program să reprezinte o componentă critică pentru spaţiul WWW, deoarece Web-ul nu reprezintă un program, ci un set de protocoale şi specificaţii standardizate, deschise, redactate de Consorţiul Web),

scalabilitatea (dezvoltarea exponenţială a Web-ului este un exemplu interesant al efortului uman depus de comunitatea utilizatorilor Internet-ului, independent de resursele hardware şi software disponibile),

multimedia (documentele, regăsite şi sub denumirea de pagini, disponibile pe Web pot integra surse de informaţie multiple, în diverse forme, de la date discrete – text, imagini statice precum fotografii, scheme, diagrame etc. – până la cele conti-nue – animaţii, audio şi video).

Drept concluzie finală, Consorţiul Web – forţa motrice din spatele XML-ului – consi-deră că misiunea sa este aceea de a conduce evoluţia Web-ului. Deşi a împărtăşit mai multe idei comune Internetului – precum „software-ul gratuit se răspândeşte mai repede”, „sis-temele ASCII proliferează mai rapid decât cele binare” şi „protocoalele proaste imită; protocoalele bune fură” – a impus o strategie inovatoare: „autodescrierea”. Web-ul poate fi construit peste el însuşi. Identificatorii universali de resurse, formatele de date uşor de proce-sat de către maşină şi specificaţiile capabile de a fi interpretate de calculatoare pot fi îm-pletite într-un sistem extensibil care asimilează orice concurenţă. În esenţă, apariţia limba-jului XML în spectrul formatelor de date pentru Web pune capăt luptei asupra structură-rii documentelor în vederea realizării viziunii originare a creatorilor Web-ului. La ora ac-tuală, XML reprezintă unica modalitate existentă pentru adnotarea complexă a datelor.

28


29

PPaarrtteeaa IIII –– FFaammiilliiaa ddee lliimmbbaajjee XXMMLL

„Esenţialul în lumânare nu este ceara ce lasă urma, ci lumina.” Antoine de Saint-Exupéry

1. Preambul 2. Caracterizare şi trăsături esenţiale 3. Părţile componente ale unui document XML 4. Membrii constituenţi ai familiei XML 5. Spaţiile de nume XML 6. Validarea documentelor XML 7. Procesarea documentelor XML 8. Transformări XML


30


1. Preambul

Pentru identificarea resurselor Web-ul recurge la identificatori uniformi de resurse (URI – Uniform Resource Identifiers), iar pentru interacţiune se foloseşte în mod uzual protocolul HTTP. Reprezentarea resurselor se realizează via formate de date. Arhitectura spaţiului WWW încurajează refolosirea formatelor existente, printre aspectele importante legate de acest aspect putându-se enumera: adoptarea formatelor textuale în contrast cu cele bina-re, controlul versiunilor, extensibilitatea, compunerea formatelor, separarea conţinutului, prezentării şi interacţiunii.

Cu proliferarea serviciilor Internet, mai ales ale Web-ului, datele au putut fi publicate liber, folosindu-se un format de redare (prezentare) a informaţiilor pus la dispoziţie de bine-cunoscutul HTML (HyperText Markup Language), în varianta actuală XHTML (Extensible HTML). În prezent, atenţia cade asupra modelării cât mai eficiente a informa-ţiilor, prin intermediul unui format deschis, extensibil – subiectul acestui capitol. Mai mult decât atât, modelarea datelor nu reflectă doar sintaxa (care e specificată printr-un set de convenţii de marcare), ci şi semantica – până acum, reprezentată de codul-sursă al programelor ce prelucrau acele date.

Dacă formatele de date transpun maniera efectivă de stocare şi prezentare a informaţii-lor, la nivel conceptual trebuie adoptat cel puţin un model de reprezentare. Evoluţia in-frastructurilor de calcul a condus şi la adoptarea unor modele de date diferite. Prezentul are la bază arhitecturile navigaţionale, bazate pe hipertext (text neliniar), utilizate de o ple-iadă de dispozitive, inclusiv cele mobile. Se consideră că unul dintre modelele de date cele mai potrivite este cel oferit de familia de limbaje XML.

Ca şi SGML (Standard Generalized Markup Language), din care provine, XML (Extensible Markup Language) reprezintă un standard internaţional pentru descrierea de marcaje (markups) ale textelor electronice disponibile pe Web. În fapt, XML reprezintă un meta-limbaj, o descriere formală a unui limbaj, în acest caz, un limbaj de adnotare (de marcare) a datelor. Specificaţiile XML au fost dezvoltate începând cu 1996 în cadrul Con-sorţiului Web, de un grup de cercetare condus de Jon Bosak de la Sun Microsystems, la care au aderat ulterior o serie de grupuri de experţi din comunităţile academice (Text Encoding Initiative, NCSA, James Clark) şi industriale (Sun, IBM, Netscape, Oracle, Adobe etc.). Specificaţiile XML sunt standardizate de către Consorţiul Web – vezi http://www.w3.org/TR/xml.

31


2. Caracterizare şi trăsături esenţiale

Putem considera XML ca reprezentând un standard internaţional pentru descrierea de marcaje (markups) privitoare la resursele electronice. În fapt, XML reprezintă un meta-limbaj (descriere formală a unui limbaj, conform unei gramatici – suită de reguli prin care, pe baza unor simboluri, se generează cuvinte). La început, a fost văzut ca un limbaj de adnotare (de formatare) de texte, dar scopurile actuale depăşesc această interpretare în-gustă.

Termenul marcaj (markup) a fost utilizat iniţial pentru a descrie anumite adnotări, note marginale în cadrul unui text cu intenţia de a indica tehnoredactorului cum trebuie listat un anumit pasaj ori chiar omis. Cum formatarea şi imprimarea textelor au fost automati-zate, termenul s-a extins pentru a acoperi toate tipurile de coduri de marcare inserate în textele electronice cu scopul de a indica modul de formatare, listare ori alte acţiuni.

Marcajul (codarea) reprezintă, astfel, o acţiune de interpretare explicită a unui fragment de dată. Astfel, un limbaj de specificare oferă un set de convenţii de marcare uti-lizate pentru codificarea textelor. Un limbaj de marcare trebuie să desemneze mulţimea de marcaje obligatorii, permise, maniera de identificare a marcajelor şi care este semantica fiecărui marcaj disponibil (similar procesului de specificare a sintaxei şi semanticii unui limbaj de programare).

Există următoarele caracteristici definitorii ale XML, primele trei preluate de la SGML: utilizarea marcajelor descriptive (descriptive markups), adoptarea tipurilor de documente via DTD (Document Type Definition), independenţa datelor şi caracterul case-sensitive (majuscule-le diferă de minuscule).

Printre trăsăturile care au făcut meta-limbajul XML să fie folosit în industria software putem enumera: suportul acordat Web-ului, facilităţile pentru utilizarea internaţională, meta-limbajul (se permite definirea de noi limbaje, într-o manieră portabilă), soluţie pen-tru reprezentarea conţinutului resurselor Web identificate via URI.

Aşadar, XML este o metodă de descriere universală a informaţiei astfel încât atât com-puterele, cât mai ales oamenii să o poată înţelege. Scopurile limbajului sunt cele legate de utilizarea lui în Internet, suportând o varietate de aplicaţii, dar fiind mult mai flexibil decât HTML. Oferind o manieră universală pentru reprezentarea (descrierea) informaţiilor hi-pertext, XML poate fi văzut ca o tehnologie complementară limbajului HTML, nu ca o înlocuire a sa.

Un prim exemplu: dacă am considera un fragment de document HTML utilizat pentru a stoca informaţii dintr-o listă privitoare la colegii de grupă, acesta ar putea avea forma:

<p>Coleg:</p>

<p>Nume: <b>Ştefan Ciprian Tanasă</b></p>

<p>Adresa: <i>Str. Berthelot, 16 - Iaşi</i></p>

32


<p>Telefon: 032-201090</p>

<p>E-mail: <tt>[email protected]</tt></p>

Din perspectiva unui calculator (a unei aplicaţii de prelucrare a acestor informaţii), nu există nici o indicaţie asupra faptului că informaţia ar fi structurată. În schimb, conside-rând aceeaşi informaţie reprezentată prin XML, fragmentul de document ar putea fi:

<coleg>

<nume>Ştefan Ciprian Tanasă</nume>

<adresa>Str. Berthelot, 16 - Iaşi</adresa>

<telefon>032-201090</telefon>

<email>[email protected]</email>

</coleg>

Dacă fragmentul de document HTML de mai sus indică mai mult modalităţile de afişa-re a datelor (forma), documentul XML descrie structura datelor (putem afirma că este vorba de un coleg, pentru el memorând numele şi diverse maniere de contact). Cunos-când structura datelor, se pot executa diferite operaţii asupra acestora (e.g. afişarea doar a numelor colegilor, trimiterea de felicitări tuturor colegilor din Iaşi, generarea unui tabel conţinând numerele de telefon etc.).

1. Subset simplificat al SGML

– foarte puternic, dar uşor de implementat

– fără limite în ceea ce priveşte complexitatea structurilor care pot fi de-finite

– îndeajuns de compact pentru a fi suportat de navigatoarele Web

2. Oferă suport pentru utilizare la nivel internaţional

– marcajele şi conţinutul pot fi reprezentate în Unicode

– instrumentele de dezvoltare XML pot suporta orice codificări

3. Meta-limbaj

– conceput pentru a suporta definirea unui număr nelimitat de limbaje specializate, oferind suport de extinderi

– portabilitate

Trăsături definitorii ale meta-limbajului XML

33

3. Părţile componente ale unui document XML

Un document XML poate cuprinde următoarele categorii de constituenţi:, declaraţia, elementele, atributele, entităţile, secţiunile de marcare, instrucţiunile de procesare.

Documentele XML pot să înceapă cu o declaraţie (numită şi prolog) XML care specifi-că versiunea limbajului XML utilizat – de exemplu: <?xml version="1.0"

encoding="UTF-8" ?> (de asemenea, s-a precizat şi tipul de codificare a setului de ca-ractere folosit).

Componenta structurală a unui document XML este elementul.

Diferite tipuri de elemente au asociate nume diferite. Fiecare element trebuie specificat explicit prin intermediul marcajelor (tag-urilor). Perechea marcaj de început (start tag) – marcaj de sfârşit (end tag) este folosită la încadrarea fiecărei instanţe a elementului respec-tiv în cadrul unui text. În XML, se utilizează <element> pentru a specifica un tag de în-ceput şi </element> pentru cel de sfârşit, unde element este numele unui element oare-care (specificat de utilizator ori de autoritatea care a redactat specificaţiile limbajului bazat pe XML folosit).

Regulile sintactice privitoare la numele de elemente sunt similare celor privitoare la identificatorii de variabile. Numele începând cu caracterele „xml” (în orice modalitate de scriere, cu majuscule sau minuscule) sunt rezervate. Numele de element nu poate conţine spaţii albe.

Un element poate fi vid (nu conţine nimic între tag-urile de început şi sfârşit), putând fi scris fie <element></element>, fie prin forma prescurtată <element />. De asemenea, poate include un text (şir de caractere) ori alte elemente. Mai multe elemente de acelaşi tip pot fi, aşadar, imbricate. Un aspect deosebit de important este cel privitor la faptul că elementele trebuie să fie închise şi imbricate corect.

Conţinutul textual al unui element poate fi compus din caracterele permise de codifica-rea precizată de atributul encoding din declaraţia XML, orice apariţie de spaţii albe multiple fiind implicit redusă la un singur caracter spaţiu.

Pentru a ilustra mai detaliat acest aspect, considerăm un model structural foarte simplu. Presupunem că dorim să identificăm o comandă de portocale ce va fi procesată de un sit de comerţ electronic. Astfel avem:

<portocale>  <achizitii> <tip>Portocale greceşti fără coajă</tip> <cod>P10-01-GR</cod> <cantit um="kg">3374</cantit> </achizitii>  <vanzari>

34


<tip>Portocale japoneze albastre</tip> <cod>P10-03-JP</cod> <cantit um="kg">0107</cantit> </vanzari> </portocale>

Exemplul de mai sus nu ne precizează anumite reguli de compunere a comenzii (de exemplu, nu putem impune ca tipul produsului solicitat să nu apară de mai multe ori). Aşadar, vom avem nevoie de un mecanism de precizare a structurii.

Un atribut este utilizat cu scopul de a descrie o anumită proprietate a unei apari-ţii specifice (particulare) a unui element.

Atributele sunt localizate în tag-ul de start al unui element, imediat după numele ele-mentului, sunt urmate de „=”, apoi de valoarea atributului, scrisă între ghilimele sau apos-trofuri. Dacă valoarea unui atribut nu este specificată între ghilimele va fi semnalată o eroare, la fel ca şi în cazul în care pentru un atribut nu ar fi ataşată şi valoarea acestuia. Pentru un element pot exista oricâte atribute, specificate în orice ordine, atât timp cât sunt declarate corect.

Pentru exemplul dat mai sus, am specificat unitatea de măsură „kilogram” prin valoa-rea „kg” a atributului um asociat elementului <cantit>.

Referinţele la entităţi constituie de fapt pointeri către entităţi. În XML, entităţile repre-zintă unităţi de text, unde o astfel de unitate poate desemna orice, de la un singur caracter la un întreg document sau chiar o referinţă la un alt document. O referinţă la o entitate prezintă construcţia sintactică &nume_entitate; (caracterul „&”, urmat de numele enti-tăţii, apoi de caracterul „;”). Una dintre cele mai frecvente utilizări ale referinţelor la enti-tăţi este atunci când se doreşte folosirea unor caractere care ar conduce la erori de proce-sare şi deci care nu ar trebui să apară în forma lor normală în text (de exemplu, pentru a genera simbolul „<” vom folosi „<”). În momentul în care se întâlneşte referinţa la o entitate în document, aceasta se va substitui cu datele pe care le referă şi se va returna documentul cu înlocuirile făcute.

Ocazional, anumite părţi ale documentului necesită un tratament special în ceea ce pri-veşte modul de procesare. Astfel, există posibilitatea folosirii secţiunii CDATA (character data), cu rolul de inhibare a prelucrării construcţiilor XML. Secţiunile CDATA pot fi inse-rate oriunde pot apărea şi datele de tip caracter. Ele sunt utilizate pentru a include blocuri de text conţinând caractere care altfel ar fi recunoscute ca marcaje. Acest aspect devine important atunci când documentul include, de exemplu, linii de cod-sursă scrise într-un limbaj de programare care are propriile convenţii sintactice.

Sintaxa generală a secţiunii CDATA are forma <![CDATA[ ... ]]>. Secţiunile CDATA nu pot fi incluse unele în altele.

35


Un exemplu este următorul:

<achizitii> <tip>Portocale greceşti fără coajă</tip> <obs><![CDATA[ Cantitatea trebuie să fie >2000. ]]></obs> </achizitii>

Instrucţiunile de procesare reprezintă un tip special de marcaj care conţine informaţii privitoare anumite aplicaţii ce urmează a fi executate pentru procesarea conţinutului. Un exemplu este instrucţiunea de procesare care permite ataşarea de foi de stiluri documen-telor XML în vederea redării conţinutului acestora:

<?xml-stylesheet href="xml2html.xsl" type="text/xsl" ?>

36


4. Membrii constituenţi ai familiei XML

Limbajul XML oferă mai mult decât o sintaxă comodă pentru reprezentarea datelor structurate sau semi-structurate. XML consistă dintr-o familie de limbaje bazate pe XML pentru reprezentarea datelor şi relaţiilor dintre ele.

Această familie de limbaje, menite a adapta conceptele curente de stocare, modelare şi publicare pe Web a datelor, este compusă din:

• XML (Extensible Markup Language) – subset al specificaţiei SGML, conceput pen-tru o implementare mai uşoară. Modalităţile de validare sunt concretizate, uzual, de schemele XML, complementare DTD-urilor;

• XLL (Extensible Linking Language) – oferind suport pentru specificarea de legături hipertext, concretizat în două componente majore:

– XLink – conceput pentru descrierea legăturilor (simple sau multiple) din-tre resursele Web;

– XPointer – are ca scop precizarea în manieră extensibilă a unor scheme de adresare a datelor XML;

• XSL (Extensible Stylesheet Language) – permite transformarea documentelor XML în alte tipuri de documente (XML, XHTML sau altele) şi ataşarea unor obiecte de formatare, în vederea redării conţinutului XML în formate precum PDF (Portable Document Format);

• XQuery – împreună cu limbajul XPath, oferă posibilitatea interogării documente-lor XML.

Pentru alte detalii, puteţi consulta lucrarea S. Buraga, Tehnologii XML, Polirom, Iaşi, 2006.

Intuitiv, structura unui document XML complex poate fi mult mai uşor înţeleasă având asociată o reprezentare grafică arborescentă – a se vedea figura de mai jos.

Reprezentarea arborescentă a unui document XML

37


De asemenea, există o multitudine de aplicaţii bazate pe XML, dintre care se pot enu-mera limbaje pentru:

• reprezentarea expresiilor matematice (MathML),

• descrierea resurselor Internet (RDF – Resource Description Framework) – baza pentru Web-ul semantic,

• crearea de ilustraţii (conţinuturi grafice) vectoriale (SVG – Scalable Vector Graphics);

• realizarea de prezentări multimedia sincronizate (SMIL – Synchronized Multimedia Integration Language),

• reprezentarea şi interschimbarea informaţiilor referitoare la afaceri pe Web (BRML – Business Rules Markup Language),

• transferul de date în medii mobile (WML – Wireless Markup Language),

• descrierea serviciilor Web (WSDL – Web Services Description Language).

Practic, este imposibil de enumerat toate limbajele bazate pe XML existente la ora ac-tuală, standardizate sau nu. Numeroase limbaje utile, în număr de peste 500, sunt descrise la adresa http://xml.coverpages.org/.

În ceea ce priveşte tipurile de instrumente XML, pot fi amintite următoarele categorii: – analizoare (procesoare, parsers) XML – e.g., Expat, libxml, MSXML,

Xerces;

– vizualizatoare şi editoare structurale – Firefox, Open Office, oXygen, Stylus, XML Spy, XMLStarlet şi multe altele;

– formatatoare – FOP, Saxon, Xalan, XEP etc.;

– instrumente de convertire/arhivare – e.g., Open SP, Tidy, XMill;

– sisteme de gestiune a bazelor de date orientate-text (native XML sau doar oferind suport pentru XML) – dbXML, eXist, Mark Logic’s CIS, Xindice etc.;

– aplicaţii hipertext – Annotea, Hyperwave;

– biblioteci/sisteme de procesare a meta-datelor – Carp and Spiral, Dri-ve.NET, Jena, Redland şi altele;

– instrumente de modelare conceptuală – pOWL, Protégé, SWOOP etc.;

– aplicaţii din domeniul social (blog-uri, portaluri, wiki-uri, adnotatoare de conţinut, managere de notiţe şi adrese personale etc.) – Connotea, del.icio.us, Furl, Spurl.net etc.

38

Exemple

Documentele XML pot stoca informaţii structurate sau semi-structurate care ulterior se pot prelucra într-o manieră comodă.

Astfel, o bază de date simplă poate fi memorată ca fişier XML astfel (desigur, această abordare nu este unică):

<tabela>

<inregistrare id="0001">

<camp1 tip="numar">valoarea 1-1</camp1>

<camp2 tip="caracter">valoarea 1-2</camp2>



</inregistrare>

<inregistrare id="0002">

<camp1 tip="numar">valoarea 2-1</camp1>

<camp2 tip="caracter">valoarea 2-2</camp2>

</inregistrare>



</tabela>

La fel, documentele XML pot fi utilizate cu succes ca fişiere de configuraţie pentru di-verse aplicaţii:

<config logdir="/var/log/app/"

debugfile="/tmp/app.debug">

<server name="odin" osname="solaris"

osversion="2.6">

<address>193.30.121.101</address>

</server>

<server name="fenrir" osname="linux"

osversion="2.4.2">


</server>

<server name="thor" osname="linux"

osversion="2.4.2">



</server>

</config>

Un alt exemplu priveşte stocarea informaţiilor referitoare la cuprinsul unei cărţi:

<?xml version="1.0" ?>



<?xml-stylesheet href="cuprins.xsl" type="text/xsl" ?>

39


<cuprins titlu="Situri Web la cheie. Solutii profesionale de imple-

mentare" editura="Polirom" an="2004">

<capitol>

<nume>Prefata</nume>

<autor>Sabin Buraga</autor>

</capitol>

<capitol>

<nume>Portaluri educationale</nume>

<autor>Bogdan Manolache</autor>

<descriere>Capitolul de fata incepe cu o prezentare generala a

portalurilor, urmata de o incursiune in lumea portalurilor

educationale.</descriere>

</capitol>

<capitol>

<nume>Modelarea si reprezentarea relatiilor intre tabele</nume>

<autor>Sorin Bahmata</autor>

<descriere>Aplicatia DataR reprezinta un sit Web dezvoltat in

limbajul PHP ce ofera posibilitatea de a modela si reprezenta

metadatele asociate structurii bazelor de date relationale (mai

exact, a bazelor de date MySQL), aici incluzand si detalii despre

relatiile intre tabele.</descriere>

</capitol>

<capitol>

<nume>FindMyHome, solutie e-business in domeniul imobiliar</nume>

<autor>Viorel Atofani</autor>

<descriere>Capitolul de fata prezinta o privire de ansamblu asu-

pra unei idei de afaceri on-line, prin detalierea unei solutii prac-

tice de e-business, reprezentata de un portal Web in domeniul imobi-

liar.</descriere>

</capitol>

</cuprins>

40

5. Spaţiile de nume XML

În unele situaţii pot apărea confuzii, atunci când se folosesc date provenite din diverse surse (documente) XML care pot avea elemente/atribute cu acelaşi nume, dar cu semni-ficaţii (semantici) diferite. Pentru evitarea acestor ambiguităţi sunt folosite spaţiile de nu-me, astfel încât numele de elemente şi/sau atribute vor fi identificate în mod unic, evitându-se conflictele.

Necesitatea folosirii spaţiilor de nume se poate remarca din exemplul următor, în care considerăm două documente XML, primul cu informaţii despre partenerii de afaceri, al doilea despre numele furnizorilor de portocale:

 <parteneri> <partener> <nume>Portocal Escu</nume> <adresa>Aleea Zăpezilor, 33</adresa> </partener> ... </parteneri>  <furnizori> <furnizor adresa="http://ja.po.ro/"> <nume>Japo Nez S.A.</nume> </furnizor> ... </furnizori>

Documentul care le utilizează pe precedentele şi foloseşte spaţii de nume pentru evita-rea ambiguităţilor („nume reprezintă un nume de persoană sau un nume de companie?”; idem pentru adresă) ar putea fi următorul:

<comanda xmlns:p="http://www.undeva.ro/parteneri/"> <partener> <p:nume>Portocal Escu</p:nume> <p:adresa>Aleea Zăpezilor, 33</p:adresa> </partener> <f:furnizor xmlns:f="urn:furnizori.info" f:adresa="http://ja.po.ro/"> <nume>Japo Nez S.A.</nume> </f:furnizor> </comanda>

Atributul xmlns este folosit pentru declararea spaţiilor de nume, iar valoarea lui trebuie să fie un URI, fie localizând o resursă prin adresa ei – cazul URL (Uniform Resource Loca-tor), fie desemnând un nume unic asociat resursei în cauză – facilitate oferită de URN (Uniform Resource Name).

Prin intermediul construcţiei xmlns, se asociază un vocabular, denumit şi spaţiu de nume (namespace), pentru elementele în cauză.

41


În cele ce urmează, vom furniza un exemplu complet, în care se vor folosi mai multe vocabulare, fiecare desemnat de un spaţiu de nume XML. Documentul serveşte pentru stocarea rezultatelor unui chestionar anonim privitor la desfăşurarea unui curs (se poate observa şi utilizarea referinţelor la entităţi, plus a atributelor speciale xml:id şi xml:lang).

<feedback xmlns="urn:infoiasi.ro:busaco:feedbacks" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" type="results" xml:id="feedback1-2005" version="0.1"> <meta> <author uri="http://www.infoiasi.ro/~busaco/"> Sabin-Corneliu Buraga</author> </meta> <issue xml:id="i2"> <question xml:lang="ro"> Care dintre aspectele propuse spre expunere vă stârnesc cel mai mult interesul? </question> <response xml:lang="ro"> <rdf:Seq> <rdf:li>Baze de date native XML & XQuery</rdf:li> <rdf:li>Cookie-uri & sesiuni</rdf:li> </rdf:Seq> </response> </issue> <issue xml:id="i3"> <question xml:lang="ro"> Ce alte subiecte aţi dori să fie prezentate? </question> <response xml:lang="ro"> <rdf:Seq> <rdf:li>Tehnologii WAP</rdf:li> <rdf:li>Animaţii pentru Web</rdf:li> <rdf:li>E-business</rdf:li> </rdf:Seq> </response> </issue> </feedback>

42


6. Validarea documentelor XML

Punerea problemei

O primă necesitate în cazul adoptării tehnologiei XML este aceea ca informaţiile marcate în XML să poată fi regăsite, reutilizate şi partajate între diverse aplicaţii. Astfel, o cerinţă importantă este de a cunoaşte:

– setul de elemente/atribute ce pot fi specificate;

– modul lor de structurare (e.g., ordinea, numărul minim/maxim de apariţii, contex-tul etc.);

– tipul conţinutului (de exemplu, cantitatea de portocale să reprezinte un număr na-tural, aparţinând intervalului [0, 7433]);

– ce anume este valid şi ce reprezintă eroare.

Soluţia este aceea ca un grup sau grupuri de indivizi (precum o companie, o industrie, persoane, producători de instrumente software specifice sau un consorţiu) să specifice mulţimea de elemente şi atribute permise şi regulile de marcare, adică tocmai modelul structural amintit mai sus.

Modelul structural se aplică unei clase de documente XML, în vederea verificării via un analizor (numit şi procesor sau parser) a corectitudinii instanţelor de documente apar-ţinând acelei clase. Se au în vedere aspecte privind:

– modul de numire a elementelor/atributelor;

– definirea regulilor de utilizare a acestora;

– specificarea structurii şi conţinutului;

– precizarea anumitor constrângeri;

– oferirea unui set de convenţii de numire.

Apare, aşadar, necesitatea specificării unui set de constrângeri asociate documentelor, astfel încât datele XML să fie verificate dacă sunt valide sau nu din punct de vedere struc-tural sau al tipului conţinutului.

Modalităţile de precizare a constrângerilor se pot baza pe: descrieri (DTD şi XML Schema), reguli (Sablotron) şi şabloane (RELAX NG) – detalii în cartea Sabin Buraga, Teh-nologii XML, Polirom, Iaşi, 2006.

43


Declaraţia tipului de document. Validări via DTD

Declaraţia tipului de document reprezintă un marcaj special care poate fi inclus în documente-le XML cu rolul de a specifica existenţa şi locaţia definiţiei tipului de document (DTD –Document Type Definition). Declaraţia tipului de document şi definiţia tipului de document sunt noţiuni diferite. DTD-ul însumează un set de reguli formale care definesc structura unui document XML, spre deosebire de declaraţia tipului de document care are rolul de a indica analizorului ce DTD trebuie să folosească pentru verificare şi validare. DTD-urile sunt o reminiscenţă a SGML-ului şi în prezent tind a fi înlocuite de schemele XML.

Pentru a putea fi procesate, documentele XML trebuie să fie măcar documente bine formatate.

Documentele bine formatate sunt documentele corecte din punct de vedere sin-tactic.

Spre deosebire de HTML, XML este mai strict în ceea ce priveşte sintaxa. Regulile care trebuie respectate pentru ca un document să fie bine formatat sunt:

– Faţă de HTML şi SGML, XML este case sensitive. Greşelile de scriere a elemen-telor şi atributelor sunt destul de greu de detectat, mai ales când nu se foloseşte un editor XML specializat.

– Fiecare tag deschis trebuie închis, în caz contrar analizorul XML va semnala eroare.

– Primul tag deschis trebuie să fie ultimul care este închis. Tag-urile trebuie închi-se exact în ordinea inversă a deschiderii lor, altfel va fi semnalată eroare (con-strucţia <client><adresa>...</client></adresa> este incorectă).

– Nu sunt acceptate elementele vide. După cum am văzut deja, elementele vide au sintaxa modificată: <element />.

Un document XML valid este acel document bine formatat a cărui structură este conformă cu DTD-ul ataşat (pot fi valide doar documentele care au ataşat un DTD).

Un analizor XML efectuează două nivele de verificare a unui document XML. După verificarea corectitudinii sintactice, analizorul poate verifica dacă documentul este con-form setului de reguli specificate de DTD-ul ataşat. Dacă sunt respectate aceste reguli, atunci spunem despre documentul XML că este valid. Procesul de verificare dacă un do-cument este valid se numeşte validare.

Sintaxa declaraţiei tipului de document diferă în funcţie de tipul DTD-ului: intern sau extern.

44

DTD-ul intern se declară imediat după declaraţia XML sau, dacă această declaraţie nu există, el va fi primul element exceptând comentariile, spaţiile de nume sau instrucţiunile de procesare. DTD-ul intern se declară utilizând cuvântul cheie DOCTYPE în modul următor:

<!DOCTYPE element_rădăcină [ declaraţii de elemente declaraţii de atribute declaraţii de entităţi, declaraţii de instrucţiuni de procesare declaraţii de notaţii ]>

DTD-ul extern este definit într-un alt fişier text care trebuie să se afle la o adresă speci-ficată. Declaraţia este asemănătoare, dar intervin cuvintele cheie SYSTEM sau PUBLIC:

<!DOCTYPE colegi SYSTEM "http://undeva.ro/colegi.dtd"> <!DOCTYPE colegi PUBLIC "parteneri" "http://undeva.ro/colegi.dtd">

Fişierul colegi.dtd aflat la adresa specificată în declaraţie conţine definiţiile elemen-telor care vor apare în document. Elementul <colegi> trebuie să apară în DTD-ul speci-ficat.

Un exemplu de document DTD este furnizat în continuare:

 <!ELEMENT cuprins (coordonator?,capitol+)> <!ELEMENT coordonator ANY> <!ELEMENT capitol (nume,autor*,descriere?)> <!ELEMENT nume (#PCDATA)> <!ELEMENT autor (#PCDATA)> <!ELEMENT descriere (#PCDATA)>  <!ENTITY busaco "Sabin Buraga <[email protected]>"> <!ATTLIST cuprins titlu CDATA #REQUIRED editura CDATA #IMPLIED an (2004|2005) "2004" > <!ATTLIST capitol numar CDATA #REQUIRED > <!ATTLIST autor email CDATA #IMPLIED >

Se observă definirea elementelor cuprins, coordonator, capitol, nume, autor şi descrie-re. Elementul cuprins (care e element rădăcină) va putea cuprinde elementele coordona-tor (apariţia acestuia e opţională, aspect indicat de „?”) şi capitol (operatorul „+” indică măcar o singură apariţie). Elementele vor apărea în secvenţă, lucru specificat de caracterul virgulă. Elementul capitol va putea include elementele nume, autor şi descriere. Elemen-

45

tul autor poate apărea de 0, 1 sau mai multe ori, deoarece a fost specificat operatorul „*”. Conţinuturile elementelor nume, autor şi descriere sunt şiruri de caractere (indicate de #PCDATA), iar conţinutul elementului coordonator poate fi oricare (s-a folosit ANY). Pentru elementul cuprins se specifică lista de atribute titlu, editura şi anul. Atributul titlu are drept valoare un şir de caractere (CDATA) şi e obligatoriu (#REQUIRED), pe când atributul editura este opţional (#IMPLIED). Atributul an are drept valori o enumerare de valori, implicit fiind considerată valoarea 2004. Similar şi pentru celelalte.

Se specifică şi o entitate (numită „busaco”) care cuprinde un şir de caractere.

Documentul XML care trebuie validat conform acestui DTD va putea fi următorul:

<!DOCTYPE cuprins SYSTEM "cuprins.dtd">  <cuprins titlu="Aplicatii Web la cheie. Studii de caz implementate in PHP" editura="Polirom" an="2003"> <coordonator>&busaco;</coordonator> <capitol numar="4"> <nume>E-Pizza - de la browser la WAP</nume> <autor email="[email protected]">Cristian Neghita</autor> <autor>Marius Ropota</autor> <autor>Iavi Rotberg</autor> <descriere>Aplicatia E-Pizza este o solutie completa pentru managementul informatiilor referitoare la activitatea unei pizzerii, incluzand comandarea on-line de produse, rezervarea de mese in restaurant si administrarea facila prin intermediul unei interfete Web. De asemenea, se descrie si o solutie de accesare - via dispozitive WAP - a sitului, utilizandu-se limbajul WML.</descriere> </capitol> <capitol numar="7"> <nume>Accesul la baze de date prin servicii Web</nume> <autor>Silvana Solomon</autor> <descriere>Acest capitol prezinta principalele trasaturi ale protocolului XML-RPC, prin care e posibila apelarea de proceduri la distanta, mesajele schimbate fiind scrise in format XML, in vederea implementarii de servicii Web bazate pe XML. Exemplificam utilizarea tehnologiei XML-RPC pentru gestiunea unei baze de date Web indiferent de platformele folosite.</descriere> </capitol> </cuprins>

46


Verificarea validităţii unui document XML în cadrul editorului Kate oferit de mediul KDE sub Linux

Descriere succintă a XML Schema

XML Schema, recomandare oficială a Consorţiului Web, este una dintre cele mai utilizate şi versatile maniere de validare a documentelor XML. În cele ce urmează, vom prezenta cele mai importante aspecte referitoare la aceasta.

47


O schemă reprezintă o specificaţie formală a gramaticii asociate unui document XML şi reprezintă, în fapt, tot un document XML stocat într-un fişier având ex-tensia .xsd (XML Schema Definition). O schemă XML defineşte o clasă de documente XML conformându-se unui model structural, suplimentar specificând un sistem de tipuri de date. Pentru a putea fi verificată validitatea, o instanţă a unei clase de documente XML trebuie să aibă asociată o schemă XML.

Aceste aspecte sunt asemănătoare celor de la paradigma orientată-obiect.

O schemă va specifica modul de apariţie şi tipurile de date pe care le pot lua valorile construcţiilor XML. Rezultatul obţinut în urma unei validări încununate cu succes este numit şi PSVI (Post-Schema Validation Infoset).

Schemele XML sunt utilizate în multe contexte/domenii, dintre care le enumerăm pe următoarele:

– verificarea tipurilor de date în contextul sistemelor de baze de date (relaţionale), al maşinilor virtuale (CLR, JVM) etc.;

– serializarea automată a datelor;

– invocarea la distanţă a metodelor (RMI – Remote Method Invocation, SOAP – Simple Object Access Protocol);

– generarea de cod-sursă;

– implementarea de editoare „inteligente”;

– crearea validatoarelor generale de date (e.g., validarea formularelor electronice).

Construcţiile XML Schema trebuie să aparţină spaţiului de nume indicat de adresa http://www.w3.org/2001/XMLSchema. Atributele privitoare la scheme ce apar în cadrul unei instanţe a unei clase de documente vor proveni din spaţiul de nume specificat de http://www.w3.org/2001/XMLSchema-instance.

Un document XML Schema are ca element-rădăcină <xsd:schema>. Definirea sau instanţierea unui element se realizează via <xsd:element>, iar în cazul unui atribut prin <xsd:attribute>.

Asemănător definirii unor tipuri de date şi variabile într-un limbaj de programare, într-o schemă XML fiecare instanţă de element trebuie să aparţină unei clase (tip) de elemen-te. Un element/atribut va avea valori permise ce aparţin unui tip de date (simplu sau complex), specificat prin <xsd:SimpleType> şi, respectiv, <xsd:ComplexType>.

Tipurile simple, predefinite ori derivate din cele predefinite, descriu conţinutul datelor textuale. În acest caz, nu se permite ca un element să includă alte elemente şi nici să aibă

48


asociate atribute. Tipurile simple pot fi folosite şi pentru specificarea conţinutului atribu-telor.

Tipurile complexe descriu datele (semi)structurate. În acest caz, se acceptă ca elemen-tele să includă alte elemente (via reguli de apariţie) şi să aibă asociate atribute. Elementele de tip complex vor putea conţine:

– declaraţii de elemente, prin intermediul construcţiei <element name="nume"

type="tip" />;

– referinţe la elemente apriori definite: <element ref="nume" re-

guli_aparitie="valori" />;

– declaraţii de atribute via <attribute name="nume" type="tip" />.

Tipurile complexe nu pot fi folosite în contextul stabilirii tipului valorilor atributelor XML.

Consorţiul Web a pus la dispoziţie o paletă largă de tipuri predefinite (primitive şi de-rivate). Cele mai utilizate sunt enumerate în continuare:

– numerice: byte, unsignedByte, integer, positiveInteger, negativeInteger, int, long, decimal, float, double şi altele;

– logice: boolean;

– privitoare la dată şi timp: time, dateTime, duration, date, gYear, gMonth, gDay etc.;

– şiruri de caractere: string, token şi altele;

– adrese Web: anyURI.

Putem defini tipuri simple derivate din cele predefinite via <xsd:simpleType>. Noul tip de date specificat poate fi o restricţie a unui tip deja existent prin intermediul unor constrângeri (facets). Prin intermediul constrângerilor pot fi precizate aspecte precum:

– lungimea: <xsd:length>;

– lungimea minimă: <xsd:minLength>;

– lungimea maximă: <xsd:maxLength>;

– un model (pattern), exprimat printr-o expresie regulată: <xsd:pattern>.

De asemenea, putem recurge la precizarea unei liste de valori (via <xsd:enumeration>) ce va forma tipul sau a unui interval de valori (construcţiile <xsd:minInclusive>, <xsd:maxInclusive>, <xsd:minExclusive> şi <xsd:maxExclusive>).

49


Tipurile simple noi vor fi folosite să descrie valorile elementelor/atributelor, ataşarea acestora unor construcţii XML putând avea loc fie în cadrul schemei la declararea unui element, fie în cadrul instanţei via atributul xsi:type.

De asemenea, vom putea preciza următoarele (simbolul „|” semnifică o alternativă):

– reguli (restricţii) de aparitie a unei instanţe de element: numărul minim de apariţii (minOccurs="număr") şi/sau numărul maxim de apariţii (maxOccurs="număr | unbounded");

– reguli de apariţie a unui atribut (obligatoriu, opţional sau interzis): use="required | optional | prohibited";

– valoarea predefinită a unui atribut via default;

– valori particulare pentru elemente sau atribute: fixed.

De reţinut că tipurile simple pot fi utilizate doar pentru a descrie date-caracter. În ve-derea definirii structurii unui document, se recurge la <xsd:complexType>. Un tip com-plex poate avea un conţinut simplu (<xsd:simpleContent>) sau unul complex.

Conţinutul simplu înseamnă că un element va putea include atribute, extinzând astfel modelul-conţinut. O primă metodă este derivarea prin extensie, via elementul <xsd:extension>, iar a doua modalitate vizează derivarea prin restricţie, realizată prin intermediul constrângerilor (facets). Atributele vor fi definite prin intermediul <xsd:attribute>, putând fi declarate global (la nivelul schemei) sau local (în cadrul unui tip complex). De asemenea, ele pot fi calificate (prefixate de spaţiul de nume ales) sau nu.

Specificarea unui tip cu conţinut complex vizează definirea listei şi ordinii sub-elementelor şi atributelor sale. Conţinutul unui element poate fi şi mixt (compus din sub-elemente sau date-caracter): <xsd:complexType mixed="true"> ori vid (nu va conţine decât declaraţii de atribute).

Pentru a preciza diverse modele ale conţinutului, vom adopta diverse construcţii refe-ritoare la:

– alternativă: <xsd:choice>;

– secvenţă: <xsd:sequence>;

– grupare: <xsd:group>;

– apariţie a tuturor elementelor, în orice ordine: <xsd:all>.

De menţionat şi faptul că specificarea unor elemente/atribute generice (ale altor ti-puri de documente) se realizează prin elementele <xsd:any> şi <xsd:anyAttribute>. De asemenea, XML Schema oferă şi suport pentru documentare via <xsd:annotation>.

50

În continuare, vom furniza un exemplu de schemă XML menită a valida documentul XML privitor la achiziţiile şi vânzările de portocale, menţionat mai sus. Structura schemei este următoarea:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="urn:portocale.info" targetNamespace="urn:portocale.info"> <xsd:annotation> <xsd:documentation xml:lang="ro"> O schemă utilizată la validarea tranzacţiilor de portocale </xsd:documentation> </xsd:annotation>  <xsd:element name="portocale" type="portocaleType" /> <xsd:complexType name="portocaleType">  <xsd:sequence maxOccurs="unbounded"> <xsd:choice>  <xsd:element name="achizitii" type="prodType" minOccurs="1" maxOccurs="unbounded" />  <xsd:element name="vanzari" type="prodType" minOccurs="1" maxOccurs="unbounded" /> </xsd:choice> <xsd:sequence> </xsd:complexType>  <xsd:complexType name="prodType"> <xsd:sequence> <xsd:element name="tip" type="xsd:string" minOccurs="1" maxOccurs="1" /> <xsd:element name="cod" type="xsd:string" minOccurs="1" maxOccurs="1" />  <xsd:element name="obs" type="xsd:string" minOccurs="0" maxOccurs="1" /> <xsd:element name="cantit"> <xsd:complexType>  <xsd:simpleContent> <xsd:extension base="xsd:unsignedInt">  <xsd:attribute name="um" type="xsd:string" use="required" /> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> </xsd:sequence>  <xsd:attribute name="id" type="xsd:ID"

51

use="optional" /> </xsd:complexType> </xsd:schema>

Reprezentarea grafică a schemei e disponibilă în figura de mai jos.

Reprezentarea generată de editorul <oXygen /> a schemei XML

Mai urmează să utilizăm schema de mai sus, pentru a verifica validitatea unei instanţe de document XML care trebuie să declare un spaţiu de nume cu un URI desemnând schema utilizată.

La nivel de instanţă de document, vom folosi o construcţie de genul:

<portocale xmlns="urn:portocale.info" xmlns:xsi= "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "urn:portocale.info file:portocale.xsd">  </portocale>

Aplicaţia <oXygen /> XML Editor amintită mai sus poate fi folosită şi ca validator de documente XML.

În cele de mai jos, ilustrăm anumite mesaje de eroare afişate de unul dintre utilitarele puse la dispoziţie de procesorul Apache Xerces – disponibil în regin open source – în cazul unui document XML invalid conform schemei descrise anterior:

P:\xerces>DOMPrint.exe -v=always -n -s -f portocale.xml Error at file "portocale.xml", line 7, column 21 Message: Unknown element 'suplimentar' Error at file "portocale.xml", line 11, column 21 Message: In element cod: Can not have element children within a simple type content Error at file "portocale.xml", line 12, column 14 Message: Required attribute 'um' was not provided

52


Error at file "portocale.xml", line 13, column 15 Message: Element 'suplimentar' is not valid for content model: '((tip,cod,obs),cantit)'

Un rezultat aproape similar îl obţinem utilizând Microsoft Visual Web Developer pentru editarea şi validarea documentelor XML – a se urmări figura alăturată.

Semnalarea erorilor de validare a unui document XML în cadrul instrumentului Visual Web Developer

53


7. Procesarea documentelor XML

Modelul DOM

Consorţiul Web a propus pentru prelucrarea sofisticată a documentelor XML şi/sau HTML un model obiectual denumit DOM (Document Object Model).

Acest model reprezintă o interfaţă de programare a aplicaţiilor destinate să prelucreze documentele HTML şi XML, independentă de platformă şi de limbaj, definind structura logică a documentelor şi modalităţile de accesare şi de modificare a lor.

Structura logică a documentelor este o structură arborescentă, documentele fiind mo-delate utilizând obiecte. Modelul DOM nu furnizează doar o vizualizare structurată a do-cumentului, ci şi o modalitate de specificare a comportamentului lui şi a obiectelor com-ponente. Fiecare element al unui document poate fi privit, aşadar, ca un obiect, cu o iden-titate şi propriile sale funcţii.

Recomandările DOM sunt structurate pe mai multe nivele de specificare a modelului. Nivelul 0 (pentru HTML) a fost nivelul de funcţionalitate a versiunilor 3 ale navigatoare-lor Netscape şi Internet Explorer. Nivelul 1 este recomandare standardizată din anul 1998, iar în 2000 a fost standardizat DOM – nivelul 2. Parţial, nivelul 3 al DOM a fost publicat ca recomandare oficială în anul 2004 şi este în curs de standardizare completă.

DOM nu este o specificaţie binară şi nu defineşte nici o formă de interoperabilitate la nivel binar, în contrast cu alte tehnologii, precum CORBA (Common Object Request Broker Architecture) ori COM (Common Object Model). DOM reprezintă un model care specifică interfeţe şi nu este un set de structuri de date (abstracte). De asemenea, nu defineşte se-mantica detaliată a documentelor HTML sau XML.

Specificaţia DOM reprezintă documentele ca o ierarhie de obiecte-nod. Anumite tipuri de noduri pot avea noduri copii (descendenţi) de diverse tipuri. Altele pot fi noduri frun-ză, lipsite de descendenţi. Tipurile fundamentale de noduri sunt cele din următorul tabel.

Pentru fiecare tip de nod, DOM oferă o interfaţă care desemnează constantele, variabi-lele şi metodele ce vor putea fi folosite de programator într-o implementare efectivă a modelului. Există o serie de interfeţe fundamentale (e.g., Document, DocumentFragment, Node, NodeList sau Attr), plus diverse interfeţe extinse pentru a suporta implementări având în vedere procesarea documentelor HTML ori oferind facilităţi adiţionale.

În continuare, vom descrie succint o serie dintre interfeţele puse la dispoziţie.

54


Tip Descendenţi

Document Element, ProcessingInstruction, Comment, DocumentType

DocumentFragment Element, ProcessingInstruction, Comment, Text, CDATASection,

EntityReference DocumentType – EntityReference Element, ProcessingInstruction, Comment,

Text, CDATASection, EntityReference

Element Element, Text, Comment, ProcessingInstruction, CDATASection,

EntityReference Attr Text, EntityReference

ProcessingInstruction – Comment –

Text – CDATASection –

Notation – Entity Element, ProcessingInstruction, Comment,

Text, CDATASection, EntityReference

Interfeţele DOM

O interfaţă importantă este DocumentFragment care poate reprezenta un obiect-document minimal. Sunt numeroase situaţiile în care nu trebuie lucrat cu întregul docu-ment, ci doar cu diverse fragmente ale sale. Arborele de noduri ale unui fragment de do-cument este un sub-arbore al structurii de noduri a documentului luat în întregul lui. În funcţie de necesităţi, DocumentFragment poate reprezenta o entitate XML, un element XML sau chiar un grup de elemente.

Interfaţa Document reprezintă un document XML, conceptual desemnând rădăcina ar-borelui de noduri-obiecte ale documentului şi oferind accesul la informaţiile conţinute de acesta. Din moment ce elementele (marcatorii), nodurile de tip text, comentariile, instruc-ţiunile de procesare nu pot exista în afara contextului unui document, interfaţa Document conţine de asemenea metodele necesare pentru a crea aceste categorii de obiecte.

Interfaţa Document are ca membri trei atribute:

i. doctype reprezintă declaraţia tipului de document (DTD) asociată unui document particular.

ii. implementation specifică implementarea sau implementările disponibile pentru procesarea documentului.

55


iii. documentElement (de tip Element) desemnează nodul-rădăcină de acce-sare a structurii arborescente a documentului.

Menţionăm următoarele metode importante:

• createElement() creează un element XML;

• createTextNode(), createComment(), createCDATASection(), createProcessingInstruction() vor genera noduri-obiect de tip text, co-mentariu, secţiune CDATA, instrucţiune de procesare, respectiv;

• createAttribute() creează un obiect atribut care va fi asociat unui element specificat;

• getElementById() va întoarce elementul al cărui atribut id se potriveşte cu cel furnizat ca argument al acestei metode (în acest mod poate fi selectat exact un anumit element, ştiind că identificatorul asociat trebuie să fie unic);

• getElementsByTagName() va returna o listă ordonată de noduri NodeList pen-tru toate elementele corespunzătoare unui tag, ordonarea nodurilor realizându-se prin parcurgerea în pre-ordine a arborelui;

Interfaţa Node defineşte un tip primar pentru întregul model DOM, reprezentând un anumit nod în cadrul arborelui asociat unui document. Atributele nodeName, nodeValue şi attributes sunt introduse ca mecanism pentru furnizarea informaţiilor despre noduri fără conversie de tipuri (vizualizare „simplificată”, nu una „orientată-obiect”). Fiecare nod va avea asociată o listă ordonată conţinând descendenţii săi, plus atribute specificând nodul părinte, primul şi ultimul nod copil, dacă există.

Ca metode prezentând interes se pot menţiona cele care manipulează nodurile copil:

• insertBefore() permite inserarea unui nod înaintea celui curent;

• replaceChild() substituie un nod-copil;

• removeChild() elimină un nod-copil specificat;

• appendChild() adaugă un alt nod-copil;

• cloneChild() clonează un anumit nod-copil;

• hasChildNodes() întoarce true dacă există noduri-copil;

• hasAttributes() întoarce true dacă nodul are atribute (metodă introdusă în DOM nivelul 2);

• isSameNode() întoarce true dacă nodul curent e identic cu un altul specificat (metodă oferită de DOM nivelul 3).

56


Interfaţa NodeList reprezintă o interfaţă care oferă un tip abstract de dată pentru co-lecţiile ordonate de noduri, fără a defini sau restricţiona cum va fi implementată efectiv această colecţie. Fiecare implementator va decide ce tipuri de date concrete vor fi utiliza-te. Membrii colecţiei se vor accesa via metoda item() pe baza unui index întreg, nume-rotarea nodurilor începând cu valoarea 0.

Interfaţa NamedNodeMap este folosită pentru reprezentarea abstractă a colecţiilor ne-ordonate de noduri, prelucrate prin intermediul numelui. Interfaţa NamedNodeMap nu derivă din NodeList.

Interfaţa Attr modelează un atribut din cadrul unui obiect de tip Element. Tipic, valo-rile permise ale atributelor sunt definite în schema XML corespunzătoare documentului. Un obiect Attr nu se consideră că aparţine arborelui de noduri-obiect al documentului. Nodurile de tip Attr sunt considerate proprietăţi ale elementelor (marcatorilor), putând fi asociate nodurilor Element conţinute de obiecte de tip DocumentFragment.

Interfaţa Element derivă din Node şi oferă metode de accesare a obiectelor Attr, prin nume sau prin valoare: getAttribute(), setAttribute(), removeAttribute(), getAttributeNode(), setAttributeNode(), removeAttributeNode().

Interfaţa Text este o interfaţă reprezentând conţinutul textual (date de tip şiruri de ca-ractere) al unui nod Element sau Attr. Dacă între tag-urile de început şi de sfârşit nu există alţi marcatori, atunci textul va fi stocat într-un obiect implementând interfaţa Text.

În prezent, există implementări complete pentru DOM – nivelurile 1 şi 2 – în majori-tatea limbajelor de programare actuale (C/C++, C#, Java, JavaScript, Perl, Python etc.). Drept exemple notabile de biblioteci şi interfeţe de programare disponibile în diverse limbaje pot fi enumerate JAXP (Java API for XML Parsing), JDOM, libxml, MSXML.NET, QDOM, Xerces DOM API şi XML::DOM.

Inspectarea arborelui DOM se poate realiza direct în navigatorul Mozilla Firefox, via componentei DOM Inspector. O captură-ecran edificatoare este dată mai jos.

57


Folosirea componentei DOM Inspector pentru vizualizarea arborelui DOM asociat unui document XHTML

O serie de exemple de manipulare prin DOM a documentelor XML vor fi furnizate pe parcursul acestei lucrări.

Procesarea XML prin SAX

Pentru documente de dimensiuni mari, modelul DOM este ineficient, deoarece înainte de a se realiza prelucrarea, documentul respectiv trebuie încărcat complet în memorie. Ca alternativă la implementările DOM, există o interfaţă simplă de programare destinată ma-nipulării documentelor XML, însă nu atât de completă precum DOM. Această interfaţă este denumită SAX (Simple API for XML).

Majoritatea celor care se ocupă de prelucrarea documentelor XML văd structura unui document în formă arborescentă, iar modelul DOM oferă din plin posibilitatea de a ma-nipula informaţiile în această manieră. Din punctul de vedere al implementatorilor, aceas-tă abordare are numeroase deficienţe (maniera de stocare internă a arborelui de obiecte, parcurgerea lui etc.). Unul dintre beneficiile utilizării interfeţei SAX este că arborele nu mai trebuie construit, dându-i-se programatorului o altă cale de analiză a documentului

58


XML. Mai mult, SAX poate ajuta la convertirea datelor din formatul arborescent DOM în alt format mai comod, iar pentru procesare nu este necesar a se memora întreaga in-formaţie XML, ci numai părţile dorite.

Interfaţa SAX reprezintă un efort independent de Consorţiul Web de standardizare a procesării XML condusă de evenimente. În acest moment, SAX este acceptat ca standard industrial, fiind folosit pe scară largă în multe aplicaţii, dar nu trebuie privit ca o înlocuire a modelului DOM, ci drept o abordare complementară.

Actualmente, sunt disponibile două versiuni ale specificaţiilor SAX: varianta 1.0 şi vari-anta 2.0, mai complexă, oferind suport pentru spaţii de nume şi extensii. Mai multe detalii la www.saxproject.org.

În esenţă, după iniţierea încărcării conţinutului documentului XML dorit a fi procesat, pentru fiecare tip de construcţie XML sintactică (început de tag, sfârşit de tag, conţinut (text), instrucţiune de procesare, comentariu etc.) se va „aprinde” un eveniment care va fi tratat de o funcţie sau metodă (handler). Funcţiile (metodele) de tratare se specifică de că-tre programator, pentru fiecare tip de construcţie XML în parte.

Astfel, programul consumă şi tratează evenimente produse de procesorul SAX folosit.

Minimal, trebuie definite următoarele funcţii/metode:

• tratează_tag_început (procesor, elem, atrib) – va fi apelată la apariţia unui tag de început şi are drept parametri procesorul XML folosit, numele ele-mentului corespunzător tag-ului şi lista de atribute ale acestuia (dacă există);

• tratează_tag_sfârşit (procesor, elem) – va fi invocată la apariţia unui tag de final, argumentele având semnificaţiile de mai sus;

• tratează_date_caracter (procesor, date) – va fi apelată la apariţia unor date caracter (conţinut propriu-zis aflat între marcatorii de început şi sfârşit).

Mai rămâne să ataşăm pentru fiecare eveniment de apariţie a tag-ului de început, a tag-ului de sfârşit şi a datelor-conţinut funcţiile de tratare descrise anterior. SAX oferă pentru aceasta două funcţii/metode de forma:

• set_element_handler (tratează_tag_început, tratea-

ză_tag_sfârşit)

• set_character_data_handler (tratează_date_caracter)

Sunt oferite implementări SAX pentru majoritatea limbajelor de programare actuale. Navigatoarele Web nu oferă suport pentru procesări XML via SAX.

59


Analizoare XML

Desigur, pentru prelucrarea documentelor XML vom trebui să recurgem la un analizor XML deja implementat în limbajul nostru preferat. Analizoarele XML pot fi de două ti-puri:

– analizoare fără validare care vor procesa un document XML verificând dacă acesta este bine-formatat (adică respectă regulile privind sintaxa şi modul de imbricare corectă a tag-urilor);

– analizoare cu validare care vor realiza procesarea documentului XML prin verifica-rea regulilor formale descrise de un DTD sau o schemă ataşate acestuia (aceste analizoare sunt mai complexe).

Unul dintre cele mai cunoscute analizoare fără validare este Expat, disponibil în regim open source. De asemenea, pot fi utilizate analizoarele cu posibilităţi de validare JAXP (Sun), JDOM, libxml (parte a proiectului GNOME), MSXML (Microsoft) sau Xerces (Apache). Practic, toate mediile de dezvoltare Web actuale oferă posibilităţi de validare a documentelor XML via DTD sau XML Schema şi diverse modalităţi de procesare.

Pentru verificarea formatării corespunzătoare a documentelor XML se pot utiliza chiar şi navigatoarele Web actuale.

De exemplu, fie documentul XHTML eronat:

<?xml version="1.0"?>

<html xmlns:html="http://www.w3.org/1999/xhtml">

<table width=600 align=center>

</table>

Vom obţine mesajul de eroare din capturile-ecran de mai jos:

60


Verificarea bunei-formatări a documentelor XML folosind navigatoarele Web

61


8. Transformări XML

Din cele descrise mai sus, am văzut că în mod uzual un document XML separă conţinu-tul de maniera de formatare/procesare (specifică, deseori, unui anumit scop şi/sau unei aplicaţii).

Pentru a prezenta – într-o manieră dorită şi comodă – datele XML, trebuie specificată o modalitate de redare via aşa-numita foaie de stiluri (stylesheet). Soluţiile actuale sunt date de două direcţii importante standardizate de Consorţiul Web:

• CSS (Cascading Style Sheets) – folosesc o sintaxă non-XML, prezintă o flexibilitate limitată şi nu oferă o redare dependentă de context;

• XSL (Extensible Stylesheet Language) – adoptă o sintaxă XML, au o flexibilitate mai mare, iar procesarea se poate face în funcţie de context; de asemenea, se pot opera modificări de structură, oferindu-se facilităţi pentru realizarea de interogări simple.

În cele ce urmează, ne vom referi la transformările XSL. Pentru efectuarea transformă-rilor se consideră că documentul XML este un arbore format din noduri de diverse tipuri, precum element-rădăcină, elemente, conţinut textual, atribute, spaţii de nume, instrucţi-uni de procesare, comentarii etc. Pentru noduri de tip text, caracterele rezervate trebuie rescrise cu entităţi.

Fiecare foaie de stiluri XSL constă, simplist vorbind, din reguli compuse dintr-un model (pattern) şi o acţiune, modelul identificând un nod sau grup de noduri XML asupra căruia se va aplica acţiunea. Expresiile modelului sunt exprimate în limbajul XPath, iar acţiunile – transformările efectuate asupra elementelor documentului – sunt specificate în XSLT (XSL Transformations). Transformările se aplică recursiv tuturor nodurilor XML care satis-fac modelul/şabloanele de reguli (pattern-matching).

Limbajul XPath

Vom prezenta în continuare principalele trăsături ale limbajului XPath. Scopul acestuia este să adreseze părţi dintr-un document XML, oferind facilităţi de bază pentru manipu-larea unor tipuri de date simple (şiruri de caractere, numere etc.) şi operând la nivelul structurii abstracte a documentului XML (i.e. arborele).

Construcţia fundamentală este expresia XPath, evaluarea acesteia realizându-se în func-ţie de context. Acest context poate fi desemnat de un nod al documentului XML, de po-ziţie, o funcţie de bibliotecă sau de o declaraţie a unui spaţiu de nume.

În urma evaluării expresiei, este întors un obiect, adică: o mulţime de noduri (node-set), o valoare logică (true, false), un număr (float), un şir de caractere.

Asupra nodurilor, pot fi folosiţi operatorii descrişi în continuare.

62


Operatorul / (descendent) este utilizat să definească o ierarhie de elemente (o cale de parcurgere a nodurilor din arborele asociat documentului). Câteva exemple: / şi /cuprins/capitol/autor (a se vedea figura următoare).

Utilizarea operatorului „/”pentru selectarea unui element descendent

Operatorul // (traversare recursivă) traversează în adâncime întreg sub-arborele unui anumit nod; exemple: //capitol şi //cuprins.

Operatorul * (wildcard) e folosit uzual pentru elemente şi atribute; oferă toate elemente-le/atributele de pe un anumit nivel al arborelui. Ca exemplificare, furnizăm capitol/* şi /cuprins/*/nume.

Operatorul . (nodul curent) este un operator contextual şi desemnează nodul curent; exemple: ./capitol şi ./cuprins/*.

Operatorul @ (atribut) e utilizat să specifice valoarea unui anumit atribut; drept exem-plificări, furnizăm //capitol/@nr şi table/@*.

Operatorul : (spaţiu de nume) este folosit să selecteze elemente/atribute pe baza unui spaţiu de nume – pentru //html:* obţinem toate construcţiile HTML existente într-un document ce au fost prefixate de spaţiul de nume corespunzător.

Operatorul [] (filtru/index) aplică un filtru sau localizează nodurile pe baza unui index (numerotarea începe de la 1); de exemplu: /cuprins/capitol[2] sau //capitol[@nr="3"].

De asemenea, pentru valori logice şi întregi pot fi utilizaţi operatorii uzuali relaţionali („or”, „and”, „=”, „!=”, „<=”, „<”, „>”, „>=”) şi aritmetici („+”, „—”, „*”, „div” şi „mod”).

Comparaţiile de şiruri de caractere se realizează în manieră case-sensitive.

Limbajul XPath clasifică tipurile de noduri în aşa-numitele axe, dintre care menţionăm:

• axa nodului curent (context node): self;

• axa nodului părinte: parent;

63


• axa nodurilor copil: child;

• axa nodurilor descendente: descendent;

• axa nodurilor de tip atribut: attribute;

• axa nodurilor spaţiilor de nume: namespace.

Pentru specificarea unei axe, se foloseşte operatorul :: precedat de numele axei dorite. Un exemplu este //child::*[@nr > 2] care selectează toate nodurile copil având va-lori mai mari decât 2 pentru atributul nr, parcurgându-se recursiv întreg arborele XML

În locul precizării anumitor axe, se poate recurge la sintaxa prescurtată. Astfel, self se poate substitui cu „.”, parent cu „..”, attribute cu „@” şi namespace prin „:”.

Specificaţia XPath descrie şi suita de funcţii de bază care pot fi folosite în cadrul unei expresii. Le menţionăm pe cele mai importante:

• privitoare la noduri: id(), position(), count(), name(), namespace-uri(), last() etc.;

• referitoare la tipuri de noduri: node(), text(), comment(), processing-instruction() şi altele;

• vizând şirurile de caractere: concat(), starts-with(), contains(), substring(), string-length(), translate() etc.;

• privitoare la valori logice: not(), true(), false();

• referitoare la numere: sum(), floor(), round(), number() etc.

Limbajul XSLT

Limbajul XSLT (XSL Transformations) are drept scop transformarea documentelor XML în alte structuri (tipuri) de documente: XML, HTML, text.

Pentru a avea efectul scontat, construcţiile XSLT trebuie să aparţină spaţiului de nume desemnat de URI-ul http://www.w3.org/1999/XSL/Transform. O foaie de stiluri XSLT are drept element-rădăcină <xsl:stylesheet> sau <xsl:transform> şi include diverse şabloane (template-uri) de transformare, măcar un şablon la nivelul rădăcină.

Pentru realizarea transformărilor, se recurge la expresii XPath folosite la selectarea no-durilor dorite a fi procesate, la specificarea condiţiilor de procesare (contextul) sau la ge-nerarea textului de ieşire (e.g., un alt document XML, o pagină HTML ori text obişnuit).

Modelul procesării consideră că o listă de noduri-sursă (input) este prelucrată pentru a se genera un fragment de arbore de noduri la destinaţie (output). Iniţial, se procesează nodul-rădăcină, la care se inserează noduri copil generate de şabloane aplicate prin pattern-matching unei liste de noduri selectate (în manieră recursivă) – via expresii XPath.

Regulile şabloanelor identifică noduri asupra cărora se vor aplica transformări, selectarea nodurilor realizându-se prin XPath. Un şablon se defineşte prin elementul

64


<xsl:template>, iar aplicarea unui şablon se realizează cu elementul <xsl:apply-templates>.

Crearea arborelui de ieşire se realizează ţinând cont de faptul că într-un şablon orice element ce nu aparţin spaţiului de nume XSLT sunt copiate, fără a fi operate modificări, în arborele de ieşire. De asemenea, pot fi generate diverse tipuri de noduri: <xsl:element>, <xsl:attribute>, <xsl:text>, <xsl:comment> etc. Pentru a avea acces la rezultatele expresiilor XPath implicând valori ale documentului sursă, vom recur-ge la <xsl:value-of>. Diverşi parametri de control al modului de generare a ieşirii se pot stabili via <xsl:output>.

Foile de stiluri XSLT pot fi considerate programe, permiţându-se exprimarea de con-strucţii repetitive: <xsl:for-each>, de construcţii de test: <xsl:if>, <xsl:choose>, <xsl:when> şi <xsl:otherwise>, de copieri de noduri: <xsl:copy> şi <xsl:copy-of>, de sortări de noduri: <xsl:sort>, de includeri de alte foi de stiluri: <xsl:include>, de variabile şi parametri: <xsl:variable> şi <xsl:param>.

Facem observaţia că, spre deosebire de limbajele de programare clasice, variabilele (de-clarate via <xsl:variable>) au valori imutabile: valoarea asociată nu se schimbă din moment ce a fost evaluată. Astfel, după o construcţie de genul <xsl:variable name="ani" select="21 + 12" />, o încercare de a atribui o altă valoare variabilei ani conduce la apariţia unei erori. Parametrii (specificaţi prin <xsl:param>) îşi pot modi-fica ulterior valoarea. Apelarea (invocarea) unui şablon se poate realiza cu pasarea de va-lori parametrilor via <xsl:with-param>.

Suplimentar, sunt puse la dispoziţie diverse funcţii de bază:

– desemnează nodul curent: current();

– adresează un alt document XML, diferit de cel curent: document();

– verifică existenţa unei funcţii (suport pentru extensii): function-available();

– formatează valori numerice: format-number();

– oferă informaţii privitoare la sistemul de procesare: system-property().

Exemple

Pentru început, considerăm documentul projects.xml care stochează o listă de proiecte propuse spre implementare şi care are structura:

<?xml-stylesheet href="projects.xsl" type="text/xsl" ?>

<projects update="...">

<project class="A">

<title>...</title>

<desc>...</desc>

65

<stud>...</stud>

<url>...</url>

</project>

</projects>

Ne propunem să generăm un document XHTML pentru redarea, în navigator, a aces-tei liste. După cum se poate remarca, folosind instrucţiunea de procesare <?xml-stylesheet ...?> ataşăm o foaie de stiluri XSLT numită projects.xsl şi având următorul conţinut:

<xsl:stylesheet version="1.0"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform">



<xsl:template match="/">

<html>

<head>

<title>Proiecte</title>

</head>

<body>



<div id="listing">

<xsl:apply-templates />

</div>

</body>

</html>

</xsl:template>



<xsl:template match="projects">

<ul>



<xsl:for-each select="project">

<li>

<h5>



<xsl:value-of select="title" />

(<xsl:value-of select="@class" />)

</h5>

<p>

<xsl:value-of select="desc" />

</p>

<div>Resurse suplimentare:



<a>



<xsl:attribute name="href">

<xsl:value-of select="url" />

66

</xsl:attribute>



<xsl:attribute name="title">Mai multe

detalii</xsl:attribute>

<xsl:value-of select="url" />

</a>

</div>

</li>

</xsl:for-each>

</ul>

<p>Ultima actualizare:

<xsl:value-of select="@update" /></p>

</xsl:template>

</xsl:stylesheet>

Codul generat este XHTML, pentru ca foaia să fie considerată un document XML bi-ne formatat. Sunt specificate două şabloane, primul construind scheletul general al paginii Web, iar al doilea generând lista privitoare la proiecte. Al doilea şablon va fi invocat la potrivirea cu succes a apariţiei elementului <projects>. Similar, <xsl:for-each> va furniza lista de noduri rezultată în urma evaluării expresiei XPath project (acelaşi efect îl avea expresia absolută /projects/project).

Primul pas al transformării va conduce la invocarea şablonului-rădăcină, în urma potri-virii cu nodul-rădăcină desemnat de operatorul „/”. Toate nodurile care nu aparţin spa-ţiului de nume xsl vor fi copiate la ieşire (astfel, se construieşte codul-sursă al paginii Web, până la apariţia elementului <xsl:apply-templates />. Acest eveniment va conduce la invocarea şablonului potrivit cu expresia project, în cazul nostru <xsl:template match="projects"> ...</xsl:template>, care va genera lista ne-numerotată a proiectelor. Cele specificate în cadrul <xsl:for-each> vor fi repetate de atâtea ori câte noduri sunt returnate de expresia specificată ca valoare a atributului se-lect al elementului <xsl:for-each>.

Se observă generarea unei legături <a href="..." title="...">...</a>, pentru aceasta recurgând la <xsl:attribute> pentru a ataşa cele două atribute – href şi title – elementului <a> al limbajului XHTML.

Vom rafina puţin cele scrise mai sus, ştiind că proiectele propuse sunt de diverse clase de dificultate, indicate de valorile atributului class al elementului <project>. Intenţio-năm să afişăm în mod diferit descrierea proiectului, conform clasei sale. Pentru aceasta, vom recurge la construcţiile de test (omitem restul foii de stiluri):

<p>



<xsl:choose>



67

<xsl:when test="@class = 'A'">

<span style="color: darkred">


</span>

</xsl:when>



<xsl:when test="@class = 'B' or @class = 'C'">

<span style="color: navy">


</span>

</xsl:when>



<xsl:otherwise>

<span style="color: black">


</span>

</xsl:otherwise>

</xsl:choose>

</p>

De asemenea, putem verifica dacă <url> există sau are o valoare nenulă, pentru a nu insera inutil legătura spre resursele suplimentare privitoare la un proiect:



<xsl:if test="url != ''">



...

</xsl:if>

Următorul pas este să ordonăm lista proiectelor conform unor criterii. Pentru aceasta, folosim o construcţie de genul:






<xsl:sort select="stud" order="descending" />



<xsl:sort select="title" />

<li>

<h5><xsl:value-of select="title" /></h5>

</li>

</xsl:for-each>

Vom recurge şi la variabile, calculând valoarea RGB a culorii de fundal pe care o vom stabili în funcţie de numărul maxim de studenţi arondaţi unui proiect – se utilizează func-ţia concat() pusă la dispoziţie de XPath:

68

<xsl:sort select="title" />

<li>



<xsl:variable name="fundal"

select="concat('rgb(',stud*90 ,',', stud*90,

',', stud*30, ')')" />

<p style="background-color: {$fundal}">



<xsl:value-of select="(position())" />.

<xsl:value-of select="title" />

</p>

</li>

</xsl:for-each>

După cum se poate remarca, valoarea unei variabile se accesează prefixând numele va-riabilei cu semnul „$”.

Realizarea transformărilor se poate face direct în cadrul unui navigator Web de ultimă generaţie, precum Mozilla Firefox 1 ori Internet Explorer 6 sau o versiune superioară. De asemenea, există o sumedenie de modalităţi de realizare a transformărilor la nivel pro-gramatic via procesoare XSLT precum Apache Xalan, libxslt, Saxon etc.

Drept exemple de aplicaţii care folosesc tehnologia XSLT amintim:

– Adobe Help Center – sistem de ajutor utilizat de suita Adobe Creative Suite 2, dar funcţionând şi independent, disponibil gratuit;

– Apache AxKit – mediu de publicare a datelor implementat în Perl;

– Apache Forrest – mediu de dezvoltare de situri Web;

– Microsoft InfoPath – editor/procesor de formulare interactive, parte a Microsoft Office 2003 şi 2007;

– Open Office – suita de birou disponibilă în regim open source.

69


70


71

PPaarrtteeaa IIIIII –– PPrrooggrraammaarreeaa aapplliiccaaţţiiiilloorr WWeebb

„O arhitectură bună poate îmbunătăţi calitatea vieţii oamenilor.” Alfred Hitchcock

1. Maniere de programare pe partea de server 2. Standardul CGI (Common Gateway Interface) 3. PHP (PHP: Hypertext Preprocessor) 4. Servicii Web


72


1. Maniere de programare pe partea de server

Pentru început, vom trece în revistă modalităţile tradiţionale de programare, pe partea de server, a aplicaţiilor Web.

Standardul CGI

Din punct de vedere istoric, prima metodă de generare dinamică pe server a reprezentări-lor unor resurse solicitate de un client Web vizează standardul de facto CGI (Common Gateway Interface) – detalii în S. Buraga et al., Programarea aplicaţiilor Web folosind bash şi Perl, Polirom, Iaşi, 2002.

Principalele dezavantaje sunt cele privitoare la invocarea concurentă a mai multor scripturi CGI, problemele survenite fiind asigurarea scalabilităţii, a integrării cu alte apli-caţii, persistenţa conexiunii şi contextul invocării (rulării). Drept soluţii se pot adopta teh-nici de caching, includerea suportului pentru CGI direct în serverul Web şi folosirea aşa-numitului FastCGI.

Servere de aplicaţii Web

Evoluţia a continuat cu apariţia altor interfeţe de programare Web pe partea de server. Astfel, pot fi menţionate mod_perl pentru Apache, NSAPI (Netscape Server API) şi ISAPI (Microsoft Internet Services API), funcţionând intern conform modelului CGI.

De un succes larg se bucură însă serverele de aplicaţii Web, printre cele mai populare numărându-se ASP (Active Server Pages), ASP.NET (parte integrantă a .NET Framework), PHP (PHP: Hypertext Preprocessor) şi JSP (Java Server Pages). Principalele avantaje ale acesto-ra faţă de vechiul, dar încă utilizatul CGI, sunt următoarele: suportul pentru sesiuni, asi-gurarea load-balancing-ului, conexiunile persistente cu sistemele de baze de date, suportul pentru template-uri de interfaţă (şabloane, componente Web, skin-uri ş.a.m.d.), facilităţile vizând modularitatea, securitatea.

Vom descrie în continuare caracteristicile comune serverelor de aplicaţii Web, fără a intra în amănunte privind modul de programare şi exploatare.

Un server de aplicaţii Web oferă posibilitatea de a include cod (script) direct în cadrul documentelor Web, cod invocat pe server. Astfel, se generează conţinut dinamic pe par-tea de server, eventual procesându-se un număr de surse de date – e.g., fişiere text, baze de date, documente XML, multimedia etc. – disponibile pe acel server sau pe alte calcula-toare. Maniera de includere a codului menit să proceseze datele şi să genereze reprezen-tări destinate clientului depinde de serverul de aplicaţii folosit. Drept exemple, putem da <% ... %> pentru ASP, ASP.NET şi JSP, <?php ... ?> în cazul PHP şi, mai general, <script language= "...">...</script>.

73


Un server de aplicaţii Web pune la dispoziţie un cadru de lucru oferind următoarele fa-cilităţi.

În primul rând oferă posibilitatea folosirii unui limbaj sau o suită de limbaje de pro-gramare – pentru ASP, se poate recurge la JScript şi VBScript (un dialect ECMAScript), interpretate pe partea de server, iar în cazul ASP.NET la limbajele .NET oferite (ASP.NET este independent de limbaj, programarea putându-se realiza în oricare din limbajele suportate de .NET Framework: C#, J#, Perl.NET, VB.NET şi multe altele). De asemenea, se poate folosi Java (via servlet-uri şi JSP) sau Python (pentru Zope).

Al doilea aspect priveşte recurgerea la funcţionalităţile oferite de API-ul de bază – aceasta are legătură cu utilizarea „puterii” limbajului şi a cadrului de lucru (e.g., folosirea de funcţii/clase predefinite). În funcţie de mediu, se poate asigura migrarea relativ facilă de la aplicaţii clasice la cele destinate Web-ului. În plus, pot fi puse la dispoziţie facilităţi referitoare la accesul la resurse, consistenţă şi siguranţă. Un alt aspect important este cel al asigurării independenţei de platformă. Funcţionalităţile incluse în API-ul de bază nu ar trebui să necesite recompilarea serverului de aplicaţii (acolo unde se poate). Există două mari puncte de vedere: existenţa unei pleiade impresionante de funcţii predefinite (cazul PHP, de exemplu) sau oferirea unei fundaţii de ierarhii de clase, uneori chiar independen-te de limbaj (vezi ASP.NET CLR – Common Language Runtime).

Al treilea avantaj este suportul pentru bazele de date – se oferă acces robust la diverse servere de baze de date, eventual folosindu-se interfeţe standardizate, precum ADO (Ac-tive Database Objects) sau JDBC (Java DataBase Connectivity). Pentru PHP, există funcţii predefinite pentru o pleiadă de servere de baze de date, majoritatea relaţionale, via biblio-teci incorporate (e.g., SQLite şi mysqli în PHP5) sau extensii, în plus putându-se folosi in-terfaţa ODBC. „Legarea” datelor de codul-program (data binding) poate fi realizată auto-mat (e.g., ASP.NET) sau manual (PHP). Eventual, se pot folosi framework-uri adiţionale (pentru Java, un exemplu fiind Hibernate).

Un alt aspect important e suportul pentru interacţiunea Web – pot fi utilizate controale Web disponibile pe server, fie emulând câmpurile din formularele HTML, fie oferind elemente interactive noi (e.g., calendarul). Unele medii, ca ASP.NET sau PHP5 via PRA-DO, permit astfel generarea de cod HTML (plus JavaScript) în funcţie de clientul Web. ASP.NET oferă şi un model de procesare a evenimentelor provenind de la client, permi-ţând scrierea de aplicaţii conduse de evenimente (event driven Web applications). Pe acest model se bazează şi PRADO, implementat în PHP5. De asemenea, se pot folosi unele framework-uri suplimentare oferind suport pentru AJAX.

De asemenea, de interes sunt facilităţile acordate procesării de documente XML – în mod natural, trebuie puse la dispoziţie modalităţile de prelucrate via DOM şi SAX, even-tual folosind o interfaţă simplificată (ASP.NET şi PHP5). Pot fi suportate şi alte tipuri de procesări, precum XPP pentru Java. Pentru o parte dintre servere, se poate realiza şi vali-darea (în ASP.NET şi JSP există clase de validare prin scheme XML şi DTD). De aseme-nea, se pot efectua transformări XSL şi „legări” ale datelor (XML data binding). Orice ser-

74


ver de aplicaţii Web la momentul actual acordă suport pentru implementarea şi invocarea de servicii Web.

Un aspect interesant este cel privitor la recurgerea la medii de dezvoltare – unele dintre ele sunt deosebit de sofisticate, încadrându-se în una dintre categoriile: comerciale (Delphi, Visual Studio .NET, JBuilder, Zend etc.), gratuite (Eclipse, NVU, WebMatrix şi altele), de evaluare/educaţionale (Kylix, Visual Express etc.). De asemenea, pot fi utilizate diverse depanatoare, utilitare de calcul al execuţiei (profilers) şi optimizatoare de cod. Sunt acordate şi facilităţi pentru dezvoltatorii de servicii Web, plus pot fi folosite clase, com-ponente şi biblioteci adiţionale, disponibile în regim comercial, gratuit sau open source.

Alt aspect este reprezentat de suportul acordat inginerilor software – aplicaţiile Web sunt de cele mai multe ori structurate pe mai multe niveluri (N-tier), unele framework-uri încurajând folosirea şabloanelor de proiectare (design patterns). De asemenea, se poate re-curge şi la unităţi de testare automată (e.g., JUnit, PHP Unit etc.), iar unele medii prezintă modalităţi de generare automată de documentaţii, în diverse formate.

De asemenea, se pot pune la dispoziţie şi alte facilităţi. De pildă, se poate oferi suport pentru dezvoltarea de aplicaţii Web complexe: descrierea atributelor unei pagini sau ale unui sit (vizând limbajul, importul de resurse, sesiunile Web, tratarea evenimentelor, tipul conţinutului etc.), modul de autentificare, tema vizuală (skin), şabloane de redare (template-uri) etc. Aplicaţiile Web pot folosi şi containere de componente, precum (Enterprise) Java Beans.

75


2. Standardul CGI (Common Gateway Interface)

Standard pentru interacţiunea clienţilor Web cu serverele Web, Common Gateway Interface se află în prezent la versiunea 1.1. Un program CGI, numit în mod uzual script, se execută pe serverul WWW, fie în mod explicit (apelat din cadrul paginii printr-o directivă specia-lă), fie la preluarea informaţiilor aflate în cadrul câmpurilor unui formular interactiv sau coordonatelor unei zone senzitive (image map).

Acest standard conferă interactivitate paginilor Web, documentele HTML putând ast-fel să-şi modifice în mod dinamic conţinutul şi să permită prelucrări sofisticate de date.

Programele CGI pot fi scrise în orice limbaj, fiind interpretate (cazul Perl, Tcl, script-uri shell Unix) sau compilate (C, C++, Delphi). Regulile care trebuie respectate la conce-perea unui program CGI sunt:

• programul scrie datele la ieşirea standard (stdout); • programul generează antete care permit serverului Web să interpreteze corect ie-

şirea script-ului (folosindu-se specificaţiile protocolului HTTP).

Cele mai multe script-uri CGI sunt concepute pentru a procesa datele introduse în formulare. Un formular se defineşte în XHTML folosindu-se tag-uri specifice pentru afi-şarea conţinutului şi introducerea datelor de către client, iar script-ul CGI, executat de server, va prelua conţinutul acelui formular şi-l va prelucra, returnând, eventual, rezultate-le.

Antetul trimis serverului de către programul CGI va respecta specificaţiile MIME, conţînând de exemplu Content-type: text/html (document HTML) sau Content-type: image/jpeg (imagine JPEG) ori Content-type: text/plain (text obişnuit).

Programului CGI i se vor transmite în diverse variabile de mediu sau de la intrarea standard informaţii referitoare la datele de procesat sau la clientul care a iniţiat cererea (de exemplu, SERVER_PORT, REQUEST_METHOD, SCRIPT_NAME, QUERY_STRING, REMOTE_HOST etc.) în funcţie de metoda de transfer utilizată.

Oricare program CGI va putea dispune de valorile următoarelor variabile de mediu, dintre care menţionăm:

• REQUEST_METHOD specifică metoda prin care va fi formulată cererea: GET, POST, PUT etc.

• QUERY_STRING conţine toate informaţiile de după caracterul "?" din URL-ul care referă script-ul CGI, informaţii care vor trebui decodificate de acel script.

• REMOTE_HOST indică maşina-gazdă care a formulat cererea (calculatorul care a apelat script-ul CGI prin intermediul unei pagini Web).

• REMOTE_ADDR furnizează adresa IP a clientului care a formulat cererea, asociată adresei simbolice date de REMOTE_HOST.

76


• CONTENT_TYPE indică tipul conţinutului datelor vehiculate, pentru cererile care au ataşate informaţii suplimentare, precum PUT sau POST (de exemplu, pentru un formular transmis prin metoda POST, normal ar trebui ca variabila CON-TENT_TYPE să aibă valoarea application/x-www-form-urlencoded).

• CONTENT_LENGTH conţine numărul de octeţi ai datelor trimise de client.

Suplimentar, liniile antet (dacă există) recepţionate de la client prin intermediul proto-colului HTTP vor fi plasate în variabile de mediu având numele prefixate de HTTP_. Ca exemple de astfel de variabile, pot fi amintite:

• HTTP_ACCEPT indică tipurile MIME pe care le va accepta clientul, fiecare tip fiind despărţit de virgulă aşa cum specifică protocolul HTTP: tip/subtip,

tip/subtip. • HTTP_USER_AGENT furnizează numele şi versiunea browserului Web care a for-

mulat cererea, în formatul general: software/versiune bibliote-

ca/versiune.

Următorul script Perl va afişa toate variabilele de mediu la care are acces prin inter-mediul interfeţei CGI:

#!/usr/bin/perl

# Afişează mediul

print "Content-type: text/plain\n\n";

print "Environment:\n\n";

foreach $key (keys %ENV) {

printf "%16s = %s\n", $key, $ENV{$key};

}

Variabila predefinită ENV este un tablou asociativ conţinând perechile (nume de variabi-la de mediu, valoarea variabilei).

Un script CGI similar, scris în bash (Bourne Again Shell), este:

#!/bin/bash

# Afişează mediul

echo "Content-type: text/plain"

echo

set

Un posibil rezultat al execuţiei programului de mai sus poate fi:

HTTP_ACCEPT_LANGUAGE=en

SERVER_SIGNATURE=<ADDRESS>Apache/1.3.12 Server at endirra.ro

Port 80</ADDRESS>

SCRIPT_FILENAME=/home/httpd/cgi-bin/env.pl.cgi

HTTP_ACCEPT_CHARSET=iso-8859-1,*,utf-8

HTTP_PRAGMA=no-cache

SERVER_NAME=endirra.ro

77


HTTP_CONNECTION=Keep-Alive

REMOTE_ADDR=127.0.0.1

REQUEST_URI=/cgi-bin/env.pl.cgi

HTTP_HOST=endirra

REMOTE_PORT=1041

REQUEST_METHOD=GET

GATEWAY_INTERFACE=CGI/1.1

QUERY_STRING=

SERVER_ADDR=127.0.0.1

SERVER_SOFTWARE=Apache/1.3.12 (Unix)

(Red Hat/Linux) PHP/4.3.15

SERVER_PROTOCOL=HTTP/1.0

SERVER_PORT=80

DOCUMENT_ROOT=/home/httpd/html

HTTP_USER_AGENT=Mozilla/7.0 [en] (X11; U; Linux i686)

HTTP_ACCEPT=image/gif, image/x-xbitmap,

image/jpeg, image/png, */*

SCRIPT_NAME=/cgi-bin/env.pl.cgi

[email protected]

HTTP_ACCEPT_ENCODING=gzip

Un program CGI scris în limbajul C standard care generează o pagină Web conţinând mesajul „Salut!”.

/*

salut-cgi.c

Generează o pagină Web conţinând mesajul 'Salut!'

*/

#include <stdio.h>

void main()

{

/* trimite în primul rând antetul HTTP referitor la

tipul de date returnate de script */

printf("Content-type: text/html\n\n");

/* început de document HTML */

printf("<html>");

/* antet de pagină */

printf("<head><title>Salut!</title></head>\n");

/* corp de pagină */

printf("<body>\n");

printf("<p>Salut!</p>\n");

printf("</body></html>");

/* terminare program */

}

Pentru a fi însă efective, programele CGI trebuie apelate (implicit sau explicit) din ca-drul paginilor Web.

78


De cele mai multe ori, un script CGI va fi invocat din cadrul unui formular XHTML la apăsarea butonului de trimitere a datelor către server (butonul de tip submit).

Să presupunem că avem următorul exemplu în care un utilizator introduce prin inter-mediul unui formular două numere întregi, iar programul CGI va genera o pagină Web conţinând maximul dintre ele.

Formularul XHTML va fi:

<form action="http://www.infoiasi.ro/cgi-bin/max.cgi"

method="GET">

<p>Vă rugăm, introduceţi două numere:

<input name="nr1" size="5" />

<input name="nr2" size="5" />

<p></p>

<input type="submit" value="Află maximul" />

</form>

De exemplu, introducând numerele 7 şi 4 şi acţionând butonul etichetat „Află maxi-mul”, vom primi o pagină Web care va afişa textul „Maximul dintre 7 şi 4 este numărul 7” (vezi figura de mai jos).

Introducerea datelor şi obţinerea rezultatului după acţionarea butonului de trimitere a datelor pentru prelucrare

Care este mecanismul prin care funcţionează interfaţa CGI?

Presupunând că în cele două câmpuri ale formularului (purtând numele nr1 şi respectiv nr2) am introdus valorile 7 şi 4 respectiv şi am apăsat butonul submit, navigatorul va trimi-te, prin intermediul protocolului HTTP, o cerere către serverul Web aflat la adresa dată de URL-ul http://www.infoiasi.ro (adresa este preluată din valoarea atributului

79


action din <form>). Desigur, în loc de o adresă absolută, putea fi specificată o cale rela-tivă, însemnând faptul că se foloseşte serverul pe care se găseşte pagina conţinând formu-larul.

Atunci când se trimite cererea HTTP, navigatorul construieşte un URL având ca sufix informaţii despre datele introduse în câmpurile formularului, în cazul nostru http://www.infoiasi.ro/cgi-bin/max.cgi?nr1=7&nr2=4 folosindu-se o codifica-re specială. Pentru fiecare câmp al formularului, se va genera o pereche nume_câmp=valoare delimitată de caracterul „&”, iar caracterele speciale (ca de exem-plu slash-ul sau apostroful) vor fi înlocuite de codul lor numeric, în hexazecimal, precedat de caracterul procent („%”). În unele implementări,. spaţiile vor fi substituite de semnul plus („+”). De exemplu, pentru a trimite textul Cina de la Maxim's se va folosi codificarea Cina+de+la+Maxim%27s.

Serverul spre care cererea a fost expediată va procesa datele recepţionate conform re-gulilor proprii. Tipic, configuraţia serverului defineşte unde sunt stocate în cadrul siste-mului de fişiere directoarele şi fişierele CGI. De cele mai multe ori, daemonul HTTP (adică serverul Web) rulează pe maşină sub auspicii de utilizator fictiv (din raţiuni de se-curitate ca nobody, în mod uzual), fişierele sale fiind stocate de obicei în directorul /home/httpd/ sau /var/www/html (în cazul unui sistem Unix/Linux). Aici, alături de directorul html unde se memorează documentele HTML ale unui sit Web, se află şi di-rectorul cgi-bin unde ar trebui să fie stocate toate fişierele (script-urile) CGI apelate din cadrul paginilor Web. Aşadar, http://www.infoiasi.ro/cgi-bin/max.cgi va în-semna pentru serverul Web de la adresa www.infoiasi.ro următoarea acţiune: invocă programul max.cgi aflat la /home/httpd/cgi-bin. Astfel, în loc să trimită către naviga-torul Web care a iniţiat cererea HTTP un document HTML sau un fişier de alt tip, serve-rul va invoca programul ori script-ul CGI specificat în cadrul URL-ului (în acest caz max.cgi) şi-i va pasa datele furnizate de sufix, de după semnul întrebării (adică şirul nr1=7&nr2=4).

Acţiunea de invocare va avea o semantică diferită în funcţie de script-ul sau programul CGI conceput. Pentru un script Perl, serverul va invoca un interpretor Perl (în cazul Apache, poate fi un modul special mod_perl; de fapt, pentru a permite execuţia de pro-grame CGI, serverul Apache se va folosi de serviciile modulului mod_cgi). Pentru un program executabil (compilat de pildă într-unul din limbajele C sau C++), serverul va lansa programul ca un proces separat.

Extensia de fişier .cgi nu are nici o relevanţă în general, dar pot exista diverse reguli de numire a fişierelor CGI executabile dependente de server sau de sistemul de operare pe care rulează.

Detalii privitoare la programarea CGI în limbajele bash si Perl sunt disponibi-le în cartea S. Buraga et al., Programare Web în bash şi Perl, Polirom, Iaşi, 2002: http://www.infoiasi.ro/~cgi/.

80


Un studiu de caz: procesarea prin SAX a unui document XML via un script CGI

În cadrul acestei secţiuni, vom urmări în continuare să prelucrăm documentele XML via script-urile Perl, în vederea transformării lor în pagini Web.

Transformarea unui document XML în pagină Web prin intermediul unui script Perl

Una dintre cele mai facile modalităţi de a prelucra documentele XML este cea a utiliză-rii analizorului Expat dezvoltat de James Clark, a cărui funcţionalitate este încapsulată de modulul XML::Parser. Acest modul va pune la dispoziţie obiectele XML::Parser şi XML::Parser::Expat.

După cum deja ştim, procesarea SAX este bazată pe evenimente, fiecare tip de nod al arborelui asociat documentului XML declanşându-se un anumit eveniment care va trebui tratat de o rutină Perl specificată de programator. Astfel, după iniţializarea analizorului, va trebui să folosim metoda setHandlers pentru a stabili ce funcţii vor fi apelate pentru fiecare tip de eveniment.

Cele mai importante evenimentele generate de procesorul XML sunt:

• Start – indică apariţia tag-ului de început al unui element;

• End – desemnează apariţia tag-ului de sfârşit al unui element;

• Char – indică apariţia conţinutului text al unui element (caracterele de text neprocesat dintre tag-ul de început şi cel de sfârşit);

• Comment – indică apariţia unui comentariu.

Vom asocia pentru evenimentele Start, End şi Char câte o subrutină care va fi apelată la fiecare apariţie a evenimentului în cauză.

Documentul XML biblio.xml care urmează stochează informaţii despre împrumu-turile dintr-o bibliotecă:

<?xml version="1.0" ?>

<imprumuturi>

<imprumut>

<carte autor="J.P. Sartre" an="1999">

81


Zidul

</carte>

<client adresa="[email protected]">

Victor Tarhon-Onu

</client>

</imprumut>

<imprumut>

<carte autor="H. Hesse" an="1998">

Jocul cu margelele de sticla

</carte>

<client adresa="[email protected]">

Stefan Ciprian Tanasa

</client>

</imprumut>

</imprumuturi>

Dorim să generăm un tabel XHTML cu aceste informaţii, prin transformarea docu-mentului XML de mai sus. Vom scrie următorul script Perl, în care vom substitui fiecare element XML cu elementele XHTML corespunzătoare (aceste substituţii vor fi stocate în tablouri asociative):

#!/usr/bin/perl

# utilizam modulul XML

use XML::Parser;

# definim tablourile hash de inlocuire a tag-urilor

# definim substitutiile de tag-uri de inceput

%start = (

"imprumuturi" => "<table border=\"1\">",

"imprumut" => "<tr>",

"carte" => "<td><b>",

"client" => "<td align=\"center\">"

);

# definim substitutiile de tag-uri de sfirsit

%sfirsit = (

"imprumuturi" => "</table>\n",

"imprumut" => "</tr>",

"carte" => "</b></td>",

"client" => "</td>"

);

# instantiem analizorul XML

my $parser = new XML::Parser(ErrorContext => 2);

# setam functiile de prelucrare

# a elementelor si continutului lor

$parser->setHandlers(

Start => \&procesare_start,

82


# functia de procesare tag-uri de inceput

End => \&procesare_sfirsit,

# functia de procesare tag-uri de sfirsit

Char => \&procesare_continut

# functia de procesare a continutului

);

# afisam antetul HTTP

print "Content-type: text/html\n\n";

# incarcam fisierul si il analizam

$parser->parsefile("biblio.xml");

# definim subrutinele pentru prelucrarea

# elementelor XML si continutului lor

sub procesare_start

{

# primul argument este instanta procesorului XML

my $procesor = shift;

# al doilea argument este numele elementului

# corespunzator tag-ului de inceput

my $element = shift;

# afisam codul HTML, folosind tabloul hash

print $start{$element};

}

sub procesare_sfirsit

{

# primul argument este instanta procesorului XML

my $procesor = shift;

# al doilea argument este numele elementului

# corespunzator tag-ului de sfirsit

my $element = shift;

# afisam codul HTML, folosind tabloul hash

print $sfirsit{$element};

}

# rutina de afisare a continutului

sub procesare_continut

{

# am preluat argumentele furnizate

my ($procesor, $data) = @_;

# afisam datele

print $data;

}

Funcţiile asociate evenimentelor de procesare XML vor primi drept argumente instan-ţa procesorului Expat şi numele elementului curent (pentru evenimentele Start şi End) sau conţinutul dintre tag-urile de început şi de sfârşit (pentru evenimentul Char).

83


Ieşirea script-ului prezentat mai sus este:

Content-type: text/html

<table border="1">

<tr>

<td><b>

Zidul

</b></td>

<td align="center">

Victor Tarhon-Onu

</td>

</tr>

<tr>

<td><b>

Jocul cu margelele de sticla

</b></td>

<td align="center">

Stefan Ciprian Tanasa

</td>

</tr>

</table>

84


3. PHP (PHP: Hypertext Preprocessor)

PHP (PHP: Hypertext Preprocessor) a fost gândit iniţial a fi o simplă aplicaţie CGI pentru interpretarea formularelor definite prin HTML şi procesate de un program scris într-un limbaj (e.g., C, Perl), executat pe server. În cazul interfeţei CGI aveam nevoie de permisiunea de a rula programe pe server, ceea ce conducea uneori la lacune în securitate şi în plus la disocierea de documentul HTML a programului care procesa datele.

PHP (în versiunea curentă PHP 4; în paralel, este disponibilă şi versiunea PHP 5) re-prezintă un pachet puternic care oferă un limbaj de programare accesibil din cadrul fişie-relor HTML, limbaj asemănător cu Perl sau C, având în plus suport pentru manipularea bazelor de date într-un dialect SQL (dBASE, Informix, MySQL, mSQL, Oracle, PostgreSQL, Solid, Sybase, ODBC etc.) şi acces la sisteme hipermedia precum Hyperwave. De asemenea, PHP suportă încărcarea fişierelor de pe calculatorul client: upload şi oferă suport pentru cookies (mecanism, pe care îl vom prezenta ulterior, de stoca-re a datelor în navigatorul client pentru identificarea utilizatorilor).

Această aplicaţie este disponibilă gratuit, integrându-se în popularul server Apache. În fapt, PHP reprezintă un server flexibil pentru dezvoltarea de aplicaţii Web sofisticate, alături de altele comerciale.

În ceea ce urmează vom prezenta numai o parte dintre facilităţile oferite de PHP, fără a intenţiona să realizăm un manual complet de programare şi de utilizare.

Mai multe detalii, inclusiv studii de caz complete, sunt disponibile în volumele:

S. Buraga (coord.), Aplicaţii Web la cheie. Studii de caz implementate în PHP, Polirom, Iaşi, 2003: http://www.infoiasi.ro/~phpapps/

S. Buraga (coord.), Situri Web la cheie. Soluţii profesionale de implementare, Polirom, Iaşi, 2004: http://www.infoiasi.ro/~busaco/books/webapps/

Caracterizare

Script-urile PHP pot fi incluse în paginile Web în diferite moduri, aşa cum arată exemplul de mai jos:

<? echo ("cea mai simplă cale de introducere...\n"); ?>

<?php echo ("se utilizează în cazul documentelor XML.\n"); ?>

<script language="php">

echo ("anumite editoare nu acceptă tag-uri necunoscute");

</script>

<% echo ("opţional se pot folosi tag-uri în stilul ASP"); %>

Comentariile pot fi scrise în stilul comentariilor din limbajele C, C++ sau shell-urile Unix (adică se pot folosi /* ... */, //... sau #...).

85


Preprocesorul PHP va determina construcţiile PHP delimitate între tag-urile de mai sus şi le va interpreta, ignorând restul conţinutului documentului pe care îl va trimite, la ieşi-rea standard, nealterat. Astfel, putem privi analizorul PHP ca un script CGI care efectu-ează o preprocesare specială înainte ca datele să fie expediate clientului Web.

Instrucţiunile de control ale limbajului sunt cele uzuale din C (if, break, while şi altele). Pentru instrucţiunea if, testul se evaluează ca fiind false şi în cazul în care rezultatul expre-siei de test va fi şirul vid ("") sau va fi şirul "0". Variabilele se declară „din zbor”, tipul lor putând fi, de exemplu, integer, double sau string, iar numele de variabile trebuie precedat de caracterul „$”. Şirurile de caractere se pot delimita între ghilimele sau apostroafe, în acest ultim caz inhibându-se evaluarea variabilelor din interiorul şirului respectiv (exact ca la script-urile bash).

Pot fi definite de asemenea şi tablouri (indexate sau asociative, ca în Perl). Există şi di-verse variabile predefinite, mai ales cele specifice serverului Web, similare variabilelor de mediu disponibile script-urilor CGI (e.g., $REMOTE_ADDR). Sunt permişi operatorii obişnu-iţi ai limbajului C şi se pot defini şi funcţii utilizator (prin construcţia function). Un ope-rator preluat din Perl este cel de concatenare a şirurilor de caractere, specificându-se prin intermediul caracterului punct „.”.

PHP pune la dispoziţia programatorului şi o serie de constante predefinite (ca de exemplu, PHP_VERSION, TRUE şi FALSE).

Pentru a experimenta exemplele de programe date în continuare, recomandăm să insta-laţi mediul Apache2Triad, care pune la dispoziţie, printre altele, – pe platforma Windows – serverele Apache, MySQL şi PHP, deja configurate pentru lucru. Apache2Triad este dis-ponibil pentru download la adresa http://apache2triad.sourceforge.net/.

Funcţionarea procesorului PHP

Un exemplu de lucru cu tablouri

Acest exemplu ilustrează folosirea tablourilor indexate, a instrucţiunii de ciclare foreach şi a generării de conţinut XHTML spre a fi transmis către browser-ul Web.

86


<?php // umplem un tablou cu valori de la 1 la 10 for ($contor = 1; $contor <= 10; $contor++) { $valori[$contor] = $contor; } // realizam suma valorilor $suma = 0; foreach ($valori as $element) $suma += $element; // afisam suma obtinute la iesirea standard // pentru a fi trimisa browserului echo ("<p>Suma de la 1 la 10 este: <b>" . $suma . "</b></p>"); ?>

Un exemplu de definire şi folosire a funcţiilor specificate de utilizator

Următoarele linii PHP oferă detalii privitoare la modul de creare şi de utilizare a funcţiilor definite de utilizator:

<?php // functia de ridicare la patrat function patrat($numar) { return $numar * $numar; } $numar = 0; while ($numar < 10) { $numar++; // incrementam numarul if ($numar % 2) // e numar impar... continue; // continuam cu urmatoarea iteratie // e numar par, deci afisam patratul echo "<p>$numar la patrat este " . patrat($numar) . "</p>"; } ?>

Un exemplu de prelucrare a formularelor electronice

Puterea limbajului PHP constă şi în manipularea facilă a formularelor, după cum vom vedea în continuare.

Presupunem că definim următorul formular folosit de utilizatori pentru a introduce di-verse impresii despre o pagină Web personală:

<html> <head> <title>Impresii</title> </head> <body text="blue" bgcolor="white"> <form action="add.php" method="POST" name="Form"> <table align="center" cellpadding="4"> <tr> <td> <p>Numele şi prenumele:</p> </td> <td> <input type="text" name="nume" />

87


</td> </tr> <tr> <td> <p>Ocupaţia:</p> </td> <td> <select name="ocupaţia" size="1"> <option selected>Student</option> <option>Elev</option> <option>Cadru didactic</option> <option>Altceva</option> </select> </td> </tr> <tr> <td> <p>Vârsta:</p> </td> <td> <p> <input type="radio" value="sub 18" name="virsta">sub 18 | <input type="radio" value="18-25" name="virsta" checked>18-25 | <input type="radio" value="25-35" name="virsta">25-35 | <input type="radio" value="35-60" name="virsta">35-60 | <input type="radio" value="peste 60" name="virsta">peste 60 </td> </tr> <tr> <td> <p>Adresa e-mail:</p> </td> <td> <input type="text" name="email"> </td> </tr> <tr> <td> <p>Impresiile d-voastră:</p> </td> <td> <textarea name="impresii" rows="3" cols="60"> </textarea> </td> </tr> <tr> <td> <input type="submit" value="Trimite"> </td> <td> <input type="reset" value="Şterge"> </td> </tr> </table> </form> </body> </html>

88


Se solicită utilizatorului numele, ocupaţia, vârsta, adresa de e-mail şi impresiile care vor fi procesate de programul (script-ul) PHP conţinut în fişierul add.php. Acesta ar putea cu-prinde următoarele:

<html> <body> <? if(!$nume || !$email) { // nu s-au introdus numele sau adresa ?> <h4 style="color: red" align="center"> Eroare: nu aţi specificat numele sau adresa! </h4>" <p align="center">Corectaţi <a href="javascript:history.go(-1)"> formularul</a></p> <? } else { ?> <h4 style="color: green" align="center"> Formularul introdus </h4> <hr /> <? // crează un mesaj pentru a fi expediat şi prin e-mail $mesaj = ""; // data curentă $mesaj .= "<impresie data=\"" . date("d M Y, G:i"); $mesaj .= "\" client=\"" . $REMOTE_HOST . "(" . $REMOTE_ADDR . ")\">\n"; // concatenează numele, adresa, ocupaţia şi impresiile $mesaj .= "<nume email=\"" . $email . "\">" . $nume . "</nume>\n"; $mesaj .= "<ocupatia>" . $ocupaţia . "</ocupaţia>\n"; $mesaj .= "<virsta>" . $virsta . "</virsta>\n"; // există impresii? if ($impresii) $mesaj .= "<text>\n" . $impresii . "\n</text>\n</impresie>\n"; // trimite e-mailul (adresa, subiect, corp-mesaj, destinatar) mail("[email protected]", "Impresii", $mesaj, "From: " . $email); // scrie şi într-un fişier $f = fopen("impresii.xml", "a"); if (!$f) echo ("<p>Eroare la deschiderea fişierului!</p>"); else { fputs($f, $mesaj); fclose($f); } // scrie şi în pagină (convertind NL cu <br>), // dar tag-urile XML nu vor fi recunoscute de navigator $mesaj_html = nl2br($mesaj); echo ("<center>$mesaj_html</center>"); }

89

?>  <hr /> </body> </html>

Script-ul PHP va expedia prin poşta electronică, unui anumit utilizator, datele introdu-se în formular, prin intermediul funcţiei predefinite mail(), şi va genera un fişier numit impresii.xml cuprinzând impresiile enunţate de vizitatorii paginii.

Un fragment dintr-un astfel de fişier XML este dat mai jos:

... <impresie data="01 Nov 2006, 11:33" client="fenrir.infoiasi.ro (193.231.30.197)"> <nume email="[email protected]">Radu Filip</nume> <ocupatia>Student</ocupatia> <virsta>18-25</virsta> <text> Salut!... Ce mai faci? </text> </impresie> <impresie data="02 Nov 2006, 18:42" client="localhost (127.0.0.1)"> <nume email="[email protected]">Luminiţa Chiran</nume> <ocupaţia>Cadru didactic</ocupaţia> <virsta>25-35</virsta> <text> Îmi place, însă cred că ar fi trebuit să pui şi ceva referitor la adnotarea lingvistică (e.g. TEI). Luminiţa </text> </impresie> ...

După cum se observă, PHP oferă un limbaj script puternic şi simplu, accesul la câm-purile formularului realizându-se prin intermediul unor variabile create automat. În cazul câmpurilor checkbox ale unui formular, nu se creează variabile decât pentru câmpurile bi-fate. Dacă nu apare atributul value pentru un buton checkbox, atunci valoarea variabilei corespunzătoare lui va fi setată automat pe „on”.

Atenţie! Ultimele versiuni de PHP interzic folosirea variabilelor globale pentru a avea acces direct la datele din formulare, transmise de către clientul Web. Astfel, se va folosi, în loc de $nume, construcţia $_REQUEST["nume"].

În PHP există, de asemenea, o multitudine de funcţii predefinite (o serie fiind similare funcţiilor din bibliotecile standard ale limbajului C) – detalii la www.php.net (situl oficial al serverului de aplicaţii PHP; tot în cadrul sitului aveţi posibilitatea să obţinem manualul PHP, în diverse formate):

– matematice;

– de conversie;

– de manipulare a şirurilor de caractere;

90


– de prelucrare a tablourilor;

– de acces la resursele sistemului de operare şi de lucru cu fişiere;

– de manipulare a bazelor de date;

– privitoare la conexiunile Internet (HTTP, FTP);

– pentru accesarea fişierelor având tipuri speciale: PDF, JPEG, XML etc.;

– specifice sistemului de operare;

– generale.

Programare orientată-obiect în PHP

Limbajul PHP oferă implementarea unora dintre cele mai importante aspecte ale pro-gramării obiectuale: încapsularea datelor, moştenirea, polimorfismul. Astfel, PHP dă po-sibilitatea programatorului să exprime distincţia dintre proprietăţile generale şi cele speci-fice ale obiectelor cu care lucrează. Vom ilustra aceste caracteristici prin câteva exemple concludente.

Încapsularea

Încapsularea datelor reprezintă un mecanism de protecţie a membrilor de tip dată, acce-sul la ei realizându-se exclusiv prin intermediul unor metode specifice şi nu în mod direct. Acest lucru se realizează prin intermediul claselor, după cum se poate remarca din frag-mentul de cod PHP de mai jos:

<?php class Student { // date-membru var $year; // an var $age; // vârsta var $name; // nume // metode function setYear($y) { $this->year = $y; } function getYear() { return $this->year; } ... } ?>

Datele-membru se definesc utilizând var, putând avea orice tip (întreg, tablou sau chiar obiect). Metodele se specifică prin declaraţii de funcţii care prelucrează membrii clasei. Pentru a accesa datele clasei, metodele vor trebui să se folosească de construcţia sintactică $this->variabila, altfel variabila se consideră a fi locală în cadrul acelei metode.

Vom crea un obiect prin operatorul new, exact ca în limbajul C++:

$stud = new Student;

91


Accesarea metodelor clasei se realizează astfel:

$stud->setYear(4); $student_year = $stud->getYear();

Din păcate, în PHP4, membrii dată ai clasei pot fi accesaţi direct, neputându-i declara privaţi. La fel, metodele nu pot fi specificate private sau protejate, aşa cum se întâmplă la C++. Astfel, PHP oferă doar suport pentru încapsulare, dar nu o poate impune. În versi-unea PHP 5 acest aspect a fost remediat.

Pentru funcţiile membru, în loc de construcţia sintactică „->”, în PHP 4 se permite „::”. Astfel, codul de mai sus este echivalent cu:

$student_year = $stud::getYear();

Moştenirea

Moştenirea reprezintă posibilitatea folosirii datelor sau metodelor definite în prealabil de o anumită clasă în cadrul unei clase derivate din prima. Relaţia de derivare se specifică prin cuvântul-cheie extends:

<?php class GoodStudent extends Student { // date-membru var $prizes; // premii // metode function setPrizes($p) { $this->prizes = $p; } function getPrizes() { return $this->prizes; } } ?>

Putem scrie următoarele linii:

$goodstud = new GoodStudent; // apel de metodă din clasa de bază $goodstud->setAge(21); // apel de metodă din clasa derivată $goodstud->setPrizes(2);

În PHP moştenirea multiplă nu este încă posibilă. Nu putem avea, de exemplu:

class GreatStudent extends GoodStudent Genius { ... }

Pentru a accesa membri ai clasei părinte ne vom folosi de construcţia „::” (exact ca şi în C++).

Constructori

PHP permite specificarea constructorilor, ei fiind metode cu acelaşi nume al clasei din care aparţin, fiind apelaţi automat atunci când instanţiem un obiect al clasei respective. Putem avea, de exemplu:

92


<?php class Student { // date-membru var $year; // an var $age; // vârsta var $name; // nume // constructor function Student($y, $a, $n) { $this->year = $y; $this->age = $a; $this->name = $n; } // metode function setYear($y) { $this->year = $y; } function getYear() { return $this->year; } ... } ?>

Aşadar, acum se poate crea un obiect de genul:

$stud = new Student(3, 24, "Radu Filip");

Constructorii şi metodele, fiind funcţii PHP obişnuite, pot avea specificate valori im-plicite pentru argumente (ca în C++):

function Student($y = "4", $a = "22", $n = "")

Dacă scriem în acest mod constructorul, atunci în următoarele cazuri vom avea:

// year = 4, age = 22, name = "" $stud = new Student(); // year = 2, age = 22, name = "" $stud = new Student(2); // year = 2, age = 20, name = "" $stud = new Student(2, 20);

Atunci când un obiect al unei clase derivate este creat, numai constructorul lui propriu va fi apelat, constructorul clasei de bază nefiind apelat implicit. Dacă dorim ca şi con-structorul clasei părinte să fie apelat, o vom face într-o manieră explicită:

<?php function GoodStudent { $this->prizes = 3; // apel explicit al constructorului clasei de bază $this->Student(); } ?>

Începând cu versiunea 4, tipurile permise pentru parametrii unui constructor sunt doar cele simple (întregi, şiruri de caractere), deci nu vor putea fi executate transmiteri de ta-blouri sau de obiecte.

Dacă o clasă derivată nu posedă propriul ei constructor, va fi apelat implicit construc-torul clasei părinte.

93


Mecanismul obiectual în PHP 4 nu permite declararea destructorilor şi nici specificarea de clase abstracte (deşi se pot imagina metode mai mult sau mai puţin sofisticate pentru a le simula). În PHP 5, există însă posibilitatea specificării destructorilor.

Supraîncărcarea

Supraîncărcarea (asocierea de semantici diferite unei aceleaşi funcţii pe baza tipurilor pa-rametrilor specificaţi) nu este suportată nici ea. Putem însă supraîncărca, indirect, con-structorii prin crearea de obiecte diferite în funcţie de numărul de argumente specificate:

<?php class Student { ... function Student() { // contruim un şir de apel $method_name = "Student" . func_num_args(); $this->$method_name(); } function Student1($x) { // cod } function Student2($x, $y) { // cod } ... } ?>

Vom putea scrie:

$stud1 = new Student('1'); // va apela Student1 $stud2 = new Student('1', '2'); // va apela Student2

Pentru a pasa un număr variabil de parametri unei funcţii şi a-i folosi ulterior putem să ne slujim de funcţiile predefinite func_get_args(), func_num_args() şi func_get_arg().

Astfel, metoda Student() de mai sus va putea afişa toţi parametrii transmişi prin co-dul următor:

function Student() { $args_array = func_get_args(); for ($i = 0; $i < count($args_array); $i++) print ($i => $argument_array [$i]); }

94


Polimorfismul

Polimorfismul reprezintă abilitatea unui obiect de a determina care metodă trebuie invo-cată pentru un obiect pasat ca argument în momentul rulării şi acest lucru se realizează foarte uşor în limbaje interpretate precum PHP.

Vom ilustra acest concept şi implementarea lui în PHP presupunând că avem o clasă Figure desemnând o figură geometrică în care se defineşte metoda draw() şi clasele derivate Circle şi Square unde vom rescrie metoda draw() în funcţie de figura dorită a fi desenată:

<?php ... function drawing($obj) { // metoda clasei Board $obj->draw(); } // coordonate centru şi raza $circle = new Circle(100, 100, 33); // coordonate stânga-sus şi latura $square = new Square(100, 200, 74); // afişează cele două figuri $board = drawing($circle); // apelează draw() din Circle $board = drawing($square); // apelează draw() din Square ... ?>

Funcţii utile pentru manipularea obiectelor

Începând cu PHP 4, se pun la dispoziţia programatorului o serie de funcţii folositoare:

– get_class() va returna numele unui obiect, instanţă a unei clase;

– get_parent_class() furnizează clasa părinte din care provine un anumit obiect;

– method_exists() testează dacă există o metodă pentru un anumit obiect specificat;

– class_exists() testează existenţa unei clase;

– is_subclass_of() va determina existenţa unei relaţii de moştenire dintre două clase.

O altă facilitate este cea a transmiterii prin referinţă a parametrilor şi nu prin valoare, cum se realizează în mod implicit. Pentru a fi transmis prin referinţă, vom prefixa numele acelui parametru cu caracterul „&”.

95


Accesarea bazelor de date

Cele de mai sus ne permit să definim un mecanism bazat pe obiecte pentru manipularea informaţiilor din bazele de date SQL. Pentru a accesa o bază de date (de oricare tip) va trebui să specificăm mulţimea minimală de membri (date şi metode) pe care să o încapsu-lăm într-o clasă generală:

class DataBase_SQL { // date-membru var $Link_ID = 0; // identif. legăturii cu o bază de date var $Query_ID = 0; // identif. interogării active var $error = 0; // starea de eroare // metode function connect() { ... } function query() { ... } function next_record() { ... } function num_rows() { ... } }

Metoda query() verifică existenţa unui $Link_ID valid care să pointeze spre o bază de date activă. Dacă nu există, query() va apela connect() pentru a stabili o legătură cu serverul SQL. Execuţia metodei query() va actualiza variabila $Query_ID şi metoda next_record() va putea furniza înregistrările găsite în urma invocării interogării SQL. Metoda num_rows() va returna numărul total de rânduri ale tabelei.

Accesând bazele de date prin clase, ne vine mult mai uşor să realizăm, de exemplu, do-uă interogări concurente asupra aceleaşi tabele, prin instanţierea obiectelor de mai jos:

$db1 = new DataBase_SQL; $db2 = new DataBase_SQL;

Folosind cele de mai sus, putem concepe o clasă care să ne faciliteze accesarea unei ba-ze de date MySQL. Astfel, vom defini clasa derivată:

class DataBase_MySQL extends DataBase_SQL { // date-membru var $Host = ""; // adresa serverului MySQL var $DataBase = ""; // numele bazei de date de pe server var $User = ""; // numele utilizatorului var $Password = ""; // parola utilizatorului var $Link_ID = 0; // rezultatul lui mysql_connect() // rezultatul celei mai recente mysql_query() var $Query_ID = 0; // rezultatul curent al lui mysql_fetch_array() var $Record = array(); var $Row; // numărul rândului curent var $Errno = 0; // starea de eroare a interogării var $Error = ""; // metode ... }

96


Pentru început trebuie să scriem codul care stabileşte conexiunea cu serverul de baze de date MySQL. În caz de eşec, va trebui să semnalăm acest lucru programului care ma-nipulează o instanţă a clasei noastre. Vom furniza în continuare metoda connect() care va utiliza funcţia auxiliară halt():

// opreşte execuţia în caz de eroare fatală function halt($msg) { printf("<p>Database error: %s\n", $msg); printf("<p>MySQL error: <b>%s (%s)</b>\n", $this->Errno, $this->Error); die("Session halted."); } // conectarea la baza de date function connect() { if ($this->Link_ID == 0) { // încă nu există o conexiune $this->Link_ID = mysql_connect($this->Host, $this->User, $this->Password); // succes sau eşec? if (!$this->Link_ID) $this->halt("Connect failed"); // deschide baza de date if (!mysql_query(sprintf("use %s", $this->DataBase), $this->Link_ID)) $this->halt("Cannot use database" . $this->DataBase); } }

Implementarea metodei query() poate fi următoarea:

// trimite o interogare serverului MySQL function query($query_str) { // realizează conectarea... $this->connect(); // încearcă să execute interogarea $this->Query_ID = mysql_query($query_str, $this->Link_ID); // iniţial stabilim pointerul pe prima înregistrare $this->Row = 0; // salvează erorile $this->Errno = mysql_errno(); $this->Error = mysql_error(); // eroare fatală? if (!$this->Query_ID) $this->halt("Invalid SQL: " . $query_str); return $this->Query_ID; }

Mai sunt necesare a fi specificate metodele next_record() şi seek():

// furnizează dacă mai există o înregistrare function next_record() { // salvează într-un tablou înregistrările $this->Record = mysql_fetch_array($this->Query_ID); $this->Row++; // salvează erorile $this->Errno = mysql_errno(); $this->Error = mysql_error();

97

// returnează înregistrarea găsită $stat = is_array($this->Record); if (!$stat) { // nu mai există o altă înregistrare mysql_free_result($this->Query_ID); // se eliberează interogarea $this->Query_ID = 0; } return $stat; } // furnizează o înregistrare după poziţia ei function seek($pos) { $status = mysql_data_seek($this->Query_ID, $pos); if ($status) $this->Row = $pos; return; }

În acest moment putem să realizăm o interogare particulară asupra unei baze de date MySQL conţinând informaţii despre studenţi. Pentru aceasta, trebuie să completăm pa-rametrii $Host, $DataBase, $User şi Password. Vom utiliza o clasă derivată Data-Base_Stud astfel:

class DataBase_Stud extends DataBase_SQL { var $Host = "localhost"; var $User = "busaco"; var $Password = ""; var $DataBase = "students"; }

Codul PHP pentru afişarea numelui şi vârstei tuturor studenţilor din anul IV este ur-mătorul:

<?php // instanţierea obiectului $db = new DataBase_Stud; // conectarea la serverul MySQL $db->connect(); // formulează interogarea SQL $query = "select name, age from students where year = 4"; $db->query($query); ?> <html> <body> <h3>Studenţii anului IV</h3> <hr>  <?php while($db->next_record()) { ?>  <p><b><?php print $db->Record["name"] ?></b></p>  <p><i><?php print $db->Record["age"] ?></i></p> <hr /> <?php } ?> </body> </html>

98


Firesc, înainte de a utiliza acest script, trebuie să creăm o bază de date MySQL pe care o vom numi stud, iar în cadrul acesteia vom genera o tabelă students conţinând informa-ţii despre studenţi (omitem răspunsurile sistemului după execuţia fiecărei comenzi SQL):

$ mysql -h localhost -u busaco -p Enter password: ******** mysql> create database stud; mysql> use stud; mysql> create table students( -> year int(1), -> name char(50), -> age int(2), -> id char(4), -> pic char(80) -> ); mysql> create unique index stud_idx on students ( id );

Ultima linie construieşte un index pe baza câmpului de identificare a unui student (id), index denumit stud_idx.

Deoarece sistemul de gestiune a bazelor de date lucrează în context multi-utilizator, va trebui să acordăm dreptul de acces asupra unei baze de date (de exemplu, pentru selecţia, inserarea şi ştergerea de înregistrări) prin intermediul comenzii SQL grant. Pentru ca utilizatorul busaco să se poată conecta la baza de date de pe sistemul local şi să poată executa comenzile SQL select, insert şi delete vom scrie:

mysql> grant usage on stud.* to busaco@localhost; mysql> grant select, insert, delete on stud.* to busaco@localhost;

În figura de mai jos putem observa operaţiunile efectuate în cadrul unei tranzacţii de date între navigator şi serverul Web, utilizându-se şi un server MySQL:

Executarea unei interogări SQL dintr-un script PHP

Paşii efectuaţi sunt:

1. Iniţierea de către navigator a unei conexiuni HTTP cu serverul Web;

2. Preprocesarea codului PHP de către interpretorul PHP;

3. Trimiterea interogării SQL conţinute de codul PHP spre serverul MySQL;

99


4. Returnarea rezultatelor interogării SQL;

5. Returnarea de către motorul PHP a codului HTML generat, în urma procesării întregului program PHP;

6. Trimiterea documentului HTML spre navigatorul Web.

În cadrul clasei DataBase_MySQL mai putem implementa următoarele metode utile:

// numărul de înregistrări găsite function num_rows() { return mysql_num_rows($this->Query_ID); } // numărul de câmpuri function num_fields() { return mysql_num_fields($this->Query_ID); } // valoarea unui câmp particular function get_field($field) { return $this->Return[$field]; }

Se pot imagina, de asemeni, clase similare şi pentru alte sisteme de management al ba-zelor de date (e.g., PostgreSQL, Oracle, ODBC).

Procesarea documentelor XML în PHP

Pentru a procesa documentele XML în cadrul programelor PHP, va trebui să avem la dispoziţie un analizor XML instalat pe server, de exemplu un procesor SAX sau DOM.

După cum deja am văzut, în cazul procesării prin SAX se declanşează un anumit eve-niment care va trebui tratat de o funcţie definită de programator. Pentru a ataşa funcţii evenimentelor XML, ne vom folosi de o serie de funcţii PHP predefinite:

• xml_set_element_handler() stabileşte funcţiile care vor fi apelate pentru procesarea elementelor XML (pentru tag-urile de început şi de sfârşit);

• xml_set_character_data_handler() stabileşte funcţia care va fi ape-lată atunci când analizorul întâlneşte un nod de tip CDATA (text);

• xml_set_processing_instruction_handler() defineşte funcţia care va fi executată la apariţia unei instrucţiuni de procesare.

Alte funcţii importante puse la dispoziţie sunt:

• xml_parser_create() iniţializează analizorul XML şi returnează o instanţă a sa;

• xml_parser_free() eliberează memoria alocată analizorului;

• xml_set_object() stabileşte adresele funcţiilor care vor fi utilizate de analizor pentru a realiza procesarea documentului XML dorit;

100


• xml_parser_set_option() se foloseşte la setarea unor opţiuni de ana-liză XML (e.g., modul de tratare a scrierii cu majuscule sau minuscule a tag-urilor);

• xml_get_error_code() furnizează codul de eroare în urma eşecului procesării.

Pot fi amintite, de asemenea, funcţiile dând mai multe amănunte despre erorile surve-nite în timpul analizei: xml_error_string() şi xml_get_current_line_number(). Funcţia xml_parse() returnează, în caz de eşec, o serie de coduri de eroare ale căror constante simbolice predefinite pot fi consultate în manualul PHP.

Vom defini o clasă pe care o vom folosi ulterior la procesarea documentelor XML (vom salva acest cod în fişierul parseXML.php).

<?php

// o clasă pentru prelucrarea documentelor XML

class parseXML {

var $xml_parser; /* instanţa analizorului XML */

var $xml_file; /* numele fişierului XML */

var $html_code; /* codul HTML generat */

var $open_tags; /* mulţimea tag-urilor de început */

var $close_tags; /* mulţimea tag-urilor de sfârşit */

// constructor

function parseXML() {

$this->xml_parser = "";

$this->xml_file = "";

$this->html_code = "";

$this->open_tags = array();

$this->close_tags = array();

}

// destructor

function destroy() {

if ($this->xml_parser)

xml_parser_free($this->xml_parser);

}

// metode

// setează tag-urile de început

function set_open_tags($tags) {

$this->open_tags = $tags;

}

// setează tag-urile de sfârşit

function set_close_tags($tags) {

$this->close_tags = $tags;

}

// setează numele fişierului XML

101


"start_element", "end_element");

xml_set_character_data_handler($this->xml_parser,

"character_data");

xml_set_processing_instruction_handler($this->xml_parser,

"processing_instruction");

// deschide fişierul XML

if (!($fp = fopen($this->xml_file, "r")))

die("could not open XML source");

// procesează fişierul

while ($data = fread($fp, 4096)) {

if (!xml_parse($this->xml_parser, $data, feof($fp))) {

// eroare de procesare

die(sprintf("XML error: %s at line %d",

xml_error_string(xml_get_error_code($this->xml_parser)),

xml_get_current_line_number($this->xml_parser)));

}

} /* while */

} /* parse() */

} /* class */

?>

Folosind această clasă, putem transforma un document XML în cod HTML, după cum se poate remarca din exemplul de mai jos, unde va fi prelucrat fişierul cu impresii despre un anumit sit Web şi va fi generat un tabel HTML.

Documentul XML conţinând impresii privitoare la un sit Web are structura de mai jos:

<impresie data="01 Nov 2006, 11:33"

client="fenrir.infoiasi.ro (193.231.30.197)">

<nume email="[email protected]">Radu Filip</nume>

<ocupatia>Student</ocupatia>

<virsta>18-25</virsta>

<text>

Salut!...

Ce mai faci?

</text>

</impresie>

Codul-sursă PHP este dat în continuare:

<?php

// necesită prezenţa clasei definite mai sus

require("parseXML.php");

// substituţia tag-urilor XML cu cod HTML

// se folosesc două tablouri asociative

$open_tags = array(

103

"impresii" => "\n\n" .

"<table>",

"impresie" => "<tr style=\"text-align: center\">",

"nume" => "<td><h4>",

"ocupatia" => "<td><p style=\"color: blue\">",

"virsta" => "<td><p><i>",

"text" => "<td><p class=\"text\">");

$close_tags = array(

"impresii" => "</table>\n" .

"\n",

"impresie" => "</tr>",

"nume" => "</h4></td>",

"ocupatia" => "</p></td>",

"virsta" => "</i></p></td>",

"text" => "</p></td>");

// instanţiază şi iniţializează analizorul

$parser = new parseXML();

$parser->set_xml_file("impresii.xml");

$parser->set_open_tags($open_tags);

$parser->set_close_tags($close_tags);

// rulează analizorul

$parser->parse();

// afişează rezultatul

echo $parser->get_html_code();

// distruge obiectul

$parser->destroy();

?>

Clasa definită este suficient de generală pentru a putea fi utilizată pentru orice tip de document XML. Tag-urile netratate de programul nostru vor fi ignorate.

De multe ori însă ar fi de dorit să realizăm anumite prelucrări asupra datelor stocate de fişierele XML. Putem încă să ne slujim de parseXML. De exemplu, am dori ca utilizatorul (sau autorul sitului) să poată trimite mesaje celor care şi-au lăsat impresiile. Pentru aceasta vom defini o clasă derivată din clasa parseXML şi vom redefini funcţiile start_element() şi end_element():

<?php

require("parseXML.php");

// folosirea moştenirii pentru a defini

// un alt comportament

class parseXML2 extends parseXML {

// indică dacă există atributul "email"

var $is_email = 0;

104


// redefinirea metodelor

function start_element($parser, $name, $attrs) {

// apelează metoda din clasa de bază

parseXML::start_element($parser, $name, $attrs);

// pune şi link spre adresa e-mail

if (!strcmp($name, "nume")) {

if ($attrs["email"]) {

$format = "<a title=\"Trimite mesaj la " .

$attrs["email"] .

"\" href=\"mailto:" . $attrs["email"] . "\">";


$this->is_email = 1;

}

else

$this->is_email = 0;

}

}

function end_element($parser, $name) {

// închide

if (!strcmp($name, "nume")) {

if ($this->is_email) {

$format = "";


}

}

// apelează metoda din clasa de bază

parseXML::end_element($parser, $name);

}

}

?>

Noul membru de tip dată is_email este folosit pentru a putea închide corect tag-urile elementului <a> (se poate întâmpla ca atributul email să nu apară). Restul codului rămâ-ne acelaşi, în loc de $parser = new parseXML() trebuind fi scrisă linia $parser = new parseXML2().

O posibilă rulare a script-ului PHP de mai sus poate avea ca efect pagina Web din cadrul capturii-ecran următoare:

105

Afişarea datelor XML în urma unei procesări SAX

Desigur, dacă facem numai prelucrări asupra documentelor XML, ne putem dispensa de definirea celor două tablouri asociative open_tags[] şi close_tags[], iar în funcţii-le startElement() şi endElement() putem insera orice cod dorim.

O altă metodă de procesare este descrisă în capitolul 4 al cărţii S. Buraga (coord.), Aplicaţii Web la cheie. Studii de caz implementate în PHP, Polirom, Iaşi, 2003.

Un exemplu complet de procesare DOM a unui document XML este furnizat în con-tinuare. Intenţionăm să procesăm conţinutul unui fişier XML referitor la proiectele pro-puse spre implementare studenţilor urmând disciplina „Reţele de calculatoare”. Acest document, numit projects.xml, va avea structura (evident, e oferit aici doar un frag-ment):



<p:projects xmlns:p="urn:infoiasi.ro:projects"

update="04 noiembrie 2004">

<project class="B">

106

<title>HangmanS</title>

<desc>

Sa se implementeze un server care sa permita...

</desc>

<stud>1</stud>

<url></url>

</project>

<project class="A">

<title>NetChatS</title>

<desc>

Sa se conceapa un server de chat.

</desc>

<stud>2</stud>

<url>http://www.infoiasi.ro/~busaco/gaen/</url>

</project>

<project class="A">

<title>Super Proiect</title>

<desc>

Un super proiect pentru niste super studenti!

</desc>

<stud>3</stud>

<url>http://www.super.org/</url>

</project>



</p:projects>

Pentru procesarea datelor, vom putea implementa următorul script PHP 4:

<?php

/* Un program PHP care procesează un document XML folosind DOM

Funcţionează pentru PHP versiunea 4.x

Autor: Sabin-Corneliu Buraga - [email protected] (c)2001, 2004

Ultima actualizare: 04 noiembrie 2004

*/

// locul unde sunt stocate fişierele

define ("PATH", '');

# De exemplu, pentru Windows cu Apache2Triad instalat in 'apache2':

# define ("PATH", 'c:\\apache2\\htdocs\\php-examples\\');

// variabila globala indicând daca documentul a fost modificat

$modified = 0;

// încărcăm documentul XML

if (!$doc = domxml_open_file(PATH . "projects.xml")) {

echo "<p>A apărut o eroare la procesarea documentului!</p>\n";

107


exit;

}

// rădăcina documentului

$root = $doc->document_element();

// afişăm informaţii generale despre document

echo "<p>Elementul radacina este <" .

$root->node_name() . ">.</p>";

// afişăm informaţii privitoare la proiecte

$projs = $root->get_elements_by_tagname("project");

foreach ($projs as $proj) {

// preluam nodurile <title> $titles = $proj->get_elements_by_tagname("title");

foreach ($titles as $title) { echo "<p>Proiect: " . $title->get_content();

}

// verificăm care e clasa proiectului if ($proj->has_attribute("class")) { echo " de clasa " . $proj->get_attribute("class") . "</p>";

}

else {

echo " de clasa necunoscuta.</p>";

// nu exista atributul "class", îl cream

// implicit, proiectul e de clasă D

$attr = $proj->set_attribute("class", "D");

// marcăm documentul ca fiind modificat

$modified = 1;

}

}

// dacă documentul a fost modificat, îl afişăm

if ($modified) { $xmldoc = $doc->html_dump_mem();

echo "<pre>" . htmlentities($xmldoc) . "</pre>";

}

?>

În ceea ce priveşte realizarea de transformări XSLT, putem recurge la funcţionalităţile oferite de extensia Sablotron disponibilă în versiunea 4 a mediului. Funcţia de transformare XSL are forma:

function xslt_transf ($xml, $xsl) {

$xp = xslt_create(); // creăm procesorul XSLT $rez = @xslt_process ($xp, $xml, $xsl); // transformăm

if (!$rez) { // o eroare echo "Eroare XSLT: " . xslt_error ($xp) .

108


" (" . xslt_errno ($xp) . ")";

return 1;

}

echo $rez; // afişăm rezultatul transformării

xslt_free ($xp); // eliberăm memoria

return 0;

}

La finalul acestei secţiuni, menţionăm că în PHP 5 pentru realizarea validărilor XML vom recurge la metodele puse la dispoziţie de clasa DOMDocument. Pentru validări con-form schemelor XML există schemaValidate(), iar cele DTD cu validate().

Exemplul de mai jos ilustrează modul de validare via o schemă XML:

<?php

$doc = DOMDocument::load('projects-xsd.xml');

echo 'Documentul este ' . $doc->schemaValidate('http://localhost/projects.xsd') ?

'valid' : 'invalid';

?>

109


4. Servicii Web

Premise

După cum am mai menţionat, originile şi scopurile Web-ului iau în consideraţie constitui-rea unui spaţiu de comunicare inter-umană prin intermediul partajării cunoştinţelor şi ex-ploatarea puterii computaţionale puse la dispoziţie de calculatoarele inter-conectate. Se poate remarca uşor că interacţiunea dintre om şi Web se rezolvă prin intermediul formu-larelor Web, iar interacţiunea dintre maşini se desfăşoară pe Web într-o manieră limitată.

Nevoile industriei au crescut, dorindu-se existenţa unor soluţii multi-platformă, slab-conectate – acestea conduc la integrarea aplicaţiilor, serviciilor şi sistemelor, prin folosirea tehnologiile Web actuale. Această integrare trebuie să se realizeze într-un mod flexibil, ad hoc, în funcţie de necesităţi. O altă necesitate priveşte crearea şi exploatarea unor servicii ataşabile (pluggable) şi „inteligente”, software-ul fiind văzut în termeni de serviciu şi nu drept aplicaţie mamut („software as service”). Aceasta pune premisele constituirii unor ofer-tanţi de servicii de aplicaţii (application service provider). Acesta conduce la proiectarea şi (re)folosirea unor standarde pentru îndeplinirea cerinţelor legate de vehicularea, disponi-bilitatea, mentenanţa, securitatea şi regăsirea datelor.

Mai mult decât atât, trebuie puse bazele constituirii unei arhitecturi destinate dezvoltă-rii de aplicaţii distribuite orientate spre Web. Software-ul trebuie divizat în servicii care se pot compune, menite a se conecta şi orchestra în mod spontan în cadrul proceselor de afaceri sau din alte medii. Este o viziune a software-ului bazat pe componente Web (com-ponent-based software), în contrast cu aplicaţiile monolitice, clasice. Desigur, software-ul standard („vechi”) trebuie integrat în această nouă arhitectură pentru a se proteja investi-ţiile făcute.

Soluţia este dată de un model, cunoscut sub numele de arhitectura orientată spre servicii (SOA – Service Oriented Architecture). Arhitectura SOA impune adoptarea unui stil de dez-voltare de aplicaţii considerate drept servicii ce vor fi invocate de alte aplicaţii.

Prin SOA se înţelege o perspectivă asupra unei arhitecturi software care defi-neşte utilizarea de servicii oferind funcţionalităţi solicitate de utilizatori. Resursele reţelei sunt astfel disponibile graţie unei suite de servicii independente ale căror implementări sunt necunoscute.

SOA presupune că noile servicii pot fi create pe baza celor deja existente, într-o manie-ră sinergică, dar componentele sistemului în ansamblu trebuie să aibă un grad mare de independenţă (de-coupling). În funcţie de schimbările ce pot interveni în cadrul cerinţelor (business requirements), serviciile pot fi re-compuse sau orchestrate diferit.

110


Conceptul de serviciu Web bazat pe XML

În mod obişnuit, putem implementa serviciile Web recurgând la script-uri CGI sau diverse servere de aplicaţii. Interacţiunea tradiţională poate decurge în următoarele două moduri.

Prima manieră este cea funcţională (de tip cerere/răspuns): utilizatorul (nu neapărat uman) vizitează o pagină şi formulează o cerere, fie traversând o legătură hipertext, fie prin intermediul unui formular. Serviciul (implementat de un program conceput într-un anumit limbaj, precum Perl, PHP, C# ori Java) întoarce un răspuns, adică o reprezentare – uzual, marcată în HTML – a resursei solicitate. Astfel, se accesează de la nivelul clientu-lui o anumită funcţionalitate specifică pusă la dispoziţie de un server Web.

Cea de a doua este una conversaţională (de tip solicitare/răspuns). Suplimentar, se dă posibilitatea exprimării unor întrebări suplimentare în vederea rafinării cererii: serviciul solicită date de la utilizator pentru a returna un răspuns mai bun.

Se poate observa că serviciul Web, respectând „tradiţia”, expune o interfaţă-utilizator (concepută în limbajul de marcare HTML în marea majoritate a cazurilor) prin interme-diul căreia are loc interacţiunea. Cererile sunt captate via formulare, utilizatorii umani tre-buind să interpreteze etichetele (labels) ataşate câmpurilor de dialog, pentru a cunoaşte ce tipuri de date pot fi introduse – se asigură câmpuri textuale, liste de opţiuni, butoane de tip checkbox şi radio etc. De asemenea, utilizatorii umani trebuie să interpreteze răspunsul oferit de serviciu prin parcurgerea rezultatului redării de către browser a reprezentării (HTML) expediate de server.

Pentru un calculator, activităţile expuse mai sus sunt dificil de realizat, deoarece pro-gramul de interpretare a rezultatului depinde de succesiunea de marcaje ale paginii Web recepţionate. Orice modificare, minoră sau nu, a tag-urilor din cadrul documentului con-duce la rescrierea script-ului de prelucrare a ieşirii oferite de serverul Web. Această metodă de „capturare” a informaţiilor incluse într-un document HTML se mai numeşte şi Web/HTML scrapping şi se dovedeşte dificil de aplicat în cazul prelucrării de structuri complexe de date.

Serviciile Web bazate pe XML fac explicite specificaţiile implicite, putând fi folosite în cadrul interacţiunii dintre maşini. Mai mult decât atât, pot fi invocate şi în cazul necu-noaşterii apriori a interacţiunii cu alte aplicaţii/servicii Web.

Nu există o definiţie unanim acceptată a conceptului de serviciu Web.

Conform IBM, reprezintă o aplicaţie modulară bazată pe tehnologiile Internet menită a îndeplini activităţi specifice şi conformându-se unui format tehnic speci-fic. Corporaţia Microsoft consideră serviciile Web ca fiind partea de procesare a datelor unei aplicaţii (application logic) disponibilă la nivel de program şi beneficiind de funcţionalităţile oferite de Internet. După Sun, un serviciu Web este o aplicaţie

111


care acceptă cereri din partea altor sisteme dispuse în Internet sau intranet, me-diate de tehnologii de comunicaţie neutre şi agile.

Un serviciu Web oferă o funcţionalitate specifică accesată pe baza unui schimb de me-saje marcate în XML. Acest schimb de mesaje e guvernat de anumite reguli. Suplimentar, un serviciu Web se pot autodescrie, folosind meta-date (date referitoare la date).

Serviciile Web implică utilizarea unor protocoale de comunicaţie, având asociate des-crieri ale datelor procesate şi alte interacţiuni cu aplicaţii terţe. Identificarea unui serviciu Web se realizează prin intermediul URI-urilor, transferul de date recurge în mod uzual la HTTP, iar definirea structurată a datelor vehiculate se face via XML. Un serviciu Web poate fi considerat ca fiind compus dintr-o colecţie de funcţii împachetate, văzute drept entitate unică şi publicate în spaţiul WWW cu scopul de a fi folosite de alte programe.

Ca exemple de operaţii ce pot fi puse la dispoziţie de serviciile Web, le amintim pe ur-mătoarele:

– transformarea datelor primite (e.g., conversii de valori în alte unităţi de măsură);

– dirijarea mesajelor (mai ales în cazul „magistralelor” de date specifice, disponibile la nivel de întreprindere);

– interogări asupra diverselor servere de baze de date relaţionale, obiectuale sau na-tive XML (de exemplu, furnizarea cataloagelor de produse, a coordonatelor unor localităţi, a situaţiei unui cont bancar, a istoricului cumpărăturilor efectuate online etc.);

– orchestrarea conversaţiilor între diferite entităţi (jucând, din acest punct de vede-re, rol de mediatori sau agenţi);

– realizarea de procesări (calcule) diverse;

– aplicarea de politici de acces asupra resurselor;

– rezolvarea unor excepţii ce pot surveni într-un context;

– solicitarea de aprobări de la utilizator (e.g., a execuţiei unor aplicaţii de către o altă entitate).

Drept principale caracteristici ale serviciilor Web menţionăm:

– accesarea, în manieră publică, se realizează printr-o adresă; serviciile Web pot fi considerate ca reprezentând puncte terminale (end points) ale comunicării între ma-şini, similar modelului folosit de protocoalele de transport ale stivei TCP/IP;

– abilitatea de a prelucra orice tip de date, din moment ce datele de intrare sunt do-cumente XML (conforme unei scheme de validare);

112


– posibilităţile de dezvoltare pe baza platformelor, arhitecturilor şi limbajelor exis-tente;

– adaptabilitatea (un serviciu Web poate fi extins, utilizând eventual, în mod trans-parent, alte aplicaţii sau invocând la rândul său alte servicii Web).

Serviciile Web sunt cărămizile pentru crearea de sisteme distribuite deschise, permi-ţând organizaţiilor şi dezvoltatorilor independenţi să-şi facă disponibile pe Web bunurile digitale într-un mod rapid şi facil.

Orice aplicaţie-client (script Perl, applet Java, program C cu interfaţă text sau grafică, aplicaţie .NET, pagină ori serviciu Web etc.) poate „consuma” – într-o varietate de mo-dalităţi – datele obţinute de la un serviciu invocat printr-o metodă standardizată, bazată pe standardele Web în vigoare.

Componentele arhitecturale ale serviciilor Web

Vom puncta în continuare principalele componente folosite în invocarea, definirea şi re-găsirea serviciilor Web.

În primul rând, apare necesitatea dezvoltării unui protocol de comunicare (transport) între maşini eterogene care să faciliteze vehicularea de mesaje permiţând interacţiunile complexe dintre calculatoare şi având un conţinut oricât de complex. Mai mult decât atât, trebuie oferit suport pentru asigurarea extensibilităţii, luându-se în calcul problemele de securitate, fiabilitate şi performanţă ce pot surveni. Acest protocol va trebui să pună la dispoziţie un mecanism de invocare şi de transmitere structurată a datelor.

Trebuie, astfel, găsit un limbaj pentru transmisia în format XML a parametrilor de in-trare şi întoarcerea răspunsului primit de la serviciul Web invocat.

Principalele protocoale de comunicare utilizate în prezent sunt XML-RPC şi SOAP.

XML-RPC oferă o specificaţie şi un set de implementări pentru realizarea de apeluri de proceduri la distanţă, în spiritul mecanismului RPC (Remote Procedure Call). A fost pro-iectat pentru a fi cât mai simplu, în acelaşi timp însă permiţând şi transmiterea, procesarea şi returnarea unor structuri complexe.

SOAP reprezintă o recomandare a Consorţiului Web, propunând facilităţi sofisticate şi oferind o paletă largă de posibilităţi de reprezentare (serializare şi deserializare) a date-lor vehiculate – vezi capitolul 4 din L. Alboaie, S. Buraga, Servicii Web, Polirom, Iaşi, 2006.

Un mesaj SOAP este compus din trei părţi:

– Un plic (envelope) care defineşte cadrul de lucru pentru a descrie ceea ce conţi-ne mesajul şi modul de procesare a acestui conţinut. Datele din corpul mesa-

113


jului pot fi transportate indiferent de protocolul folosit (uzual, e folosit HTTP);

– Un set de reguli de codificare (encoding rules) pentru exprimarea instanţelor ti-purilor de date definite în aplicaţie;

– O convenţie de reprezentare (representation) a apelurilor de metode implemen-tate de serviciul Web şi răspunsurilor furnizate în urma invocării acestora.

De asemenea, SOAP poate specifica şi o cale de la expeditor la destinatar, via un in-termediar (proxy) opţional, în vederea realizării de dirijări de mesaje (SOAP routing). O eroare (excepţie) privitoare la funcţionalitatea serviciului este semnalată printr-un mesaj special, denumit SOAP fault.

În vederea exploatării funcţionalităţilor puse la dispoziţie de un serviciu Web, trebuie oferită o descriere a acestuia. Apare necesitatea unui limbaj de descriere, menit a răspun-de la întrebări precum „Care e sintaxa mesajelor vehiculate?”, „Cum se desfăşoară trans-ferul de date?” şi „Cum găsim un serviciu Web?”.

Soluţia este furnizată de WSDL (Web Service Description Language). Limbajul permite separarea descrierii abstracte a funcţionalităţii oferite de un serviciu de detaliile concrete (de tipul „cum” şi „unde” este disponibilă acea funcţionalitate). WSDL descrie serviciile Web începând cu mesajele interschimbate între entitatea care oferă şi cea care invocă un anumit serviciu. Mesajele sunt „povestite” în manieră abstractă şi apoi sunt asociate unui protocol de reţea, precizându-se de asemenea şi un format (o sintaxă). Un mesaj constă dintr-o colecţie de date de anumite tipuri, iar schimbul de mesaje este descris ca o opera-ţie. Tipurile de date se definesc via scheme XML, la nivel conceptual folosindu-se un model de date reprezentat printr-un set de componente – mesaj, port, manieră de ataşare, serviciu – având specificate diverse proprietăţi. La nivel sintactic, se recurge la XML.

Apare încă o cerinţă: instituirea unui mecanism pentru publicarea şi regăsirea, în ma-nieră publică, a unui serviciu Web. Este posibil ca o anumită funcţionalitate oferită de un grup de servicii Web să poată fi regăsită prin intermediul unor interogări formulate de partea care intenţionează să folosească acea funcţionalitate.

Pentru aceasta, s-a constituit un catalog al tuturor furnizorilor de servicii Web publice în vederea regăsirii informaţiilor dorite: UDDI (Universal Description, Discovery, and Integra-tion), oferind o bază de date distribuită a serviciilor Web din prisma tipurilor de afaceri electronice pe care acestea le pot modela.

Conceptual, datele stocate într-un catalog UDDI pot fi împărţite în următoarele trei categorii:

114


– paginile albe (white pages) semnifică informaţii generale referitoare la o compa-nie furnizoare de servicii (numele companiei, descrierea tipurilor de afaceri efectuate, adresa etc.);

– paginile aurii (yellow pages) includ scheme de clasificare a companiilor şi/sau serviciilor disponibile (de exemplu, coduri de clasificare pe criterii geografice, ale categoriei de afaceri, taxonomii referitoare la produsele comercializate şi altele);

– paginile verzi (green pages) specifică informaţii tehnice despre un serviciu Web specific (e.g., o adresă Web spre descrierea acestuia, o adresă privitoare la in-vocarea serviciului etc.).

Uzual, căutarea în cadrul UDDI se realizează în funcţie de clasa din care face parte afacerea, după un nume de serviciu sau după locaţia geografică a furnizorului. Detalii sunt furnizate la adresa www.uddi.org.

Maniera de interogare a registrului UDDI

Funcţionalităţile de căutare sunt implementate via servicii Web, astfel încât accesul la registrul UDDI se realizează prin intermediul protocolului SOAP descris mai sus. UDDI va pune la dispoziţie documentul WSDL corespunzător unui serviciu compatibil cu cere-rea formulată.

115


Suplimentar, actualmente sunt disponibile o serie de specificaţii şi iniţiative adiţionale privitoare la diverse aspecte referitoare, printre altele, la adresarea, descoperirea, securita-tea şi asigurarea inter-operabilităţii serviciilor Web.

Modalităţi de implementare şi exploatare

Existenţa serviciilor Web este insuficientă, fără a avea la îndemână instrumente suplimen-tare de implementare, exploatare şi integrare. Un aspect important este dat de faptul că informaţiile şi serviciile trebuie să fie accesibile de pe orice tip de calculator şi de oriunde, apărând necesitatea utilizării unei platforme independente de dispozitiv, al cărei rol poate fi jucat de o maşină virtuală.

Noile servicii dezvoltate pot fi compuse din serviciile Web deja existente, accesibile în mod transparent. Ne situăm astfel la nivel de middleware oferind atât funcţionalităţi (im-plementate de codul-sursă al unor programe concepute în limbaje diverse), cât şi suport pentru inter-operabilitate.

Soluţia este oferită de implementarea şi exploatarea unui cadrul de lucru (framework) Web cu suport pentru SOA. Un astfel de cadru de lucru trebuie să asigure suportul pen-tru protocoalele Web şi cele înrudite (HTTP, SMTP, FTP etc.), plus pentru familia XML.

De asemenea, trebuie să se pună la dispoziţie mijloace pentru catalogarea, descoperi-rea şi integrarea serviciilor Web via UDDI şi descrierea funcţionalităţii şi intrări-lor/ieşirilor graţie limbajului WSDL, cu posibilitatea generării automate de documente WSDL asociate serviciilor Web implementate. Suplimentar, dezvoltatorii vor putea re-curge la facilităţi de specificare şi ataşare a unui context de execuţie, luându-se în calcul factori precum autorizarea (cine poate invoca un anumit serviciu), localizarea (unde e lo-calizat serviciul: platformă, server, port folosit şi altele), planificarea (când poate fi rulat serviciul) etc.

Pentru accesul la aplicaţii şi sisteme tradiţionale (legacy) sau la servere de stocare (backend servers), cadrul de lucru va trebui să ofere un nivel de integrare. Mai mult decât atât, este necesară existenţa unui nivel de interfaţare (frontend) via un server Web, care pre-supune existenţa unei/unor maşini virtuale şi a unui motor de asigurare a fluxului de acti-vităţi (workflow engine). La nivelul cel mai de sus, se află ofertantul de servicii Web sau utili-zatorul direct al acestora.

Actualmente, există o sumedenie de tehnologii, produse şi ofertanţi de servicii Web, dintre care le enumerăm doar pe următoarele: Apache Axis implementat în Java, Borland Delphi/JBuilder Web Services, IBM Web Services Toolkit, JBoss, Microsoft .NET Framework, NuSOAP şi PEAR::SOAP pentru PHP, modulul SOAP::Lite pentru Perl, Web Services Developer Pack pus la dispoziţie de mediul Java. De asemenea, există im-plementări oferite şi alte companii precum Apple, BEA, Fujitsu, Hewlett-Packard, Oracle, SAP, Sybase etc.

116


Mai trebuie să remarcăm faptul că au apărut diverşi ofertanţi de servicii Web, dintre care îi enumerăm pe Amazon, Blogger, cddb (CD DataBase), eBay, European Bioinformatics Institute, Google, Interfax, LiveJournal, PayPal, RedHat, MSN (Virtual Earth), Shopsync, Xignite şi Yahoo!.

Dezvoltarea şi invocarea de servicii Web

În majoritatea cazurilor, serviciilor Web funcţionează conform paradigmei client/server: serverul rulează permanent, unul sau mai mulţi clienţi trimit spre acesta cereri SOAP via un protocol de transport (cel mai uzual, HTTP), iar serverul întoarce un răspuns.

În cazul serviciilor Web, standardele sunt esenţiale pentru asigurarea inter-operabilităţii. Codificarea conţinutului mesajelor vehiculate (cererea şi răspunsul) prin SOAP adoptă formatul XML, iar descrierea serviciului Web se bazează pe limbajul WSDL.

Trebuie să remarcăm, încă o dată, că nu există nici o restricţie în alegerea limbajului de programare în care se vor implementa serviciul Web şi posibilii lui clienţi (programe desktop, aplicaţii Web, alte servicii Web etc.). Indiferent ce limbaj, instrument, platformă sunt folosite, în esenţă dezvoltarea şi utilizarea serviciilor Web prezintă aceleaşi caracteris-tici şi adoptă şabloane de proiectare similare.

Unele instrumente SOAP implementează propriul server Web, folosind HTTP (de exemplu, SOAP::Lite sau Microsoft Visual Web Developer). Altele – precum extensia Soap pentru PHP sau biblioteca gSOAP – presupun instalarea în cadrul unui server Web parti-cular, astfel încât daemonul HTTP va manevra mesajele SOAP spre o componentă proxy, care realizează invocarea serviciului Web în manieră transparentă pentru programator. O serie de instrumente SOAP suportă un mecanism de transport configurabil care permite selecţia, la nivel de aplicaţie, a protocolului de transport.

Instrumentele SOAP furnizează o componentă proxy, menită a procesa şi interpreta mesajul SOAP în vederea invocării codului aplicaţiei. Această componentă trebuie să aibă în responsabilitate recunoaşterea stilului de codificare, translatarea datelor din format na-tiv – de exemplu, obiecte Java sau .NET – în XML (şi invers) şi altele.

În ciuda diferenţelor de implementare, instrumentele pentru dezvoltarea de servicii Web prin SOAP urmează acelaşi model.

În continuare, ne propunem să detaliem modul de implementare şi de invocare a unor servicii Web pe baza uneltelor open source existente pentru PHP. Pentru început, vom construi un server şi un client SOAP simplu în PHP, utilizând extensia Soap disponibilă în versiunea 5 a acestui server de aplicaţii (ca alternativă, se poate recurge şi la biblioteca NuSOAP care poate fi folosită şi în PHP 4).

117


Astfel, trebuie să implementăm un server SOAP care va oferi accesul la un serviciu Web incluzând o singură metodă – furnizeazaCantit(). Aceasta va avea ca parametru de intrare un şir de caractere desemnând un sortiment de portocale şi va returna cantita-tea existentă, dacă acel sortiment există. Nu vom furniza o descriere WSDL asociată ser-viciului, invocarea putându-se realiza explicit, după cum vom vedea mai jos. Codul-sursă al acestui serviciu simplu este dat în continuare:

<?php

try {

// nu oferim nici o descriere WSDL,

// stabilim URI-ul serviciului

$server = new SoapServer(null,

array('uri' => 'urn:portocale.info'));

// adăugăm metodele implementate $server->addFunction('furnizeazaCantit');

// aşteptăm cereri SOAP $server->handle(); } catch (SOAPFault $exception) {

echo 'A apărut o excepţie: ' . $exception;

}

// funcţie care furnizează cantitatea

// dintr-un sortiment de portocale

function furnizeazaCantit ($numeSortiment) {

// de obicei, aici vom efectua o interogare SQL

switch ($numeSortiment) {

case 'japoneze': return 33;

case 'albastre': return 74;

default : return 'inexistent';

}

}

?>

Primul argument al constructorului desemnează adresa (URL-ul) documentului WSDL descriind serviciul, în acest caz fiind null. Spaţiul de nume prin care e identificat serviciul dezvoltat este dat în situaţia de faţă de un URN – urn:portocale.info. Fieca-re funcţie implementată va fi adăugată cu addFunction(). De asemenea, unui serviciu i se poate asocia o clasă prin intermediul metodei setClass(). Cererile SOAP vor fi re-zolvate via handle() care va avea în responsabilitate şi (de)serializarea datelor.

Deoarece extensia Soap este inclusă în distribuţia standard PHP 5, pentru rularea pro-gramului de mai sus nu va trebui instalat nimic suplimentar. În exemplificările de faţă am recurs la PHP versiunea 5.0.4 sub diverse versiuni ale serverului Apache 2.0.

118


Recurgând tot la extensia Soap, vom concepe acum un client care va invoca metoda expusă de serviciul Web pentru o serie de sortimente de portocale. Liniile de cod PHP sunt următoarele:

try { $client = new SoapClient(null,

array('location' =>

'http://localhost/sxml/oranges-server.php',

'uri' => 'urn:portocale.info'));

// realizăm o suită de invocări ale metodei dorite

foreach (array('albastre', 'japoneze', 'celeste')

as $sortiment) { $rez = $client->__call('furnizeazaCantit',

array($sortiment));

echo "<p>Stocul de portocale $sortiment

este <strong>$rez</strong>.</p>";

} } catch (SOAPFault $exception) {

echo 'A apărut o excepţie: ' . $exception->faultstring;

}

Deoarece nu avem la dispoziţie descrierea WSDL a serviciului, vom folosi __call() pentru invocarea metodei furnizeazaCantit(). Excepţiile ce pot surveni sunt captura-te graţie construcţiei try ... catch incluse în PHP 5.

Obiectul SOAPFault încapsulează informaţiile privitoare la un fault SOAP; în cazul de faţă, am utilizat proprietatea faultstring pentru a afişa mesajul de excepţie. Eşuarea unui apel SOAP poate fi verificată şi cu is_soap_fault().

În urma iteraţiilor realizate, vom obţine un rezultat precum cel din captura-ecran ur-mătoare.

Tipul răspunsului primit este unul eterogen (fie întreg, fie string), în funcţie de existen-ţa sortimentului de portocale pentru care realizăm invocarea metodei.

119


Invocarea serviciului Web implementat în PHP 5

Pentru aprofundarea subiectului, recomandăm consultarea lucrărilor L. Alboaie, S. Buraga, Servicii Web, Polirom, 2006 şi S. Buraga, Tehnologii XML, Polirom, 2006.

120


121

PPaarrtteeaa IIVV –– RReeggăăssiirreeaa iinnffoorrmmaaţţiiiilloorr ppee WWeebb

„Unde se găseşte ultimul port de unde nu vom mai ridica ancora?” Herman Melville

1. Preliminarii 2. Motoare de căutare 3. Meta-căutătoare 4. Alte mijloace de regăsire a informaţiilor


122


1. Preliminarii

Fiind bazat pe hipertext, spaţiul WWW are ca prim obiectiv oferirea unui mecanism facil de a stoca şi de a furniza, ulterior, informaţii, într-o manieră non-secvenţială.

Conform studiilor întreprinse în ultimii ani, utilizatorii care petrec mai mult de cinci ore pe Internet alocă peste 70% din timp căutării de informaţii. Pentru a localiza resursele dorite, un procent de 85%-90% dintre utilizatori apelează la motoarele de căutare.

Astfel, importanţa acestor aplicaţii se dovedeşte de necontestat, actualmente existând disponibile pe Web o multitudine de căutatoare şi meta-căutatoare, generale sau speciali-zate.

Motoarele de căutare pot oferi servicii de căutare pe bază de indecşi (i.e. Altavista) sau pe baza unor ierarhii de termeni – aşa-numitele servicii director (cum ar fi Yahoo!). În ulti-ma perioadă, aceste tipuri de servicii au devenit hibride, primul dintre motoarele de căuta-re care a adoptat tehnicile mixte fiind Excite.

123


2. Motoare de căutare

Preambul

Au fost evidenţiate mai multe modalităţi de regăsire a informaţiilor disponibile pe Web, în funcţie de intenţiile utilizatorilor. Printre cele mai importante se enumeră:

• scanarea (scanning) – utilizatorii parcurg, superficial, o arie largă de informa-ţii, aparţinând de obicei unui anumit subiect sau unui grup de subiecte conexe;

• răsfoirea (browsing, surfing) – utilizatorii vizitează locaţiile care le captează in-teresul, fără a avea stabilit un model mental al informaţiilor dorite;

• căutarea (searching) – utilizatorii sunt motivaţi să găsească o categorie parti-culară de informaţii ţintă. De cele mai multe ori este folosită căutarea bazată pe cuvinte-cheie (e.g. „procesare XML”) sau pe construcţii formulate în limbaj natu-ral, cum ar fi „Unde găsesc documentaţii despre design Web?”;

• explorarea (exploring) – utilizatorii investighează legăturile referitoare la o anumită resursă informativă şi pe cele conexe;

• hoinăreala (wandering) – utilizatorii realizează o navigare complet nestructu-rată.

De remarcat faptul că, în mod frecvent, utilizatorii nu parcurg la un moment dat decât o singură pagină WWW, aparţinând unui server particular, fără a avea o vedere de an-samblu a modului de structurare a tuturor documentelor de la acea adresă. Astfel, spaţiul Web prezintă următoarele caracteristici negative:

• modelul plat de memorare a datelor

Documentele nu sunt stocate în mod structurat pe serverele Web. Structura hipertext pe care, eventual, o formează acestea poate fi recunoscută de cele mai multe ori doar examinând URI-urile asociate. Uzual, paginile nu posedă legături către documentul părinte („rădăcina” sitului – un fişier al cărui nume diferă în funcţie de serverul Web folosit, pentru Apache şi IIS de exemplu fiind /index.html, respectiv /default.htm).

• legăturile unidirecţionale

Limbajul HTML nu oferă decât posibilitatea de specificare a legăturilor unidi-recţionale, simple. Este dificil de alcătuit o hartă locală care să ilustreze toate sur-sele şi destinaţiile legăturilor dintre paginile Web ale unui sit. Reţelele sofisticate de legături conduc la o navigare greoaie şi pot deveni frecvent surse de confuzie.

124


• lipsa unei hărţi globale de navigare

Nu poate fi realizată o hartă globală de navigare prin întreg spaţiul WWW, într-o manieră ierarhică (arborescentă), deoarece structura hipertext de ansamblu a Web-ului este necunoscută.

• menţinerea legăturilor

Legăturile fiind stocate în interiorul documentelor, posibilitatea de a adăuga di-rect adnotări sau de a modifica legăturile dintr-o pagină este deţinută doar de proprietarul acesteia. Menţinerea integrităţii legăturilor pentru situri Web care conţin un număr foarte mare de documente se dovedeşte dificilă. De cele mai multe ori se apelează la programe de verificare a validităţii legăturilor şi de con-struire a ierarhiilor de legături între paginile unui sit Web.

În concluzie, pentru a avea acces la informaţiile dorite, de cele mai multe ori se recurge la facilităţile oferite de unul sau mai multe dintre motoarele de căutare disponibile.

Interacţiunea cu un motor de căutare

Interfaţa de căutare a unui motor de căutare este o componentă importantă a sistemului, oferind în funcţie de motor posibilităţi de formulare a cererilor prin intermediul diverşilor operatori logici, în limbaj natural, explorând ierarhii de domenii catalogate (directoare Web), stabilind localizarea paginilor etc.

Majoritatea motoarelor de căutare utilizează o convenţie de compunere a interogărilor. Pot fi introduse şi relaţii desemnate prin intermediul operatorilor AND, OR, NOT şi NEAR. Urmează o descriere succintă a fiecăruia dintre aceşti operatori:

• termen1 AND termen2

Se foloseşte atunci când dorim ca paginile returnate de motor să aibă în com-ponenţă ambii termeni. De multe ori, semnul plus (caracterul „+”) prefixând fie-care termen înlocuieşte funcţia lui AND: +termen1 +termen2.

• termen1 OR termen2

Îl vom folosi în situaţia când dorim ca paginile căutate să conţină măcar unul dintre cei doi termeni specificaţi.

• NOT termen

Dacă vrem ca paginile să nu includă termenul specificat vom utiliza acest ope-rator (o construcţie echivalentă este -termen).

125


• termen1 NEAR termen2

Vom specifica acest operator pentru situaţiile în care dorim ca paginile căutate să conţină cei doi termeni localizaţi la mică depărtare unul de celălalt (vecinătate de 20-200 de cuvinte, în funcţie de serviciul de căutare ales).

Pentru gruparea şi schimbarea precedenţei operatorilor se pot utiliza parantezele „()”. Se mai poate folosi şi construcţia "listă de termeni", ghilimelele însemnând fap-tul că se va realiza o căutare exactă a secvenţei de termeni din lista dată. De exemplu:

"Proiectare Web" +sfaturi -utilitare

De asemenea, se oferă şi posibilitatea de căuta în titlurile paginilor Web, prin interme-diul unui construcţii de forma:

title: şir căutat

De exemplu, pentru a căuta „Linux” în titlurile paginilor, vom putea scrie:

title: Linux

O altă facilitate este aceea de a găsi toate paginile care includ ancore către o adresă spe-cificată, prin folosirea cuvântului-cheie link. Astfel, pentru a obţine lista tuturor docu-mentelor care includ o anumită adresă e-mail am putea introduce:

link: [email protected]

În mod obişnuit, ne vom sluji foarte rar de toate aceste facilităţi puse la dispoziţie, pre-ferând formularea unui interogări compuse dintr-un singur cuvânt sau a unei propoziţii în limbaj natural. Tehnologia Ask Jeeves – www.askjeeves.com – încorporată de Altavista este utilizată pentru procesarea cererilor formulate în limbaj natural (în speţă, în limba engleză), problemele care trebuie să fie rezolvate fiind cele legate de dezambiguizarea termenilor, eliminarea cuvintelor nerelevante sau expandarea interogării (de exemplu, pot fi automat formulate noi cereri conţinând sinonime ale cuvintelor furnizate de utilizator).

De asemenea, majoritatea motoarelor oferă posibilitatea de rafinare (refine) a interogării sau de specificare a unor cereri avansate de căutare (advanced search).

De reţinut însă faptul că nici un motor nu poate fi perfect, serviciile de căutare oferite neputând avea o acurateţe de 100%. Pentru testarea serviciilor de căutare se iau în consi-deraţie mai mulţi factori, dintre care pot fi amintiţi: acurateţea, posibilitatea de căutare avansată, ergonomia în utilizare şi acordarea de alte facilităţi.

La finalul acestei secţiuni, putem menţiona că actualmente cele mai bine cotate sau po-pulare motoare de căutare sunt Google, Yahoo!, Ask Jeeves, All The Web, AOL Search şi

126


HotBot. Alte alegeri se pot îndrepta către Altavista, Gigablast sau LookSmart. Printre noii veniţi, se enumeră Clusty şi MSN Search.

Structura internă a unui motor de căutare

În general, un motor de căutare este constituit din trei componente de bază:

1. o aplicaţie, denumită robot Web (spider, crawler), având misiunea de a parcurge spaţiul WWW şi de a vizita anumite pagini, extrăgând informaţii despre ele. Aceste infor-maţii vor fi stocate pe serverul/serverele motorului de căutare, într-o bază de date sau într-un index. Roboţii Web vor fi prezentaţi în cadrul următoarei secţiuni;

2. un depozit de memorare a informaţiilor despre paginile parcurse de robot, numit index (catalog). Acest index conţine de cele mai multe ori câte o copie a fiecărei pa-gini şi a URI-ului corespunzător acesteia, organizarea informaţiilor în cadrul inde-xului efectuându-se conform unor criterii specifice;

3. un mecanism de evaluare (ranking) a importanţei paginilor din index în conformitate cu cererea formulată de utilizator, cerere introdusă prin intermediul unei interfeţe Web (partea vizibilă a motorului de căutare). În ordinea importanţei, adresele paginilor (plus alte informaţii) sunt returnate – sub forma unui document Web – utilizatoru-lui care a formulat cererea. Utilizatorul este cel care va decide care pagină (sau grup de pagini) întruneşte preferinţele sale.

Diferenţele dintre motoarele de căutare operaţionale în acest moment sunt date de fie-care componentă în parte.

127


Arhitectura internă a unui motor de căutare

Roboţii Web

Roboţii Web, regăsiţi şi sub numele de păianjeni (spiders), sunt programe care tra-versează în mod automat structura hipertext a spaţiului WWW, cu scopul extrage-rii unor informaţii.

Trebuie să facem o distincţie clară între roboţii Web şi navigatoarele Web, acestea din urmă fiind aplicaţii acţionate de om.

Activitatea unui robot Web constă în a transmite o cerere HTTP către un server Web – pornind de la un identificator uniform de resurse (URI) – şi în a extrage informaţiile corespunzătoare dintr-o reprezentare a unei resurse şi din toate documentele desemnate de legăturile acesteia.

Roboţii Web se pot utiliza în diverse scopuri, principalele fiind cele detaliate mai jos:

• analiza statistică – prin traversarea completă a unui sit Web particular, robotul poate furniza diverse statistici preţioase referitoare la resursele procesate, precum media documentelor stocate pe acel server, procentul de documente de un anumit tip,

128


lungimea medie a unei pagini, gradul de interconectare cu alte documente, locale sau la distanţă etc. De fapt, primul robot implementat a fost conceput tocmai cu scopul declarat de a contoriza toate serverele Web din lume, pentru a se cerceta cât de întins este spaţiul hipertext.

De asemenea, roboţii Web pot fi utilizaţi la descoperirea diverselor modele de date (pattern-uri) prin explorarea unei cantităţi apreciabile de informaţii disponibile pe Web, fiind astfel implicaţi în activităţi de descoperire a resurselor – cunoscute în li-teratura de specialitate prin sintagma „minerit al datelor” (data mining); de asemenea, se poate efectua şi un „minerit al relaţiilor” (relation mining), pentru descoperirea posibilitelor relaţii stabilite între resursele Web. Aceste aspecte sunt imperios nece-sare în domenii precum comerţul electronic;

• menţinerea legăturilor – în prezent, este foarte important să fie menţinută în bune condiţii starea legăturilor stabilite între diverse documente Web. Un robot poate ajuta la descoperirea şi rezolvarea aşa-numitelor „legături moarte” care indică resur-se inexistente. Deşi serverele Web pot înregistra toate cererile care nu pot fi satisfă-cute din cauza specificării adreselor invalide, administratorul unui sit Web de pro-porţii poate recurge la asistenţă din partea unui robot pentru descoperirea automată a legăturilor eronate.

Roboţii pot verifica, de asemenea, şi structura documentelor (X)HTML, semnalând erorile de design şi de stil ale acestora, precum şi eludarea unor reguli privind acce-sibilitatea conţinutului. Serviciul de validare oferit de Consorţiul Web reprezintă tocmai un astfel de robot;

• oglindire – tehnica oglindirii (mirroring) este preluată de la arhivele FTP şi constă în copierea într-o altă locaţie a întregii structuri arborescente a unui sit (adică a tuturor fişierelor sale, în mod recursiv) şi în reactualizarea periodică a acestor copii. Oglin-direa resurselor asigură fiabilitate, viteză mai mare de transfer, evitarea încărcării traficului de reţea, acces neconectat (off-line) etc.

Pentru Web, oglindirea poate fi realizată de un robot, care trebuie să aibă în res-ponsabilitate şi rescrierea referinţelor la alte documente, păstrarea integrităţii hiper-textului şi actualizarea regulată a paginilor WWW. Oglindirea poate fi evitată, folosindu-se în mod inteligent memoria cache a serverelor proxy (intermediare), care oferă posibilităţi de actualizare selectivă şi de organizare a resurselor. O categorie specială de astfel de roboţi este cea a programelor aşa-numite download managers, ca exemple putând fi menţionate utilitarele wget sau ProZilla din distribuţiile Linux ori programele Download Express, FreshDownload, GetRight, LeechGet şi Teleport disponibi-le în Windows;

• descoperirea resurselor – probabil cea mai importantă aplicaţie a roboţilor Web este uti-lizarea acestora la descoperirea resurselor. Creşterea progresivă a volumului de in-formaţii disponibile pe Web are drept consecinţă principală conceperea de aplicaţii pentru sumarizarea, indexarea şi monitorizarea modificărilor resurselor WWW.

129


Astfel, fiecare motor de căutare, conţinând baze de date privind localizarea şi tipul de informaţii dorite de utilizatori, apelează la serviciul roboţilor Web pentru desco-perirea resurselor care înglobează aceste informaţii.

Un avantaj suplimentar al roboţilor este cel dat de capacitatea acestora de a moni-toriza schimbările survenite în cadrul unor pagini Web indicate de utilizatori;

• utilizări combinate – desigur, roboţii pot îndeplini sarcini multiple, ca de exemplu descoperirea resurselor în paralel cu realizarea de statistici Web sau menţinerea in-tegrităţii legăturilor şi, concomitent, detectarea schimbărilor survenite în cadrul do-cumentelor Web.

E necesar să facem o serie de observaţii:

Un aspect important care trebuie luat în consideraţie în exploatarea roboţilor Web este timpul de actualizare a bazelor de date ale motoarelor de căutare. Robo-ţii de căutare a informaţiilor sunt cei care vor trebui să decidă care informaţii sunt importante pentru a fi transmise programelor de indexare.

Rularea în manieră necontrolată a roboţilor Web de către utilizatorii finali care ar putea folosi opţiuni inadecvate sau ar rula mai multe instanţe de program poate conduce la abuzuri nedorite asupra unui sit sau grupuri de situri Web.

Roboţii Web, în special cei netestaţi insuficient, pot fi ineficienţi sau pot avea vicii de arhitectură astfel încât să dăuneze traficului de informaţii, mai ales dacă sunt folosiţi de persoane neavizate ori de neprofesionişti. Implementări eronate pot determina roboţii să intre în arii aproape infinite denumite găuri negre (atunci când, de exemplu, un document are o legătură care se referă la el însuşi, iar pro-gramul nu detectează acest aspect). De asemenea, roboţii nu trebuie să acceseze tipuri de date fără relevanţă, având dimensiuni considerabile (e.g.: arhive, fişiere executabile, fişiere multimedia etc.).

De cele mai multe ori, fiecare motor de căutare are implementat propriul robot, sensibil la diverse situaţii care pot surveni pe Web. De exemplu, roboţii de la Excite (Inktomi), Go (InfoSeek) şi Lycos nu pot indexa paginile conţinând cadre, iar cei de la FAST şi Google au probleme cu hărţile de imagini senzitive (care pot îngloba legături spre alte documente).

Trebuie de menţionat faptul că fiecare creator al unui robot Web trebuie să ofere in-formaţii privind identificarea acestuia (nume, locaţie, grup de programatori etc.). De exemplu, unii roboţi personali (utilizaţi de aplicaţiile de oglindire a siturilor sau de motoa-rele de căutare experimentale) pot fi recunoscuţi prin nume ca BackRub (folosit în perioa-da pre-Google), WebMapper ori wget. De asemenea, roboţii principalelor motoare de căuta-re actuale se identifică prin Googlebot (de la Google), Infoseek sau Scooter (de la Altavista).

130


Pentru evitarea accesului roboţilor în zone Web lipsite de relevanţă, conţinând date temporare ori private, s-a adoptat un standard pentru excluderea roboţilor. Acesta stipulează că orice robot care accesează un anumit server Web va accesa în primul rând un fişier text denumit robots.txt. Acest fişier va trebui stocat în directorul rădăcină al serverului, specificând părţile din sit care vor fi evitate la parcurgerea automată (pentru evitarea gău-rilor negre sau din alte raţiuni).

Un exemplu de astfel de fişier este dat mai jos: # /robots.txt pentru http://www.infoiasi.ro User-agent: * # toţi roboţii Disallow: /tmp/ # date temporare Disallow: /busaco/work/ # spaţiu privat

Anumiţi roboţi pot utiliza tag-uri specifice (ascunse) dintr-o pagină Web care să dicteze un anumit comportament pentru acea pagină (aşa cum se întâmplă în cazul programului de oglindire Teleport).

Nu toate paginile vor avea aceeaşi importanţă pentru robot, ţinându-se cont de mai mulţi factori. Se pot lua în calcul:

• compatibilitatea cu posibilele cereri ale utilizatorilor,

• numărul legăturilor care au, la rândul lor, legături spre pagina analizată pe robot – gradul de „citare” a documentului,

• relevanţa conţinutului paginii,

• numărul de legături conţinute de pagină şi metrica locaţiei (o pagină din domeniul .com se consideră a fi mai importantă decât una a domeniului .za).

Importanţa unui document Web depinde, aşadar, de contextul apariţiei acestuia.

Managementul indexului

Componentă secundă a unui motor de căutare, indexul (catalogul) este alcătuit dintr-o serie de baze de date stocate de un server (modul) de stocare, constituindu-se un depozit (distribu-it) de date. Acest depozit va avea o capacitate considerabilă, memorând documentele in-dexate returnate de robotul asociat motorului de căutare.

Modulul de stocare realizează diverse activităţi, cele mai importante fiind:

• inserarea datelor noi privitoare la paginile parcurse de roboţi, • actualizarea conţinutului vechilor documente stocate, • programarea diverselor cereri de accesare a informaţiilor despre o serie de docu-

mente.

De cele mai multe ori aceste date sunt comprimate.

131


Modulul de indexare şi meta-date este responsabil cu extragerea meta-datelor din paginile colectate şi cu indexarea atât a meta-datelor, cât şi a documentelor (X)HTML. Pentru in-dexarea conţinutului textual al documentelor, uzual vor fi luate în consideraţie toate cu-vintele, exceptând aşa-numitele cuvinte stop (cu o lungime mai mică sau egală cu trei carac-tere şi desemnând prepoziţii, conjuncţii sau interjecţii; de exemplu „a”, „the”, „in” din limba engleză). Unele motoare de căutare (e.g.: Google sau Lycos) vor contoriza şi numă-rul de apariţii ale celor mai frecvente cuvinte dintr-o pagină Web şi vor realiza indecşi suplimentari şi/sau vor stabili categoria în care va fi încadrată acea pagină.

Desigur, pot fi adoptate şi alte tehnici (eventual, mai complexe).

Extragerea meta-datelor variază în funcţie de motorul de căutare. Cea mai populară tehnică este cea a indexării documentelor pe baza cuvintelor-cheie furnizate fie explicit de creatorul acestor documente, fie în urma unei catalogări automate realizate de un robot. Trebuie să menţionăm aici şi faptul că indexarea se poate realiza manual, de către experţi umani – este cazul catalogului Open Directory.

Anumite motoare de căutare (i.e. Altavista) permit înscrierea unei pagini în baza de da-te, solicitând introducerea unor cuvinte-cheie pe baza cărora să se efectueze operaţiunea de indexare.

În activitatea de catalogare a informaţiilor, de multe ori intervine ierarhizarea datelor în funcţie de subiectul pe care-l tratează, această clasificare conducând la apariţia serviciilor director (de genul Yahoo! sau dmoz.org), bazate pe generarea de taxonomii (arbori de con-cepte).

De asemenea, pentru fiecare document se calculează numărul de legături care se referă la o anumită pagină şi numărul total de legături conţinute de acea pagină. Aceste valori sunt denumite tehnic hit-uri.

Indecşii pot cuprinde indecşi text obişnuiţi, dar şi indecşi ai meta-datelor extrase.

Meta-datele şi indecşii se stochează pe dispozitive separate de cele ale depozitului de date (de cele mai multe ori se utilizează un sistem de management al bazelor de date rela-ţionale).

Depozitul de documente indexate oferă trei moduri de acces:

• acces direct (random access) – se realizează pe baza identificatorului unic asociat fiecărei pagini indexate;

• acces bazat pe interogări (query-based access) – vor fi furnizate toate documentele care sa-tisfac o anumită cerere. Cererea poate să se refere la diverse atribute ale me-ta-datelor (e.g.: autor, titlu, locaţie) sau la conţinutul textual al paginilor;

132


• acces flux de date (streaming access) – este folosit atunci când din depozitul de date se extrage un grup de pagini pentru a fi trimis ca flux de date spre o anumită aplicaţie (de exemplu, atunci când se reindexează o serie de pagini).

În cadrul depozitului de date este de dorit să se memoreze cea mai recentă versiune a paginilor traversate de roboţii Web. Trebuie avute în vedere aspecte importante precum consistenţa indecşilor şi eliminarea paginilor vechi/inexistente pe Web. Astfel, corespunzător fiecă-rei pagini pot fi ataşate două valori numerice pentru a specifica timpul de viaţă permis şi respectiv pentru a contoriza acest timp. Timpul de viaţă permis reprezintă perioada de stocare a unui document fără a necesita actualizarea ori ştergerea sa din depozit. Contorul este decrementat periodic până când devine nul, caz în care robotul Web va trebui să proceseze noi informaţii referitoare la acea pagină. Desigur, fiecare motor de căutare va adopta propria manieră de stabilire a timpului de viaţă. De asemenea, roboţii Web pot avea proprii lor parametri pentru realizarea acestei actualizări regulate, ţinând cont de di-verse raţiuni, cum ar fi cele legate de congestia reţelelor.

Pentru asigurarea scalabilităţii, depozitul de date poate fi unul distribuit, constituindu-se în acest scop o colecţie de noduri de stocare interconectate, controlul realizându-se prin intermediul unui server de management al nodurilor. Acest server menţine o tabelă cu starea fiecărui nod de stocare: capacitatea totală de memorare, spaţiul liber, nivelul frag-mentării datelor, numărul şi tipul de accesări, modul de operare a nodului etc. Pentru sporirea eficienţei, nodurile pot conţine pagini grupate pe diverse criterii (cuvinte-cheie, tematică, localizare etc.). Depozitul de date distribuit poate fi considerat ca fiind o singură resursă de calcul, constituind un cluster sau un Grid.

Mecanismul de căutare şi de evaluare

A treia componentă a unui motor este reprezentată de mecanismul de căutare şi de evaluare a paginilor Web furnizate utilizatorului în urma cererii acestuia, formulată prin intermediul unei interfeţe puse la dispoziţie de motorul de căutare.

Interfaţa de căutare (denumită frecvent motor de interogare) este o componentă importan-tă a sistemului, oferind, în funcţie de motor, posibilităţi de formulare a cererilor prin in-termediul diverşilor operatori logici, în limbaj natural, explorând ierarhii de domenii cata-logate (directoare Web), stabilind localizarea paginilor etc.

Am discutat mai sus despre modul de formulare a interogărilor adresate motorului de căutare.

Procesul de evaluare a interogării specificate de utilizator poate fi derulat conform ur-mătoarelor etape:

1. analizarea cererii formulate de utilizator; 2. căutarea în indecşii corespunzători termenilor rămaşi după analiza cererii;

133


3. scanarea tuturor documentelor care întrunesc întregul set de condiţii de căutare;

4. evaluarea gradului de relevanţă a fiecărei pagini în funcţie de cererea for-mulată;

5. eliminarea duplicatelor şi sortarea în ordinea relevanţei; 6. afişarea adreselor celor mai relevante N documente (eventual furnizându-

se şi alte informaţii, precum lungimea documentului, formatul, limba, con-textul apariţiei etc.).

Nu toate motoarele de căutare urmează toate fazele descrise mai sus. Unele dintre ele nu realizează decât parţial sau chiar deloc eliminarea duplicatelor (e.g.: Excite sau Lycos).

Alte motoare vor afişa paginile găsite grupate pe termeni sau vor oferi legături către al-te documente stocate pe acelaşi server Web.

Sistemul de evaluare depinde de motorul de căutare ales. Calculul relevanţei documen-telor se poate baza pe:

tehnici de clasificare umană – resursele sunt clasificate manual, de către experţi (la o astfel de abordare recurge, de exemplu, Open Directory);

informaţii privitoare la utilizarea unei resurse – în acest caz, sunt importante tim-pul de viaţă al resursei şi periodicitatea vizitei;

conectivitate – se are în vedere analizarea relaţiilor resursei considerate cu altele (similare).

De exemplu, în cazul lui Google, sunt menţinute mai multe meta-date despre docu-mentele indexate decât la alte motoare, ceea ce conduce la o precizie ridicată. Sunt me-morate chiar şi poziţia în cadrul documentului, tipul de font şi modul de scriere ale in-formaţiilor. În plus, rezultatele obţinute în urma fiecărei interogări emise de utilizator sunt salvate temporar, putând fi folosite la evaluarea unor cereri similare viitoare.

Relevanţa paginii (page rank) se calculează şi pe baza corelaţiilor dintre relevanţa calcu-lată de motor şi cea observată din interacţiunea cu utilizatorul (gradul de relevanţă a unei resurse poate scădea, dacă se observă ca acea resursă nu este considerată spre vizitare de către utilizator, deşi e plasată printre primele). Motorul Google calculează acest page rank în funcţie de structura hipertext, o legătură de la pagina A la pagina B reprezentând un „vot” dat paginii B de către A. Cu cât un sit e mai important, cu atât page rank-ul asociat lui este mai mare.

Cititorii interesaţi de mai multe detalii referitoare la page rank pot consulta adresa http://www.iprcom.com/papers/pagerank.

134


3. Meta-căutătoare

Pentru a formula interogări şi a primi rezultate de la o multitudine de motoare de căutare, utilizatorii au posibilitatea de a apela la serviciile oferite de un meta-căutător. Funcţia prin-cipală a acestuia este cea de a compila toate listele de pagini obţinute de la motoarele obişnuite (interogate eventual în manieră paralelă) şi de a prezenta utilizatorului cele mai relevante documente găsite. Deseori, un meta-căutător are implementat propriul sistem de evaluare a relevanţei paginilor, în funcţie de anumite criterii proprii sau formulate de utilizator. Un exemplu este Mamma – www.mamma.com.

De asemenea, un meta-căutător poate oferi o vedere ierarhizată a paginilor găsite, de genul structurii de directoare Web (ierarhii de termeni) pe care acestea le formează.

O serie de meta-căutătoare sunt direcţionate spre domenii specifice, folosind bazele de date furnizate de unul sau mai multe motoare de căutare de succes. Prin astfel de meta-căutătoare, putem avea acces la diverse servicii specializate (e.g., software, adrese poştale, documente multimedia etc.).

Structura unui meta-motor

Anatomia unui meta-motor de căutare este ilustrată în figura de mai jos.

Dispecerul de cereri poate diviza interogările complexe date de utilizator în sub-cereri, fiecare sub-cerere fiind expediată unui motor de căutare clasic. Nu toate meta-motoarele de căutare trimit în manieră concurentă cereri motoarelor de căutare.

Monitorul de performanţă supraveghează starea fiecărui motor de căutare. Atunci când unul dintre motoare devine neoperaţional sau inaccesibil din raţiuni legate de reţea, se poate decide în mod automat ca respectiva cerere să fie dată spre prelucrare altui motor. De asemenea, monitorul de performanţă are ca misiune şi primirea listelor de adrese ale paginilor găsite.

Modulul responsabil de interfaţa cu utilizatorul va furniza un formular electronic pen-tru a fi completat cu interogarea dorită. După primirea rezultatelor de la motoarele de căutare, listele cu URI-uri vor fi compilate, eliminându-se informaţiile redundante şi cele contradictorii. Deoarece fiecare motor de căutare va returna o listă de pagini într-un for-mat propriu, meta-motorul de căutare va realiza şi o convertire la un format comun care va fi prezentat clientului.

Unele meta-motoare de căutare pot oferi informaţii privind relevanţa resurselor căutate sau legăturile dintre ele – este cazul meta-motorului Kartoo, disponibil la adresa www.kartoo.com.

135


Structura generală a unui meta-motor de căutare

136


4. Alte mijloace de regăsire a informaţiilor

În cadrul acestei secţiuni, vom prezenta o serie de detalii interesante privitoare la alte sur-se de informare disponibile pe Web: forumurile, siturile de tip wiki, blog-urile şi portalurile Web – toate, componente ale Web-ul social (denumit şi „Web 2.0”), alături de alte tehno-logii, paradigme şi stiluri arhitecturale de aplicaţii Web.

Forumurile Web

O primă soluţie este oferită de forumurile on-line, scopul acestora fiind acela de a pune la dispoziţie un cadru Web de realizare a unor discuţii (uzual, în regim asincron), pe diferite teme.

O platformă de management al forumurilor poate, eventual, oferi suport pentru a structura firele (thread-urile) subiectelor abordate, în vederea regăsirii facile a mesajelor dorite, în funcţie de tematică. De asemenea, un astfel de sistem poate permite, printre altele: accesul autorizat sau anonim, realizarea de sondaje (poll-uri), notificarea automată a utilizatorilor asupra apariţiei unui răspuns la un mesaj, căutarea pe diverse criterii, redac-tarea facilă a mesajelor prin folosirea marcajelor (X)HTML etc.

Există diverse aplicaţii care oferă suport pentru crearea şi întreţinerea de forumuri, din-tre care se pot menţiona phpBB, un popular instrument open-source, şi JForum.

Siturile colaborative de tip wiki

Un wiki reprezintă un sit Web care permite utilizatorilor să adauge diverse tipuri de con-ţinuturi, semănând în acest sens cu forumurile Web, dând în plus posibilitatea vizitatori-lor să editeze acel conţinut.

Termenul wiki se referă şi la software-ul colaborativ utilizat pentru crearea acestor ti-puri de situri. Denumirea provine din limba hawaiană (în această limbă, „wiki wiki” în-seamnă „foarte rapid”).

Primul sit de tip wiki s-a numit WikiWikiWeb şi a fost folosit începând cu anul 1995 în cadrul comunităţii specialiştilor în proiectare software. Părintele (creatorul) lui este Ward Cunningham. Pe parcursul anilor, diverse alte comunităţi virtuale au dezvoltat sisteme wiki, în prezent considerându-se că Wikipedia (lansat în 2001) este situl wiki cel mai cu-prinzător, reprezentând o veritabilă sursă de cunoaştere.

137


Varianta în limba română a enciclopediei Wikipedia

Caracteristica principală a unui sit wiki este aceea că permite ca documentele Web să poată fi redactate uşor în manieră colectivă folosind un limbaj de marcare. O pagină fă-când parte dintr-un wiki este referită ca fiind o „pagină wiki”, iar o colecţie de pagini – uzual, puternic interconectate prin intermediul hiperlegăturilor – se numeşte un „wiki”.

Crearea şi actualizarea documentele sunt facil de realizat, în general orice modificare fi-ind reflectată instantaneu în cadrul sitului (nu se operează o „cenzură” prealabilă, iar utili-zatorii nu trebuie să fie autentificaţi pentru a efectua schimbări). Marcarea paginilor wiki recurge la un limbaj de adnotare simplu, dar unele servere wiki oferă facilităţi suplimenta-re de editare. Legăturile hipertext spre alte pagini wiki sunt marcate prin intermediul unor simboluri speciale (de genul parantezelor acolade sau a caracterului „/”).

Pentru controlul istoricului modificărilor, există două funcţii importante: istoricul revi-ziilor (revision history) şi managementul diferenţelor de conţinut (diff feature). Persoana care menţine wiki-ul poate folosi astfel de instrumente pentru a elimina unele schimbări efec-tuate de vizitatori. În vederea prevenirii vandalismului, unele sisteme wiki limitează drep-

138


turile de editare ori impun autentificarea utilizatorilor care intenţionează să opereze modi-ficări de conţinut.

Pentru a dezvolta un sit wiki, se pot folosi aplicaţii precum MediaWiki, MoinMoin, TWiki, UseMod sau XWiki, disponibile în regim open-source. Serverul XWiki este folosit ca platformă pentru situl Facultăţii de Informatică a Universităţii „A. I. Cuza” din Iaşi.

Ca şi în cazul altor sisteme de management al conţinutului, criteriile principale care trebuie avute în vedere pentru a decide ce sistem wiki este cel optim sunt gradul de popu-laritate al software-ului, facilităţile oferite pentru editare, managementul utilizatorilor, fa-cilităţile groupware (forum, galerie de fotografii, sistem intern de mesagerie etc.), controlul accesului, abilitatea de import/export a altor tipuri de conţinut (e.g.: documente HTML, fişiere PDF, documente Word), suportul multilingv, extensibilitatea, portabilitatea şi scalabilitatea. Pentru mai multe detalii, puteţi consulta şi lucrarea S. Buraga (coord.), Ten-dinţe actuale în proiectarea şi dezvoltarea aplicaţiilor Web, Matrix Rom, Bucureşti, 2006.

Weblog-urile

Un Weblog (sau blog, pe scurt) reprezintă o pagină Web care conţine diverse fragmente de informaţie puse la dispoziţie de către o persoană posibililor vizitatori. Termenul provine de la cuvintele „Web” (WWW) şi „log” (jurnal) şi a fost introdus în premieră de Jorn Barger în decembrie 1997.

La adresa www.usemod.com/cgi-bin/mb.pl?WebLog sunt disponibile informaţii privitoare la istoricul şi adresele unor situri referitoare la blog-uri.

Un blog poate fi considerat un mijloc de comunicare inter-personală, natura sa putând varia de la o formă de jurnal on-line până la depozit de informaţii privitoare la un domeniu (tehnic sau nu).

Un astfel de blog este redactat (întreţinut) fie de o singură persoană, fie de un grup. Lu-ând în consideraţie tematica abordată, un blog poate fi încadrat în următoarele categorii principale: personal, comunitar, oferind noutăţi, specializat, colaborativ, politic, corpora-tist.

După Greg Hard, „blogging-ul nu reprezintă doar un blog. Este o manieră de partajare la nivelul întregii lumi a opiniilor şi gândurilor personale. Dacă punem la dispoziţie informa-ţii de interes, atunci trebuie să partajăm hiper-legături şi să facem disponibile comentariile din cadrul altor blog-uri. Legăturile hipertext reprezintă punctul forte al Web-ului, iar în cazul Weblogging-ului ele sunt elementul cheie.”

Din punctul de vedere al strategiei realizării afacerilor electronice sau a instituirii unei comunităţi on-line, „blogging-ul este una dintre cele mai rapide căi de actualizare a sitului propriu” (Eric Dolecki).

139


Unele blog-uri devin depozitare a unor informaţii ştiinţifice de excepţie sau sunt folosite pentru organizarea de concursuri la nivel regional, naţional sau chiar mondial – un astfel de exemplu este cel al competiţiei Imagine Cup iniţiate în lumea întreagă de către corpora-ţia Microsoft, folosind tehnologiile Web proprii în cadrul sitului TheSpoke.

La fel, în domeniul e-learning, siturile dedicate unor discipline pot avea asociate astfel de blog-uri, folosite atât la prezentarea unor informaţii suplimentare referitoare la anumite subiecte ale materiei predate la curs şi/sau laborator, cât şi ca instrumente de comunicare – de cele mai multe ori, informală – dintre studenţi şi cadrele didactice (titularul discipli-nei, persoanele implicate în predarea seminarului sau laboratorului etc.).

De asemenea, un alt context de utilizare a blog-urilor este cel reprezentat de intranetul întreprinderilor virtuale, un blog putând deveni un instrument indispensabil de inter-comunicare la nivel de echipe de lucru în cadrul unui proiect. Din această perspectivă, blog-ul poate fi o componentă importantă a aplicaţiilor de tip groupware (teamware).

Conţinutul unui blog nu trebuie să fie exclusiv textual, existând blog-uri care oferă pre-zentări multimedia (audio – de succes sunt MP3 blog-urile, fotografii, video – denumirea acestei categorii fiind videoblog sau, pe scurt, vlog).

Anatomia unui blog este relativ simplă, structura sa incluzând:

un titlu (eventual un subtitlu – acest subtitlu poate fi considerat ca fiind un slogan asociat blog-ului),

o listă a mesajelor (intrărilor) curente, redactate de autorul/autorii blog-ului ori de terţi vizitatori,

o listă de legături spre alte situri sau blog-uri de interes (aşa-numitul blogroll), eventual, diverse alte componente (siglă, adrese spre liste de discuţii, statistici etc.).

Unele subiecte interesante pot fi discutate separat, utilizatorii având posibilitatea – via unor formulare Web – să-şi introducă propriile opinii sau sugestii în cadrul blog-ului. Une-le blog-uri oferă facilităţi de inserare a emoticon-urilor sau de detectare automată a adreselor Web introduse. Desigur, discuţiile pot fi monitorizate de proprietarul blog-ului, iar unele mesaje necorespunzătoare pot fi eliminate complet sau parţial de către acesta.

Pentru a putea referi un anumit mesaj (care poate dispărea de pe prima pagină a blog-ului, atunci când dinamica sa este mare), utilizatorii pot să se folosească de aşa-numita legătură permanentă (permanent link) asociată acestuia. Astfel, un mesaj poate fi accesat fie direct, fie parcurgând lista mesajelor (numite şi post-uri) existente.

O componentă opţională o reprezintă motorul de căutare internă, vizitatorii având po-sibilitatea să regăsească, pe baza unor criterii (e.g.: cuvinte-cheie incluse în subiect, data redactării, autor etc.), informaţiile cuprinse în lista mesajelor care compun blog-uri.

140


De asemenea, cele mai multe sisteme de management al Weblog-urilor dau posibilitatea programelor (roboţi sau agenţi Web) să indexeze ori să manipuleze conţinutul mesajelor via fişierele RSS (Really Simple Syndication) sau Atom asociate. Formatul RSS/Atom permite calculatoarelor să interschimbe informaţii privitoare la conţinutul siturilor Web (în acest caz, al blog-urilor). Fiind bazat pe meta-limbajul XML, un document RSS/Atom este uşor de procesat sau de creat, existând diverse instrumente – numite agregatori de conţinut – care extrag, sumarizează şi stochează datele RSS/Atom.

Disponibile de cele mai multe ori în regim open-source, pot fi folosite o serie de instru-mente de administrare comodă a blog-urilor (atât din punct de vedere al conţinutului pro-priu-zis, cât şi al configurării şi modificării preferinţelor referitoare la interfaţa Web), pre-cum Blogger, Blosxom, Blojxom, LiveJournal, Manila, MovableType sau WordPress. Aceste aplica-ţii se încadrează în categoria sistemelor de management al conţinutului (CMS – Content Management System).

Portalurile Web

Web-ul reprezintă un mediu de partajare a diverselor informaţii, specifice unui domeniu de interes: afaceri, comunităţi umane, divertisment etc. Unul dintre mijloacele de punere la dispoziţie a informaţiilor şi serviciilor este portalul Web. Dezvoltarea portalurilor este susţinută de faptul că organizaţiile trebuie şi pot să ofere informaţiile şi serviciile bazate pe Web în formatul necesar utilizatorului. Aceasta este o schimbare importantă, în primul rând deoarece majoritatea organizaţiilor, inclusiv universităţile, şi–au organizat informaţia rareori în alt format decât cel necesar membrilor comunităţilor. Acest nou şi interesant aspect al managementului Web oferit de portaluri se bazează pe ideea creării şi adminis-trării sistemelor informaţionale al căror scop de bază este menţinerea relaţiilor pozitive dintre susţinătorii unei instituţii şi acea instituţie.

Portalurile Web pot pune, în plus, la dispoziţie şi alte servicii, precum accesarea unui cont de poştă electronică, cursul valutar, starea meteo, înscrierea la liste de discuţii şi alte-le. Astfel, un portal poate fi privit drept integrator de conţinut, fără a oferi însă doar o colecţie nestructurată de legături spre alte situri.

Principalele categorii de portaluri sunt:

portalurile generale – destinate unei largi categorii de utilizatori; portalurile academice – folosite în e-science, oferind acces la resursele distribuite (in-

formaţii, aplicaţii, servicii de cercetare etc.) ale unei reţele de excelenţă într-un anumit domeniu;

portalurile educaţionale – utilizate în e-learning, pentru a pune la dispoziţie diverşilor cursanţi materiale cu caracter educaţional;

portalurile de întreprindere – disponibile în intranet-ul sau extranet-ul unei organizaţii aliniate problematicilor e-business.

141


Ca exemple de portaluri generale putem menţiona Yahoo! sau MSN (Microsoft Network), care oferă – printr-o interfaţă unică – acces la mai multe categorii de servicii standard (poştă electronică, ştiri, starea vremii, cotaţiile bursiere etc.). Un exemplu autohton de portal este reprezentat de home.ro. Unele aplicaţii de tip portal dau posibilitatea accesului la informaţii şi servicii via dispozitive mobile, de cele mai multe ori wireless.

Pentru facilitarea colaborării on-line dintre cercetători, se poate recurge la funcţionalită-ţile unui portal academic. De cele mai multe, un astfel de portal reprezintă interfaţa cu o infrastructură de calcul destinată unor proiecte ştiinţifice de anvergură, desfăşurate la ni-vel de stat, continental sau chiar mondial, graţie tehnologiilor Grid. Portalul poate oferi suport pentru căutarea şi regăsirea informaţiilor, indiferent de localizarea lor fizică, dar poate permite şi executarea de activităţi (task-uri) pe mai multe maşini, privite ca un sis-tem unic de calcul. Ca exemple de astfel de aplicaţii putem enumera Large Hadron Collider Computing Grid funcţionând la CERN, CrossGrid utilizat în chirurgia vasculară virtuală ori myGrid în domeniul bioinformaticii.

Drept exemple de aplicaţii pentru implementarea portalurilor putem menţiona BEA Secure Portal, eZ Publish, IBM Enterprise Information Portal, Microsoft SharePoint, Oracle Portal sau PHP Nuke. Tehnologiile Java pun la dispoziţie componente de tip portal numite portlet-uri.

142


143

EExxeerrcciiţţiiii şşii tteemmee pprrooppuussee

„Înainte să vă supăraţi pe cel care vă pune la treabă, amintiţi-vă că fără presiune nu se formează diamantele.” Mary Case

1. Ce deosebire este între un proxy şi un server Web?

2. Precizaţi care dintre următoarele URI-uri sunt corecte:

telnet:fenrir.infoiasi.com:8080 mailto:[email protected] http://students.infoiasi.ro/~busaco/www/ http://MyDocuments.org/scrisoare.cgi?query=Listing ftp;//ftp.uaic.ro/Readme.tex

3. Fie formularul stocat intr-o pagina de pe serverul www.neu.ro:

<form nethod="POST" action="/cgi-bin/add.cgi"> <input name="Un nume" style="width: 300px" value="dati un nume" /> <input type="hidden" name="Control" value="W " /> <input type="submit" value="Trimite" style="color: blue" /> </form>

În urma apăsării butonului de tip submit, fără ca utilizatorul să modifice formularul, ce URI va primi serverul Web? Ce metodă de transfer HTTP a fost folosită?

4. Se consideră programul de mai jos:

<?php class Animal { var $nume="C", $ani, $kg="0"; function Animal($n="rocodilescu", $a="33", $k="333") { $this->nume.=$n; $this->ani=$a; $this->kg=($k || $this->nume)? $k+$this->kg++:$k+$ani; } function seteazaAni($a="3") { $this->ani .= $a.$a; } function furnizeazaAni() {


return $this->ani; } } $m = new Animal(); #m->seteazaAni($m->kg-$m->kg[1]); $t = new Animal("oarne", $m->furnizeazaAni()); $ani = $t->furnizeazaAni()-$m->ani+$ani."0"; ?>

Ce tip şi valoare vor avea variabilele $ani, $m->kg, $t->kg şi $kg? Argumentaţi.

5. Fie următorul script PHP:

<?php class S { var $s1 = "WEB"; var $s2 = "wEb"; function S($s1 = "s1") { $m = "S" . func_num_args(); $this->$m($s1); } function S0() { echo $this->s1; } function S1($s1) { echo $s1?"->$s2":$this->s2; } function S2($s1) { echo "$this->s2"; } } $s = new S($s1); echo $s2; $s = new S(); ?>

Precizaţi ce va afişa navigatorul Web în urma apelării acestui script (presupunem că motorul PHP este operaţional).

6. Să se marcheze în XML datele privitoare la medicamentele dintr-o farmacie: nu-mele medicamentului, producătorul, furnizorul, cantitatea, preţul, indicaţiile şi contra-indicaţiile, valoarea livrărilor dintr-o lună etc.

7. Să se imagineze un set de documente XML care sa stocheze informaţii relative la mersul trenurilor (orar, staţii intermediare, tipuri de trenuri) şi la rezervarea locurilor si eliberarea de bilete la anumite trenuri. Se vor specifica spaţii de nume şi maniere de vali-dare (DTD-uri şi/sau scheme XML) pentru fiecare document în parte.

8. Să se organizeze în format XML datele referitoare la proprietăţile imobiliare ale unei persoane, în vederea realizării ulterioare de programe pentru determinarea tuturor imobilelor unei persoane, listarea persoanelor dintr-un imobil, situaţia imobilelor dintr-un cartier etc.

144


9. Să se modeleze ca documente XML informaţiile privitoare la cursele aeriene fur-nizate de o anumită companie şi apoi să se realizeze o aplicaţie Web care să le proceseze. Eventual, se vor implementa şi diverse servicii Web pentru a furniza detalii referitoare la cursele disponibile pe un anumit traseu ori la o dată calendaristică.

10. Să se stocheze ca document(e) XML informaţiile incluse de o agendă de birou, permiţându-se realizarea de adnotări pe zile, săptămâni, luni, includerea de legături Web, programarea de întâlniri etc. Să se implementeze aplicaţia Web care să proceseze aceste informaţii, folosindu-se atât modelul DOM, cât şi interfaţa SAX.

11. Să se conceapă, în orice limbaj de programare preferat, un script CGI care să fie utilizat pentru evaluarea expresiilor matematice cu paranteze.

12. Să se realizeze o aplicaţie (sit) Web pentru vizualizarea şi trimiterea de ilustrate electronice, pe diverse teme (peisaje, oraşe celebre, figuri de personalităţi, opere de artă etc.). Informaţiile vor fi stocate exclusiv în documente XML.

13. Să se realizeze un studiu comparativ al manierelor de procesare (SAX şi DOM) a aceluiaşi document XML, pe mai multe platforme (e.g., Linux şi Windows), recurgându-se la mai multe limbaje de programare (de exemplu, Perl şi PHP). O posibilă statistică va putea lua în calcul numărarea elementelor unui document XML având structura: <doc><element atribut=”valoare” /></doc>, unde <element> va putea apărea de zece mii, zece sute de mii şi, respectiv, zece milioane de ori.

14. Să se implementeze o aplicaţie Web pentru stocarea în manieră distribuită a dife-ritelor tipuri de teste de cunoştinţe care pot fi folosite în regim de testare sau auto-testare la diverse discipline. Pe baza autentificării, titularii de curs vor putea gestiona colecţia de teste de la discipline diferite (accesare întrebări şi răspunsuri, realizare de teste prin alege-rea întrebărilor după diverse criterii sau aleatoriu etc.). Studenţii vor putea avea acces la module de auto-testare pe diverse domenii, contra-cronometru sau nu (demo-uri ale unor teste reale în regim de examen). Testele vor putea fi de mai multe tipuri (single/multiple choice, cu diferite modalităţi de acordare a punctajelor, cu întrebări dependente una de cea-laltă etc.), bazate sau nu pe cronometrare. Aplicaţia va putea oferi rapoarte privitoare la prestaţia unui anumit student la o disciplină, eventual diferite statistici – numerice şi gra-fice – referitoare la gradul de cunoştinţe ale studenţilor (e.g., numărul răspunsurilor erona-te, timpul realizat, întrebările la care n-a răspuns nici unul dintre studenţii testaţi etc.).

Se vor oferi posibilităţi de căutare de teste pe diverse criterii – domeniu de interes (i.e. limbajul PHP), cuvinte cheie (e.g., moştenire multiplă), grad de dificultate etc. – şi de res-tricţionare a accesului (de exemplu, doar studenţii înscrişi la cursul de programare Web vor beneficia de (auto-)testare la acest obiect).

Toate informaţiile vor fi stocate în cadrul unor documente XML.

145


15. Să se creeze o aplicaţie Web care să ofere accesul la conţinut documentar, struc-turat pe teme şi sub-teme de interes (e.g., Programare :: Limbaje :: Scripting :: Perl ori IA :: Recunoaştere forme :: Reţele neurale :: Auto-învăţare). Se va avea în vedere faptul că documenta-ţiile:

pot fi stocate în diverse formate (proprietare sau nu), în manieră distribuită (pe mai multe maşini),

vor putea fi accesibile în limbi multiple (e.g.: engleză şi/sau română),

vor putea fi de un anumit tip (carte, manual de referinţă, specificaţie, tutorial etc.), într-un anumit stadiu (ciornă, propus pentru standardizare, final etc.).

Pentru fiecare resursă, se vor reţine cel puţin următoarele date:

autor(i);

titlu;

tip (carte, articol, raport tehnic, referat etc.);

editor (e.g., Springer Verlag, Prentice-Hall,…);

an al apariţiei;

loc al apariţiei;

rezumat;

cuvinte cheie (i.e. Web, XML, căutare structurată, DOM);

legătură spre documentul complet (dacă există) sau spre o oglindire locală.

Acest sit va putea oferi statistici privind cele mai accesate documente, localizarea clien-ţilor şi va oferi posibilitatea de a fi administrat via Web, de la distanţă. Soluţiile de stocare a datelor vor recurge la tehnologiile XML.

146


147

RReessuurrssee bbiibblliiooggrraaffiiccee

„Este bine să existe un sfârşit în fiecare călătorie, dar în final cea mai importantă este chiar călătoria.” Ursula K. LeGuin

Alboaie, L, S. Buraga, Servicii Web, Polirom, Iaşi, 2006:

http://www.infoiasi.ro/~busaco/books/ws/ Anghel, T., Programarea în PHP. Ghid practic, Polirom, Iaşi, 2005 Apparao, V. et al. (eds.), Document Object Model (DOM) Level 1 Specification, W3C Recommendation,

Boston, 1998: http://www.w3.org/TR/REC-DOM-Level-1

Berlung, A. et al. (eds.), XML Path Language (XPath) 2.0, W3C Working Draft, Boston, 2005: http://www.w3.org/TR/xpath20/

Berners-Lee, T., Fielding, R., Masinter, L., Uniform Resource Identifiers (URI): Generic Syntax, RFC 2396, Internet Engineering Task Force (IETF), 2004: http://www.ietf.org/rfc/rfc2396.txt

Booth, D., Liu, C. (eds.), Web Services Description Language (WSDL) Version 2.0 Part 0: Primer, W3C Candidate Recommendation, Boston, 2006: http://www.w3.org/TR/wsdl20-primer

Bray, T. et al. (eds.), Extensible Markup Language 1.0 (4th Edition), W3C Recommendation, Boston, 2006: http://www.w3.org/TR/xml

Bray, T. et al. (eds.), Namespaces in XML (2nd Edition), W3C Recommendation, Boston, 2006: http://www.w3.org/TR/REC-xml-names

Buraga, S., Tehnologii XML, Polirom, Iaşi, 2006: http://www.infoiasi.ro/~busaco/books/xml/

Buraga, S., Proiectarea siturilor Web (ediţia a doua), Polirom, Iaşi, 2005: http://www.infoiasi.ro/~design/

Buraga, S., Semantic Web, Matrix Rom, Bucureşti, 2004: http://www.infoiasi.ro/~sweb/ Buraga, S. et al., Programare Web în bash şi Perl, Polirom, Iaşi, 2002:

http://www.infoiasi.ro/~cgi/ Buraga, S. (coord.), Tendinţe actuale în proiectarea şi dezvoltarea aplicaţiilor Web, Matrix Rom, Bucu-

reşti, 2006: http://www.infoiasi.ro/~busaco/books/nw05/

Buraga, S. (coord.), Situri Web la cheie. Soluţii profesionale de implementare, Polirom, Iaşi, 2004: http://www.infoiasi.ro/~busaco/books/webapps/

Buraga, S. (coord.), Aplicaţii Web la cheie, Polirom, Iaşi, 2003: http://www.infoiasi.ro/~phpapps/


Cabrera, L.F., Kurt, C., Web Services Architecture and Its Specifications, Microsoft Press, 2005 Clark, J. (ed.), XSL Transformations (XSLT) – Version 1.0, W3C Recommendation, Boston, 1999:

http://www.w3.org/TR/xslt

Clark, J., DeRose, S. (eds.), XML Path Language (XPath) Version 1.0, W3C Recommendation, Bos-ton, 1999: http://www.w3.org/TR/xpath

Daum, B., Merten, U., System Architecture with XML, Elsevier Science, 2003 Erl, T., Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall PTR,

2005 Fallside, D., Walmsley, P. (eds.), XML Schema Part 0: Primer (Second Edition), W3C

Recommendation, Boston, 2004: http://www.w3.org/TR/xmlschema-0/ Freed, N., Borenstein, N., Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet

Message Bodies, RFC 2045, Internet Engineering Task Force (IETF), 1996: http://www.ietf.org/rfc/rfc2045.txt

Freed, N., Borenstein, N., Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, RFC 2046, Internet Engineering Task Force (IETF), 1996: http://www.ietf.org/rfc/rfc2046.txt

Geroimenko, V., Dictionary of XML Technologies and the Semantic Web, Springer-Verlag, 2004 Gettys, J. et al., Hypertext Transfer Protocol – HTTP/1.1, RFC 2616, Internet Engineering Task

Force (IETF), 1999: http://www.ietf.org/rfc/rfc2616.txt

Guruge, A., Web Services: Theory and Practice, Digital Press, 2004 Jacobs, I., Walsh, N., Architecture of the World Wide Web, Volume One, W3C Recommendation, Bos-

ton, 2004: http://www.w3.org/TR/webarch/

Le Hors, A. et al. (eds.), Document Object Model (DOM) Level 2 Core Specification, W3C Recommendation, Boston, 2000: http://www.w3.org/TR/DOM-Level-2-Core

Le Hors, A. et al. (eds.), Document Object Model (DOM) Level 3 Core Specification, W3C Recommendation, Boston, 2004: http://www.w3.org/TR/DOM-Level-3-Core

Mitra, N. (ed.), SOAP Version 1.2 Part 0: Primer, W3C Recommendation, Boston, 2003: http://www.w3.org/TR/soap12-part0/

Shiflett, C., HTTP Developer’s Handbook, Sams Publishing, 2003 Tanasă, Ş., Olaru, C., Dezvoltarea aplicaţiilor Web folosind Java, Polirom, 2005 Weerawarana, S. et al., Web Services Platform Architecture, Prentice Hall PTR, 2005 * * *, Apache2Triad: http://apache2triad.sourceforge.net/ * * *, Apache XML: http://xml.apache.org/

* * *, Café con Lèche: http://www.cafeconleche.org/ * * *, Exemple privitoare la limbajele XML: http://www.xmlpitstop.com/ * * *, Expat: http://expat.sourceforge.net/

* * *, Fundaţia Mozilla: http://www.mozilla.org/

* * *, IBM’s DeveloperWorks Web Services: http://www-136.ibm.com/developerworks/webservices

* * *, libxml: http://xmlsoft.org/

* * *, MSDN (Microsoft Developer Network): http://msdn.microsoft.com/

* * *, Organizaţia OASIS (Organization for the Advancement of Structured Information Standards): http://www.oasis-open.org/

* * *, O’Reilly OnLAMP: http://www.onlamp.com/

* * *, Resurse privind programare pe partea de server: http://www.devshed.com/Server_Side/

* * *, SAX (Simple API for XML): http://www.saxproject.org/

148


* * *, Situl dedicat dezvoltatorilor MySQL: http://dev.mysql.com/ * * *, Situl oficial PHP: http://www.php.net/ * * *, Sun’s XML Technologies: http://java.sun.com/xml * * *, The Open Sourcery: http://theopensourcery.com/ * * *, UDDI (Universal Description, Discovery, and Integration): http://www.uddi.org/ * * *, Web Services Activity: http://www.w3.org/2002/ws/ * * *, World-Wide Web Consortium, Boston, 2007: http://www.w3.org/ * * *, XML.com: http://www.xml.com/ * * *, Yahoo! Developer Network: http://developer.yahoo.net/

* * *, ZVON: http://www.zvon.org/

149