Upload
others
View
26
Download
0
Embed Size (px)
Citation preview
UNIVERSITATEA POLITEHNICA DIN BUCURESTI Facultatea de Electronica, Telecomunicatii si Tehnologia Informatiei
INGINERIE SOFTWARE
Servicii Web
Ancuța Ionuț-Alexandru Ciucă Maria-Mădălina Milca Mihaela-Elena Pistol Bogdan
Grupa 441A
Conținut
I. Milca Mihaela-Elena ........................................................................................................................ 3
1. Introducere. Explicații, definții .................................................................................................... 3
2. Concepte și arhitecturi ................................................................................................................ 4
II. Pistol Bogdan ................................................................................................................................... 8
3. Servicii Web ..................................................................................................................................... 8
i. SOAP ........................................................................................................................................ 8
III. Ancuta Ionut Alexandru ............................................................................................................. 14
ii. Arhitectura REST ........................................................................................................................ 14
iii. XML-RPC .................................................................................................................................... 15
iv. JSON-RPC ................................................................................................................................... 16
IV. Ciucă Maria – Mădălina ............................................................................................................. 19
4. Regăsirea serviciilor SOAP in aplicații moderne (Google App engine, Amazon Web Services) 19
Bibliografie ............................................................................................................................................ 26
I. Milca Mihaela-Elena
1. Introducere. Explicații, definții
[1]Un serviciu web este un sistem software conceput să suporte interacțiuni masină-către-
mașină cu ajutorul internetului. El are o interfață descrisă într-un format usor de procesat de
mașină ,în mod special WSDL. WSDL este aconimul cuvântului Web Services Description
Languages(Limbaje de descriere a serviciilor web) și reprezintă un document scris în
XML(Extensible Markup Language-sistem extensibil de marcare). Documentul descrie
serviciul web. El specifică locația serviciului și operațiile(metodele) de care sistemul dispune.
Alte sisteme interactionează cu serviciul web într-o manieră prescrisă de descrierea lui
folosind mesaje SOAP(Simple Object Access protocol-protocol de acces la obiecte),
transportul normal folosind HTTP(Hypertext Transfer Protocol-protocol de transfer de tip text)
cu serializare cu XML, ce este în legatura cu alte standarede relaționare.
[3]Serviciile web preiau multe idei și principii ale internetului și le aplică pe calculator. La fel
ca World Wide Web(WWW), serviciile web comunică folosind un set de protocoale care
împart o arhitectură comună și sunt menite să fie realizare într-o varietate de sisteme
dezvoltate și implementate. Ca World Wide Web, protocoale de servicii web datoreză mult
moștenirii textului de bază al Internetului și sunt concepute pentru a fi “curate”, fără a fi
dependente, nejustificat, în stiva de protocol.
Un domeniu important în care serviciile Web diferă de World Wide Web este domeniul de
aplicare. HTTP și HTML au fost proiectate pe conceptul navigare interactivă a conținutului,
care este, in mare parte, statică. În contrast, arhitectura serviciilor Web este proiectată
pentru interactiuni program-către-program,ce sunt foarte dinamice. În arhitectura de servicii
Web, multe tipuri de sisteme distribuite pot fi puse în aplicare. Exemplele includ: sisteme
sincrone și asincrone de mesagerie, clustere de calcul distribuite, sisteme de rețea-mobilă,
sisteme de rețea, și medii de tip capăt-la-capăt. Spectrul larg de cerințe, în interacțiuna
program-la-program forțează stiva de protocoale de servicii web pentru a avea un scop mult
mai general decât primele protocoalele Web. Cu toate acestea, la fel ca și Web, serviciile
Web se bazează pe un număr mic de protocoale specifice.
Principiile fundamentale care au condus la proiectarea și implementarea arhitecturii
protocoalelor serviciilor Web sunt:
-Orientarea mesajelor-sunt folosite doar mesaje pentru a sa realiza comunicarea într servicii
și pentru a realiza ca mesajele au, de obicei, o viață în spatele evenimentelor de transport;
-Compozabilitatea protocolului-evitarea monoliților, prin utilizarea infrastructurii elementelor
de protocol, ce pot fi utilizați în orice combinație;
-Servicii autonome-permit punctelor de final să fie construite independent, instalate,
gestionate și securizate;
-Gestionarea transparenței-controlează ca aspecte ale punctului final să fie(sau să nu fie)
vizibile serviciilor externe;
-Integrarea protocoalelor de bază.
[2]Serviciile web sunt aplicații modulare de sine stătătoare, care pot fi descrise, publicate,
situate și invocate într-o rețea, în general, Web.
Arhitectura serviciilor web reprezintă evoluția logică a proiectării și analizei obiectelor
orientate și evoluția logică a componentelor orientate pe arhitectură, proiectare,
implementare și dezvoltarea soluțiilor e-busniess. Ambele abordări au fost dovedite dadorită
complexității sistemului. Ca și în sistemele orientate pe obiecte unele dintre conceptele
fundamentale ale serviciilor web sunt încapsulate, mesajsul trece, leagă dinamic și
interoghează descrierea serviciilor.
Mai multe activități esențiale trebuie să aibă loc în orice mediu orientat spre servicii:
-Un serviciu Web trebuie să fie creat, iar interfețele lui și metode de invocare trebuie să fie
definite.
-Un serviciu Web trebuie să fie publicat la una sau mai multe arhive intranet sau Internet ai
potențialilor utilizatori pentru a fi localizați.
-Un serviciu Web trebuie să fie localizat pentru a fi invocat de către potențialii utilizatori.
- Un serviciu Web trebuie să fie invocat pentru a fi un beneficiu.
-Un serviciu Web trebuie să fi nepublicat atunci când nu mai este disponibil sau necesar.
2. Concepte și arhitecturi
[5]Un serviciu web reprezintă o noțiune abstractă care trebuie să fie implementată de un
agent concret. Agentul trebuie să fie partea concretă a software-ului sau hardware-ului care
să trimită și să primească mesaje, în timp ce serviciul este resursa caracterizată de setul
abstract de functionalitate care este prevazut. Pentru a ilustra această distinctive trebuie
impementat un serviciu web particular folosind un agent într-o zi și alt agent într-o alta zi cu
aceeași funcționalitate. Chiar dacă agentul este schimbat serviciul web rămâne același.
Mecanismul schimbului de mesaje este documentat într-o descriere a serviciilor web(WSD-
Web Service Description). WSD este o specficație de procesare a interfeței serviciilor web.
Acesta definește formatul mesjului, tipurile de date, protocoalele de transport sau formatele
serializabile de transport care ar trebui folosite între agentul care creeeă cererea și agentul
beneficiar. Se precisează, de asemenena una sau mai multe locații de rețea la care un agent
furnizor care poate fi invocat și poate oferi informații despre modul de schimb de mesaje care
se așteaptă. În esență, descrierea serviciului reprezintă un acord care reglementează
mecanismul de interactiune cu acest serviciu.
[4]Schema serviciului web reprezintă așteptările legate de comportamneul serviciului, în
particular răspunsul la mesajele ce sunt trimise. De fapt, aceasta este legătura dintre
entitatea solicitanului și entitatea furnizorului cu privire la scopul și consecințele interacțiunii.
Există mai multe moduri în care o entitate solicinat poate folosi un serviciu web. În general,
sunt necesare următoarele etape generale(asa cum este ilustrat în figura ce urmeaza):
1.Entitățile solicitant și furnizor devin cunoscute unul fată de altul (sau cel puțin unu cunoaste
pe celălalt);
2.Solicitantul și furnizorul sunt de accord asupra descrierii serviciului și asupra semnaticii ce
vor guverna interacțiunea dintre cel care realizează cererea și cel care furnizează raspunsul;
3. Descrierea serviciului și semantica sunt realizate de către agenții solicitantului și
furnizorului;
4. Solicitantul și furnizorul fac schimb de mesaje, performând și anumite cerințe în numele
solicitantului și furnizorului. (Schimbul de mesaje cu furnizorul reprezintă legatura ce se
realizează cu serviciul web)
[5]
Un document WDS este utilizat pentru a preciza informațiile neoperaționale pentru un
serviciu, cum ar fi categoria de serviciu, descriere și data de expirare. Un document WDS
este complementar cu un document NASSL corespunzător. Împreună, acestea sunt utilizate
pentru a specifica o descriere completă a serviciuui care permite solicitanților de servicii
pentru a localiza și invoca un serviciu.
Sistemele serviciilor web promovează decuplarea și semnificanța și legarea dinamică a
compomentelor:toate componentele dintr-un sistem de servicii, în masura în care
încapsulează comportamenul și publică un mesaj API către alte component ale rețelei.
În cazul în care entitatea solicitantului dorește să inițieze o interacțiune cu un furnizor și nu
știe ce agent furnizor dorește, atunci entitatea solicitantului trebuie sa descopere un candidat
potrivit. Descoperirea reprezinta localizarea descrierii a unui serviciu Web care ar fi fost
anterior necunoscut și care îndeplinește anumite criterii funcționale.
[5]
Angajarea serviciului de a găsi un serviciu de descoperire presupune următorii pași:
1.Entitățile solicitant și furnizor trebuie să se cunoască una pe alta;
2.Entitățile solicitant și furnizor devin de acord în legatură cu schema interacțiunii dorite. Deși
acest lucru poate fi realizat în mod obișnuit de furnizor el trebuie să definească schemele și
să le ofere pe principiul”ia-l sau lasa-l”.
3.Descrierea serviciului și a schemelor și introducerea lor sau încorporarea lor, atât pentru
agentul solicitant cât și pentru cel furnizor.
4. Agentul solicitant și furnizorul oferă mesajele de schimb SOAP.
Utilizarea arhitecturii Web Services oferă următoarele beneficii:
1. Promovează interoperabilitatea prin minimizarea cerințelor pentru înțelegere comună.
2. Permite integrarea just-in-time.
3. Reduce complexitatea de încapsulare
4. Complexitatea sistemului este redusă atunci când designerii de aplicații nu trebuie să
iși facă griji cu privire la detaliile de implementare ale serviciilor care sunt invocate.
5. Flexibilitate și scalabilitate. Schimbarea diferitelor implementări ale aceluiaș tip de
serviciu sau a mai multor echipamante de servicii.
6. Extensibilitate. Comportamentul este încapsulat și extins prin furnizarea de noi
servicii cu descrieri de servicii similare.
7. Permite interoperabilitatea aplicațiilor mai vechi.
II. Pistol Bogdan
3. Servicii Web
i. SOAP
Caracteristici
SOAP a fost un acronim pentru Simple Object Access Protocol dar acum este doar “SOAP”. SOAP este un serviciu de tip RPC (Remote Procedure Call) ce comunica folosind un format specific de tip XML.
Protocolul este alcatuit din trei parti:
Plic (eng: envelope), ce defineste structura mesajului si cum sa fie procesat
Un set de reguli de codare pentru a exprima instante ale tipurilor de date definite in aplicatie
conventie pentru a reprezenta invocari de metode si raspunsuri
SOAP are trei caracteristici importante:
1. Extensibilitate – se refera la posbilitatea folosirii plicului cu orice protocol de comunicatii prin adaugarea de blocuri in antet (eng: header blocks). Acestea au rolul de a influenta procesarea mesajului. Un exemplu de astfel de block este adaugarea de credentiale pentru a controla accesul.
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<!-- security credentials -->
<s:credentials xmlns:s="urn:examples-org:security">
<username>dave</username>
<password>evad</password>
</s:credentials>
</soap:Header>
<soap:Body>
<x:TransferFunds xmlns:x="urn:examples-org:banking">
<from>22-342439</from>
<to>98-283843</to>
<amount>100.00</amount>
</x:TransferFunds>
</soap:Body>
</soap:Envelope>
2. Neutralitatea – Protocolul este independent de protocolul de comunicare. Fiecare intermediar poate alege sa foloseasca alt protocol, cum ar fi HTTP, SMTP, TCP, UDP, or JMS fara a afecta mesajul. Cu toate acestea, sunt folosite legaturi de protocol (eng: protocol bindings) standard pentru a asigura interoperabilitate intre aplicatii si infrastructura.(vezi figura 1)
3. Independenta – SOAP poate fi folosit cu orice model de programare. Acesta poate fi implementat atat in limbaje procedural cat si in limbaje orientate pe obiect.
Arhitectura mesajelor
Un mesaj SOAP este alcatuit din patru elemente XML de baza: Plic, Antet, Corp si
Erori (care nu este obligatoriu).
Plicul este intodeauna elementul radacina (primul element) dintr-un mesaj SOAP. Acest lucru faciliteaza identificarea mesajelor SOAP pe baza numelui elementului radacina. Versiunea de SOAP folosita poate fi identificata prin numele namespace-ului plicului. Plicul poate contine un element optional, numit Antet (eng: Header) urmat apoi de un element numit Corp (eng: Body) care reprezinta mesajul propriu-zis.
Ca exemplu, urmatorul mesaj SOAP reprezinta o cerere (request) de transfer de fonduri intre doua conturi bancare:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<x:TransferFunds xmlns:x="urn:examples-org:banking">
<from>22-342439</from>
<to>98-283843</to>
<amount>100.00</amount>
</x:TransferFunds>
</soap:Body>
</soap:Envelope>
Figure 1 Legatura SOAP – HTTP [17]
In cazul in care cererea ar fi procesata cu success, raspunsul (response) ar fi tot un mesaj SOAP:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<x:TransferFundsResponse
xmlns:x="urn:examples-org:banking">
<balances>
<account>
<id>22-342439</id>
<balance>33.45</balance>
</account>
<account>
<id>98-283843</id>
<balance>932.73</balance>
</account>
</balances>
</x:TransferFundsResponse>
</soap:Body>
</soap:Envelope>
Arhitectura SOAP contine si un element numit Eroare (eng: Fault) care contine erori atunci cand acestea apar. Acest bloc se regaseste in interiorul Corpului. Elementul Eroare este foarte important pentru a standardiza modul in care aplicatiile recunosc daca comunicarea a avut loc cu success sau nu. Urmatorul mesaj SOAP contine un element Eroare care indica faptul ca au fost fonduri insuficiente in cont si astfel nu a putut fi realizat transferul.
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>Insufficient funds</faultstring>
<detail>
<x:TransferError xmlns:x="urn:examples-org:banking">
<sourceAccount>22-342439</sourceAccount>
<transferAmount>100.00</transferAmount>
<currentBalance>89.23</currentBalance>
</x:TransferError>
</detail>
</x:TransferFunds>
</soap:Body>
</soap:Envelope>
Elementul de eroare trebuie sa contine un cod (faultcode) urmat de un text (faultstring). Codul are rolul de a clasifica eroarea, in timp ce textul ofera o explicatie destinata interpretarii umane.
Elementul eroare mai poate contine un element Detaliu care ofera informatii suplimentare despre eroare care ajuta in diagnosticarea problemei.
Modelul de procesare
Modelul de procesare SOAP stabilieste un set de reguli pentru procesarea unui mesaj SOAP. Mesajul SOAP poate comunica printr-un model simplu, in care este implicat un emitator, care transmite mesajul, si un receptor. (figura 2)
Figure 2 Schimb de mesaje Request/Response [18]
Acest model poate fi si mai complex ce ar permite introducerea unor noduri intermediare. Nodurile intermediare au rol atat de receptor cat si de emitator. (figura 3) La procesarea mesajelor un nod intermediar isi asuma unul sau mai multe roluri care influentareaza modul in care antetele sunt procesate. Odata ce si-a asumat un rol, nodul trebuie sa proceseze toate antetele acelui rol marcate cu mustUnderstand="1" si optional, le poate procesa si pe cele marcate cu mustUnderstand="0". Table 1 Roluri in SOAP 1.2
Numele Rolului SOAP Descrierea
http://www.w3.org/2002/06/soap-
envelope/role/next
Toti intermediarii SOAP si ultimul receptor trebuie sa isi asume acest rol dar isi mai pot asuma si alte rolui SOAP
http://www.w3.org/2002/06/soap-
envelope/role/none
Nodurile soap nu trebuie sa isi assume acest rol
http://www.w3.org/2002/06/soap-
envelope/role/ultimateReceiver
Acest rol este folosit pentru a determina receptorul final. Nodurile intermediare nu trebuie sa isi asume acest rol.
Figure 3Model SOAP complex [19]
Avantaje si dezavantaje ale SOAP
Avantaje
SOAP permite folosirea unor protocale de transport variate. Chiar daca standardul foloseste HTTP, alte protocoale cum ar fi SMTP, JMS sau Message Queues pot fi folosite
Modelul SOAP poate comunica usor prin firewall-uri si proxy-uri fara sa trebuiasca modificat protocolul.
Dezavantaje
Deoarce foloseste XML acest lucru il face simtitor mai incet si mai greoi decat alte tehnologii. Acest lucru devine o problema atunci cand se trimit mesaje de dimensiuni mari si trebuiesc introduse tehnologii suplimentare pentru imbunatatirea performantelor.
Atunci cand SOAP se bazeaza pe HTTP, rolurile aplicatiilor implicate sunt fixe. Doar o singura aplicatie (clientul) poate folosi serviciile celeilalte.
Deoarce protocolul este foarte explicit, arhitectura REST este adeseori preferata.
III. Ancuta Ionut Alexandru
ii. Arhitectura REST
[20] REST după cum îi spune și numele reprezintă un transfer al stării,iar în
comparație cu cu protocoale ca SOAP sau XML-RPC este mai mult o filosofie sau un set de principii decât un protocol .REST este un set de idei cu privire la modul în care datele sunt transferate elegant și deși nu este legat de HTTP vom vorbi despre el in contextul HTTP-ului. Într-un serviciu REST sunt utilizate patru atribute pentru a oferi un set de bază CRUD(Create,Read,Update,Delete).Pot apărea si alte implementări ale altor atribute,dar acestea patru formează o platformă de bază a unui serviciu REST. Serviciile REST se ocupă de transferul reprezentațiilor de resurse.O astfel de reprezentare poate sa fie JSON sau XML.Fiecare înregistrare individuală a datelor într-un sistem este o resursă.În prima etapă de proiectare API,un punct de plecare ar putea fi sa ia în considerare fiecare linie a unei baze de date ca o resursă individuală.De exemplu într-un sistem imaginar de blogging resursele pot fi postările,categoriile sau chiar autorii,iar fiecare resursă are un identificator unic pentru înregistrare. Constrângeri de arhitectură Proprietățile arhitecturii REST sunt realizate prin aplicarea unor constrângeri specifice de interacțiune intre componente,conectori si date.Constrângerile formale sunt: Client-server O interfață uniformă separă clienții de servere.Această separare înseamnă că,spre exemplu pe clienți nu îi interesează unde sunt stocate datele,care rămân intern în fiecare server și astfel se îmbunătățește portabilitatea cod-client.Serverele nu sunt preocupate de interfața cu userul sau de starea acestuia,astfel că acestea pot fi destul de simple și scalabile.Serverele și clienții pot fi înlocuite sau dezvoltate independent,atât timp cât interfața dintre ele rămâne nemodificată. Protocolul stateless Comunicarea client-server este constrânsă și mai mult de nestocarea pe server a niciunui context între cereri.Fiecare cerere de la orice client conține toate informațiile necesare pentru a deservi cererea,iar starea sesiunii este ținută în client.Această stare poate fi transferată de server altui serviciu,cum ar fi o bază de date pentru a menține o stare persistentă de o perioadă pentru a permite autentificarea.Clientul incepe trimiterea cererilor atunci când este gata să facă tranziția la o stare nouă.În timp ce una sau mai multe stări sunt remarcate,clientul este considerat a fi in tranziție.Reprezentarea fiecărei stări a aplicației conține linkuri care pot fi folosite următoarea dată când clientul alege să inițieze o nouă stare de tranziție. Cacheul Web Ca și în internet,clienții pot stoca răspunsurile.Răspunsurile trebuie prin urmare,implicit sau explicit,să fie definite stocabile,sau nu,pentru a preveni clienții de reutilizarea unor date vechi sau inadecvate ca răspuns la unele solicitări suplimentare. Sistem stratificat Un client nu poate spune dacă acesta este conectat la serverul final sau la unul intermediar de-a lungul unei rețele.Serverele intermediare pot îmbunătăți scalabilitatea sistemului prin punerea la dispoziție a unui cache comun sau prin permiterea încărcării echilibrate a rețelei.Ele pot impune,de asemenea și anumite politici de securitate.
iii. XML-RPC
[22]XML-RPC este un protocol care face un apel de procedură la distanță și care utilizează XML pentru a coda apelurile sale și HTTP ca mecanism de transport.XML-RPC se referă la utilizarea XML pentru apel de procedură la distanță,independent de protocolul specific. Utilizare XML-RPC funcționează prin trimiterea unei cereri HTTP la un server care implementează protocolul.Clientul in acest caz este deobicei un software care dorește să solicite o singură a unui sistem la distanță. Parametrii multipli de intrare pot fi dați metodei care returnează o anumită valoare.Tipurile parametrilor permit gruparea acestora în hărți și liste,astfel structurile mai mari pot fi transportate.Prin urmare XML-RPC poate fi folosit la transportul obiectelor sau structurilor atât ca parametrii de intrare cât și ca parametrii de ieșire. Identificarea clienților în scopul autorizării poate fi realizată folosind metode de securitate HTTP cunoscute.Autentificarea accesului de bază este utilizată pentru identificare,HTTPS este folosit când este nevoie de identificarea si criptarea mesajelor.Ambele metode pot fi combinate.Comparativ cu REST,unde documentele sunt transferate, XML-RPC este proiectat pentru apelul metodelor. Este mai simplu de folosit decât SOAP deoarece permite un singur mod de a serializa metodele,în timp ce SOAP permite mai multe codări diferite și are un model de securitate mai simplu.
Un exemplu al unei cereri XML-RPC tipice ar fi:
<?xmlversion="1.0"?>
<methodCall>
<methodName>examples.getStateName</methodName>
<params>
<param>
<value><i4>40</i4></value>
</param>
</params>
</methodCall>
Iar ca exemplu al unui răspuns XML-RPC avem:
<?xmlversion="1.0"?>
<methodResponse>
<params>
<param>
<value><string>South Dakota</string></value>
</param>
</params>
</methodResponse>
Exemplu eroare XML-RPC:
<?xmlversion="1.0"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>4</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Too many parameters.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>
XML-RPC folosește de 4 ori mai mulți biți în comparație cu XML simplu pentru a coda
aceleași obiecte.
iv. JSON-RPC [21]Json-Rpc este un protocol de apel de procedură la distanță codat in JSON.Este
un protocol relativ simplu si asemănător XML-RPC care definește doar câteva tipuri de date
și comenzi.JSON-RPC permite notificări de la date transmise către server care nu au nevoie
de răspuns și de la apeluri multiple trimise la server la care se poate răspunde în ordine.
Utilizare
JSON-RPC funcționează prin trimiterea unei cereri la un server care implementează
acest protocol.Clientul în acest caz este de obicei un software care inteționează să solicite o
singură metodă a unui sistem la distanță.Parametrii de intrare multiplii pot si atribuiți metodei
la distanță ca o matrice sau ca un obiect,în timp ce metoda poate returna mai multe date de
ieșire.
O metodă la distanță este apelată prin trimiterea unei cereri unui serviciu la distanță prin
HTTP sau TCP/IP.La utilizarea HTTP conținutul poate fi definit ca aplicație JSON.
O cerere este un apel al unei metode specifice pusă la dispoziție de un sistem la
distanță.Trebuie sa conțină următoarele proprietăți:
--method(string cu numele metodei apelate);
--params(o matrice de obiecte care poate fi atribuită ca parametru metodei definite);
--id(leagă răspunsul cu cererea la care răspunde).
Receptorul trebuie să răspundă la toate cererile primite.Un răspuns trebuie să conțină
următoarele proprietăți:
--result(valoarea returnată a metodei apelate/eroare returnează NULL);
--error(returnează o eroare specifică la apelarea metodei,altfel NULL);
--id(idul cererii la care răspunde).
În cazul notificărilor,acestea au aceleași proprietăți doar că lipsește atributul id de care nu
este nevoie deoarece niciun răspuns nu va fi returnat.
În cazul JSON-RPC formatul cererii,respectiv al răspunsului diferă oarecum de la o versiune
la alta.Ca exemplu am ales versiunea 1.1.
Formatul conținutului unei cereri poate arăta astfel,în cazul versiunii 1.1:
{
"version":"1.1",
"method":"confirmFruitPurchase",
"id":"194521489",
"params":[
["apple","orange","mangoes"],
1.123
]
}
Iar formatul unui răspuns poate fi de forma:
{
"version":"1.1",
"result":"done",
"error":null,
"id":"194521489"
}
IV. Ciucă Maria – Mădălina
4. Regăsirea serviciilor SOAP in aplicații moderne (Google App engine,
Amazon Web Services)
[13]Pentru început voi alege , pentru o bună evidențiere , un serviciu simplu si gratuit SOAP
furnizat de WebserviceX numit GeoIPService . Acest serviciu permite căutarea cu ușurință a
țării de origine pentru o adresă IP dată.
1) Crearea unui obiect WSDL
Pentru a utiliza biblioteca SOPA , primul lucru de care avem nevoie este fisierul WSDL
asociat serviciului web . Fisierul WSDL ('Limbajul de definiție al serviciului Web ') conține
metadatele („date despre date) necesare biliotecii să găsească serviciul și să știe ce operații
pot fi folosite.
Pentru acest serviciu , limbajul de definitie al serviciului Web poate fi găsit la:
http://www.webservicex.net/geoipservice.asmx?wsdl .
Este doar un fișier XML mic care descrie serviciile , operațiile și tipurile de argumente
disponibile.
Odată ce avem locația fișierului WSDL , putem incepe să-l utilizăm în Google Apps Script
astfel :
var wsdl = SoapService.wsdl( "http://www.webservicex.net/geoipservice.asmx?wsdl" );
[13]
2) InterogareaunobiectWSDL
SoapService.wsdl va returna un obiect de tip WSDL care ne va ajută să ajungem la locația
specificată .Pentru moment vom folosi ‚getServiceNames’ pentru a determina serviciile
diponibile. In mod normal un singur serviciu trebuie să fie disponibil , dar uneori ar putea fi și
mai multe .
Logger.log(wsdl.getServiceNames());
După rularea acestuia vom vedea că un singur serviciu a fost returnat :'GeoIPService' . Dacă
ne uiăam in fișierul WSDL inițial vom vedea că acesta a fost singurul serviciu definit astfel:â
<wsdl:servicename = "GeoIPService">
3) Obtinerea unuiobiectWsdlService
Acum , putem incepe verificarea acestui serviciu pentru a vedea care sunt operațiile puse la
dispoziție. Există 2 metode de a ajunge la serviciul propriu-zis . Prima este de a apela pur și
simplu getService pe obiectul WSDL cu numele serviciului întors mai sus , adică:
var geoService = wsdl.getService("GeoIPService"); A doua metodă :
var geoService = wsdl.getGeoIPService();
Unerori serviciile SOAP vor avea nume pentru lucruri care nu pot fi reprezentate în Javascrip. Pentru aceste situații , prima forma prezentată , prevede un sistem care va functiona mereu indiferent de care este numele serviciului.
4) InterogareaunobiectWsdlService
Acum ca avem obiectul , este timpul să vedem ce facem. Pentru aceasta , folosim metoda
getOperationNames :
Logger.log(geoService.getOperationNames());
Acesta va returna următoarele rezultate: [GetGeoIP, GetGeoIPContext] .Așa cum era de așteptat , acestea au aceleași nume ale operațiilor listate pe pagina originală WebservicesX . Pentru acest exemplu vom folosi metoda GetGeoIP care „ne permite să căutam cu ușurința țări după adresele IP”
5) Crearea Web Service Parameters
Este timpul sa invocăm primul serviciu web. Pentru aceasta trebuie să vedem modul în care serviciul web este invocat în prezent . Ne putem conecta la adresa propie a paginii , fie pur și simplu printr-o adresă ip de probă ca 72.14.228.129 .
[13]
POST /geoipservice.asmx HTTP/1.1
Host: www.webservicex.net
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction:"http://www.webservicex.net/GetGeoIP"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/e
nvelope/">
<soap:Body>
<GetGeoIP xmlns="http://www.webservicex.net/">
<IPAddress>72.14.228.129</IPAddress>
</GetGeoIP>
</soap:Body>
</soap:Envelope>
Tot ce trebuie noi sa facem este:
<GetGeoIP xmlns="http://www.webservicex.net/">
<IPAddress>72.14.228.129</IPAddress>
</GetGeoIP>
[13]
Pentru a genera acest fragment XML putem folosi următoarele metode:
varparam =Xml.element("GetGeoIP",[
Xml.attribute("xmlns",http://www.webservicex.n
et/),
Xml.element("IPAddress",[
"72.14.228.129"
])
]);
[13]
6) Invocarea unei operatii SOAP
Pentru a invoca un serviciu web , putem folosi 2 metode:
var result = geoService.invokeOperation("GetGeoIP",[param]);
sau
var result = geoService.GetGeoIP(param);
7) Lucrul cu reszultatul operatiei SOAP
Deoarece SAOP este un sistem de transmisie de mesaje XML înainte și înapoi, rezultatul returnat este XML-ul însuși. Pentru a îl putea vizualiza putem folosi metoda „ toXmlString”
Logger.log(result.toXmlString());
Pentru a putea ajunge la informatiile pe care le dorim (codul de tara pentru adresa IP ) folosim:
Logger.log(result.Envelope.Body.GetGeoIPResponse.GetGeoIPResult.CountryCode.Tex
t);
REZULTATUL OBTINUT este „US”
Serviciul Național de Meteorologie
NDFD --National Digital Forecast Database-- este un serviciu care oferă publicului
capacitatea de a solicita date pe internet despre prognoza meteo și să primească informațiile
înapoi într-un format XML . Procesul de solicitare/ răspuns este prosibil prin protocolul de
acces NDFD XML SOAP.
Acesta asigură clienților informații NWS („Serviciul Național de Meteorologie”) disponibile
rapid , eficient ți în forme ușoare și ușor de ințeles .
Cum este generat XML NDFD ?
Cu datele NDFD disponibile , o aplicație utilizator creaza și trimite o cerere SOAP pentru
servarul SOAP NDFD XML . Cererea SOAP este procesată , creând documentul DWML
care este returnat pentru prelucrare.[14]
In figura de mai jos am prezentat o forma grafica a procesului:
Primul pas pentru a utiliza serviciul web este de a crea un cont client SOAP .
Clientul crează și trimite cererea SOAP la server . Cererea trimisă invocă apoi una dintre
funcțiile server:
NDFDgen ()
NDFDgenLatLonList ()
LatLonListSubgrid ()
LatLonListLine ()
LatLonListZipCode ()
LatLonListSquare ()
CornerPoints ()
NDFDgenByDay ()
NDFDgenByDayLatLonList ()
Exemplu NDFDgen():
Name: NDFDgen
Binding: ndfdXMLBinding
Endpoint:
http://graphical.weather.gov/xml/SOAP_server/ndfdXMLserver.php
SoapAction:
http://graphical.weather.gov/xml/DWMLgen/wsdl/ndfdXML.wsdl#NDF
Dgen
Style: rpc
Input:
use: encoded
namespace:
http://graphical.weather.gov/xml/DWMLgen/wsdl/ndfdXML.wsdl
encodingStyle: http://schemas.xmlsoap.org/soap/encoding/
message: NDFDgenRequest
parts:
latitude: xsd:decimal
longitude: xsd:decimal
product: xsd:string
startTime: xsd:dateTime
endTime: xsd:dateTime
Unit: xsd:string
weatherParameters: tns:weatherParametersType
Output:
use: encoded
namespace:
http://graphical.weather.gov/xml/DWMLgen/wsdl/ndfdXML.wsdl
encodingStyle: http://schemas.xmlsoap.org/soap/encoding/
message: NDFDgenResponse
parts:
dwmlOut: xsd:string
Namespace:
http://graphical.weather.gov/xml/DWMLgen/wsdl/ndfdXML.wsdl
Transport: http://schemas.xmlsoap.org/soap/http
[14]
NDFD XML conține previziuni pentru parametrii meteorologici.
AMAZON[15]
Comerțul electronic este practicat de utilizatorii de calculatoare pentru a cumpăra și vinde
bunuri și servicii de pe piată într-o rețea cum ar fi internetul.
Un astfel de site este www.amazon.com.
Modul de folosire API:
Cererile si răspunsurile apar pe Internet.
Clientul si serverul foloseste REST, SOAP sau XML ca mijloc de comunicare
Clientul si server-ul sunt de acord cu privire la gramatica și sintaxa utilizate în cereri și
răspunsuri prin specificarea unui WSDL
Cererile si răspunsurile nu sunt legate de un singur sistem de operare sau limbaj de
programare
Un simplu exemplu prin care Amzon folosește API este operația ItemSearch . Această
solicitare cere bazei de date Amazon să găsească produsul specificat. Serverele web caută
serviciul apoi datele sunt trimise înapoi solicitantului.
Toate cererile API se bazează pe REST și SOAP și tote răspunsurile sunt bazate pe XML.
Sintaxa XML <note><para>Sentence</para></note>
Exmenplu pentru Amazon :[16]
<SubTotal>
<Amount>2998</Amount>
<CurrencyCode>USD</CurrencyCode>
<FormattedPrice>$29.98</FormattedPrice>
</SubTotal>
Exemplul arata ca subtotalul este format din 3 parti:
Suma,
Cosul Valutar,
Format Pre
Google App engine
Google App engine (GAE ) este o platformă care are scopul de a permite dezvolatrea si
găzduirea aplicațiilor web Java, Python și GO.
Fluxul logic după care functionează Serverul:
In concluzie serviciile SOAP sunt larg utilizate in : rate de schimb intre diferite valute, servicii
bancare pentru verificarea si operarea in conturi (de catre aplicatii WEB de comert ,
electronic , de exemplu), servicii de memorare si regasire date s.a.m.d
Bibliografie
[1] http://www.w3schools.com/webservices/ws_wsdl_intro.asp
[2] http://www.ibm.com/developerworks/library/w-ovr/
[3] https://msdn.microsoft.com/en-us/library/ms996441.aspx
[4] http://www.w3.org/TR/ws-arch/
[5] http://docs.oracle.com/javaee/6/tutorial/doc/giqsx.html
[6] http://en.wikipedia.org/wiki/Web_service
[7] L. J. Mitchell, PHP Web Services, O'Reilly, 2013.
[8] A. Skonnard and DevelopMentor, "http://msdn.microsoft.com/en-
us/library/ms995800.aspx," Microsoft, 2003.
[9] http://en.wikipedia.org/wiki/SOAP
[10] http://www.w3schools.com/webservices/ws_soap_intro.asp
[11] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[12] http://www.cs.colorado.edu/~kena/classes/7818/f08/lectures/lecture_3_soap.pdf
[13] https://developers.google.com/apps-script/articles/soap_geoip_example
[14] http://graphical.weather.gov/
[15] http://en.wikipedia.org/4
[16] http://docs.aws.amazon.com/
[17] https://i-msdn.sec.s-msft.com/dynimg/IC167235.gif
[18] https://i-msdn.sec.s-msft.com/dynimg/IC58582.gif
[19] https://i-msdn.sec.s-msft.com/dynimg/IC65569.gif
[20] http://en.wikipedia.org/wiki/Representational_state_transfer
[21] https://developer.atlassian.com/display/CROWDDEV/JSON+Requests+and+Responses
[22] http://en.wikipedia.org/wiki/XML