Music FinderMarius Mutescu, Simona Cotin

Universitatea Alexandru Ioan Cuza Iasi, Facultatea de Informatica

ABSTRACT

“Rapid Application Development (RAD) is a development lifecycle designed to give much fasterdevelopment and higher-quality results than those achieved with the traditional lifecycle. It is designed to take the maximum advantage of powerful development software that has evolved recently.” James Martin

KEYWORDS: Web Services. REST. SOAP. RAD. C#

1.RAD (Rapid Application Development)

1.1.Definitie

Rapid Application Development este un termen folosit iniţial pentru a descrie un proces de dezvoltare de software introdus de James Martin în 1991. Metodologia lui Martin implică dezvolatrea iterativa şi construcţia de prototipuri. Mai recent, termenul şi acronimul acestuia au ajuns să fie utilizate într-un sens mai larg care cuprinde o varietate de metode care vizează dezvoltarea de aplicaţii in viteză, prin utilizarea platformelor de dezvoltare software de tipuri variate, cum ar fi platforme de dezvoltare aplicatii web.

1.2 Avanjate

RAD are ca avantaje folosirea de instrumente automatizate si tehnici pentru a restructura procesul de construire a sistemelor informatice. Acest proces nou, extrapolat la întreaga organizare IS, rezulta într-o profundă transformare a dezvoltarii de sisteme informatice. RAD înlocuieşte design-ul de mana si procesele de programare, care sunt dependente de abilităţile unor indivizi izolati, cu un design si proces de programare automate, care este un proces inerent mai stabil. RAD poate da, astfel, unei organizari IS prima sa baza reala pentru o îmbunătăţire continuă. În afară de a fi mai stabil, Rapid Application Development este un proces mult mai capabil, deoarece este mult mai rapid şi mai putin predispus la eroare decât programarea „de mână”.

1.3 Descriere

RAD comprimă dezvoltarea pas-cu-pas a metodelor convenţionale într-un proces iterativ. Abordarea RAD astfel include dezvoltarea şi rafinarea modelelor de date, modelelor de proces, şi prototipizarea în paralel folosind un proces iterativ.

Cerinţele utilizatorului sunt analizate, o soluţie este concepută, soluţia este prototipizată, prototipul este revizuit, datele de intrare sunt furnizate, iar procesul incepe din nou.

Rapid Application Development are patru aspecte esenţiale: metodologie, oameni, management, şi instrumente.

Bazele metodologiei RAD includ:

- Combina cele mai bune tehnici disponibile şi specifică secvenţa de sarcini care va face aceste tehnici mai eficiente- Utilizarea de prototipuri evolutive care se vor tranforma în produsul final- Utilizarea atelierelor de lucru, în loc de interviuri, pentru a aduna cerintele de proiectare şi revizuirea designului- Selectarea unui set de instrumente CASE pentru modelarea, prototipizarea şi reutilizarea codului, precum şi automatizarea tehnicilor utilizate- Implementarea tehnicii „timeboxed development”, care permite echipelor de dezvoltare construirea rapida a sistemului de bază şi implementarea detaliilor in etape ulterioare- Definirea unor tehnici pentru obinerea succesului şi descrierea capcanelor care ar trebui evitate

1.4 Structura

Structura ciclului de viaţă RAD este conceputa astfel incat asigura că dezvoltatorii construiescsistemele de care chiar au nevoie utilizatorii. Acest ciclu de viaţă, prin următoarele patrustadii, include toate activităţile şi sarcinile necesare pentru a defini cerinţele şi proiectarea, dezvoltarea şi implementarea aplicatiei care indeplineste aceste cerinţe.

1.4.1 Planificarea cerintelor

Cunoscuta si ca etapa de definire a conceptelor, acest stadiu defineşte funcţiile şi domeniile de date pe care le va suporta sistemul şi determină domeniul de aplicare al sistemului.

1.4.2 User Design

De asemenea, cunoscut sub numele de faza de proiectare funcţională, această etapă foloseste ateliere de lucru pentru a modela sistemul de date şi procesele şi pentru construi un prototip functionabil pentru componetele critice ale sistemului

1.4.3 Construirea

De asemenea, cunoscut sub numele de stadiul de dezvoltare, această etapă inglobeaza elementele finale in construcţia fizica a aplicatiei, construieste sistemul de conversie, şi dezvoltă ghidul de utilizare şi de implementare a cerintelor de lucru.

1.4.5 Implementarea

De asemenea, cunoscut sub numele de faza de implementare, acest stadiu include testarea finala de catre utilizator şi instruirea acestuia, conversia de date, precum şi implementarea aplicatiei.

1.5 Instrumente

Instrumentele cele mai importante în RAD sunt instrumentele CASE (Computer-Aided Systems Engineering). Acestea pot fi impartite in doua categorii: pe de-o parte instrumente CASE care, pornind de la specificatii precise dar exprimate intr-un mod mai natural, generează cod intr-un limbaj de programare si, pe de altă parte, instrumente CASE specializate pe realizarea de aplicatii prototip.Astfel, instrumente de tip CASE au trecut prin diverse etape de dezvoltare permiţându-ne depăşirea mai multor probleme legate de dezvoltare de software, prin inovaţii precum Rapid Application Development.

1.6 C# - mediu RAD                                                                                                        

Una dintre caracteristicile RAD ale limbajului C# este colectarea spatiului disponibil in stilul limbajului Java. La intervalele arbitrare din timpul momentul executiei, toate obiectele care nu mai sunt referite sunt in mod automat sterse. Usurand treaba programatorului de a elibera manual memoria- colectarea spatiului disponibil face generarea programelor mai usoarã si fãrã eroare. C# pune in aplicare un tip  un sistem valoare/referinta in stilul limbajelor Java/Delphi: Pentru a sprijini RAD, C# foloseste in continuare pointerul de C, C++ in favoarea tipului de sistem valoare/referinta Java si Delphi. Acest tip de sistem este mai mult simplu decat pointerii din C++. Face mai usoarã folosirea obiectelor si eliminã multe din erorile ce apar in programele de C si C++. In C# interfetele sunt declarat separat fata de clase.Este opusul modelului C++, unde interfetele sunt clase de baza abstracte. Acest model evita problema multiplei mosteniri, in care pot aparea conflicte. Nevoia pentru mecanismele complexe ca de exemplu mostenirea virtuala este de asemenea eliminata. Interfata simplificata a C#-ului ajuta la marirea vitezei aplicatiei. Declaratiile si definitiile metodelor de clasa sunt combinate: C# simplifica dezvoltarea aplicatiilor prin combinarea declaratiilor si definitiilor de metodele clasei. C# foloseste referirile metodelor, numiti "delegate", in loc de pointerii la metoda, pentru a conecta repede obiectele si metodele. Numite si "delegate", aceste metode sunt asemanatoare cu tipurilor procedurale ale limbajului Delphi. Un delegat este un tip de o referinta care tine semnatura metodei. O aplicatie sa poata sa desemneze oricare metoda care un potriveste aceasta o semnatura la o variabila "delegate". Spre deosebire de tipurile de proceduri Delphi, "delegates" suporta si multicasting-ul. O aplicatie poate sa desemneze multe metode la o variabila "delegat"; Cand variabila este invocata, sunt apelate toate metodele. Sincronizarea firelor de executie in C#, se realizaeaza pur si simplu prin marcharea blocurile critice de cod, folosind "lock"=lacat. Un mutex protejeaza blocul, permitand numai un fir sa execute codul odata. Declaratiile de suprascriere explicite sprijina dezvoltarea rapida a aplicatiilor, protejand metoda claselor namespaces si expunand accidental conflictele.Se marcheaza o suprascriere de metoda cu cuvantul cheie "override" iar daca o clasa derivata include o metoda care are acelasi nume ca metoda virtuala din clasa de baza, compilatorul nu poate precis sa desluseasca intentia autorului. Pe de alta parte, un conflict de nume ar putea foarte bine accidental; se intampla in special cand clasa de baza si clasa derivata au fost implementate in mod independent de doi programatori, lucrand poate in companiile diferite. in astfel de caz, compilatorul va da un avertisment si va trata metodele clasei derivate ca o declaratie noua,nu ca pe o suprascriere.

2. Servicii Web

2.1 Definitie

Un serviciu web reprezintă un API expus independent de tehnologie. Serviciul este definit de proxy-ul metodelor remote şi formă de afişare a rezultatelor. Serviciul funcţionează peste HTTP şi mapează metodele GET,PUT,POST şi DELETE sub formă metodelor remote. Simplitatea şi robusteţea arhitecturii

REST l-au făcut un competitor puternic în lumea comunicaţiilor mobile. Motivul pentru care stilul serviciului este REST şi nu SOAP este dat de faptul că protocolul SOAP oferă suport pt " strong types " prin Schemă XML ,suport pentru tranzacţii , securitate , encriptarea datelor şi multe altele. Scopul serviciului web în cazul de faţă este să returneze un pachet de date cât mai mic şi mai rapid către clientul mobil, fără tot overhead-ul generat de SOAP şi fără consumul suplimentar de resurse.

2.2 HTTP

HyperText Transport Protocol este un protocol de comunicaţie pentru sisteme informaţionale distribuite, colaborative. HTTP-ul reprezintă fundaţia comunicării pe World Wide Web.Dezvoltarea Standardului HTTP a fost coordonată de Internet Engeneering Task Force (IETF) şi World Wide Web Consortium (W3C) , culminând în publicarea unei serii de Requests for Comments (RFCs) , care definesc HTTP/1.1 .HTTP -ul funcţionează ca un protocol cerere – răspuns în modelul client-server. În HTTP, un web browser acţionează ca un client, şi o aplicaţie care rulează pe un alt computer care găzduieşte un web site este serverul. Clientul trimite un mesaj cerere serverului. Serverul , care stochează conţinut, sau oferă resurse , cum ar fi fişiere HTML , returnează un mesaj clientului. Mesajul de la server conţine informaţii despre completarea cererii, despre cerere şi poate conţine şi resursă cerută de client. Clientul este numit de obicei User Agent (UA) . La fel ca browsere web , crawlerele web sunt tot o formă de UA.Protocolul HTTP este creat că să permită elemente intermediare de reţea să îmbunătăţească sau să permită comunicaţia dintre client şi server. Serverele de trafic sporit se folosesc de server web cache, care returnează conţinutul în locul serverului propriu-zis, pentru a îmbunătăţi timpul de răspuns. Servere de proxy HTTP de la graniţa reţelelor facilitează comunicaţia când un client fără o adresă rutabila global este localizat in reţele private.HTTP este protocol pe nivelul aplicaţie din stivă TCP , creat în cadrul framework-ului Internet Protocol Suite. Definiţia protocolului se bazează pe un nivel de transport sigur pt transferul de date de la gazdă la gazdă. Protocolul TCP este protocolul dominant folosit în acest scop.Resursele HTTP sunt identificate şi localizate în reţea pe bază Uniform Resource Identifier (URI) şi Uniform Resource Locators (URL-uri) folosind schemele URI http sau https. Uri-urile şi Html-ul formează un sistem de resurse interconectate, denumite documente hypertext, pe Internet, care a condus la înfiinţarea în 1990 a World Wide Web de fizicianul englez Tim Berners-Lee.În cadrul lucrării comunicaţiile între view şi controller se fac utilizând protocolul HTTP. Comunicaţiile între view , controller şi resursele externe (serviciile Google) se realizează tot folosind protocolul HTTP.

2.3 REST

REST : Representational State Transfer este un stil de arhitectură software pentru sisteme hypermedia distribuite cum ar fi WWW. Termenul Respresentational State Transfer a fost întrodus şi definit în 2000 de către Roy Fielding în lucrarea de dizertaţie .Un sistem care se conforma regulilor REST se numeşte RESTful.Arhitectura a fost dezvoltată în paralel cu HTTP 1.1 , fiind bazat pe HTTP 1.0. Cea mai mare implementare a unui sistem conformat REST este WWW -ul. REST exemplifica cum arhitectura WWW s-a format prin caracterizarea şi constrângerea macro-interacţiunilor a celor patru mari componente ale Web-ului : origin server , gateway, proxy şi client fără să impună limitări participanţilor individuali. Astfel REST guvernează comportamentul corect al participanţilor. Arhitectura în stilul REST este bazată pe clienţi şi servere. Clienţii iniţiază cereri către servere , serverele procesează cererile şi returnează răspunsurile adecvate . Cererile şi răspunsurile sunt construite în jurul transportului resurselor reprezentate. O resursă poate fi esenţial orice concept coerent care poate fi o adresă. Reprezentarea resursei este un document care cuprinde starea curentă sau dorită a resursei. În orice moment un client poate fi între stările aplicaţiei sau idle ("at rest") . Un client în starea de rest poate să acţioneze cu utilizatorul , dar nu creează load-uri sau storage asociat userului pe reţea său pe server efectiv. Clientul începe să trimită cereri când este pregătit să treacă în starea următoare. Cât timp cereri sunt încă active , clientul este într-o stare de tranziţie. Reprezentarea fiecărei stări ale aplicaţiei conţine linkuri care vor fi

folosite data următoare când se va iniţia o nouă tranziţie. REST a fost descris pt prima dată în contextul HTTP , dar nu este limitat la acest protocol. Arhitecturi RESTful pot fi bazat pe protocoale pe nivelul aplicaţie, dacă vocabularul este destul de bogat şi de uniform pentru aplicaţiile bazate pe transferul de stări reprezentative importante. Aplicaţiile RESTful maximizează folosirea interfeţelor bine-definite şi a altor capabilităţi integrate oferite în descrierea protocolului folosit şi minimizează adăugarea de features noi specifice aplicaţiei.Stilul arhitectural REST descrie următoarele şase constrângeri care trebuie să fie aplicate arhitecturii , laşând liberă implementarea componentelor.

Client-server : clienţii sunt separaţi de servere de o interfaţa uniformă. Această separare de concepte asigură clienţii de faptul că nu sunt interesaţi de stocarea datelor, care este internă fiecărui server , şi portabilitatea codului client este sporită. Serverul nu este influenţat de interfaţa utilizatorului şi de starea uşerului, astfel încât serverele pot fi cât mai simple şi mai scalabile. Serverele şi clienţii sunt independenţi şi oricând pot fi schimbate sau îmbunătăţite fără să se afecteze unul pe celălalt.

Stateless : comunicaţia client-server este constrânsă de faptul că nu se poate stoca pe server starea nuci unuia dintre clienţi între cereri. Fiecare cerere de la client conţine informaţiile necesare rezolvării cererii , partea de stare rămânând pe client. Serverul poate fi stateful , această constrângere necesită că starea server-side să fie accesibilă prin adresare URL ca o resursă. Această caracteristică nu doar că face serverul mai vizibil pentru monitorizare , dar îl face şi mai stabil în fata problemelor parţiale de reţea, cât şi pentru îmbunatăţiri viitoare pe partea de scalabilitate.

Cacheabble : ca pe WWW clienţii sunt capabili să face cache la răspunsuri. Răspunsurile trebuie că în mod implicit sau explicit să se declare cacheable , sau nu pentru a oferi clienţilor informaţiile necesare în situaţii de creare de cache. Un sistem de caching bine definit elimină parţial sau complet interacţiunile client-server , astfel se îmbunătăţeşte iarăsi scalabilitatea şi performanţele.

Sistem ierarhizat: clientul nu poate şti dacă este conectat direct la server sau la un intermediar. Serverele intermediare pot îmbunătăţi scalabilitatea, pot oferi load balancing şi pot oferi chiar şi soluţii de securitate.

Code on demand ( opţional): serverele pot extinde funcţionalitatea clienţilor , transferând logica pe care clientul o poate folosi.

Uniform Interface : interfaţa între client şi server simplifică şi decuplează arhitectura, ceea ce permite fiecare componenta să evolueze independent.

2.2.1 Serviciile web RESTful

Un serviciu web RESTful este un serviciu simplu care este implementat utilizând HTTP şi principiile REST. Este o colecţie de resurse , cu trei aspecte definite.

- URL -ul de bază a serviciului web http://example.com/resources/- un tip de Internet media suportat de serviciu , acesta de obicei este JSON,XML sau YAML- un set de operaţii suportate de serviciul web utilizând metode HTTP

2.4 SOAP

2.4.1 Definitie

SOAP este un protocol de mesaje extensibil bazat pe XML ce constituie fundamentul pentru serviciile web. SOAP ofera un mecanism simplu si consistent ce permite unei aplicatii sa trimita un mesaj XML unei alte aplicatii. SOAP ofera suport pentru comunicatiile tip peer-to-peer. Un mesaj SOAP este o

transmisie one-way de la un trasmitator SOAP la un receptor SOAP, orice aplicatie poate participa in acest schimb de mesaje fie ca transmitator fie ca receptor. Mesajele SOAP pot fi combinate sa suporte deverse tipuri de comunicatii de ex: cerere/raspuns (request/response) cerere de raspuns (solicit response) sau notificare (notification)

2.4.2 Componente

SOAP Envelope –mecanism de identificare a continutului mesajului si de explicitare a modului in care trebuie procesat mesajul. SOAP Envelope include un SOAP header si un SOAP body.

SOAP Transport Binding Framework –mecanism extensibil ce mapeaza  SOAP Envelope la protocoalele de transport de nivel inferior. Specificatia SOAP 1.2 defineste legaturile de transport pentru HTTP si HTTP Extensions Framework.

SOAP Enconding Rules- toate datele transmise printr-un mesaj SOAP sunt codate utilizand XML, dar nu exista un mecanism implicit de serializare pentru maparea tipurilor de date definite de aplicatie la elementele XML. Datele pot fi transmise literal sau ca valori codate. Utilizatorii pot defini propriul lor mecanism sau pot utiliza mecanismul de serializare definit de regulile de codare SOAP.

SOAP RPC Representation. Un transmitator SOAP trimite un mesaj iar receptorul SOAP determina ce face cu el.Transmitatorul SOAP  nu este necesat sa conoasca totul despre implementarea serviciului ci doar formatul mesajului si accesul la puntul URI. Este in sarcina receptorului SOAP sa determine pe baza continutului mesajului ceea ce transmitatorul cere si cum sa proceseze cererea.

2. Music Finder

Music Finder se folseste de 3 servicii web pentru a furniza date despre majoritatea formatiilor sau artistilor muzicali. Acesta invoca doua servicii REST si unul SOAP:

-MusicBrainz (detalii despre artist si albume)

-LastFM (detalii despre artist si albume)

-lyrics.wikia.com (lyrics)

Primul serviciu invocate este cel oferit de http://musicbrainz.org/ .

Acestea sunt cele 3 adrese de unde se iau informatiile. Raspunsul returnat este primit sub forma de XML. Prima problema intalnita a fost cum prelucram raspunsul primit. O varianta ar fi fost parcurgerea documentului XML in cautarea nodurilor care ne intereseaza. Deoarece solutia este una destul de greoiaie

am ales alternative mai usoara si mai eleganta. Am capturat cu Fiddler(http://www.fiddler2.com/fiddler2/) raspunsul XML primit la fiecare cerere din cele 3 de mai sus.

Odata ce avem modelul de raspuns XML vom creea schema XSD a acestuia. Pentru a face lucrul acesta copiem XML-ul in Visual Studio iar acolo printr-o simpla apasare de buton vom genera schema XSD a acestuia.

Dupa ce avem schema XSD a raspunsului vom folosi un alt tool gratuit WSCF.blue (http://wscfblue.codeplex.com/) pentru a genera clasa in care vom deserializa fiecare raspuns (un raspuns normal, fara eroare).

Din fereastra care ne apare putem seta mai multe proprietati a fisierului generat(clasei in cazul nostru) cum vedem in imaginea de mai sus. La fel vom proceda pentru fiecare metoda a serviciilor REST pe care

dorim sa le apelam: capturam respunsul, generam schema XSD a acestuia dupa care generam clasa in care vom deserializa raspunsurile primate de la server.

Al doilea serviciu REST accesat este cel de pe LastFM (http://www.lastfm.fr/api). Pentru crearea claselor am procedat exact ca mai sus.

Al treilea serviciu este cel de Lyrics (http://lyrics.wikia.com/server.php?wsdl).

O data adaugat serviciul web este foarte usor de invocate metodele serviciului.

REFERINTE:

1. SEMANTIC WEB SERVICES: A RESTFUL APPROACH; Otávio Freitas Ferreira Filho, Maria Alice Grigas Varella Ferreira

2. Representation Design for RESTful Web Services ; Qingling Wang, Yan Liu3. http://www.casemaker.com/download/products/totem/rad_wp.pdf4. http://en.wikipedia.org/wiki/Rapid_application_development5. http://soapuser.com/basics1.html 6. http://msdn.microsoft.com/en-us/library/aa984213%28v=vs.71%29.aspx7. http://rosu-e.marte.ro/