serviciile XML-RPC

(1)

Universitatea Babes ¸-Bolyai

Facultatea de Matematic˘ a s ¸i Informatic˘ a Specializarea Sisteme Distribuite ˆ In

Internet

LUCRARE DE DISERTAT ¸ IE Descriptor XRDL ¸ si echivalent ¸a cu

serviciile XML-RPC

Conduc˘ ator ¸ stiint ¸iific:

Prof. Dr. BOIAN Florian

Absolvent:

TROANC ˘ A Diana

2013

(2)

Cuprins

1 Introducere 1

1.1 Generalit˘at¸i . . . 1

1.2 Motivat¸ie ¸si obiective . . . 1

1.3 Contribut¸ie personal˘a . . . 2

1.4 Structura lucr˘arii . . . 3

2 Servicii Web 4 2.1 Scurt˘a istorie . . . 4

2.2 Caracteristicile unui serviciu web . . . 5

2.3 Componentele ¸si arhitectura unui serviciu web . . . 7

3 Servicii Web de tip XML-RPC 10 3.1 Generalit˘at¸i . . . 10

3.2 Protocolul XML-RPC . . . 11

3.2.1 Modelul de date XML-RPC . . . 13

3.2.2 Formatul cererii . . . 18

3.2.3 Formatul r˘aspunsului . . . 20

4 Descriptorul XRDL 22 4.1 Scopul descriptorilor de servicii web . . . 22

4.2 Structura documentului XRDL . . . 22

4.3 Validitatea XRDL ca limbaj de descriere pentru XML-RPC . . . 24

4.3.1 Existent¸a unui document XRDL pentru orice serviciu XML-RPC . 25 4.3.2 Existent¸a unui serviciu XML-RPC valid pentru orice document XRDL 30 5 Aplicat¸ie 38 5.1 Motivarea ¸si scopul aplicat¸iei . . . 38

5.2 Specificarea aplicat¸iei . . . 39

5.3 Integrarea aplicat¸iei cu servicii web existente . . . 41

(3)

5.3.1 Exemplu de serviciu web XML-RPC folosind Apache XML-RPC . . 42 5.3.2 Generarea documentului XRDL pentru serviciul web . . . 42 5.4 Posibile extinderi . . . 42

6 Concluzii 44

(4)

1. Introducere

1.1 Generalit˘ at ¸i

Internetul evolueaz˘a ˆın ultimii ani ˆın direct¸ia aplicat¸iilor distribuite, iar tehnologiile care se dezvolt˘a cel mai mult ˆın acest sens sunt servciile web. Acestea reprezint˘a o solut¸ie foarte popular˘a pentru a pune la dispozit¸ia clientului prin internet funct¸ionalit˘at¸i cˆat mai diverse, eficiente, dar ¸si pesonalizate. Avantajul principal al serviciilor web este interoperabilitatea, fapt pentru care serviciile web pot fi implementate ˆın orice limbaj de programare, iar utilizatorul nu trebuie s˘a ¸stie ˆın ce limbaj a fost implementat sau ce distribut¸ie folose¸ste serviciul pe care dore¸ste s˘a ˆıl apeleze. Pentru apelul unei funct¸ionalit˘at¸i oferite de un serviciu clientul are nevoie de put¸ine informat¸i despre server, cum ar fi URL-ul la care serviciul este pus la dispozit¸ie, numele metodei apelate ¸si parametrii s˘ai.

Datorit˘a u¸surint¸ei de a implementa o aplicat¸ie distribuit˘a cu ajutorul unui serviciu web, toate companiile mari ˆıncep s˘a ofere, ˆın prezent, funct¸ionalit˘at¸ile noi prin intermediul serviciilor web. De asemenea pentru funct¸ionalit˘at¸ile deja existente, se implementeaz˘a servicii web echivalente. Un exemplu ˆın acest sens este Google care ofer˘a funct¸ionalit˘at¸i precum motor de c˘autare sau h˘art¸i prin intermediul serviciilor web. Astfel, ˆınglobarea funct¸ionalit˘at¸ilor oferite ˆın cadrul altor aplicat¸ii devine foarte simpl˘a.

Datorit˘a dezvolt˘arii rapide a serviciilor web, ˆın funct¸ie de diferitele tipuri de servicii (SOAP, REST, XML-RPC) acestea se extind pe direct¸ii diferite. Un avantaj major ˆın utilizarea serviciilor ar fi uniformizarea lor ¸si automatizarea unor act¸iuni. Pentru aceast˘a uniformizare rolul principal ˆıl det¸ine utilizarea fi¸sierelor de descriere a serviciilor web, ceea ce reprezint˘a tema central˘a a lucr˘arii de fat¸˘a.

1.2 Motivat ¸ie ¸ si obiective

Serviciile web pot fi caracterizate prin fi¸siere de descriere ˆın format XML, care este un format universal recunoscut. Dezavantajul este c˘a, dintre cele trei tipuri de servicii web (SOAP, REST ¸si XML-RPC), XML-RPC nu define¸ste un format standard pentru

(5)

fi¸sierul de descriere al serviciului. Serviciile de tip XML-RPC reprezint˘a categoria cea mai simpl˘a de servicii web. De asemenea datorit˘a simplit˘at¸ii lor constituie o solut¸ie ieftin˘a

¸si fiabil˘a pentru implementarea unor funct¸ionalit˘at¸i sub form˘a de servicii web. Cu toate acestea, este un tip de serviciu nu foarte extins. Consider c˘a existent¸a unui format de descriere a serviciului cu avantajele aferente le va cre¸ste popularitatea serviciilor XML- RPC. De aceea, obiectivul principal al acestei lucr˘ari este de a prezenta XRDL ca Dlimbaj de descriere pentru XML-RPC.

Utilizarea fi¸sierelor de descriere a serviciilor web este multipl˘a. În primul rând, pentru a simplifica implementarea unui serviciu, o solut¸ie este s˘a se genereze automat un schelet al serviciului web utilizând fi¸sierul de descriere al serviciului. Aceast˘a generare poate fi folosit˘a ¸si ˆın cazul ˆın care este nevoie de reconstruct¸ia serviciului web. De asemenea, pe baza fi¸sierului de descriere se pot genera automat schelete pentru client¸ii care doresc s˘a apeleze serviciul web.

Un alt obiectiv care nu a fost ˆınc˘a atins ˆın domeniul cercet˘arilor serviciilor web este compararea a dou˘a servicii web de tip diferit. De¸si au existat diferite propuneri de aplicat¸ii

¸si metode de comparare a dou˘a servicii web [3, 8], nici una dintre acestea nu este viabil˘a ˆın lipsa fi¸sierelor de descriere a serviciilor web. De aceea existent¸a unui standard pentru fi¸sierul de descriere a oric˘arui tip de servciiu web este foarte important˘a. Obiectivul lucr˘arii de fat¸˘a este s˘a atrag˘a atent¸ia asupra formatului XRDL de descriere pentru serviciile XML-RPC. ˆIn viitor, XRDL va putea fi acceptat ca ¸si standard pentru descrierea unui serviciu web de tip XML-RPC, iar utilizarea lui va deveni, dac˘a nu obligatorie, cel put¸in recomandat˘a la implementarea unui serviciu.

1.3 Contribut ¸ie personal˘ a

XRDL a pornit ca un proiect open-source ¸si nu este ˆınc˘a acceptat ca ¸si standard pentru XML-RPC Description Language. De¸si proiectul include cˆateva aplicat¸ii, precum generarea automat˘a a documentului XRDL pentru servicii ¸si client¸i scri¸si ˆın PHP sau C++/Qt [20], nu a fost demonstrat˘a echivalent¸a formatului XRDL cu serviciile XML- RPC. Contribut¸ia personal˘a principal˘a ˆın aceast˘a lucrare este demonstrat¸ia faptului c˘a XRDL este un limbaj de descriere valid pentru XML-RPC. Acest rezultat va fi publicat ˆın articolul intitulat ”XRDL: a valid Description Language for XML-RPC”, ˆın cadrul conferint¸ei Knowledge Engineering, Principles and Techniques Conference (KEPT) 2013.

Scopul articolului ¸si al lucr˘arii de fat¸˘a este s˘a aduc˘a o acceptare mai larg˘a a formatului XRDL ˆın lumea ¸stiint¸ific˘a.

Ca parte aplicativ˘a inovativ˘a lucrarea prezint˘a un generator automat pentru un servi-

(6)

ciu web de tip XML-RPC scris ˆın Java. Acest˘a aplicat¸ie are un rol foarte important. Dac˘a se dore¸ste ca toate serviciile web s˘a aib˘a fi¸siere de descriere, trebuie s˘a se ia ˆın considerare c˘a exist˘a deja foarte multe servicii web care nu au fi¸siere de descriere. De asemenea nu se dore¸ste complicarea procesului de implementare al unui serviciu web. Astfel, utilizˆand aceast˘a aplicat¸ie, fi¸sierul de descriere XRDL al unui serviciu web poate fi generat automat.

Avantajul solut¸ii implementate este c˘a nu depinde de distribut¸ia XML-RPC folosit˘a ˆın implementarea serviciului web (de exemplu Apache XML-RPC sauc Redstone XML-RPC pentru Java, XmlRpc++ pentru C++, xmlrpclib pentru Python, etc.). ˆIn cazul serviciilor web deja existente, modific˘arile care trebuie f˘acute sunt minore, find nevoie doar de apelul unei metode care genereaza documentul XRDL. Aplicat¸ia prezentat˘a completeaz˘a setul de generatoare automate existente ˆın proiectul opensource XRDL [20].

1.4 Structura lucr˘ arii

Lucrarea este structurat˘a pe 5 capitole: un capitol introductiv, trei capitole teoretice

¸si un capitol aplicativ. Capitolul introductiv, cel de fat¸˘a, prezint˘a pe scurt motivat¸ia ¸si obiectivele lucr˘arii, contribut¸ia original˘a ¸si structurarea lucr˘arii.

Capitolul 2 intitulat ”Servicii Web” cont¸ine trei subcapitole ¸si ˆıncepe cu prezenta- rea pe scurt a istoriei aparit¸iei serviciilor web. ˆIn urm˘atorul subcapitol sunt prezentate caracteristicile unui serviciu, cu accent pe avantajele oferite de serviciile web. Ultimul subcapitol descrie componentele ¸si arhitectura unui serviciu web.

Capitolul 3 se intituleaz˘a ”Servicii Web de tip XML-RPC”, iar primul subcapitol prezint˘a caracteriticile generale ale acestui tip de serviciu ˆın contrast cu cel˘alalte dou˘a tipuri, SOAP ¸si REST. Al doilea subcapitol descrie protocolul XML-RPC care documenteaz˘a modelul de date folosit, formatul cererii ¸si al r˘aspunsului.

Capitolul 4 intitulat ”Descriptorul XRDL” cuprinde ˆınc˘a trei subcapitole. Primul dintre acestea prezint˘a pe scurt scopul descriptorilor de servicii web. Urm˘atroul subcapitol descrie strucutra documentului XRDL. Ultimul subcapitol trateaz˘a validitatea formatului XRDL ca limbaj de descriere pentru XML-RPC.

Ultimul capitol prezint˘a partea aplicativ˘a a lucr˘arii ˆıncep˘and cu motivarea ¸si scopul aplicat¸iei. ˆIn al doilea subcapitol se specific˘a aplicat¸ia cu funct¸iile ¸si metodele oferite, urmˆand ca ˆın ultimul subcapitol s˘ase prezinte viitoare extinderi ˆın urma rezultatelor prezentate ˆın aceast˘a lucrare.

(7)

2. Servicii Web

2.1 Scurt˘ a istorie

La ˆınceputul anilor ’90 pentru servicii software distribuite se folosea tehnologia DCE (Distributed Computing Environment). DCE include un framework ¸si un toolkit care ajut˘a la dezvoltarea aplicat¸iilor distribuite client-server. Framework-ul are diferite componente, ¸si anume: DCE/RPC care este un mecanism pentru apeluri Remote Procedure Call, un serviciu de nume (naming service), un serviciu de timp (time service), un serviciu de autentificare ¸si un sistem de fi¸siere distribuit numit DCE/DFS (DFS- Distributed File System) [12]. DCE era bazat pe Unix, iar ca variant˘a pentru Windows, Microsoft a implementat o alt˘a versiune cunoscut˘a ca MSRPC. Primele framework-uri pentru sisteme distribuite (CORBA- Common Object Request Broker Arhitecture, Microsoft Dis- tributed COM, Java RMI - Remote Method Invocation) se bazeaz˘a tot pe framework-ul DCE/RPC. De¸si aceste framework-uri nu ofer˘a un standard pentru aplicat¸ii distribuite, ele au reprezentat un pas important pentru dezvoltarea aplicat¸iilor client-server, fiind totodat˘a precursoarele serviciilor web.

La sfˆar¸situl anilor ’90 a fost dezvoltat standardul XML (Extensible Markup Language) pentru a simplifica specificarea apelului peste web. Bazˆandu-se pe acest standard, ˆın 1998 Dave Winer a dezvoltat XML-RPC, primul tip de serviciu web, care era un framework mult mai simplu ce oferea suport pentru tipuri elementare de date. Avantajul major adus de XML-RPC este independent¸a de limbajul de programare si utilizarea protocolului HTTP (Hypertext Transfer Protocol, protocol ce a fost dezvoltat dupa aparit¸ia tehnologi- ilor bazate pe DCE/RPC) sau SMTP (Simple Mail Transfer Protocol) pentru transportul datelor. XML-RPC este un protocol simplu care se bazeaza pe modelul cerere-raspuns [7, 1].

ˆIn contradict¸ie cu simplitatea framework-ului XML-RPC a fost dezvoltat protocolul SOAP (Simple Object Access Protocol) care a vrut sa ofere suport pentru mai multe tipuri de date. ˆIn cadrul SOAP au fost numeroase propuneri de standarde pentru diferite categorii, cum ar fi: interoperabilitate, securitate, metadata, resurse ¸si altele. Astfel SOAP

(8)

devine un protocol foarte complex, care are ˆıns˘a avantajele sale, cum ar fi comunicarea SOAP care trece peste proxie-uri sau firewall-uri far˘a a fi nevoie s˘a se modifice protocolul ˆın sine [14]. Din cauza complexit˘at¸ii sale SOAP nu folose¸ste decˆat metoda POST a protocolului HTTP, deorece cel˘alalte metode nu ofera informat¸ii suficiente. Ca avantaj fat¸˘a de framework-urile bazate pe DEC/RPC, SOAP folose¸ste formatul XML pentru reprzenta- rea datelor. Astfel transferul de date poate fi verificat, validat ¸si procesat. Din punct de vedere teoretic, se consider˘a c˘a XML-RPC face parte din protocolul SOAP. Ce aduce ˆın plus protocolul SOAP este WSDL (Web Service Description Language) care reprezint˘a un contract al serviciului ¸si UDDI (Universal Description, Discovery and Integration), folosit pentru publicarea ¸si descoperirea serviciului web. O alt˘a utilizare a standardului WSDL este generarea automat˘a a unui client [7, 1].

Un alt standard dezvoltat ˆın anul 2000 a fost REST. Acest tip de serviciu web a pornit de la teza de doctorat a lui Fielding, care propune s˘a se foloseasc˘a toate metodele oferite de HTTP (GET, PUT, POST ¸si DELETE). Aceste caracteristici deosebesc REST de SOAP, care folose¸ste doar metoda POST a protocolului HTTP. Totodat˘a REST devine mai u¸sor de folosit pentru utilizator, dar mai greu de procesat de c˘atre calculator. Dezavantajul serviciilor REST a fost, la ˆınceput, lipsa unui standard pentru generarea client¸ilor sau a unui contract al serviciului. De aceea a fost propus WADL (Web Application description Language) de c˘atre World Wide Web Consortium. WADL reprezint˘a o descriere bazat˘a pe XML a serviciului REST. Totu¸si WADL nu a fost standardizat, deoarece nu este suportat la scar˘a larg˘a [7, 13, 1].

ˆIn evolut¸ia actual˘a a serviciilor web se consider˘a c˘a acestea se ˆımpart ˆın servicii de tipul SOAP, care includ ¸si serviciile XML-RPC, ¸si servicii de tipul REST. Dintre cele trei categorii prezentate, cea mai popular˘a pe piat¸˘a este categoria serviciilor de tip REST.

Acestea au ca avantaj fat¸˘a de serviciile de tip XML-RPC un suport pentru mai multe tipuri de date, iar avantajul principal fat¸˘a de serviciile de tip SOAP ˆıl reprezint˘a simplitatea.

Cu toate acestea, ˆın cele mai multe cazuri transferul de date ¸si documente suportat de XML-RPC este suficient pentru a implementa funct¸ionalit˘at¸ile dorite. De aceea lucrarea de fat¸˘aare ca subiect serviciile web de tip XML-RPC.

2.2 Caracteristicile unui serviciu web

Serviciile web reprezint˘a o categorie de tehnologii middleware de tip RPC (Remote Procedure Call) care permit apeluri peste web ¸si au ca scop principal interoperabilitatea oric˘aror dou˘a aplicat¸ii ¸si independent¸a de platform˘a ¸si de limbajul de programare. Astfel serviciile web aduc eterogenitate ˆın cadrul aplicat¸iilor distribuite. W3C (World Wide Web

(9)

Consortium) a publicat ˆın anul 2002 o serie de propuneri pentru a standardiza serviciile web. În aceast˘a perioad˘a serviciile web au ˆınceput s˘a se dezvolte ˆın diferite direct¸ii ¸si prin aceste propuneri W3C ˆıncearc˘a s˘a defineasc˘a arhitectura ¸si componentele serviciilor web, pentru a uniformiza modul de apel ˆıntre sistemul care ofer˘a serviciile ¸si cel care face cereri c˘atre aceste servicii. O alt˘a parte a propunerilor reprezint˘a o standardizare a modului ˆın care serviciile web sunt descoperite de sistemele care le apeleaz˘a. În cadrul acestor propuneri W3C define¸ste serviciul web ca un software proiectat astfel ˆıncât s˘a ofere suport pentru interoperabilitate peste ret¸ea [6, 5, 16].

Serviciile web au o serie de caracteristici care le confer˘a abilitatea de interoperabilitate, cea mai important˘a dintre acestea fiind faptul c˘a se bazeaz˘a pe XML (Extensible Mar- kup Language). XML este un standard propus de W3C pentru structurarea, stocarea ¸si transportul datelor care uniformizeaz˘a practic transferul de date ˆıntre aplicat¸ii. Se rezolv˘a astfel problema diferitelor reprezent˘ari de date. Avantajul principal adus de XML este reprezentarea serializat˘a a obiectelor din diferite limbaje de programare. De ment¸ionat este c˘a XML ajut˘a atˆat la transferul de date, cˆat ¸si al documentelor indiferen de com- plexitatea acestora. Astfel XML asigur˘a portabilitatea ¸si transparent¸a ˆın transferul de documente ˆıntre client si serverul web [5, 18].

Un alt avantaj al serviciilor web este ”cuplarea slab˘a” ˆıntre componenta care ofer˘a serviciile ¸si consumatorii serviciilor. Aceast˘a caracteristic˘a se refer˘a la leg˘atura dintre server si client, ¸si anume, serverul trebuie s˘a aibe posibilitatea s˘a modifice interfat¸a serviciului far˘a s˘a influent¸eze abilitatea clientului de a apela serviciul (far˘a s˘a fie nevoie s˘a se fac˘a modific˘ari suplimentare pe partea clientului). ˆIn cazul serviciilor web integrarea serverului cu clientul este foarte simpl˘a ¸si se poate ˆıntret¸ine u¸sor pe parcursul diferitelor modific˘ari ce apar [5].

Un serviciu web poate fi atât sincron cât ¸si asincron. Un serviciu asincron ˆıi ofer˘a clientului avantajul c˘a dup˘a apelul serviciului poate s˘a efectueze alte operat¸ii pân˘a prime¸ste r˘aspunsul de la serviciul web. Capacitatea unui serviciu de a fi asincron are un rol fun- damental ˆın cuplarea slab˘a a servului cu clientul [5].

Serviciile web ofer˘a client¸ilor posibilitatea s˘a apeleze funct¸ii sau servicii ale unor obiecte remote utilizand un protocol bazat pe XML. Astfel serviciul web poate fie s˘a ofere servicii proprii cu acelea¸si funct¸ionalit˘at¸i, fie s˘a transforme invocat¸iile primite ˆın invocat¸ii c˘atre componente EJB sau .NET [5].

Scopul serviciilor web este ca, ˆın final, s˘a se ajung˘a la o integrare a business-urilor automat˘a. Cˆand se descoper˘a o component˘a software nou˘a care ofer˘a funct¸ionalitatea dorit˘a, aceasta se acceseaz˘a, se integreaz˘a ¸si apoi se pot invoca metodele oferite de noul software. Toate aceste procese trebuie s˘a aib˘a loc autoamat f˘ar˘a intervent¸ie uman˘a. Din acest punct de vedere serviciul web poate fi v˘azut ca o interfat¸˘a care are implementate o

(10)

serie de funct¸ionalit˘at¸i ¸si care este accesibil˘a peste web. Astfel, serviciul web face leg˘atura ˆıntre furnizorul de servicii si clientul care dore¸ste s˘a le apeleze.

2.3 Componentele ¸ si arhitectura unui serviciu web

Un serviciu web se bazeaz˘a pe tehnologii standard Internet pentru a furniza serviciile dorite. Astfel clientul cand are nevoie de o funct¸ionalitate apeleaz˘a un serviciu web care ofer˘a funct¸ionalitatea respectiv˘a , iar acesta la rˆandul s˘au act¸ioneaz˘a pe post de interfat¸˘a ¸si apeleaz˘a aplicat¸ia care implementeaz˘a serviciul respectiv. Deoarece comunicarea se efectueaz˘a pe Internet, localizarea celor trei componente nu este important˘a, acestea putˆand fi localizate pe diferite ma¸sini. Pentru fiecare nivel din stiva de protocoale serviciile web s-au dezvoltat ˆın jurul unor protocoale, fie c˘a acestea sunt protocoale standard folosite pentru comunicat¸ia peste web sau protocoale specializate pentru serviciile web [1]. Aceast˘a stiv˘a ˆımpreun˘a cu protocoalele aferente se poate observa ˆın figura 2.1.

Figura 2.1: Stiva de protocoale pentru un serviciu web

Primul nivel al stivei se refer˘a la descoperirea serviciului web de c˘atre client¸ii care doresc s˘a ˆıl utilizeze. Serviciile web de tip SOAP folosesc ˆın acest sens serviciile UDDI.

Companii precum Microsoft, Google, IBM ofer˘a servicii UDDI publice care reprezint˘a di- rectoare globale ce cont¸in mai multe servicii oferite de diferit¸i client¸i ai companiilor respective. Exist˘a de asemenea servicii UDDI private folosite de corporat¸ii bancare, organizat¸ii guvernamentale, consort¸ii, etc. Totu¸si alte tipuri de servicii nu ofer˘a acest nivel de desco-

(11)

perire, ceea ce implic˘a faptul c˘a un client care vrea s˘a apeleze serviciile respective trebuie s˘a cunoasc˘a detaliile serviciului prin alte mijloace, cum ar fi un contract direct sau o ofert˘a citeboian.

Pentru a introduce un serviciu web intr-un director de servicii folosit de UDDI, trebuie ca acesta s˘a aib˘a o descriere. Protocoalele folosit pestru a descrie un serviciu web sunt WSDL ¸si WADL. WSDL e folosit, de obicei, de serviciile de tip SOAP ¸si cont¸ine o descriere a serviciului care ˆıi ofer˘a clientului toate informat¸iile necesare pentru a apela serviciul.

ˆIn aceast˘a descriere serviciul este definit ca o colect¸ie de porturi. Deoarece se bazeaz˘a pe XML, WSDL poate fi procesat automat de c˘atre anumite programe software [1, 17].

Serviciile de tip REST folosesc ca ¸si descriptor WADL care se bazeaz˘a de asemenea pe XML. WADL descrie serviciul sub forma unei mult¸imi de resurse care au parametrii si metode care descriu forma cererii ¸si a r˘aspunsului unei resurse. De¸si exist˘a dou˘a standarde pentru descrierea unui serviciu web, sunt ¸si servicii web care nu au fisier de descriere [1, 15].

De obicei serviciile web de tip XML-RPC nu ofer˘a o astfel de descriere, deoarece nu este obligatorie pentru ca un client s˘a poat˘a apela serviciul cu succes. ˆIn lucrarea de fat¸˘a vom prezenta un descriptor pentru serviciile de tip XML-RPC. Acesta, de¸si nu este ˆınc˘a larg r˘aspˆandit ¸si nici standardizat, este foarte util.

Pentru a ment¸ine caracteristica de interoperabilitate a serviciilor web cel mai important nivel din stiva prezentat˘a este cel de impachetare a datelor. Astfel cererile ¸si r˘aspunsurile unui serviciu web trebuie s˘a aib˘a un format standard, independent de platform˘a. De aceea pentru reprezentarea cererilor ¸si a r˘aspunsurilor se folose¸ste de obicei XML, dar se poate folosi ¸si JSON, HTML( sau XHML) sau text ASCII. Apoi pentru ˆımpachetarea acestora se folosesc cele trei standarde de servicii web: XML-RPC, SOAP

¸si REST [1].

Nivelul de transport se ocup˘a cu modalitatea ˆın care cererea gata ˆımpachetat˘a este trimis˘a la serviciul web, iar apoi raspunsul gata impachetat este trimis ˆınapoi la client.

Cel mai des folosit protocol pentru transportul peste web este HTTP (poate fi folosit ¸si alt protocol de transfer al resurselor) [1].

La nivelul ret¸ea, comunicarea ˆıntre dou˘a calculatoare se face de obicei prin Inter- net cu ajutorul protocolului bazat pe TCP/IP (Transmission Control Protocol/ Internet Protocol) [1].

Cu ajutorul primelor dou˘a nivele ale stivei de protocoale, descoperirea ¸si descrierea, clientul afl˘a toate informat¸iile necesare pentru a putea apela metode ale serviciului. Aceste informat¸ii nu se schimb˘a de la un apel la altul. De aceea ar fi redundant, atât pentru viteza de react¸ie a serviciului, cât ¸si pentru cantitatea de informat¸ii trimis˘a prin ret¸ea, ca acestea s˘a fie trimise de serviciu c˘atre client la fiecare apel de metod˘a. În acest scop se folose¸ste un proxy la client care salveaz˘a toate datele necesare, astfel ˆıncât, la al doilea

(12)

apel c˘atre serviciu, clientul sare peste etapele de descoperire si descriere a serviciului.

Etapele de ˆımpachetare, transport ¸si ret¸ea r˘amˆan ˆıns˘a valabile pentru fiecare apel f˘acut de client. Acestea au rolul de a urm˘ari cererea pe traseul s˘au de la client la server unde se transform˘a ˆıntr-un r˘aspuns, iar apoi r˘aspunsul pˆan˘a ˆın momentul ˆın care ajunge la client [1].

(13)

3. Servicii Web de tip XML-RPC

3.1 Generalit˘ at ¸i

XML-RPC ofer˘a programelor posibilitatea de a apela funct¸ii sau proceduri stocate pe un alt calculator prin ret¸ea. XML-RPC este cel mai simplu dintre cele trei tipuri de servicii web, ˆın primul rˆapentru c˘a refolose¸ste infrastructura existent˘a pentru comunicarea peste web : HTTP ¸si XML. Datorit˘a utiliz˘arii XML datele pot fi procesate de calculator

¸si ˆın acela¸si timp pot fi citite ¸si ˆınt¸elese de oameni. Astfel dezvoltatorii nu mai trebuie s˘a se concentreze pe proiectarea unor interfet¸e pentru utilizatori, cum era cazul pˆan˘a acum la toate aplicat¸iile web [4, 9].

XML-RPC are anumite limit˘ari datorit˘a tipurilor restrânse de date acceptate sau a utiliz˘arii protocolului HTTP. Dezavantajul folosirii protocolului HTTP este limitarea vitezei de r˘aspuns, a m˘arimii mesajelor transmise ¸si a utiliz˘arii serviciului la scar˘a larg˘a (ˆın cazul unor aplicat¸ii care trimit informat¸ii foarte des ¸si ˆıpentru care timpul de raspuns este vital). De asemenea, comunicarea prin HTTP este stateless, iar starea sistemului trebuie memorat˘a ˆın logica aplicat¸iei. Cu toate acestea, avantajul major adus de acest tip de servicii web este simplitatea. Datorit˘a simplit˘at¸ii sale integrarea sistemelor de tipuri diferite devine mult mai simpl˘a decâˆın cazul celorlalte servicii web. De asemenea nu apar dificult˘at¸i ˆın implementarea protocolului ¸si testarea interoperabilit˘at¸ii se face foarte u¸sor. De¸si XML-RPC ofer˘a suport pentru un numar mic de tipuri de date, are ˆıns˘aun nivel de granularitate suficient pentru a exprima informat¸iile necesare. Astfel XML-RPC este folosit atâde dezvoltatori care integreaz˘a sisteme distribuite, cât ¸si de dezvoltatori care creeaz˘a servicii publice. În cel de=al doilea caz, avantajul dezvoltatorului este c˘a folosind XML-RPC creeaz˘a o interfat¸˘a prin care serviciul este accesibil utilizatorilor, iar funct¸ionalit˘at¸ile le pot implementa ˆın orice limbaj de programare. Dezvoltatorii au control total asupra serverului, dar nu pot controla modul ˆın care client¸ii apeleaz˘a serviciile oferite [4, 9, 1].

Deoarece respect˘a paradigma RPC, protocolul XML-RPC se bazeaz˘a pe un mecanism simplu de cerere - r˘aspuns. Pentru a asigura comunicarea, implementarea protocolului nu

(14)

trebuie s˘a aib˘a detalii despre arhitectura ¸si infrastructura clientului care apeleaz˘a serviciul, ci trebuie doar s˘a publice o interfat¸˘a care poate fi apelat˘a peste web. Deoarece XML- RPC se bazeaz˘a pe schimburi de informat¸ii prin apeluri procedurale, nu este obligatoriu s˘a respecte arhitectura client-server. XML-RPC suport˘a atˆat comunicarea peer-to-peer, cˆat ¸si comunicarea client-server. De asemenea, un program poate include ˆın acel¸si timp o parte de server XML-RPC ¸si o parte de client XML-RPC [4, 9].

Dezvoltatorii serviciilor web XML-RPC nu au nevoie s˘a cunoasc˘a toate detaliile in- terne despre funct¸ionarea protocolului. De cele mai multe ori se folosesc libr˘arii care se ocup˘a cu detaliile de implementare ale protocolului, cum ar fi ˆımpachetarea ¸si transportul datelor. Singurul efort pe care dezvoltatorii este nevoie s˘a ˆıl fac˘a este s˘a integreze aplicat¸ia cu libr˘ariile folosite, care de obicei ofer˘a un API u¸sor de utilizat ¸si de ˆınt¸eles. De asemenea XML-RPC le ofer˘a posibilitatea dezvoltatorilor de a folosi un standard ˆın crearea protocolului pentru integrarea diferitelor sisteme. Acest standard ofer˘a posbilitatea refolosirii funct¸ionalit˘at¸ilor implementate. Acest lucru nu era posibil pˆan˘a la aparit¸XML-RPC, deoarece fiecare dezvoltator concepea alt protocol pentru ca dou˘a sisteme s˘a comunice ˆıntre ele, iar dou˘a astfel de protocoale diferite nu puteau comunica ˆıntre ele. Astfel standardiza- rea salveaz˘a timp ¸si efort prin refolosirea implement˘arilor unor funct¸ionalit˘at¸i XML-RPC.

O caracteristic˘a a serviciilor web de tip XML-RPC care paote fi considerat˘a ˆın acela¸si timp un avantaj ¸si un dezavantaj este trecerea de firewall-uri cu ajutorul HTTP. Avan- tajul este, evident, faptul c˘a serviciul poate fi utilizat f˘a r˘a ca utilizatorii s˘a fie nevoit¸i s˘a modifice politica de filtrare a pachetelor pentru a putea apela funct¸ionalit˘at¸iile oferite de un serviciu web. Dezavantajul ˆıl reprezint˘a problemele de securitate datorate u¸surint¸ei cu care apelurile de tip cerere-r˘aspuns c˘atre serviciul web trec de firewall. Astfel calcula- toarele pe care se afla o interfat¸˘a pentru un serviciu web XML-RPC sunt vulnerabile ˆın fat¸a unor atacuri peste web [9].

Specificat¸iile XML-RPC nu sunt foarte complexe, deoarece scopul protocolului este s˘a aib˘a un format simplu, u¸sor extensibil. De asemenea standardul a fost gˆandit astfel ˆıncˆat s˘a fie u¸sor de implementat ¸si s˘a se poat˘a adapta repede la alte medii de programare sau la alte sisteme de operare [11].

3.2 Protocolul XML-RPC

Un apel c˘atre un serviciu XML-RPC implic˘a doi actori principali: un client ¸si un server, reprezentat printr-un URL (Uniform Resource Locator). Documentul XML folosit ˆın cererea ¸si r˘aspunsul XML-RPC are o sintax˘a simpl˘a ¸si bine definit˘a de DTD (Document Type Definition), dup˘a cum se observ˘a ˆın figura 3.1 [1].

(15)

Figura 3.1: XML-RPC.dtd Pa¸sii urmat¸i ˆın cadrul apelului sunt urm˘atorii:

1. Clientul XML-RPC preg˘ate¸ste apelul c˘atre server, ˆın care specific˘a metoda pe care vrea s˘a o apeleze ˆımpreun˘a cu parametrii necesari ¸si serverul care implementeaz˘a metoda.

2. Clientul XML-RPC creeaz˘a un document XML care cont¸ine numele metodei ¸si parametrii pe care ˆıl trimite c˘atre server printr-o cerere HTTP de tip POST.

3. Serverul XML-RPC prime¸ste cererea POST ¸si trimite fi¸sierul XML mai departe la un listener XML-RPC.

4. Listener-ul XML-RPC parseaza fi¸sierul XML primit pentru a obt¸ine numele metodei

¸si parametrii cu care clientul vrea s˘a apeleze metoda. Apoi apeleaza local metoda cu parametrii respectivi.

5. Componenta XML-RPC listener prime¸ste r˘aspunsul de la metod˘a ¸si ˆıl ˆımpacheteaza sub forma unui document XML.

6. Serverul web trimite r˘aspunsul la cererea POST cu corpul format din documentul XML.

(16)

7. Clientul XML-RPC prime¸ste r˘aspunsul de la server ¸si parseaz˘a documentul XML pentru a-i trimite clientului r˘aspunsul la apelul f˘acut ˆın forma cerut˘a.

8. Clientul prime¸ste valoarea dorit˘a¸si poate continua procesarea datelor.

Din pa¸sii prezentat¸i observ˘am c˘a folosirea protocolului HTTP ˆınseamn˘a c˘a XML-RPC este stateless ¸si sincron, deoarece r˘aspunsul trebuie s˘a fie primit pe aceea¸si conexiune HTTP ca ¸si cererea. Se pot implementa de asemenea sisteme XML-RPC asincrone, ˆıns˘a pentru aceasta este nevoie de mai multe cicluri cerere - r˘aspuns [1, 9].

Specificat¸iile tehnice XML-RPC cont¸in trei p˘art¸i principale, ¸si anume:

• modelul de date XML-RPC

• structura cererii XML-RPC

• structura r˘aspunsului XML-RPC

Fiecare dintre acestea vor fi descrise pe scurt ˆın urm˘atoarele trei subcapitole.

3.2.1 Modelul de date XML-RPC

Specificat¸iile XML-RPC definesc ¸sase tipuri simple de date ¸si dou˘a tipuri complexe.

De¸si acestea reprezint˘a un num˘ar foarte mic din toate tipurile de date existente ˆın diferite limbaje, acestea sunt cele mai des utilizate ¸si de obicei sunt suficiente pentru a exprima informat¸iile dorite. Cererea poate avea mai mult¸i parametrii, tot¸i exprimat¸i prin aceste tipuri de date, iar r˘aspunsul poate returna o singur˘a valoare din acea¸si list˘a de tipuri de date. Tipurile simple de date sunt reprezentate prin elemente simple XML care reprezint˘a tipul de date ¸si al c˘aror cont¸inut este valoarea. Acest element este inclus ˆıntr-un element de tipul <value> </value> [1, 9, 4].

Numerele ˆıntregi reprezint˘a prima categorie din cadrul tipurilor de date simple. Se pot reprezenta numere pe 32 bit¸i cuprinse ˆıntre -2147483648 (−2³¹) ¸si 2147483647 (2³¹−1).

Pentru reprezentarea numerelor ˆıntregi exist˘a dou˘a posibilit˘at¸i echivalente, ¸si anume:

sau

Elementul < i4> este denumit astfel datorit˘a reprezent˘arii num˘arului ˆıntreg pe 32 bit¸i, adic˘a 4 octet¸i. Cont¸inutul tag-ului nu trebuie s˘a cont¸ina alte caractere ˆın afara de prefixul

− sau + ¸si cifre. Acestea sunt cˆateva exemple de numere ˆıntregi reprezentate conform specificat¸iilor XML-RPC:

(17)

Numerele cu virgul˘a flotant˘a pot fi reprezentate binar pe 64 bit¸i conform standardului IEEE 754. Numerele cu virgul˘a flotant˘a care pot fi reprezentate au modulele cuprinse ˆıntre 10⁻³²⁴ ¸si 10³⁰⁸. Pentru a marca valori nedefinite standardul IEEE 754 propune utilizarea valoarii N aN(not a number), dar aceasta nu are o reprezentare echivalent˘a ˆın XML-RPC ¸si nu poate fi folosit˘a ˆıntr-o cerere sau un r˘aspuns. Aceste numere se reprezint˘a ˆın standardul XML-RPC prin urm˘atorul element:

Exemple de astfel de numere ar fi:

Caracterele valide ˆın reprezentarea unui num˘ar cu virgul˘a flotant˘a sunt similare cu cele de la numerele ˆıntregi, dar ˆın plus apare punctul zecimal.

Elementele de tip boolean pot avea ca valori doar 1, care reprezint˘a adev˘arat, sau 0, care reprezint˘a fals. ˆIn standardul XML-RPC aceste valori se reprezint˘a dupa cum urmeaz˘a:

Avˆand ˆın vedere limitarea valorilor posibile pentru un element boolean, singurele reprezent˘ari posibile sunt urm˘atoarele:

Pentru elementele de tip string exist˘a dou˘a reprezent˘ari echivalente. Acestea pot fi incluse doar ˆın tag-ul value sau ˆın tag-ul string care este inclus la rˆandul s˘au ˆıntr-un tag value. ˆIn elemente de tip string se poate folosi orice tip de caracter, dar caracterele speciale pentru XML, cum ar fi < > & se pot introduce astfel : <, >, respectiv

&. Ca exemplu, un string poate fi reprezentat prin cele dou˘a metode astfel:

<value>Elaine\ \&\ Co.</value>$ (av\ai nd ca valoare \sh irul $Elaine\ \&\ Co.) sau

<value><string>Elaine\ \&\ Co.</string></value>

Ca ¸si reprezentare se poate folosi atât coldul ASCII, care este cel mai des ˆıntâlnit, cât ¸si UNICODE cu standardul ISO 8859-1.

(18)

Elementele de tip dat˘a calendaristic˘a se reprezint˘a conform unuia dintre profilele standardului ISO 8601, iar formatul folosit este an lun˘a zi or˘a minut secund˘a. De aceea se folose¸ste tag-ul dateTime.iso8601:

<value><dateTime.iso8601>AAAALLZZTHH:MM:SS/dateTime.iso8601></value>

Un exemplu de dat˘a calendaristic˘a reprezentat˘a dup˘a standardul XML-RPC este:

Specificat¸ia XML-RPC ment¸ioneaz˘a c˘a det¸in˘atorul server-ului unde este implementat serviciul trebuie s˘a specifice ˆın documentat¸ie fusul orar. De aceea se recomand˘a s˘a se foloseasc˘a GMT, umrˆand ca aplicat¸iile s˘a converteasc˘a valoarea primit˘a la ora locala ˆın funct¸ie de fusul orar local.

Pentru a putea trimite prin XML-RPC caractere care sunt speciale ˆın XML se folose¸ste sistemul de codificare base 64. Acest sistem de codificare se bazeaz˘a pe urm˘atoarele idei:

• S¸irul de octet¸i este prelungit, dac˘a este cazul, cu zerouri, astfel ˆıncˆat lungimea ¸sirului s˘a fie un multiplu de trei octet¸i.

• Fiecare grupa de trei octet¸i este ˆımp˘art¸it ˆın patru grupe de cˆate 6 bit¸i.

• Fiecare grup de 6 bit¸i poate fi reprezentat ca un num˘ar ˆıntreg ˆıntre 0 ¸si 63. Astfel se poate ˆınlocui cu caracterul de pe pozit¸ia corespunz˘atoare din lista celor 64 de caractere ( 26 litere mari, 26 litere mici, 10 cifre, caracterul +, caracterul /)

• ˆIn cazul ˆın care grupul de 6 bit¸i este alc˘atuit doar din zerouri, acesta se reprezint˘a prin caracterul =.

Dac˘a lu˘am ca exemplu ¸si rul ASCII ”Baza”, acesta se reprezint˘a conform sistemului de codificare astfel:

Constanta nul˘a se reprezint˘a prin tag-ul < nil/ >

Toate tipurile de date simple prezentate [11, 1, 9, 4] sunt sumarizate ˆın figura 3.2.

(19)

Figura 3.2: Tipuri de date simple XML-RPC

Pentru a putea reprezenta informat¸ii mai complexe protocolul XML-RPC propune dou˘a tipuri de date compuse: tablou (array) ¸si structur˘a. Conform specificat¸iilor, tipurile de date compuse pot cont¸ine una sau mai multe valori, care pot fi la rˆandul lor de tip simplu sau de un tip compus deja definit.

Un tablou este o secvent¸˘a de valori XML-RPC. Aceste valori nu sunt obligatoriu toate de acela¸si tip. Tabloul poate fi v˘azut ca o list˘a de elemente nenumerotate, care nu pot fi accesate printr-un index ca ˆın alte limbaje de programare. Elementul tablou este indicat de tag-ul array care cont¸ine la rˆandul s˘au un tagdata [1, 11, 9]. Conform standardului XML-RPC, un element de tip tablou se reprezint˘a ˆın forma urm˘atoare:

<value>

<array>

<data>

<value>valoare</value>

...

<value>valoare</value>

</data>

</array>

</value>

Un exemplu simplu de tablou este:

(20)

<value>

<array>

<data>

<value><string>cantitate</string></value>

</data>

</array>

<value>

Se pot reprezenta tablouri multidimensionale prin includerea unui tablou ˆın alt tablou.

Un exemplu de tablou multidimensional este urm˘atorul:

<value>

<array>

<data>

<value>

<array>

<data>

<value><string>linia 1, coloana 1</string></value>

</data>

</array>

</value>

<value>

<array>

<data>

</data>

</array>

</value>

</data>

</array>

</value>

Elementul de tip structur˘a este format din perechi de forma nume-valoare. Numele sunt de tip string, iar valoarea poate fi de orice tip valid ˆın XML-RPC. O structur˘a are

(21)

urm˘atoarea form˘a:

<value>

<value>valoare_1</member>

...

<value>valoare_n</value>

</struct>

</value>

Specificat¸ia XML-RPC nu impune ca numele elementelor sa fie unice ˆın cadrul unei structuri. Cu toate acestea, deoarece de obicei implement˘arile XML-RPC convertesc automat datele de tip structur˘a din XML-RPC ˆın date de tip dict¸ionar ˆın limbajul respectiv, se recomand˘a ca numele s˘a fie unice [1, 9]. Urm˘atorul element este un exemplu de structur˘a ˆın care numele membrilor nu se repet˘a:

<value>

<member>Prenume</member>

<value>Vasile</value>

<member>Locul na\sh terii</member>

<value>Sibiu</value>

</struct>

</value>

Un element de tip structur˘a poate de asemenea s˘a cont¸in˘a alte elemente compuse, adic˘a structuri sau tablouri.

3.2.2 Formatul cererii

Cererea XML-RPC reprezint˘a o cerere HTTP prin metoda POST care are ca ¸si corp un document XML. Antetul cererii cont¸ine o serie de atribute, dintre care o parte sunt obligatorii, ¸si anume:

• Method - specific˘a faptul c˘a metoda folosit˘a ˆın cerere este POST

(22)

• User-Agent - reprezint˘a ce implementare de XML-RPC se folose¸ste, de exemplu ws-xmlrpc de la Apache

• Host - indic˘a adresa ma¸sinii server care va trata cererea

• Content-Type - trebuie s˘a aib˘a valoarea text/xml, deoarece corpul cererii este un

document XML

• Contetn-Length - indic˘a lungimea corpului cererii

Corpul cererii este format dintr-un document XML care respect˘a sintaxa definit˘a ˆın schema 3.1. Astfel r˘ad˘acina documentului este elementul methodCall care cont¸ine dou˘a elemente methodName ¸si params. Tag-ul methodName cont¸ine numele metodei pe care utilizatorul vrea s˘a o apeleze. Elementul params cont¸ine lista de parametrii cu care se apeleaz˘a funct¸ia. Fiecare parametru este specificat printr-un element de tipul param

¸si cont¸ine un element de tipul value cu valoarea parametrului. În cazul apelului unei metode f˘ar˘a parametrii coprul cerererii trebuie s˘a cont¸in˘a totu¸si elementul params. Un exemplu de cerere valid˘a XML-RPC (considerând c˘a lungimea cererii ˆıbytes corespunde), care cont¸ine atât headere-ul HTTP, cât ¸si documentul XML care reprezint˘a corpul cererii, este urm˘atorul:

POST /xmlrpc HTTP 1.0

User-Agent: unClientXMLRPC/1.0 Host: 192.168.124.5

Content-Type: text/xml Content-Length: 235

<?xml version="1.0"?>

</params>

</methodCall>

(23)

3.2.3 Formatul r˘ aspunsului

R˘aspunul XML-RPC este, ca ¸si ˆın cazul cererii de tip HTTP ¸si cont¸ine un header HTPP ¸si un corp al cererii ˆın format XML. Atributele din header-ul HTTP care sunt obligatorii ˆın acest caz sunt urm˘atoarele:

• Server - indic˘a server-ul care a procesat r˘aspunsul XML-RPC

• Content-Type- trebuie s˘a aib˘a valoareatext/xml, deoarece corpul r˘aspunsului este un document XML

• Content-Length - indic˘a lungimea corpului r˘aspunsului

Corpul r˘aspunsului este format, ca ¸si ˆın cazul r˘aspunsului, dintr-un document XML care respect˘a sintaxa definit˘a ˆın schema 3.1. Elementul r˘ad˘acin˘a al r˘aspunsului este tag-ul methodResponse. Acesta cont¸ine un alt fiu, care ˆın funct¸ie de procesarea cererii cu succes sau nu poate fi params sau fault.

Dac˘a funct¸ia apelat˘a u a dat nici o eroare, atunci este prezent elementulparams care cont¸ine un alt element param cu valoarea rezultatului funct¸iei apelate. Dac˘a rezultatul trebuie sa returneze mai multe valori, acestea trebuie s˘a fie ˆınglobate ˆıntr-un tip de dat˘a compus, deoarece, spre deosebire de cerere, ˆın cazul r˘asunsului elementul params poate avea un singur fiuparam. Urm˘atorul este un exemplu de r˘aspuns ˆıntors de server, ˆın cazul unui apel cu succes al funct¸iei dorite, la cererea dat˘a ca exemplu anterior, :

<?xml version="1.0">

</params>

</methodResponse>

ˆIn cazul ˆın care apelul metodei returneaz˘a vreo eroare (metoda nu este g˘asit˘a, apelul metodei nu s-a executat corect, metoda nu returnat un rezultat valid), protocolul HTTP ofer˘a un mecanism de aruncare de except¸ii. ˆIn acest caz este prezent tag-ul fault care cont¸ine un tag value. Valoarea este reprezentat˘a sub forma unei structuri cu doi membrii. Primul membru indic˘a faultCode printr-un num˘ar ˆıntreg, iar al doilea membru cont¸ine uns tring ce reprezint˘a faultString. Un exemplu de r˘aspuns ˆın caz de eroare este urm˘atorul:

<?xml version="1.0">

(24)

<fault>

<value>

<name>faultCode</name>

</member>

<name>faultString</name>

<value><string>No such method.</string></value>

</member>

</struct>

</value>

</fault>

</methodResponse>

Un dezavantaj al standardului XML-RPC este c˘a nu include o standardizare a codurilor

¸si a mesajelor fault. Astfel acestea difer˘a ˆın funct¸ie de implementarea XML-RPC ¸si nu pot fi tratate automat de c˘atre aplicat¸ia clientului. Faptul c˘a r˘aspunsurile sunt trimise prin HTTP, nu ajut˘a la detectarea eventualelor erori, deoarece codul de r˘aspuns HTTP va fi 200 OK chiar dac˘a corpul r˘aspunsului cont¸ine un element de tip fault.

Dup˘a ce r˘aspunsul a fost trimis se ˆınchide conexiunea cu clientul. Dac˘a dup˘a aceea acesta face ˆınc˘a o cerere se deschide o nou˘a conexiune XML-RPC.

(25)

4. Descriptorul XRDL

4.1 Scopul descriptorilor de servicii web

Dintre cele trei tipuri de servicii web, SOAP este singurul care are ˆın mod obligatoriu un fi¸sier de descriere al serviciului bazat pe standardul WSDL. REST propune ca format pentru descriptorul serviciului WADL, dar existent¸a acestui fi¸sier de descriere la publicarea serviciului este opt¸ional˘a. ˆIn contrast cu cel˘alalte dou˘a tipuri de servicii, standardul XML-RPC nu cont¸ine nici un format pentru descriptorul serviciului, iar acest fi¸sier de descriere nu este nici obligatoriu. Faptul c˘a descrierea serviciului nu ese obligatorie este considerat de mult¸i cercet˘atori ca un avantaj pentru c˘a ˆıi confer˘a standardului simplitate [19]. Cu toate acestea, lipsa fi¸sierului de descriere al unui serviciu este un inconvenient pentru diferite tool-uri care utilizeaza descriptorul unui serviciu web.

Scopul principal este de a uniformiza serviciile web. Acest lucru presupune dou˘a idei principale : generarea automat˘a uniformizat˘a a diferitelor tipuri de servicii web ¸si a unor proxy-uri pentru client¸i ¸si compararea serviciilor web. Pentru generarea automat˘a a unui serviciu web este nevoie de fi¸sierul de descriere al acestuia, deoarece f˘ar˘a acel fi¸sier generarea automat˘a devine foarte complicat˘a sau chiar imposibil˘a [2]. De asemenea compararea a dou˘a servicii web nu este posibil˘a far˘a existent¸a fi¸sierelor de descriere a celor dou˘a servicii web, indiferent de abord˘arile propuse [8, 3].

Avˆand ˆın vedere utiliz˘arile fi¸sierelor de descriere XML-RPC, consider c˘a existent¸a unui limbaj de descriere al serviciului XML-RPC este foarte important˘a. ˆIn cele ce urmeaz˘a voi prezenta XRDL ca limbaj de descriere pentru XML-RPC, care de¸si nu este standardizat este un pas important pentru descrierea serviciilor de acest tip.

4.2 Structura documentului XRDL

XRDL (XML-RPC Description Language) este un proiect open-source creat ca ˆınlocuitor pentru WSDL ˆın cazul serviciilor de tip XML-RPC. XRDL este definit printr-o schema XSD ([20]) care descrie structura unui fi¸sier XRDL valid:

(26)

<?xml version="1.0"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="service">

<xs:complexType>

<xs:sequence>

<xs:element name="types">

<xs:complexType>

<xs:sequence>

<xs:element name="type" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="member" minOccurs="0" maxOccurs="unbounded">

<xs:complexType mixed="true">

<xs:attribute name="type" type="xs:string" />

</xs:complexType>

</xs:element>

</xs:sequence>

<xs:attribute name="name" type="xs:string" />

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="methods">

<xs:complexType>

<xs:sequence>

<xs:element name="method" minOccurs="0" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="param" minOccurs="0" maxOccurs="unbounded">

<xs:complexType mixed="true">

<xs:attribute name="type" type="xs:string" use="required" />

</xs:complexType>

</xs:element>

</xs:sequence>

<xs:attribute name="result" type="xs:string" />

(27)

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

<xs:attribute name="url" type="xs:string" />

<xs:attribute name="ns" type="xs:string" />

</xs:complexType>

</xs:element>

</xs:schema>

Dup˘a cum se observ˘a ˆın schema XSD, documentul XRDL are dou˘a mari sect¸iuni:

• o sect¸iune ˆın care se definesc tipurile de date complexe folosite de serviciul respectiv

• o sect¸iune care descrie metodele serviciului web

A doua sect¸iune define¸ste metodele oferite de serviciul web ˆımpreun˘a cu parametrii ¸si rezultatul returnat. Tipul de date pentru parametrii ¸si rezultat se specific˘a cu ajutorul atributuluitypecare are ca ¸si valoare un element de tip string. Teoretic pentru elementul type orice valoare care reprezint˘a un tip de date valid ˆın XML, va genera un document XML valid. Cu toate acestea, pentru a descrie un serviciu XML-RPC este nevoie doar de datele simple din standardul XML-RPC, ¸si anume: int sau i4, double, boolean, string, dataTime.iso8601 sau base64, iar tipurile de date compuse din XML-RPC trebuie speci- ficate ˆın prima sect¸iune a documentului XRDL. De aceea restrict¸ionez valorile luate de atributul typeˆıntr-un document XRDL la cele 6 valori simple din standardul XML-RPC sau la o valoare complex˘a definit˘a ˆın prima parte a documentului.

4.3 Validitatea XRDL ca limbaj de descriere pentru XML-RPC

Proiectul open-source XRDL define¸ste structura documentului XRDL ¸si propune cˆateva aplicat¸ii (generarea automat˘a a documentului XRDL pentru servicii ¸si client¸i scri¸si ˆın PHP sau C++/Qt) [20]. Ceea ce lipse¸ste ˆıns˘a din documentat¸ia proiectului este o demonstrat¸ie a faptului c˘a XRDL este un limbaj de descriere valid pentru XML-RPC. Acest lucru presupune demonstrarea unei echivalent¸e, ¸si anume c˘a orice serviciu web de tip XML-RPC

(28)

poate fi descris printr-un document XRDL ¸si orice document valid XRDL descrie un serviciu web XML-RPC valid [10].

4.3.1 Existent ¸a unui document XRDL pentru orice serviciu XML- RPC

Prima parte a echivalent¸ei const˘a ˆın demonstrarea urm˘atoarei teoreme:

Teorema 4.3.1 Orice serviciu XML-RPC poate fi caracterizat printr-un document XRDL.

Pentru a caracteriza un serviciu web trebuie descrise metodele implementate. Pentru ca utilizatorul s˘a ¸stie cum s˘a apeleze metodele are nevoie de numele funct¸iei, datele de intrare necesare ¸si rezultatul pe care ˆıl returneaz˘a. Dup˘a cum se observ˘a din schema XSD a documentului XRDL orice metod˘a poate fi descris˘a printr-un mecanism simplu.

R˘amˆane ˆıns˘a de demonstrat c˘a orice tip de date are echivalent ˆın XRDL. Pentru tipurile simple de date acest lucru este evident. Mai trebuie ar˘atat c˘a tipurile compuse din XML- RPC pot fi definite ˆın XRDL. ˆIn paragrafele urm˘atoare se trateaz˘a cele dou˘atipuri de date compuse: tablou ¸si structur˘a.

Dupa cum am vazut ˆın sect¸iunea 3.2.1, un element de tip tablou poate cont¸ine atât elemente de tip simplu, cât ¸si elemente de tip compus. Astfel putem defini un tablou unidimensional ca un tablou care cont¸ine doar elemente de tip simplu, iar dac˘a cont¸ine cel put¸in un element de tip compus, atunci tabloul va fi multidimensional. Voi dmeonstra mai ˆıntâi urm˘atoarea lem˘a:

Lema 4.3.2 Un tablou unidimensional cu n elemente poate fi definit ca tip de date ˆın XRDL, ∀n∈N.

Voi demonstra lema 4.3.2 folosind induct¸ia matematic˘a. Pentru cazul n = 1 tabloul cu un element va avea ca form˘a general˘a urm˘atoarea structur˘a:

<array>

<data>

<_tipSimpluDeDate>_valoare</_tipSimpluDeDate>

</data>

</array>

tipSimpluDeDate va fi ˆınlocuit cu cu oricare dintre tipurile: string, int/i4, double, boolean, dateTime.iso8601 sau base64, iar valoareva fi ˆınlocuit cu o valoare corespun˘atoare tipului de date ales. Corespunz˘atorul acestui tablou ˆın XRDL va fi urm˘atorul tip de date complex:

(29)

<member type="_tipSimpluDeDate"> _membru_1</member>

</type>

tablou 1 elemeste numele ales pentru noul tip de date definit, tipSimpluDeDate este

acela¸si tip definit mai sus, iar membru 1 este numele dat membrului din tablou (Obs.

Numele date tipului customizat de date definit sau a membrilor tipului sunt irelevante).

Se observ˘a c˘a acest tip customiza de date din XRDL este echivalent cu cel anterior ˆın XML.

Pentru pasul inductiv presupunem c˘a un tablou unidimensional cu k elemente poate fi definit ca tip complex de date ˆın XRDL. R˘amˆane de demonstrat c˘a un tablou cu k+1 elemente poate fi de asemenea definit ˆın XRDL. Fie tabloul cu k+1 elemente urm˘atorul:

<array>

<data>

<value>

<_tipSimpluDeDate_1>_valoare_1</_tipSimpluDeDate_1>

</value>

<value>

</value>

...

<value>

<_tipSimpluDeDate_k>_valoare_k</_tipSimpluDeDate_k>

</value>

<value>

<_tipSimpluDeDate_k+1>_valoare_k+1</_tipSimpluDeDate_k+1>

</value>

</data>

</array>

Conform presupunerii putem defini ˆın XRDL un tip de date complex care s˘a cont¸ina primele k elemente ale tabloului. Fie acest tip definit astfel:

<member type="_tipSimpluDeDate_1">_ membru_1</member>

<member type="_tipSimpluDeDate21">_ membru_2</member>

...

<member type="_tipSimpluDeDate_k-1">_ membru_k-1</member>

<member type="_tipSimpluDeDate_k"> _membru_k</member>

(30)

</type>

ˆIn cele ce urmeaz˘a se poate defini un tablou similar prin extinderea acestuia cu un element:

<member type="_tipSimpluDeDate_1">_ membru_1</member>

<member type="_tipSimpluDeDate_2"> membru_2</member>

...

<member type="_tipSimpluDeDate_k-1">_ membru_k-1</member>

<member type="_tipSimpluDeDate_k"> membru_k</member>

<member type="_tipSimpluDeDate_k+1">_ membru_k+1</member>

</type>

Se oserv˘a c˘a elementul tablou k+1 elem este chiar echivalentul din XRDL al taboului din XML cu k+1 elemente. ˆIn concluzie, rezult˘ac˘a ipoteza indcut¸ie este adev˘arat˘a pntru orice n ∈N.

ˆIn cele ce urmeaz˘ase trateaz˘a cazul tablourilor multidimensionale (tablouri ce cont¸in cel put¸in un element de tip tablou sau structur˘a). Fie urm˘atoarea lem˘a:

Lema 4.3.3 Un tablou n-dimensional poate fi definit ca tip de date ˆın XRDL, ∀n ∈N.

Un exemplu de tablou bidimensional este urm˘atorul:

<array>

<data>

<value>

</value>

<value>

<array>

<data>

</data>

</array>

</value>

</data>

</array>

(31)

ˆInainte ˆıns˘a de a demonstra lema 4.3.3 trebuie tratat ¸si cel˘alalt tip de date complex, structura. Dup˘a cum am v˘azut ˆın sectt¸3.2.1 structura poate fi de asemenea unidimensional˘a sau multidimensional˘a. Prima lem˘a trateaz˘a structurile unidimensionale:

Lema 4.3.4 O strucutr˘a unidimensional˘a cu n perechi de elemente nume-valoare poate fi definit˘aca tip de date ˆın XRDL, ∀n∈N.

Pentru cazul particular din cadrul induct¸iei se trateaz˘a o strucutra cu o pereche nume- valoare:

<name>_membru_1</name>

<value>

<_tipSimpluDeDate>_valoare_1</_tipSimpluDeDate>

</value>

</member>

</struct>

tipSimpluDeDate va fi ˆınlocuit cu unul din tipurile: string, int/i4, double, boolean dateTime.iso8601 sau base64. Tipul de date echivalent ˆın XRDL va fi:

<member type="string">_membru_1</member>

<member type="_tipSimpluDeDate">_valoare_1</member>

</type>

Pentru pasul inductiv se presupune c˘a o structur˘a unidimensional˘a cu k elemente poate fi definit˘a ca tip complex de date ˆın XRDL. R˘amˆane de demonstrat c˘a o structur˘a unidimensional˘a cu k+1 elemente poate fi definit˘a ˆın XRDL. Fie structura cu k+1 elemenete urm˘atoarea:

<value>

</value>

</member>

...

(32)

<name>_membru_k</name>

<value>

</value>

</member>

<name>_membru_k+1</name>

<value>

</value>

</member>

</struct>

Dac˘a lu˘am ˆın considerare doar primele k perechi ale structurii, acestea formeaz˘a o alt˘a structur˘a cu k perechei nume-valoare. Aceast˘a structur˘a cu k elemente poate fi definit˘a ˆın XRDL conform presupunerii inductive astfel:

<member type="_tipSimpluDeDate_1">_valoare_1</member>

...

<member type="string">_membru_k-1</member>

<member type="_tipSimpluDeDate_k-1">_valoare_k-1</member>

<member type="string">_membru_k</member>

<member type="_tipSimpluDeDate_k">_valoare_k</member>

</type>

Pornind de la aceast˘a strutur˘a se poate construi un alt tip complex care ˆıl extinde pe acesta cu ˆınc˘a doi membrii (o pereche de tipul membru-valoare):

<member type="_tipSimpluDeDate_1 ">_valoare_k</member>

...

<member type="string">_membru_k+1</member>

<member type="_tipSimpluDeDate_k+1">_valoare_k+1</member>

</type>

(33)

Elementul structura k elem este echivalentul ˆın XRDL al structurii cu k+1 elemente, ceea ce concluzioneaz˘a induct¸ia. Astfel ipoteza induct¸iei este adev˘arat˘a pentru ∀n ∈N.

Revenim acum la demonstrat¸ia lemei 4.3.3. Pentru cazul particular se observ˘a c˘a un tablou bidimensional trebuie s˘a cont¸in˘a cel put¸in un element compus unidimensional de tip tablou sau structur˘a ¸si eventual unul sau mai multe elemente de tip simplu de date. Dar lema 4.3.2 ¸si lema 4.3.4 demonstreaz˘a deja c˘a orice tip de date compus unidimensional are un tip de date complex echivalent ˆın XRDL. Forma general˘a a unui tablou bidimensional este:

<member type="_tip_1">_membru_1</member>

<member type="_tip_2">_membru_2</member>

...

<member type="_tip_m">_membru_m</member>

</type>

tip i reprezint˘a fie un tip simplu de date, fie un tip unidimensional de date compuse,

∀i∈1,2, ..., m, ¸si cu proprietatea c˘a exist˘a cel put¸in un j ∈1,2, ..., mpentru care tip j este un tip compus de date. Cazul particular pentru lema 4.3.3 este evident adev˘arat deoarece se refer˘a la tablouri unidimensionale, adic˘a ceea ce a fost demonstrat ˆın lema 4.3.2. Pentru pasul inductiv presupunem c˘a orice tablou k-dimensional poate fi definit ˆın XRDL ca un tip complex de date. Se observ˘a c˘a un tablou (k+1)-dimensional cont¸ine elemente de dimensiuni k sau mai mici. Din presupunerea inductiv˘a deducem c˘a orice element al tabloului (k+1)-dimensional poate fi definit ˆın XRDL ca un tip de date complex.

ˆIn concluzie putem defini tabloul (k+1)-dimensional folosind elemente de acele tipuri de date definite, iar lemma 4.3.3 este demonstrat˘a.

Pentru structuri multi-dimensionale se define¸ste urm˘atoarea lem˘a:

Lema 4.3.5 O structur˘a n-dimensional˘a poate fi definit˘a ca tip de date ˆın XRDL, ∀n ∈ N.

Lema 4.3.5 se demonstreaz˘a prin acela¸si rat¸ionament ca ¸si lemma 4.3.3, cu observat¸ia c˘a unul din membrii perechii structurii (care reprezint˘a numele perechii respective) va fi ˆın totdeauna de tip string.

4.3.2 Existent ¸a unui serviciu XML-RPC valid pentru orice do- cument XRDL

Aceast˘a sect¸iune va cont¸ine demonstrat¸ia urm˘atoarei teoreme:

(34)

Teorema 4.3.6 Orice document XRDL descrie un serviciu XML-RPC valid.

Din sect¸iunile anteriaore se observ˘a c˘a structura unui document XRDL permite descrierea unei metode de serviciu web ¸si, dac˘a este cazul, a unor tipuri de date compuse.

În XRDL metodele serviciului web sunt descrise prin nume, datele de intrare ¸si datele de ie¸sire ale metodei. Putem deduce astfel c˘a orice metod˘a descris˘a ˆın XRDL este o metod˘a valid˘a XML-RPC dac˘a datele de intrare ¸si de ie¸sire sunt date valide XML-RPC. Având ˆın vedere restrict¸ia impus˘a asupra XRDL, toate tipuri de date simple din XRDL sunt date valide ˆın XML-RPC. R˘amâne de deomnstrat urm˘atoarea lem˘a:

Lema 4.3.7 Orice tip compus de date din XRDL este un tip de date valid ˆın XML-RPC.

Pentru a demonstra aceast˘a lem˘a ¸si pentru a p˘astra corespondet¸ele ˆıntre acelea¸si tipuri de date, presupunem c˘a XRDL respect˘a urm˘atoarele convent¸ii de denumire:

Propozit¸ia 4.3.8 Tipurile compuse de date din documentul XRDL care descriu date XML-RPC de tip structur˘a vor reflecta perechile structurii printr-o convent¸ie de nume:

unul din membrii, care este de tip string ¸si reprezint˘a numele perechii va avea o denumire care ˆıncepe cu membru, iar cel˘alalt membru care poate fi de orice tip valid de date va avea o denumire care ˆıncepe cu valoare. Tipruile compuse de date din documentul XRDL care descriu date XML-RPC de tip tablou vor cont¸ine doar membrii a c˘aror denumire ˆıncepe cu membru.

Aceast˘a propozit¸ie asigur˘a faptul c˘a tipurile de date compuse definite ˆın XRDL pot fi diferent¸iate ˆın funct¸ie de corespondetul lor ˆın XML-RPC. F˘ar˘a aceast˘a convent¸ie tipurile de date compuse din XRDL arat˘a la fel, deoarece toate se definesc printr-o enumerare de date membre, f˘ar˘a vreo diferent¸˘a de structur˘a ˆıntre ele.

Luˆand ˆın considerare propozit¸ia 4.3.8, demonstrat¸ia lemei 4.3.7 se poate ˆımp˘art¸ii ˆın dou˘a p˘art¸i, tratˆand datele compuse care cont¸membrii denumit¸i cu membru ¸si valoare separat de cel˘alalte tipuri compuse de date.

Se va trata mai ˆıntˆacazul datelor compuse ce cont¸in membrii denumit¸i cu membru ¸si valoare. Fie urm˘atoarea lem˘a:

Lema 4.3.9 Un tip compus de date din documentul XRDL care cont¸ine membrii denumit¸i cu valoare ¸si care are doar membrii de tipuri simple de date poate fi transcris ˆın XML- RPC ˆıntr-un element de tip structur˘a.

Din ipoteza lemei 4.3.9 deducem c˘a elementul de tip compus va avea forma general˘a:

(35)

...

<member type="string">_membru_n</member>

<member type="_tipSimpluDeDate_n">_valoare_n</member>

</type>

tipSimpluDeDate i, ∀i= 1, n, va fi ˆınlocuit cu unul din tipurile de date: string, int/i4, double, boolean, dateTime.iso8601 sau base64.

Pentru demonstrat¸ia lemei vom folosi induct¸ia matematic˘a dup˘an ∈N. Pentru cazul de baz˘a n=1 se obt¸ine un element compus de forma:

</type>

Acesta poate fi transcris ˆın XML-RPC printr-un element de tip structur˘a:

<value>

</value>

</member>

</struct>

Pentru pasul inductiv presupunem c˘a lema este adev˘arat˘a pentru n =k, adic˘a orice tip compus de date cu 2∗ k membrii poate fi transcris ca un element de tip structur˘a ˆın XML-RPC. Fie acest tip compus de date:

...

</type>

¸si elementul din XML-RPC echivalent:

(36)

<value>

</value>

</member>

...

<value>

</value>

</member>

</struct>

Se observ˘a c˘a pentru pasul k+1 tipul compus de date va fi:

...

<member type="string">_membru_k+1</member>

<member type="_tipSimpluDeDate_k+1">_valoare_k+1</member>

</type>

Se observ˘a c˘a se poate extinde structura echivalent˘a cu tipul compus cu 2∗k membrii cu ˆınc˘a un membru pentru a obt¸ine echivalentul pentru acest tip compus cu 2∗(k+ 1) membrii. Astfel se pote transcrie sub forma:

<value>

</value>

(37)

</member>

...

<value>

</value>

</member>

<name>_membru_k+1</name>

<value>

</value>

</member>

</struct>

Aceast˘a structur˘a este elemntul echivalent din XML-RPC c˘autat, ceea ce concluzioneaz˘a demonstrat¸ia lemei 4.3.9.

Ca o generalizare a lemei 4.3.9 avem:

Lema 4.3.10 Un tip compus de date din documentul XRDL care cont¸ine membrii denumit¸i cu valoare poate fi transcris ˆın XML-RPC ˆıntr-un element de tip structur˘a.

Se observ˘a c˘a aceast˘a lem˘a nu mai are restrict¸ia ca membrii s˘a aib˘a doar tipuri simple de date. Acest˘a lem˘a trateaz˘a ¸si cazurile tipurilor compuse de date ce cont¸in alte tipuri compuse de date.

ˆInainte de a demonstra lema 4.3.10 trebuie tratate tipurile de date compuse care au ca echivalent ˆın XRLD elemente de tip tablou. Se consider˘a urm˘atoarea lem˘a:

Lema 4.3.11 Un tip compus de date dintr-un document XRDL care cont¸ine doar membrii a c˘aror denumire incepe cu membru ¸si care are doar membrii de tipuri simple de date poate fi transcris ˆın XML-RPC ca un element de tip tablou.

Din ipoteza lemei deducem c˘a forma general˘a a elementelor compuse descrise este:

<member type="_tipSimpluDeDate_1">_membru_1</member>

...

<member type="_tipSimpluDeDate_n">_membru_n</member>

</type>

(38)

tipSimpluDeDate i, ∀i= 1, n, va fi ˆınlocuit cu unul din tipurile de date: string, int/i4, double, boolean, dateTime.iso8601 sau base64. Aceast˘a lem˘a se demonstreaz˘a cu ajutorul unei induct¸ii matematice dup˘a n. Pentru cazul particular n=1 tipul compus de date are forma:

</type>

Acesta poate fi transcris ˆın XML-RPC ca urm˘atorul tablou:

<array>

<data>

<value>

</value>

</data>

</array>

Pentru pasul inductiv presupunem c˘a un element compus cu k memebrii pote fi descris ˆın XML-RPC ca un element de tip tablou. R˘amˆane de demonstrat c˘a un element compus cu k+1 membrii poate fi de asemenea descris ˆın XML-RPC. Fie elementul compus cu k membrii urm˘atorul:

...

<member type="_tipSimpluDeDate_k">_membru_k</member>

</type>

¸si echivalentul s˘au ˆın XML-RPC:

<array>

<data>

<value>

</value>

...

<value>

</value>

</data>