Disciplina: E-comunicare și E -documente [601337]

Universitatea Alexandru Ioan Cuza, Iasi
Facultatea de Econo mie si Administrarea Afacerilor

Servicii web

Profesor coordonator: Lect.univ.dr. Greavu -Serban Valerica
Disciplina: E-comunicare și E -documente
Studenta: Rodica Guja
Anul de studiu: 2
Grupa: 2

-2015 –

Cuprins
Introducere ………………………….. ………………………….. ………………………….. ………………………….. ……………… 3
Servicii ………………………….. ………………………….. ………………………….. ………………………….. ……………………… 3
Servicii web SOAP ………………………….. ………………………….. ………………………….. ………………………….. ….. 3
 WSDL ………………………….. ………………………….. ………………………….. ………………………….. …………. 5
Servicii web REST ………………………….. ………………………….. ………………………….. ………………………….. …… 6
 Reprezentarea ………………………….. ………………………….. ………………………….. …………………………. 7
 Mesaj ………………………….. ………………………….. ………………………….. ………………………….. …………. 7
 URI ………………………….. ………………………….. ………………………….. ………………………….. …………….. 9
 Interfata uniforma ………………………….. ………………………….. ………………………….. …………………. 10
 Statelessness ………………………….. ………………………….. ………………………….. …………………………. 10
 Relatii intre resurse ………………………….. ………………………….. ………………………….. ………………… 10
 Caching ………………………….. ………………………….. ………………………….. ………………………….. …….. 11
Concluzie ………………………….. ………………………….. ………………………….. ………………………….. ………………… 11
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ……………… 12

Introducere
Exista o multitudine de sisteme software care au necesitatea de a schimba date lor intre
ele, si un servicicu web set o metoda de comunicare care permite schimbarea datelor prin
intermediul internetului intre doua sisteme software.
Sistemul software care cere date este numit service requester, iar sistemul software care
proceseaza cerer ea si furnizeaza date este numit service provider .
Termenul "Servicii web" descrie un mod standardizat de integrare a aplicatii bazate pe
web folosind standardele XML, SOAP, WSDL și UDDI. XML este folosit pentru a eticheta
datele, SOAP este folosit pentru a transfera date, WSDL este folosit pentru a descrie servic iile
disponibile si UDDI enumera care servicii sunt disponibile .
W3C define ste un serviciu web, in general, ca:
“Un si stem software conceput pentru a sprijini interactiunea interoperabila masina -catre -masina
prin intermediul retelei”. (a software system designed to support interoperable machine -to-
machine interaction over a network.)
Un serviciu este o component a software care furnizeaza prin intermediul retelei un endpoint
accesibil. Consumatorul de serviciu cat si furnizorul ace stuia folosesc mesaje pentru a face
schimb dintre cererea invocata si informatia primita ca raspuns sub forma de document cu
auto-continut.
Trebuie sa fie defi nite niste reguli de comunicare intre sisteme diferite precum:
 Cum un si stem poate prelua/cere date de la alt si stem;
 Ce parametric specifici sunt necesari cand se creaza cererea;
 Care v -a fi sturctura datelor produse (normal,datele sunt schimbate in fisiere XML, si
structura fisierul XML este validate prin intermediul unui fisier .xsd);
 Ce mesaje de eroare trebuiesc afisate atunci cand nu se observa o anumita regula de
comunicare, pentru a face mai usor procesul de depanare.
La nivel tehnic, serviciile web pot fi implementate intr -o mare varietate de modalitati. Exista
doua tipuri de servicii web care sunt populare la momentul actual si anume serviciile web
“mari”(big web services) si servicii web :
 SOAP – Simple Object Access Protocol
 REST – Representational State Transfer
Servicii
Servicii web SOAP

SOAP defineste un protocol standard de comunicare (un set de reguli) folosit pentru
schimbul de mesaje bazate pe XML. SOAP -ul foloseste difererite protocoale de transport
precum HTTP si SMTP( Simple Mail Transport Protocol).

Un mesaj SOAP este un document XML care a fost s tandartizat (fig. 1) . Mesajul es te format din
tag-ul envelope (este elementu l radacina), acesta la randul lui este format din 2 elemente: body
si header.
Elementul body ofera un mecanism simplu pentru schimbul de informatii obligatorii
destinate beneficiarul final al mesajul ui. Aici, mesajul este conținut i ntr-un format XML.
Elementul corpului poate conține un document XML sau daca es te o cerere de RPC, acesta
conti ne date str ucturate returnare sau argumente, sau o eroare de raportare a erorilor.

Fig. 1. Mesajul SOAP
Exemplu de mesaj SOAP:
<SOAPenv:Envelope
xmlns:SOAPenv="http://schemas.xmlSOAP.org/SOAP/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema -instance">
<SOAPenv:Body>
<req:getNumberOfArticles xmlns:req="http://daily -moon.com/CMS/">
<req:category>classifieds</req:category>
</req:getNumberOfArticles>
</SOAPenv:Body>
</SOAPenv:Envelope >

Aceste mesaje trec de la un sistem la altul, de obicei, prin intre mediul HTTP. Sistemul
de recept ie interpreteaza mesajul, executa operatiile car e trebuie sa le execute, si trimite
inapoi un raspuns in forma de un alt mesaj SOAP.
Este un sis tem simplu, s i, ca atare, exista multe aspecte ale nivel enterprise , care nu sunt
acoperite de aceasta. Din fericire, multe dintr e aceste aspecte au fost luate i n considerare, și au
propriile lor specifi catii pentru a determina modul i n care tranzactia trebuie sa aiba loc pentru a
incorpora mai multe dintre aspectele securitat ii și alte aspecte ale mesajelor traditionale.

 WSDL

WSDL -ul este o specificatie care detaliaza modalitatea standard de a descrie serviciul SOAP,
incluzand decsri erea formatului mesajului, locatia acestuia si metodele acestuia . De asemenea
descrie si formatul mesajului de raspuns. WSDL -ul, combinat cu anumite medii de lucru (ex.
Eclipse), permite crearea unui apel la serviciul web fara a stii de ce anume are nevoie acesta,
aplicatia poate extrage aceste detalii din fisierul WSDL si ofera o interfata care va fi folosita
pentru a comunica cu serviciul web.
Elementele care descriu fisierul WSDL:
Element Descriere
<types> Defineste tipul de date (schemaXML) folosite de serviciul web
<message> Determina elementele de date pentru fiecare operatie
<portType> Descrie peratia ce poate fi executata si mesajul folosit
<binding> Descrie protocolul si formatul de data pentru fiecare port

Structura de baza a unui fisier WSDL este:

Exemplu de operatie cerere -raspuns :

Elementul binding are doua atribute – name (poate fi orice numere, defineste numele
binding -ului) si type (defineste portul buinding -ului, in exemplul de mai sus portul este
“glossaryTerm”).
Elementul soap: binding are doua atribute – style (poate fi “rpc” sau “document”) si
transport( defineste protocol care v -a fi utilizat – in exemplu de mai sus e HTTP).
Elementul operatio n defineste fiecare metoda expusa de portType.Pentru fiecare
operatie o actiune SOAP corespunzatoare trebuie sa fie definite, la fel trebuie specificat modul
de encodate adatelor de intrare si iesire (input and output elements), in exemplu e utilizat
“literal”.
Servicii web REST

Servicii web REST sunt construite pentru a lucra pe Web. Rep resentational State
Transfer (REST) este un stil arhitectural care specifica constrangeri, cum ar fi interfata uniforma,
care aplica la un serviciu web aduce proprietati dorite, cum ar fi performanta, scalabilitate si
mobilitate, care permit servicii sa lu creze mai bine pe Web. In stilul arhitectural REST, datele și
functionalitatea sunt considerate resurse si sunt accesate folosind Uniform Resource Identifiers
(URI-uri), de obicei link -uri de pe Web. Resursele sunt utilizate printr -un set de operatiuni
simple, bine definite.

Orice sistem foloseste resurse. Aceste resurse pot fi imag ini, fisiere video, pagini web,
informatii, sau orice altceva care poate fi reprezentat in prin intermediul calculatorului. Scopul
serviciului este de a furniza o fereastra clie ntilor sau ca ei sa poata acesa aceste resurse.
Arhitecturile serviciilor vor ca aceste servicii sa fie usor de impelmentat, mentinut, extins si sa fie
si scalabile. In general serviciile RESTful trebuie sa aiba urmatoarele proprietati:
 Reprezentare
 Mesaje
 URI-uri
 Interfata uniforma
 Stateless
 Sa existe relatii intre resurse
 Sa fie stocate (caching)

 Reprezentarea

Focusul serviiclor RESTful cade pe resurse si furnizarea accesului catre acestea. O resursa
poate fi privita ca un obiect precum in POO. O resursa poate sa fie compusa din alte resurse.
Cand se creaza un system, primul lucru care trebuiesc definiste sunt resursele si legaturile
dintre aceastea, este similar cu primul pas de creare a bazei de date: identificarea entita tilor si a
relatiilor. Odata ce au fost identificate resursele urmatorul pas este gasirea modului de
reprezentarea a acestora in system. Se poate utiliza orice format de reprezentare a resurselor,
REST nu impune nici o restrictive la nivelul formatului de reprezentare a resurselor . In functi de
cerinte se poate utiliza JSON sau XML. Daca se construiesc servcii web care vor fi folosite in
paginile web la apelurile AJAX atunci JSON este cea mai buna alegere. XML -ul deobicei este
utilizat pentru reprezentarea resurselor complexe. De exemplu resursa persoana poate fi
reprezentata ca:
 Reprezentarea JSON a resursei:
{
"ID": "1",
"Name": "M Vaqqas",
"Email": "m.vaqqas@gmail.com",
"Country": "India"
}
 Reprezentarea XML a resursei

<Person>
<ID>1</ID>
<Name>M Vaqqas</Name>
<Email>m.vaqqas@gmail.com</Email>
<Country>India</Country>
</Person>
 Mesaj

Clientul si serviciul comunica unul cu celalat prin intermediu mesajelor. Clientrul trimite o cerere
catre server, iar servelul raspunde. Pe langa resursa, mesajul contine si metadata despre mesaj.

HTTP Request
Request -ul HTTP are urmatoarul format:

 <VERB> este una din metodele HTTP precum: GET, PUT, POST , DELETE , OPTIONS
 <URI> este URI -ul resurselor unde se vor executa
 <HTTP Version> este versiunea de HTTP, in general e "HTTP v1.1" .
 <Request Header> contine medata ca o colectie ca o pereche de tipul cheie -valoare a
hederilor si a valorilor acestora. Aceste setari contin informatii despre mesaj si
expeditor precum: tipul clientul, formatul suportat de client, tipul formatului a corpului
mesajului si alte informatii.
 <Request Body> continutul mesajul. In serviciul REST aici se gaseste reprezentarea
resuselor. Nu exista nici un tag care sa specific inceputul sau sfarsitul mesajului HTML.

Exemplu de request de tip POST, care trebuie sa inser eze o noua persoana (resourcePerson) :
POST http://MyService/Person/
Host: MyService
Content-Type: text/xml; charset=utf -8
Content-Length: 123
<?xml version="1.0" encoding="utf -8"?>
<Person>
<ID>1</ID>
<Name>M Vaqqas</Name>
<Email>m.vaqqas@gmail.com</Email>
<Country>India</Country>
</Person>
Raspunsul HTPP

 Serverul returneaza <response code> – care contine statusul cererii( request -ului).
Acest codde raspuns este format din 3 digiti (200, 404, 302, 500 etc).

 <Response Header> contine metadata si setarile despre mesajul de raspuns .
 <Response Body> contine re prezentare mesajului de raspuns.

Exemplu de raspuns:
HTTP/1.1 200 OK
Date: Sat, 23 Aug 2014 18:31:04 GMT
Server: Apache/2
Last-Modified: Wed, 01 Sep 2004 13:24:52 GMT
Accept-Ranges: bytes
Content-Length: 32859
Cache-Control: max -age=21600, must -revalidate
Expires: Sun, 24 Aug 2014 00:31:04 GMT
Content-Type: text/html; chars et=iso-8859-1
<!DOCTYPE html PUBLIC " -//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1 -strict.dtd ">
<html xmlns='http://w ww.w3.org/1999/xhtml '>
<head><title>Hypertext Transfer Protocol – HTTP/1.1</title></head>
<body>
…

 URI

Serviciile REST cer ca resursele sa fie reprezentate cel putin de un URI. Lucrul URI -lor este
identificarea resurselor sau a colectiilor de resurse. Operatia actuala este determinate de verbul
HTTP, URI -ul nu trebuie sa zica sau sa specific nimic despre operatie sau actiunea ce trebuie
sa fie executata. Acest fapt permite apelarea aceluiasi URI cu diferite verbe HTTP pentru a
executa diverse operatii.
Sa presupunem ca avem o baza de date cu personae si vrem sa o expunem prin
intermediul unui serviciu. O resursa persoana poate fi expusa ca si:

http://MyService/Persons/1

Acest URL are urmatorul format: Protocol://NUmeleServiciului/TipulResurse/IDResursa .

Parametri de interogare in URI

Scopul principal al parametrului de interogare este de a furniza parametri catre operatiile care
au nevoie de date.
URI-ul precedent construit cu ajutorul parametrului de interogare:
http://MyService/Persons?id=1
Prin intermediul acestui URI se apeleaza metoda de cautare a persoanei cu id -ul 1.

 Interfata uniforma

Sistemul RESTful trebuie sa aiba o interfata uniforma. HTTP 1.1 asigura un set de metode, numite verbe,
pentru acest scop. Cele mai importante verbe sunt:
Metoda Operatia executata pe server Calitatea
GET Citeste o resursa Safe
PUT Insereaza o resursa noua sau o actualizeaza pe cea existenta . Idempotent
POST Insereaza o resursa noua . Deasemenea poate fi folosita in actualizarea resursei
deja existente. N/A
DELETE Sterge resursa. Idempotent
OPTIONS Afiseaza lista cu operatii ce poate fi executate pe o resursa . Safe
HEAD Returneaza doar header -ul raspunsului. Safe

Diferente dintre POST si PUT

Diferenta esentiala intre PUT si POST este ca PUT este idempotent in timp ce POST nu
este. Nu conteaza de cate ori ai trimite o cerere de PUT, rezultatele vor fi la fel . Apelarea
metodei POST de mai multe ori poate duce la crearea a mai multor resurse pe server.
O alta diferenta este ca pentru me toda PUT trebuie specificat URI -ul complet al resursei.
Acest lucru implica faptul ca clientul trebuie sa fie capabil sa construiasca URI -ul resursei chiar
daca aceasta nu exista pe server. Daca clientul nu poate sa “ghiceasca” URI -ul resursei, atunci
pentru a executa o operatie se apeleaza metoda POST.
 Statelessness

Serviciul RESTful este un serviciu stateless si nu mentine starea aplicatie pentru nici un
client. O cerere nu poate depinde de o cerere anterioara si serviciul trateaza fiecare cerere
independent. HTTP este un protocol stateless si pentru a implementa un serviciu stateful
(men tine stareaanterioara a sistemului) folosind HTTP este necesar implementare extra.
 Relatii intre resurse

Reprezentarea unei resurse poate sa contina relatii cu alte resurse.
Sa presupunem ca o Persoana face parte dintr -un Club, atunci Clubul reprezentant in serviciu
va fi:
<Club>
<Name>Authors Club</Name>
<Persons>
<Person>
<Name>M. Vaqqas</Name>
<URI>http://MyService/Persons/1 </URI>

</Person>
<Person>
<Name>S. Allamaraju</Name>
<URI>http://MyService/Persons/12 </URI>
</Person>
</Persons>
</Club>
 Caching

Caching – este un concept de stocare a raspunsurilor generate si fo losirea rezultatelor stocate in
schimbul gererarii lor in mod repetat in cazul in care apare o cerere identica in viitorul apropiat. Acest
lucru poate fi executata atat pe partea de client, server sau pe un alt calculator intermediar, spre
exemplu un serve r proxy. C aching -ul este o modalitate foarte buna de a creste performanta serviciului,
dar daca nu e gestionat i n mod corespunza tor, aceasta poate furniza la client ului rezultate vechi.
Caching -ul poate fi controlat prin intermediul urmatoarelor headere al HTTP -ului:
Header Application
Date Data si ora cand reprezentarea a fost generate.
Last Modified Data si ora cand serverul a modificat ultima data reprezentarea .
Cache-Control The HTTP 1.1 header folosit pentru controlul cache -lui
Expires Data si ora de expirare a reprezentarii
Age Durata masurata in secunde de cand a fost trimisa reprezentarea de la server. Poate fi introdusa de o
component intermediara.

Concluzie

Inainte de a petrece ore in sir in scopul alegerii intre servicii SOAP sau REST, dar sunt anumite
persoan e care prefer a SOAP si alte prefer REST. In cazul in care se doreste crearea propriilor servicii web
trebuie v azut care dintre acestea satisfa ce mai bine nevoiele propuse, decat ce protocol trebuie folosit.
De exemplu ser viciile web de la Amazon sprijina ambele tipuri de servicii.

Bibliografie
1. Migrating to a service -oriented architecture – Kishore Channabasavaiah and Kerrie Holley, IBM
Global Services and Edward M. Tuggle, Jr., IBM Software Group April 2004
2. Develop Servi ce-Oriented Architecture Solutions, Antony Reynolds Matt Wright 2010
3. SOA Made Simple, Lonneke Dikmans Ronald van Luttikhuizen 2012
4. REST Vs SOAP The Difference Between Soap And Rest – http://spf13.com/post /soap -vs-rest
5. http://blog.manishchhabra.com/2013/04/rest -and-soap -web -services -analogy/
6. http://www.w3schools.com/xml/xml_services.asp