XML-RPC




2.2.1 Introducere XML-RPC
XML-RPC este un mecanism de apel de metode la distanta, care foloseste HTTP ca trensport si XML pentru codificare.Este proiectat ca sa fie cat se poate de simplu, permitand transmiterea si prelucrarea structurilor de date complexe. Defineste simple functionalitati, evita solutii complexe, n-a fost proiectat ca sa rezolve o scara larga de probleme. Este o modalitate simpla de a trimite si primi informatii, are avantajul fata de SOAP simplcitatea si overhead redus. Defineste un format al apelurilor si raspunsurilor de metode, si taguri pentru tipuri de date simple (integer, string) sau mai complexe (array), deci XML-RPC poate defini majoritatea tipurilor de date folosite in remote procedure calling.


2.2.2 Mesaj de apel metoda XML-RPC
Apelurile de metode sint reprezentate de tagul "methodCall", numele metodei apelate este specificat de elementul copil "methodName", iar parametrii in tagul "params" care poate sa aiba, la randul ei , mai multe taguri "param". Pentru ca XML-RPC functioneaza peste HTTP, informatiile de header HTTP trebuie incluse in apelul de metoda. Exemplu de apel de metoda:




Am apelat o metoda cu numele echo si cu parametrul String "Hello World".

2.2.3 Mesaj de raspuns XML-RPC




Raspunsurile de metode sunt reprezentate de tagul "methodResponse". Raspunsul poate returna rezultatul apelului sau "fault" daca o aparut o eroare in executarea metodei. Codul returnat de "fault" , "fault code" ofera informatii despre eroarea aparuta.
Daca nu apare nici o eroare, se primeste codul 200, deci "ok", formatul raspunsului este urmatorul: un tag "methodResponse" urmarit de tagul "params", valoarea raspunsului este returnat in tagul "value" si "datatype". Inca odata, informatiile standard de HTTP header trebuie incluse in mesaj. XML-RPC poate fi folosit cu un server "custom made" sau incorporat intr-unul dintre serverele web existente (de exemplu Apache) si folosit impreuna cu JSP sau Java Servlets.

2.2.4 Evaluare XML-RPC
Este un protocol mult mai "lightweight" decat SOAP, are mult mai putin overhead asociat, totusi este un protocol stabil, usor de utilizat, "user friendly" cu interfete simple. Este independent de sistem de operare sau de limbaj de programare, dar, din pacate, pentru cazul nostru dispune de aceeasi dezavantaje ca si SOAP.
. Eficienta
Se bazeaza pe arhitectura request-reply, deci nu se scaleaza bine pentru grupuri mai mari.
. Conectivitate la retea Intampina aceeasi probleme ca si SOAP, fiecae nod
trebuie sa ruleze un fel de server care sa permita comunicare bidirectionala, deci traversarea firewallurilor tot ramane o problema.
. Controlul schimbului de informatii Se refera la interactiunea intre noduri, rolul
de prezentator trebuie sa poata sa fie asumat de oricare nod, aici apar tot aceeasi probleme ca si la SOAP, replicarea prin mai multe noduri a informatiei de stare de prezenta conduce la o stare inconsistenta.