Dezvoltarea Aplicatiilor Web de Tip Single Page

ADNOTARE

Teza de master ”Dezvoltarea aplicațiilor web de tip single page” a studentului Zgureanu Tudor, grupa BD2, specialitatea Baze de date și cunoștințe.

Cuvinte-cheie: single page application, AJAX, aplicație web, web servicii.

Domeniul de studiu al tezei constă în cercetarea evoluției aplicațiilor web, componentele aplicației web moderne.

Ca obiective principale ale tezei pot fi menționate: studierea evoluției aplicațiilor web, studierea și descrierea părților componente ale unei aplicații web moderne, elaborarea unei aplicații web ce folosește componentele descrise în această teză.

Valoarea aplicativă a lucrării: cu ajutorul mai multor tehnologii și limbaje de programare a fost elaborată o aplicație web, folosind aceste tehnici de dezvoltare ale unei aplicații web moderne.

Teza cuprinde introducerea, patru capitole, concluzii cu recomandări, bibliografia din 14 titluri. Ea este perfectată pe 60 pagini, conține 14 figuri

În primul capitol sunt prezentate noțiunile de bază, evoluția aplicațiilor web, cât și unele avantaje față de aplicațiile desktop. Exemplele sunt însoțite de ilustrări schematice, pentru oferi o claritate sporită asupra principiului de lucru al aplicațiilor web.

În capitolul doi este prezentată prima parte componentă al unei aplicații web moderne, pe partea de server, web serviciile. Sunt descrise cele mai folosite tipuri de web servicii, prezentate avantaje și dezavantaje.

În capitolul trei, este prezentată cealaltă componenta al unei aplicații web moderne, partea de client, de la AJAX până la Single Page Application, beneficiile folosirii AJAX și dezvoltării aplicațiilor de tip Single Page, cât și provocări, dar care pot fi soluționate.

Capitolul patru însumează rezultatele obținute în urma studiului componentelor unei aplicații web moderne. Este prezentată o aplicație web, în care sunt folosite tehnici moderne de dezvoltare al unei aplicații web.

ANNOTATION

Master’s thesis "Development of single page web applications” student [anonimizat], BD2 group, specialized in databases and knowledge.

Keywords: Single page application, AJAX, web application, web services.

Domain of study of the thesis is researching web application development, modern web application components.

The main objectives of this thesis are: studing the evolution of web applications, presenting all the components of a modern web application, developing a web application that uses the components described in this thesis.

Value of the work: using multiple technologies and programming languages ​​has been developed a web application using the techniques of development of modern web applications.

The thesis consists of the introduction, four chapters, conclusions and recommendations, bibliography of 14 titles. It is written on 60 pages, containing 14 figures.

The first chapter presents the basic concepts, evolution of web applications and some advantages over desktop applications. Examples are accompanied by schematic illustrations to provide more clarity on the working principle of web applications.

The second chapter presents the first component of a modern web applications, on the server side – web services. It describes the most common types of web services, with the advantages and disadvantages.

In the third chapter, is presented the other component of a modern Web applications, the client side, from AJAX to Single Page Applications, the benefits of using AJAX and application development using Single Page model.

The fourth chapter summarizes the results of the study of the components of a modern web application. It’s presented a web application, in which are used modern techniques of web application development.

CUPRINS

TOC \o 1-3

ADNOTARE PAGEREF _Toc \h 1

ANNOTATION PAGEREF _Toc1 \h 2

CUPRINS PAGEREF _Toc2 \h 3

INTRODUCERE PAGEREF _Toc3 \h 4

Evoluția aplicațiilor web PAGEREF _Toc4 \h 6

1.1 Istoricul evoluției aplicației web PAGEREF _Toc5 \h 6

1.2 Concluzii PAGEREF _Toc6 \h 12

Web Servicii PAGEREF _Toc7 \h 13

2.1 Noțiuni de bază PAGEREF _Toc8 \h 13

2.2 Beneficii Serviciilor Web PAGEREF _Toc9 \h 15

2.3 Arhitecturi Web Servicii PAGEREF _Toc10 \h 17

2.4 Web Servicii SOAP PAGEREF _Toc11 \h 19

2.5 Web Servicii REST-ful PAGEREF _Toc12 \h 23

2.6 Concluzii PAGEREF _Toc13 \h 27

Programare client-side PAGEREF _Toc14 \h 29

3.1 AJAX PAGEREF _Toc15 \h 29

3.1.1 Prezentare AJAX PAGEREF _Toc16 \h 29

3.1.2 Obiectul XMLHttpRequest PAGEREF _Toc17 \h 32

3.1.3 Avantaje și dezavantaje PAGEREF _Toc18 \h 34

3.2 Single Page Application PAGEREF _Toc19 \h 36

3.2.1 Prezentare SPA PAGEREF _Toc20 \h 36

3.2.2 Provocări folosind modelul SPA PAGEREF _Toc21 \h 41

3.2.3 Beneficii folosind modelul SPA PAGEREF _Toc22 \h 44

3.3 Concluzii PAGEREF _Toc23 \h 44

Aplicația Weather PAGEREF _Toc24 \h 46

4.1 Descriere generală PAGEREF _Toc25 \h 46

4.2 Prezentarea funcționalităților aplicației PAGEREF _Toc26 \h 51

4.2.1 Pagina principală PAGEREF _Toc27 \h 51

4.2.2 Căutare localități PAGEREF _Toc28 \h 51

4.2.3 Prognoza în detalii PAGEREF _Toc29 \h 52

4.2.4 Prognoza zilnică PAGEREF _Toc30 \h 53

4.2.5 Ultimele căutări PAGEREF _Toc31 \h 54

CONCLUZII GENERALE ȘI RECOMANDĂRI PAGEREF _Toc32 \h 55

BIBLIOGRAFIE PAGEREF _Toc33 \h 57

INTRODUCERE

La început, web-ul a fost proiectat ca un mediu pur informațional, în prezent evoluând într-un mediu al aplicației. Aplicațiile web din zilele noastre devin din ce în ce mai rapide și complexe, oferind-ne servicii interactive și personalizabile. accesibile prin intermediul diferitor dispozitive; ele oferă posibilitatea realizării tranzacțiilor între utilizatori și de obicei păstrează datele într-o bază de date.

Aplicațiile web sunt populare ca urmare a omniprezenței browserelor web, cât și comodității folosirii unui browser web în rol de client. Capacitatea de a actualiza și menține aplicațiile web fără distribuirea și instalarea software-ului pe o mulțime de computere este motivul principal de care se datorează popularitatea lor, așa cum este suportul de compatibilitate pe o mulțime de platforme.

Am ales dezvoltarea aplicațiilor moderne single page ca obiect de cercetare, deoarece ea reunește cele mai noi tehnici de dezvoltare al unei aplicații web, ele ajută la organizarea arhitecturii aplicației cât și organizarea din punct de vedere al responsabilităților componentelor aplicației.

Așadar, scopul acestei lucrări este de a prezenta un concept modern, nou pentru dezvoltarea aplicațiilor moderne performante.

Teza cuprinde introducerea, patru capitole, concluzii și recomandări, bibliografia din 14 titluri. Ea este perfectată pe 60 pagini, conține 14 figuri.

În primul capitol sunt prezentate noțiunile de bază, evoluția aplicațiilor web, cât și unele avantaje față de aplicațiile desktop. Exemplele sunt însoțite de ilustrări schematice, pentru oferi o claritate sporită asupra principiului de lucru al aplicațiilor web.

În capitolul doi este prezentată prima parte componentă al unei aplicații web moderne, pe partea de server, web serviciile. Sunt descrise cele mai folosite tipuri de web servicii, prezentate avantaje și dezavantaje. În concluziile capitolului, este indicată alegerea mea ,ce privește tipul web serviciilor folosite în aplicația dezvoltată în cadrul tezei de master.

În capitolul trei, este prezentată cealaltă componenta al unei aplicații web moderne, partea de client, de la AJAX până la Single Page Application, beneficiile folosirii AJAX și dezvoltării aplicațiilor de tip Single Page, cât și provocări, dar care pot fi soluționate.

Capitolul patru însumează rezultatele obținute în urma studiului componentelor unei aplicații web moderne. Este prezentată o aplicație web, în care sunt folosite tehnici moderne de dezvoltare al unei aplicații web. Folosind aceste tehnici moderne de dezvoltare, mă aștept ca procesul de dezvoltare al aplicației să fie mai simplu, aplicația să fie organizată la nivel de arhitectură și cod. Aplicația este din domeniul meteorologic, oferă utilizatorilor posibilitatea de a vizualiza datele meteo în câteva formate: prognoza curentă, prognoza detaliată din 3 în 3 ore pentru câteva zile, și prognoza zilnică pe 14 zile. Designul interfeței este elaborată într-un mod cât mai simplu, astfel încât utilizatorii noi să se simtă cât mai confortabil cu această aplicație.

Evoluția aplicațiilor web

1.1 Istoricul evoluției aplicației web

Aplicațiile web moderne reprezintă niște sisteme software complexe, iar dezvoltarea acestora necesită o abordare metodologică a proiectării lor. Similar cu proiectarea aplicațiilor software, proiectarea aplicațiilor web implică utilizarea unei abordări similare pentru implementarea specificațiilor, funcționalităților cât și întreținerii acestor aplicații web de-o calitate cât mai înaltă.. Cerințele particulare ale proiectării aplicațiilor web rezultă din caracteristicile specifice din sfera produselor software, dezvoltării și utilizării acestora.

La început, web-ul a fost proiectat ca un mediu pur informațional, în prezent evoluând într-un mediu al aplicației. Aplicațiile web din zilele noastre sunt rapide și complexe, oferind-ne servicii interactive și personalizabile. accesibile prin intermediul diferitor dispozitive; ele oferă posibilitatea realizării tranzacțiilor între utilizatori și de obicei păstrează datele într-o bază de date. Elementul distinctiv al aplicațiilor web, față de aplicațiile desktop, este modul in care este utilizat web-ul: de exemplu tehnologiile și standardele sale sunt utilizate ca o platforma de dezvoltare și ca platforma utilizator in același timp.

O aplicație web reprezintă orice aplicație software care rulează într-un browser web sau este creat într-un limbaj de programare sprijinit de browser (cum ar fi o combinație de JavaScript , HTML si CSS ) și se bazează pe un browser web obișnuit pentru a utiliza aplicația.

Aplicațiile web sunt populare ca urmare a omniprezenței browserelor web, cât și comodității folosirii unui browser web ca un client. Capacitatea de a actualiza și menține aplicații web fără distribuirea și instalarea software-ului pe o mulțime de computere este motivul principal de care se datorează popularitatea lor, așa cum este suportul de compatibilitate pe o mulțime de platforme.

Această definiție include în mod explicit tehnologiile folosite dar și interacțiunea utilizatorului. De aici putem deduce că tehnologiile propriu-zise, la fel ca și serviciile web, nu sunt aplicații web, dar pot fi o parte al acestora. În plus, aceasta implică faptul că site-urile web lipsite de componente software, cum sunt paginile HTML statice, să nu fie considerate aplicații.

În modele anterioare de computing, de exemplu în client-server, responsabilitatea funcționalității aplicației a fost împărțită între codului de pe server și codul de instalat pe fiecare client local (computer). Cu alte cuvinte, o aplicație își avea propriul program de client care servea drept de interfața utilizatorului și trebuia să fie instalată separat pentru fiecare utilizator al computerului personal. Un upgrade la codul de pe partea serverului al aplicației, ar necesita, de asemenea, un upgrade pentru codul de pe partea de client instalat pe fiecare stație de lucru al utilizatorului, adăugând la suport costul și scăderea productivității .

În contrast, aplicațiile web folosesc documente web scrise într-un format standard, cum ar fi HTML și JavaScript , care sunt compatibile cu o varietate de browsere web. Aplicațiile web poate fi considerate ca o variantă specifică de software client-server, în care software-ul client este descărcat de mașina-client atunci când vizitează pagina web, utilizând proceduri standard, cum ar fi HTTP. Actualizările pentru software-ul client poate avea loc de fiecare dată când pagina web este vizitată. În timpul sesiunii, browser-ul web interpretează și afișează paginile, comportându-se ca un client universal pentru orice aplicație web.

Figura 1. Webul "static".

În primele zile ale web-ului fie upgrade pentru codul de pe partea de client instalat pe fiecare stație de lucru al utilizatorului, adăugând la suport costul și scăderea productivității .

În contrast, aplicațiile web folosesc documente web scrise într-un format standard, cum ar fi HTML și JavaScript , care sunt compatibile cu o varietate de browsere web. Aplicațiile web poate fi considerate ca o variantă specifică de software client-server, în care software-ul client este descărcat de mașina-client atunci când vizitează pagina web, utilizând proceduri standard, cum ar fi HTTP. Actualizările pentru software-ul client poate avea loc de fiecare dată când pagina web este vizitată. În timpul sesiunii, browser-ul web interpretează și afișează paginile, comportându-se ca un client universal pentru orice aplicație web.

Figura 1. Webul "static".

În primele zile ale web-ului fiecare pagina web în parte era livrată clientului ca un document static, dar secvența de pagini putea oferi o experiență interactivă, prin intermediul unui web formular, elemente căruia erau încorporate în markup-ul paginii.

În 1995, Netscape a introdus un client-side scripting limbaj numit JavaScript care permite programatorilor să adauge unele elemente dinamice pentru interfața cu utilizatorul care a fugit pe partea de client. Deci, în loc de a trimite date de la server, în scopul de a genera o întreagă pagina web, script-urile încorporate ale paginii descărcate pot efectua diferite sarcini, cum ar fi validare de intrare sau arată / ascunde părți ale paginii. În paralel, pe partea de server au apărut posibilități de generat paginile în mod dinamic, folosind server-side scripting (PHP, CGI). Deci, putem afirma această perioada ca începutul dinamizării webului, și apariției aplicațiilor web.

Figura 2. Primele aplicații web

În 1999, conceptul de "aplicație web" a fost introdus în limbajul Java (în Specificația Servlet versiunea 2.2). La acea vreme, atât JavaScript cât și XML au fost deja elaborate, dar Ajax încă nu era inventat, obiectul XMLHttpRequest era abia adăugat în Internet Explorer 5, dar sub forma unui obiect ActiveX. Totodată, sunt dezvoltate primele frameworkuri MVC pe web (de exemplu Apache Struts), astfel aplicația web devine mai complexă, structurată pe responsabilități.[1]

Figura 3. Aplicație web creată cu un framework MVC.

În 2005, a fost inventat termenul AJAX, și aplicații cum ar fi Gmail au început să dezvolte partea de client, făcând aplicația web mai interactivă și mai rapidă. Deja un script de pe pagina web este capabil să contacteze serverul pentru stocarea/primirea datelor, fără a descărca o întreagă pagina web. Însă la fel o mare parte din markup era oferit de către server, framework-urile MVC ofereau posibilitatea de a primi un anumit fragment de pagină, care era înlocuit cu fragmentul vechi.

În 2011, HTML5 a fost finalizat, oferă capabilități grafice și multimedia fără a fi nevoie de plugin-uri. HTML5 a îmbogățit, de asemenea, conținutul semantic al documentelor. API-urile și Document Object Model (DOM) nu mai sunt lăsate pe planul secund, ci sunt părți fundamentale ale specificației HTML5. WebGL API deschis calea pentru grafici 3D avansate bazate pe canvas-uri HTML5 și limbajul JavaScript. Acestea au o importanță semnificativă în crearea de aplicații web bogate independente de platformă sau browser web. AJAX deja ocupa un loc important în dezvoltarea aplicațiilor web moderne, aplicațiile web au un aspect din ce în ce mai apropiat cu aplicațiile desktop. Se utilizează intensiv manipularea DOM-ului pentru a crea o aplicație cât mai interactivă. Web serviciile devin părți componente din aplicații web.

În ultima perioadă, se încearcă mutarea funcționalității ce cine de vizualizare către partea de client, dezvoltându-se framework-uri JavaScript care funcționează în interiorul browserului. Serverul are un rol de suport de date, oferind API prin intermediul web serviciilor, astfel scăzând considerabil din presiunea pe care o avea într-o aplicație web.

Crearea unei aplicații web moderne, reprezentată printr-o schemă generală mai jos, este scopul final al acestei teze.

Figura 4. Aplicație dezvoltată cu MVC pe partea de client

1.2 Concluzii

În acest capitol ne-am făcut o impresie despre cum evoluează aplicațiile web, și cursul curent al evoluției, de la pagini web statice, la pagini generate în mod dinamic pe server, si mai apoi la dinamizarea client-side cu ajutorul JavaScript, în care serverul are doar un rol de suport de date, ceea ce scoate din presiune și îl face mai rapid.

Web Servicii

2.1 Noțiuni de bază

Un serviciu web (web serviciu) este o metodă de comunicații între două dispozitive electronice într-o rețea. Este o funcție software furnizat la o adresă de rețea pe web cu serviciul întotdeauna online. Conform W3C (World Wide Web Consortium), un serviciu web reprezintă un sistem software conceput pentru a sprijini interacțiunile interoperabile mașină-mașină într-o rețea. Acesta are o interfață descrisă într-un format machine-processable (în special WSDL ). Alte sisteme interacționează cu serviciul Web într-un mod stabilit de descrierea sa, folosind SOAP mesaje, de obicei transmise prin HTTP cu un XML serializare în conjuncție cu alte standarde legate de web.

De asemenea, putem identifica două clase majore de servicii Web:

Servicii Web RESTful-în care scopul principal al serviciului este de a manipula reprezentări XML de resurse web , folosind un set uniform de stateless operațiunilor

Servicii web arbitrare, în care serviciul poate expune un set arbitrar de operații.

Multe organizații folosesc sisteme software multiple de management. Diferite sisteme software de multe ori trebuie să facă schimb de date cu ele, și un serviciu web este o metodă de comunicare care permite două sisteme de software să facă schimb de aceste date pe internet. Sistemul de software care solicită date este numit un solicitant de serviciu, în timp ce sistemul de software-ul care va procesa cererea și furniza date este numit un furnizor de servicii .

Programe diferite pot fi construite folosind diferite limbaje de programare, și, prin urmare, este nevoie de o metodă de schimb de date, care nu depinde de un anumit limbaj de programare. Cele mai multe tipuri de software-ul poate, cu toate acestea, interpreta etichete XML. Astfel de servicii de web pot utiliza fișiere XML pentru schimbul de date.

Reguli de comunicare între diferite sisteme trebuie să fie definite, cum ar fi:

Cum un sistem poate solicita date de la un alt sistem

Care sunt necesare pentru parametrii specifici în cererea de date

Care ar fi structura datelor produse. În mod normal, datele sunt schimbate în fișiere XML, precum și structura fișierului XML este validat de un fișier xsd.

Ce mesaje de eroare vor fi afișate atunci când o anumită regulă de comunicare nu este respectată, pentru a face depanarea mai ușoară

Toate aceste reguli de comunicare sunt definite într-un fișier denumit WSDL (Web Services Description Language), care are extensia. WSDL.

Un directoriu numit UDDI (Universal Description, Discovery și Integrare), definește care sistemul de software ar trebui să fie contactat pentru ce tip de date. Deci, atunci când un sistem software-ul are nevoie de un anumit raport / date, s-ar merge la UDDI și de a afla ce alte sisteme se pot contacta pentru a primi aceste date. Odată ce sistemul de software afla ce alt sistem ar trebui să contacteze, se va contacta, atunci acest sistem, folosind un protocol special numit SOAP (Simple Object Access Protocol). Sistemul de furnizorul de servicii în primul rând ar valida cererea de date prin referire la fișierul WSDL, iar apoi procesa cererea și transmite datele în conformitate cu protocolul SOAP.

2.2 Beneficii Serviciilor Web

Deși există multe beneficii pentru afaceri, cum ar fi servicii îmbunătățite pentru clienții și partenerii, există, de asemenea, beneficii specifice pentru departamentul IT, care pot aduce economii de costuri mari și eficiență îmbunătățite.

Serviciile web oferă multe beneficii de peste alte tipuri de arhitecturi de calcul distribuit.

Interoperabilitatea – Acesta este cel mai important beneficiu al Web Serviciilor. Serviciile web de obicei, lucrează în afara de rețele private, oferind dezvoltatorilor o cale non-proprietate pentru soluțiile lor. Servicii dezvoltate sunt susceptibile, prin urmare, să aibă o durată de viață mai mare, oferind o mai bună rentabilitate a investiției de serviciu dezvoltat. Serviciile Web, de asemenea, permit dezvoltatorilor să utilizeze limba lor de programare preferate. În plus, datorită utilizării de metode de comunicare bazate pe standarde, Web Services sunt practic independente de platformă.

Usability – Serviciile Web permite business logica de multe sisteme diferite pentru a fi expuse pe Web. Aceasta oferă aplicațiile libertatea de a alege de Serviciile Web de care avem nevoie. În loc de a re-inventa roata pentru fiecare client, avem nevoie doar să includem business logica suplimentară specifică aplicației pe partea de client. Acest lucru ne permite să dezvoltăm servicii și / sau codul de client-side folosind limbile și instrumentele pe care le dorim.

Reutilizare – Serviciile Web nu oferă un model bazat pe componente de dezvoltare a aplicațiilor, dar cel mai apropiat lucru posibil la lansare zero-coding de astfel de servicii. Acest lucru îl face ușor de a refolosi componente de servicii web, după caz, în alte servicii. De asemenea, ea face ușor de implementat cod legacy ca un serviciu Web.

Lansare – Serviciile Web sunt implementate pe tehnologii standard de Internet. Acest lucru face posibilă lansarea serviciilor Web chiar peste firewall la serverele care rulează pe internet pe cealaltă parte a globului. De asemenea, datorită utilizării standardelor comunitare dovedite, care stau la baza de securitate (cum ar fi SSL) este deja built-in.

Pe lângă aceasta, web serviciile aduc beneficii și pentru afaceri:

Reducerea costurilor de tehnologie pentru dezvoltarea de noi produse.

Disponibil pentru toate dimensiunile de organizare și persoane fizice.

Low-cost, astfel încât toți partenerii și furnizorii mai mici pot fi acum integrate.

Permit accesul de la distanță la sistemele de afaceri atât de personal offsite sau clienții pot beneficia, de asemenea.

Ușor de utilizat pentru consumatori, servicii de web se poate conecta aplicații, servicii și dispozitive împreună (acționează la informații în orice moment, în orice loc și la orice dispozitiv inteligent).

Cu toate acestea, pe lângă avantaje, utilizarea serviciilor web au si dezavantaje:

Cu toate simplitatea de servicii Web este un avantaj în unele privințe, ea poate fi, de asemenea, un obstacol. Serviciile web utilizează protocoale de text simplu, care utilizează o metodă destul de detaliată pentru a identifica date. Acest lucru înseamnă că cererile de servicii web sunt mai mari decât cereri codificate cu un protocol binar. Mărimea adițională este de fapt doar o problemă de peste conexiuni de viteză redusă, sau prin conexiuni extrem de ocupat.

Deși HTTP și HTTPS (Protocoalele Web de bază) sunt simple, nu au fost într-adevăr a însemnat pentru sesiuni pe termen lung. De obicei, un browser face o conexiune HTTP, solicită o pagină Web și, poate, unele imagini, și apoi deconectează. Într-un CORBA tipic sau mediu RMI, un client se conectează la server și ar putea rămâne conectat pentru o perioadă lungă de timp. Serverul poate trimite periodic date înapoi la client. Acest tip de interacțiune este dificil de servicii Web, și aveți nevoie pentru a face un pic de lucru suplimentar pentru a compensa ceea ce HTTP nu face pentru tine. [9]

Problema cu HTTP și HTTPS atunci când vine vorba de servicii Web este că aceste protocoale sunt "stateless", interacțiunea dintre server și client este de obicei de scurtă durată și, atunci când nu există date fiind schimbate, server și client nu au nici o cunoaștere reciprocă. Mai exact, în cazul în care un client face o cerere la server, primește unele informații, și apoi imediat se blochează din cauza unei pene de curent, serverul nu știe că clientul nu mai este activ. Serverul are nevoie de o modalitate de a urmări ce face un client și, de asemenea, să determine când un client nu mai este activ.

De obicei, un server trimite un fel de identificator de sesiune la client atunci când clientul accesează prima dată serverul. Clientul folosește apoi acest identificator, atunci când se fac cereri suplimentare către server. Acest lucru permite serverului să reamintească orice informații pe care le are despre client. Un server trebuie să se bazeze pe un mecanism de regulă timeout pentru a determina că un client nu mai este activ. În cazul în care un server nu primește o cerere de la un client, după o perioadă predeterminată de timp, se presupune că clientul este inactiv și elimină orice informație despre client ce a fost păstrată. Acest exces înseamnă mai mult de lucru pentru dezvoltatorii de servicii Web.

2.3 Arhitecturi Web Servicii

La nivel conceptual, un serviciu este o componentă software furnizat printr-un obiectiv de rețea accesibilă. Servicii mesajele de consum și de a folosi furnizor de a face schimb de cerere invocarea și informații răspuns în formă de documente de auto-conținut, care fac foarte puține presupuneri cu privire la capacitățile tehnologice ale receptorului. La un nivel tehnic, servicii web pot fi implementate în diverse moduri. Cele două tipuri de servicii de web discutate în această secțiune pot fi distinse ca servicii web SOAP și servicii web REST-ful.

Web servicii SOAP

Aceste servicii web utilizează mesaje XML care urmează standardul Simple Object Access Protocol (SOAP), un limbaj XML care definește o arhitectură bazată pe mesaje mesaj și formatele mesajelor. Astfel de sisteme conțin adesea o descriere, care poate fi citită de mașină, a operațiilor oferite de către web serviciu, scris în Web Services Description Language (WSDL), un limbaj XML pentru definirea interfețelor punct de vedere sintactic.

Formatul mesajului SOAP și limba de definiție interfață WSDL au câștigat adoptarea pe scară largă. Multe instrumente de dezvoltare poate reduce complexitatea de dezvoltare a aplicațiilor de servicii web. [5]

Un design bazat pe SOAP trebuie să includă următoarele elemente.

Un contract formal ce trebuie să fie stabilit pentru a descrie interfața care serviciul web oferă. WSDL poate fi folosit pentru a descrie detaliile contractului, care poate include mesaje, operațiuni, legături, și locația serviciului web.

Arhitectura trebuie să abordeze cerințele nefuncționale complexe. Multe specificații de servicii web abordează astfel de cerințe și de a stabili un vocabular comun pentru ei. Exemplele includ tranzacții, securitate, abordarea, de încredere, de coordonare, și așa mai departe.

Arhitectura trebuie să se ocupe de prelucrare asincronă și invocare. În astfel de cazuri, infrastructura oferită de standarde, cum ar fi Web Services Reliable Messaging (WSRM), și API-uri, cum ar fi JAX-WS, cu suport de invocare asincronă pe client-side, pot fi extinse fără efort adițional.

Web Servicii RESTful

REST este foarte potrivit pentru scenariile de bază, ad-hoc de integrare. Serviciile web REST-ful, de multe ori mai bine integrate cu HTTP față de servicii bazate pe SOAP sunt, nu au nevoie de mesaje XML sau definiții WSDL service-API.

Pentru ca serviciile web REST-ful folosesc bine-cunoscutele standardele W3C și standardele Internet Engineering Task Force (IETF) (HTTP, XML, URI, MIME) și au o infrastructură ușoară, care permite serviciilor să fie construit cu instrumente minimale, dezvoltarea de serviciilor web RESTful este ieftin și are astfel o barieră destul de joasă pentru adoptare.

Un serviciu Web REST urmează, de obicei, patru principii de design de bază:

Utilizează metode HTTP în mod explicit.

Să fie fără stare (stateless).

Expune- URI-uri asemănător structurii directoriilor.

Transferă XML, JavaScript Object Notation (JSON), sau ambele.

2.4 Web Servicii SOAP

Principalele componente prin care se realizează definirea si transmiterea informației unui serviciu web SOAP sunt :

SOAP (Simple Object Acces Protocol) – este un protocol de comunicare proiectat pentru schimbul de informații structurate in implementarea serviciilor web in cadrul unei rețele de calculatoare. Structura sa este bazata pe XML (formatul mesajelor este definit în XML), și se bazează pe protocoale de aplicație, ca de exemplu HTTP sau SMTP (Simple Mail Transfer Protocol) pentru transmiterea mesajelor. Acest protocol este alcătuit din trei parți: un plic care definește ceea ce este in mesaj si cum poate fi procesat conținutul, un set de reguli de codificare (encoding) pentru a defini tipuri de date specifice aplicațiilor si o convenție pentru a reprezenta apelurile de proceduri si răspunsurile primite;

WSDL (Web Service Description Language) – este de asemenea un limbaj bazat pe XML si este folosit pentru descrierea funcționalității oferite de serviciul web. O descriere WSDL a serviciului web (fișier WSDL) pune la dispoziție o structura de date ce poate fi citita cu ușurință de un calculator, structura ce descrie modul in care serviciul web poate fi apelat, ce parametrii sunt așteptați la apel si ce tipuri de date sunt returnate după execuție.

UDDI (Universal Description, Discovery and Integration) – este un registru independent de platforma, bazat pe XML folosit pentru a înregistra si localiza servicii web definite in diverse aplicații. Specificațiile UDDI, create de companiile IBM, Microsoft, Ariba au ca obiectiv definirea unui mecanism comun pentru publicarea și căutarea informației prin servicii Web.

Dezvoltat de către în 1998, și numit "Simple Object Access Protocol" a fost proiectat ca fiind o platformă și o alternativă independentă de limbaje față de precedentele tehnologii gen CORBA și DCOM. Prima apariție publică a fost un draft publicat pe internet (transmisă către IETF) în 1999; la scurt timp după aceea, în decembrie 1999, SOAP 1.0 a fost lansat. În luna mai a anului 2000 a fost prezentată versiunea 1.1 către W3C, unde a format inima apariției tehnologiilor ulterioare pentru web servicii. Versiunea curentă este de 1,2, finalizat în 2005. [10]

Împreună cu WSDL și XML Schema, SOAP a devenit standardul pentru schimbul de mesaje bazate pe XML. SOAP a fost, de asemenea, proiectat de la zero pentru a fi extensibil, astfel încât alte standarde ar putea fi integrate în el – și au existat multe, adesea denumite colectiv ca WS-*: WS- Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS- Coordination, WS-AtomicTransaction, WS-RemotePortlets, și lista poate continua. Prin urmare o mare parte din complexitatea percepută de SOAP, la fel ca în Java, provine de la multitudinea de standarde care au evoluat în jurul său. Acest lucru nu ar trebui să fie un motiv de a fi prea preocupat: ca și alte lucruri, trebuie doar de utilizat ceea de ce este nevoie.

Structura de bază a SOAP este la fel ca orice alt format de mesaj (inclusiv HTML în sine): antet și corp. În SOAP 1.2 acest lucru ar arata în felul următor:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

<env:Header>

<!– Header information here –>

</env:Header>

<env:Body>

<!– Body or "Payload" here, a Fault if error happened –>

</env:Body>

</env:Envelope>

De reținut că elementul <header> este opțională aici, dar <body> este obligatoriu.

Elementul SOAP <Header>

SOAP folosește atribute speciale în standard "soap-plic", spațiul de nume care manipulează extensibilitatea elementelor care pot fi definite în antet. Cel mai important dintre acestea este atributul mustUnderstand. În mod implicit, orice element din antet poate fi ignorat în condiții de siguranță de către destinatarul mesajului SOAP, exceptând cazul în care atributul mustUnderstand al elementului este setat pe "true" (sau "1", care este singura valoare recunoscută în SOAP 1.1). Un bun exemplu ar fi un element de simbol de securitate care autentifică expeditorul / solicitantul mesajului. În cazul în care pentru un motiv oarecare destinatarul nu este capabil să proceseze aceste elemente, un defect ar trebui să fie livrat înapoi la expeditor, cu un cod de eroare de MustUnderstand.

Deoarece SOAP este conceput pentru a fi utilizat într-un mediu de rețea cu mai mulți intermediari (SOAP "noduri", cum au fost identificate de către elementul <Node>), definește, de asemenea, rolul atributelor XML speciale pentru a gestiona care intermediar ar trebui să proceseze un element de antet dat și indicator, care este folosit pentru a indica faptul că acest element trebuie să fie trecut la următorul nod dacă nu a fost prelucrat în cel curent.

Elementul SOAP <Body>

Acest element conține "payload"-ul a mesajului, care este definit de elementul <Message> al WSDL. Dacă există o eroare care trebuie să fie transmise înapoi la expeditor, un singur element <Fault> este folosit ca element copil al <body>.

Elementul SOAP <Fault>

<Fault> este elementul standard pentru procesarea erorilor. Când este prezent, reprezintă unicul element copil al elementului SOAP <Body>. Structura unei erori arată în felul următor:

<env:Fault xmlns:m="http://www.example.org/timeouts">

<env:Code>

<env:Value>env:Sender</env:Value>

<env:Subcode>

<env:Value>m:MessageTimeout</env:Value>

</env:Subcode>

</env:Code>

<env:Reason>

<env:Text xml:lang="en">Sender Timeout</env:Text>

</env:Reason>

<env:Detail>

<m:MaxTime>P5M</m:MaxTime>

</env:Detail>

</env:Fault>

În cazul de față, doar elemente-copil <Code> și <Reason> sunt necesare, elementul-copil <Subcode> al <Code> este, de asemenea, opțional. Conținutul elementului Code/Value este o enumerare fixă cu valorile:

VersionMismatch : aceasta indică faptul că nodul care "a aruncat" eroarea a găsit un element nevalid în plicul SOAP, fie un spațiu de nume incorect, nume local incorect, sau ambele.

MustUnderstand : acest cod indică faptul că un element de antet cu atributul mustUnderstand="true" nu a putut fi procesat de către nodul ce aruncă eroarea. Un bloc de antet NotUnderstood ar trebui să fie furnizat astfel încât să detalieze toate elementele din mesajul original, ce nu au fost înțelese.

DataEncodingUnknown : codificarea datelor specificate în plic de către atributul encodingSytle nu este suportat de către nodul ce aruncă eroarea.

Sender : Acesta este un cod "catch-all", care indică faptul că mesajul transmis nu s-a format corect sau nu dispune de informațiile corespunzătoare.

Receiver : Un alt cod "catch-all", care indică faptul că mesajul nu a putut fi procesat din motive imputabile către procesarea mesajului și nu al conținutul mesajului în sine.

Subcodurile, cu toate acestea, nu sunt limitate și sunt de aplicare definit; acestea vor fi de obicei definit atunci când codul de eroare este de Sender sau Receiver . <Reason> element este acolo pentru a oferi o explicație pe înțelesul tuturor a defectului. Opțional <Detail> element este acolo pentru a furniza informații suplimentare cu privire la vina, cum ar fi (în exemplul de mai sus), valoarea de timeout. <Fault> are, de asemenea, copii opționale <Node> și <Role> , indicând care nod aruncat vina și rolul pe care nodul a fost de operare în (a se vedea role atribut de mai sus), respectiv.

Un exemplu simplu SOAP

Punând toate împreună, mai jos este prezentat un exemplu simplu cerere-răspuns în SOAP. Transportul datelor se face prin intermediul HTTP.

Cererea:

GET /StockPrice HTTP/1.1

Host: example.org

Content-Type: application/soap+xml; charset=utf-8

Content-Length: nnn

<?xml version="1.0"?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"

xmlns:s="http://www.example.org/stock-service">

<env:Body>

<s:GetStockQuote>

<s:TickerSymbol>IBM</s:TickerSymbol>

</s:GetStockQuote>

</env:Body>

</env:Envelope>

Răspunsul:

HTTP/1.1 200 OK

Content-Type: application/soap+xml; charset=utf-8

Content-Length: nnn

<?xml version="1.0"?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"

xmlns:s="http://www.example.org/stock-service">

<env:Body>

<s:GetStockQuoteResponse>

<s:StockPrice>45.25</s:StockPrice>

</s:GetStockQuoteResponse>

</env:Body>

</env:Envelope>

În mod normal, mesajele SOAP nu vor fi vizibile; fiecare SOAP engine va face tot posibilul să ascundă acest conținut, cu excepția cazurilor în care dorim cu adevărat să vizualizăm aceste mesaje. În cazurile în care lucrurile nu merg în direcția corectă în web servicii, cu toate acestea, va fi util să știm conținutul mesajelor, în scopuri de depanare.

2.5 Web Servicii REST-ful

REST definește un set de principii arhitecturale prin care se poate proiecta servicii Web care se concentrează asupra resurselor de sistem, inclusiv modul în care stările resurselor sunt abordate și transferate prin HTTP de o gamă largă de clienți scrise în diferite limbaje. Dacă se măsoară prin numărul de servicii Web care îl utilizează, REST a apărut în ultimii ani numai ca un model de design de web servicii predominant. De fapt, REST a avut un impact mare asupra web-ului pe care le-a înlocuit în mare parte SOAP-ul și design de interfață bazată pe WSDL deoarece este un stil mult mai simplu de utilizat.

REST nu a atras atât de mult atenția atunci când a fost introdus pentru prima dată în anul 2000 de către Roy Fielding de la Universitatea din California, Irvine, în teza sa de doctorat academic, "Stiluri arhitecturale și proiectarea de arhitecturi software de rețea pe bază de,", care analizează un set de principii al arhitecturii software care folosește web-ul ca o platformă de calcul distribuit. Acum, după o lungă perioadă de la introducerea sa, framework-uri majore pentru REST au început să apară și sunt încă în curs de dezvoltare.

REST a fost descris inițial în contextul protocolului HTTP, dar nu este limitat la acesta. Arhitecturile REST pot avea la baza orice protocol de aplicație ce pune la dispoziție un vocabular bogat si uniform bazat pe transferul unei reprezentări a unei resurse. REST maximizează folosirea capabilităților și interfețelor deja existente și minimizează folosirea conceptelor si datelor specifice fiecărei aplicații. Practic prin intermediul modelului descris se transmite prin rețea doar informația brută (reprezentarea stării al unei resurse), cel mai des sub formă XML, JSON sau chiar YAML, iar fiecare punct din cadrul canalului de comunicare (client, service) este obligat sa interpreteze această informație sau să o alcătuiască.

Un design RESTful poate fi adecvat atunci când sunt îndeplinite următoarele condiții:

Serviciile web sunt complet stateless. Un test bun este de luat în considerare dacă interacțiunea poate supraviețui o repornire a serverului.

O infrastructură de caching poate fi extinsă pentru performanță. În cazul în care datele care se întorc de la serviciile web nu sunt generate dinamic și pot fi memorate în cache, infrastructura de caching ,care web servere și alți intermediari o oferă în mod implicit pot fi extinse pentru a îmbunătăți performanța. Cu toate acestea, dezvoltatorul trebuie să aibă grijă pentru că astfel cache-uri sunt limitate la metoda GET HTTP pentru cele mai multe servere.

Producătorul și consumatorul de servicii trebuie să aibă o înțelegere reciprocă a contextului și a conținutului propriu-zis. Deoarece nu există nici o modalitate formală de a descrie interfața de servicii web, ambele părți trebuie să convină schemele care descriu datele ce sunt inter-schimbate și cu privire la modalitățile semnificative de procesare. În lumea reală, cele mai multe aplicații comerciale, care expun servicii ca implementările RESTful distribuie, de asemenea, așa-numitele pachete de instrumente ce descriu interfețele pentru dezvoltatorii în limbaje de programare populare.

Lățimea de bandă este deosebit de importantă și trebuie limitată. REST este deosebit de util pentru dispozitive de profil limitat, cum ar fi PDA-uri si telefoane mobile, pentru care excesul de anteturi și straturi suplimentare de elemente SOAP în payload-ul XML trebuie să fie restricționate.

Furnizarea de servicii web sau de agregare în site-uri web existente pot fi activate cu ușurință cu un stil RESTful. Dezvoltatorii pot utiliza astfel de tehnologii ca JAX-RS și Asynchronous JavaScript cu XML (AJAX) și seturi de instrumente, cum ar fi Direct Web Remoting (DWR), să consume serviciile în aplicațiile lor web. În detrimentul scrierii serviciilor de la zero, serviciile pot fi expuse cu XML (sau alte formate) și consumate de pagini HTML fără restructurări semnificative a arhitecturii site-ului existent. Dezvoltatorii existenți vor fi mai productivi, deoarece aceștia lucrează la ceva ce sunt deja familiarizați, decât să înceapă ceva de la zero, cu o nouă tehnologie. [11]

Orice resursă are un identificator de resursă, cunoscut sub numele de URI (Uniform resource identifier). URI-urile pot fi clasificate în 2 subcategorii: locatori (URL) și nume (URN), sau ambele. Sintaxa URI constă din numele schemei URI (de exemplu: http, ftp, file, mailto) urmat de caracterul “:”, și apoi de partea specific schemei. Specificațiile care guvernează schemele determină sintaxa și semantica părții specifice schemei. Cu toate acestea, sintaxa URI are nevoie de toate schemele pentru a adera la o sintaxă generală care (printre altele) își rezervă anumite caractere pentru anumite scopuri (fără a identifica întotdeauna aceste scopuri). Sintaxa URI impune, de asemenea, restricții privind partea specifică schemei, pentru a (de exemplu) pentru a oferi un grad de consistență în cazul în care partea are o structură ierarhică.

Exemple de URI-uri absolute și relative:

http://example.org/absolute/URI/with/absolute/path/to/resource.txt

ftp://example.org/resource.txt

http://example.org/absolute/URI/with/absolute/path/to/resource.txt

//example.org/scheme-relative/URI/with/absolute/path/to/resource.txt

/relative/URI/with/absolute/path/to/resource.txt

relative/path/to/resource.txt

../../../resource.txt

În spațiul World Wide Web, sunt doar câteva acțiuni pe care le putem face cu o resursă. HTTP oferă patru metode de bază pentru cele mai comune operații:

Returnarea unei reprezentări a unei resurse: HTTP GET

Crearea unei noi resurse: HTTP PUT unui nou URI, or HTTP POST unui URI existent

Modificarea unei resurse: HTTP PUT unui URI existent

Ștergerea unei resurse: HTTP DELETE

Pentru a obține sau a șterge o resursă, clientul trimite o cerere de tip GET sau DELETE asupra URI-ului resursei. În cazul unei cereri GET, serverul returnează o reprezentare în corpul răspunsului. Pentru o cerere DELETE, corpul răspunsului poate conține un mesaj de stare, sau nimic.

Pentru a crea sau modifica resurse, clientul trimite o cerere PUT care, de obicei, include o entitate-corp. Entitatea-corp conține propunerea clientului pentru reprezentarea resursei. Ce fel de date alcătuiesc reprezentarea, și în ce format, depinde de serviciu.

Într-o arhitectură REST, POST este folosit pentru a crea resurse subordonate: resurse sunt în relație cu o altă resursă "părinte". De exemplu, pentru a crea o pagină wiki într-un spațiu XWiki, trimitem o cerere POST resursei părinte, care este spațiul.

Mai sunt două metode HTTP care pot fi folosite într-un serviciu web:

Returnarea unei reprezentări formată doar din meta date: HTTP HEAD

Verificarea metodelor HTTP suportate de o anumită resursă: HTTP OPTIONS

Pentru ca un serviciu web să fie RESTful nu trebuie să folosim interfața uniformă definită de HTTP. Metodele HTTP nu sunt cele mai potrivite de fiecare dată. Ceea ce contează este să alegem o interfață care să fie uniformă. Dacă avem un URI al unei resurse, știm cum să obținem reprezentarea: trimitem o cerere HTTP GET acelui URI. Interfața uniformă face ca două servicii să fie la fel de similare cum sunt două site-uri web. Fără interfața uniformă, ar trebui să aflăm cum fiecare serviciu web acceptă și transmite informații. Regulile ar putea fi diferite chiar și pentru diferite resurse dintr-un singur serviciu. Fără o interfață uniformă, am avea numeroase metode care ar lua locul lui GET: doSearch, getPage, nextPrime.

Câteva aplicații extind interfața uniformă HTTP. Cea mai cunoscută este WebDav, care adaugă opt noi metode HTTP, printre care MOVE, COPY și SEARCH. Dacă am folosi aceste metode într-un serviciu web nu am viola nici un principiu REST, pentru că arhitectura REST nu impune folosirea unei anumite interfețe uniforme.

2.6 Concluzii

În acest capitol au fost prezentate web serviciile, importanța lor cât și cele mai răspândite tipuri de web servicii.

Un serviciu web (web serviciu) este o metodă de comunicații între două dispozitive electronice într-o rețea. Este o funcție software furnizat la o adresă de rețea pe web cu serviciul întotdeauna online. Cele mai des întâlnite tipuri de web servicii sunt SOAP si RESTful.

Web serviciile SOAP folosesc WSDL ca limbaj descriptiv ale funcționalităților oferite de serviciul web. De cealaltă parte, web serviciile RESTful elimină această procedură, simplificând utilizarea lor. Tocmai de aceea, voi recurge la web serviciile RESTful în dezvoltarea aplicației mele.

Programare client-side

3.1 AJAX

3.1.1 Prezentare AJAX

În trecut, aplicațiile web erau limitate din punct de vedere al posibilităților, deoarece o pagină web trebuia să fie reîncărcată (sau o altă pagină încărcată în locul său), pentru ca noi date să fie obținute. Alte metode au fost disponibile (fără a încărca o altă pagină), dar tehnicile nu au fost susținute îndeajuns și aveau tendința de a fi defectuoase. În ultimul timp, o tehnică care nu a fost susținută pe scară largă în trecut, dar a devenit disponibil pentru un număr mare de utilizatori web, oferind dezvoltatorilor mai multă libertate de a dezvolta aplicații web de ultimă oră. Aceste aplicații, care preiau în mod asincron date XML, prin intermediul JavaScript, sunt cunoscută sub numele de "aplicații AJAX" (Asynchronous JavaScript și aplicații XML).

Ajax, sau Asynchronous JavaScript și XML, este o abordare de dezvoltare de aplicații web care folosește client-side scripting pentru a face schimb de date cu serverul web. Ca rezultat, paginile web sunt actualizate în mod dinamic fără o reîmprospătare completă a paginii sau fără a întrerupe fluxul de interacțiune. Cu Ajax, se pot crea interfețe mai bogate, mai dinamice care se apropie de iminența și de modul de utilizare al aplicațiilor desktop native. Ajax nu este o tehnologie, este mai mult un pattern – o modalitate de a identifica și descrie o tehnică utilă de design. Ajax este nou în sensul că mulți dezvoltatori sunt doar conștienți de existența lui, dar toate componentele care implementează o aplicație Ajax există de mai mulți ani.

Ajax este un termen inventat în 2005 de către Jesse James Garrett, care descrie o "nouă" abordare, utilizând un mai multe tehnologii existente împreună, inclusiv:

prezentare bazate pe standarde, folosind XHTML și CSS;

afișarea și interacțiunea dinamică, folosind Document Object Model ;

schimbul de date și manipularea lor, folosind XML și XSLT ;

obținerea datelor în mod asincron, folosind XMLHttpRequest ;

și JavaScript creează legătură intre aceste componente.

Atunci când aceste tehnologii sunt combinate în modelul Ajax, aplicații web sunt în măsură să facă, actualizări incrementale rapide la interfața utilizatorului, fără reîncărcarea întregii pagini al browserului. Acest lucru face ca aplicația să fie mai rapidă și mai receptivă la acțiunile utilizatorului [6].

Deși X în Ajax se referă la XML, JSON este folosit mai des față de XML, oferind mai multe avantaje, cum ar fi prelucrare mai simplă si fiind ca parte din JavaScript. Atât JSON și XML sunt folosite pentru împachetarea informațiilor în modelul Ajax.

Aplicațiile web tradiționale folosesc un sistem sincron în care trebuie să așteptăm serverul să trimită prima pagină a unui sistem înainte de a putea solicita o altă pagină, așa cum este arătată în figura următoare.

Figura 5. Aplicație web tradițională, sistem sincron.

După cum am menționat, folosind AJAX, aderăm la sistemul asincron, care este prezentat în figura ce urmează:

Figura 6. Aplicație AJAX, sistem asincron

3.1.2 Obiectul XMLHttpRequest

Inițial, Microsoft a proiectat XMLHttpRequest pentru a permite Internet Explorer (IE) să încărca documente XML cu ajutorul JavaScript. Chiar dacă are XML în numele său, XMLHttpRequest reprezintă în sine un client generic HTTP pentru JavaScript. Prin intermediul acestui obiect, JavaScript poate face cereri HTTP de tip GET și POST. (Pentru cereri POST, datele pot fi trimise la server într-un format definit.) Principalele limitări al obiectului XMLHttpRequest este cauzat de sandbox-ul de securitate al browser-ului. Se poate face numai HTTP (S) cereri (URL-uri pentru fișiere, de exemplu, nu va funcționa), și se pot face cereri doar pentru același domeniu în care paginile sunt încărcate în prezent.

Limitările de securitate ale obiectului XMLHttpRequest limitează modul în care poate fi folosit, dar compromisul de a avea un plus de securitate este bine meritat. Cele mai multe atacuri împotriva aplicațiilor JavaScript presupun injectarea de cod malițios în pagina Web. Dacă XMLHttpRequest ar permite cererilor de pe orice site Web, aceasta ar deveni un jucător important în aceste atacuri. Sandbox-ul de securitate reduce aceste potențiale probleme. În plus, se simplifică modelul de programare, deoarece codul JavaScript poate avea încredere implicit în orice date ce se încarcă cu un obiect XMLHttpRequest. Se poate avea încredere în date, deoarece noile date sunt la fel de sigure ca și pagina care a încărcat pagina inițială.

În ciuda faptului că XMLHttpRequest oferă doar un API redus și doar un număr redus de metode și proprietăți, are diferențe sale în diferite browsere. Aceste diferențe sunt în principal în manipularea evenimentelor și instanțierea obiectelor (in IE, XMLHttpRequest este de fapt un obiect ActiveX), astfel acestea nu prezintă un impediment în lucrul cu acest obiect.

XMLHttpRequest este metoda cea mai utilizată pentru comunicații AJAX, deoarece acesta oferă două caracteristici unice. Prima caracteristică oferă posibilitatea de a încărca conținut nou, fără ca conținutul să fie schimbat în nici un fel, ceea ce o face extrem de ușor pentru a se potrivi AJAX mediile de dezvoltare obișnuite. A doua caracteristică permite JavaScript să efectueze apeluri sincrone. Un apel sincron oprește orice alte operațiuni până când apelul devine complet, și în timp ce acest lucru nu este o opțiune ar fi demn de folosit de obicei, acesta poate fi util în cazurile în care cererea curentă trebuie să fie finalizată înainte de a trece la pasul următor.

Un exemplu AJAX simplu folosind o cerere HTTP de tip GET:

// Aceasta este un script pe partea de client

// Inițializarea unei cereri Ajax

var xhr=new XMLHttpRequest();

xhr.open('get', 'send-ajax-data.php');

// Manipulări în momentul în care starea cererii este modificată

xhr.onreadystatechange=function(){

// Această stare indică că cererea a fost efectuată

if(xhr.readyState === 4){

// 200 cererea efectuată cu succes

if(xhr.status === 200){

alert(xhr.responseText); // 'Date de pe server'

}else{

alert('Error: '+xhr.status); // O eroare cauzată în timpul cererii

}

}

}

// trimite cererea către send-ajax-data.php

xhr.send(null);

send-ajax-data.php:

<?php

// Acesta este un script php

// Setarea tipului conținutului

header('Content-Type: text/plain');

// Trimite datele către client

echo "'Date de pe server";

?>

3.1.3 Avantaje și dezavantaje

Deși există numeroase motive pentru a ne comuta la AJAX, există câteva aspecte care ar trebui de luat în reconsidere. Mai jos sunt prezentate câteva dintre avantajele și dezavantajele utilizării AJAX.

Avantaje:

O mai bună interactivitate
Acest lucru este cel mai mare motiv care face din ce în ce mai mulți dezvoltatori și webmasteri să treacă la AJAX în dezvoltarea site-urilor lor. AJAX permite interacțiunea mai ușoară și mai rapidă între utilizatori și site-ul, datorită faptului că paginile nu sunt reîncărcate pentru a afișa conținutul nou.

Navigare mai ușoară
Aplicațiile AJAX pe site-uri facilitează o navigare mai ușoară pentru utilizatori, în comparație cu utilizarea butonului tradițional back / forward din browser.

Compact
Cu AJAX, pot fi manipulate mai multe aplicații și caracteristici folosind o singură pagină web.

Susținut de branduri de renume
Un alt motiv care îndeamnă la folosirea AJAX în site-uri web este faptul că mai multe aplicații web complexe folosesc modelul Ajax, Google Maps este exemplul cel mai impresionant și evident. Pe lângă Google Maps, putem enumera GMail, Facebook, Twitter și lista poate continua la nesfârșit.

Dezavantaje:

Butoanele back / forward sunt inutile
Cu AJAX, dat fiind faptul că totul este încărcat pe o pagină în mod dinamică fără ca pagina să fie reîncărcată sau, mai important, fără ca un URL-ul să fi fost schimbat (cu excepția pentru un simbol hash poate), butoanele back sau refresh s-ar comporta în mod diferit față de modul în care noi sau utilizatorul se așteaptă. Acesta este principalul dezavantaj în folosirea AJAX, dar din fericire, această problemă poate fi remediată cu bune abilitați de programare.

Acesta este construit pe javascript
În timp ce JavaScript este sigur și a fost puternic folosit pe site-urile web pentru o perioadă lungă de timp, un procent suficient de web surferi site-ul prefera sa închidă funcționalitatea Javascript pe browser, făcând AJAX inutil, o posibilă soluție ar fi, ca dezvoltatorul să scrie în paralel o versiune non-javascript al paginii pentru a satisface dorința acestui grup de utilizatori.

3.2 Single Page Application

3.2.1 Prezentare SPA

Aplicații web single page – sau SPA-uri, întrucât acestea sunt frecvent menționate – devin rapid standardul de facto pentru dezvoltare aplicațiilor web. Faptul că o mare parte din aplicație rulează în interiorul unei singure pagini web, este foarte interesant și atrăgător, astfel creșterea accelerată a capacităților browser-ului web ne împinge mai aproape de ziua, când toate aplicațiile vor rula în întregime în interiorul browser-ului.

Din punct de vedere tehnic, cele mai multe pagini web deja sunt SPA; Complexitatea unei pagini diferențiază o pagină web de la o aplicație web. O pagină devine o aplicație odată cu includerea fluxurilor de lucru, operațiunile CRUD, și de gestionare de stări în jurul anumitor sarcini. O aplicație poate fi numită un SPA atunci când fiecare dintre aceste sarcini au loc pe aceeași pagină (folosind AJAX pentru comunicarea client / server, desigur).

Într-o aplicație web obișnuită, de fiecare dată când aplicația apelează server, serverul construiește o noua pagina HTML. Acest lucru declanșează o reîmprospătare a paginii în browser.

Într-un SPA, după ce prima pagină este încărcată, toate interacțiunile cu serverul se întâmplă prin apeluri AJAX. Aceste apeluri AJAX returnează date-nu markup-de obicei în format JSON. Aplicația utilizează datele JSON pentru a actualiza pagina în mod dinamic, fără a reîncărca pagina. Figura de mai jos ilustrează diferența dintre cele două abordări. [2]

Figura 7. Ciclu de viață aplicație web obișnuită și SPA

Un beneficiu al SPA este evident: cererile sunt mult mai fluide și receptive, fără efectul discordant de reîncărcare și rerendering al paginii. Un alt avantaj ar putea fi mai puțin evident și se referă la modul în care o aplicație web este proiectată. Trimiterea datelor aplicației în format JSON creează o separare între prezentare (HTML markup) și logica aplicației (cereri AJAX plus răspunsuri JSON).

Această separare face mai ușor pentru a proiecta și de a dezvolta fiecare strat. Într-un SPA bine proiectat, markup-ul HTML poate fi modificată fără a atinge codul care implementează logica de aplicare (cel puțin, asta e idealul). [7]

Într-un SPA pur, toate interacțiune UI au loc pe partea de client, prin intermediul JavaScript și CSS. După ce pagina inițială a fost încărcată, serverul acționează doar ca un service layer. Clientul trebuie doar să știe ce fel de cereri HTTP să efectueze. Acestuia nu-i pasă în ce mod serverul implementează aceste lucruri pe partea de back end.

Cu această arhitectură, clientul și serviciul sunt independente. Întreg back end-ul care se execută serviciul poate fi înlocuit, și atâta timp cât nu se schimba API, nu va avea vreun efect asupra clientului. Inversul este de asemenea adevărat, aplicația client poate fi înlocuită complet, fără a schimba stratul de serviciu. De exemplu, s-ar putea scrie un client mobil nativ care consumă serviciul.

Framework-urile JavaScript pentru web browsere, cum ar fi AngularJS sau Ember au adoptat deja principiile SPA. AngularJS un framework complet client-side. Templating-ul în AngularJS este bazat pe data binding bidirecțional. Data-binding reprezintă un mod automatizat de updatarea vederii în momentul când model-ul suferă schimbări, la fel ca și updatarea modelului când vederea suferă schimbări. Șablonul HTML este compilat în interiorul browser-ului Etapa de compilare creează html pur, momentul în care browserul reface vederea live. Acești pași sunt repetați pentru diferite vederi. În programarea html tradițională pe partea de server, conceptele, cum ar fi controller și model interacționează într-un server pentru a produce noi vederi HTML. În cadrul framework-ului AngularJS, starea controller-ului și modelului sunt menținute în browser, pe partea de client. Prin urmare, noi pagini sunt generate fără a interacționa cu serverul. [3][4][8]

Framework-urile folosesc șabloanele de proiectare MVC sau MVVM, care facilitează mediul într-o aplicație SPA. MVC un șablon pentru dezvoltarea interfeței utilizatorului ce divide aplicația web în arii de responsabilități:

Modelul reprezintă mulțimea de obiecte sau structuri de date care reprezintă starea aplicației;

View-ul observă această stare a aplicației și generează răspunsul corespunzător către utilizator;

Controller-ul transformă input-ul utilizatorului în operații asupra modelului. [12]

Figura 8. Șablonul arhitectural MVC

MVVM (Model-View-ViewModel) este o variantă mai recenta a MVC și are următoarele caracteristici:

Modelul reprezintă încă datele domeniu.

View Model este o reprezentare abstracta a vizualizării.

View afișează View Model și trimite datele introduse de utilizator către View Model.

Figura 9. Șablonul arhitectural MVVM

Unit teste și teste de integrare

Este de la sine înțeles că unit testele reprezint o parte esențială a dezvoltării aplicației. Ele ne ajută în momentele în care dorim să refactorizăm codul, să adăugăm anumite librării, ba mai mult, ele ne ajută să facem un design cât mai reușit al aplicației. Fără unit teste, va fi destul de dificil să aflăm problema, atunci când ceva nu lucrează în mod scontat, din cauza la o modificare minoră în cod. Cuplat cu testarea end-to-end, acesta poate fi un instrument puternic, atunci când se fac schimbări arhitecturale.

Pe partea de client, unele dintre cele mai populare framework-uri de testare sunt Jasmine, Mocha și QUnit. Jasmine și Mocha contribuie mai mult la un still Behavior-Driven Development (BDD). QUnit, pe de altă parte, este un framework de testare unitate mai tradițional, oferind un API bazat pe aserțiuni. Jasmine, Mocha sau Qunit rulează testele pe un singur browser.

În cazul în care se dorește adunarea rezultatelor testelor de pe mai multe browsere, a fost elaborate un instrument numit Karma, care rulează testele în mai multe browsere.

Pentru a testa întreg produsul, vom avea nevoie de teste de integrare în aplicația dezvoltată, folosind framework-uri de testare gen Selenium și Cucumber /. Cucumber permite ca testele să fie scrise într-o sintaxă engleză, numite Gherkin, care pot fi împărtășite cu oameni care nu sunt apropiați programării. Fiecare caz de testare din fișierul Cucumber este susținut de cod executabil pe care poate fi scris în Ruby, JavaScript sau la oricare alt limbaj suportat de Cucumber.

Executând un script Cucumber, este executat un fragment de cod, care, la rândul său, testează aplicația și se asigură că toate funcționalitățile au fost implementate în mod corespunzător. O astfel de abordare este extreme de importantă pentru proiectele mari, și ar putea fi nejustificată pentru cele mici. Este nevoie cu siguranță un pic de efort pentru a scrie și menține aceste script-uri Cucumber, totul reducându-se la decizia echipei.

3.2.2 Provocări folosind modelul SPA

Deoarece SPA este o evoluție departe de modelul stateless (fără stare) de redesenare al paginii, pentru care browsere au fost concepute iniția, au apărut noi provocări. Pentru fiecare dintre aceste probleme există cel puțin câte o soluție eficientă cu:

Biblioteci JavaScript pe partea de client ce abordează diferite probleme.

Frameworkuri pe partea de server de web care se specializează în modelul SPA.

Evoluția browserelor și a specificației HTML5 ce vizează modelul de SPA.

Utilizarea frameworkurilor pe partea de client. (de exemplu AngularJS)

3.2.2.1 Search engine optimization

Din cauza lipsei de execuție JavaScript pe crawrelere al motoarelor populare de căutare web, SEO (optimizare pentru motoarele de căutare), de-a lungul timpului au însemnat o problemă pentru site-urile publice care doresc să adopte modelul SPA.

Google accesează cu ajutorul crawlerelor în prezent URL-uri care conțin fragmente de hash începând cu #!,. Acest lucru permite utilizarea de fragmente hash în URL-ul unic al unui SPA. Comportamentul special trebuie să fie pus în aplicare de către site-ul SPA, pentru a permite extragerea de metadate relevante de către crawler-ul motorului de căutare. Pentru motoarele de căutare care nu sunt compatibile cu acest sistem de hash URL, URL-urile hash ale SPA rămâne invizibile.

Alternativ, aplicațiile pot să afișeze pagina la prima încărcare de pe server și de pe modificările ulterioare ale paginilor pe client. Acest lucru este în mod tradițional dificil, pentru că ar fi nevoie de codul de redare să fie scris într-un altă limbaj sau framework pe server și în client. Folosind template-uri fără logică, cross-compilarea de la o limbaj la altul, sau folosind același limbaj atât pe server și pe client poate ajuta în creșterea cantității de cod care poate fi partajat.

O modalitate de a crește cantitatea de cod care poate fi partajată între servere și clienți este de a folosi un limbaj de template-uri fără logică, spre exemplu Mustache sau Handlebars. Aceste template-uri pot fi folosite de diferite limbaje, cum ar fi Ruby (Java, .NET etc.) pe server și JavaScript în client. Cu toate acestea, doar schimbul de template-uri necesită de obicei dublarea logicii aplicației, folosite pentru alegerea corectă a modelelor și a le popula cu date. Redare pe baza de template-uri ar putea avea efecte negative, de performanță, atunci când se actualizează doar o mică parte a paginii, cum ar fi valoarea textfield într-un șablon mare. Înlocuirea unui întreg șablon ar putea perturba, de asemenea, selecția sau poziția cursorului unui utilizator, dar în cazul în care se actualizează doar valoarea modificată s-ar putea să nu fie afectat. Pentru evitarea acestor probleme, aplicațiile pot folosi data bindings (legături de date) sau manipularea granulară a DOM, pentru a actualiza doar părțile corespunzătoare ale paginii, în loc de reafișarea întregului șablon.

O altă abordare utilizată de către frameworkurilor pe Web Server, cum ar fi ItsNat, bazate pe Java, este de a afișa orice hypertext pe server folosind același limbaj și tehnologie templating. În această abordare serverul știe cu precizie starea DOM în client, orice actualizări mari sau mici ale paginii se efectuează generând pe server, și transportat prin AJAX, codul JavaScript pentru a aduce pagina de client la o stare nouă executând metode DOM. Dezvoltatorii pot decide care stări ale paginii trebuie să fie eligibile pentru crawler pentru SEO și să fie capabil să genereze starea necesară în timpul de încărcare, pentru a genera HTML simplu în loc de JavaScript. În cazul frameworkului ItsNat acest lucru este automat, deoarece ItsNat păstrează ramificarea de pe client al DOM pe server ca o ramificare Java W3C DOM, afișarea acestei ramificări DOM în sistem generează HTML simplu în timpul de încărcare și acțiuni JavaScript pe DOM pentru cererile AJAX. Această dualitate este foarte importantă pentru SEO, deoarece dezvoltatorii pot construi cu același cod Java și templating bazat pe HTML pur starea DOM dorită pe partea de server.

Deoarece compatibilitatea SEO nu este chiar trivială în SPA, este demn de remarcat faptul că SPA-uri nu sunt de obicei utilizate într-un context în care indexarea motorului de căutare este fie o cerință.

3.2.2.2 Istoricul browser-ului

În contextual SPA, acest model încalcă într-o oarecare măsură design-ul browser-ului pentru istoricul navigărilor folosind butoanele Forward / Back. Aceasta prezintă un impediment de usability atunci când un utilizator apasă butonul Back, așteptând starea anterioară al ecranului din cadrul SPA, dar în schimb browserul pleacă de pe pagina aplicației și revine la pagina anterioară prezentă în istoricul browserului.

Soluția tradițională pentru a SPA este de a schimba hash URL-ul din browser, conform stării curente al aplicației. Aceasta se poate realiza prin intermediul JavaScript, și provoacă ca evenimentele de tip URL history să fie incluse în browser. Atâta timp cât SPA este capabil să refacă aceeași stare al ecranului din informațiile conținute în URL-ul hash, comportamentul scontat al butonului back este reținut.

Pentru abordarea în continuare al aceastei probleme, specificația HTML5 a introdus pushState și replaceState oferă acces programatic la URL-ul actual și istoricul browser-ului.

3.2.3 Beneficii folosind modelul SPA

Folosind modelul Single Page Application se pot obține beneficii evidente. Unele din ele ar fi:

O dată cu prima încărcare vom primi o mare parte din aplicație aceasta rămânând în cache-ul browser-ului – acest lucru însemnând o experiență foarte rapidă.

Încărcare ulterioară a datelor se poate face prin trimiterea de obiecte JSON foarte mici cu conținutul dorit, ceea ce este un lucru foarte bun pentru conexiuni lente sau cu trafic limitat (de exemplu, medii mobile)

Menținerea aplicației în totalitate cu JavaScript exclude necesitatea de a avea cadre calificate în mai multe limbaje de programare.

Folosind principiile pentru dezvoltarea aplicației web pe back end, face cu mult mai simplă trecerea la dezvoltarea pe partea de client.

Creează senzația folosirii unei aplicații desktop.

În esență, toate acestea fac o interfață mai interactivă. Nu se mai trimit mărimi mari de date, și nu se mai reîncarcă interfața aplicației din browser.

3.3 Concluzii

În acest capitol m-am focusat pe partea de client, punând accentul pe 2 tehnici/modele folosite în aplicațiile moderne: AJAX și SPA.

O dată cu apariția AJAX, aplicațiile web au devenit mult mai dinamice, dat fiind faptul că nu era deja necesară reîncărcarea paginii, îmbunătățind enorm calitatea aplicațiilor web, oferind utilizatorilor un randament mai mare al aplicației. Cu toate acestea în cele mai dese cazuri aceasta nu elimină complet reîncărcarea paginilor, mai ales în navigarea între pagini.

Aici intervine SPA (Single Page Application), care are ca scop soluționarea problemei reîncărcării paginilor, oferirea utilizatorului unei experiențe cât mai plăcute, prin intermediul unei aplicații web rapide, interactive, apropiindu-se de aplicațiile desktop la nivel de percepere dar în același timp rămânând o aplicație web.

Aplicația Weather

4.1 Descriere generală

În acest capitol aș dori să prezint aplicația dezvoltată de mine, atât posibilitățile ei, cât și soluțiile alese pentru diferite probleme din cadrul aplicației (structurarea aplicației, modulul de prezentare, accesul la baza de date etc.). Fiecare posibilitate a unei aplicații trebuie privită ca o problemă ce necesită a fi rezolvata într-un mod cât mai eficient, astfel încât să nu genereze erori (excepții) în timpul rulării, să nu folosească prea multe resurse de memorie, codul să fie ușor de citit pentru ca pe viitor să fie ușor de îmbunătățit, să aibă un aspect plăcut utilizatorului (în caz că aplicația conține interfață pentru utilizator). În mod normal trebuie de făcut o balansare între toate aceste aspecte, pentru a primi un produs final calitativ. Astfel se aleg tehnologiile care vor fi folosite în cadrul aplicației.

Aplicația dezvoltată este din domeniul meteorologic, și permite vizualizarea datelor meteo și anume: date despre vremea curentă, prognoza meteo în următoarele zile în câteva formate: prognoza în detalii (din 3 în 3 ore, pentru câteva zile) și prognoza zilnică (sumar pentru 10+ zile). Pe lângă aceasta, aplicația oferă un motor de căutare pentru localități, utilizatorul primind o listă de localități relevante, bazată pe datele introduse de către utilizator.

Până a trece la prezentarea în detalii a funcționalităților însoțite de imagini extrase din aplicație, voi face o scurta prezentare a arhitecturii aplicației.

Aplicația constă din 4 părți componente fiecare din ele având rolul său în această aplicație. În figura de mai jos avem reprezentarea schematică a componentelor aplicației.

Figura 10. Diagrama componentelor aplicației meteo

Componenta nr 1 (Weather App UI) reprezintă modulul interfeței utilizatorului. Spre deosebire de o aplicație web clasică, lucrurile legate de vizualizare, popularea șabloanelor predefinite, rutarea în interiorul aplicației are loc la nivel de client, prin intermediul browserului, astfel, serverul (componenta nr 2) este utilizat doar ca furnizor de date. Componenta nr 2 (Weather App Web Services) reprezintă partea de back end al aplicației. Ea este componenta cu care comunică aplicația UI, de la care accesează datele necesare. API-ul este oferit prin intermediul Web Serviciilor de tip RESTful, fiind mult mai comod de utilizat, din perspectiva UI cât și backend, față de Web Servicii SOAP. După cum am menționat mai sus, aceste web servicii ne oferă datele de care are nevoie aplicația UI ca să funcționeze, și anume: datele meteo în toate formatele, care la rândul său au fost accesate și oferite de către Weather Data Vendor (componenta nr. 4), și căutarea localității, aceasta incluzând o logică complexă de sugestii bazate pe caracterele introduse de către utilizator, datele sunt accesate din baza de date (componenta nr. 3).

Modalitatea de a separa aplicația in mai multe module mari, cât și rezultatul ei se numește Multitier architecture (Arhitectură pe mai multe nivele). În ingineria software, arhitectura pe mai multe nivele este o arhitectura client-server în care prezentarea, procesarea aplicației și managementul datelor sunt procese separate după logică. În cazul aplicației mele am două nivele: nivelul web, fiind cel mai înalt nivel, nivelul web servicii, în care este concentrată colectarea și procesarea datelor. Deseori această arhitectură este numită n-tier architecture (arhitectura n-nivele) dat fiind faptul că nu sunt restricții în folosirea ei, nu există un număr finit de nivele în care trebuie să fie împărțită aplicația, fiecare având posibilitate să implementeze această arhitectură la dorință, însă evident deja sunt soluții care și-au demonstrat utilitatea și eficiența de-a lungul timpului.[13]

Prin această arhitectură am încercat să responsabilizez mai mult browserul, de la afișarea paginilor generate pe server la construirea acestor pagini din șabloane, efectuarea operațiunilor de rutare cât și efectuarea unor mici operațiuni de manipulare a datelor. Astfel, după cum am menționat, serverul are rolul doar de procesator de date, colectând date de la furnizorul de date meteo și baza de date de localități, și oferind aplicației UI într-o formă definită și cunoscută. Datele sunt transmise de către server către browser în formatul JSON, care este foarte simplu de procesat în Javascript. Această abordare separă responsabilitățile, cât și dependențele față de limbaje de programare. Altfel pot lucra în paralel 2 echipe diferite, cu aptitudini diferite, o echipă ce dezvoltă aplicația UI, lucrând cu HTML, CSS și Javascript, altă echipă dezvoltând web serviciile, dezvoltate cu ajutorul unui limbaj de programare corespunzător (Java, C#, Groovy etc.) + cunoștințe SQL de bază, pentru lucrul cu bază de date. Mai mult ca atât pe lângă separarea responsabilităților putem obține performanțe superioare unei aplicații web simple, deoarece serverul va folosi cu mult mai puține resurse pentru a ne oferi datele, pagina fiind construită la nivel de client, de exemplu pe computerul utilizatorului. Astfel, serverele vor fi mai puțin încărcate și vor putea procesa mai multe cereri, respectiv mai rapid.

Interfața utilizatorului a fost implementată cu ajutorul HTML, Javascript, CSS, adițional un framework care face în mare parte uitate toate problemele legate de programarea aplicațiilor de tip single page – AngularJS. Dezvoltat de Google, acest framework este implementat pe baza șablonului arhitectural MVVM (Model View ViewModel), fiind o variantă mai recenta a MVC și are următoarele caracteristici:

Modelul reprezintă încă datele domeniu.

View Model este o reprezentare abstracta a vizualizării.

View afișează View Model și trimite datele introduse de utilizator către View Model.

Web serviciile sunt implementate în limbajul JAVA, și anume cu ajutorul JAX-RS, o specificație JAVA a web serviciilor de tip RESTful. Este folosită implementarea de referință Jersey. Simplificarea accesului la baza de date am realizat-o prin intermediul JPA (Java Persistence API cu implementarea de la Hibernate) [15], astfel în cadrul aplicației nu utilizez nicio instrucțiune SQL, toate operațiunile sunt efectuate asupra obiectelor, numite entități (entity beans). JPA vine cu un set de funcții ce permite efectuarea operațiilor CRUD (Create, Read, Update and Delete), astfel dispare necesitatea de a folosi instrucțiuni complicate pentru a extrage sau modifica conținutul mai multor tabele. [15].

Pentru împachetarea web serviciilor am folosit tool-ul automatizat Maven. Maven este un sistem de construire si management al proiectelor, scris in Java. Face parte din proiectele găzduite de Apache Software Foundation. Este un tool open source (instrument cu codul sursa deschis) care este pe larg utilizat atât de majoritatea proiectelor Java Open Source, cât si de multe altele. Marele avantaj pe care l-am simțit folosind acest tool a fost downloadarea în mod automat al librăriilor necesare pentru a rula aplicația, este nevoie doar de indicat într-un fișier .xml datele despre librăriile necesare.

4.2 Prezentarea funcționalităților aplicației

În acest paragraf voi prezenta cele mai importante funcționalități ale aplicației, modul de utilizare și posibilități. Aplicația este compusă 2 secțiuni: bara de meniu, care este situată mereu în partea de sus a paginii, și conținutul propriu-zis al aplicației. Să trecem la prezentarea funcționalităților în detalii.

4.2.1 Pagina principală

Pagina principală este compusă din 2 blocuri: căutările recente (descrisă în secțiunea 4.2.5) și vremea curentă în principalele orașe ale țării (figura 11). În principiu putem observa date despre temperatura curentă, starea cerului cu ajutorul unor imagini, cât și date privind viteza și direcția vântului, umiditatea relativă, presiunea atmosferică, cât și ora răsăritului și apusului soarelui.

Figura 11. Pagina principală

4.2.2 Căutare localități

În figura 11, avem reprezentată un mic formular de căutare, format din un input de tip text și un buton (situat în partea dreapta-sus al ecranului). În funcție de datele introduse de către utilizator, este returnată o listă de localități, cele mai relevante fiind în capul listei (figura 12). Căutarea datelor se face în stilul motoarelor de căutare. Datorită faptului că sistemul analizează datele introduse de utilizator și returnează căutările relevante, se pot introduce date incomplete, sau chiar și cu mici greșeli. La moment aplicația suportă doar localitățile din Republica Moldova, dar pe viitor este preconizată adăugarea celor mai importante localități din toate țările lumii. Datele despre localități sunt păstrate într-o bază de date relațională MySql, o bază de date gratuită, la fel ca și toate tehnologiile folosite în această aplicație web.

Figura 12. Căutare localități

4.2.3 Prognoza în detalii

Unul din cele 2 funcționalități în care este afișată prognoze pentru perioada următoare. Conținutul este afișat în mai multe secțiuni, pentru comoditate cu posibilitatea de a vizualiza doar o secțiune în același timp. Fiecare secțiune conține prognoze meteo din 3 în 3 ore pentru o anumită zi. Comutarea între secțiuni se face prin apăsarea săgeților, apăsarea pe una din zile din partea dreaptă a paginii, fie folosind „roata” mouse-ului, ducând în prealabil cursorul deasupra secțiunii. Pe lângă prognoza meteo, în stânga secțiunii este prezentă blocul „vremea curentă”, unde sunt afișate datele despre situația curentă în localitatea dată.

Figura 13. Prognoza în detalii

4.2.4 Prognoza zilnică

Pe lângă prognoza în detalii, putem vedea un sumar zilnic pentru 14-15 zile. După cum este prezentată în figura de mai jos, pot fi observate date pentru temperatura minimă și maximă a zilei, cerul, direcția și viteza vântului, presiunea atmosferică. La fel ca și la prognoza în detalii conținutul este afișat în secțiuni, câte 7 zile, cu posibilitatea de a fi listat cu ajutorul săgeților sau cu ajutorul roții de la mouse. Blocul „vremea curentă”, în care sunt afișate datele despre situația curentă în localitatea dată, la fel este prezent.

Figura 14. Prognoza zilnică

4.2.5 Ultimele căutări

Această funcționalitate constă în păstrarea și afișarea către utilizator unei liste ce prezintă ultimele localități ce au participat în afișarea prognozei meteo. Lista este afișată sub forma unui bloc (figura 13, blocul “ultimele căutări”). Localitățile sunt click-abile, astfel utilizatorul poate afla prognoza meteo pentru localitățile favorite fără a introduce de la tastieră numele acestor localități.

CONCLUZII GENERALE ȘI RECOMANDĂRI

Teza este dedicată studiului aplicațiilor web moderne, beneficiile care le oferă utilizatorului. Aplicațiile web au suferit și suferă schimbări considerabile din punct de vedere al arhitecturii, venind mereu cu diferite îmbunătățiri și inovări. Acestea au la scop rezolvarea diferitor probleme ce apar în dezvoltarea și utilizarea aplicațiilor web: de la ușurința cu care se dezvoltă o aplicație web până la experiența utilizatorului în urma folosirii acestei aplicații, viteza de răspundere, interactivitate.

Astfel, în ultimii ani au apărut așa noțiuni gen: Ajax și SPA (single page application). Ajax ne oferă interacțiunea cu serverul fără reîncărcarea paginilor, SPA reprezintă un model al aplicației web prin care oferă mai multă responsabilitate pe partea de client, care în mod obișnuit se făcea pe server: generarea paginilor web pe baza unor șabloane, dirijarea navigației. Browserul devine nu doar un simplu vizualizator de pagini, ci un container de aplicații web, moderne , rapide, receptive.

Studiind și analizând posibilitățile realizării unei aplicații web, am dedus faptul că cea mai bună combinație reprezintă web serviciile RESTful pe partea de server, care are ca scop doar oferirea datelor, și pe partea de ui folosirea unui framework pe Javascript, care preia majoritatea atribuțiilor care le avea serverul într-o aplicație web obișnuită: administrarea prezentărilor, generarea paginilor web pe baza de șabloane, mecanismul de navigare. Astfel, partea legată de prezentare va avea loc în browserul fiecărui utilizator în parte, această însemnând micșorarea semnificativă a presiunii și a volumului de date procesat de server. Un plus care nu trebuie de neglijat este și scăderea traficului din rețea.

Teza prevede și partea practică: a fost elaborată o aplicație web, folosind metodele și tehnologiile descrise în cadrul acestei teze. Aplicația elaborată reprezintă un vizualizator al datelor meteo, vremea curentă și prognoze pe următoarele zile. Pe lângă aceasta sunt implementate funcționalități care ușurează interacțiunea utilizatorului cu aplicația, cum ar fi implementarea unor shortcut-uri in aplicație sau căutarea localităților după caracterele introduse de către utilizator, folosind căutarea fuzzy utilizatorul poate primi rezultatul dorit chiar dacă greșește denumirea localității.

În urma experienței dezvoltării aplicațiilor web de tip Single Page, pot să afirm și să recomand adoptarea acestui model de aplicație web, deoarece în primul rând procesul de dezvoltare este mai clar și interesant, si nu în ultimul rând oferă utilizatorului o experiență plăcută, o aplicație rapidă și receptivă, un fapt foarte important care merită și trebuie luat în considerare în procesul de dezvoltare al aplicațiilor de orice tip.

BIBLIOGRAFIE

James Duncan Davidson, Danny Coward (1999-12-17). Java Servlet Specification ("Specification") Version: 2.2 Final Release. Sun Microsystems. pp. 43–46. Retrieved 2008-07-27.

Michael Mikowski:Single Page Web Applications: JavaScript end-to-end,Manning Publications, 2013

Adam Freeman: Pro AngularJS, Apress, 2014

Brad Green: AngularJS, O'Reilly Media, 2013

Martin Kalin: Java Web Services: Up and Running, O'Reilly Media, 2013

Vishal Layka: Learn Java for Web Development: Modern Java Web Development, Apress, 2014

Chris Love: High Performance Single Page Web Applications, 2014

Leon Shklar: Web Application Architecture: Principles, Protocols and Practices, Wiley, 2009

Ethan Cerami: Web Services Essentials, O'Reilly Media, 2002

James Snell: Programming Web Services With SOAP, O'Reilly Media, 2001

Leonard Richardson: RESTful Web APIs, O'Reilly Media, 2013

Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra, Elisabeth Robson. Head First Design Patterns, November 1, 2004.

http://en.wikipedia.org/wiki/Multitier_architecture

Christian Bauer, Gavin King.Java Persistence with Hibernate,Manning Publications Co., 2007.

BIBLIOGRAFIE

James Duncan Davidson, Danny Coward (1999-12-17). Java Servlet Specification ("Specification") Version: 2.2 Final Release. Sun Microsystems. pp. 43–46. Retrieved 2008-07-27.

Michael Mikowski:Single Page Web Applications: JavaScript end-to-end,Manning Publications, 2013

Adam Freeman: Pro AngularJS, Apress, 2014

Brad Green: AngularJS, O'Reilly Media, 2013

Martin Kalin: Java Web Services: Up and Running, O'Reilly Media, 2013

Vishal Layka: Learn Java for Web Development: Modern Java Web Development, Apress, 2014

Chris Love: High Performance Single Page Web Applications, 2014

Leon Shklar: Web Application Architecture: Principles, Protocols and Practices, Wiley, 2009

Ethan Cerami: Web Services Essentials, O'Reilly Media, 2002

James Snell: Programming Web Services With SOAP, O'Reilly Media, 2001

Leonard Richardson: RESTful Web APIs, O'Reilly Media, 2013

Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra, Elisabeth Robson. Head First Design Patterns, November 1, 2004.

http://en.wikipedia.org/wiki/Multitier_architecture

Christian Bauer, Gavin King.Java Persistence with Hibernate,Manning Publications Co., 2007.