tehnologii web decrypted

7/31/2019 Tehnologii WEB Decrypted

1/144

TEHNOLOGII WEB

SUPORT CURSAn universitar 2006-2007

Conf. dr. Cristina Mndru

p d f Machine

A pdf w r i te r t ha t produces qua l i ty PDF f i les w i th ease!

Produce quality PDF files in seconds and preserve the integrity of your original documents. Compatible acrossnearly all Windows platforms, simply open the document you want to convert, click print, select the

Broadgun pdfMachine printer and thats it! Get yours now!
http://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?cl


2/144

2

1. CONCEPTELE DE BAZ ALE ARHITECTURII WEB................................ 5

1.1 Arhitecturi pentru INTERNET............................................................................................ 5

1.1.1 Arhitecturi hardware pentru Internet ............................................................................. 51.1.2. Arhitecturi software pentru Internet.............................................................................. 71.1.3. Arhitectura client-server aplicat la Web ..................................................................... 81.1.4 Arhitectura MVC........................................................................................................... 9

1.2 Comunicarea in Web........................................................................................................ 101.2.1 Protocolul HTTP (HyperText Transfer Protocol)..................................................... 111.2.2. Cererea HTTP............................................................................................................ 111.2.3 Rspunsul HTTP ..................................................................................................... 121.2.4 Identificare resurse: URI i URL ............................................................................... 131.2.6 Gestiunea reprezentrilor......................................................................................... 191.2.7 Structura informaiilor pe site-uri Web ..................................................................... 20

1.3 Formate de date ............................................................................................................. 201.3.1 Formate binare i textuale pentru date ....................................................................... 201.3.2. Hipertext..................................................................................................................... 211.3.3. Formate de date bazate pe XML ............................................................................... 211.3.4. Versiuni i extensibilitate ........................................................................................... 231.3.5. Compoziie i formate de date ................................................................................... 231.3.6 Separareantre coninut, prezentare i interaciune ............................................... 24

1.4 Principiile generale ale arhitecturii Web....................................................................... 241.4.1. Specificaii ortogonale................................................................................................ 241.4.2. Extensibilitatea........................................................................................................... 251.4.3. Gestionarea erorilor ................................................................................................... 251.4.4. Interoperabilitate bazat pe protocol ......................................................................... 26

2. HTML......................................................................................................... 27

2.1 Modelul DOM-HTML ........................................................................................................ 272.1.1 Modelul Document- Obiect (DOM) ........................................................................... 272.1.2 Modelul DOM HTML ................................................................................................ 29

2.2 HTML (HyperText Markup Language) ........................................................................... 312.2.1. Elementele limbajului HTML ..................................................................................... 312.2.2. FORME ...................................................................................................................... 332.2.3 CADRE (FRAMES)..................................................................................................... 342.2.4 HTML DINAMIC (DHTML) ......................................................................................... 37

2.2.5 FOI DE STIL (SS Style Sheets)............................................................................. 38

3. ARHITECTURI PENTRU EXTINDERE FUNCIONALITATE LA CLIENT43

3.1. Componente .................................................................................................................... 43

3.2 OBIECTEN PAGINI WEB ................................................................................................ 443.2.1 Plug-ins ....................................................................................................................... 443.2.2 COMPONENTE ActiveX............................................................................................. 45

3.3 JAVA SCRIPT.................................................................................................................... 463.3.1. Specificaiile standardului ECMAScript ..................................................................... 46

3.3.2. Identificarea obiectelor din ierarhia JavaScript.......................................................... 47

p d f Machine





3/144

3

3.3.3. Modelul evenimentelor.............................................................................................. 493.3.4. Structura paginilor HTML ce conin JavaScript ......................................................... 503.3.5 Exemple ..................................................................................................................... 50

3.4 APPLET ............................................................................................................................. 53

3.4.1 Apel applet .................................................................................................................. 543.4.2 Operaiile realizate de agentul utilizator..................................................................... 55

3.5 STRI PERSISTENTE LA CLIENT................................................................................... 573.5.1 COOKIE-s ................................................................................................................... 573.5.2 Crearea unui cookie.................................................................................................... 583.5.3 tergerea unui cookie................................................................................................. 593.5.4 Accesul clientului la cookie......................................................................................... 59

4. XML I TEHNOLOGII ASOCIATE............................................................ 60

4.1 Baze de date semistructurate i XML ............................................................................ 60

4.2 SGML (Standard Generalized Markup Language) ....................................................... 62

4.3 XML (eXtended Markup Language) .............................................................................. 634.3.1 Documente XML ....................................................................................................... 634.3.2 Marcaje .................................................................................................................... 644.3.3 Elemente.................................................................................................................. 644.3.4 Atribute...................................................................................................................... 654.3.5 Referine ................................................................................................................... 664.3.6 Structura unui document XML ................................................................................... 674.3.7 Instruciuni de procesare ......................................................................................... 674.3.8 Restricii asupra documentelor XML....................................................................... 684.3.9 Definirea tipului unui document (DTD) .................................................................... 68

4.4 Terminologie i definiii.................................................................................................. 70

4.5 XML Schema.................................................................................................................... 724.5.1 Caracterizare XMLSchema........................................................................................ 724.5.2 Structura unei scheme XML ...................................................................................... 73

4.6 Spaii de nume i calificatori.......................................................................................... 77

4.7 Familia de limbaje XML................................................................................................... 824.7.1 XPath ......................................................................................................................... 834.7.2 Familia foilor de stil: XSL, XSLT i XSLFO.............................................................. 904.7.3 XQuery..................................................................................................................... 92

4.7.4 Modelul de date pentru XQuery, XPath i XSLT .................................................... 934.7.5 XLink ......................................................................................................................... 954.7.6 XPointer ................................................................................................................... 974.7.7 XInclude ................................................................................................................... 994.7.8 XML Base .............................................................................................................. 1004.7.9 XHTML.................................................................................................................... 1014.7.10 SVG ...................................................................................................................... 101

5. ARHITECTURI PENTRU EXTINDERE FUNCIONALITATE LA SERVER............................................................................................................................... 103

5.1 CONTAINER-ul WEB ...................................................................................................... 103

p d f Machine





4/144

4

5.2 CGI (Common Gateway Interface)................................................................................ 104

5.3 Tehnologii de scripting la server.................................................................................. 1065.3.1 Tehnologia ASP (Active Server Pages).................................................................... 1065.3.2 Modelul Obiect al tehnologiei ASP ........................................................................... 108

5.3.3 Aplicaii ASP ............................................................................................................. 1095.3.4 Programare la server cu PHP................................................................................... 111

5.4 ACCESUL LA DATE PERSISTENTE ............................................................................. 1155.4.1 ACCESUL LA SISTEMUL DE FIIERE .................................................................. 1155.4.2 ACCESUL LA BAZE DE DATE ................................................................................ 117

5.5. TEHNOLOGII JAVA PENTRU EXTINDEREA FUNCIONALITII LA SERVER....... 1275.5.1 SERVLET.................................................................................................................. 1275.5.2 JSP (Java Server Pages) ......................................................................................... 136

p d f Machine





5/144

5

1. CONCEPTELE DE BAZ ALE ARHITECTURII WEB

n acest capitol sunt prezentate noiuni fundamentale despre arhitecturi desisteme de calcul, arhitecturi hardware care stau la baza Internetului i arhitecturisoftware construite peste acestea, bazate pe paradigmele client/server i MVC. ncontinuare sunt descrise componentele fundamentale ale arhitecturii Web pentruidentificarea resurselor, interaciunea resurselor i reprezentarea datelor imetadatelor.n final sunt prezentate cerinele i evoluia arhitectural ce a condus laapariia stilului REST, destinat sistemelor hipermedia moderne. Capitolul ofer operspectiv de ansamblu asupra conceptelori problematicii specifice Web, a creicunoatere este necesar pentru dezvoltarea de aplicaii n acest mediu distribuitcomplex.

1.1 Arhitecturi pentru INTERNET

Arhitectura reprezint perspectiva structural asupra unui sistem de calcul.Aceasta definete numrul, tipurile i subtipurile resurselor componente iinterconectrile lor.

Fiecare tip de component corespunde unui mecanism pe care aceasta lrealizeaz n sistem.

Interconectarea componentelor este realizat pe baza unor abloane, caredefinesc modul de interconectare ntre componente prin reguli i restricii deinterconectare.

1.1.1 Arhitecturi hardware pentru Internet

Internet-ul este o reea de reele format din platforme (sub-reele) multiple ieterogene care trebuie s comunice ntre ele. Pentru aceasta se utilizeaz diferite cide comunicare (cablu, fibr optic, unde radio) i componente ce distribuieinformaiile ntre platforme, numite router-e.

Privit din punct de vedere logic, comunicarea ntre clienii C1i C2 aflai nsubreele diferite, posibil cu protocoale de comunicare de nivel inferior diferite, este o

comunicare direct

. Din punct de vedere fizic aceast

comunicare se poate face pe

Reea 1 Reea k

Reea 2

RouterRouter k

Router 2

CLIENT c1

CLIENT c2

Fig.1.1 Arhitectur hardware pentru Internet

p d f Machine





6/144

6

cel puin dou ci: de la clientul C1 la router-ul R1, de la R1 la router-ul Rki apoi larouter-ul R2. De la R2 informaia este transmis clientului C2. A doua cale esteformat de succesiunea de corespondeni client C1, routerR1, routerR2i client C2.

Exist dou variante de realizare a unei comunicari logice ntre clienii

Internet-ului. Anterior am prezentat varianta care utilizeaz

router-e. A doua variant

este mai complexi este reprezentat de furnizorul de servicii Internet. Fiecare dinaceste variante ofer clienilor servicii specifice pentru comunicare n Internet.

Router-ul realizeaz transparena comunicrii fizice pentru cei doi clieni. Dinpunctul de vedere al clienilor avem urmtoarea arhitectur:

Router-ul este o component Internet ce furnizeaz dou servicii clienilor si:serviciul de tranzit i serviciul de acces. Serviciul de tranzitrealizeaz legtura ntreregiuni cu lrgimi mari de band i viteze mari de transfer. Serviciul de accesrealizeaz comunicarea ntre clieni prin linii dedicate sau comutate.

Fiecare routergestioneaz informaii referitoare la zona sa de aciune. Router-ele comunic ntre ele n mod dinamic, n vederea stabilirii cii optime de transmiterea fiecrui pachet de informaii. La acest nivel sunt rezolvate dinamic problemele careapar datorit unor defecte n reeaua fizic de comunicare sau datorit congestionriitraficului.

Identificarea corespondenilor se face pe baza unui set de identificatori

numerici unici disponibili la nivelul reea (IP). Pentru uzul nivelelor superioare, decare ne ocupm n monografia de fa, se utilizeaz o schem de nume explicite,bazat pe o organizare pe domenii i subdomenii a mainilor din Internet.Traducerea acestor nume n valorile numerice ale identificatorilor unici se face pebaza corespondenelor coninute n baze de date specializate aflate n servere carefuncioneazca servicii de nume la nivel de domeniu (DNS - Domain Name Server).

A doua variant de comunicare ntre clieni Internet este reprezentat defurnizorul de servicii Internet. Acesta este o form pentru intermediereacomunicaiilor n Internet superioarrouter-ului.

Furnizorul de servicii Internet (ISP Internet Service Provider) ofera mai multetipuri de servicii clienilor si. Serviciul de tranzit i serviciul de acces au aceleai

funcii ca

i cele oferite de

router. Furnizorul de servicii Internet ofer n plus servicii

Client 1Client 2

Cale de comunicare backbone

Fig.1.2 Comunicare logic n Internet

InternetISP ISP

Client 1Client 2

Fig.1.3 Comunicare utiliznd furnizori de servicii Internet

p d f Machine





7/144

7

cu valoare adaugat. Acestea sunt servicii de server Web, servicii de firewall, serviciide intraneti servicii de extranet.

Serviciile de server Web realizeaz gzduirea de site-uri Web ca i accesul laacestea. Serviciile de firewall asigur protecia controlat a accesului clienilor la

diferite servicii. Serviciile de intranetpermit crearea de reele private cu acces limitatdoar la clienii reelei respective. Serviciile de extranetofer posibilitatea crerii dereele private virtuale, deoarece permit extinderea unui intranetcu posibilitatea de aiei n Internet ctre anumite noduri privilegiate, noduri pentru care se relaxeazrestriciile din firewall. Nodurile privilegiate au ataate nivele de privilegiu bazate pestructura de comunicare logic definit pentru reeaua virtual. De exemplu, se potdefini nivele de privilegiu diferite pentru diferite categorii de utilizatori cum ar fi clien i,furnizori sau prieteni.

1.1.2. Arhitecturi software pentru Internet

Paradigma care st la baza arhitecturilor software pentru Internet este

paradigma CLIENT-SERVER.Paradigma client/server se bazeaz pe doi actori: clientul i serverul. Clientulare rolul de a solicita un serviciu, iar serverul are rolul de a oferi clientului serviciulsolicitat.

Schimbul de informaii ntre procesele client i server se face prin intermediulunui canal de comunicare prin care circul mesaje de cerere de la client la serverimesaje de rspuns de la server la client.

O arhitectur simpl bazat pe paradigma client-server este compus dintr-unserver i mai muli clieni.

Aceasta este o arhitectur pe dou straturi i este utilizat de aplicaiileclient/server cu server centralizat.

Solicitrile clienilor sunt rezolvate n ntregime de ctre server, acestaconinnd toate informaiile i procesele necesare construirii rspunsului.

rspuns

cerere

CLIENT SERVER

Fig.1.4 Paradigma client/server

Raspuns

ServerClientCerere

Client

Client

Fig.1.5 Arhitectura cu un serveri mai muli clieni

p d f Machine





8/144

8

n cazul n care serverul are un grad mare de complexitate, o arhitecturbazat pe paradigma client/server este organizat pe mai multe straturi.

n acest caz, pentru realizarea unui serviciu, un client apeleaz la un servercare, pentru a oferi serviciul solicitat, necesit o serie de funcii pe care le obineapelnd la rndul su la unul sau chiar mai multe servere.

Un proces poate fi client al unuia sau mai multor procese, dar, n acelai timp,poate fi server pentru alt set de procese.

1.1.3. Arhitectura client-server aplicat la Web

Arhitectura client-server pe dou straturi aplicat la Web este compus dinclieni de tip navigator (browser) si din server de tip WebServer.

Server-ul Web are dou interfee. Prin interfaa cu clienii se realizeazoperaiile de preluare a solicitrilor acestora i de transmitere a rspunsului. Clieniisolicit documente aflate pe server care sunt depozitate n fiiere de tip *.html.

Serverul Web are ca principala funcie asigurarea accesului la fiierele*.html, care formeaz cea mai simpl varianta de site Web. Odat cu evoluiatehnologiilor au aprut modaliti de extindere a acestei funcionaliti simple att pepartea clientului, ct i pe partea server-ului. Acestea permit separarea diferitelor

WebServer

RspunsInterfaaclient

BrowserCerere

Interfaa cu site-ul Web

HTTP

Fig.1.7 Arhitectura Web clasic

Fisiere *.htmlaflaten sistemul de fiiere al mainii gazd

raspuns

rspuns

rspunsrspuns

rspuns

cerere

cerere

cererecerere

cerere

CLIENT SERVER

SERVER

SERVER

Fig.1.6 Arhitectura client/server cu straturi multiple

p d f Machine





9/144

9

tipuri de funcionaliti ale unei aplicaii Web, astfel nct arhitectura acesteia devinemai complex.

n arhitectura client/server tradiional, pe dou straturi, clienii aplicaieiintermediaz interaciunile utilizatorului, n mod tipic prin GUI1, i implementeazlogica aplicaiei, incluznd i accesele la baze de date. n aceste arhitecturi logica

aplicaiei este procesat pe mainile utilizatorilor. ntr-o aplicaie pe mai multe straturiclienii pot delega logica aplicaiei i accesul la baze de date ctre componentesoftware aflate pe nivele intermediare.

n aplicaiile din Internet clienii Web au nlocuit clienii aplicaiilor de sinestttoare. n arhitecturile bazate pe clieni Web, nivelul interaciunii cu utilizatoruleste separat de nivelul client tradiional. Navigatoarele Web sau aplicaii cu scopgeneral similare gestioneaz interaciunea cu utilizatorul, lsnd restulresponsabilitilor nivelului client n seama aplicaiilor aflate pe server. Acesteresponsabiliti includ logica de comand a interfeei utilizator, interaciunea cucomponentele de pe nivelele intermediare i cea cu sursele de date. n aceastarhitectur, pentru un utilizator final, navigatorul este clientul tuturor aplicaiilor

bazate Web.Clienii Web se caracterizeaz prin:- un navigator sau o aplicaie similar pentru gestionarea interaciunii

cu utilizatorul,- HTML (cu JavaScript i/sau DHTML), XHTML sau XML (Cu XSL), ca

mijloc de definire a interfeei utilizator,- HTTP/HTTPS ca protocol pentru schimbul de informaii ntre clienii

Web i aplicaiile Web.Prin separarea prezentrii datelor de ntreinerea acestora se obin aplicaii

Web care corespund unei alte paradigme arhitecturale, numit Model-View-Controller (MVC) i descris n continuare.

1.1.4 Arhitectura MVC

Arhitectura MVC ("Model-View-Controller") este o modalitate de a mpricerinele de funcionalitate ale aplicaiei ntre obiectele responsabile cu ntreinereadatelor i cele responsabile cu prezentarea datelor, astfel nct s se minimizezegradul de cuplarentre grupuri de obiecte cu funcionaliti diferite.

1 Graphic User Interface.

gesturi utilizator

selecie view

notificare modificare

modificare stare

interogare asupra strii

eveniment

invocare metod

Modelncapsuleaz starea aplicaieiRspunde la interogri asupra striiExpune funcionalitatea aplicaieiNotific modificrile ctre vederi

ControllerDefinete comportamentul aplicaieiPunen coresponden aciunileutilizatorului cu actualizrile modeluluiSelecteaz view pentru rspunsCorespunde la o funcionalitate

Fig.1.8 Arhitectura MVC

Vedere(view)Red modeleleSolicit actualizri de la modeleTrimite gesturile utilizatorului la controllerPermite controller-ului sa selecteze oanumita vedere

p d f Machine





10/144

10

Spre deosebire de separarea functionalitii unui sistem conform rolurilor declient i de server, aceast arhitectur introduce trei roluri in sistem.

Modelul(M) reprezint datele aplicaiei

i regulile referitoare la accesul

i la

modificarea acestora.De multe ori modelul servete ca o aproximare software a unui proces din

lumea real iar n definirea lui se aplic tehnici simple de modelare a lumii reale.Atunci cnd modelul se modific, are loc notificarea vederilor, care au astfel

posibilitatea de a interoga modelul asupra strii sale. Controller-ul acceseazfuncionalitatea aplicaiei ncapsulat n model.

O vedere(V) red coninutul modelului ntr-un format specific. Funciile uneivederi sunt accesarea datelor din model i specificarea modului de (re)prezentare aacestora. Dac modelul se schimb, vederea este responsabil cu pstrareaconsistenei ntre datele din model i reprezentarea acestora. Tot vederea rspunde

de transmiterea c

tre controllera solicit

rilor (gesturilor) utilizatorului.Controller-ul(C) definete comportamentul aplicaiei. Pentru aceasta elinterpreteaz gesturile utilizatorului i le pune n coresponden cu aciunile cetrebuie realizate de model. Pentru fiecare set de funcii nrudite exist cte uncontroller.

1.2 Comunicarea in Web

Arhitectura software este o perspectiv abstract asupra sistemului i unmodel pentru compararea diferitelor sisteme. Ea definete alocarea i identificareacomponentelor unui sistem, interaciunile dintre acestea ca i cantitatea i

granularitatea necesar realizrii acestor interaciuni n cazul aplicaiilor Webcomunicarea este restricionat la transfer de mesaje.Realizarea unui transfer prin interfaa cu clientul se face n mai multe etape.

Acestea sunt: stabilirea conexiunii, emiterea unei cereri de ctre client, emiterearaspunsului de ctre serveri nchiderea conexiunii.

Comunicarea ntre componentele arhitecturii Web are loc pe baza unuiprotocol de comunicare specific. Protocolul de comunicare este colecia de regulicare definesc comunicarea ntre doua entitati, n cazul nostru ntre componenteleunei arhitecturi client/server. Aceste reguli se refer la structurarea datelor care setransferi la ordinea de realizare a transferurilor.

Protocolul de comunicare ntre componentele unei aplicaii Internet este o

entitate complex care se bazeaz pe o stiv de protocoale. Fiecare nivel al acesteistive utilizeaz serviciul de comunicare oferit de nivelul inferior. Ultimul nivel aparinecomunicrii fizice.

Modelul general al comunicarilorn reea este modelul OSI, care conine aptenivele: aplicaie, prezentare, sesiune, transport, reea, legatur de date i nivelul fizic.Modelul TCP/IP utilizat n reele de calculatoare acoper primele patru niveleinferioare ale modelului OSI i reprezint un standard pentru nivelele reea (Internet)i transport. La nivelul reea Internet este definit protocolul IP care asigur legturantre calculatoare identificate prin adrese numerice unice de Internet numite IP.ntreacestea sunt transmise pachete cu informaii. La nivelul transport sunt furnizateservicii de gestionare a pachetelor IP. Aceste servicii realizeaz modelul comunicrii

p d f Machine





11/144

11

end-to-end(cu sursi destinaie cunoscute), rendez-vousal conexiunilor i controlulfluxului pentru comunicare date.

Peste TCP/IP se suprapune un singur nivel (corespunzator nivelelorsuperioare din modelul OSI), care reprezint nivelul aplicaiei. Pentru acest nivelexist mai multe protocoale, cele mai semnificative fiind urmtoarele:

- Telnet protocol pentru conectarea clientului la o interfa de lansare comenzi, nregim de terminal- FTP protocol pentru transfer fisiere (File Transfer Protocol)- SMTP protocol pentru e-mail (Simple Mail Transfer Protocol)- POP protocol pentru e-mail- DNS protocol pentru numire maini Internet (Domain Name Server)- HTTP protocol pentru comunicare hipertext (HyperText Transfer Protocol)

1.2.1 Protocolul HTTP (HyperText Transfer Protocol)

HTTP este un protocol la nivel de aplicaie pentru sisteme informaionalehipertext i hipermedia distribuite i colaborative. El este un protocol generic, fr

memorare stare (stateless). Utilizarea sa de baz este n transferul de hipertext ihipermedia. Totui, prin extensii ale tipurilor de cereri, ale codurilor de eroare iconinutului din antet, poate fi folosit i de sisteme de gestiune a obiectelor distribuitesau de servere de nume. Una din caracteristicile sale fundamentale este tipizarea inegocierea reprezentrilor datelor, ceea ce permite construirea sistemelorindependent de datele ce sunt transferate.

HTTP este protocolul de comunicare cu serverul Web. Att clientul Web ct iserverul Web implementeaz acest protocol. Pentru aceasta, fiecare are un modulsoftware care conine aceast implementare.

Protocolul HTTP este de tip cerere/rspuns pentru o resurs identificat cuURL2. Protocolul HTTP ofer o funcionalitate sporit fa de alte protocoale,incluznd un subset al funcionalitii de transfer de fiiere, abilitatea de a solicitacutarea unui index, negociere automat a formatului i abilitatea de a deferi cerereaclientului ctre un alt server. HTTP realizeaz unificarea diferitelor tipuri de date (text,imagine, etc.), a variaiilor de localizare i de protocol, prezentnd clientului un formatomogen, sub form de pagini, a informaiilor. Prin HTTP se asigur transferul defluxuri de caractere organizate pe linii terminate cu . Protocolul HTTP defineteatt formatul cererii ct i formatul rspunsului.

1.2.2. Cererea HTTP

Fiecare cerere HTTP utilizeaz o conexiune proprie. Spunem ca HTTP esteun protocol stateless deoarece nu pstreaz starea de la o cerere a unui client laalta. Acesta reprezint un dezavantaj ce este acoperit de o serie de tehnologiiadugate peste HTTP, att la client (cookies) ct i la server (gestiune sesiuni client).Utiliznd aceste tehnologii se poate realiza gruparea coleciilor de cereri aflate ndiferite relaii logice.

O cerere HTTP estensoit de identificatorul resursei solicitate, URL. CerereaHTTP este format din patru elemente componente, specificaten figura urmtoare.

Component SemnificaieMetoda Comanda de executat asupra resursei:

2 Uniform Resource Locator.

p d f Machine





12/144

12

GET/HEAD/PUT/POST/DELETE/TRACE

Antet (header) Informaii despre cerere i clientLinie liber Separator obligatoriu

Coninut (body) Date de transferat

Pentru fiecare cerere se definete o metod prin care se specific tipulrspunsului ateptat de client. Dac metoda specificat este GET, clientul primeteresursa identificat cu URL. Dac metoda este HEAD, clientul primete doarinformaii despre resurs (meta-date) i nu resursa propriu-zis. Dac n cerere sespecific metoda PUT, serverul plaseaz coninutul transmis prin cerere (body) lalocaia identificat cu URL Coninutul transmis devine noua resurs, aceasta fiind ometoda prin care clientul poate modifica coninutul site-ului Web. Evident c aceast

modificare se face n limita permisiunilor acordate de administratorul site-ului.Metoda POST este, de asemenea, destinat transmiterii unei entiti de la client laserver. n acest caz se specific identificatorul resursei ce va prelucra entitateatransmis n mesaj. Exist, de asemenea, nc dou metode mai puin utilizate:DELETE, prin care se solicit tergerea unei entiti de pe server i TRACE, princare se invoc o cerere de diagnosticare.

Prezentm n continuare un exemplu de cerere n care e specificat metodaPOST.

1.2.3 Rspunsul HTTP

Rspunsul serverului Web este format din trei elemente componente,specificaten figura ce urmeaz.

Component SemnificaieStare Versiunea HTTP, cod stare, descriere stareAntet (header) Informaii despre pagina returnat ca rspunsConinut (body) Pagina solicitat n cerere

Fig.1.9 Formatul cererii HTTP

Fig.1.10 Formatul rspunsului HTTP

POST /servlet/personal.class HTTP/1.0User-Agent: Mozilla/4.04

Accept: image/gif, image/X-bitmap, image/jpeg, Host: www.pub.roContent-type: application/x-www-form-urlencodedContent-length: 100Connection: keep-aliveAccept-Charset: ISO-8859-1, Referer: http://www.pub.ro/studenti.htmlnume = &prenume=&zi=&luna=&an=

p d f Machine



http://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pub.ro/studenti.htmlhttp://www.pub.ro/


13/144

13

Principalele informaii din antet se refer la tipul serverului Web, la tipurile dedate acceptate, la tipul documentului returnat (MIME-type3 - ex. text/html,

imagine/gif, audio/basic, multipart/digest, video/mpeg) i ladimensiunea documentului transmis.

Exemplificm n continuare formatul rspunsului HTTP.

HTTP 1.0 200 document followsServer: Apache_Go_Webserver/4.6Date: Thu, 20 Febr 2003 15:30:00 GMTAccept-Range: bytesContent-type: text/htmlContent-length: ...Last-Modified: Wed, 19 Febr Coninutul paginii solicitate

S-HTTP (secure HTTP) reprezint o extensie a protocolului cu faciliti deencriptare a informaiilor i cu semnturi digitale, n vederea asigurrii securitiiacestora.

1.2.4 Identificare resurse: URI i URL

World Wide Web (WWW) este un spaiu informaional compus din resurseidentificaten mod unic cu URI (Uniform Resurce Identifier).

n acest spaiu activeaz agenii Web care pot fi persoane sau componentesoftware. Acesul persoanelor este intermediat de agenii utilizator. Agenii softwareinclud ageni utilizator, ca navigatoare i player-e multimedia, i alte categorii deageni de tip server, proxyi spider.

Bazele arhitecturale ale Web sunt identificarea resurselor, interaciuneaacestora i formatele de reprezentare a datelori metadatelor.Identificarea resurselor se facen mod uniform, utiliznd URI.Agenii Web comunic prin mesaje, utiliznd protocoale standardizate ce

definesc sintaxa i semnatica mesajelor. Cazul comun de interaciune este emitereaunei cereri de resurs, formatat conform definiiilor protocolului HTTP, la careserverul solicitat rspunde cu o reprezentare a resursei.

Majoritatea protocoalelor utilizate pentru extragerea i/sau memorarea dereprezentri de resurse utilizeaz o secven de unul sau mai multe mesaje, careluate mpreun formeaz reprezentrile datelor i metadatelor, pentru a transferareprezentrile ntre ageni.

Alegerea protocolului limiteaz formatele reprezentrilor datelori metadatelorce pot fi transmise. Astfel, HTTP transmiten mod tipic un singur flux de octei plusmetadate i utilizeaz n antet cmpurile Content-Typei Content-Encodingpentru a specifica formatul reprezentrii. Agenii utilizator de tip navigator suntprogramai ca s interpreteze valorile din aceste cmpuri ca instruciuni de alegere aunui mod de redare a coninutului.

Dac, de exemplu, valoarea specificat pentru Content-Type esteapplication/xhtml+xml, atunci datele din reprezentare pot fi procesateconform specificaiei XHTML. Aceasta include i orice interaciune subsidiar

3Multipurpose Internet Mail Extensions reprezint o specificaie tehnic utilizat pentru a

descrie transferul de date multimedia cu ajutorul standardelor de pot Internet.

ANTETMeta-informaii (informaiidespre pagin)

p d f Machine





14/144

14

http://www.unSite.ro/cursuri

URI

Lista cursurilor oferite

RESURS

Metadate:

Content-type: application/xhtml+xml

Date:


15/144

15

Un element fundamental al arhitecturii Web este URI (Unified ResourceIdentifier) ca identificator unic globaln sistem.

Pe lng avantajele oferite de caracteristica global a URI, utilizarea acestuiaprezint beneficii legate de stabilire de legturi, liste de preferine, caching i

indexare de ctre motoarele de cutare.Cu fiecare resurs care are ataat un identificator de tip URI se pot realiza

diverse operaii. Asfel, ea poate fi indicat ca destinaie a unei hiperlegturi, poate fianalizat, extras ca atare sau se poate prelua n cacheuna din reprezentrile ei,poate fi inclus parial sau total ntr-o alt reprezentare, poate fi adnotat.

Relaii URI-resurs

URI identific o resurs. Termenul de resurs are un sens larg i reprezintorice entitate identificabil de ctre un URI.

n Web resursele sunt diverse, dar au ca i caracteristic unificatoare faptul cproduc informaii, numite reprezentri ale resursei, ce pot fi transferate prin

intermediul mesajelor. De aceea ele sunt identificate cu termenul mai particular deresurse de informaii.Specificaiile pentru URI reprezint un acord referitor la modul n care

comunitatea Internet face alocarea de nume asociate resurselor pe care le identific.URI este divizat n scheme care definesc, n specificaiile fiecrei scheme,mecanismul prin care se asociaz resurselor identificatori specifici unei schemei. Deexemplu, schema http utilizeaz servere HTTP bazate pe TCP i DNS pentrualegerea i alocarea de identificatori. Ca rezultat, un identificator bazat pe schemahttp se refer la realizarea unei cereri HTTP de tip GET cu acest identificator, iardac se primete un rspuns corect, acesta este interpretat ca o reprezentare aresursei identificate.

Arhitectura Web permite asocierea mai multor URI-uri, de tip alias, cu osingur resurs.

Alocarea unui URI pentru o resurs se poate realiza de ctre proprietariiacesteia sau de alte autoriti. Este esenial ca n acest proces de alocare s se evitefenomenul de coliziune produs de utilizarea aceluiai URI pentru identificarea maimultor resurse.

Proprietatea asupra unui URI este o relaie ntre URI i o entitate social, carepermite asocierea unei resurse cu URI-ul deinut. Dreptul de proprietate estegestionat de o ierarhie organizaional cu rdcina n specificaiile schemei URInregistrate la IANA (Internet Assigned Numbers Authority). IANA gestioneaz unregistru de corespondene ntre numele schemelor URI i specificaiile acestora.

Scheme URI

Fiecare schem URI are o specificaie care explic detaliile referitoare laalocarea i asocierea cu o resurs. Sintaxa URI este un sistem de numire federativ iextensibil, n care fiecare specificaie de schem poate impune restricii propriiasupra sintaxei i semanticii identificatorilor din schema respectiv. Multe dinaspectele procesrii unui URI sunt dependente de schema cruia i se conformeazacesta. Introducerea unei noi scheme induce costuri legate de dezvoltarea idistribuirea de componente software de tip client, gateway, proxy, etc.corespunztoare acesteia. De aceea se recomand utilizarea schemelor existente ntoate cazurilen care acestea rspund cerinelor aplicaiei.

p d f Machine





16/144

16

Opacitatea URI

Web-ul este proiectat astfel nct agenii comunic informaiile despre starearesurselor prin intermediul reprezentrilori nu prin identificatori. Dei unele numear putea fi sugestive, n general4 nu se poate determina tipul reprezentrii uneiresurse pe baza URI-ului acesteia. De exemplu, un identificator ca

http://www.unSite.ro/exemplu.html nu garanteaz faptul c reprezentarearesursei pe care o identific va fi de tip text/html, deoarece protocolul HTTP nuimpune acest lucru. Avantajul acestei flexibiliti este transparena modificriloraprute n starea unei resurse, deci i n reprezentrile acesteia.

Identificatori de fragment

Una din componentele unui URI este identificatorul de fragment. Acestapermite identificarea indirect a unei resurse secundare prin referire la o resursprimar, extins cu informaii adiionale de identificare. Resursa secundar poate fi oporiune sau un subset al celei primare, o anumit perspectiv a reprezentrilorresursei primare sau o alt resurs definit sau descris prin aceste reprezentri.

n acest context, termenii de primar i secundar indic o relaie ntre douresurse i nu limiteaz natura unei resurse la un fragment, n sens propriu, al alteia.Identificatorii de fragment pot fi utilizai cu nume de spaii de nume pentru a identificacomponente abstracte.

Preocuprile de viitor n domeniul identificrii resurselor n Web se refer lainternionalizarea identificatorilor prin extinderea setului de caractere acceptate i lautilizarea tehnologiilor oferite de Web Semantic, inclusiv de limbajul OWL (OntologyWeb Language), pentru a deduce c dou URI-uri identific aceeai resurs.

URI i URL

URI are o sintax standard pentru irurile prin care se identific o resurs n

Web. Informal, URI este un termen generic pentru adresele i numele resurselor dinWeb. Resursa Web,n sens general, este orice entitate fizic sau abstract ce poatefi accesat n Web i care are o identitate proprie.

URI-urile sunt de dou tipuri.URL (Uniform Resource Locator) care identific o resurs dup modul n care

este accesat. De exemplu, "http://www.example.com/stuff/index.html"identific o pagin HTML pe un server al crui nume estehttp://www.example.com, pagin accesat prin intermediul protocolului HTTP

URN (Uniform Resource Name) creaz un nume unic i persistent pentru oresurs, fie n spaiul de nume urn fie ntr-un alt spaiu de nume nregistrat. Spaiulde nume este cel care dicteaz sintaxa identificatorului de tip URN.

Un identificator unic de resurs are urmtorul format general.

protocol: // resurs # subresurs

Identificarea unei resurse de pe un server Web se face cu URL (UnifiedResource Locator). Un URL se poate specifica fie n manier absolut, caz n care

4Sunt totui definite cteva cazuri particulare n care se poate deduce cu certitudine tipul

reprezentrii.

p d f Machine



http://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.example.com%2C/http://www.unsite.ro/exemplu.html


17/144

17

conine identificatorul serverului i al localizrii absolute a resursei pe site-ulrespectiv5, fie relativ la directorul curent al documentului care face referirea.

n general, exist o serie de porturi standard pe care ascult procese cecomunic prin diferite protocoale. Procesul server Web comunica prin protocolulHTTP i ascult implicit pe portul 80 al masinii gazd pe care se execut. Aceast

alocare poate fi modificat prin stabilirea altui port de ascultare la reconfigurareaserverului Web.Dac procesul solicitat ascult pe un alt port dect cel implicit (80), atunci se

specific numrul portului n URL.Sintaxa general a unui URL este urmtoarea:

http: // identificator_proces[:port] / cale / nume_fisier

Colectia de fisiere *.html ca i de alte tipuri (n cazul serverelor Web cufuncionalitate extins), formeaz site-ul Web, accesibil clienilor din Internet.

Fiierele site-ului Web sunt localizate ntr-un director specific pe maina pe

care se execut serverul Web. Acesta reprezint rdcina site-ului Web.De exemplu, n cazul unui server Apache rdcina (root) este

%APACHE_HOME%/htdocs, unde variabila sistem %APACHE_HOME% conine caleape care se afl instalat serverul Apache (ex. C:/ProgramFiles/ApacheGroup/Apachepe o main Windows). Un alt exemplu este rdcina unui site Webaccesibil prin IIS (Internet Information Server de la Microsoft), aceasta fiind, ngeneral, C:\InetPub\wwwroot\.

1.2.5 Interaciune

Comunicarea inter-agent referitoare la resurse implic URI-uri, mesaje i date.Protocoalele Web (HTTP, FTP, SOAP, NNTP i SMTP) se bazeaz pe schimbul de

mesaje. Un mesaj poate include date i metadate despre resurse, date despremesaj, metadate despre metadatele mesajului (ex. verificri de integritate amesajului) i,n fine, mesajul propriu-zis.

Faptul c Web-ul este un sistem larg distribuit afecteaz restriciilearhitecturale i presupunerile legate de interaciuni.

Metoda prin care agenii utilizeaz un URI pentru a referi o resurs estenumit dereferirea URI6-lui. Accesul la resurs poate mbrca forme diferite. Elinclude extragerea unei reprezentri a acesteia (ex. utiliznd metodele GET sauHEAD din HTTP), adugarea sau modificarea reprezentrii unei resurse (ex. HTTPPOST sau PUT) care poate conduce la modificarea strii acesteia, sau tergereauneia sau tuturor reprezentrilor unei resurse (ex. HTTP DELETE), caz n care sepoate produce chiar eliminarea definitiv a resursei.

Contextul aplicaiei este cel care determin modul n care se acceseaz oresurs identificat cu un URI dat. De exemplu, un navigator ar putea utiliza HTTPGET pentru a obine o reprezentare a resursei, pe cnd un agent de verificare alegturilor hipertext ar putea utiliza HTTP HEAD pe acelai URI doar pentru a stabilidac resursa este disponibil.

O schem URI nu implic n mod necesar utilizarea unui anume protocolpentru a accesa resursa identificat. Aceasta poate fi accesat printr-o colecie de

5Rdcina unui site este, n general, diferit de rdcina sistemului de fiiere al sistemului de

operare pe care se afl site-ul.6 Dereferencing the URI.

Localizare pe site

p d f Machine





18/144

18

servicii de tip gateway, proxy, sau servicii de nume care sunt independente deprotocolul asociat schemei de nume. Totui majoritatea schemelor URI definesc unprotocol de interaciune implicit pentru accesul la resursa identificat. Acesta este deobicei baza alocrii identificatorilor schemei. Astfel, URI-urile care au la bazhttpsunt definiten termeni de servere HTTP bazate pe TCP.

Stabilirea exact a reprezentrii ce va fi furnizat de o resurs depinde de oserie de factori. Acetia se refer la faptul c proprietarul resursei oferreprezentarea respectiv, c agentul solicitant are privilegiile de acces necesare, cn urma negocierii dintre agentul utilizatori server s-a stabilit transferul reprezentriirespective dintr-un set disponibil de reprezentri ale resursei. Odat transferat,expresivitatea formatului reprezentrii va afecta precizia cu care furnizorul comunicstarea resursei. O stare a resursei care nu este comunicat cu acuratee de ctrereprezentare poate conduce la confuzii semantice. O soluie este dat de SemanticWeb, care propune un cadru de comunicare exact a semanticilor unei resurse ntr-un format de reprezentare a acesteia ce poate fi interpretat de main.

Tipuri de reprezentri i tipuri de media n Internet

O reprezentareeste o colecie de date care codific informaii despre stareaunei resurse7.

Reprezentrile unei resurse sunt transmise i recepionate utiliznd protocoalede interaciune. Aceste protocoale sunt cele care determin forma n carereprezentrile sunt difuzate n Web. De exemplu, protocolul HTTP transmitereprezentrile de resurse sub form de fluxuri de octei tipate8 conform tipurilor demedia in Internet. Ca i n cazul schemelor URI, reutilizarea de tipuri de fluxuri deoctei n protocoale diferite permite utilizarea acelorai produse software pentruredarea reprezentrilor9.

Tipuri de reprezentri i semanticile identificatorului de fragmentTipul de media Internet10definete sintaxa i semanticile identificatorului de

fragment (dac exist) care poate fi utilizat n conjuncie cu o anumit reprezentare.Aceste semantici sunt definite de setul de reprezentri care pot rezulta n urma uneiaciuni de extragere din resursa primar. Formatul i rezoluia fragmentului suntastfel dependente de tipul unei reprezentri ce poate fi extras, chiar dac aceastextragere are loc dac URI-ul este dereferit. Dac nu exist o astfel de reprezentare,atunci semanticile fragmentului sunt considerate necunoscute i nerestricionate.Semanticile identificatorului de fragment sunt ortogonale cu schemele URI i deaceea nu pot fi redefinite de specificaii pentru scheme URI.

Interpretarea identificatorului de fragment este fcut n mod exclusiv de ctreagentul care face dereferirea URI-ului. Identificatorul nu este transferat altor sistemen cursul procesului de extragere, astfel c elemente intermediare din arhitecturaWeb (ex. proxy) nu interacioneaz cu identificatorii de fragment n vederearedirectrii lor.

Identificatori de fragment i negocierea coninutuluiNegocierea coninutului are loc atunci cnd pentru acelai URI sunt

disponibile reprezentri multiple. Negocierea ntre agentul solicitant i serverdetermin reprezentarea considerat cea mai potrivit din punct de vedere a

7Ea nu descrien mod necesar resursa, nu este o copie sau o reprezentaren alte sensuri a

acesteia.8

Care sunt caracterizate de un tip.9

Exemplu pentru principiul specificaiilor ortogonale prezentat n seciunea 1.4.1.10 Internet Media Type.

p d f Machine





19/144

19

posibilitilor de redare de la agent, aceasta fiind cea care va fi servit ca rspuns lacerere. HTTP este unul din protocoalele care permit negocierea coninutului.

Unele formate individuale de date pot defini reguli proprii pentru utilizareasintaxei identificatorului de fragment n vederea specificrii diferitelor tipuri desubseturi, vederi, sau referine externe care sunt identificabile ca resurse secundare

de ctre acel tip de media. De aceea furnizorii de reprezentri trebuie s gestionezecu grij negocierea de coninut atunci cnd aceasta este utilizat pentru un URI ceconine un identificator de fragment. Pe de alt parte, autorii de coninut Web potfolosi noile formate de date cu condiia s asigure compatibilitate rezonabil pentruagenii care nu le-au implementatnc.

Inconsistene ntre reprezentrile de date i metadateReuita comunicrii ntre doi corespondeni depinde de partajarea rezonabil

ntre acetia a semanticilor mesajelor, coninnd att date ct i metadate, pe care leschimb ntre ei. n practic au fost observate o serie de inconsistene posibile ntredatele i metadatele transportate de un mesaj. n aceste cazuri agenii suntresponsabili cu detectarea inconsistenelor i cu executarea de operaii

corespunztoare pentru recuperare. Pe de alt parte i furnizorii de reprezentri suntresponsabili de asignarea corect a metadatelor. Astfel, acurateea metadatelor sebazeaz pe administratorii de servere, pe autorii de reprezentri i pe componentelesoftware utilizate pentru extragerea i prelucrarea acestora.

Interaciuni sigureO interaciune sigur este cean care agentul nu-i asum nici o alt obligaie

n afara interaciunii propriu-zise. Un agent i poate asuma o obligaie prin altemijloace, ca de exemplu semnarea unui contract. Altfel spus, dac un agent nu are oanumit obligaie nainte de o interaciune sigur, atunci el nu are acea obligaie nicidup realizarea interaciunii respective. O interaciune sigur se poate obine, deexemplu, prin utilizarea metodei HTTP GET.

Interaciunile nesigure11 seamn mai mult cu ordinele dect cu interogrile ipot cauza schimbarea strii unei resurse, schimbare pentru care utilizatorul esteresponsabil.

1.2.6 Gestiunea reprezentrilor

Proprietarul unui URI poate oferi zero sau mai multe reprezentri ale resurseiidentificate de acesta. Totui exist cazuri n care referirea unui URI nu trebuie snsemne i extragerea unei reprezentri asociat acestuia. Dereferirea unui URIinduce costuri potenial semnificative legate de operaii de calcul i de lrgime deband necesar transferului n reea, poate avea implicaii legate de securitate ipoate impune o laten semnificativ aplicaiei. De aceea acest operaie trebuieevitat de cte ori este posibil.

ncrederea n interaciunile din Web depinde de stabilitate i predictibilitate.Persistena unei resurse de informaii depinde de consistena reprezentrilor.Termenul de persisten URI descrie proprietatea prin care un URI asociat uneiresurse o va identifica pe termen nelimitat. De aceea i reprezentrile acelei resursetrebuie s fie consistente i predictibile. Un exemplu de suport pentru consistenareprezentrilor este redirectarea HTTP, care permite serverelor s informeze agentuldespre eventuale aciuni suplimentare ce trebuie realizate de agent n vederearezolvrii cererii. Negocierea coninutului promoveaz de asemenea consistena,

11 Nunseamn c sunt periculoase i pot fi acceptate ca atare.

p d f Machine





20/144

20

deoarece un manager de site nu trebuie s defineasc un nou URI odat cuadugarea de suport pentru o nou specificaie de format.

1.2.7 Structura informaiilor pe site-uri Web

Coninutul site-urilor Web este organizat ntr-o o structur ierarhic. Aceast

structur se reflect n coninutul paginilor Web sub form de hipertext i hipermedia.Hipertextul este o manier de organizare a documentelor text dup un model

ierarhic. Ierarhia conine documente i legturi ntre acestea. Legturile specificate ninteriorul documentelor i se numesc hiperlegturi (hyperlink). Specificarea uneihiperlegturi se face utiliznd URL-ul corespunztor resursei legate.

Hipermedia este o manier de organizare a documentelor media (grafic,audio, video, etc.) dup un model ierarhic i reprezint o extindere a hipertextului cuelemente de multimedia.

Pentru a accesa informaii organizate conform modelului ierarhic, URL are osintax specific ce evideniaz resurse i subresurse.

n varianta clasic, resursele sunt fiiere tip text sau media. n cazularhitecturilor ce extind funcionalitatea arhitecturii Web clasice resursele pot fi ifiiere ce conin cod executabil.

Exist posibilitatea rafinrii identificrii informaiilor prin specificareaparagrafelor dintr-un document text.

Sintaxa general a unui URL devine n acest caz:

protocol://serviciu (proces).maina/cale/fiier#paragraf

Urmtorul exemplu identific primul capitol dintr-un document numitcurs1.html aflat pe calea /cursuri/cursSO a mainii unSite din

domeniulro

pe care activeaz serviciul www

.

http://www.unSite.ro/cursuri/cursSO/curs1.html#cap1

1.3 Formate de date

O specificaie pentru un format de date (ex. XHTML, RDF/XML, SMIL, XLink,CSS i PNG) conine un acord asupra interpretrii corecte a reprezentrii datelor.Primul format de date utilizat n Web a fost HTML. n prezent arhitectura Web nuimpune nici o restricie asupra formatului datelor utilizate de furnizorii de coninut.Aceast flexibiltate suport evoluia constant a aplicaiilor, n sensul introducerii de

noi formate de date sau al rafin

rii celor existente. Corespondenii care schimb

informaii ntr-un anume format de date trebuie s fie n consens referitor la sintaxa isemantica acestora. Acest lucru nu impune ns restricii asupra utilizrii acestordate.

n continuare sunt descrise cteva caracteristici ale unui format de date, carei faciliteaz integrarea n arhitectura Web.

1.3.1 Formate binare i textuale pentru date

Formatele binare sunt cele obinute prin codificarea datelor realizat nvederea utilizrii directe de ctre procesoare.

Un format textual este cel n care datele sunt specificate ntr-o codificare

definit

ca secven

de caractere. Un format textual nu implic

utilizarea unui tip de

p d f Machine



http://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.pdfmachine.com/?clhttp://www.unsite.ro/cursuri/cursSO/curs1.html#cap1


21/144

21

media care ncepe cu text/ ci poate fi i un format bazat XML. n principu, toatedatele pot fi reprezentaten format textual. n practic anumite tipuri de coninut (ex.audio sau video) sunt reprezentate,n general, utiliznd formate binare.

Formatele binare suntn mod substanial mai compacte, pe cnd cele textualeau avantajul portabilitii i interoperabilitii precum i cel al apropierii de percepia

uman. Alegerea unui tip pentru un format de date este fcut de proiectaniispecificaiei pentru formatul datelor i se bazeaz pe studii cantitative alecompromisuluintre cele dou tipuri.

1.3.2. Hipertext

O caracteristic definitorie a Web-ului este aceea c permite includerea dereferine la alte resurse prin identificarea acestora cu URI. Legturile hipertextutilizez identificator URI absolut() saurelativ().

O hiperlegtur de tip XLink)12 poate conine i metadate.Este de remarcat faptul c o hiperlegtur reprezint o relaie i nu o

conexiune fizic.Pentru flexibilitatea unei aplicaii se recomand utilizarea URI-urilor pentru

exprimarea de legturi chiari ntre elemente interne documentelori, de asemenea,folosirea de URI-uri generice, neconstrnse de o a numit schem.

Formatele de date utilizate n interfee bazate pe paradigma hipertext trebuies permit autorilor crearea de hiperlegturi. Cele care nu ofer acest posibilitateconduc la crearea de noduri terminalen Web.

Referine URILegturile sunt exprimate prin referine URI care pot fi combinate cu un URI

de baz pentru a se obine o referin utilizabil. Agenii rezolv referina URI iarrezultatul este folosit pentru a interciona cu un alt agent. Acest model al interciuniipermite proiectarea local a reprezentrilor, fr ca autorul s fie preocupat deidentificatorul global ce va fi folosit pentru a referi ulterior resursa asociat.

1.3.3. Formate de date bazate pe XML

Formatele de date bazate pe XML se conformeaz regulilor sintactice definiten specificaia XML.

XML definete formate textuale care se potrivesc n mod natural cu descriereaobiectelor procesate ierarhicntr-o secven aleas. Modelul este larg aplicat dar nuse potrivete oricrui tip de formate de date (ex. formate audio sau video). Restriciilede proiectare specifice formatelor bazate pe XML sunt reprezentate de urmtorul setde cerine pentru datele ce vor fi reprezentate n aceste formate:

- structur iererhic,- instrumente pe o larg varietate de platforme,- supravieuirea n raport cu aplicaiile care le proceseaz n mod curent,- abilitatea de a suporta internaionalizarea ntr-o manier autodescriptiv

astfelnct s nu poat apare confuzie la opiunile de codificare,- detectarea timpurie a erorilor de codificare fr necesitatea de a le rezolva,- proporie nsemnat de coninut textual destinat a fi citit de utilizatorul

uman,

12 Mecanism generic de legare folosit de limbaje bazate XML (v. cap. 4)..

p d f Machine





22/144

22

- potenial de compunere a formatului de date cu alte formate codificateXML,

- uor de analizat lexical att de ctre main ct i de ctre utilizatoruluman,

- vocabulare care s poat fi inventate n maier distribuiti cu flexibilitate

combinat.Mecanismul XPointer are rolul de a permite realizarea de legturi pentruadresarea de coninut care nu are o ancor explicit i identificat cu nume.Mecanismul XLink este o specificaie pentru reprezentarea legturilor n aplicaiiXML hipertext. Acesta permite ca o legtur s aib destinaii multiple i s poat fiexprimat fie in-line fie bazat pe informaii externe uneia sau tuturor resurseloridentificate de legturile pe care le conine.

Un spaiu de nume XML permite utilizarea de vocabulare (n care suntdefinite nume de elemente i de atribute) ntr-un mediu global, astfelnct s reducriscul coliziunilor de nume din interiorul documentelor ce folosesc combinaii devocabulare. Ca orice resurs Web, fiecare spaiu de nume este identificat printr-un

URI. Dac dou specificaii diferite (ex. MathML i SVG) utilizeaz acelai nume ndefinirea unui element (ex. set), fiecare utilizare a numelui respectiv trebuie nsoitde precizarea specificaiei la care se face referirea, prin URI-ului spaiului de numecorespunztor acesteia.

URI-ul unui spaiu de nume poate fi folosit pentru a identifica o resurs deinformaii care conine informaii utile, fie pentru maina de calcul fie pentruutilizatorul uman, despre termenii din spaiul de nume. Aceast resurs de informaiieste documentul spaiului de nume13, care este valabil i autoritar pentru acesta.Un astfel de document ofer informaii despre scopul spaiului de nume, modul deutilizare a vocabularului de marcare din spaiul de nume, cine controleaz spaiul denume, ce politicii sunt asociate, cum se solicit accesul la schem sau la materialecolaterale, posibilitile de raportare a unor probleme legate de utilizarea spaiului denume. De asemenea, tot n acest document de afl informaii ce pot fi utilizate deprocesoare pentru a extrage o schem de validare, o foaie de stil pentru prezentaresau o ontologie pentru a face raionamente.

Formatele datelor utilizate n crearea de reprezentri ale resurselor de tipdocument al spaiului de nume ca i faptul c informaiile apar direct n reprezentaresau sunt referite din aceasta, sunt influenate de aplicaiile ce le utilizeaz. Exemplede formate de date pentru documente ale spaiilor de nume sunt OWL, RDDL,XMLSchema, XHTML. Fiecare ndeplinete cerinele descrise mai sus pentru asatisface cerina unui agent pentru informaii suplimentare despre spaiul de nume.

QNames este o construcie sintactic pentru exprimarea compact a numelor

calificaten documente XML. Un nume calificat este o pereche format dintr-un URIcare indic un spaiu de nume i un nume local plasat n acel spaiu de nume.QNames suntn general folosite n contextul numelor de atribute i elemente. Existpropuneri pentru utilizarea lorn valorile atributelor sau n coninutul elementelor darn aceste cazuri nu pot fi folosite mpreun cu URI-uri deoarece nu se pot distinge deacestea.

Deoarece QNames sunt compacte, unele specificaii au adoptat sintaxeidentice cu cele pentru identificarea resurselor. Totui QNames nu pot nlocui URI casistem de identificaren Web. Utilizarea de QNames pentru a identifica resurse Web

13 Namespace document.

p d f Machine





23/144

23

trebuie s fie nsoit de o mapare a acestora n URI-uri, pentru a fi consistent cuarhitectura Web.

Un identificator de element este definitn declaraiile DTD sau XMLSchemacare au valoarea ID pentru atributul name.

RFC 3023 definete tipurile media pentru Internet application/xmli

text/xml14

i descrie o convenie prin care formatele de date bazate XMLutilizeaz tipuri media Internet cu sufixul +xml (ex. image/svg+xml).

Semanticile identificatorilor de fragment specifice fiecrui format suntdefinite de proiectanii formatelor de date bazate pe XML. XPointer Framework oferun punct de plecare interoperabil pentru acetia.

Nu se vor folosi identificatori de fragment dac tipul media asignatreprezentrii este application/xml sau dac are sufixul +xml, deoarecenaceste cazuri nu sunt definite semantici pentru identificatorii de fragment. Existpropuneri de normative pentru ca identificatoare de fragment de forma #abc sidentifice elementul cu ID-ul abc al documentului XML referit.

1.3.4. Versiuni i extensibilitateExtensibilitatea i versiunile multiple sunt strategii de gestionare a evoluiei

naturale a informaiilor din Web i a tehnologiilor de reprezentare a acestora. Deaceea fiecare specificaie pentru un format de date trebuie s fie nsoiti de unnumr de versiune. De asemenea, este ncurajat dezvoltarea de limbaje ce spermit o anumit form de extensibilitate care s nu necesite modificarea numeluispaiului de nume utilizat. Aceast extensibilitate este limitat de un set de restriciiasupra modificrilor posibile n spaiul de nume, limitare necesar realizrii deimplementri stabile.

Posibilitile de extindere trebuie s rmn n cadrul conformanei cu

specificaia original

. De asemenea, o specificaie trebuie s

indice comportamentulagentuluin faa unor extensii pe care nu le recunoate. Acesta poate fi de ignorare aoricrui coninut nerecunoscut sau de tratare a acestuia ca pe o eroare.

1.3.5. Compoziie i formate de date

Majoritatea formatelor de date includ mecanisme pentru compoziie. Deexemplu, este posibil nglobarea de comentarii text n unele formate de imagini.Exist formate container, cum ar fi SOAP, care pot include coninut din spaii denume multiple, dar care ofer o relaie semantic de ansamblu a elementenlorunuimesaj. De asemenea, sunt bine definite semanticile combinrii documentelor RDFcare conin vocabulare multiple. n principiu, aceste relaii pot fi mixate i incluse n

mod arbitrar. De exemplu, un mesaj SOAP poate conine o imagine SVG careconine un comentariu RDF ce se refer la un vocabular de termeni pentrudescrierea imaginii.

Totui, pentru XML n general nu exist un model semantic care defineteinteraciunile din interiorul documentelor XML cu elemente i/sau atribute dintr-ovarietate de spaii de nume. Fiecare aplicaie trebuie s defineasc modul n carespaiile de nume interacioneaz i ce efect are spaiul de nume al unui elementasupra ancestorilor, vecinilor i descendenilor elementului.

14n general, furnizorii de reprezentri vor evita asignarea de tipuri media care ncep cu

"text/" (pentru care este permis transcodarea de la o codificare la alta) la reprezentri XML care

trebuie s fie autodescriptive.

p d f Machine





24/144

24

1.3.6 Separareantre coninut, prezentare i interaciune

Web-ul este un context eterogen n care agenii ofer utilizatorilor acces laconinut.

Autorii sunt interesai n a crea coninut pentru o audien ct mai larg nsensul diversitii dispozitivelor de preluare i prezentare a informaiilor: calculatoarede birou cu interfee grafice, dispozitive manuale, telefoane mobile, dispozitive pentrupersoane cu disabiliti sau dispozitive ce urmeaz a fi proiectate n viitor. Deasemenea, nu pot fi cunoscute n momentul crerii coninutului toate tipurile deprelucrri pe care le vor face agenii n vederea prezentrii acestuia.

Soluia pentru flexibilitate este dat de separarea coninutului de prezentarealui i de interaciuni, ca principii ortogonale. Aceasta are ca rezultat reutilizarea iindependena de dispozitive a coninutului.

Recombinarea acestor principii este realizat de ageni care utilizeaz unspectru ce variaz de la recombinare integral la client la recombinare exclusiv laserver. Recombinarea la server are avantajul informaiilor puine, dedicate,transferaten re

ea, dar nu permite agen

ilor client s execute opera

ii care nu au fost

anticipate de autor. Pe de alt parte, recombinarea la client ofer o reutilizare mairobusti care se poate adresa unei audiene mai largi, avantaj pltit cu transferuriimportante de informaii de la server.

Decizia de proiectare se face funcie de puterea de calcul de la client, dencrcarea i de puterea de calcul de la server i de lrgimea de band oferit demediul prin care acestea se conecteaz. Scalabilitatea unei aplicaii (referitor lanumrul de clieni acceptai) este mai bun dac este mrit ncrcarea de calcul laclient. Pe de alt parte, se poate dori limitarea accesului clienilor, lucru realizat printehnologii de encriptare i prin metode de control a accesului.

Unele formate de date, cum ar fi SVG, XSL Formating Objects, sunt destinate

descrierii prezentrii, caz n care prezentarea este inclus n coninut. Pentru arespecta principiul specificaiilor ortogonale este necesar ca aceste formate de dates se refere doar la elemente de prezentare.

Formatele de date permit crearea de noi aplicaii care s utilizezeinfrastructura spaiului informaional. Una din aplicaiile semnificative este Web-ulSemantic, construit peste RDF15.

1.4 Principiile generale ale arhitecturii Web

Urmtoarele principii se aplic pentru toate cele trei baze ale arhitecturii Web.

1.4.1. Specificaii ortogonale

Identificarea, interaciunea i reprezentarea sunt concepte ortogonale.Tehnologiile specifice acestora evolueaz n mod independent. Astfel, resursele suntidentificate cu URI-uri care pot fi publicate fr a fi obligatorie existenareprezentrilor resursei. O sintax generic pentru URI permite agenilor sfuncioneze fr a cunoate specificul schemelor URI. De asemenea,n multe cazuri,se poate schimba o reprezentare fr s fie afectate referinele la acesta (de ex. prinutilizarea mecanismului de negociere a coninutului).

15 Resource Description Framework (v. cap. 9).

p d f Machine





25/144

25

Principul ortogonalitii spune c abstractizri ortogonale beneficiaz despecificaii ortogonale.

Dac dou specificaii sunt ortogonale, fiecare se poate schimba fr anecesita modificri la nivelul celeilalte, chiar dac exist dependene ntre ele. Deexemplu, dei specificaia HTTP depinde de specificaia URI, ele pot evolua n mod

independent. Aceast ortogonalitate are ca efect creterea flexibilitii i robusteei nWeb. De exemplu, se poate referi o imagine cu un URI fr a se cunoate formatulales pentru reprezentarea acesteia. Acest lucru a facilitat introducerea de noi formatede imagine (PNG i SVG), fr a afecta referinele la resursele respective.

Din experien s-a observat c pot s apar probleme atunci cnd concepteleortogonale apar n aceeai specificaie sau cnd specificaiile ncearc s modificeabstractizri ortogonale descrise n alt parte. O prim etap n soluionarea acestorprobleme este condiia ca o specificaie s indice n mod clar caracteristicile care sesuprapun cu cele guvernate de o alt specificaie.

1.4.2. Extensibilitatea

Informaiile din Web i tehnologiile utilizate pentru reprezentarea lor sufermodificri continue. Extensibilitatea este acea proprietate a unei tehnologii carepromoveaz evoluia acesteia, fr a sacrifica interoperabilitatea ei. Exemple deproiectare care ofer acest proprietate sunt:

- specificarea ortogonal a schemelor URI,- utilizarea unui set deschis de tipuri media Internet n mail i HTTP, pentru

a specifica interpretarea documentului,- separarea gramaticii generice XML i setul deschis de spaii de nume XML

pentru numele de elemente i de atribute,- extensibilitatea modelelorn CSS, XSLT1.0 i SOAP,- utilizarea de plug-inla agenii utilizator.

n continuare ne referim la proprietatea de extensibilitate expus de URI, deunele formate de date i de unele protocoale (prin incorporarea de mesaje noi).

Un limbaj este un limbaj subset, subset (sau profil) al altui limbaj numitlimbaj extins (sau superset)n acest relaie, dac orice document scris n limbajulsubset este un document valid i are aceeai interpretare i n limbajul extins.Diferena dintre cele dou limbaje se numete extensie.

Pentru a pstra interoperabilitatea, se prefer extinderea unui limbaj i nucrearea unuia nou. n mod ideal, multe instane ale limbajului superset pot fiprocesate ca i cum ar aparine limbajului subset. Limbajele care evolueaz astfel,

permind aplicaiilor s

ofere informaii noi atunci cnd este necesar i n acelaitimp s interopereze cu aplicaii care neleg doar un subset al limbajului, se numesclimbaje extensibile. Extensibilitatea poate fi facilitat de ctre proiectanii de limbajeprin definirea unui comportament implicit pentru extensiile pe care nu le recunosc(ex. le ignor sau le trateaz ca erori).

1.4.3. Gestionarea erorilor

Erorile pot fi bine caracterizate (ex. erori de formare corect n XML) sau pots apar n mod impredictibil. Corectarea erorilor se definete ca fiind aciuneaagentului de a soluiona problema astfel nct apariia acesteia s fie transparent lanivelul sistemului. Un exemplu de corectare eroare este retransmiterea datelor n

cazul unei cderi temporare n reea. Recuperarea din eroare se refer la

p d f Machine





26/144

26

comportamentul unui agent care nu soluioneaz problema ci continu procesarea cuindicarea faptului c s-a produs o eroare.

n mod frecvent agenii corecteaz erori de transmisie n reea. Pe de altparte, este la fel de important ca agenii s realizeze recuperarea din eroare ntr-unmod care s fie evident utilizatorului, deoarece ei acioneaz n numele acestuia.

Pentru a nuntrerupe utilizatorul la apariia necesitii de confirmare sau selecie dinpartea acestuia a unei anumite soluii propus de agent, utilizatorul poate indica nprealabil deciziile sale pentru diferite cazuri prin setri de configurare a agentului.Agentul va aciona conform acestor opiuni i va raporta utilizatorului apariia erorilor.

Pentru a susine interoperabilitatea, proiectanii de specificaii trebuie sidentifice condiiile de eroare predictibile.

1.4.4. Interoperabilitate bazat pe protocol

Interfeele eseniale din Web sunt definite n termeni de protocoale prinspecificarea sintaxei, semanticilor i restriciilor de secveiere a mesajelorinterschimbate. Protocoalele utilizate sunt flexibile, asfel nct au permis extinderea

Web-ului n medii foarte variate i au facilitat comunicarea peste granie multiple.Interfeele tradiionale de programare a aplicaiilor (API) nu iau n considerarentotdeauna aceste restricii i nici nu este necesar. Unul din efectele proiectriibazat pe protocol este acela c tehnologia partajat de ageni dureaz de cele maimulte ori mai mult dect agenii nii.

Programatorii lucreaz n general direct cu cod care prelucreazi genereazdirect aceste mesaje. Ele sunt rareori expuse ca atare i utilizatorilor finali, dei acestlucru prezint avantajul c acetia pot cpta abiliti de a lucra cu sistemulplatform16.

16 Underlying system.

p d f Machine





27/144

27

2. HTML

Acest capitol cuprinde principalele concepte ale modelului DOM i extensiaDOM-HTML a acestuia . Este apoi descris limbajul HTML i foile de stil din DHTML,ca metode de programare a paginilor Web statice.

2.1 Modelul DOM-HTML

2.1.1 Modelul Document- Obiect (DOM)

DOM (Document Object Model) este un model de date i un APIindependente de limbaj. Interfaa de programare a aplicaiilor (API) este destinataccesului programatic i manipulrii XML i HTML.

Spre deosebire de instanele XML i schemele XML care sunt memorate nfiiere pe disc, DOM este o reprezentare n memorie a documentului. Necesitatea

acestei reprezentri a derivat din diferenele dintre modul n care diferite navigatoarepermit accesarea i manipularea documentelor dinamice. Unificarea este realizatprintr-o reprezentare standard n memoria navigatorului pentru obiectele dindocument. Modelul acestei reprezentri este cel din programarea OO. Astfel, DOMse definete ca un model de date care utilizeaz obiecte pentru a reprezenta undocument XML sau HTML.

Programarea OO introduce dou concepte cheie n modelarea datelor: claselei obiectele. Clasa este o definiie prin care sunt descrise caracteristicile icomportamentele unei entiti sau concept din lumea real. Pe baza acestei descrierise pot construi n memorie instane ale clasei numite obiecte. Principalul avantaj alacestei abordri n modelarea datelor este este acela c limbajul de programare

necesar prelucrrii acestora este mai apropiat domeniului problemei ce trebuiesoluionat n programul respectiv.

Modelul obiect din cadrul metodologiei OO specific interfee i obiecte.Modelul definete semantica interfeelori obiectelor, comportamentul interfeeloriobiectelor, atributele interfeelori obiectelori relaiile i dependenele ntre interfeei obiecte. DOM (Document Object Model) este o particularizare, pentru domeniulobiectelor de tip document, a modelului obiect din cadrul metodologiei OO. DOMconine specificaiile interfeelori obiectelor utilizate s reprezinte i s manipulezedocumente, specificaii care definesc semantica, comportamentul, atributele, relaiilei dependenele ntre interfeele i obiectele utilizate s reprezinte i s manipulezedocumente. DOM conine definiii pentru o interfa de programare a aplicaiilor careprelucreaz documente HTML i XML. Acestea prezint o modalitate structurat de aaccesa i modifica coninutul paginilor Web, care sunt colecii de elemente.

Specificaia DOM este independent de platformi de limbaj. Ea definetestructura logic a documentelor, ca fiind obiectuali arborescent, i reguli pentruaccesarea i modificarea lor.

Modelul ofer o perspectiv structurat asupra docum

tehnologii web decrypted

Documents