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