Tehnici De Tip Mashup Pentru Interactiuni Web In Sisteme Informationale Geografice

Universitatea „Alexandru Ioan Cuza”

Facultatea de Informatică

Tehnici de tip mashup pentru
interacţiuni Web în sisteme
informaţionale geografice
Iaşi, 2007

Candidat: Ecaterina Valică

Coordonator: Lect. univ. dr. Sabin Corneliu Buraga

Cuprins
Cuprins...........................................................................................................................2
2. Tehnologii Web .........................................................................................................4
2.1 Web 2.0 ................................................................................................................4
2.1.1 Aspecte generale ...........................................................................................4
2.1.2 Dezvoltare de Software 2.0...........................................................................9
2.2 Servicii Web.......................................................................................................12
2.2.1 Arhitectura orientată spre servicii...............................................................12
2.3 JavaScript...........................................................................................................15
2.3.1 Aspecte generale .........................................................................................15
2.4 AJAX .................................................................................................................18
2.4.1 Aspecte generale .........................................................................................18
2.4.2 JavaScript Object Notation .........................................................................20
3. Sisteme informaţionale geografice ..........................................................................22
3.1 Aspecte generale ................................................................................................22
3.2 Formate de date..................................................................................................27
3.2.1 Geography Markup Language ....................................................................27
3.2.2 Keyhole Markup Language.........................................................................27
3.2.3 GeoRSS.......................................................................................................28
3.2.4 GPS eXchange Format................................................................................28
3.2.5 Microformate ..............................................................................................29
4. Mashup.....................................................................................................................31
4.1 Aspecte generale ................................................................................................31
4.1.1 Tipuri de Mashup........................................................................................33
4.1.2 Provocări, Beneficii, Neajunsuri.................................................................34
4.2 Studiu de caz: GeoLink......................................................................................36
4.2.1 Concept .......................................................................................................36
4.2.2 Analiză şi Proiectare ...................................................................................37
4.2.3 Detalii de implementare..............................................................................39
4.2.4 Utilizare.......................................................................................................45
5. Concluzii ..................................................................................................................49
Acronime......................................................................................................................50
Bibliografie…………………………………………………………………………...51

2

1. Introducere
Suntem obişnuiţi de a organiza informaţiile, locurile şi obiectele din jurul nostru.
Avem capacităţi native de a reţine şi actualiza numele zonelor care prezintă interes,
cât şi modul în care putem ajunge în aceste locuri. Totuşi acest număr de locaţii pe
care le putem gestiona reprezintă un număr limitat per individ şi natura acestuia este
una subiectivă.

În zilele noastre conţinutul informaţional din întreaga lume este convertit la o formă
digitală, făcând astfel informaţiile disponibile oricui, oriunde şi oricând. În ultimele
decenii, Web-ul a devenit o componentă esenţială în vieţile noastre, fiind folosit în
cele mai diverse domenii de activitate. Prin intermediul Web-ului, a serviciilor oferite
de acesta, multe dintre activităţile pe care omul le întreprinde pot fi uşurate şi chiar
evident eficientizate.

Web-ul a devenit un sistem distribuit care permite programatorilor să creeze aplicaţii
combinând date şi servicii în moduri originale spre realizarea unor produse
inovatoare.

Pe măsură ce platformele Web încep să se maturizeze se dezvoltă un număr mare de
tehnologii care duc aplicaţiile actuale la un nivel nou de putere şi accesibilitate.
Hărţile interactive devin din ce în ce mai prezente în aplicaţiile Web moderne. Două
dintre domeniile cele mai evidente în care această tehnologie are un mare impact sunt
turismul şi piaţa imobiliară. Deşi majoritatea aplicaţiilor Web din ziua de astăzi ar
putea beneficia de un sistem cartografic integrat, dezvoltatorii se izbesc de
complexitatea integrării unui sistem geografic de baze de date.

Hărţile interactive, care să comunice în timp real cu un server, au fost considerate
dificil de realizat până la apariţia tehnologiilor recente ca Google Maps şi Ajax.

Convergenţa dintre SOA/Client şi aplicaţiile de tip mashup va duce la realizarea de
unelte de dezvoltare care vor facilita transferul de servicii între graniţele interne ale
organizaţiilor. Informaţia devenind total accesibilă va permite arhitecţilor,
dezvoltatorilor şi utilizatorilor să pună în spaţiul Web orice idee.

3

2. Tehnologii Web
2.1 Web 2.0
Web-ul pune la dispoziţie un sistem global şi standardizat de comunicare
multimedia, informaţiile fiind organizate asociativ şi distribuite în funcţie de cererile
utilizatorilor.

Web-ul se îndreaptă de la o colecţie descentralizată de situri Web către o platformă
computaţională ubicuă. Acest nou concept îl întâlnim sub denumirea de Web 2.0.

Web 2.0 doreşte să ofere suport pentru realizarea de marcaje definite de utilizatori,
manieră deschisă de participare, grad ridicat de descentralizare a datelor şi a
serviciilor existente, încredere radicală şi interacţiune tot mai bogată şi complexă cu
utilizatorul. Mai mult, utilizatorii actuali doresc flexibilitate, internaţionalizare,
calitate, funcţionalitate, utilizabilitate, adaptabilitate şi consistenţă.

Momentan, suntem martorii unei tranziţii în care Web-ul este văzut mai mult ca o
platformă software, în care utilizatorul îşi controlează propriile date, punându-le în
mod uzual la dispoziţia altora, prin intermediul unor instrumente colaborative.
Asistăm la proliferarea de servicii specializate, acestea putând fi invocate într-o
manieră transparentă, de către oricine.

2.1.1 Aspecte generale
Principalele competenţe ale unei aplicaţii Web 2.0:

Oferirea de servicii, nu de pachete software, cu o scalabilitate eficientă cost;
Controlul asupra surselor de date, care sunt îmbunătăţite pe măsură ce mai
mulţi utilizatori le folosesc;
Încredinţarea utilizatorilor ca co-dezvoltatori;
Utilizarea inteligenţei colective;
Permiterea de auto-serviciu (self-service) şi participare pentru client;
Distribuirea de software pentru mai multe dispozitive;
Descentralizare radicală;
Mixarea datelor din surse de calitate, combinând micro-conţinut pentru a oferi
noi funcţionalităţi;
Comportament emergent: funcţionalitatea poate fi reutilizată, remixată,
agregată;
Interfeţe utilizator intuitive, modele de dezvoltare şi modele de afacere.

Ideea centrală a Web 2.0 este aceea a manipulării inteligenţei colective,
posibilitatea utilizării de lucruri şi idei pe care ceilalţi le consideră ca fiind folositoare,
interesante.

Se generează conceptul de sit Web care să fie întreţinut de către comunitate şi care
să ofere acesteia serviciile dorite. Funcţionalităţi de genul self-service îl fac pe

4

utilizator să aibă încredere în informaţiile pe care le stochează, să depună timp şi
răbdare pentru îmbunătăţirea serviciilor de care beneficiază. Acest lucru nu arată
numai puterea utilizatorilor în cadrul Web ci demonstrează şi interesul general pentru
software-ul online de calitate, care beneficiază de un „marketing viral”.

Din moment ce majoritatea conţinutul disponibil este generat de către utilizator se
impune un anumit factor de control şi proprietate, astfel încât dacă utilizatorilor le este
refuzat controlul asupra propriilor date, aceştia vor schimba respectivul furnizor
pentru unul care le va oferi această facilitate.

Un serviciu de acest gen devine din ce în ce mai puternic cu cât mai mulţi
utilizatori în folosesc, încadrându-se astfel în acea „arhitectură a participării”.

Una din promisiunile Web 2.0 era aceea de piese de dimensiuni reduse, slab
interconectate. Acest aspect este benefic deoarece reduce complexitatea aplicaţiilor şi
efortul de integrare.

Dezvoltarea mashup-urilor este o dovadă că acest model de integrare aduce
îmbunătăţiri modelului de programare, totul fiind datorat sutelor de API-uri
disponibile ce pot fi combinate şi utilizate pentru ca rezultatul să aducă mai multă
valoare decât suma componentelor.

Comunitatea Web 2.0 a arătat că există metode mai flexibile de a conecta sisteme
decât cele în care se impunea control absolut şi constrângeri rigide. Web 2.0 si
mashup-urile ne oferă o nouă perspectivă asupra arhitecturii orientată-servicii.

Unul dintre conceptele cheie când vine vorba de Web 2.0 este ideea de a
transforma aplicaţiile în platforme şi de a focaliza atenţia pe crearea de software prin
intermediul serviciilor (fie că e vorba de interfeţe utilizator sau servicii Web).

Figura 2.1: Web 2.0 ca platformă [15]

Web 2.0 se concentrează asupra utilizării de integrări lightweight cu scopul de a
avea o barieră inexistentă în crearea comunităţilor şi pentru a permite schimbul dual
de tehnologie pentru crearea ecosistemelor şi a relaţiilor dintre acestea.

5

Un sit Web 2.0 poate folosi unele din tehnologiile următoare [36]:

Aplicaţii Internet complexe (RIA – Rich Internet Applications), realizate
opţional prin Ajax;
Utilizare CSS (Cascading Style Sheets) pentru partea de prezentare;
Marcaje XHTML valide, îmbunătăţite prin utilizarea microformatelor;
Agregarea datelor în format RSS/Atom;
URL-uri curate şi semnificative;
Utilizarea extensivă de folksonomi (în formă de taguri);
Utilizarea de software wiki complet sau parţial, pentru generarea de platforme;
Utilizarea de software open-source complet sau parţial;
XACML (eXtensible Access Control Markup Language) sau SOAP pentru
controlul acces-ului între organizaţii şi domenii;
Publicare prin blog-uri;
Mashups - aplicaţii Web hibridă;
REST (Representational State Transfer) sau XML Web Service API.

Ajax este o tehnologie extrem de puternică care pune la dispoziţie aplicaţii
puternice, cu aceeaşi flexibilitate cu programele care rulează pe computer, fără a avea
nevoie de nimic mai mult decât un simplu navigator Web. Ajax necesită pentru a
putea funcţiona utilizarea serviciilor Web, mai ales a celor pure HTTP. Astfel, Ajax
este aliniat cu conceptele prezente la ora actuală în Web şi reprezintă o soluţie naturală
pentru multe probleme întâlnite în software-ul online.

Asta ne aduce la arhitectura informaţiei stilului Web. Informaţia este stocată în
XML şi referenţiată prin ierarhii URL. Inabilitatea de a accesa informaţia prin
intermediul unui URL împiedică indexarea la nivel de motor de căutare, posibilitatea
de a integrare sau accesa acea informaţie.

Astfel, modul Web 2.0 de testare, design sau menţinere a software-ului prin
combinarea de componente ca simple incluziuni JavaScript (mashup pe partea de
client) sau servicii Web în stil REST, facilitează dezvoltarea Global SOA (Service-
Oriented Architecture) sau a sferei mashup-urilor.

Serviciile Web lightweight şi modelele ca RSS şi Atom creează un ecosistem
informaţional care nu cunoaşte limite din punct de vedere al consumului şi al
integrării.

O posibilă problemă care poate intervine este aceea a securităţii aplicaţiilor Ajax
din cauza codului disponibil şi uşurinţei cu care acesta poate fi manipulat.

Aplicaţiile de acest gen sunt folositoare pentru că acestea sunt disponibile de
fiecare dată când sunt necesare, indiferent de locaţie, oferind mereu informaţia
căutată.

O îmbunătăţire a acestui model poate fi adusă de publicarea informaţiilor într-un
loc foarte social. Astfel, aceasta devine mult mai valoroasă şi completă, prin
interacţiunea utilizatorilor care pot să-i adauge valoare prin comentarii, tag-uri,
agregări, bookmarking, etc. Informaţia devine o componentă din inteligenţa colectivă
a Web-ului.

6

Unul dintre punctele tari Web 2.0 este acela de a încuraja protocoalele deschise şi
API-urile pentru răspândirea informaţiei prin servicii, în loc de pagini statice, pentru a
lucru permite informaţiei în stare brută pe care utilizatorii o adaugă aplicaţiilor Web
2.0 să fie distribuită pentru reutilizare. Acest lucru a dus la dezvoltarea rapidă a
fenomenului de mashup şi dezvoltarea unui lanţ dinamic de distribuire de informaţie,
denumit Global SOA şi caracterizat de tehnologii ca RSS, REST.

Web 2.0 asigură lumii SOA tehnici lightweight de construire de soluţii scalabile,
valoroase, atât în interiorul, cât şi în exteriorul firewall-urilor.

SOA devine astfel coloana vertebrală a fenomenului mashup, realizând aspectele
dificile în fundal şi rezolvând problematici ca versiuni multiple, transformări de date,
etc. Mashup-urile sunt aflate la un nivel superior, bazându-se pe arhitecturi dinamice.

Figura 2.2: Imagine de ansamblu asupra Web 2.0 [7]

Aplicaţiile de tip situational software, sunt aplicaţii instante ce pot fi asamblate
just-in-time prin utilizarea unor palete de servicii şi feed-uri disponibile în cadrul Web
sau în cadrul întreprinderii. Se numesc situaţionale deoarece pot fi create doar când o
anumită situaţie apare şi distruse când nu mai sunt necesare. Acest tip de aplicaţii
poate fi inclus în conceptul Web 2.0 de self-service, consumatorul realizând soluţii din
concatenarea blog-urilor, wiki-urilor, adăugând feed-uri, widget-uri şi servicii Web.
Această soluţie este încadrată în managementul personalizat al relaţiilor cu clientul în
care utilizatorii obţin ceea ce îşi doresc ajutându-se singuri şi creând respectiva
aplicaţie. Toate aceste realizează aplicaţii mult mai rapide, ieftine, mai uşor de
refolosit şi menţinut.

7

Pentru realizarea acestui tip de aplicaţie este nevoie de:

Servicii, nu aplicaţii monolitice. Se realizează o conexiune mult mai strânsă
între produs şi consumator. Se urmăreşte succesul serviciilor focalizate pe
adopţia cerinţelor utilizator, date la cerere, costuri scăzute, ridicarea
infrastructurii publice şi feedback între furnizor şi consumator.
Comunitate. Crearea unei locaţii virtuale în care utilizatorul să poată adăuga
informaţii personalizate (tag-uri, comentarii, ratings) şi care să ofere
caracteristici sociale şi mecanisme de feedback.
Simplitate. Uşurinţa de folosire a unui program este un aspect cheie. Api-urile
actuale se concentrează asupra experienţei utilizator şi procesul de mixare de
informaţii devine simplu pentru dezvoltator datorită uşurinţei de utilizare a
API-urilor respective, cât şi a formatelor simple de transport a informaţiei ca
RSS sau Atom.

Există cantităţi masive de conţinut generat utilizator creat non-stop. Acest lucru
face ca un utilizator să devină cea mai importantă componentă a Web-ului. Apoi este
ecosistemul mashup care îşi atinge din ce în ce mai mult scopul de a oferi
utilizatorilor o experienţă ghidată, prin alegerea informaţiei prezentate. Blog-urile şi
wiki-urile sunt aproape în totalitate self-service, ceea ce arată că transferul puterii de
creare de software în mâna utilizatorilor este în desfăşurare.

Inovaţia va veni din partea utilizatorilor ce deţin timpul, energia, creativitatea,
motivaţia şi contextul pentru a realiza software mai bun, în felul lor. Şi aceasta devine
productivă când este împărţită, încurajând şi ceilalţi utilizatori de a aduce
îmbunătăţiri.

RSS, Ajax au bariere foarte mici în reutilizare. Majoritatea software-ului folositor
este open source. Opţiunea navigatoarelor „View Source” permite oricărui utilizator
să înţeleagă şi refolosească componentele folositoare întâlnite. RSS a dat utilizatorului
posibilitatea de a selecta informaţia pe care doreşte să o vizualizeze.

8

2.1.2 Dezvoltare de Software 2.0

Satisfacerea consumatorilor reprezintă un scop al afacerilor online şi offline. Acest
lucru este posibil în modelul Web 2.0 datorită aplicaţiilor, şabloanelor care au fost
introduse, oferind potenţialul de prezentare clienţilor de produse mai bune, mai
complete şi într-un mod cât mai rapid.

Figura 2.3: Redarea controlului utilizatorilor pentru realizarea de aplicaţii [13]

Având în vedere că numărul de potenţiali clienţi depăşeşte mereu numărul de
dezvoltatori, este greu de oferit consultanţă, mai ales într-un mod individual. Mediul
de interacţiune fiind cel online, se pot oferi acum unelte utilizatorilor pentru a rafina,
adapta şi contribui la produsele şi serviciile oferite, adăugându-le acestora inovaţie.
YouTube este poate cel mai bun exemplu de co-dezvoltare din partea clienţilor (mai
mult de 65.000 fişiere video adăugate în fiecare zi). Dezvoltarea de Software 2.0
înseamnă în primul rând colectarea de contribuţii utilizator, realizând o bază de date
de „intenţii” şi clasificând feedback-ul primit pentru a identifica cel mai bun şi cel mai
popular conţinut sau capabilitate.

Acest transfer de dezvoltare de la instituţii către utilizatori, transformă pe
beneficiari mai mult în mediatori şi facilitatori, decât în creatori sau deţinători. Acesta
reprezintă un aspect al aplicaţiilor aflate în stadiul de beta continuu, concept care
reflectă că produsele şi serviciile online nu sunt niciodată complete sau în formă
finală, mereu fiind adăugat conţinut şi funcţionalitate.

9

Dezvoltarea de Software 1.0 Dezvoltarea de Software 2.0
Canal de interacţiune Telefon, e-mail, contact Web, e-mail, IM
cu utilizatorul personal (face-to-face)
Sursa de inovaţie Organizaţiile Clienţii
Ciclul inovaţiei Luni, Ani Minute, ore, zile
Creatori de conţinut Producători interni Producători externi
Mecanisme feedback Studiu de piaţă, chestionare, Analiză, cereri online,
reclamări, grupuri de interes schimbări produse de clienţi
Stilul clienţilor Controlat, proces bine definit Spontan şi haotic
Proces de dezvoltare Desing Preconceput Mai mult emergent
Arhitectura Închisă, neflexibilă Deschisă, uşor de extins,
produsului extensiilor creată pentru remixare şi
mashup
Cultura de Ierarhică, centralizată, Decentralizată, colaborativă,
dezvoltare realizată de experţi inteligenţă colectivă
Testarea produsului Intern, dedicată grupului de Utilizatori ca testeri
test, testeri selectaţi
Suport pentru client Serviciu client Comunitate de useri
Promovare Produs Publicitate şi marketing într- Propagare virală, publicitate
o singură direcţie generată de utilizator şi
bidirecţională
Relaţii client Cumpărător extern Partener (consumator ca
producător)
Deţinerea produsului Instituţie, acţionari, Întreaga comunitate de
management executiv utilizatori
Proces de parteneriat Formal, explicit, mediat Ad hoc, parteneri online,
nemediat

Dezvoltarea Heavyweight, formal, Lightweight, informal,
produsului complex, costisitor, simple, gratuit, rapid, orientat
consumator de timp, orientat consumator
întreprindere
Avantaje Produse superioare, avantaje Personalizare, popularitate,
competitive de branding, preţ simţ de proprietate, audienţă

Tabel 2.1: Tranziţia către Dezvoltarea de Software 2.0 [13]

Astfel produsele Web 2.0 ar trebui să ofere:

Lansări frecvente ce au ca beneficii înlăturarea erorilor nou găsite, ceea ce
face experienţa pe care o are utilizatorul să fie într-o evoluţie lină;
Bucăţi mai puţin specialitate, slab interconectate, ce permit realizarea
schimbărilor într-un mod rapid şi neriscant;
Modele de programare lightweight prin utilizarea de limbaje dinamice şi
formate de date simple ca RSS, REST, ce fac dezvoltarea, integrarea, testarea şi
refolosirea simple şi eficiente;
Feedback în timp real şi utilizarea informaţiilor primite de la utilizator pentru
îmbunătăţirea aplicaţiilor.

10

Un astfel de produs va fi criticat în funcţie de următoarele criterii [35]:

Aplicabilitate (35%) – evaluarea soluţiei în mod realist în funcţie de problema
pe care trebuia să o rezolve. Ar trebui să deţină un răspuns pozitiv la
următoarele întrebări: Vor folosi angajaţii vreunei companii această aplicaţie?
Aduce îmbunătăţiri productivităţii, stilului de viaţă? Poate obţine finanţare
pentru dezvoltări ulterioare?
Funcţionalitate (35%) – testarea soluţiei pentru asigurarea corectitudinii.
Există funcţii care nu merg? Sunt mesaje de eroare generate? Sunt întâlnite
erori serioase? Împiedică erorile utilitatea aplicaţiei? Există funcţii care aduc
inovaţie?
Design (20%) – evaluarea uşurinţei de folosire, simplitatea de afişare a
informaţiilor, manevre de navigaţie, grade de efort de înţelegere. Navigarea se
realizează cu uşurinţă şi rapiditate? Utilizează metode intuitive? Sunt
aplicabile instrucţiunile minimale?
Ansamblul soluţiei (10%) – se testează dacă aplicaţia îndeplineşte scopurile
pentru care a fost creată şi modalităţile de realizare a acestora. Confruntarea se
face la nivel de documentaţie Rezumatul lucrării descrie concis scopul
aplicaţiei? Este prezentat modul de utilizare al aplicaţiei? Sunt toate funcţiile
descrise?

Alte criterii de jurizare ale unei aplicaţii pot fi:

Interes (25%) – soluţia prezintă interes din punct de vedere al consumatorilor?
Utilitate (25%) – rezolvă o problemă existentă pe piaţă?
Unicitate (20%) – oferă o funcţionalitate indisponibilă până atunci?
Uşurinţă (20%) – soluţia este uşor de utilizat?
General (10%) – este o aplicaţie care ar putea fi cumpărată?

11

2.2 Servicii Web
O aplicaţie Web reprezintă o colecţie interconectată de pagini Web cu un conţinut
dinamic, menită să ofere o funcţionalitate specifică utilizatorilor.

Serviciile Web reprezintă o particularizare a aplicaţiilor Web. Principala diferenţă
este dată de faptul că serviciile Web nu sunt destinate direct utilizatorilor umani, ci
sunt destinate „consumării” sau exploatării, de către alte aplicaţii. De asemenea, un
serviciu Web poate fi consumat de alte servicii Web pentru a asigura un plus de
funcţionalitate şi integrare. Serviciile Web sunt deci componente care oferă capacitate
de procesare adiţională, aplicaţiilor consumator.

Serviciile Web implică utilizarea unor protocoale de comunicaţie, având asociate
descrieri ale datelor procesate şi alte interacţiuni cu aplicaţii terţe. O altă caracteristică
de bază a serviciilor Web derivă din necesitatea de interoperabilitate (capacitatea de
colaborare între componente, aplicaţii şi sisteme eterogene). Un serviciu Web poate fi
considerat ca fiind compus dintr-o colecţie de funcţii împachetate, interpretate ca o
entitate unică şi publicate în spaţiul WWW cu scopul de a fi folosite de alte programe.

2.2.1 Arhitectura orientată spre servicii
Arhitectura orientată spre servicii (SOA) impune adoptarea unui stil de dezvoltare de
aplicaţii, considerate drept servicii ce vor fi invocate de alte aplicaţii. SOA presupune
că noile servicii pot fi create pe baza celor deja existente, dar componentele sistemului
în ansamblu trebuie să aibă un grad mare de independenţă.

Astfel, arhitectura SOA trebuie să suporte între aplicaţii paradigme de comunicare
bazate pe Web, să ofere o localizare transparentă a serviciilor şi să permită adăugarea,
înlocuirea şi eliminarea serviciilor în mod dinamic.

Prin intermediul SOA, consumatorii de servicii nu sunt dependenţi de ofertanţii de
servicii, putând avea acces la o paletă largă de servicii oferind aceleaşi funcţionalităţi
dorite.

Pentru a adresa această necesitate serviciile Web trebuie să deţină abilitatea de a
comunica folosind standarde ale industriei precum SOAP şi WSDL, ambele
recomandări ale consorţiului Web. Protocoalele de comunicare trebuie să permită
vehicularea de mesaje oricât de complexe şi interacţiuni avansate între maşinile care
le utilizează, asigurând extensibilitatea, securitatea, fiabilitatea şi performanţa ce pot
surveni.

Descrierea serviciilor Web (locaţie, operaţiuni, parametri, tipuri de date) se
realizează prin intermediul limbajului WSDL (Web Service Description Language),
dezvoltat de IBM şi Microsoft. Folosind WSDL se pot crea fişiere XML care conţin
seturi de definiţii pentru descrierea serviciilor Web. Conceptual, WSDL constituie o
modalitate de specificare a sintacticii serviciilor Web, nu a semanticii acestora.

12

Înregistrarea şi regăsirea serviciilor Web se realizează prin intermediul
standardului UDDI (Universal Description, Discovery and Integration). Aceasta oferă
utilizatorului o modalitate sistematică şi unitară de a regăsi furnizorii serviciilor Web,
cu ajutorul unui catalog al acestor servicii.

Mecanismul de invocare a serviciilor Web şi de schimb al mesajelor între client şi
server este descris de un protocol de comunicare, independent de platformă, limbaj de
programare, reţea sau protocol de transport: XML-RPC (XML-Remote Procedure
Call), SOAP (Simple Object Access Protocol).

2.2.1.1 SOAP

SOAP reprezintă un standard ce utilizează paradigma XML-RPC pentru a transporta
mesaje serializate XML într-o manieră extensibilă, utilizabil indiferent de
infrastructura conexiunii şi independent de modelul programatic utilizat de aplicaţie.

SOAP reprezintă o recomandare a Consorţiului Web. Mesajul SOAP este compus
din trei părţi:

un plic (envelope) – care defineşte cadrul de lucru pentru a descrie ceea ce
conţine mesajul şi modul de procesare a acestui conţinut. Datele din corpul
mesajului pot fi transportate indiferent de protocolul folosit (HTTP);
un set de reguli de codificare (encoding rules) pentru exprimarea instanţelor
tipurilor de date definite în aplicaţie;
o convenţie de reprezentare (reprezentation) a apelurilor de metode
implementate de serviciul Web şi răspunsurilor furnizate în urma invocării
acestora.

SOAP poate specifica o cale de la expeditor la destinatar, via un intermediar
(proxy) opţional, în vederea realizării de dirijări de mesaje.

SOAP poate fi privit ca fiind un protocol de mesagerie (serializare), cererea
incluzând un obiect-cerere serializat, iar răspunsul stochează un obiect-răspuns
serializat.

2.2.1.2 REST (Representational State Transfer)

Arhitectura REST este o arhitectură de dezvoltare a aplicaţiilor Web, în cadrul căreia
rezultatul unei procesări conduce la returnarea unei reprezentări a unei resurse Web.
Orice accesare a unei reprezentări plasează aplicaţia-client într-o stare care va fi
schimbată în urma unui transfer de date. Principiile REST oferă o abordare diferită de
una în stilul RPC (abordată de protocolul SOAP). În cazul RPC, punctul focal e
reprezentat de mulţimea de operaţii ce pot fi executate, pe când în viziunea REST totul
se axează pe diversitatea resurselor disponibile.

Ca şi alte tipuri de servicii Web, arhitectura REST este bazată pe conceptul de
resursă. Unui serviciu Web de tip REST îi sunt impuse de anumite constrângeri.

13

Interfeţele sale sunt limitate la protocolul HTTP:

GET - utilizată pentru a obţine o reprezentare a unei resurse; folosind un URI,
un consumator recurge la această metodă pentru a regăsi o reprezentare;
DELETE – utilizată pentru a elimina reprezentările unei resurse;
POST – utilizată pentru actualizarea sau crearea reprezentărilor unei resurse;
PUT – utilizată pentru crearea reprezentărilor unei resurse.

Mesajele utilizează formatul XML, putând fi validate prin intermediul unor
specificaţii precum XML Schema sau RELAX NG.

Crearea şi utilizarea serviciilor Web de tip REST necesită o infrastructură software
minimală. Astfel, aceasta trebuie să implementeze protocolul HTTP şi o serie de
tehnologii de procesare XML, suportate de cele mai multe platforme li limbaje de
programare. Filozofia serviciilor Web REST este aceea de a nu instala instrumente
suplimentare pentru trimiterea şi primirea de date, ci de a le utiliza pe cele existente.

Un număr de companii (Google, Yahoo!, Amazon, eBay, etc.) au pus la dispoziţia
programatorilor servicii Web bazate pe REST. În mod obişnuit, clientul trimite o
cerere GET serviciului. Acesta procesează cererea primită şi întoarce rezultatele
obţinute.

14

2.3 JavaScript
JavaScript a fost creat pentru a adăuga interacţiune paginilor XHTML şi este folosit
de milioane de pagini Web pentru o îmbunătăţire a design-ul, validarea de formulare,
detectarea navigatorului, crearea de cookies, tratarea evenimentelor, scrierea de noi
elemente.

JavaScript este un limbaj orientat obiect foarte puternic, portabil, rapid, simplu în
ciuda reputaţiei că nu ar fi potrivit pentru programatorii profesionişti.

JavaScript este un limbaj interpretat. Deoarece este folosit cu preponderenţă
pentru procesare pe partea de client a aplicaţiilor Web, majoritatea navigatoarelor au
integrate interpretoare JavaScript.

JavaScript este un limbaj de scripting, cu o sintaxă apropiată de C, având la bază
conceptul de prototip. Mediul gazdă în care este înglobat este navigatorul Web, care
creează obiecte responsabile pentru implementarea modelului DOM.

În mod uzual, codul JavaScript este înglobat direct în paginile XHTML, prin
intermediul marcajului script sau în fişiere externe cu extensia .js, urmate a fi incluse
ulterior în pagini.

Nucleul limbajului include elementele de bază ale limbajului: tipuri de variabile şi
constante, operatori, structuri de control, instrucţiuni, reguli pentru definirea funcţiilor
şi obiectelor, funcţii şi obiecte predefinite, etc.

JavaScript este un limbaj flexibil în ceea ce priveşte datele utilizate. O variabilă
este numele simbolic atribuit unei locaţii de memorie în care sunt stocate date.
Domeniul de accesibilitate al variabilelor şi al constantelor poate fi unul global sau
local, declaraţie facută prin utilizarea cuvântului var, respectiv const. Dacă o variabilă
sau o constantă este declarată în interiorul unei funcţii, ea este numită locală, fiind
accesibilă numai în cadrul funcţiei. Variabilele declarate fără var sunt globale în
întreg programul. Flexibilitatea limbajului se datorează faptului că la declararea
variabilelor nu se cere specificarea tipului de date stocate. În plus, este posibil ca în
script să se modifice tipul datelor stocate în variabile.

JavaScript este case-sensitive.

Funcţiile sunt secvenţe de cod care realizează o anumită operaţie şi care poate fi
apelată în mod repetat. Din punct de vedere al modalităţilor de definire există funcţii
definite de utilizator şi funcţii predefinite.

Definiţia unei funcţii JavaScript constă din cuvântul-cheie function, urmat de
numele funcţiei, o listă de argumente inclusă între paranteze rotunde şi separate prin
operatorul virgulă şi un bloc de instrucţiuni inclus între acolade:

15

function numeFuncţie(arg1, arg2, arg3) {
instrucţiuni; return expresie;
}

Sunt permise şi funcţiile anonime:

var funcţie = function(arg1, arg2) {
instrucţiuni;
return expresie;
};

Este posibil ca unei funcţii JavaScript să-i fie transferate mai multe argumente
decât au fost specificate la declarare. Acest lucru este util, mai ales în situaţiile în care
nu se ştie de la început câte argumente trebuie transmise acesteia. Valorile
suplimentare nu sunt pierdute, ci sunt stocate într-un tablou numit arguments.
Transferul argumentelor având tipuri simple(e.g. şir, întreg) este realizat prin valoare,
în timp ce argumentele de tip obiect sunt transferate prin referinţă.

Funcţiile predefinite de nivel înalt prezente în limbaj sunt: decodeURI(),
decodeURIComponent(), encodeURI(), encodeURIComponent(), escape(), eval(),
isFinite(), isNAN(), Number(), parseFloat(), parseInt(), String(), unescape().

JavaScript este un limbaj bazat pe obiecte. Spre deosebire de alte limbaje
orientate obiect, bazate pe clase şi instanţe, în JavaScript nu avem decât obiecte. Un
obiect JavaScript este un tip de date care include proprietăţi şi funcţii, numite şi
metode. Pentru a adăuga o proprietate unui obiect creat anterior se utilizează
proprietatea prototype. Prototipul unui obiect este la rândul său un obiect, în care se
caută metodele şi proprietăţile cerute în cazul în care nu sunt găsite în obiectul iniţial.
Se creează astfel un lanţ de obiecte ce definesc un comportament, într-o manieră
asemănătoare moştenirii din OOP (programare orientată obiect). Filozofia limbajului
are în vedere asocierile de tip cheie-valoare folosite pentru descrierea proprietăţilor
obiectelor.

Nucleul JavaScript include mai multe obiecte predefinite: Array, Boolean, Date,
Function, Math, Number, String şi RegExp, fiecare dintre aceste obiecte având
metode proprii specifice.

JavaScript este utilizat, în special, pentru accesarea arborelui DOM al
documentelor XHTML şi XML. Interfaţa DOM furnizează o reprezentare structurală a
unui document, oferind posibilitatea modificării dinamice a conţinutului, a structurii şi
stilurilor acestuia. Utilizând DOM se pot construi documente, naviga prin structura
acestora şi adăuga, modifica sau şterge elemente sau atribute incluse. Documentul
poate fi procesat în continuare, iar rezultatul procesării poate fi inclus înapoi în pagina
afişată. În DOM, documentul XHTML este văzut ca un arbore de noduri. În vârful
arborelui se află obiectul document, prin intermediul căruia avem acces la colecţii de
obiecte asociate elementelor existente în document. Până în prezent există trei niveluri
de specificare DOM.

Evenimentele DOM permit înregistrarea unor handlere de eveniment asociate
nodurilor arborelui. Printre evenimentele suportate de toate navigatoarele actuale
avem evenimente de mouse (click, mousedown, mouseup, mouseover, mouseover,

16

mousemove), evenimente de tastatură (keydown, keypressed, keyup), evenimente
declanşate în formulare (select, change, submit, reset, focus, blur), evenimente legate
de ferestre (load, unload, abort, error, resize, scroll).

Astfel, JavaScript este cel mai utilizat limbaj de scripting pentru client în Web.
Problemele care pot apărea sunt datorate diferenţelor de implementare dintre
navigatoarele Web, totuşi se remarcă o tendinţă comună de implementare a modelului
standardizat al Consorţiului Web.

17

2.4 AJAX
„if the traditional web was letter writing, Ajax is instant messaging.” Derek Powazek

AJAX este o componentă cheie a aplicaţiilor Web 2.0 ce are scopul de a crea aplicaţii
cu proprietăţi asemănătoare aplicaţiilor desktop din punct de vedere al conţinutului şi
modului de răspuns, dar cu avantajul că pot fi accesate de navigatoare Web.

Interacţiunea AJAX derivă dintr-o necesitate de a mări viteza de navigare prin
micşorarea timpilor de răspuns la acţiunile utilizatorilor, aceasta bazându-se pe o
comunicare asincronă între client şi serverul Web, care realizează actualizarea
conţinutului fără necesitatea reîncărcării paginii de prezentare.

AJAX este tehnologia care permite codului JavaScript să trimită o cerere către
server, să primească datele din răspuns (în format XML sau JSON), să procese aceste
date şi să actualizeze conţinutul paginii în mod corespunzător. Cererile AJAX,
realizate prin obiectul XMLHttpRequest, se pot trimite serverului fără a întrerupe
utilizatorul, în mod asincron. Când răspunsul este primit de navigatorul clientului, o
funcţie callback este apelată pentru procesare datelor şi afişarea acestora în cadrul
paginii Web.

Avantajele majore aduse de AJAX sunt cele legate de eliminarea reîncărcării
paginilor, de facilitatea interacţiunii cu utilizatorul, de micşorarea timpilor morţi,
accesarea doar a unei anumite părţi din cadrul paginii Web.

Pe măsură ce deţinem navigatoare puternice, conexiuni la Internet de mare viteză,
direcţii de dezvoltare de software online şi unelte pentru a le implementa, atingem un
punct în care Ajax devine popular şi permite lumii să îmbrăţişeze nevoia de a
transforma paginile statice şi plictisitoare în aplicaţii sofisticate.

Ajax este deseori asociat cu Rich Internet Applications (RIA), reprezentând
aplicaţii cu interfeţe complexe utilizator sunt din ce în ce mai prezente pe scena Web,
utilizând grafice complexe, informaţie diversă şi o experienţă utilizator cât mai
completă.

Ajax este diferit de modul tradiţional de dezvoltare şi design Web, datorită
pierderii de convenţii de interfaţă, permiterea integrării de funcţionalităţi ascunse sau
latente, şi crearea programatică în loc de declarativă a elementelor. Pentru proiectarea
interfeţei, designeri Web au nevoie de o întelegere mai aprofundată a capabilităţilor
DOM, JavaScript, CSS şi a modalităţii în care navigatorul randează grafice, elemente
şi dispunerea acestora. Un alt neajuns datorat lipsei de unelte de dezvoltare este
testarea aplicaţiilor care este dificilă. Va mai fi nevoie de câţiva ani pentru ca
industria să dezvolte practici şi şabloane eficiente de dezvoltare.

Nu se poate preciza încă un lider al pieţei, uneltele şi componentele de dezvoltare
Ajax fiind în continuă dezvoltare. Dintre aceste unelte, putem aminti: Dojo,

18

script.aculo.us, Prototype, Google Web Toolkit, Yahoo! UI Library, JackBe, Zapatec,
Bindows, Nexaweb, General Interface, Backbase, ActiveWidgets sau Microsoft Atlas.

Ajax este o componentă de bază al fenomenului de dezvoltare de mashup-uri în
interiorul navigatoarelor. Datorită Global SOA, componente Ajax online, ca Google
Maps, pot fi referenţiate prin linii de cod JavaScript şi folosite pentru mixare într-o
formă sau alta.

Astfel, AJAX este o tehnică de tip remote scripting prin care sunt utilizate
împreună, în mod specific, mai multe tehnologii existente, în scopul creării aplicaţiilor
Web cu interactivitate crescută şi cu viteză de execuţie ridicată. AJAX include:

HTML/XHTML şi CSS, pentru reprezentarea datelor;
DOM pentru redarea dinamică şi interacţiune;
XML sau JSON, precum şi XSLT, pentru schimbul de date şi manipularea
acestora;
obiectul XMLHttpRequest pentru transferul asincron al datelor;
JavaScript pentru procesarea informaţiilor.

Modul de lucru al aplicaţiilor Web bazate pe tehnica AJAX are următoarele
caracteristici:

Foloseşte interacţiunea la nivel de componentă a paginii;
O componentă poate face un apel JavaScript către motorul AJAX;
Procesorul AJAX face o cerere HTTP pentru o resursă situată pe server, pe
care o trimite unui modul pentru procesare;
După procesare, serverul utilizează un anumit format pentru date pe care le
trimite apoi procesorului AJAX;
Procesorul AJAX actualizează componenta care a iniţializat procesul.

Din punct de vedere AJAX, întreaga aplicaţie se regăseşte la nivelul navigatorului,
ceea ce poate avea repercusiuni nedorite privind sincronizarea serverului cu clientul.
Alte dezavantaje vizează dependenţa de tehnologia JavaScript (implementată în mod
diferit de fiecare navigator în parte), dificultatea testării şi depanării aplicaţiilor,
necesitatea folosirii navigatoarelor de ultimă generaţie, accesul oricui la codul-sursă
(probleme de securitate) şi imposibilitatea folosiri mecanismului istoric al navigării
(history).

Componenta de bază este obiectul XMLHttpRequest [37] pus la dispoziţie de către
navigatorul Web. Acest obiect permite realizarea de cereri HTTP (e.g. GET şi POST)
dintr-un program rulând la nivel de client spre o aplicaţie de pe server, într-un mod
asincron.

Obiectul XMLHttpRequest este o interfaţă de programare a aplicaţiilor (API) care
permite scripturilor să realizeze funcţionalităţile unui client HTTP, cum ar fi
trimiterea datelor incluse în formulare sau încărcarea datelor stocate pe un sit Web.
Obiectul XMLHttpRequest are o serie de metode definite în specificaţia publicată de
Consorţiul Web:

19

Open() – iniţializează o conexiune HTTP cu serverul, trimiţând o cerere către
acesta;
Send() – transmite date, în manieră asincronă, către aplicaţia care rulează pe
server;
Abort() – abandonează transferul curent;
setRequestHeader() – specifică diverse câmpuri ale antetului HTTP;

şi proprietăţi:

readyState – conţine codul de stare a transferului (0 - uninitialized, 1 – open, 2
- sent, 3 – receiving, 4 - loaded);
status – reprezintă codul de stare HTTP întors de serverul Web (200 – OK,
404 – Not Found, 500 – Server Error);
statusText – desemnează şirul de caracter care descrie codul de stare obţinut;
onreadystatechange – desemnează funcţia care va fi invocată la modificările
privind schimbarea stării de transfer a datelor

O alternativă la XML în ceea ce priveşte interschimbul de date este JSON.

2.4.2 JavaScript Object Notation
JSON (JavaScript Object Notation) [38] este un format complementar XML pentru
reprezentarea datelor schimbate între server şi client în AJAX. Formatul JSON este
complet independent de limbaj şi este bazat pe două structuri de date universale: o
colecţie de perechi nume/valoare; o listă ordonată de valori.

JSON este popular pentru serviciile de tip REST care sunt consumate de aplicaţii
Web 2.0.

În JSON, cele două structuri iau următoarele forme:

obiect – set neordonat de perechi nume/valoare inclus între acolade. Fiecare
nume este urmat de caracterul două puncte şi valoarea sa. O pereche
nume/valoare este separată de următoarea prin simbolul virgulă;
tablou – este o colecţie ordonată de valori, inclusă între paranteze drepte,
valorile fiind separate prin virgulă;
valoare – poate fi un şir inclus între ghilimele duble, un număr, un obiect, un
tablou, precum şi valorile true, false sau null. Aceste structuri pot fi imbricate;
şir – este o colecţie încadrată de ghilimele duble, formată din zero, unul sau
mai multe caractere Unicode;
număr – este asemănător cu tipul similar utilizat în JavaScript.

Simplicitatea JSON a determinat o gamă largă de utilizări ale acestuia. El
reprezintă o alternativă la XML în AJAX, ca format utilizat pentru schimbul de date.

În JavaScript, JSON poate fi procesat utilizând funcţia eval(). Acest lucru a fost
important pentru acceptarea JSON de către comunitatea de programatori AJAX,
deoarece JavaScript este prezent în toate navigatoarele moderne.

20

Un exemplu de obiect JSON în formă serializată:

{"location":
{"id": "WashingtonDC",
"city": "Washington DC",
"venue": "Hilton Hotel, Tysons Corner",
"address": "7920 Jones Branch Drive"
}
}

21

3. Sisteme informaţionale geografice
Sistemele informaţionale geografice (GIS) sunt sisteme de captare, stocare, analiză şi
prelucrare de date care sunt raportate geografic. Scopul sistemelor informaţionale
geografice este acela de a localiza informaţia, de a o face accesibilă, de a vizualiza
relaţiile acesteia cu alte componente de acelaşi fel şi de a realiza rapoarte statistice
între aceste componente. În alte cuvinte, scopul este acela de a oferi un punct de start
pentru organizarea din punct de vedere geografic a tuturor informaţiilor.

3.1 Aspecte generale
Organizaţiile care utilizează sau întreţin date geografice întâmpină multe provocări.
Tehnicile curente de colectare şi management de date sunt costisitoare şi producătoare
de erori. Analiştii din industrie susţin că circa 80% din informaţia guvernamentală
este asociată cu informaţii geografice. De asemenea, un număr ridicat de organizaţii
doresc să incorporeze date geografice în producţie (e.g. Yahoo!, Google). O astfel de
ce cerere a acestui tip de date necesită un management eficient şi distribuţia
informaţiilor devine critică. Rezultatul este apariţia unei pieţe noi în arena GIS care să
satisfacă cerinţa de informaţia geografică calitativă distribuită pe Internet în timp real.

Informaţia geografică stă la baza aplicaţiilor care au la bază locaţia. Aceste
aplicaţii pun la dispoziţie utilizatorului posibilitatea de a vizualiza hărţi şi de a:

Crea rute către o destinaţie, calculând calea cea mai scurtă;
Sorta categoriile, cum ar fi instituţiile comerciale, după distanţă şi timp faţă de
locaţia clientului;
Modifica dinamic rute pentru a evita obstacolele, cum ar fi traficul;
Marca locaţiile vehiculelor şi de a elimina pe cele mai apropiate sau care ating
anumite obiective.

Deciziile corecte de cele mai multe ori se bazează pe hărţi cât mai complete,
precise, actuale şi provenite din surse de încredere, care sunt utilizate pentru
navigaţie, trafic, căutare de puncte de interes, reţele sociale, turism, etc.

Hărţile conţin date topologice de tip vector sau raster care pot fi organizate prin
multiple metode, cum ar fi baze de date relaţionale. Aceste date sunt folosite pentru
calcularea rutelor, găsirea punctelor de interes apropiate, sau pentru orice alte tipuri de
analiză geografică.

În termeni simpli, informaţia spaţială constă din puncte, linii şi-sau poligoane.
Fiecare dintre aceste elemente pot fi asociate unuia sau mai multor atribute pentru a
defini calitatea sau caracteristicile unui obiect. În contextul unei hărţi, un atribut
reprezintă orice tip de informaţie care poate fi asociat direct sau indirect unei locaţii la
un anumit punct, despre o anumită linie sau poligon. Aceste atribute conţin atât
dimensiuni statice (drumuri, semne, râuri), cât şi dinamice (trafic, condiţii de vreme).

22

Există 204 atribute geografice clasificate de NAVTEQ, furnizor mondial de GIS,
în 14 categorii. Aceste atribute descriu calităţile esenţiale care sunt necesare unei
hărţi pentru a reda informaţii estetice şi folositoare, care vor fi folosite în planificare
de rute sau în ghidare.

Categoriile se împart în [39]:

Legătură – include atribute de clasificare ale drumurilor folosite pentru a
determina eficienţa drumului respectiv pentru un turist. Sub-categoriile cheie
sunt:

General – include categoria de viteza, direcţia de mers, clasa drumului;
Caracteristici de acces – identifică tipurile de trafic permise pe un
drum (pietoni, autobuze, camioane);
Caracteristici de afişare – descrie aspecte ale drumului ca poduri,
tuneluri;
Nume şi Adresă – se orientează asupra convenţiilor asociate numelor şi
adresei, cum ar fi formatul adresei, tipul străzii, tipul rutei;
Statutul de Nume – include numărul de ieşire, numele de joncţiune şi
numele semnului de circulaţie folosit în aplicaţii de navigare în
momentul anunţurilor de stradă pe care conducătorul trebuie să le
urmeze pentru îndrumările de direcţie ale unei rute;

Zone administrative – identifică entităţile guvernamentale asociate cu un
drum, cum ar fi: ţară, stat, oraş, cod poştal, zonă;
Punct de interes (POI) – include nume, locuri ca bănci, benzinării sau
restaurante. Peste 30 de atribute sunt folosite pentru a caracteriza un POI, cum
ar fi felul benzinăriei, tipul de mâncare servit în restaurant sau număr de
telefon;
Semne – include reprezentările textuale sau grafice de informaţie, întâlnite pe
parcursul drumului, ca: textul semnului, codul de limbă, numărul de ieşire,
numărul de sector;
Utilizare terestră - include informaţii cartografice referitoare la obiective
create de om, ca şcoli, aeroporturi, parcuri, etc.;
Ţară – deţine informaţii ca fus orar, codul de telefon, etc.;
Nod – include intersecţii, descrise de atribute ca coordonată x, y, z, aliniere;
Condiţii – identifică limitările şi calificările pentru utilizarea unui drum, de
exemplu, zonele cu acces interzis pentru rezidenţi;
Trafic – include un set de coduri care descriu condiţiile de trafic, cum ar fi
fluxul de trafic, accidente, disponibilitate;
General – conţin atribute ca intersecţii, drumuri şi obiecte ca intersecţii
complexe sau noduri multiple, care pot fi reprezentate simplificat pentru a
eficientiza calculele rutelor;
Adiţional – extinde valoarea unei baze de date prin informaţii referitoare la:
limita de viteză, numărul de benzi de circulaţie, etc.;
Informaţii extinse despre străzi – ce descriu conectivitatea, dependenţa,
direcţia şi numărul de străzi, alei existente;
Date Vocale – conţin pronunţie şi reprezentare textuală a informaţiilor
prezente în baza de date;

23

Altele – este un atribut adiţional care indică pe care parte a drumului trebuie
afişată o anumită informaţie;

Pentru managementul bazei de date, aceste puncte, linii, poligoane şi atribute
asociate au asociate structuri de date, elemente de date adiţionale, şi-sau metode care
fac procesarea mai rapidă şi mai uşor de întreţinut pentru a face tranziţia către harta
virtuală. Acestea includ:

Topologie spaţială – datele spaţiale şi datele geografice consistă din
menţinerea şi structurarea componentelor lineare cum ar fi reţele de drumuri,
poligoane cum sunt limitele de zonă sau ţară, şi puncte ca oraşe sau locaţii de
spital;
Geocoding – acest proces asignează o poziţie pe hartă unei înregistrări adresă.
Procesul potriveşte informaţiile din două baze de date: o bază de date de
adrese şi o referinţă către locaţia hărţii, astfel adresând informaţiile căutate cu
poziţia corectă pe hartă, prin coordonate latitudine-longitudine;
Referinţă lineară – datele din cadrul reţelelor de transport sunt măsurate în
funcţie de un punct fix de referinţă ales. Aceste metode includ distanţele
rutelor complete, coordonatele geografice şi coordonatele GPS (Global
Positioning System).
Segmentarea dinamică – această funcţie localizează un punct sau un segment
de linie prin interpolarea distanţelor dintre două puncte şi permiţând
înregistrarea informaţiei pe parcursul caracteristicilor lineare, de obicei
utilizând GPS.
Stratificare – Combinând două sau mai multe hărţi care au aceeaşi referinţă
geodezică. Hărţile digitale realizează stratificări (layouts) pe mai multe nivele
de date, integrându-le cu informaţii referitoare la alte entităţi.

Pe viitor, aplicaţiile orientate locaţie vor creşte numărul de informaţie
tridimensională, permiţând utilizatorilor să acceseze locuri distante având o experienţă
3D: „plimbarea” pe Fifth Avenue în Manhattan, „intrarea” în diferite magazine.

Toate aceste lucruri sunt posibile datorită avansului tehnologic din ultimii ani care
a oferit conexiuni puternice la Internet, plăci video, procesoare şi programe de
compresie îmbunătăţite pentru transferul masiv de date, procesarea acestora şi
managementul lor în spaţii tridimensionale.

Pentru crearea unei hărţi de succes este necesar să se ia în consideraţie audienţa.
Hărţile au avut mereu scopuri precise, de cele mai multe ori, acestea fiind accesul la
informaţie într-un mod vizual şi structurat.

Sisteme informaţionale geografice ca Google Maps sau Google Earth permit
computerului să perceapă informaţia având şi o componentă fizică, geografică şi să
poată astfel asocia date pentru respectiva locaţie. Google Maps pune la dispoziţie hărţi
şi imagini aeriale de pe întreaga planetă, oferind date despre instituţiile şi obiectivele
de atracţie a unei zone specificate. În plus, oferă posibilitatea de a crea aplicaţii care
combină informaţia geografică cu setul propriu de date pentru crearea de reprezentări
personalizate ale informaţiei de interes.

24

Această tehnologie poate fi folosită pentru multiple scopuri, cum ar fi obţinerea de
informaţie referitoare la:

Localizarea datelor: se pot afla toate restaurantele(sau orice alt fel de
instituţie) în jurul unei anumite locaţii;
Hărţi şi rute: se pot afla rute detaliate între două locaţii, care includ punctele
intermediare;
Reprezentări topografice: se oferă imagini detaliate ale unei locaţii putând afla
relaţia între un punct şi elementele înconjurătoare, cum ar fi un munte, un lac.
Date statistice: se pot descrie grafic date statistice (cum ar fi nivelul
populaţiei) printr-o hartă specializată.

Până acum, o componentă crucială lipsea din scenariul aplicaţiilor Web, şi anume
locaţia. Orice obiect este caracterizat de o anumită locaţie, care poate fi vizualizată
acum prin intermediul Google Maps, care ne pune la dispoziţie o interfaţă intuitivă,
imagini cartografice pregenerate şi un API prin intermediul căruia putem adăuga o
astfel de hartă pe orice pagină personală.

Utilizarea în Google Maps a tehnologiei AJAX ajută mult la succesul interfeţei şi
la rapiditatea interacţiunii cu utilizatorul. Un alt motiv este acela că datele
interschimbate între server şi navigator sunt de cele mai multe ori în format XML,
astfel încât toată informaţia vehiculată este accesibilă oricui. Google Maps, aplicaţii
bazate AJAX şi filozofia Web 2.0 în general fac parte din mentalitatea „View Source”
în care oricine poate să-ţi vizualizeze pagina, să înveţe din cod şi să încerce să
refolosească această informaţie în scopuri proprii.

GeoWeb este un termen relativ nou care implică îmbinarea informaţiei geografice
cu informaţia abstractă care se găseşte pe Internet. Astfel se creează un mediu de
lucru în care se pot căuta informaţii după locaţia pe care o au şi nu neapărat după un
anumit cuvânt cheie.

Succesul GeoWeb-ului este datorat noilor tehnologii şi produse ca Google Earth,
NASA World Wind, Windows Live Local, Yahoo Maps.

Sistemele GIS erau deţinute de către profesionişti experimentaţi şi utilizate în
organizaţii mari cum ar fi guverne sau municipalităţi. GeoWeb-ul promite de a
transforma informaţia geografică într-un concept mult mai ubicuu, deschizând accesul
către piaţa de masă. Una din ţintele GeoWeb-ului este aceea de a crea un mediu digital
care să oglindească propria realitate şi care să ne permită de a ne gestiona resursele,
găsind informaţii despre serviciile, oamenii din imediata vecinătate.

Geo Search, tradusă căutare la nivel geografic, are ca scop organizarea tuturor
informaţiilor ce au conţinut geografic şi transformarea acestora în conţinut accesibil şi
care poate fi folosit ulterior.

Una dintre avantajele acestui tip de căutare este acela că informaţia poate fi
indexată şi se pot realiza interogări la nivelul bazei de date ce conţine astfel de
informaţii. Standardele acceptate de Google Search conţin tipurile de formate KML
[26]
şi GeoRSS [40].

25

Geotagging este procesul de adăugare de meta-date geografice diferitelor pagini
Web, feed-uri RSS sau imaginilor. Aceste date cuprind coordonate de latitudine şi
longitudine, dar pot fi caracterizate şi de altitudine.

26

3.2 Formate de date
Pentru a realiza această sarcină există mai multe tipuri de formate de date ce pot fi
utilizate pentru găsirea sau crearea de conţinut cu relevanţă geografică, ca GML,
KML, GeoRSS, GPX, LOC, care fiind simple fişiere XML pot fi uşor parsate şi
refolosite în funcţie de necesităţi.

3.2.1 Geography Markup Language
Geography Markup Language (GML) [41] este un limbaj de modelare pentru sistemele
geografice utilizat şi ca format de schimb de date între tranzacţiile efectuate pe
Internet.

GML este standard-ul XML pentru infrastructura GeoWeb, permiţând
dispozitivelor conectate la Internet să acceseze informaţie geografică, incluzând, de
exemplu, locaţii ale unor anumite magazine sau condiţii de trafic. Aşa cum XML
permite Web-ului de a separa conţinutul de prezentare, GML oferă acelaşi lucru
pentru lumea geografică. Dacă GML este un limbaj ce codifică conţinut geografic prin
descrierea unui spectru de obiecte şi a proprietăţilor acestora (e.g. poduri, drumuri),
KML este un limbaj care permite vizualizarea informaţiei geografice.

Un exemplu de reprezentare a coordonatelor utilizând GML:

<gml:Point gml:id="p1" srsName="#srs1">
<gml:coordinates>45.67, 88.56</gml:coordinates>
</gml:Point>

3.2.2 Keyhole Markup Language
KML [26] foloseşte structură bazată pe etichete ce conţin elemente şi atribute
încapsulate bazate pe standardul XML.

KML, ca format de date, este folosit de Google Maps, Google Earth şi Google
Maps Mobile, şi este descris ca fiind „PDF-ul GIS-ului” (Brian McClendon). Este
realizat pentru a fi un format de fişier pachet, care să conţină sau să conecteze
resursele necesare afişării conţinutului descris de Google Earth.

KML este folosit pentru:

Specificarea de etichete şi pictograme pentru identificare locaţiilor;
Schimbarea poziţiei camerei pentru permiterea de vizualizări 3D;
Utilizarea de imagini suprapuse ataşate componentelor terestre sau
vizualizării;
Definirea de stiluri de afişare;
Integrarea de cod XHTML în cadrul descrierii unei locaţii;
Crearea structurilor ierarhice pentru grupuri de caracteristici;
Schimbări şi afişări de texturi şi obiecte 3D.

27

Un exemplu de fişier KML:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Placemark>
<name>Stonehenge, England</name>
<description>Stonehenge was built around 2500BC</description>
<Point>
<coordinates>-1.826752,51.179045,0 </coordinates>
</Point>
</Placemark>
</kml>

3.2.3 GeoRSS
RSS este un vocabular de meta-date, folosit pentru mediatizarea (syndication) a ştirilor
Web şi a schimbărilor survenite în cadrul sit-urilor. RSS face parte din familia XML şi
a fost adoptat pentru a distribui documente diverse, de la ştiri şi articole la date audio-
vizuale. În ultimii ani RSS a devenit protocolul de mashup prin excelenţă, datorită
simplităţii de utilizare.

GeoRSS (Geographically Encoded Objects for RSS feeds) [40] adaugă tag-uri
formatului RSS pentru a descrie date geografice. GeoRss a fost adoptat de Yahoo şi
Microsoft. GeoRss foloseşte ubicuitatea RSS şi schema GML pentru a crea cea mai
bună metodă de geo-distribuire (syndication). GeoRSS este folosit în GeoSearch şi
agregare.

GeoRSS este identificat prin spaţiul de nume "georss:" şi scufundate în fişiere RSS
normale, de exemplu:

<georss:point>43.127697 -77.573776</georss:point>

3.2.4 GPS eXchange Format
Printr-un receptor GPS (Global Positioning System) se pot determina locaţia, viteza şi
direcţia unui anumit obiect. GPS a devenit un ajutor pentru crearea de hărţi,
supravegherea zonelor, comerţ şi uz ştiinţific.

GPX (GPS eXchange Format) este un format XML proiectat pentru transferul
datelor GPS între aplicaţiile software. Este utilizat pentru a descrie puncte şi rute.
Deoarece GPX este bazat pe XML, acesta moşteneşte toate beneficiile acestuia. GPX
defineşte un set comun de tag-uri pentru descrierea datelor geografice şi GPS în XML.
Este un format simplu dar destul de puternic pentru a descrie obiecte complexe
geografice. GPX permite dezvoltatorilor să-şi definească propriile obiecte şi atribute.

Un exemplu:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<gpx xmlns="http://www.topografix.com/GPX/1/1" creator="byHand"
version="1.1" xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="http://www.topografix.com/GPX/1/1
http://www.topografix.com/GPX/1/1/gpx.xsd">

28

<wpt lat="39.921055008" lon="3.054223107">
<ele>12.863281</ele>
<time>2005-05-16T11:49:06Z</time>
<name>Cala Sant Vicenç - Mallorca</name>
<sym>City</sym>
</wpt>
</gpx>

3.2.5 Microformate
Microformatele sunt seturi de vocabulare pentru realizarea de adnotări semantice în
cadrul unor limbaje prezentaţionale, precum XHTML. Microformatele sunt uşor de
parcurs de către oameni, nefiind marcate de experţi ai domeniului, dar pot fi procesate
şi de către maşină.

Companiile mari ca Google, Yahoo, Microsoft utilizând sisteme necostisitoare ca
unelte GPS (Global Positioning System), au încurajat explozia marcării informatice
din cadrul Web-ului din ultimii ani. Dar tot acest timp a fost caracterizat de lipsa unui
standard, fiecare dintre companiile amintite dezvoltându-şi propriul fel de marcare al
datelor, Google utilizând KML (Keyhole Markup Language), un format XML, iar
Yahoo! utilizând GeoRss, o variaţie de RSS. Această lipsă de uniformitate a dus la
adoptarea de către dezvoltatori a diferitelor convenţii, cum sunt tagurile geo folosite
de către Flickr.

Astfel, au fost introduse microformatele geo şi adr.

3.2.5.1 Geo

Orice loc de pe planetă poate fi descris în mod unic utilizând latitudine şi longitudine.
Microformatul geo permite încapsularea acestor date în cadrul conţinutul unei pagini
Web. În cazul în care avem ca informaţie numai aceste coordonate, este preferabil de
folosit microformatul geo. În cazul în care deţinem informaţii mai detaliate despre
respectiva adresă, cum ar fi numele străzii, etc. este indicat de folosit microformatul
adr. Ambele microformate pot fi încapsulate microformatele compuse cum este
hCard.

Informaţiile turistice (jurnale de călătorie, informaţii meteo, postări de blog sau
sit-uri de turism comerciale) sunt menite a fi descrise cu geo, la fel şi evenimentele
istorice în care locaţia joacă un rol important. Locaţia este o componentă importantă şi
fenomenul de utilizare a acesteia este încontinuă creştere datorită aplicaţiilor ca
Google Maps, Yahoo Maps sau mashup-urilor ce au la bază hărţi.

În geo, elementul rădăcină conţine două proprietăţi, fiecare fiind un element
XHTML: unul pentru latitudine şi unul pentru longitudine. Latitudinea şi longitudinea
trebuie să fie exprimate în format decimal, sau grade decimale. De exemplu:

<span class="geo">
<span class="latitude">27.976628</span>,
<span class="longitude">86.933302</span>
</span>

29

Succesul unui mashup ţine de deţinerea de informaţie ce poate fi interpretată de
către maşină pentru a putea interacţiona cu un serviciu de mapare. În prezent, există
un număr de formate de Geo-date asemănătoare, ca KML sau GeoRss, dar acestea nu
sunt larg adoptate. Simplitatea formatului Geo este un plus şi poate fi preferat de către
dezvoltatorii de aplicaţii.

3.2.5.2 Adr

Spre deosebire de Geo-date, adresele fizice sunt utilizate de mai mult timp, dar la fel
nu a existat nici un fel de mod standardizat de a introduce aceste informaţii în cadrul
paginilor Web.

De obicei, adr este componentă a microformat-ului hCard şi poate să conţină
următoarele câmpuri:

post-office-box;
extended-address;
street-address;
locality;
region;
postal-code;
country-name.

Şablonul de clasă necesită utilizarea atributului class şi precizarea atributelor
prezentate. De exemplu:

<div class="adr">
<div class="street-address">2560 Ninth Street </div>
<div class="extended-address">Suite 219</div>
<span class="locality">Berkeley</span>,
<span class="region">CA</span>
<span class="postal-code">94710</span>
<div class="country-name">USA</div>
</div>

30

4. Mashup
"We know we don't have a corner on creativity. There are creative people all around
the world, hundreds of millions of them, and they are going to think of things to do
with our basic platform that we didn't think of." Vint Cerf

4.1 Aspecte generale
Unul din conceptele promiţătoare ale Web-ului 2.0 este acela de a divide informaţia în
părţi de dimensiuni reduse, slab conectate, astfel încât să putem reduce complexitatea
aplicaţiilor şi efortul de integrare.

Avem sute de API-uri disponibile pentru reutilizare şi integrare în noile noastre
aplicaţii Web, permiţându-ne realizarea unui întreg mai valoros decât suma
componentelor sale.

Un mashup este o aplicaţie Web hibridă, ce combină în mod agil diverse date din
surse externe într-o formă unitară şi mai complexă. Sursele externe sunt de obicei alte
aplicaţii Web, servicii Web sau RSS feed-uri.

Figura 4.1: Mashup, aplicaţie ce încapsulează servicii

Pentru a putea crea un mashup este nevoie de combinarea datelor din minim două
surse externe, pentru a realiza un serviciu care nu este disponibil dintr-o altă sursă.
Astfel se pot combina servicii geospaţiale ca Google Maps sau Yahoo Maps, cu alte
informaţii despre produse, acţiuni, evaluări din surse ca Amazon sau eBay.

Se recomandă utilizarea unui număr rezonabil de servicii Web pe care un mashup
le foloseşte şi mai ales „seriozitatea” acestor servicii, pentru că ele stau la baza
funcţionării şi succesului aplicaţiei respective.

Mashups-urile se bazează pe interacţiunea cu utilizatorul pentru personalizarea şi
utilitatea informaţiilor afişate.

31

Reutilizarea de software a devenit un crez al industriei IT şi acesta este unul din
motivele pentru care mashup-urile sunt atât de fascinante.

Unul din conceptele Web 2.0 este acela de a încuraja dezvoltatorii de a-şi
încapsula aplicaţiile ca un set de servicii ce pot fi folosite ulterior. Această teorie
susţine valoarea pe care un dezvoltator poate să o aducă comunităţii dacă software-ul
creat de acesta poate fi refolosit în noi modalităţi.

Un alt aspect de succes este utilizarea tehnologiei Ajax şi a formatelor de date
JSON, RSS. O bună aplicaţie Ajax încarcă o dată scripturile JavaScript în cadrul unui
navigator Web şi apoi manipulează conţinutul prin CSS şi HTML pentru a obţine
efectele vizuale scontate.

Figura 4.2: Anatomia Mashup, prezentarea nivelelor [10]

32

4.1.1 Tipuri de Mashup
Există două tipuri principale de mashup-uri:

Mashup-uri client: în care codul şi datele sunt combinate în cadrul unei pagini
folosind incluziuni JavaScript. Un avantaj al acestui model de dezvoltare este
portabilitatea pe care o oferă.
Mashup-uri server: ce oferă o infrastructură de programare mult mai puternică
şi completă.

Aceste tipuri principale se împart în cinci stiluri de dezvoltare, care stratifică modul
de utilizare al informaţiei şi elementelor vizuale în multiple nivele [10]:

Mashup de prezentare: este cea mai superficială formă de mashup, informaţia
fiind pur şi simplu extrasă şi prezentată. Nu este adăugat nici un fel de
funcţionalitate. În această categorie se înscriu portalurile şi alte forme de
prezentare de genul mashup.
Mashup de date la nivelul clientului: informaţiile preluate de mashup provin
din surse ca servicii Web, feed-uri sau sit-uri HTML şi sunt combinate cu date
provenite din alte surse. Se generează informaţie nouă care nu exista înainte,
cum ar fi locaţii specifice vizualizate în cadrul unei hărţi.
Mashup de software la nivelul clientului: în acest caz este integrat cod în
navigator cu scopul de a realiza o funcţionalitate nouă.
Mashup de software la nivel de server: la acest nivel fiind mai uşoară
combinarea serviciilor neexistând restricţii de securitate sau probleme de acces
între domenii diferite.
Mashup de date la nivel de server: care utilizează date din baze de date aflate
pe server, facilitând transferul de informaţie provenit din furnizori distincţi.

Figura 4.3: Diferenţă mashup la nivel de navigator şi la nivel de server [8]

33

4.1.2 Provocări, Beneficii, Neajunsuri
Asemeni Web 2.0, mashup-urile sunt rezultatul direcţiei actuale a tehnologiilor, fiind
caracterizate de conectivitate sporită, viteză de dezvoltare, consum de informaţie
generată utilizator, suport din partea comunităţilor online, îmbunătăţind rapid
informaţia găsită pe Internet.

Astfel, mashup-urile devin din ce în ce mai mult orientate către utilizatorul final şi
facilităţile oferite devin din ce în ce mai sofisticate.

Criteriile care trebuie să fie luate în considerare în crearea unui mashup sunt:
unicitate, creativitate, experienţa utilizatorului, utilitate şi conţinut.

Aspecte cheie şi beneficii ale abordării Mashup:

Combinarea eficientă între componente Web reutilizabile şi SOA. Mashup-
urile sunt construite din componente şi servicii deja existente în alte aplicaţii
Web, fiind adăugat cod pentru a integra aceste părţi într-un tot unitar. Această
reutilizare este benefică şi se caracterizează prin „building on the shoulder’s of
giants.”
Simplitate în dezvoltare şi integrare. Concentrându-se asupra formatelor şi
tehnicilor lightweight, mashup-urile au succes datorită simplităţii de
dezvoltare. Mashup-urile folosesc feed-uri şi XML pentru a conecta
componentele, structuri şi incluziuni JavaScript utilizate pentru integrarea de
elemente externe, ca Google Maps sau player YouTube. Mashup-urile devin
astfel Software as a Service (SaaS), având nevoie doar de un navigator Web şi
a adresă URL şi eliminând necesitatea unei instalării, a update-urilor, plug-in-
urilor sau drepturilor de administrator.
Focus pe auto-dezvoltare. Mashup-urile sunt disponibile dezvoltării şi de către
utilizatori neexperimentaţi, cât şi de dezvoltatori de software profesionişti. Ca
toate componentele Web care oferă puterea de publicare şi participare oricărui
utilizator, mashup-urile prezintă potenţialul de a creare software inovator şi
folositor. Se pot dezvolta aplicaţii de către un utilizator sau un grup de
colaboratori care să ofere exact facilitatea de care aceştia aveau nevoie.
Există şi alte beneficii ca: faptul că sunt orientate Web, tind să fie mai deschise
şi transparente în privinţa schimbului de informaţie şi oferă sursele oricui este
interesat de acest lucru.

O provocare este conflictul dintre cele două modele de mashup-uri, cele
dezvoltate de utilizatori şi cele dezvoltate de companii pentru uz comercial. Există în
jur de 2000 de dezvoltatori independenţi (conform ProgrammableWeb.com [30]) care
îşi utilizează blog-urile, profilurile sau alte pagini Web pentru a crea noi mashup-uri,
widget-uri sau gadget-uri. Pe lângă aceştia există un număr în creştere de produse
comerciale care încercă să aducă utilitatea mashup-urilor în cadrul Web-ului sau a
intranet-ului. Aceste două modele sunt diferite una faţă de cealaltă. Prima încurajează
fenomenul natural de reutilizare, folosind componente Web furnizate de alţi
distribuitori şi încercând să aplice acestora diferite strategii, găsindu-o pe care se
potriveşte scopului iniţial. Modelul comercial încearcă să adauge instrumentelor pe
care le oferă funcţionalităţi care lipsesc, cum ar fi securitate, suport pentru local SOA,

34

sau interfaţă vizuală pentru a facilita procesul de creaţie şi pentru cei care nu au
cunoştinţe de programare. Modelul comercial de cele mai multe ori ignoră vasta
colecţie de îmbunătăţiri adusă de utilizatori, lucru pe care aplicaţiile de succes ar
trebui să-l aibă în vedere

Un neajuns este reprezentat de numărul de servicii Web disponibile care să
permită accesul la date, în timp ce numărul de API-uri este în continuă creştere.
Majoritatea informaţiei o găsim în pagini statice în format HTML. Un ajutor îl oferă
formatul adiacent Web 2.0, RSS.

Cerinţe pentru realizarea de unelte mashup eficiente:

Uşurinţă în folosire: Un adevărat succes ar avea uneltele de mashup care ar
permite utilizarea lor persoanelor fără cunoştinţe de programare, în cadrul
oricărui navigator Web, în orice limbă.
Încapsularea şabloanelor în dezvoltarea de software. Utilizatorii finali nu sunt
dezvoltatori şi astfel nu înţeleg multe aspecte ale dezvoltării. Acestea includ
testare, controlul versiunilor, securitate, scalabilitate şi reliabilitate. Cea mai
bună unealtă mashup va avea grijă de aceste probleme automat şi nu va sta în
calea utilizatorilor în procesul de dezvoltare.
Suportul pentru standarde deschise. Aplicaţiile create de către uneltele mashup
trebuie să fie aplicaţii Web obişnuite bazate pe formate deschise şi nu
proprietare. Mashup-urile ar trebui alcătuite din componente HTML actuale,
JavaScript, CSS şi orice alte componente Web necesare. Web-ul este în
continuă expandare şi popularitate deoarece este un „sistem fără proprietar” ce
oferă transparenţă.
Utilizarea de părţi vizuale şi servicii Web. Începând cu snippet-uri JavaScript,
servicii orientate Web ca REST şi arhitectură orientată servicii ca SOAP, şi
continuând cu formate ca RSS sau ATOM, uneltele mashup trebuie să suporte
cea mai mare arie de ingrediente. Generarea oricărei aplicaţii într-un serviciu
care poate fi utilizat în cadrul unui mashup, oferă uşurinţa de consum ce ar
trebui suportată de orice unealtă de acest gen.
Încurajarea utilizării sociale pentru realizarea de sisteme puternice, care să
permită funcţionalitate de propagare de legături, invitaţii, feedback, etc.

35

4.2 Studiu de caz: GeoLink
4.2.1 Concept
Travel 2.0 reprezintă extensia şi personalizarea conceptului de Web 2.0 pe una dintre
cele mai puternice industrii actuale: turismul. Ca multe alte industrii, industria
turismului online este în tranziţie, adaptându-se noilor tehnologi şi direcţii din
Internet. Turiştii devin din ce în ce mai interesaţi în găsirea de recenzii, comentarii şi
sfaturi profesioniste cu referire la locaţii posibile. Acest lucru a oferit un impact
semnificativ acestui sector economic, turismul ocupând un loc de frunte în comerţul
online. Industria de travel online se împarte în mai multe categorii, cuprinzând: agenţi
online, ghiduri online, planificatoare de călătorie, comunităţi şi forum-uri online.

Travel 2.0 defineşte transformarea ofertelor în pachete online pentru a da
consumatorului un nou nivel de funcţionalitate şi putere. Travel 2.0 ca şi componentă
a Web 2.0 deţine următoarele caracteristici:

Transparenţă în date, preţuri, conţinut, imagini: sunt disponibile toate
informaţiile referitoare la o anumită locaţie;
Colaborare între utilizatori: pentru uşurinţa schimbului de date şi posibilitatea
de găsire de informaţii personalizate (recomandări, fotografii, etc.) de la toate
categoriile de utilizatori;
Viteză: în însuşirea conţinutului informaţional, datorită motoarelor de căutare
actuale;
Informaţie predictivă: asupra utilizatorului, oferindu-i exact datele de care
acesta are nevoie în funcţie de propriul profil.

Astfel, cel mai important aspect al turismului online este încrederea şi utilizarea
conţinutului generat utilizator. Cu cât mai mulţi utilizatori folosesc un anumit
serviciu, cu atât acesta devine mai de încredere.

Aplicaţia GeoLink se încadrează în curentul Travel 2.0 punând la dispoziţie
utilizatorilor o modalitate de realizare şi documentare a traseelor turistice.

La ora actuală, majoritatea consumatorilor decid asupra locaţiilor pe care doresc a
le vizita în funcţie de reviziile altor consumatori. GeoLink permite realizarea de hărţi
personalizate care pot fi apoi distribuite prietenilor şi cunoscuţilor.

Scopul aplicaţiei este acela de a permite utilizatorului de a marca puncte de interes
şi trasee turistice adăugând plus de informaţie. Aceste hărţi pot fi apoi distribuite ca
ghiduri turistice, ce conţin comentarii şi legături către sit-uri informative, ştiri, video
şi imagini. Încadrarea acestor date în conţinutul unei hărţi are un impact mai mare
decât simpla vizualizarea a datelor în cadrul unor tabele.

Navigatorul permite crearea de bookmarks ale site-uri de interes. Această aplicaţie
permite acelaşi lucru, dar pentru locaţii reale din jurul lumii. Utilizând această
aplicaţie, utilizatorul poate gestiona locuri pe care doreşte să le păstreze, viziteze sau
împărtăşească cu alţii.

36

4.2.2 Analiză şi Proiectare
S-a dorit realizarea unei aplicaţii intuitive, uşor de folosit, puternice, care să permită
utilizatorilor introducerea de informaţii în cadrul unei hărţi. Aplicaţia poate servi
pentru crearea de trasee turistice, realizarea de semne de carte cu reprezentare
geografică, crearea de scenarii de desfăşurare a activităţilor sau pentru publicitate, în
cazul în care se doresc introduse legături şi comentarii despre obiective comerciale.

Datorită sutelor de API disponibile dezvoltatorilor, aplicaţiile acestora pot fi
îmbogăţite cu componente avansate, logice sau de interfaţă, reutilizând tehnologia
disponibilă în loc să o reinventeze şi bazând noile proiecte pe experienţa anterioară.
Mashup permite utilizarea de astfel de „rotiţe” iar comunitatea Open Source pune la
dispoziţie exemple de utilizare de cod preexistent, realizând din procesul de
dezvoltare un proces rapid, simplu şi mai puţin costisitor.

Cerinţa ca o aplicaţie să fie publică nu este suficientă pentru a asigura
interoperabilitatea, fiind nevoie de o aplicaţie completă şi neutră. Utilizarea de
componente provenind de la furnizori diferiţi este o dovadă evidentă de neutralitate şi
se încadrează în spiritul Web 2.0.

O aplicaţie bazată JavaScript, nu este necesară instalare, fiind accesibilă în cadrul
unui navigator Web care are suport pentru JavaScript.

Rulând din cadrul navigatorului, aplicaţia devine independentă de platformă şi mai
rapidă, deoarece logica aplicaţiei este executată local utilizând JavaScript, oferind
răspuns fără întârziere şi crescând interactivitatea aplicaţiei.

Figura 4.4: Anatomia aplicaţiei GeoLink

37

Modelul facil de programare promovat de Google a dus la utilizarea acestuia în
multiple mashup-uri, Google Maps API fiind lider şi deţinând un procent de 50% de
utilizare, conform ProgrammableWeb.com [30]. Google oferă utilizatorilor încredere şi
credibilitate şi ca furnizor de componente mashup, aceste atribute sunt esenţiale
pentru a stabili relaţii de lungă durată cu clienţii săi.

Google Maps utilizează nativ tehnologia Ajax, utilizatorul nefiind nevoit să reîncarce
pagina, deoarece toate transferurile sunt realizate în fundal, ascunse de către acesta.
Conexiunea dintre client şi server este una dinamică, ce păstrează actualizarea datelor
într-un mod continuu.

Majoritatea mashup-urilor construite pe API-ul Google Maps doar plasează anumite
informaţii pe hartă, dar lasă puţină putere utilizatorului de a prelucra şi selecta sursele
externe utilizate. GeoLink permite personalizarea intrărilor, căutând informaţie
aferentă şi oferă o paletă diversă de categorii de puncte de interes ce pot fi adăugate
(asemeni legendelor). Informaţia introdusă este relaţionată din punct de vedere
geografic şi dispune de unelte pentru interogare, vizualizare şi analiză.

Motoarele de căutare au căpătat un rol vital în experienţa utilizatorului în cadrul sit-
urilor Web, simţindu-se acut inexistenţa acestui mod de navigare în cadrul aplicaţiilor.
Aplicaţia GeoLink utilizează Google Ajax Search API, ce pune la dispoziţie căutarea
de surse provenite din locaţii diferite şi permiţând dezvoltatorului de a aplica restricţii
asupra formatelor rezultatelor. Se pot adăuga informaţii referitoare la ştiri, articole,
imagini şi video, acest lucru diminuând timpul şi efortul căutării acestor date în surse
externe.

Descrierea aspectului, reprezentarea grafică a componentelor este determinată de
fişiere CSS care ajută la separarea conţinutului de prezentare, interfaţa fiind uşor de
modificat în cazul intervenţiilor viitoare. Google Maps şi Google Ajax Search pun la
dispoziţie clase speciale de formatare a datelor conţinute, iar Yahoo! UI Library aduce
plus de funcţionalitate controalelor HTML.

Accesul la server este realizat doar pentru salvarea hărţii şi exportul datelor introduse
în formatul geografic ales: kml sau gpx, având astfel un rol mai mult de stocare de
date, decât un rol de prelucrare.

Un dezavantaj al utilizării JavaScript cu preponderenţă este acela că aplicaţia fiind
dinamic generată la execuţie, conţinutul acesteia este inaccesibil motoarelor de
căutare. O soluţie este exportul informaţiei în format kml, format care poate fi indexat
de către Google. O altă întrebuinţare a formatului kml este utilizarea acestuia în cadrul
Google Earth, permiţând utilizatorului afişarea vizuală a informaţiei atât în mediu
online, cât şi offline.

Pentru a crea o nouă hartă nu este nevoie de a fi un utilizator autentificat. Legăturile
către hărţile personalizate sunt generate aleator, confidenţialitatea unei legături având
şanse de a fi compromisă prin încercări multiple.

Un alt posibil dezavantaj este necesitatea şi dependenţa faţă de cheia utilizator primită
pentru utilizarea API-urilor Google şi a licenţei care impune caracterul deschis şi
necomercial al aplicaţiei.

38

Spaţiul de lucru GeoLink consistă din cinci componente:

Harta – care redă informaţiile adăugate de utilizator;
Zona de unelte – care permite selectarea de elemente grafice ce doresc a fi
adăugate;
Salvare – permite denumirea hărţii create;
Zona de Help (Ajutor) – ce conţine un tutorial de folosire al aplicaţiei;
Zona de căutare – pentru adăugarea de legături.

Figura 4.5: Zonele de lucru GeoLink

4.2.3 Detalii de implementare
GeoLink este o aplicaţie JavaScript ce utilizează ca surse externe două API-uri
Google şi permite personalizarea informaţiei vizualizată pe hartă cu date preluate de
la utilizator (user generated content).

GeoLink este un mashup de software la nivelul clientului, ce utilizează pentru
partea de interfaţă Google Maps şi Yahoo! UI Library, iar pentru partea de date
Google Ajax Search şi conţinut utilizator.

API-ul Google Maps este la origine un API JavaScript care ne permite integrarea
de hărţi interactive direct în aplicaţiile noastre Web. Google Maps nu permite numai
vizualizarea de hărţi, ci şi interacţiunea cu anumite zone specifice, cum ar fi plasarea
unui cursor la o anumită locaţie pentru marcarea unui loc anume sau unei adrese.

Google Maps este suportat pe navigatoarele: Firefox 0.8+, Mozilla 1.4+, IE 5.5+,
Safari 1.2+, Netscape 7.1+, Opera 7+ şi din aprilie 2006 este în versiune 2 cu statutul
de Beta.

39

Pentru utilizarea acestui API este necesară o înregistrare anterioară pentru
obţinerea unei chei de acces utilizată pentru conectarea la serverul Google Maps.
Cheia poate fi folosită doar în cadrul unui domeniu şi este necesară adăugarea ei
pentru orice apel de API Google.

<script
src="http://maps.google.com/maps?file=api&v=2&key=..."
type="text/javascript"></script>

Inserarea unei hărţi în cadrul unei pagini se realizează prin apelul constructorului
GMap2(). Se pot adăuga controale standard, de exemplu controlul de nivel de zoom,
controlul de reprezentare dorit (imagini satelit, hibrid) sau controale definite utilizator.

if(GBrowserIsCompatible()){
document.map=new GMap2(document.getElementById("map"));
document.map.setCenter(new GLatLng(0,0),2);
document.map.addControl(new GLargeMapControl());
document.map.addControl(new GMapTypeControl());
document.map.addControl(new geolink.distance_control());
}

Spaţiul de nume GEvent este utilizat pentru înregistrarea de handlere de
evenimente şi pentru lansarea acestora în execuţie. Toate evenimentele definite cu
ajutorul acestui API sunt evenimente personalizate şi sunt declanşate intern utilizând
GEvent.trigger().

GEvent.trigger(geolink.poi_markers[i],"click");

Pentru înregistrarea evenimentelor se foloseşte metoda GEvent.addListener,
care transferă rezultatul apelului de funcţie către hartă. Evenimentele utilizate în
această aplicaţie sunt click, dragend, mouseover şi mouseout.

GEvent.addListener(document.map,"click",function(marker){
if(!marker){
geolink.handle_click(marker);
}
});

Aplicaţia gestionează două tipuri de puncte care pot fi adăugate: waypoint,
respectiv poi. Există funcţii de gestiune pentru fiecare dintre aceste puncte, diferenţa
fiind că waypoint sunt puncte componente ale rutelor, realizându-se calcule de
distanţă şi inserare de locaţii intermediare.

Punctele de pe hartă sunt păstrate în liste de obiecte, de genul:

geolink.waypoint_list[i]= [Object Lat=47.170151 Lng=27.583549
Text=Iasi Link= [["http://www.google.com/", "Google"]]]

Există liste pentru waypoint, cât şi pentru poi, ce conţin atât datele (_list), cât şi
referinţe ale obiectelor afişate pe hartă (_marker).

Uneltele sunt diferite şi în funcţie de tipul de punct selectat. Afişarea acestor
informaţii în format grupat este posibilă folosind metoda openInfoWindowTabsHtml.

40

YAHOO.util.Color. YAHOO.util.Event.addListener se ocupă de adăugarea de triggere
de evenimente pentru diferite componente.

Salvarea datelor conţinute de hartă este realizată prin utilizarea componentei
YAHOO.util.Connect.asyncRequest(method, uri, callback, postData),
unde:

method: metode de cerere către server(POST, GET, PUT, DELETE, ect.);
uri: calea către locaţia care receptează şi prelucrează datele;
callback: o referinţă către obiectul callback care este transmis;
postData: datele în format query-string ("new=1&old=2")

YAHOO.util.Connect.asyncRequest(
'GET', 'save.php', {
success: function(o) {
alert(o.responseText);
},
failure: function(o) {
alert('Request failed: ' +
o.statusText);
}
}
);

Pentru transmisia datelor în postData s-a folosit formatul JSON şi anumite metoda
toJSONString() pentru a putea serializa liste de colecţii de obiecte.
var postData=
"waypoints="+encodeURIComponent(geolink.waypoint_list.toJSONString())
;
postData+=
"&pois="+encodeURIComponent(geolink.poi_list.toJSONString());

Pe server se va genera noul fişier care conţine datele introduse şi se vor apela
funcţii speciale de afişare (prefixate în acest caz cu saved_) care vor extrage
informaţia din structurile geolink.waypoint_list, geolink.poi_list, etc.
geolink.waypoint_list = stripslashes($_POST['waypoints']);
geolink.waypoint_list[i]=
[{"Lat":47.170151,"Lng":27.583549,"Text":"Iasi","Icon":"yellow",
"Links":[["http://en.wikipedia.org/wiki/Ia%25C5%259Fi","Iasi -
Wikipedia, the free encyclopedia"]]}]

Odată ce harta generată este salvată pe server se vor genera şi fişierele .gpx şi
.kml. Salvarea se realizează utilizând PHP pe partea de server.

Generarea fişierului .kml se realizează prin adăugarea nodurilor existente pe hartă
şi a traseului generat de acestea. Ca informaţie specifică unui nod este introdus
numele, numărul de legături specifice şi conţinutul lor.
for(var i=0;i<geolink.waypoint_list.length;i++){
html +="<Placemark>n";
html +="<styleUrl>#waypoint</styleUrl>";
html +="<name>"+get_first_line(geolink.waypoint_list[i].Text)+"
("+(i+1)+" of "+geolink.waypoint_list.length+")</name>n";
html +="<description><![CDATA[<p>"+
geolink.waypoint_list[i].Text+"</p>";
if (geolink.waypoint_list[i].Links.length != 0){

42

html +="<p>Total of "+geolink.waypoint_list[i].Links.length+"
links: <ol>";
for(var j=0;j<geolink.waypoint_list[i].Links.length;j++){
html +="<li><a href='"+geolink.waypoint_list[i].Links[j][0]+
"'>"+geolink.waypoint_list[i].Links[j][1]+"</a></li>";
}
html +="</ol></p>";
}
html +="]]></description>n";
html +="<Point>n";
html +="<coordinates>"+geolink.waypoint_list[i].Lng+","
+geolink.waypoint_list[i].Lat+",0</coordinates>n";
html +="</Point>n";
html +="</Placemark>n";
}

Pentru fiecare punct salvat se vor genera microformatele geo şi xfolkentry care vor
putea fi vizualizate şi reutilizate cu extensiile Firefox Tails şi Operator. Pentru
aceasta sunt necesare coordonatele locaţiei, titlul, tag-ul şi adresa fiecărei legături:
for(var i=0;i<geolink.waypoint_list.length;i++){
var point= geolink.waypoint_markers[i].getPoint();
html+="<span
class='geo'>"+get_first_line(geolink.waypoint_list[i].Text)+": <span
class='latitude'>"+roundto(point.lat(),5)+ "</span>, <span
class='longitude'>"+roundto(point.lng(),5)+ "</span></span>";
for(var j=0;j<geolink.waypoint_list[i].Links.length;j++){
html+= "<div class='xfolkentry'> <a class='taggedlink' href='"
+geolink.waypoint_list[i].Links[j][0]+"'>"+
geolink.waypoint_list[i].Links[j][1]+"</a> <a rel='tag' href='/tag/"+
get_first_word(geolink.waypoint_list[i].Text)+
"'>Waypoint"+(i+1)+"</a></div>";
}
}

API-ul Google AJAX Search permite integrarea motorului de căutare Google în
cadrul unei pagini Web. Se poate încapsula o astfel de unealtă (search box) care să
permită realizarea de interogări şi afişarea rezultatelor în orice format.

API-ul Google AJAX Search este o librărie JavaScript ce pune la dispoziţie
obiecte pentru accesarea unui număr de servicii Google, cum ar fi Web Search, Local
Search, Video Search, Blog Search, News Search şi Book Search.

Google AJAX Search API este suportat pe navigatoarele: Firefox 1.5+, Safari,
Opera 9 şi IE 6. şi este la versiunea 1.0.

Pentru a putea integra controlul în aplicaţie trebuie identificate locaţiile în care
acestea vor fi plasata în cadrul documentului.

geolink.searchContainer = document.getElementById("searchContainer");
geolink.searchform = document.getElementById("searchform");

Crearea un control de search şi configurarea acestuia pentru a realiza interogări la
nivelul Video Search şi News Search se realizează folosind:
geolink.searchControl = new GSearchControl();
geolink.searchControl.addSearcher(new GnewsSearch());
geolink.searchControl.addSearcher(new GvideoSearch());

43

Se va configura modului de afişare, respectiv mod
grupat
(GSearchControl.DRAW_MODE_LINEAR, GSearchControl.DRAW_MODE_TABBED) şi
plasarea controlului în cadrul paginii.

var drawOptions = new GdrawOptions();
drawOptions.setDrawMode(GSearchControl.DRAW_MODE_TABBED);
geolink.searchControl.draw(geolink.searchContainer, drawOptions);

Se poate schimba şi modul de afişare al rezultatelor, acestea fiind vizibile parţial,
total sau deloc.

var webSearch = new GwebSearch();
var searcherOptions = new GsearcherOptions();
searcherOptions.setExpandMode(GSearchControl.EXPAND_MODE_OPEN);
geolink.searchControl.addSearcher(webSearch, searcherOptions);

Dacă se doreşte activarea capabilităţii de stocare a rezultatelor trebuie folosită
metoda setOnKeepCallback()care va transforma fiecare intrare accesată
în instanţe GResult.

geolink.searchControl.setOnKeepCallback( this, geolink.onKeep, "add
this to my place" );

Aceste obiecte conţin un număr de proprietăţi, inclusiv o reprezentare HTML care
poate fi clonată şi ataşată arborelui DOM.

var node = result.html.cloneNode(true);
var savedResults = document.getElementById("saved_results");
savedResults.appendChild(node);

Proprietăţile rezultatului unui obiect GwebSearch(), sunt de tip GwebResult şi
cuprind:

.unescapedUrl – forma brută a URL-ului;
.url – versiunea escaped a URL-ului iniţial;
.visibleUrl – o formă prescurtată a URL-ului, fără protocol şi cale;
.title – valoarea titlului;
.titleNoFormatting – valoarea titlului, dar care nu conţine marcaj HTML;
.content – informaţia asociată rezultatului respectiv.

În anumite situaţii se pot realiza restricţii pentru rezultatele întoarse, ca returnarea
legăturilor provenite numai de pe un anumit sit Web, sau primirea ca rezultatul numai
a unui format specificat de fişier.
var imageSearch = new GwebSearch();
imageSearch.setUserDefinedLabel("Images");
imageSearch.setQueryAddition("filetype:jpg");
geolink.searchControl.addSearcher(imageSearch);

Iniţializarea controlului de căutare şi execuţia unui căutări:
geolink.searchForm = new GSearchForm(false, geolink.searchform);
geolink.searchForm.setOnSubmitCallback(this, geolink.onNewSearch);
geolink.searchForm.execute("Google");

44

4.2.4 Utilizare
Utilizând GeoLink se pot:

Căuta puncte de interes care merită vizitate
Marca locaţii pe care utilizatorul le găseşte interesante de oriunde în lume
Adăuga comentarii personalizate asupra unei locaţii
Adăuga legături relevante pentru utilizator
Distribui conţinutul final

Paşi în crearea unei hărţi:

Căutarea unei locaţii ce se doreşte a fi adăugată. Localizarea se realizează folosind
geocoder-ul oferit de Google Map API, care translatează adresele în perechi
latitudine-longitudine;

Figura 4.6: Casetă de căutare locaţie

Explorarea hărţii utilizând nivelul de zoom dorit şi vizualizări specifice (Map,
Satellite, Hybrid). Există 19 nivele de Zoom disponibile navigării, încapsulate în
motorul Google Maps;

Figura 4.7: Google Maps integrat în GeoLink

Selectarea tipului de locaţie din zona de unelte. O locaţie poate fi un punct
intermediar în cadrul unei rute (waypoint) sau un punct de interes (POI);

45

Figura 4.8: Tipuri de puncte ce pot fi integrate

Adăugarea punctelor pe hartă la locaţiile alese. În cadrul rutelor se vor calcula
distanţele necesare parcurgerii traseului şi este posibilă schimbarea culorii liniei
de legătură între punctele intermediare;

Figura 4.9: Personalizarea traseului generat

Adăugarea de legături pentru o locaţie specifică folosind zona de căutare. Se pot
căuta informaţii din categorii ca Web, Ştiri, Video, Imagini. Adăugarea legăturilor
se realizează utilizând „Add this to my place”;

Figura 4.10: Integrare Google Ajax Search în GeoLink

Gestionarea legăturilor pentru locaţia respectivă. Cele mai recente intrări sunt
marcate diferit de legăturile deja existente;

46

Figura 4.11:Links Tab pentru o locaţie

Adăugarea de comentarii pentru o locaţie. Se consideră primul cuvânt ca fiind
tag-ul intrării, prima linie ca fiind titlul intrării. Aceste informaţii sunt utilizate
pentru crearea de microformate şi tooltip-uri integrate;

Figura 4.12: Comments Tab pentru o locaţie

Gestionarea punctelor rutei, având posibilitatea de a adăuga puncte intermediare,
şterge sau afla coordonatele locaţiei;

Figura 4.13: Tools Tab pentru o locaţie

47

Salvarea hărţii generate, alegând un nume care să identifice informaţiile
gestionate. O hartă trebuie să conţină măcar o locaţie introdusă;

Figura 4.14: Caseta de salvare pentru hartă

Distribuirea şi vizualizarea hărţii personalizate, fiind posibil şi exportul
informaţiilor în format KML sau GPX;

Figura 4.15: Informaţii referitoare la hartă

48

5. Concluzii
Pe parcursul acestei lucrări au fost prezentate principalele direcţii urmate de
evoluţia Web 2.0, în încercarea de a fundamenta principiile care stau la baza creării de
produse software online atât la nivel de reprezentare a resurselor, cât şi la nivel de
conţinut al acestora.
Un accent important a fost pus asupra inovaţiilor introduse de noile direcţii
Web, observându-se mai în detaliu fenomenul mashup care oferă perspective
nelimitate în ceea ce priveşte dezvoltarea generaţiei de aplicaţii interconectate.
Facilitarea exploatării eficiente a resurselor disponibile constituie principiul
fundamental aflat la baza celor mai noi tendinţe în evoluţia tehnologiilor
informaţionale. Măsura în care aceste tendinţe pot influenţa pozitiv aspecte ale vieţii
cotidiene a utilizatorilor, depinde integral de capacitatea de implementare concretă a
acestor direcţii de dezvoltare.
Satisfacerea utilizatorului reprezintă unul dintre scopurile cele mai greu de
atins, oferirea unei funcţionalităţi care să fie benefică unui spectru larg de folosire
fiind subiect de analiză îndelungată.
Crearea aplicaţiilor este facilitată de colaborarea masivă între dezvoltatori din
cadrul comunităţilor, de reutilizarea componentelor, realizând din Web un mediu aflat
într-un ritm accelerat de dezvoltare şi îmbunătăţire, ce are ca element central
utilizatorul.
Succesul aplicaţiilor Web este datorat avantajelor pe care acesta le pune la
dispoziţie dezvoltatorilor şi utilizatorilor. Aplicaţiile Web nu necesită instalare, nu
ocupă spaţiu, nu au nevoie de întreţinere explicită şi pot fi accesate de orice computer
conectat la Internet.

Direcţii Viitoare
În momentul concretizării unei idei, evoluţia trebuie privită ca un lucru
inevitabil şi implementarea trebuie să permită îmbunătăţirea permanentă a
elementelor componente, din punctul de vedere al utilizabilităţii şi al funcţionalităţii
oferite, asigurându-şi astfel continuitate. În acest moment, GeoLink, se află încă în
stadiu de dezvoltare, implementarea actuală având rolul de a exemplifica funcţionarea
unei soluţii mashup.

Evoluţia tehnologiilor Web va juca, de asemenea, un rol important în
implementările viitoare, dezvoltarea aplicaţiei având ca obiectiv exploatarea
îmbunătăţirilor în ceea ce priveşte interacţiunea cu utilizatorul şi performanţa.

Se doreşte transformarea aplicaţiei într-o aplicaţie colaborativă, care să
permită comunicarea şi interacţiunea între utilizatori prin vizualizarea şi modificarea
de hărţi ale persoanelor apropiate.

Pe termen scurt, preocupările privind continuarea dezvoltării GeoLink sunt
legate de îmbunătăţirea interfeţelor utilizator, de introducerea mai multor formate
geografice suportate, atât ca input, cât şi ca output.

49

Acronime
AJAX - Asynchronous JavaScript and XML
API - Application Programming Interface
CSS - Cascading Style Sheets
DOM - Document Object Model
GIS - Geographic Information System
GML - Geography Markup Language
GPS - Global Positioning System
GPX - GPS eXchange Format
HTTP - HyperText Transfer Protocol
JSON - JavaScript Object Notation
KML - Keyhole Markup Language
PHP - Hypertext Preprocessor
POI - Point Of Interes
REST - Representational State Transfer
RIA - Rich Interface Application
RPC - Remote procedure call
RSS - Really Simple Syndication
GeoRSS - Geographically Encoded Objects for RSS feeds
SaaS - Software as a Service
SOA - Service-oriented architecture
SOAP - Service Oriented Architecture Protocol
UDDI - Universal Description, Discovery and Integration
UI - User Interface
URI - Uniform Resource Identifier
URL - Uniform Resource Locator
W3C - World Wide Web Consortium
WSDL - Web Service Description Language
XACML - Extensible Access Control Markup Language
XHTML - Extensible HyperText Markup Language
XML - Extensible Markup Language
XSLT - Extensible Stylesheet Language Transformatins

50

Bibliografie
[1] Sabin Buraga, „Tehnologii Web”, Polirom, 2006;

[2] Lenuţa Alboaie, Sabin Buraga, „Servicii Web”, Polirom, 2006;

[3] Sabin Buraga, Lenuţa Alboaie, Sînică Alboaie, Sergiu Dumitriu, Marta Gârdea,
Diana Gorea, Sergiu Tauciuc, „Tendinţe actuale în dezvoltarea aplicaţiilor Web”,
Matrix Rom, 2006;

[4] Traian Anghel, „Introducere în AJAX”, Polirom, 2006;

[5] Rich Gibson, Schuyler Erle, „Google Maps Hacks”, O’Reilly 2006;

[6] John Allsopp, „Microformats: Empowering Your Markup for Web 2.0”, friendsof,
2007;

[7] Peter Forret, „Web 2.0 mememap overview“, 2005,
http://blog.forret.com/2005/09/web-20-mememap-overview/

[8] Dion Hinchcliffe, „Building Web 2.0: The two major styles of mashups”, 2006,
http://web2.socialcomputingmagazine.com/making_the_most_of_the_web_creating_g
reat_mashups.htm

[9] Dion Hinchcliffe, „The intangible aspects of mashups matter most“, 2006,
http://blogs.zdnet.com/Hinchcliffe/?p=29

[10] Dion Hinchcliffe, „Is IBM making enterprise mashups respectable?”, 2006,

[11] Dion Hinchcliffe, „The Web 2.0 is here”, 2005,
http://web2.socialcomputingmagazine.com/web2ishere.htm

[12] Dion Hinchcliffe , “Continuing an Industry Discussion: The Co-Evolution of
SOA and Web 2.0, 2006” ,
http://web2.socialcomputingmagazine.com/continuing_an_industry_discussion_the_c
oevolution_of_soa_and.htm

[13] Dion Hinchcliffe , ”Product Development 2.0” , 2007,
http://web2.socialcomputingmagazine.com/product_development_20.htm

[14] Dion Hinchcliffe, „RIA clients: Not just for the Web anymore”, 2006,
http://blogs.zdnet.com/Hinchcliffe/index.php?p=11

[15] Dion Hinchcliffe ,“Blogs, wikis, and Web 2.0 as the next application platform”,
2006 ,http://blogs.zdnet.com/Hinchcliffe/?p=50

[16] Dion Hinchcliffe, “Everyone as Co-Creators: Harnessing Collective Innovation
with Web 2.0”, 2006,

51

,http://web2.socialcomputingmagazine.com/everyone_as_cocreators_harnessing_colle
ctive_innovation_with.htm

[17] Dion Hinchcliffe, ““Enterprise 2.0″ as the example that proves the rule”, 2006,

[18] Dion Hinchcliffe, „Seven Things Every Software Project Needs to Know About
Ajax”, 2006,
http://web2.socialcomputingmagazine.com/seven_things_every_software_project_nee
ds_to_know_about_ajax.htm

[19] Dion Hinchcliffe, „Making the Most of the Web: Creating Great Mashups”,
2006,
http://web2.socialcomputingmagazine.com/making_the_most_of_the_web_creating_g
reat_mashups.htm

[20] Dion Hinchcliffe, „Some predictions for the coming ‘mashosphere’”, 2006,

[21] Dion Hinchcliffe, „Enterprise mashups: More about processes and less about
services?”, 2006, http://blogs.zdnet.com/Hinchcliffe/?p=61

[22] ***, „Ajax-Powered Google Maps Mashup”,
http://dev2dev.bea.com/pub/a/2007/05/google-mashups.html?page=2

[23] ***, Google Maps Official API Site, http://www.google.com/apis/maps/

[24] ***, Google Code, http://code.google.com/

[25] ***, Google Ajax Search API Site, http://code.google.com/apis/ajaxsearch/

[26] ***, Google KML, http://code.google.com/apis/kml/documentation/

[27] ***, Yahoo! User Interface Library, http://developer.yahoo.com/yui/

[28] ***, GPX, http://www.topografix.com/gpx.asp

[29] ***, http://www.wikipedia.org/

[30] ***, http://www.programmableweb.com

[31] ***, http://www.zdnet.com/

[32] ***, http://safari.oreilly.com/

[33] ***, http://developer.navteq.com

[34] ***, http://doug.ricket.com/geoweb/examples/

52

[35] ***,
http://www.lbschallenge.com/pdfs/Global%20LBS%20Challenge%20Official%20Rul
es%20EU%2006-07%20v4%20final.pdf

[36] ***, http://en.wikipedia.org/wiki/Web_2#Technology_overview

[37] ***, http://www.w3.org/TR/XMLHttpRequest/

[38] ***, http://tools.ietf.org/html/rfc4627

[39] ***,
http://developer.navteq.com/site/global/30_developingwnav/155_technical_library/co
re_map/attributes/p_attributes.jsp

[40] ***, http://georss.org/

[41] ***, http://schemas.opengis.net/gml/3.1.1/base/

53

Tehnici De Tip Mashup Pentru Interactiuni Web In Sisteme Informationale Geografice

More Related Content

Similar to Tehnici De Tip Mashup Pentru Interactiuni Web In Sisteme Informationale Geografice (20)

More from Ecaterina Moraru (Valica) (20)

Tehnici De Tip Mashup Pentru Interactiuni Web In Sisteme Informationale Geografice