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. 2.3.1 Aspecte generale 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 2.4.1 Aspecte generale 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, http://blogs.zdnet.com/Hinchcliffe/?p=49 [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, http://blogs.zdnet.com/Hinchcliffe/?p=62 [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, http://blogs.zdnet.com/Hinchcliffe/?p=13 [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

by Ecaterina Valica

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Tehnici De Tip Mashup Pentru Interactiuni Web In Sisteme Informationale Geografice Document Transcript