Serviciibunbun 140818040019 Phpapp02 PDF

LENU}A ALBOAIE, SABIN BURAGA
Servicii Web
Inteligen]\ artificial\ [i web semantic
Seria Web este coordonat de dr. Sabin Buraga

(Facultatea de Informatic, Universitatea Al.I. Cuza, Iai)
Lenua Alboaie este doctorand la Universitatea Al.I. Cuza din Iai i are ca domenii de interes
serviciile Web i sistemele distribuite. n prezent, este cercettor programator la Axiologic Research,
SRL i cadru asociat al Facultii de Informatic a Universitii Al.I. Cuza.
Sabin Buraga este lector doctor la Facultatea de Informatic a Universitii Al.I. Cuza din Iai,
fiind titularul cursurilor Tehnologii Web, Semantic Web, Interaciune om-calculator i Reele
de calculatoare. Este laureat al Premiului Gheorghe Crtianu al Academiei Romne (2005). Mai
multe amnunte privitoare la activitile sale sunt disponibile pe Web la adresa http://www.infoiasi.ro/
~busaco. La Editura Polirom a mai publicat: Atelier de programare n reele de calculatoare (n colaborare,
2001), Programare Web n bash i Perl (n colaborare, 2002), Proiectarea siturilor Web. Design i funcionalitate
+ CD (2002), Aplicaii Web la cheie (coord., 2003), Utilizare Linux (n colaborare, 2004), Situri Web la
cheie. Soluii profesionale de implementare (coord., 2004), Proiectarea siturilor Web. Design i funcionalitate + CD
(ediia a IIa, 2005) i Primii pai n Linux (n colaborare, 2006).
Bruna Zani, Augusto Palmonari (a cura di), Manuale di psicologia di comunit

1996 by Societ editrice il Mulino, Bologna
2006 by Editura POLIROM

www.polirom.ro
Editura POLIROM
Iai, B-dul Carol I nr. 4, P.O. BOX 266, 700506
Bucureti, B-dul I.C. Brtianu nr. 6, et. 7, ap. 33, O.P. 37; P.O. BOX 1-728, 030174
Descrierea CIP a Bibliotecii Naionale a Romniei:
ALBOAIE, LENUA
Servicii web: concepte de baz i implementri / Lenua Alboaie, Sabin Buraga. Iai :
Polirom, 2006
ISBN (10)973-681-522-6
ISBN (13)978-973-681-522-5
I. Buraga, Sabin
004.42
004.738.5
Printed in ROMANIA
POLIROM
2006
Cuprins
Prefa ................................................................................................................................................ 9
Capitolul 1. Prezentare general a serviciilor Web ...............................................13
1. Preambul .......................................................................................................................... 13
1.1. Protocolul HTTP pe scurt ................................................................................ 13
2. Arhitectura orientat spre servicii Web ................................................................... 19
2.1. Introducere ............................................................................................................ 19
2.2. Programarea aplicaiilor Web ........................................................................... 20
2.3. Servicii Web. Punerea problemei .................................................................... 21
2.4. Conceptul de serviciu Web bazat pe XML .................................................. 26
2.5. Modalitile de implementare i exploatare .................................................. 34
Referine ................................................................................................................................... 36
Capitolul 2. Familia XML........................................................................................................ 39
1. Preliminarii ....................................................................................................................... 39
2. XML (Extensible Markup Language) ............................................................................. 40
2.1. Caracterizare i trsturi eseniale ................................................................... 40
2.2. Pri componente ale unui document XML ................................................ 41
2.3. Membrii constitueni ai familiei XML ........................................................... 43
2.4. Spaiile de nume XML ....................................................................................... 44
2.5. XML Infoset ......................................................................................................... 45
2.6. Validarea documentelor XML .......................................................................... 47
2.7. Procesarea documentelor XML ....................................................................... 54
Referine ................................................................................................................................... 59
Capitolul 3. Descrierea serviciilor Web .............................................................................. 61
1. Punerea problemei ......................................................................................................... 61
2. WSDL (Web Service Description Language) ................................................................... 62
2.1. Modelul conceptual al WSDL .......................................................................... 64
2.2. Diferenele dintre specificaiile WSDL 1.1 i WSDL 2.0 ......................... 72
2.3 Exemple de documente WSDL ....................................................................... 72
2.4. Tipuri de operaii i mesaje .............................................................................. 76
2.5 Platforme i instrumente de lucru cu documentele WSDL .................... 78
Referine ................................................................................................................................... 84
Capitolul 4. Protocolul SOAP ................................................................................................ 87

1. Evoluia protocoalelor bazate pe XML ................................................................... 87
1.1. Prezentare succint a protocoalelor din prima generaie ......................... 87
1.2. Dezavantajele protocoalelor din prima generaie ....................................... 90
2. SOAP scurt istorie .................................................................................................. 91
3. SOAP o vedere de ansamblu ................................................................................. 92
4. Forma general a unui mesaj SOAP.
Procesarea datelor de ctre serverele SOAP .......................................................... 94
5. Modelul SOAP mesaje i codificri ...................................................................... 98
5.1. Mesajele SOAP .................................................................................................... 98
5.2. Elementul Envelope .............................................................................................. 99
5.3. Elementul Header ............................................................................................... 100
5.4. Corpul mesajului SOAP. Elementul Body .................................................... 104
5.5. Maniera de codificare a mesajelor SOAP Encoding .............................. 108
5.6. Reguli de serializare .......................................................................................... 116
6. Maniera de transport al mesajelor SOAP ............................................................. 119
6.1. Relaia dintre SOAP i HTTP ....................................................................... 119
6.2. Relaia dintre SOAP i transportul de mesaje
de pot electronic (e-mail) .......................................................................... 122
7. Apelul de proceduri la distan via SOAP RPC ................................................. 124
8. Versiuni SOAP ............................................................................................................. 130
9. Intermediarii SOAP ..................................................................................................... 130
10. O privire asupra SOAP 1.1. O comparaie cu SOAP 1.2 ............................... 133
Referine ................................................................................................................................. 140
Capitolul 5. Descoperirea serviciilor ................................................................................. 143
1. Descoperirea serviciilor Web prin UDDI ............................................................. 143
1.1. Scurt istoric ......................................................................................................... 144
1.2. Concepte de baz ale UDDI ......................................................................... 144
1.3. Structura tModel .................................................................................................. 150
1.4. Informaii privitoare la publicarea serviciului ............................................ 152
1.5. Taxonomia entitilor UDDI ......................................................................... 153
1.6. Interfee de programare pentru UDDI ....................................................... 155
1.7 UDDI i SOAP ................................................................................................. 158
1.8. UDDI i WSDL ................................................................................................ 159
1.9. Crearea propriului registru UDDI folosind jUDDI ................................. 171
2. WSIL (Web Service Inspection Language)...................................................................... 179
Referine ................................................................................................................................. 182
Capitolul 6. Dezvoltarea i utilizarea serviciilor Web ................................................. 185
1. Dezvoltarea i invocarea de servicii Web
folosind instrumente open source ................................................................................ 185
1.1. Introducere .......................................................................................................... 185
1.2. Furnizarea stocurilor de portocale via
un serviciu Web scris n PHP 5 .................................................................... 186
1.3. Un client PHP pentru serviciul Web privitor la portocale .................... 188
1.4. Un serviciu de manipulare a fiierelor implementat
n Perl cu SOAP::Lite ....................................................................................... 189
1.5 Scrierea n Perl a clientului SOAP ............................................................... 192
1.6. Invocarea serviciului de ctre un client PHP ............................................ 196
2. Inter-operabilitatea ntre diverse tehnologii,
instrumente i limbaje de programare a serviciilor Web ................................... 199
2.1. Dezvoltarea de servicii Web n .NET Framework ..................................... 199
2.2. Un client C# pentru serviciul creat ............................................................. 210
2.3. Accesarea dintr-un script Perl a serviciului Web
implementat n .NET ....................................................................................... 212
2.4. Invocarea din PHP a serviciului Web .......................................................... 213
2.5. Invocarea de servicii Web externe ................................................................ 216
2.6. Folosirea instrumentului gSOAP pentru C/C++ ..................................... 224
2.7. Implementarea serviciilor Web n Java ........................................................ 228
2.8. Suportul oferit de mediul Delphi pentru crearea
i utilizarea serviciilor Web ............................................................................. 237
3. Invocarea serviciilor Web n contextul AJAX ..................................................... 245
3.1. Punerea problemei ............................................................................................ 245
3.2. Caracteristici importante ale suitei de tehnologii AJAX ......................... 245
3.3. Invocarea asincron a unui serviciu Web via AJAX ............................... 249
3.4. Utilizarea bibliotecii Prototype .......................................................................... 255
3.5. Invocarea direct, din JavaScript, a unui serviciu Web ........................... 259
3.6. Transferuri asincrone prin Atlas ASP.NET ................................................ 263
Referine ................................................................................................................................. 271
Capitolul 7. Retrospectiv i perspective ........................................................................ 273
1. Procesul de dezvoltare a serviciilor Web .............................................................. 273
2. Alte iniiative viznd serviciile Web ........................................................................ 275
2.1. Privire de ansamblu .......................................................................................... 275
2.2. Adresarea serviciilor prin WS-Addressing ..................................................... 276
2.3. Descoperirea serviciilor ................................................................................... 276
2.4. Coordonarea serviciilor Web .......................................................................... 278
2.5. Accesarea resurselor serviciilor Web ............................................................ 283
2.6. Accesarea meta-datelor asociate serviciilor ................................................ 285
2.7. Securitatea serviciilor Web .............................................................................. 286
2.8. Asigurarea inter-operabilitii ......................................................................... 295
2.9 Serviciile Web n contextul proceselor de afaceri .................................... 298
2.10. Servicii Web pentru grid ................................................................................... 302
3. SOA n contextul noului Web ..................................................................................... 304
Referine ................................................................................................................................. 307
Acronime......................................................................................................................................... 311
Bibliografie general ........................................................................................................................ 317
Prefa
Misiunea crii de fa este, cel puin pentru autori, att una relativ dificil, ct mai
ales! atrgtoare: ne propunem s prezentm sistematic unul dintre domeniile
importante, dinamice i de succes ale tehnologiilor actuale serviciile Web. Astfel,
adresm acest volum viitorului sau actualului programator Web care dorete s se
iniieze n tehnologiile i metodologiile de dezvoltare a serviciilor Web bazate preponderent pe SOAP. Desigur, nu uitm nici abordarea REST, concretizat n ilustrarea
invocrii de servicii n mod asincron via suita de tehnologii AJAX.
Plecnd de la metafora c putem asemna un serviciu Web cu o portocal, vom
ncerca s decojim straturile poate uneori mai aspre ale specificaiilor privitoare
la descrierea prin WSDL a interfeei i implementrii serviciului, la protocolul de
transport SOAP i la descoperirea prin diverse metode (e.g., UDDI) a serviciilor
disponibile n regim public sau privat. ntr-un anumit moment vom ajunge i la miez,
adic tocmai la prezentarea limbajelor, instrumentelor i platformelor ce ofer suport
pentru crearea i invocarea de servicii Web.
Programatorii se vor putea delecta cu diverse biblioteci, framework-uri i servere de
aplicaii, prinznd gustul implementrii de servicii (cu mult) mai complexe. Nu uitm s
enumerm noiunile de baz privitoare la familia XML baza pe care se fundamenteaz
ntreg eafodajul de limbaje i iniiative privitoare la serviciile Web ori s tragem cu
ochiul la livada de portocali actuali, (re)prezentnd perspectivele domeniului.
Materialul i are drept destinatari pe toi cei interesai de tehnologiile Web n general
i de servicii Web n special: studeni de la faculti de profil, elevi din clasele terminale,
dezvoltatori din cadrul companiilor, alte categorii de specialiti n informatic sau n
domenii conexe. Notm, en passant, c una dintre cerinele obligatorii ale seciunii
Software Design a deja bine-cunoscutei competiii internaionale Imagine Cup este ca
fiecare echip concurent s implementeze cel puin un serviciu Web
Vom descrie n continuare structura lucrrii de fa.
Capitolul 1 conine o prezentare general a serviciilor Web, n contextul dezvoltrii
aplicaiilor distribuite bazate pe XML. Tot aici realizm o trecere n revist a caracteristicilor principale ale protocolului HTTP, introducem SOA (arhitectura orientat
spre servicii) i discutm necesitatea existenei tehnologiilor SOAP, WSDL, UDDI,
REST.
Al doilea capitol se focalizeaz asupra familiei de limbaje XML. Descriem sintaxa,
spaiile de nume, manierele de validare i tehnicile de procesare a documentelor XML.
Insistm asupra unor concepte privitoare la XML Schema i modelul DOM, deoarece
ne vor fi de folos pe parcursul crii.
10
PREFA
Cel de-al treilea capitol este dedicat manierei de descriere a serviciilor Web. n
primul rnd, ne oprim asupra limbajului WSDL: componente, tipuri de documente, de
operaii i de mesaje, exemple i instrumente de lucru.
n cadrul capitolului patru detaliem inima serviciilor Web SOAP. Dup o
succint prezentare a protocoalelor de transport bazate pe XML, realizm o privire de
ansamblu a protocolului SOAP. De asemenea, printre altele, sunt descrise: structura i
maniera de codificare a mesajelor, modul de procesare i transport ale datelor, relaia
dintre SOAP i HTTP i diferenele dintre versiunile n vigoare ale acestui important
protocol.
Capitolul cinci are drept subiect descoperirea serviciilor Web. Prima parte se
focalizeaz asupra UDDI, unul dintre cele mai populare mecanisme de cutare a
serviciilor, mai ales prin prisma proceselor de afaceri pe care le modeleaz. Dup
detalierea arhitecturii UDDI, a tipurilor de informaii stocate i a intimitilor privind
funcionarea, oferim i o soluie practic de constituire a unui registru UDDI propriu
prin intermediul instrumentului open source jUDDI. A doua parte a capitolului vizeaz
descoperirea dinamic a serviciilor prin WS-Inspection.
Pentru unii dintre cititorii mai grbii, capitolul ase ar putea reprezenta cea mai
incitant parte a volumului, deoarece cuprinde reete de sdire a serviciilor Web
fie ele referitoare la portocale (albastre) sau la alte aspecte i de consumare a
funcionalitilor oferite de acestea. Am folosit majoritatea limbajelor de programare
(C/C++, C#, Java, Perl, PHP, Visual Basic), a instrumentelor (Apache Axis2, gSOAP,
NuSOAP, SOAP::Lite) i mediilor de dezvoltare (.NET, Java, Delphi) actuale, fie ele
comerciale sau liber disponibile. Tot aici punctm etapele care trebuie parcurse pentru
accesarea serviciilor Web externe (Google i XMethods) i ilustrm principiile de baz
ale suitei de tehnologii AJAX. Prezentm, de asemenea, maniera de invocare asincron
a serviciilor Web, fie direct via programe JavaScript , fie pe baza unor biblioteci i
framework-uri precum Prototype i Atlas ASP.NET.
Ultimul capitol realizeaz o recapitulare a tematicilor atinse i traseaz diverse
direcii de evoluie, invitndu-i pe cei interesai s aprofundeze domeniul. Astfel,
prezentm succint iniiative industriale ca WS-Addressing, WS-Discovery, WS-Coordination
sau WS-AtomicTransaction. Suplimentar, punem n discuie aspecte referitoare la ingineria,
securitatea i asigurarea inter-operabilitii serviciilor Web. Spre final, degustm rapid
rolul serviciilor Web n cadrul proceselor de afaceri, al sistemelor de tip grid i al noului
Web (ale crui tendine sunt cunoscute sub denumirea generic de Web 2.0, etap
preliminar Web-ului semantic).
Volumul se ncheie cu un set cuprinztor de acronime folosite n text i, n mod
firesc, cu o bibliografie general.
Aceast carte nu ar fi ajuns la forma actual fr ajutorul oferit att prin
parcurgerea versiunilor preliminare, ct i prin formularea unor sugestii utile de Snic
Alboaie, Mihaela Brut, Diana Gorea, Adrian Iftene, Loredana i tefan Tanas i, nu n ultimul
rnd, Cosmin Vrlan. Suntem recunosctori profesorilor notri Toader Jucan, Cornelius
Croitoru, Dorel Lucanu i Henri Luchian, de la Facultatea de Informatic a Universitii
Alexandru Ioan Cuza din Iai. De asemenea, mulumim familiilor noastre i echipei
de profesioniti a Editurii Polirom.
PREFA
11
La finalul acestei prefee trebuie s menionm contribuiile autorilor, dup cum

urmeaz: capitolele 3, 4 i 5 au fost redactate n principal de Lenua Alboaie, care a
realizat i implementarea exemplelor de servicii Web scrise n limbajele C/C++, Java
i Visual Basic .NET din cadrul capitolului 6. Restul materialului, inclusiv ilustraiile, a
fost preponderent conceput de Sabin Buraga.
Pentru experimentarea codului-surs al programelor incluse, nu ezitai s vizitai
adresa http://www.infoiasi.ro/~busaco/books/ws/. De asemenea, v invitm s ne contactai
prin pota electronic la adria@infoiasi.ro i, respectiv, busaco@infoiasi.ro.
Autorii
Iai, 3 septembrie 2006
Capitolul 1
Prezentare general a serviciilor Web

Cea mai bun cale de a prezice viitorul
este s-l inventm.
(Alan Key)
1. Preambul
Spaiul World Wide Web reprezint un sistem de distribuie local sau global a
informaiilor hipermedia, vzut ca univers informaional compus din elemente de
interes, denumite resurse, desemnate de identificatori globali URI (Uniform
Resource Identifiers).
Din punct de vedere tehnic, Web-ul pune la dispoziie un sistem global i
standardizat de comunicare multimedia (summum de media), informaiile fiind
organizate asociativ i distribuite n funcie de cererile utilizatorilor, funcionnd
conform modelului client/server. Prin definiie, clientul (n cazul nostru denumit
i navigator sau agent-utilizator Web) solicit servicii (informaii) de la componenta server. Serverul rspunde aadar cererilor clienilor, protocolul folosit
fiind, uzual, HTTP (HyperText Transfer Protocol).
1.1. Protocolul HTTP pe scurt

Dat fiind importana protocolului HTTP, vom realiza n continuare o trecere n
revist a caracteristicilor sale importante.
Protocolul HTTP, standardizat de documentul RFC 2616, este folosit n
special pentru hipertext, dar poate fi considerat drept protocol generic, baza
comunicrii ntr-un sistem distribuit de management al datelor, n cazul WWW
fiind vorba n principal de facilitarea transferului de date ntre clienii i serverele
Web. Fiind un protocol utilizat n Internet, HTTP se situeaz la nivelul de
aplicaii al stivei de protocoale TCP/IP (Transmission Control Protocol/Internet
Protocol), putnd fi considerat fiabil (reliable).
14
SERVICII WEB
Concepte fundamentale
Conceptele de baz sunt cererea i rspunsul: un client Web trimite un mesaj
(cererea) la un server. Mesajul conine identificatorul resursei dorite, dat sub
forma unui URI (Uniform Resource Identifier), metoda de acces folosit, versiunea
protocolului, precum i o serie de meta-informaii care pot fi utile serverului.
Rspunsul serverului cuprinde un cod indicnd starea serverului dup interpretarea cererii, un mesaj explicativ pentru codul de stare transmis, meta-informaiile care vor fi procesate de ctre client i, eventual, un coninut (e.g.,
resursa solicitat).
n general, o sesiune de comunicare HTTP este iniiat de ctre client i
const din solicitarea unei resurse (o pagin Web, uzual) identificat unic pe un
server cunoscut. Acesta este numit i server de origine datorit faptului c n
comunicarea ntre client i server pot s apar unul sau mai muli intermediari:
proxy (numit i server proxy), poart (gateway) sau tunel (tunnel). Entitatea proxy
reprezint un intermediar care retrimite un mesaj HTTP, eventual modificnd o
parte a sa. Poarta semnific un intermediar care se poate situa naintea unui
server de origine i s se identifice drept acesta, clientul Web necunoscnd acest
aspect. Tunelul este un intermediar care nu schimb coninutul mesajului, ci are
rolul exclusiv de retransmitere a lui; de exemplu, tunelul poate fi folosit pentru
(de)criptarea mesajelor vehiculate ntre server i client n cadrul unui intranet/
extranet.
Un alt concept important este cel de cache, desemnnd un depozit local de
stocare (n memorie, pe disc) a mesajelor (datelor) la nivel de server/client. Un
proxy deine obligatoriu un cache, denumit i sistem de cache.
Un exemplu tipic de cerere-rspuns este urmtorul, n care cererea formulat
de un browser are forma:
GET /catalog_produse.html HTTP/1.1
Host: www.portocale.info
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5
Accept: text/html, image/gif, image/jpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate, compress, identity
Connection: Keep-Alive
Un posibil rspuns obinut din partea serverului Web ar putea fi urmtorul

(am omis coninutul propriu-zis al documentului solicitat):
Date: Tue, 22 Aug 2006 07:17:13 GMT
Server: Apache/2.0.54 (Win32) PHP/5.0.4
PREZENTARE GENERAL A SERVICIILOR WEB
15
Accept-Ranges: bytes
Content-Length: 201
Keep-Alive: timeout=15, max=74
Connection: Keep-Alive
Content-Type: text/html; charset=ISO-8859-1
...
Adresarea resurselor via URI

Modalitatea de adresare a resurselor Web este reprezentat de identificatorii uniformi
de resurse URI (Uniform Resource Identifiers). Mulimea URI e compus din
localizatori uniformi de resurse URL (Uniform Resource Locator) i nume uniforme
de resurse URN (Uniform Resource Name).
Adresele de tip URL sunt folosite n localizarea unei resurse n reea (n
special n Internet) prin protocolul HTTP, avnd forma bine-cunoscut
http://server:port/cale?interogare, unde n mod implicit, dac nu e precizat, portul se
consider 80, iar cale reprezint un ir de directoare delimitate de /, terminat
eventual cu numele fiierului care stocheaz resursa adresat prin intermediul
URL-ului. Componenta interogare este opional i desemneaz un ir suplimentar,
incluznd informaii interpretate de resurs (de cele mai multe ori de un script).
De precizat faptul c o serie de caractere sunt rezervate, cum ar fi simbolurile
;, /, ?, :, @, &, =, + i $. Aceste caractere speciale sunt
codificate conform unei metode denumite URL encoding n care caracterul n
cauz este substituit de codul su numeric, n baza 16, prefixat de semnul %
(de exemplu, ~ devine %7E).
Un URL poate avea drept sufix un identificator de fragment, precedat
de caracterul #, cu scopul de a face referire direct la o parte constituent
a resursei adresate de acel URL. Drept exemplificare, se poate da URL-ul
http://www.portocale.info/catalog_produse.html#albastre.
O adres de tip URN desemneaz un subset al URI care rmne permanent
i unic, chiar dac resursa a disprut ori a devenit inaccesibil. URN-ul se
utilizeaz mai ales pentru a desemna entiti (tipuri de date, spaii de nume etc.)
folosite de anumite aplicaii Web. Drept exemplificri, enumerm:
urn:mozilla:package:communicator identific pachetele software ale suitei Mozilla;
urn:schemas-microsoft-com:datatypes desemneaz tipurile de date definite de
Microsoft;
urn:ISBN:978-973-46-0249-0 desemneaz numrul ISBN (International Standard
Book Number) asociat unei cri.
Mai general, adresele URI pot preciza resurse care pot fi accesate prin intermediul
unor diverse protocoale (uzual, cele bazate pe TCP/IP). Astfel, forma generic
16
SERVICII WEB
a unui identificator uniform de resurse este schema://autoritate/cale?interogare. O

serie de exemple de scheme sunt:
file:///tmp/ schem ce desemneaz resurse de tip fiier din cadrul sistemului
de stocare de la nivelul clientului (aici, directorul /tmp);
ftp://ftp.funet.fi/pub/README.txt schem utilizat pentru serviciile protocolului de transfer de fiiere (FTP);
https://www.infoiasi.ro/~busaco/teach/ schem pentru serviciile protocolului
securizat HTTPS HTTP folosit n conjuncie cu SSL (Secure Sockets Layer)
sau TLS (Transport Layer Security);
mailto:busaco@infoiasi.ro schem mailto pentru pota electronic;
tag:blogger.com,2006:blog-333 schem destinat s identifice n mod unic (spaial
i temporal) o anumit resurs, ntr-o manier convenabil pentru utilizator
(n acest caz, este vorba de subiectele de interes ale unui blog);
uuid:d52c-e89c-01f8-3b53-a25e-89cf-a5bb-ad17 schem care specific un identificator unic universal (UUID Universal Unique IDentifier) ce desemneaz o
anumit resurs; acest identificator se reprezint prin 32 de cifre n baza 16
i se regsete uneori i sub denumirea de GUID (Globally Unique IDentifier).
Maniera de codificare a coninutului

Pentru ca datele s fie corect interpretate de toate entitile participante la
conversaia prin reea, indiferent de platforma hardware i software, ele trebuie
s respecte aceeai codificare.
Astfel, se definete conceptul de set de caractere, pentru a putea interpreta
corect datele schimbate via protocolul HTTP ntre dou platforme diferite (e.g.,
un server rulnd pe un sistem Linux cu un navigator Web de pe un dispozitiv
mobil), avnd reprezentri diferite ale datelor. Informaia e transmis sub forma
unui ir de caractere urmnd ca entitatea de la cellalt capt, folosind indicaiile
despre setul de caractere, s realizeze transformarea din ir de octei n ir de
caractere. Setul de caractere implicit este ISO-8859-1, dar exist o multitudine de
alte seturi (de exemplu, ISO-8859-2 denumit i Latin-2, care ofer printre altele
i reprezentarea diacriticelor din limba romn).
Protocolul HTTP respect seturile de caractere definite de specificaiile MIME
(Multipurpose Internet Mail Extensions) descrise n documentele RFC 2045 i 2046.
Conform standardului MIME, pentru fiecare resurs n parte se specific tipul i
subtipul acesteia. De exemplu, text/html pentru un document HTML, text/plain
n cazul unui document text neformatat, image/png pentru o imagine n format
PNG, application/json n situaia datelor vehiculate via JSON (JavaScript Object
Notation), application/soap+xml pentru mesajele SOAP (Simple Object Access Protocol)
i multe altele.
17
De asemenea, mesajele pot fi codificate prin diverse metode, precum gzip ori
compress, n vederea comprimrii sau asigurrii identitii i/sau integritii.
Mesajele HTTP
Cererile i rspunsurile HTTP sunt vehiculate prin intermediul mesajelor. Astfel,
mesajele HTTP sunt considerate de dou tipuri: cerere provenit de la un client
ctre un server i rspuns al serverului, trimis la acel client. Un mesaj e compus
dintr-o succesiune de linii de text, delimitate de caracterele CRLF (Carriage Return
i Line Feed). Prima linie semnific o cerere efectuat de un client sau un cod de
stare obinut de la server, urmat de un numr de atribute de antet.
Un antet (header) conine mai multe atribute care sunt folosite la completarea
unei cereri sau a unui rspuns cu meta-informaia necesar interpretrii corecte
a mesajului prin stabilirea unor valori specificate de ctre protocolul HTTP sau
a unor protocoale definite de utilizator (de exemplu, SOAP). Un atribut este
furnizat printr-un nume urmat de : i de o valoare (opional, n unele cazuri).
O cerere e specificat de o metod de acces, printre cele mai folosite fiind:
GET reprezint o cerere de accesare a unor informaii (reprezentri de
resurse). Un client HTTP (navigator, robot, program de descrcare, agregator
de tiri, player multimedia etc.) folosete metoda GET pentru a obine o
anumit resurs, fie c ea reprezint un fiier (document text, HTML, imagine
PNG sau JPEG, aplicaie, arhiv, document XML etc.), fie c indic execuia
pe serverul Web a unui proces care va produce datele dorite (e.g., invocarea
unui script CGI sau a unui program PHP);
HEAD este similar cu metoda GET, dar serverul va ntoarce un mesaj
avnd informaii doar n antet. Meta-datele din anteturile HTTP din rspunsul
la o cerere HEAD vor fi identice cu cele din rspunsul la o cerere GET.
Utilitatea acestei metode const n obinerea meta-datelor asociate unei resurse
Web fr a transfera efectiv ntreaga entitate, n vederea de exemplu a
testrii existenei resursei, a obinerii datei ultimei modificri sau furnizarea
drepturilor de acces;
POST este utilizat pentru a identifica dac serverul accept o entitate
nglobat n cerere. POST este proiectat s implementeze o metod uniform
pentru funcii precum adnotarea resurselor, trimiterea datelor unui formular
Web ctre server, extinderea unei baze de date printr-o operaiune de inserare,
invocarea unui serviciu etc.
n cadrul unei cereri pot fi specificate diverse atribute, utilizate pentru a
transmite serverului informaii suplimentare privitoare la acea cerere i la client.
18
SERVICII WEB
Se poate face o analogie ntre trimiterea unei metode HTTP i apelul unei
funcii dintr-un limbaj de programare, unde atributele reprezint parametrii de
intrare.
Dup primirea i interpretarea unui mesaj de tip cerere i interpretarea lui, un
server HTTP ntoarce un mesaj denumit rspuns. Prima linie conine versiunea
protocolului HTTP implementat de ctre server i continu cu un cod de stare
reprezentnd un numr asociat de ctre specificaia HTTP unei anumite situaii
a serverului n urma tratrii unei cereri. Urmeaz un text explicativ pentru codul
de stare, menit s clarifice situaia exprimat de acesta.
Codul de stare este format din trei cifre organizate n categorii de stri;
codurile din aceeai categorie se refer la stri similare. Ele se disting dup prima
cifr n modul urmtor:
Coduri de informare (1xx) furnizeaz informaii privitoare la o anumit
aciune (cererea a fost primit, comunicaia continu). De exemplu: 100
Continue (clientul poate continua cererea, trebuind s trimit urmtoarea parte
a unui mesaj parial).
Coduri de succes (2xx) raporteaz efectuarea cu succes a unei operaiuni
(cererea a fost primit, interpretat i acceptat de ctre server). Un cod tipic
din aceast categorie este 200 OK (cererea a fost rezolvat cu succes). Alt
exemplu este 204 No Content (serverul a rezolvat cererea, dar nu are ce returna
clientului).
Coduri de redirecionare (3xx) indic o redirecionare a cererii spre alt
locaie ori alt server. Drept exemple, menionm codurile 301 Moved Permanently
(resursa solicitat a fost asociat unui URI nou i orice referin viitoare la ea
trebuie s se realizeze prin acest URI furnizat) i 302 Moved Temporarily
(resursa cerut are asociat un alt URI, dar pentru o perioad temporar).
Coduri de eroare provocate de client (4xx) specific apariia unei erori pe
partea clientului (fie cererea este incorect din punct de vedere sintactic, fie
nu poate fi satisfcut din varii motive). Ca exemple, furnizm 401 Unauthorized
(cererea necesit autentificarea utilizatorului e.g., via un nume de cont urmat
de o parol) i 403 Forbidden (serverul a recepionat o cerere corect, dar
refuz s o satisfac din diverse motive legate de restricionarea accesului).
Un alt cod tipic, des ntlnit, este 404 Not found (serverul nu gsete resursa
specificat).
Coduri de eroare generate de server (5xx) desemneaz coduri semnificnd
o eroare pe partea serverului (cererea este aparent corect, dar serverul nu o
poate ndeplini din anumite motive). Drept exemplificare menionm 503
Service Unavailable (serverul Web nu poate satisface cererea e.g., din cauza
suprancrcrii temporare sau din raiuni de administrare).
19
Lista tuturor codurilor de stare este disponibil n specificaiile HTTP.

n tabelul de mai jos poate fi parcurs lista unora dintre cele mai importante
atribute care nsoesc mesajele HTTP.
Atribut HTTP
Accept
Semnificaie
Specific unei cereri, cu rol n stabilirea tipului coninutului prin
intermediul unei negocieri conduse de server; clientul are posibilitatea de a furniza tipurile media (MIME) pe care acesta le
recunoate i le poate interpreta sau poate indica numai tipul de
rspunsuri preferate. Un exemplu este Accept: text/xml,
application/xml
Cache-Control
Connection
Content-Type
Host
Location
Server
Permite controlul cache-ului, de cele mai multe ori la nivelul

proxy-ului dintre client i server Cache-Control:
max-age=600
Atribut general folosit pentru a specifica anumite proprieti

legate de conexiune. Se aplic doar comunicaiei ntre dou
aplicaii HTTP din lanul unor cereri sau rspunsuri. E util n
implementarea conexiunilor persistente Connection: close
Desemneaz tipul MIME al reprezentrii resursei solicitate de un
client ori transmise de server. Un exemplu notoriu este
Content-Type: text/html
Folosit ntr-o cerere pentru specificarea adresei Internet i a portului n vederea stabilirii exacte a locaiei unde se afl resursa
creia i se adreseaz cererea Host: www.portocale.info
Specific rspunsurilor HTTP. Utilizat n conjuncie cu coduri de
stare de tip 3xx sau 201 Created. Poate stabili locaia curent sau
preferat a resursei sub forma unui URI absolut.
Conine informaii despre aplicaia server, cum ar fi numele,
versiunea, productorul, aplicaiile compatibile Server:
libwww-perl-daemon/1.36
2. Arhitectura orientat spre servicii Web

2.1. Introducere
Sistemul pe care ruleaz un server Web i care gzduiete o serie de pagini
(documente) WWW nrudite ale unei organizaii, companii sau persoane se
numete sit (site). Aceast colecie este orientat, de obicei, ctre anumite
informaii unitare sau scopuri comune.
Din punctul de vedere al vizibilitii, un sit Web poate fi disponibil doar n
cadrul unui intranet (reeaua intern proprie unei companii sau organizaii) i/sau
20
SERVICII WEB
n extranet (extindere a facilitilor intranetului prin mijlocirea comunicaiilor

ntre intraneturile a dou sau mai multe organizaii).
O aplicaie Web reprezint o colecie interconectat de pagini Web cu un
coninut dinamic, menit s ofere o funcionalitate specific utilizatorilor. Natural,
interaciunea dintre aplicaie i utilizatori are loc prin intermediul unei interfee
Web. Deseori, termenii de sit i aplicaie Web sunt folosii unul n locul celuilalt,
pentru a desemna acelai concept. Drept exemple de aplicaii Web pot fi
enumerate Amazon, Basecamp, eBay, Expedia, Flickr, Google Maps, PHPMyAdmin,
Wikipedia, Yahoo! i multe altele.
2.2. Programarea aplicaiilor Web

Devine evident faptul c trebuie recurs la un mecanism de generare dinamic a
coninutului Web redat utilizatorului, prin intermediul browser-ului, n funcie de
datele de intrare, de modul de navigare printr-un sit i de diveri ali factori
(autentificare, integrare de coninuturi preluate de pe alte situri, preferine etc.).
Informaiile puse la dispoziie pot fi eterogene, provenind din surse de date
multiple (fiiere text, baze de date, documente XML, stream-uri multimedia,
arhive software, rezultate ale unor operaii efectuate la distan, pe alte calculatoare, i aa mai departe).
Din punct de vedere istoric, prima metod de generare dinamic pe server a
reprezentrilor unor resurse solicitate de un client Web vizeaz standardul de facto
CGI (Common Gateway Interface). Principalele dezavantaje sunt cele privitoare la
invocarea concurent a mai multor script-uri CGI, problemele survenite fiind
asigurarea scalabilitii, a integrrii cu alte aplicaii, persistena conexiunii i
contextul invocrii (rulrii).
Evoluia a continuat cu apariia altor interfee de programare Web pe partea
de server. Astfel, pot fi menionate mod_perl pentru Apache, NSAPI (Netscape
Server API) i ISAPI (Microsoft Internet Services API), funcionnd intern conform
modelului CGI. Ulterior a aprut i tehnologia servlet-urilor Java.
De un succes larg se bucur ns mediile i framework-urile care faciliteaz
dezvoltarea de aplicaii Web, printre cele mai populare numrndu-se ASP
(Active Server Pages), ASP.NET (parte integrant a .NET Framework), PHP (PHP:
Hypertext Prepocessor) i JSP (Java Server Pages). Principalele avantaje ale acestora
fa de vechiul, dar nc utilizatul CGI, sunt urmtoarele: suportul pentru
sesiuni, asigurarea load-balancing-ului, conexiunile persistente cu sistemele de baze
de date, suportul pentru template-uri de interfa, facilitile viznd modularitatea,
securitatea etc. Desigur, n unele situaii pot fi folosite i cadre de lucru adiionale.
21
2.3. Servicii Web. Punerea problemei

Premise
Dup cum am mai menionat, originile i scopurile Web-ului iau n considerare
constituirea unui spaiu de comunicare interuman prin intermediul partajrii
cunotinelor i exploatarea puterii computaionale puse la dispoziie de calculatoarele interconectate. Se poate observa cu uurin faptul c interaciunea
dintre om i Web se rezolv prin intermediul formularelor i legturilor hipertext,
iar interaciunea dintre maini se desfoar pe Web ntr-o manier limitat.
O prim abordare este aceea de a recurge la un mecanism care s ne permit
apelarea unor operaii menite a fi executate la distan. Astfel, un program client
poate s invoce proceduri (metode, funcionaliti) pe alte calculatoare din reea.
Aceast soluie este oferit de paradigma RPC (Remote Procedure Call), pe care o
vom prezenta pe scurt n cadrul urmtoarei seciuni.
RPC ( Remote Procedure Call)

Mecanismul RPC a aprut cu mai bine de dou decenii n urm n lumea UNIX
i a fost/este folosit n construcia de aplicaii distribuite pe sisteme eterogene,
avnd la baz tehnologiile Internet.
Paradigma RPC confer for modelului client/server i constituie un instrument de programare mai simplu fa de abordarea clasic oferit de socket-uri.
Dac n mod obinuit modelul client/server se axeaz mai mult pe partea de
comunicaie ntre procese aflate pe maini diferite, RPC este mai aproape de
proiectarea clasic a aplicaiilor, programatorul focalizndu-se pe logica programului i abia la final diviznd aplicaia n componente i adugnd suportul
de comunicare n reea.
O aplicaie RPC va consta dintr-un client i un server, serverul fiind localizat
pe maina care execut procedura. Aplicaia client comunic prin reea via
TCP/IP cu procedura de pe calculatorul aflat la distan, transmind argumentele i recepionnd rezultatele. Clientul i serverul se execut ca dou
procese separate care pot rula pe calculatoare diferite din reea.
Aceste procese client i server comunic n mod transparent, prin intermediul
a dou interfee numite ciot (stub): va exista deci un stub pentru client i altul
pentru server. Interfeele implementeaz protocolul RPC, care specific modul
cum se construiesc i cum se prelucreaz mesajele emise ntre procesele client i
server. Stub-urile se genereaz de obicei cu ajutorul unui utilitar, dup care se
leag de programele client i server. Fiierele stub conin funcii care translateaz
22
SERVICII WEB
(de obicei, fr aportul programatorului) apelurile locale de procedur ntr-o

secven de apeluri de funcii RPC de reea. Astfel, din punctul nostru de vedere,
totul se consider a fi un simplu apel local. Clientul cheam procedurile din
stub-ul su prin care utilizeaz biblioteca RPC pentru a gsi procesul la distan,
urmnd ca apoi s-i transmit cereri. Procesul la distan ascult reeaua prin
intermediul stub-ului propriu. Stub-ul serverului realizeaz invocarea rutinelor
dorite cu ajutorul unei interfee de apel de proceduri locale.
Clientul i serverul trebuie s comunice prin mesaje, utiliznd o reprezentare
a datelor independent de calculator i de sistemul de operare. RPC adopt un
format propriu pentru reprezentarea datelor, cunoscut sub numele de XDR
(External Data Representation) i descris pe larg n documentul RFC 1014. Tipurile
standard suportate de XDR sunt cele uzuale din limbajul C (precum int, unsigned
int, float sau void), plus altele, suplimentare. Stub-urile client i server sunt
responsabile i cu translatarea n i din acest format. Se permite translatarea
tipurilor predefinite din C, precum i a unor tipuri mai complexe, cum ar fi
vectorii de lungime variabil. Operaia de (de)codificare se numete (de)serializare
sau (un)marshalling.
O facilitate important oferit de RPC este ascunderea n totalitate a procedurilor de reea n interiorul interfeelor stub. Acest aspect conduce la simplificarea programelor client i server, eliminndu-se necesitatea de a controla detaliile
legate de comunicarea n reea. Deoarece sistemul RPC ncearc s ascund
detalii legate de reea, el include de obicei o convenie legat de schimbul de
argumente i rezultate ntre client i server, mrindu-se astfel gradul de portabilitate a aplicaiilor.
Astfel, RPC pune premisele oferirii de servicii (a cror implementare nu
trebuie s fie cunoscut de ctre clientul care dorete s-l foloseasc), adresele
clientului, serverului i numele serviciilor fiind pstrate la nivel simbolic. Un
serviciu de reea este identificat prin portul la care este oferit i unde exist un
daemon (proces care ruleaz n fundal) ateptnd cererile de conectare. Un port
n viziunea RPC reprezint un canal logic de comunicare. Comunicarea cu
serviciul se realizeaz via XDR, vehicularea datelor decurgnd la nivel binar,
conform unor reguli prestabilite de codificare, independente de platform.
Exist mai multe implementri ale paradigmei RPC. Prima, de referin, a fost
oferit de corporaia Sun Microsystems, fiind denumit Open Network Computing
RPC (ONC RPC) aceasta este de altfel cea mai rspndit implementare pentru
UNIX/Linux (detalii n RFC 1057). Procedurile la distan se vor include ntr-un
program la distan. Un program aflat la distan reprezint unitatea software
care se va executa pe o main aflat la distan. Fiecare program aflat la distan
corespunde unui server, putnd conine un set de una sau mai multe proceduri
23
la distan ori date globale. Procedurile pot partaja date comune. De remarcat
faptul c argumentele pasate procedurilor la distan trebuie s fie ncapsulate
ntr-o structur (similar cu struct din limbajul C) pentru a reduce numrul de
argumente transmise procedurii.
Fiecrui program aflat la distan i se va asocia un identificator unic, stocat
pe 32 de bii, iar fiecare procedur component (care va fi executat n cadrul
acelui program) este numerotat (indexat) secvenial de la 1 la n, unde n este
numrul maxim de proceduri ale acelui program. De asemenea, fiecare program
la distan va fi nsoit de un numr ntreg pozitiv desemnnd versiunea. Prima
versiune a unui program de obicei este 1. Urmtoarele versiuni vor fi identificate
de alte numere, n mod unic. Numerele de versiuni ofer posibilitatea de a
schimba detaliile de implementare sau extinderea capabilitilor aplicaiilor fr
a asocia unui program un identificator diferit.
Mecanismul RPC i gsete utilizri interesante, dintre care, cea mai important o reprezint accesul la sisteme de fiiere la distan prin NFS (Network File
System), prezent n orice mediu UNIX i semnificnd de fapt un sistem de fiiere
distribuit (distributed file system).
O alternativ la ONC RPC este mediul de calcul distribuit DCE (Distributed
Computing Environment), care constituie i fundamentul unor servicii de reea
vitale din Windows 2000/XP.
n anii 90, RPC a continuat s fie utilizat prin abordarea obiectual ORPC
(Object RPC), mesajele de cerere i rspuns de la distan fiind ncapsulate de
obiecte. Ca descendeni direci ai ORPC se pot enumera DCOM (Distributed
Common Object Model) i IIOP (CORBA Internet Inter-ORB Protocol). Arhitectura
Java pune la dispoziie RMI (Remote Method Invocation), iar platforma .NET ofer
aa-numitul .NET Remoting.
Necesitatea unei arhitecturi orientate spre servicii. Caracterizare

Odat cu proliferarea aplicaiilor Web, dezvoltatorii i-au dat seama c nevoile
industriei de profil au crescut, dorindu-se existena unor soluii multi-platform
slab-conectate. Acestea conduc la integrarea aplicaiilor, serviciilor i sistemelor,
prin folosirea tehnologiilor Web actuale. Aceast integrare trebuie s se realizeze
ntr-un mod flexibil, ad hoc, n funcie de necesiti. De asemenea, trebuie atins
un grad nalt de performan prin asigurarea scalabilitii i e necesar existena
unui suport pentru crearea i exploatarea unor servicii ataabile (pluggable) i
inteligente; software-ul fiind vzut n termeni de serviciu i nu drept aplicaie
mamut (software as service).
Aceasta pune premisele constituirii unor ofertani de servicii de aplicaii
(application service provider). De asemenea, apare necesitatea proiectrii i (re)folosirii
24
SERVICII WEB
unor standarde pentru ndeplinirea cerinelor legate de vehicularea, disponibilitatea, mentenana, securitatea i regsirea datelor.
Spaiul Web poate fi considerat din acest punct de vedere ca o tehnologie
middleware, extensie a unor modele precum CORBA sau DCOM (a se urmri i
figura 1). Componentele intermediare (proxy) la nivel de client i server pot juca
acelai rol ca interfeele stub RPC.
Figura 1. Spaiul Web ca tehnologie middleware
Mai mult dect att, trebuie puse bazele constituirii unei arhitecturi destinate
dezvoltrii de aplicaii distribuite orientate spre Web. Software-ul trebuie divizat
n servicii care se pot compune, menite a se conecta i orchestra n mod spontan
n cadrul proceselor de afaceri sau din alte medii. Este o viziune a software-ului
bazat pe componente Web (component-based software), n contrast cu aplicaiile
monolitice, clasice. Desigur, software-ul standard (vechi) trebuie integrat n
aceast nou arhitectur pentru a se proteja investiiile fcute.
Soluia este dat de un model cunoscut sub numele de arhitectura orientat spre
servicii (SOA Service Oriented Architecture). Arhitectura SOA impune adoptarea
unui stil de dezvoltare de aplicaii, considerate drept servicii ce vor fi invocate
de alte aplicaii. Conform OMG (Object Management Group), definiia propus n
aprilie 2006 a arhitecturii orientat spre servicii este urmtoarea: SOA reprezint
25
un stil arhitectural de obinere a unor valori mutuale de ctre comunitile de

ofertani i consumatori de servicii, permind participanilor la aceste comuniti
de interese s conlucreze ntr-o manier ct mai puin dependent de tehnologie.
Acest stil specific, de asemenea, contractele pe care organizaiile, oamenii i
tehnologiile respective trebuie s le respecte n vederea participrii n cadrul
comunitii, n vederea obinerii de valori de tip business i derulrii de procese de
afaceri. Facilitarea interaciunilor n cadrul comunitii trebuie s se fac prin
intermediul unei varieti de tehnologii (prezente i viitoare).
Conform enciclopediei colaborative deschise Wikipedia, prin SOA se nelege
o perspectiv asupra unei arhitecturi software care definete utilizarea de servicii,
oferind funcionaliti solicitate de utilizatori. Resursele reelei sunt astfel disponibile graie unei suite de servicii independente ale cror implementri sunt
necunoscute.
SOA presupune c noile servicii pot fi create pe baza celor deja existente,
ntr-o manier sinergic, dar componentele sistemului n ansamblu trebuie s
aib un grad mare de independen (de-coupling). n funcie de schimbrile ce
pot interveni n cerine (business requirements), serviciile pot fi recompuse sau
orchestrate diferit.
Principiile de baz impuse de prevederile SOA sunt:
serviciile trebuie s partajeze un contract formal;

serviciile trebuie s fie slab conectate (loosely coupled);
serviciile trebuie s ascund dezvoltatorului detaliile de implementare;
serviciile trebuie s ofere suport pentru compunerea cu alte servicii
(composability);
serviciile trebuie s poat fi reutilizate;
serviciile trebuie s se execute ntr-un mod autonom;
serviciile nu trebuie s depind de starea comunicrii (statelessness), cantitatea
de informaie specific unei activiti ce trebuie reinut fiind minimal;
serviciile trebuie s poat fi facil descoperite (discoverability).
Astfel, arhitectura SOA trebuie s suporte ntre aplicaii paradigme de

comunicare bazate pe Web s ofere o localizare transparent a serviciilor i s
permit adugarea, nlocuirea i eliminarea serviciilor n mod dinamic.
Prin intermediul SOA, consumatorii de servicii nu sunt dependeni de
ofertanii de servicii, putnd avea acces la o palet larg de servicii oferind
aceleai funcionaliti dorite. Serviciul poate fi vzut doar drept interfa,
maniera de procesare (business logic) putnd fi separat de serviciul propriu-zis.
Via SOA, utilizarea i descoperirea serviciilor se pot realiza n mod dinamic,
facilitndu-se integrarea la nivel de aplicaii (A2A Application to Application)
26
SERVICII WEB
i/sau de afaceri (B2B Business to Business). Suplimentar, prin intermediul

serviciilor se poate realiza managementul proceselor de afaceri (BPM Business
Process Management).
Metodologia de proiectare i dezvoltare a aplicaiilor aliniate prevederilor
SOA poart numele de SOAD (Service-Oriented Analysis and Design). Una dintre
propunerile de astfel de metodologii este cea publicat de IBM n 2004 SOMA
(Service-Oriented Modelling and Architecture).
2.4. Conceptul de serviciu Web bazat pe XML

Precursori
n mod obinuit, putem implementa serviciile Web recurgnd la script-uri CGI
sau diverse servere de aplicaii. Interaciunea tradiional poate decurge n
urmtoarele dou moduri.
Prima manier este cea funcional (de tip cerere/rspuns): utilizatorul (nu
neaprat uman) viziteaz o pagin i formuleaz o cerere, fie traversnd o
legtur hipertext, fie prin intermediul unui formular. Serviciul (implementat de
un program conceput ntr-un anumit limbaj, precum Perl, PHP, C# ori Java)
ntoarce un rspuns, adic o reprezentare uzual, marcat n HTML a resursei
solicitate. Astfel, se acceseaz de la nivelul clientului o anumit funcionalitate
specific pus la dispoziie de un server Web.
Cea de a doua este una conversaional (de tip solicitare/rspuns). Suplimentar, se d posibilitatea exprimrii unor ntrebri adiionale n vederea rafinrii
cererii: serviciul solicit date de la utilizator pentru a returna un rspuns mai bun.
Se poate observa c serviciul Web, respectnd tradiia, expune o interfa-utilizator (conceput n limbajul de marcare HTML n marea majoritate a
cazurilor) prin intermediul creia are loc interaciunea. Cererile sunt captate via
formulare, utilizatorii umani trebuind s interpreteze etichetele (labels) ataate
cmpurilor de dialog, pentru a cunoate ce tipuri de date pot fi introduse (se
asigur cmpuri textuale, liste de opiuni, butoane de tip checkbox i radio etc.). De
asemenea, utilizatorii umani trebuie s interpreteze rspunsul oferit de serviciu
prin parcurgerea rezultatului redrii de ctre browser a reprezentrii (HTML)
expediate de server.
Pentru un calculator, activitile expuse mai sus sunt dificil de realizat,
deoarece programul de interpretare a rezultatului depinde de succesiunea de
marcaje ale paginii Web recepionate. Orice modificare, minor sau nu, a tag-urilor
din cadrul documentului conduce la rescrierea script-ului de prelucrare a ieirii
oferite de serverul Web. Aceast metod de capturare a informaiilor incluse
27
ntr-un document HTML se mai numete i Web/HTML scrapping i se dovedete

dificil de aplicat n cazul receptrii de structuri complexe de date.
Definiii i caracterizri
Serviciile Web bazate pe XML (Extensible Markup Language) fac explicite specificaiile implicite, putnd fi folosite n cadrul interaciunii dintre maini. Mai
mult dect att, pot fi invocate i n cazul necunoaterii a priori a interaciunii cu
alte aplicaii/servicii Web.
Nu exist o definiie unanim acceptat a conceptului de serviciu Web.
Conform IBM, reprezint o aplicaie modular bazat pe tehnologiile Internet,
menit a ndeplini activiti specifice i conformndu-se unui format tehnic
specific. Microsoft consider serviciile Web ca fiind partea de procesare a datelor
unei aplicaii (application logic) disponibil la nivel de program i beneficiind de
funcionalitile oferite de Internet. Dup Sun, un serviciu Web este o aplicaie
care accept cereri din partea altor sisteme dispuse n Internet sau intranet,
mediate de tehnologii de comunicaie neutre i agile.
Un serviciu Web ofer o funcionalitate specific accesat pe baza unui
schimb de mesaje marcate n XML. Acest schimb de mesaje e guvernat de
anumite reguli. Suplimentar, un serviciu Web se poate autodescrie, folosind
meta-date (date referitoare la date).
Serviciile Web implic utilizarea unor protocoale de comunicaie, avnd
asociate descrieri ale datelor procesate i alte interaciuni cu aplicaii tere.
Identificarea unui serviciu Web se realizeaz prin intermediul URI-urilor; transferul de date recurge n mod uzual la HTTP, iar definirea structurat a datelor
vehiculate se face via XML. Un serviciu Web poate fi considerat ca fiind compus
dintr-o colecie de funcii mpachetate, interpretate ca o entitate unic i publicate
n spaiul WWW cu scopul de a fi folosite de alte programe.
Ca exemple de operaii ce pot fi puse la dispoziie de serviciile Web, le
amintim pe urmtoarele:
transformarea datelor primite (e.g., conversii de valori n alte uniti de msur);
dirijarea mesajelor (mai ales n cazul magistralelor de date specifice,
disponibile la nivel de ntreprindere);
interogri asupra diverselor servere de baze de date relaionale, obiectuale sau
native XML (de exemplu, furnizarea cataloagelor de produse, a coordonatelor
unor localiti, a situaiei unui cont bancar, a istoricului cumprturilor
efectuate online etc.);
orchestrarea conversaiilor ntre diferite entiti (jucnd, din acest punct de
vedere, rolul de mediatori sau ageni);
28
SERVICII WEB
realizarea de procesri (calcule) diverse;

aplicarea de politici de acces asupra resurselor;
rezolvarea unor excepii ce pot surveni ntr-un context;
solicitarea de aprobri de la utilizator (e.g., a execuiei unor aplicaii de ctre
o alt entitate).
Drept principale caracteristici ale serviciilor Web menionm:
accesarea, n manier public, se realizeaz printr-o adres; serviciile Web pot fi

considerate ca reprezentnd puncte terminale (end points) ale comunicrii ntre
maini, similar modelului folosit de protocoalele de transport ale stivei TCP/IP;
abilitatea de a prelucra orice tip de date, din moment ce datele de intrare sunt
documente XML (conforme unei scheme de validare);
posibilitile de dezvoltare pe baza platformelor, arhitecturilor i limbajelor
existente;
adaptabilitatea (un serviciu Web poate fi extins, utiliznd eventual, n mod
transparent, alte aplicaii sau invocnd la rndul su alte servicii Web).
Serviciile Web sunt crmizile pentru crearea de sisteme distribuite deschise,
permind organizaiilor i dezvoltatorilor independeni s-i fac disponibile pe
Web bunurile digitale ntr-un mod rapid i facil.
Mai mult, serviciile Web separ modul de prezentare a datelor de partea de
prelucrare a acestora, fiind aliniate ablonului de proiectare MVC (Model-View-Controller), des ntlnit n domeniul ingineriei programrii. Modulul de interaciune cu utilizatorul (componenta view) este separat de cel de procesare (model),
reprezentat de serviciul Web n sine, comunicarea fiind facilitat de un strat de
control (controller) a se urmri figura 2. Astfel, rezultatele preluate de la serviciul
Web, ce ofer o anumit funcionalitate aplicaiei noastre, pot fi redate utilizatorului ntr-o multitudine de forme, fr a trebui s modificm (sau s avem
mcar acces la) implementarea serviciului.
Figura 2. Interaciunea ntre un serviciu Web i un client,

prin prisma MVC
29
Orice aplicaie-client (script Perl, applet Java, program C cu interfa text sau
grafic, aplicaie .NET, pagin ori serviciu Web etc.) poate consuma ntr-o
varietate de modaliti datele obinute de la un serviciu invocat printr-o
metod standardizat, bazat pe normele Web n vigoare.
Desigur, n afar de avantajele incontestabile oferite (inter-operabilitate ntre
diverse platforme i limbaje de programare, utilizarea de standarde i protocoale
deschise, reutilizarea componentelor software, lipsa unei relaii strnse ntre
entiti etc.), serviciile Web pot prezenta i dezavantaje, precum lipsa ori suportul
precar pentru tranzacii i performana relativ sczut fa de abordrile binare
(CORBA, DCOM ori RMI).
Odat cu proliferarea arhitecturii SOA, sunt disponibile servicii specifice
mediului enterprise, viznd aspecte legate de:
coninut specificarea, colectarea i organizarea cunotinelor din cadrul
organizaiei;
acces utilizatorii, via un portal/desktop Web, vor avea la ndemn mijloacele
de creare i de exploatare a serviciilor sau aplicaiilor compuse;
integrare n contextul EAI (Enterprise Application Integration) ndeosebi,
coninutul vehiculat de aplicaii/utilizatori va putea fi transformat graie unor
entiti software inteligente;
procesare se vor putea specifica reguli pentru managementul traficului de
date (dirijare, caching, filtrare etc.) n funcie de specificul afacerilor ntreprinse;
analizare acordarea unui suport avansat de luare (inteligent) a deciziilor;
colaborare va putea fi instituit o fundaie pentru managementul interaciunilor i comunicaiilor ntre utilizatori (umani sau nu) un exemplu n
acest sens este enterprise wiki.
XML pentru servicii Web: SOAP, WSDL i UDDI

Vom prezenta n continuare principalele componente folosite n invocarea,
definirea i regsirea serviciilor Web.
n primul rnd, apare necesitatea dezvoltrii unui protocol de comunicare (transport)
ntre maini eterogene care s faciliteze vehicularea de mesaje permind interaciunile complexe dintre calculatoare i avnd un coninut orict de complex.
Mai mult dect att, trebuie oferit suport pentru asigurarea extensibilitii,
lundu-se n calcul problemele de securitate, fiabilitate i performan ce pot
surveni. Acest protocol va trebui s pun la dispoziie un mecanism de invocare
i de transmitere structurat a datelor.
Trebuie, astfel, gsit un limbaj pentru transmisia n format XML a parametrilor
de intrare i ntoarcerea rspunsului primit de la serviciul Web invocat.
30
SERVICII WEB
Figura 3. Nivelurile de standardizare a serviciilor Web
Principalele protocoale de comunicare utilizate n prezent sunt XML-RPC i

SOAP.
XML-RPC ofer o specificaie i un set de implementri pentru realizarea de
apeluri de proceduri la distan, n spiritul mecanismului RPC descris succint mai
sus. A fost proiectat pentru a fi ct mai simplu, n acelai timp ns permind
i transmiterea, procesarea i returnarea unor structuri complexe. n mod succint,
putem considera ecuaia: XML-RPC = HTTP + XML + RPC.
SOAP (Simple Object Access Protocol) reprezint o recomandare a Consoriului
Web, propunnd faciliti sofisticate i oferind o palet larg de posibiliti de
reprezentare (serializare i deserializare) a datelor vehiculate.
Un mesaj SOAP este compus din trei pri: un plic (envelope), un set de reguli
de codificare (encoding rules) i o convenie de reprezentare (representation). Plicul definete
cadrul de lucru pentru a descrie ceea ce conine mesajul i modul de procesare
a acestui coninut. Datele din corpul mesajului pot fi transportate indiferent de
protocol (uzual, se recurge la HTTP). Regulile de codificare sunt de folos la
exprimarea instanelor tipurilor de date definite n aplicaie, iar convenia de
reprezentare este utilizat n contextul apelurilor de metode implementate de
serviciul Web i al rspunsurilor furnizate n urma invocrii acestora.
31
De asemenea, SOAP poate specifica i o cale de la expeditor la destinatar, via

un intermediar (proxy) opional, n vederea realizrii de dirijri de mesaje (SOAP
routing). Detalii sunt disponibile n capitolul 4 al lucrrii de fa.
Protocolul SOAP poate fi privit din mai multe perspective. Prima ar fi aceea
n care poate reprezenta o extindere obiectual a paradigmei RPC: cererea i
rspunsul conin parametrii de intrare/ieire, suplimentar fiind indicate, via
XML Schema, tipurile de date ale acestora. A doua consider SOAP ca fiind un
protocol de mesagerie (serializare), cererea incluznd un obiect-cerere serializat,
iar rspunsul stocnd un obiect-rspuns serializat. Cel de-al treilea punct de
vedere prezent i n cazul REST (vezi infra) admite o tranzacie SOAP ca
fiind o transformare XSLT la distan (XSLT with a long wire): cererea este un
document XML, iar serverul returneaz, ca rezultat al invocrii serviciului, o
versiune XML transformat a cererii. Desigur, nici una dintre aceste abordri nu
este impus de protocol.
n vederea exploatrii funcionalitilor puse la dispoziie de un serviciu
Web, trebuie oferit o descriere a acestuia. Apare necesitatea unui limbaj de
descriere, menit a rspunde la ntrebri precum Care e sintaxa mesajelor
vehiculate?, Cum se desfoar transferul de date? i Cum gsim un
serviciu Web?.
Soluia este furnizat de WSDL (Web Service Description Language). Limbajul
ofer separarea descrierii abstracte a funcionalitii oferite de un serviciu de
detaliile concrete (de tipul cum i unde este disponibil acea funcionalitate).
WSDL descrie serviciile Web ncepnd cu mesajele interschimbate ntre entitatea
care ofer i cea care invoc un anumit serviciu. Mesajele sunt specificate n
manier abstract i apoi sunt asociate unui protocol de reea, precizndu-se de
asemenea i un format (o sintax). Un mesaj const dintr-o colecie de date de
anumite tipuri, iar schimbul de mesaje este descris ca o operaie. Tipurile de date
se definesc via scheme XML, la nivel conceptual folosindu-se un model de date
reprezentat printr-un set de componente (mesaj, port, manier de ataare,
serviciu) avnd specificate diverse proprieti. La nivel sintactic se recurge la
XML. Mai multe amnunte privind WSDL vor fi oferite n capitolul 3.
Apare nc o cerin: instituirea unui mecanism pentru publicarea i regsirea,
n manier public, a unui serviciu Web. Este posibil ca o anumit funcionalitate
oferit de un grup de servicii Web s poat fi regsit prin intermediul unor
interogri formulate de partea care intenioneaz s foloseasc acea funcionalitate.
Pentru aceasta s-a constituit un catalog al tuturor furnizorilor de servicii Web
publice n vederea regsirii informaiilor dorite: UDDI (Universal Description,
Discovery, and Integration), oferind o baz de date distribuit a serviciilor Web din
32
SERVICII WEB
prisma tipurilor de afaceri electronice pe care acestea le pot modela. Conceptual,

datele stocate ntr-un catalog UDDI pot fi mprite n urmtoarele trei categorii:
paginile albe (white pages) semnific informaii generale referitoare la o companie furnizoare de servicii (numele companiei, descrierea tipurilor de afaceri
efectuate, adresa etc.);
paginile aurii (yellow pages) includ scheme de clasificare a companiilor i/sau
serviciilor disponibile (de exemplu, coduri de clasificare pe criterii geografice, ale
categoriei de afaceri, taxonomii referitoare la produsele comercializate i altele);
paginile verzi (green pages) precizeaz informaii tehnice despre un serviciu
Web specific (e.g., o adres Web spre descrierea acestuia, o adres privitoare
la invocarea serviciului etc.).
Uzual, cutarea n cadrul UDDI se realizeaz n funcie de clasa din care face
parte afacerea, dup un nume de serviciu sau dup locaia geografic a furnizorului. Detalii sunt furnizate n capitolul 5.
Figura 3. Relaiile dintre un client, un serviciu Web i registrul UDDI interogat prin SOAP
pentru a se obine descrierea WSDL a serviciului dorit
33
Funcionalitile de cutare sunt implementate via servicii Web, astfel nct

accesul la registrul UDDI se realizeaz prin intermediul protocolului SOAP
descris mai sus. UDDI va pune la dispoziie documentul WSDL corespunztor
unui serviciu compatibil cu cererea formulat a se vedea i figura 3.
Arhitectura REST
REST (REpresentational State Transfer) reprezint o arhitectur de dezvoltare a
aplicaiilor Web. Conform filosofiei REST, rezultatul unei procesri conduce la
returnarea unei reprezentri a unei resurse Web. Orice accesare a unei reprezentri
plaseaz aplicaia-client ntr-o stare care va fi schimbat n urma unui transfer de
date (accesarea altei reprezentri, pe baza traversrii unei legturi hipertext
desemnat de un URI inclus n reprezentarea resursei iniiale). Starea
comunicrii ntre mesajele vehiculate ntre server i client nu trebuie reinut
(stateless).
Transferul de date se realizeaz prin HTTP, reprezentarea este marcat n
XML (ori alt format), iar adresabilitatea se rezolv via URI, spaiul Web putnd
fi considerat drept un sistem REST.
Serviciile Web actuale se pot dezvolta n concordan cu arhitectura REST.
Componentele care invoc funcionaliti vor consuma reprezentri de resurse
(n stilul pull) conform clasicei arhitecturi client/server. Fiecare cerere este
considerat independent, fr a se lua n consideraie contextul conexiuni
stateless. Resursele Web pot fi accesate printr-o interfa generic pus la dispoziie
de metodele protocolului HTTP: GET, POST, PUT i DELETE. Actualmente
sunt utilizate preponderent GET i POST.
REST se consider a fi o viziune complementar de implementare i utilizare
a serviciilor Web, n locul mesajelor SOAP (al cror format e considerat de unii
dezvoltatori prea complex n anumite situaii) recurgndu-se la reprezentri
XML mai simple numite i POX (Plain Old XML). O astfel de abordare e
adoptat i de suita de tehnologii AJAX, prezentat n cadrul capitolului 6.
O aplicaie Web dezvoltat conform principiilor REST are o arhitectur
diferit de una n stilul RPC (acesta din urm fiind adoptat i de protocolul
SOAP). n cazul RPC, punctul focal e reprezentat de mulimea de operaii ce pot
fi executate (numite i verbe), pe cnd n viziunea REST totul se axeaz pe
diversitatea resurselor disponibile (denumite i substantive).
De exemplu, pentru o aplicaie Web privitoare la un sit de comer electronic
oferind sortimente de portocale, abordarea SOAP relev existena unor operaii
(metode) precum furnizeazaSortiment(), adaugaSortiment(), eliminaSortiment(), actualizeazaSortiment(), listeazaSortimente(), cautaSortimente() privitoare la sortimentele disponibile
34
SERVICII WEB
i furnizeazaUtilizator(), adaugaUtilizator(), eliminaUtilizator(), listeazaUtilizatori() i

cautaUtilizatori() referitoare la utilizatorii (clienii) magazinului virtual. Toate
aceste funcionaliti pot fi implementate de un serviciu Web bazat pe SOAP.
Recurgnd la REST, vom defini doar dou tipuri de resurse (Sortiment i Utilizator),
fiecare identificat unic de un URI (de exemplu, http://www.portocale.info/sortimente/
japoneze). O resurs poate avea asociate reprezentri XML ce pot fi accesate ori
alterate. Astfel, prin intermediul unor operaii HTTP standard, putem manipula
uor resursele. n acest mod, via GET putem obine o copie a reprezentrii unei
resurse, cu PUT actualizm o resurs, iar prin DELETE o tergem de pe server.
Metoda POST se folosete pentru aciuni care ar putea avea posibile efecte
colaterale (side effects) de exemplu, realizarea unei comenzi de plat a sortimentelor de portocale dorite.
Dup cum se observ, interfaa oferit de HTTP este una generic, oferind
suport pentru operaiile de baz, de tip CRUD (Create, Retrieve, Update, Delete)
creare, accesare, actualizare i tergere.
Actualmente, exist numeroase organizaii care i pun la dispoziie serviciile
via o interfa REST. Ca exemple notabile, menionm Amazon, Bloglines, del.icio.us,
eBay, Google i Yahoo!. De asemenea, pot fi folosite diverse cadre de lucru pentru
dezvoltarea de aplicaii Web n stilul REST: JAX-WS (Java API for XML: Web
Services), Tonic (pentru PHP), Ruby on Rails, Zope (pentru Python) etc.
2.5. Modalitile de implementare i exploatare

Existena serviciilor Web este insuficient fr a avea la ndemn instrumente
suplimentare de implementare, exploatare i integrare. Un aspect important este
dat de faptul c informaiile i serviciile trebuie s fie accesibile de pe orice tip
de calculator i de oriunde, aprnd astfel necesitatea utilizrii unei platforme
independente de dispozitiv, al crei rol poate fi jucat de o main virtual.
Noile servicii dezvoltate pot fi compuse din serviciile Web deja existente,
accesibile n mod transparent. Ne situm astfel la nivel de middleware, oferind att
funcionaliti (implementate de codul-surs al unor programe concepute n
limbaje diverse), ct i suport pentru inter-operabilitate.
Serverele Web actuale trebuie s funcioneze ca pori spre pagini i servicii
Web, deoarece nc exist o baz larg de situri aliniate stilului vechi (e.g.,
recurgnd la script-uri CGI i/sau servere de aplicaii convenionale).
Soluia este oferit de implementarea i exploatarea unui cadru de lucru
(framework) Web cu suport pentru SOA. Un astfel de cadru de lucru trebuie s
asigure suportul pentru protocoalele Web i cele nrudite (HTTP, SMTP, FTP
etc.), plus pentru familia XML.
35
Figura 4. Arhitectura stratificat a unui cadru de lucru

aliniat problematicilor serviciilor Web
De asemenea, trebuie s se pun la dispoziie mijloace pentru catalogarea,

descoperirea i integrarea serviciilor Web via UDDI i descrierea funcionalitii
i intrrilor/ieirilor graie limbajului WSDL, cu posibilitatea generrii automate
de documente WSDL asociate serviciilor Web implementate. Suplimentar, dezvoltatorii vor putea recurge la faciliti de specificare i ataare a unui context de
execuie, lundu-se n calcul factori precum autorizarea (cine poate invoca un
anumit serviciu), localizarea (unde e localizat serviciul: platform, server, port
folosit i altele), planificarea (cnd poate fi rulat serviciul) etc.
Pentru accesul la aplicaii i sisteme tradiionale (legacy) sau la servere de
stocare (backend servers), cadrul de lucru va trebui s ofere un nivel de integrare.
Mai mult dect att, e necesar existena unui nivel de interfaare (frontend) via un
server Web, care presupune existena unei/unor maini virtuale i a unui motor
de asigurare a fluxului de activiti (workflow engine). La nivelul cel mai de sus se
afl ofertantul de servicii Web sau utilizatorul direct al acestora vezi figura 4.
36
SERVICII WEB
Actualmente exist o sumedenie de tehnologii, produse i ofertani de servicii

Web, dintre care le enumerm doar pe urmtoarele: Apache Axis implementat n
Java, Borland Delphi/JBuilder Web Services, IBM Web Services Toolkit, JBoss, Microsoft
.NET Framework, NuSOAP i PEAR::SOAP pentru PHP, modulul SOAP::Lite
pentru Perl, Web Services Developer Pack pus la dispoziie de mediul Java. O parte
dintre ele vor fi utilizate n cadrul exemplelor incluse n aceast lucrare, n special
n capitolul 6. De asemenea, exist implementri oferite i de alte companii
precum Apple, BEA, Fujitsu, Hewlett-Packard, Oracle, SAP, Sybase etc.
Mai trebuie s remarcm faptul c au aprut diveri ofertani de servicii Web,
dintre care i enumerm pe Amazon, Blogger, cddb (CD DataBase), eBay, European
Bioinformatics Institute, Google, Interfax, LiveJournal, PayPal, RedHat, MSN (Virtual
Earth), Shopsync, Xignite i Yahoo!.
Drept direcii importante de evoluie se remarc, pe de o parte, implementrile
bazate pe Java i, pe de alt parte, serviciile Web bazate pe .NET Framework.
La finalul acestui capitol notm c unii specialiti consider c mediatizarea
tirilor (syndication) prin formatele deja notorii RSS (Really Simple Syndication) i
Atom constituie tot o form de acces la servicii Web. Astfel, informaii diverse
marcate n RSS ori Atom i disponibile prin intermediul serviciilor de tip feed
pot fi integrate i prelucrate n diverse alte aplicaii de sine stttoare (BitTorrent,
Excel sau iTunes) ori disponibile pe Web (e.g., Gmail, Indeed.com, RSSWheather,
TadaList, TagCloud, Technorati, Yahoo! Maps).
Referine
Albin, S., The Art of Software Architecture: Design Methods and Techniques, Wiley & Sons, 2003
Alboaie, L, Buraga, S., Dialoguri despre SOAP, NET Report, februarie 2003:
http://www.infoiasi.ro/~busaco/publications/articles/SOAP.pdf
Berners-Lee, T., Fielding, R., Masinter, L., Uniform Resource Identifiers (URI): Generic
Syntax, RFC 2396, Internet Engineering Task Force (IETF), 2004: http://www.ietf.org/
rfc/rfc2396.txt
Booth, D. et al. (eds.), Web Services Architecture, W3C Working Draft, Boston, 2003:
http://www.w3.org/TR/ws-arch/
Buraga, S., Tehnologii XML, Polirom, Iai, 2006: http://www.infoiasi.ro/~busaco/
books/xml/
Buraga, S., Proiectarea siturilor Web (ediia a doua), Polirom, Iai, 2005: http://
www.infoiasi.ro/~design/
Buraga, S., Ciobanu, G., Atelier de programare n reele de calculatoare, Polirom, Iai, 2001:
http://www.infoiasi.ro/~lrc/
Cabrera, L.F., Kurt, C., Web Services Architecture and Its Specifications, Microsoft Press, 2005
37
Coyle, F., XML, Web Services, and the Data Revolution, Addison-Wesley, 2002
Dumbill, E. et al., Programming Web Services with XML-RPC, OReilly, 2001
Erl, T., Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall PTR, 2005
Fielding, R., Architectural Styles and the Design of Network-based Software Architectures, Ph.D. Dissertation, 2000: http://www.ics.uci.edu/~fielding/pubs/dissertation/
top.htm
Freed, N., Borenstein, N., Multipurpose Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies, RFC 2045, Internet Engineering Task Force (IETF), 1996:
http://www.ietf.org/rfc/rfc2045.txt
Freed, N., Borenstein, N., Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types, RFC 2046, Internet Engineering Task Force (IETF), 1996: http://www.ietf.org/
rfc/rfc2046.txt
Gettys, J. et al., Hypertext Transfer Protocol HTTP/1.1, RFC 2616, Internet Engineering
Task Force (IETF), 1999: http://www.ietf.org/rfc/rfc2616.txt
Guruge, A., Web Services: Theory and Practice, Digital Press, 2004
He, H., What is Service-Oriented Architecture?, XML.com, 2003: http://webservices.xml.com/
pub/a/ws/2003/09/30/soa.html
He, H., Implementing REST Web Services: Best Practices and Guidelines, XML.com, 2004:
http://www.xml.com/pub/a/2004/08/11/rest.html
Jacobs, I., Walsh, N., Architecture of the World Wide Web, Volume One, W3C Recommendation, Boston, 2004: http://www.w3.org/TR/webarch/
Linthicum, D., Enterprise Application Integration, Addison-Wesley, 1999
Mahmoud, Q., Service-Oriented Architecture (SOA) and Web Services: The Road to Enterprise
Application Integration (WAI), Sun, 2005: http://java.sun.com/developer/technical/
WebServices/soa/
Myerson, J., The Complete Book of Middleware, Auerbach Publications, 2002
Tanenbaum, A., Distributed Operating Systems, Prentice Hall International, 1995
Weerawarana, S. et al., Web Services Platform Architecture, Prentice Hall PTR, 2005
* * *, Atom: http://atomenabled.org/
* * *, Flickr API Documentation: http://www.flickr.com/services/api/
* * *, Google Web API: http://www.google.com/apis/
* * *, IBMs DeveloperWorks Web Services: http://www-136.ibm.com/developerworks/
webservices
* * *, MSDN (Microsoft Developer Network): http://msdn.microsoft.com/
* * *, Representation State Transfer, Wikipedia.org, 2006: http://en.wikipedia.org/
wiki/Representational_State_Transfer
* * *, Service-oriented architecture, Wikipedia.org, 2006: http://en.wikipedia.org/
wiki/Service-oriented_architecture
* * *, Situl lui Paul Prescod: http://www.prescod.net/
* * *, Web Services Activity: http://www.w3.org/2002/ws/
* * *, World Wide Web Consortium, Boston, 2006: http://www.w3.org/
* * *, Yahoo! Developer Network: http://developer.yahoo.net/
Capitolul 2
Familia XML
Este mai bine s tii cteva ntrebri dect
toate rspunsurile.
(James Thurber)
1. Preliminarii
Pentru identificarea resurselor, Web-ul recurge la identificatori uniformi de
resurse (URI Uniform Resource Identifiers), iar pentru interaciune se folosete n
mod uzual protocolul HTTP. Reprezentarea resurselor se realizeaz via formate
de date. Arhitectura spaiului WWW ncurajeaz refolosirea formatelor existente,
printre aspectele importante legate de acest latur putndu-se enumera: adoptarea
formatelor textuale n contrast cu cele binare, controlul versiunilor, extensibilitatea, compunerea formatelor, separarea coninutului, prezentrii i interaciunii.
Cu proliferarea serviciilor Internet, mai ales ale Web-ului, datele au putut fi
publicate liber, folosindu-se un format de redare (prezentare) a informaiilor pus
la dispoziie de bine-cunoscutul HTML (HyperText Markup Language), n varianta
actual XHTML (Extensible HTML). n prezent, atenia cade asupra modelrii
ct mai eficiente a informaiilor, prin intermediul unui format deschis,
extensibil subiectul acestui capitol. Mai mult dect att, modelarea datelor nu
reflect doar sintaxa (care e specificat printr-un set de convenii de marcare), ci
i semantica pn acum reprezentat de codul-surs al programelor ce prelucrau
acele date.
Dac formatele de date transpun maniera efectiv de stocare i prezentare a
informaiilor, la nivel conceptual trebuie adoptat cel puin un model de reprezentare. Evoluia infrastructurilor de calcul a condus i la adoptarea unor modele
de date diferite.
Prezentul are la baz arhitecturile navigaionale, bazate pe hipertext (text
neliniar), utilizate de o pleiad de dispozitive, inclusiv cele mobile. Se consider
c unul dintre modelele de date cele mai potrivite este cel oferit de familia de
limbaje XML.
40
SERVICII WEB
2. XML (Extensible Markup Language)

Aproape de finalul secolului XX, Consoriul Web a dorit crearea unui limbaj
compatibil cu mai vechiul SGML (Standard Generalized Markup Language), dar care
s se preteze la utilizarea n cadrul spaiului WWW. n anul 1998, apare prima
recomandare-specificaie privitoare la XML (Extensible Markup Language), iar la
momentul scrierii acestei lucrri sunt n vigoare specificaiile XML 1.0 (ediia a
patra) i XML 1.1 (ediia secund).
2.1. Caracterizare i trsturi eseniale

Putem considera XML ca reprezentnd un standard internaional pentru descrierea de marcaje (markups) privitoare la resursele electronice. n fapt, XML reprezint
un meta-limbaj (descriere formal a unui limbaj, conform unei gramatici suit
de reguli prin care, pe baza unor simboluri, se genereaz cuvinte). La nceput, a
fost vzut ca un limbaj de adnotare (de formatare) de texte, dar scopurile actuale
depesc aceast interpretare ngust.
Termenul marcaj (markup) a fost utilizat iniial pentru a descrie anumite
adnotri, note marginale n cadrul unui text cu intenia de a indica tehnoredactorului cum trebuie listat un anumit pasaj ori chiar omis. Cum formatarea
i imprimarea textelor au fost automatizate, termenul s-a extins pentru a acoperi
toate tipurile de coduri de marcare inserate n textele electronice cu scopul de a
indica modul de formatare, listare ori alte aciuni.
Marcajul (codarea) reprezint o aciune de interpretare explicit a unui fragment
de dat. Astfel, un limbaj de specificare ofer un set de convenii de marcare utilizate pentru
codificarea textelor. Un limbaj de marcare trebuie s desemneze mulimea de
marcaje obligatorii, permise, maniera de identificare a marcajelor i care este
semantica fiecrui marcaj disponibil (similar procesului de specificare a sintaxei
i semanticii unui limbaj de programare).
Exist urmtoarele caracteristici definitorii ale XML, primele trei fiind preluate
de la SGML: utilizarea marcajelor descriptive (descriptive markups), adoptarea
tipurilor de documente via DTD (Document Type Definition), independena datelor
i caracterul case-sensitive (majusculele difer de minuscule).
Printre trsturile care au fcut meta-limbajul XML s fie folosit n industria
software putem enumera: suportul acordat Web-ului, facilitile pentru utilizarea
internaional, meta-limbajul (se permite definirea de noi limbaje ntr-o manier
portabil), soluiile pentru reprezentarea coninutului resurselor Web identificate
via URI.
FAMILIA XML
41
Aadar, XML este o metod de descriere universal a informaiei, astfel nct

att computerele, ct mai ales oamenii s o poat nelege. Scopurile limbajului
sunt cele legate de utilizarea lui n Internet, suportnd o varietate de aplicaii, dar
fiind mult mai flexibil dect HTML. Oferind o manier universal pentru
reprezentarea (descrierea) informaiilor hipertext, XML poate fi vzut ca o
tehnologie complementar limbajului HTML, nu ca o nlocuire a sa.
2.2. Pri componente ale unui document XML

Un document XML poate cuprinde urmtoarele categorii de constitueni: declaraia,
elementele, atributele, entitile, seciunile de marcare i instruciunile de procesare.
Documentele XML pot s nceap cu o declaraie (prolog) XML care specific
versiunea limbajului XML utilizat de exemplu: <?xml version="1.0"
encoding="UTF-8" ?> (de asemenea, s-a precizat i tipul de codificare a setului
de caractere folosit).
Componenta structural a unui document XML este elementul. Diferite tipuri
de elemente au asociate nume diferite. Fiecare element trebuie specificat explicit
prin intermediul marcajelor (tag-urilor). Perechea marcaj de nceput(start tag)-marcaj de sfrit (end tag) este folosit la ncadrarea fiecrei instane a elementului
respectiv n cadrul unui text. n XML se utilizeaz <element> pentru a specifica
un tag de nceput i </element> pentru cel de sfrit, unde element este
numele unui element oarecare (specificat de utilizator ori de autoritatea care a
redactat specificaiile limbajului bazat pe XML folosit). Regulile sintactice
privitoare la numele de elemente sunt similare celor privitoare la identificatorii
de variabile. Numele ncepnd cu caracterele xml (n orice modalitate de
scriere, cu majuscule sau minuscule) sunt rezervate. Numele de element nu
poate conine spaii albe.
Un element poate fi vid (nu conine nimic ntre tag-urile de nceput i sfrit),
putnd fi menionat fie <element></element>, fie prin forma prescurtat
<element />. De asemenea, poate include un text (ir de caractere) ori alte
elemente. Mai multe elemente de acelai tip pot fi, aadar, imbricate. Un aspect
deosebit de important este cel privitor la faptul c elementele trebuie s fie
nchise i imbricate corect.
Coninutul textual al unui element poate fi compus din caracterele permise de
codificarea precizat de atributul encoding din declaraia XML, orice apariie de
spaii albe multiple fiind implicit redus la un singur caracter spaiu.
Pentru a ilustra mai detaliat acest aspect, considerm un model structural foarte
simplu. Presupunem c dorim s identificm o comand de portocale ce va fi
procesat de un sit de comer electronic. Astfel avem:
42
SERVICII WEB
<portocale>

<achizitii>
<tip>Portocale greceti fr coaj</tip>
<cod>P10-01-GR</cod>
<cantit um="kg">3374</cantit>
</achizitii>

<vanzari>
<tip>Portocale japoneze albastre</tip>
<cod>P10-03-JP</cod>
<cantit um="kg">0107</cantit>
</vanzari>
</portocale>
Exemplul de mai sus nu ne precizeaz anumite reguli de compunere a

comenzii (de exemplu, nu putem impune ca tipul produsului solicitat s nu apar
de mai multe ori). Aadar, vom avem nevoie de un mecanism de specificare a
structurii.
Un atribut este utilizat cu scopul de a descrie o anumit proprietate a unei
apariii specifice (particulare) a unui element. Atributele sunt localizate n tag-ul
de start al unui element, imediat dup numele elementului i sunt urmate de =,
apoi de valoarea atributului scris ntre ghilimele sau apostrofuri. Dac valoarea
unui atribut nu este specificat ntre ghilimele, va fi semnalat o eroare, la fel ca
i n cazul n care pentru un atribut nu ar fi ataat i valoarea acestuia. Pentru
un element pot exista oricte atribute, specificate n orice ordine, att timp ct
sunt declarate corect.
Pentru exemplul dat mai sus, am specificat unitatea de msur kilogram
prin valoarea kg a atributului um asociat elementului <cantit>.
Referinele la entiti constituie de fapt pointeri ctre entiti. n XML,
entitile reprezint uniti de text, unde o astfel de unitate poate desemna orice,
de la un singur caracter la un ntreg document sau chiar o referin la un alt
document. O referin la o entitate prezint construcia sintactic &nume_entitate;
(caracterul & , urmat de numele entitii, apoi de caracterul ; ). Una dintre
cele mai frecvente utilizri ale referinelor la entiti este atunci cnd se dorete
folosirea unor caractere care ar conduce la erori de procesare i deci care nu ar
trebui s apar n forma lor normal n text (de exemplu, pentru a genera
simbolul < vom folosi <). n momentul n care se ntlnete referina la
o entitate n document, aceasta se va substitui cu datele pe care le refer i se va
returna documentul cu nlocuirile fcute.
Ocazional, anumite pri ale documentului necesit un tratament special n
ceea ce privete modul de procesare. Astfel, exist posibilitatea folosirii seciunii
FAMILIA XML
43
CDATA (character data), cu rolul de inhibare a prelucrrii construciilor XML.

Seciunile CDATA pot fi inserate oriunde pot aprea datele de tip caracter. Ele
sunt utilizate pentru a include blocuri de text coninnd caractere care altfel ar
fi recunoscute ca marcaje. Acest aspect devine important atunci cnd documentul
include, de exemplu, linii de cod-surs scrise ntr-un limbaj de programare care
are propriile convenii sintactice.
Sintaxa general a seciunii CDATA are forma <![CDATA[ ... ]]>.
Seciunile CDATA nu pot fi incluse unele n altele.
Un exemplu este urmtorul:
<achizitii>
<tip>Portocale greceti fr coaj</tip>
<obs><![CDATA[
Cantitatea trebuie s fie >2000.
]]></obs>
</achizitii>
Instruciunile de procesare reprezint un tip special de marcaj care conine

informaii privitoare la anumite aplicaii ce urmeaz a fi executate pentru
procesarea coninutului. Un exemplu este instruciunea de procesare care permite
ataarea de foi de stiluri documentelor XML n vederea redrii coninutului
acestora:
<?xml-stylesheet href="xml2html.xsl" type="text/xsl" ?>
2.3. Membrii constitueni ai familiei XML

Limbajul XML ofer mai mult dect o sintax comod pentru reprezentarea
datelor structurate sau semistructurate. XML consist dintr-o familie de limbaje
bazate pe XML pentru reprezentarea datelor i relaiilor dintre ele.
Aceast familie de limbaje, menite a adapta conceptele curente de stocare,
modelare i publicare pe Web a datelor, este compus din:
XML (Extensible Markup Language) subset al specificaiei SGML, conceput
pentru o implementare mai uoar. Modalitile de validare sunt concretizate,
uzual, de schemele XML, complementare DTD-urilor;
XLL (Extensible Linking Language) oferind suport pentru specificarea de
legturi hipertext, concretizat n dou componente majore:
XLink conceput pentru descrierea legturilor (simple sau multiple)
dintre resursele Web;
XPointer are ca scop precizarea n manier extensibil a unor scheme de
adresare a datelor XML;
44
SERVICII WEB
XSL (Extensible Stylesheet Language) permite transformarea documentelor

XML n alte tipuri de documente (XML, XHTML sau altele) i ataarea unor
obiecte de formatare, n vederea redrii coninutului XML n formate precum
PDF (Portable Document Format);
XQuery mpreun cu limbajul XPath, ofer posibilitatea interogrii documentelor XML.
Practic, este imposibil s se enumere toate limbajele bazate pe XML existente
la ora actual, standardizate sau nu. Numeroase limbaje utile, n numr de peste
500, sunt descrise la adresa http://xml.coverpages.org/.
2.4. Spaiile de nume XML

n unele situaii pot aprea confuzii, atunci cnd se folosesc date din diverse
surse (documente) XML care pot avea elemente/atribute cu acelai nume, dar cu
semnificaii (semantici) diferite. Pentru evitarea acestor ambiguiti sunt folosite
spaiile de nume, astfel nct numele de elemente i/sau atribute vor fi identificate
n mod unic, evitndu-se conflictele.
Necesitatea folosirii spaiilor de nume se poate remarca din exemplul urmtor,
n care considerm dou documente XML, primul cu informaii despre partenerii
de afaceri, al doilea despre numele furnizorilor de portocale:

<parteneri>
<partener>
<nume>Portocal Escu</nume>
<adresa>Aleea Zpezilor, 33</adresa>
</partener>
...
</parteneri>

<furnizori>
<furnizor adresa="http://ja.po.ro/">
<nume>Japo Nez S.A.</nume>
</furnizor>
...
</furnizori>
Documentul care le utilizeaz pe precedentele i folosete spaii de nume

pentru evitarea ambiguitilor (nume reprezint un nume de persoan sau un
nume de companie?; idem pentru adres) ar putea fi urmtorul:
FAMILIA XML
45
<comanda xmlns:p="http://www.undeva.ro/parteneri/">
<partener>
<p:nume>Portocal Escu</p:nume>
<p:adresa>Aleea Zpezilor, 33</p:adresa>
</partener>
<f:furnizor xmlns:f="urn:furnizori.info"
f:adresa="http://ja.po.ro/">
<nume>Japo Nez S.A.</nume>
</f:furnizor>
</comanda>
Atributul xmlns este folosit pentru declararea spaiilor de nume, iar valoarea
lui trebuie s fie un URI, fie localiznd o resurs prin adresa ei cazul URL
(Uniform Resource Locator), fie desemnnd un nume unic asociat resursei n cauz
facilitate oferit de URN (Uniform Resource Name). Prin intermediul construciei
xmlns , se asociaz un vocabular, denumit i spaiu de nume (namespace), pentru
elementele n cauz.
2.5. XML Infoset

XML nu trebuie considerat a fi doar o manier de precizare la nivel sintactic a
structurii i coninutului unor resurse. Mai mult dect att, Consoriul Web a pus
problema redactrii unei recomandri care s specifice un model de date (abstract)
pentru XML, numit XML Information Set (sau XML Infoset).
Prin intermediul acestei specificaii se ofer un punct de vedere comun
referitor la: serializarea datelor semistructurate, implementarea/folosirea de
interfee de programare (API-uri) pentru procesarea XML, definirea unor alte
recomandri de nivel (mai) nalt.
Acest model de date asigur inter-operabilitatea diferitelor tehnologii, interfee
de programare i aplicaii XML, stabilind o interpretare comun a conceptelor
folosite.
Sunt definite urmtoarele concepte de baz, mprtite de ntreaga familie
XML:
document (document information item) este considerat a fi un arbore, avnd nodul
rdcin dat de proprietatea [document element]. De asemenea, posed
proprietatea [children] oferind o serie de lucruri de interes (items);
element specific un element XML i are ataat proprietatea [parent]
coninnd informaii despre elementul printe cruia i aparine. Are asociat
i proprietatea [children] cu semantica descris mai sus. Proprietatea
[local name] specific numele local al elementului al crui scop (vizibilitate)
46
SERVICII WEB
e dat() de proprietatea [namespace uri] indicnd URI-ul spaiului de

nume folosit (vid, dac nu se specific spaii de nume). Prefixul spaiului de
nume utilizat este stocat de proprietatea [prefix]. Astfel, se d posibilitatea
precizrii calificate a numelor elementelor. Accesul la lista neordonat a
atributelor asociate elementului se face via proprietatea [attributes]. De
asemenea, proprietatea [namespace attributes] menioneaz lista neordonat a atributelor xmlns ataate;
atribut (attribute) desemneaz conceptul de atribut XML. Numele i spaiul
de nume ataat sunt specificate de proprietile [local name] i
[namespace name] . Elementul cruia i aparine este indicat de proprietatea
[owner element] , iar valoarea e specificat de [normalized value]
(valoarea normalizat, rezultat dup expandarea tuturor referinelor la
entiti);
caractere (characters) corespund informaiilor textuale ale coninuturilor elementelor XML. Proprietatea [parent] indic elementul cruia i aparin, iar
[children] conine datele-caracter propriu-zise. Setul de caractere utilizat e
oferit de proprietatea [character code].
Prin intermediul XML Infoset, datele XML nu trebuie neaprat s aib
reprezentri textuale, stocate n fiiere .xml, ci pot proveni din diverse alte surse
(obiecte, rezultate ale unor interogri etc.), cu reprezentri diferite. Intuitiv,
structura unui document XML complex poate fi mult mai uor neleas avnd
asociat o reprezentare grafic arborescent a se vedea figura 1.
Figura 1. Reprezentarea arborescent

a unui document XML
FAMILIA XML
47
2.6. Validarea documentelor XML

Punerea problemei
O prim necesitate n cazul adoptrii tehnologiei XML este aceea ca informaiile
marcate n XML s poat fi regsite, reutilizate i partajate ntre diverse aplicaii.
Astfel, o cerin important este de a cunoate:
setul de elemente/atribute ce pot fi specificate;
modul lor de structurare (e.g., ordinea, numrul minim/maxim de apariii,
contextul etc.);
tipul coninutului (de exemplu, cantitatea de portocale s reprezinte un
numr natural, aparinnd intervalului [0, 7433]);
ce anume este valid i ce reprezint eroare.
Soluia este ca un grup sau grupuri de indivizi (precum o companie, o
industrie, persoane, productori de instrumente software specifice sau un
consoriu) s specifice mulimea de elemente i atribute permise i regulile de
marcare, adic tocmai modelul structural amintit mai sus.
Modelul structural se aplic unei clase de documente XML, n vederea
verificrii printr-un analizor (numit i procesor sau parser) a corectitudinii
instanelor de documente aparinnd acelei clase. Se au n vedere aspecte privind:
modul de numire a elementelor/atributelor;

definirea regulilor de utilizare a acestora;
specificarea structurii i coninutului;
precizarea anumitor constrngeri;
oferirea unui set de convenii de numire.
Apare aadar necesitatea specificrii unui set de constrngeri asociate documentelor, astfel nct datele XML s fie verificate dac sunt valide sau nu din
punct de vedere structural sau al tipului coninutului.
Modalitile de precizare a constrngerilor se pot baza pe: descrieri (DTD i
XML Schema), reguli (Sablotron) i abloane (RELAX NG) detalii n cartea lui
Sabin Buraga, Tehnologii XML, Polirom, Iai, 2006.
48
SERVICII WEB
Descriere succint a XML Schema

Caracteristici
Deoarece este una dintre cele mai utilizate i versatile maniere de validare a
documentelor XML, n cele ce urmeaz vom prezenta cele mai importante
aspecte referitoare la XML Schema, recomandarea oficial a Consoriului Web.
O schem reprezint o specificaie formal a gramaticii asociate
unui document XML i reprezint, n fapt, tot un document XML stocat ntr-un
fiier avnd extensia .xsd (XML Schema Definition). O schem XML definete o
clas de documente XML conformndu-se unui model structural suplimentar,
specificnd un sistem de tipuri de date n termenii infoset-ului (vezi supra). Pentru
a putea fi verificat validitatea, o instan a unei clase de documente XML
trebuie s aib asociat o schem XML. Aceste aspecte sunt asemntoare celor
de la paradigma obiectual.
O schem va specifica modul de apariie i tipurile de date pe care le pot lua
valorile construciilor XML. Rezultatul obinut n urma unei validri ncununate
cu succes este numit i PSVI (Post-Schema Validation Infoset).
Schemele XML sunt utilizate n multe domenii, dintre care le enumerm pe
urmtoarele:
verificarea tipurilor de date n contextul sistemelor de baze de date (relaionale)
a mainilor virtuale (CLR, JVM) etc.;
serializarea automat a datelor;
invocarea la distan a metodelor (RMI Remote Method Invocation, SOAP
Simple Object Access Protocol) a se vedea cele discutate n capitolul 4;
generarea de cod-surs;
implementarea de editoare inteligente;
crearea validatoarelor generale de date (e.g., validarea formularelor electronice).
Construciile XML Schema trebuie s aparin spaiului de nume indicat de
adresa http://www.w3.org/2001/XMLSchema. Atributele privitoare la scheme ce
apar n cadrul unei instane a unei clase de documente vor proveni din spaiul
de nume specificat de http://www.w3.org/2001/XMLSchema-instance.
Construcii de baz
Un document XML Schema are ca element-rdcin <xsd:schema>. Definirea
sau instanierea unui element se realizeaz via <xsd:element> , iar n cazul unui
atribut prin <xsd:attribute>.
FAMILIA XML
49
Asemntor definirii unor tipuri de date i variabile ntr-un limbaj de

programare, ntr-o schem XML fiecare instan de element trebuie
s aparin unei clase (tip) de elemente. Un element/atribut va avea valori
permise ce aparin unui tip de date (simplu sau complex), specificat prin
<xsd:SimpleType> i, respectiv, <xsd:ComplexType> .
Tipurile simple, predefinite ori derivate din cele predefinite, descriu coninutul
datelor textuale. n acest caz, nu se permite ca un element s includ alte
elemente i nici s aib asociate atribute. Tipurile simple pot fi folosite i pentru
specificarea coninutului atributelor.
Tipurile complexe descriu datele (semi)structurate. n acest caz, se accept ca
elementele s includ alte elemente (prin reguli de apariie) i s aib asociate
atribute. Elementele de tip complex vor putea conine:
declaraii de elemente, prin intermediul construciei <element name="nume"
type="tip" /> ;
referine la elemente a priori definite: <element ref="nume" reguli_aparitie=
"valori" />;
declaraii de atribute via <attribute name="nume" type="tip" /> .
Tipurile complexe nu pot fi folosite n contextul stabilirii tipului valorilor
atributelor XML.
Consoriul Web a pus la dispoziie o palet larg de tipuri predefinite (primite
i derivate). Cele mai utilizate sunt enumerate n continuare:
numerice: byte, unsignedByte, integer, positiveInteger, negativeInteger,
int, long, decimal, float , double i altele;
logice: boolean;
privitoare la dat i timp: time, dateTime , duration, date, gYear , gMonth,
gDay etc.;
iruri de caractere: string, token i altele;
adrese Web: anyURI.
Ierarhia tipurilor de date XML Schema este ilustrat de figura 2.
Pentru codificri ale coninuturilor binare n cadrul documentelor XML se
poate folosi tipul base64Binary, care ofer o reprezentare a oricror iruri de
octei prin intermediul a 65 de caractere specificate de documentul RFC 2045.
Mulimea acestor caractere e compus din literele minuscule i majuscule, cifre,
diverse simboluri i caracterele desemnnd spaiile albe.
50
SERVICII WEB
Figura 2. Tipurile de date specificate de XML Schema
Putem defini tipuri simple derivate din cele predefinite via <xsd:simpleType> .
Noul tip de date specificat poate fi o restricie a unui tip deja existent prin
intermediul unor constrngeri (facets). Prin intermediul constrngerilor pot fi
precizate aspecte precum:
lungimea: <xsd:length> ;
lungimea minim: <xsd:minLength>;
lungimea maxim: <xsd:maxLength>;
un model (pattern), exprimat printr-o expresie regulat: <xsd:pattern>.
De asemenea, putem recurge la precizarea unei liste de valori (folosind

<xsd:enumeration>) ce va forma tipul sau a unui interval de valori (construciile
<xsd:minInclusive> , <xsd:maxInclusive> , <xsd:minExclusive> i
<xsd:maxExclusive>).
Tipurile simple noi vor fi folosite s descrie valorile elementelor/atributelor,
ataarea acestora unor construcii XML putnd avea loc fie n cadrul schemei la
declararea unui element, fie n cadrul instanei via atributul xsi:type.
FAMILIA XML
51
De asemenea, vom putea preciza urmtoarele (simbolul | semnific o

alternativ):
reguli (restricii) de apariie a unei instane de element: numrul minim de
apariii (minOccurs="numr") i/sau numrul maxim de apariii (maxOccurs=
"numr | unbounded");
reguli de apariie a unui atribut (obligatoriu, opional sau interzis): use=
"required | optional | prohibited" ;
valoarea predefinit a unui atribut via default;
valori particulare pentru elemente sau atribute: fixed.
De reinut c tipurile simple pot fi utilizate doar pentru a descrie date-caracter.
n vederea definirii structurii unui document se recurge la <xsd:complexType>.
Un tip complex poate avea un coninut simplu (<xsd:simpleContent> ) sau
unul complex.
Coninutul simplu nseamn c un element va putea include atribute, extinznd
astfel modelul-coninut. O prim metod este derivarea prin extensie, via
elementul <xsd:extension>, iar a doua modalitate vizeaz derivarea prin
restricie, realizat prin intermediul constrngerilor (facets). Atributele vor fi
definite prin intermediul <xsd:attribute>, putnd fi declarate global (la nivelul
schemei) sau local (n cadrul unui tip complex). De asemenea, ele pot fi calificate
(prefixate de spaiul de nume ales) sau nu.
Specificarea unui tip cu coninut complex vizeaz definirea listei i ordinii
sub-elementelor i atributelor sale. Coninutul unui element poate fi i mixt
(compus din sub-elemente sau date-caracter): <xsd:complexType mixed="true">
ori vid (nu va conine dect declaraii de atribute).
Pentru a preciza diverse modele ale coninutului, vom adopta construcii
referitoare la:
alternativ: <xsd:choice>;
secven: <xsd:sequence>;
grupare: <xsd:group>;
apariie a tuturor elementelor, n orice ordine: <xsd:all>.
De menionat i faptul c specificarea unor elemente/atribute generice (ale

altor tipuri de documente) se realizeaz prin elementele <xsd:any> i <xsd:
anyAttribute>. De asemenea, XML Schema ofer i suport pentru documentare
via <xsd:annotation> .
n continuare vom furniza un exemplu de schem XML menit a valida
documentul privitor la achiziiile i vnzrile de portocale, menionat n seciunea
2.2 a capitolului de fa. Structura schemei este urmtoarea:
52
SERVICII WEB
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:portocale.info"
targetNamespace="urn:portocale.info">
<xsd:annotation>
<xsd:documentation xml:lang="ro">
O schem utilizat la validarea
tranzaciilor de portocale
</xsd:documentation>
</xsd:annotation>

<xsd:element name="portocale" type="portocaleType" />
<xsd:complexType name="portocaleType">

<xsd:sequence maxOccurs="unbounded">
<xsd:choice>

<xsd:element name="achizitii"
type="prodType"
minOccurs="1" maxOccurs="unbounded" />

<xsd:element name="vanzari"
type="prodType"
minOccurs="1" maxOccurs="unbounded" />
</xsd:choice>
<xsd:sequence>
</xsd:complexType>

<xsd:complexType name="prodType">
<xsd:sequence>
<xsd:element name="tip" type="xsd:string"
minOccurs="1" maxOccurs="1" />
<xsd:element name="cod" type="xsd:string"

<xsd:element name="obs" type="xsd:string"
<xsd:element name="cantit">
<xsd:complexType>

<xsd:simpleContent>
<xsd:extension base="xsd:unsignedInt">

FAMILIA XML
53
<xsd:attribute name="um"
type="xsd:string"
use="required" />
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>

<xsd:attribute name="id" type="xsd:ID"
use="optional" />
</xsd:complexType>
</xsd:schema>
Reprezentarea grafic a schemei e disponibil n figura de mai jos.
Figura 3. Reprezentarea generat de editorul <oXygen /> a schemei XML
Mai urmeaz s utilizm schema de mai sus pentru a verifica validitatea unei
instane de document XML care trebuie s declare un spaiu de nume cu un URI
desemnnd schema utilizat.
La nivelul unei instane de document vom folosi o construcie de genul:
<portocale xmlns="urn:portocale.info"
xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"urn:portocale.info file:portocale.xsd">

</portocale>
54
SERVICII WEB
Aplicaia <oXygen /> XML Editor amintit mai sus poate fi folosit i ca
validator de documente XML.
n cele de mai jos ilustrm anumite mesaje de eroare afiate de unul dintre
utilitarele puse la dispoziie de procesorul Apache Xerces disponibil n regim open
source n cazul unui document XML invalid, conform schemei descrise anterior:
P:\xerces>DOMPrint.exe -v=always -n -s -f portocale.xml
Error at file "portocale.xml", line 7, column 21
Message: Unknown element 'suplimentar'
Message: In element cod: Can not have element children
within a simple type content
Message: Required attribute 'um' was not provided
Message: Element 'suplimentar' is not valid for content
model: '((tip,cod,obs),cantit)'
Un rezultat aproape similar obinem utiliznd Microsoft Visual Web Developer

pentru editarea i validarea documentelor XML a se urmri figura alturat.
Figura 4. Semnalarea erorilor de validare a unui document XML n cadrul instrumentului

Visual Web Developer
2.7. Procesarea documentelor XML

Modelul DOM
Consoriul Web a propus pentru prelucrarea sofisticat a documentelor XML
i/sau HTML un model obiectual denumit DOM (Document Object Model). Acest
model reprezint o interfa de programare a aplicaiilor destinate s prelucreze
FAMILIA XML
55
documentele HTML i XML, independent de platform i de limbaj, definind

structura logic a documentelor i modalitile de accesare i de modificare a lor.
Structura logic a documentelor este o structur arborescent, conform cu
XML Infoset, documentele fiind modelate utiliznd obiecte, iar modelul nu
furnizeaz doar o vizualizare structurat a documentului, ci i o modalitate de
specificare a comportamentului lui i a obiectelor componente. Fiecare element
al unui document poate fi privit, aadar, ca un obiect cu o identitate i o serie
de funcii proprii.
Recomandrile DOM sunt structurate pe mai multe nivele de specificare a
modelului. Nivelul 0 (pentru HTML) a fost nivelul de funcionalitate a versiunilor
3 ale navigatoarelor Netscape i Internet Explorer. Nivelul 1 este recomandarea
standardizat din anul 1998, iar n 2000 a fost standardizat DOM nivelul 2.
Parial, nivelul 3 al DOM a fost publicat ca recomandare oficial n anul 2004
i este n curs de standardizare complet.
DOM nu este o specificaie binar i nu definete nici o form de inter-operabilitate la nivel binar, n contrast cu alte tehnologii, precum CORBA (Common
Object Request Broker Architecture) ori COM (Common Object Model). DOM reprezint
un model care specific interfee i nu este un set de structuri de date (abstracte).
De asemenea, nu definete semantica detaliat a documentelor HTML sau XML.
Specificaia DOM reprezint documentele ca o ierarhie de obiecte-nod.
Anumite tipuri de noduri pot avea noduri copii (descendeni) de diverse tipuri.
Altele pot fi noduri frunz, lipsite de descendeni. Tipurile fundamentale de
noduri sunt cele din urmtorul tabel:
Tip
Document
DocumentFragment
DocumentType
EntityReference
Descendeni
Element,
ProcessingInstruction,
Comment,
DocumentType
Element,
Comment,
Text,
CDATASection,
EntityReference
Element,
Comment,
Text,
CDATASection,
EntityReference
56
SERVICII WEB
Tip
Element
Attr
ProcessingInstruction
Comment
Text
CDATASection
Notation
Entity
Descendeni
Element,
Text,
Comment,
CDATASection,
EntityReference
Text,
EntityReference
Element,
Comment,
Text,
CDATASection,
EntityReference
Pentru fiecare tip de nod, DOM ofer o interfa care desemneaz constantele,
variabilele i metodele ce vor putea fi folosite de programator ntr-o implementare efectiv a modelului. Exist o serie de interfee fundamentale (e.g.,
Document, DocumentFragment, Node, NodeList sau Attr), plus diverse interfee extinse
pentru a suporta implementri avnd n vedere procesarea documentelor HTML
ori oferind faciliti adiionale.
n continuare, vom descrie succint o serie dintre interfeele puse la
dispoziie.
O interfa important este DocumentFragment care poate reprezenta un obiect-document minimal. Sunt numeroase situaiile n care nu trebuie lucrat cu
ntregul document, ci doar cu diverse fragmente ale sale. Arborele de noduri al
unui fragment de document este un sub-arbore al structurii de noduri a
documentului luat n ntregul lui. n funcie de necesiti, DocumentFragment poate
reprezenta o entitate XML, un element XML sau chiar un grup de elemente.
Interfaa Document reprezint un document XML, desemnnd conceptual
rdcina arborelui de noduri-obiecte ale documentului i oferind accesul la
informaiile coninute de acesta. Din moment ce elementele (marcatorii), nodurile
de tip text, comentariile, instruciunile de procesare nu pot exista n afara
contextului unui document, interfaa Document conine de asemenea metodele
necesare pentru a crea aceste categorii de obiecte.
FAMILIA XML
57
Interfaa Document are ca membri trei atribute:

i. doctype reprezint declaraia tipului de document (DTD) asociat unui
document particular.
ii. implementation specific implementarea sau implementrile disponibile
pentru procesarea documentului.
iii. documentElement (de tip Element) desemneaz nodul-rdcin de accesare a
structurii arborescente a documentului.
Menionm urmtoarele metode importante:
createElement() creeaz un element XML;
createTextNode(), createComment() , createCDATASection() , createProcessingInstruction() vor genera noduri-obiect de tip text, comentariu,
seciune CDATA, respectiv instruciune de procesare;

creeaz un obiect atribut care va fi asociat unui element
specificat;
getElementById() va ntoarce elementul al crui atribut id se potrivete cu
cel furnizat ca argument al acestei metode (n acest mod poate fi selectat
exact un anumit element, tiind c identificatorul asociat trebuie s fie unic);
getElementsByTagName() va returna o list ordonat de noduri NodeList
pentru toate elementele corespunztoare unui tag, ordonarea nodurilor realizndu-se prin parcurgerea n preordine a arborelui;
createAttribute()
Interfaa Node definete un tip primar pentru ntregul model DOM, reprezentnd un anumit nod n cadrul arborelui asociat unui document. Atributele
nodeName , nodeValue i attributes sunt introduse ca mecanisme pentru
furnizarea informaiilor despre noduri fr conversie de tipuri (vizualizare
simplificat, nu una orientat-obiect). Fiecare nod va avea asociat o list
ordonat coninnd descendenii si, plus atribute specificnd nodul printe,
primul i ultimul nod copil, dac exist.
Ca metode prezentnd interes se pot meniona cele care manipuleaz nodurile
copil:
insertBefore() permite inserarea unui nod naintea celui

replaceChild() substituie un nod-copil;
removeChild()elimin un nod-copil specificat;
appendChild()adaug un alt nod-copil;
cloneChild() cloneaz un anumit nod-copil;
hasChildNodes() ntoarce true dac exist noduri-copil;
hasAttributes() ntoarce
DOM nivelul 2);
curent;
true dac nodul are atribute (metod introdus n
58
SERVICII WEB
isSameNode() ntoarce
true dac nodul curent e identic cu un altul specificat

(metod oferit de DOM nivelul 3).
NodeList reprezint o interfa care ofer un tip abstract de dat pentru

coleciile ordonate de noduri, fr a defini sau restriciona cum va fi implementat
efectiv aceast colecie. Fiecare implementator va decide ce tipuri de date
concrete vor fi utilizate. Membrii coleciei se vor accesa prin metoda item()pe
baza unui index ntreg, numerotarea nodurilor ncepnd cu valoarea 0.
Interfaa NamedNodeMap este folosit pentru reprezentarea abstract a coleciilor neordonate de noduri, prelucrate prin intermediul numelui. Interfaa
NamedNodeMap nu deriv din NodeList.
Interfaa Attr modeleaz un atribut din cadrul unui obiect de tip Element.
Tipic, valorile permise ale atributelor sunt definite n schema XML corespunztoare documentului. Un obiect Attr nu se consider c aparine arborelui
de noduri-obiect al documentului. Nodurile de tip Attr sunt considerate proprieti ale elementelor (marcatorilor), putnd fi asociate nodurilor Element
coninute de obiecte de tip DocumentFragment.
Interfaa Element deriv din Node i ofer metode de accesare a obiectelor
Attr, prin nume sau prin valoare: getAttribute(), setAttribute(), removeAttribute(), getAttributeNode(), setAttributeNode(), removeAttributeNode().
Interfaa Text este o interfa reprezentnd coninutul textual (date de tip
iruri de caractere) al unui nod Element sau Attr. Dac ntre tag-urile de nceput
i de sfrit nu exist ali marcatori, atunci textul va fi stocat ntr-un obiect
implementnd interfaa Text.
n prezent exist implementri complete pentru DOM nivelurile 1 i 2 n
majoritatea limbajelor de programare actuale (C/C++, C#, Java, JavaScript,
Perl, Python etc.). Drept exemple notabile de biblioteci i interfee de programare
disponibile n diverse limbaje pot fi enumerate JAXP (Java API for XML Parsing),
JDOM, libxml, MSXML.NET, QDOM, Xerces DOM API i XML::DOM.
O serie de exemple de manipulare prin DOM a documentelor XML, pentru
procesarea rspunsurilor obinute de la serviciile Web invocate sau n contextul
AJAX, sunt furnizate n cadrul capitolului 6.
Procesarea XML prin SAX

Pentru documente de dimensiuni mari, modelul DOM este ineficient, deoarece
nainte de a se realiza prelucrarea, documentul respectiv trebuie ncrcat complet
n memorie. Ca alternativ la implementrile DOM, exist o interfa simpl de
programare destinat manipulrii documentelor XML, ns nu att de complet
precum DOM. Aceast interfa este denumit SAX (Simple API for XML).
FAMILIA XML
59
Majoritatea celor care se ocup de prelucrarea documentelor XML vd

structura unui document n form arborescent, iar modelul DOM ofer din plin
posibilitatea de a manipula informaiile n aceast manier. Din punctul de
vedere al implementatorilor aceast abordare are numeroase deficiene (maniera
de stocare intern a arborelui de obiecte, parcurgerea lui etc.). Unul dintre
beneficiile utilizrii interfeei SAX este c arborele nu mai trebuie construit,
dndu-i-se programatorului o alt cale de analiz a documentului XML. Mai
mult, SAX poate ajuta la convertirea datelor din formatul arborescent DOM n
alt format mai comod, iar pentru procesare nu este necesar a se memora ntreaga
informaie XML, ci numai prile dorite.
Detalii privitoare la SAX i alte maniere de procesare XML sunt oferite de
resursele bibliografice indicate.
Analizoare XML
Desigur, pentru prelucrarea documentelor XML va trebui s recurgem la un
analizor XML deja implementat n limbajul nostru preferat. Analizoarele XML
pot fi de dou tipuri:
analizoare fr validare, care vor procesa un document XML verificnd dac
acesta este bine formatat (adic respect regulile privind sintaxa i modul de
imbricare corect a tag-urilor);
analizoare cu validare, care vor realiza procesarea documentului XML prin
verificarea regulilor formale descrise de un DTD sau o schem ataate
acestuia (aceste analizoare sunt mai complexe).
Unul dintre cele mai cunoscute analizoare fr validare este Expat, disponibil
n regim open source. De asemenea, pot fi utilizate analizoarele cu posibiliti de
validare JAXP (Sun), JDOM, libxml (parte a proiectului GNOME), MSXML
(Microsoft) sau Xerces (Apache). Practic toate mediile de dezvoltare Web actuale
ofer posibiliti de validare a documentelor XML via DTD sau XML Schema
i diverse modaliti de procesare.
Referine
Apparao, V. et al. (eds.), Document Object Model (DOM) Level 1 Specification, W3C Recommendation, Boston, 1998: http://www.w3.org/TR/REC-DOM-Level-1
Biron, P., Malhotra, A. (eds.), XML Schema Part 2: Datatypes (Second Edition), W3C
Recommendation, Boston, 2004: http://www.w3.org/TR/xmlschema-2/
60
SERVICII WEB
Bray, T. et al. (eds.), Extensible Markup Language 1.0 (4 th Edition), W3C Recommendation,
Boston, 2006: http://www.w3.org/TR/xml
Bray, T. et al. (eds.), Extensible Markup Language 1.1 (2nd Edition), W3C Recommendation,
Boston, 2006: http://www.w3.org/TR/xml11
Bray, T. et al. (eds.), Namespaces in XML (2nd Edition), W3C Recommendation, Boston,
2006: http://www.w3.org/TR/REC-xml-names
books/xml/
Buraga, S. et al., Programare Web n bash i Perl, Polirom, Iai, 2002: http://www.infoiasi.ro/
~cgi/
Cowan, J., Tobin, R. (eds.), XML Information Set (Second Edition), W3C Recommendation,
Boston, 2004: http://www.w3.org/TR/xml-infoset
Daum, B., Merten, U., System Architecture with XML, Elsevier Science, 2003
Dick, K., XML: A Managers Guide (2nd Edition), Addison Wesley, 2002
Fallside, D., Walmsley, P., XML Schema Part 0: Primer Second Edition, W3C Recommendation, Boston, 2004: http://www.w3.org/TR/xmlschema-0/
Geroimenko, V., Dictionary of XML Technologies and the Semantic Web, Springer-Verlag,
2004
Harold, E., XML 1.1 Bible (3rd Edition), Wiley Publishing, 2004
Le Hors, A. et al. (eds.), Document Object Model (DOM) Level 2 Core Specification, W3C
Recommendation, Boston, 2000: http://www.w3.org/TR/DOM-Level-2-Core
Le Hors, A. et al. (eds.), Document Object Model (DOM) Level 3 Core Specification, W3C
Recommendation, Boston, 2004: http://www.w3.org/TR/DOM-Level-3-Core
Marini, J., The Document Object Model: Processing Structured Documents, McGraw-Hill, 2002
McLaughlin, B., Java & XML (3rd Edition), OReilly, 2006
* * *, Apache XML: http://xml.apache.org/
* * *, Caf con Lche: http://www.cafeconleche.org/
* * *, libxml: http://xmlsoft.org/
* * *, MSXML: http://msdn.microsoft.com/xml
* * *, Oxygen XML Editor: http://www.oxygenxml.com/
* * *, Suns XML Technologies: http://java.sun.com/xml
* * *, XML Standards Library: http://xmlstds.xemantics.com/
* * *, ZVON: http://www.zvon.org/
Capitolul 3
Descrierea serviciilor Web

Analfabetul viitorului nu va mai fi cel care nu tie
s citeasc; va fi cel care nu tie s neleag.
(Alvin Toffler)
1. Punerea problemei
Aa cum am menionat n primul capitol, modul de acces la un serviciu Web este
specificat printr-un set de documente care conin definiii, toate acestea constituind descrierea serviciului.
Asemenea documente pot fi vzute drept blocuri menite a furniza descrierea
unui serviciu Web, incluznd (a se urmri i figura 1):
definiia unui serviciu = abstract + concret (service definition = abstract +
concrete);
descrierea unui serviciu = definiia serviciului + definiii suplimentare (service
description = service definition + supplementary definitions).
S analizm fiecare dintre termenii de mai sus:
descrierea interfeei unui serviciu Web este independent de implementare i
este referit de termenul abstract. Informaiile despre implementarea i
localizarea serviciului Web constituie pri concrete ale documentului care
descrie serviciul. Termenii abstract i concret au fost introdui cu sensul
de mai sus de ctre Consoriul Web n specificaiile privind arhitectura
serviciilor;
definiia serviciului (service definition) este compus din definiiile interfeei
(abstracte) i definiiile implementrii (concrete);
descrierea unui serviciu (service description) const de obicei doar din definiia
serviciului, ns opional ea mai poate conine informaii suplimentare (de
exemplu, cum este conectat serviciul respectiv de alte servicii).
62
SERVICII WEB
Figura 1. Coninutul descrierii unui serviciu
2. WSDL (Web Service Description Language)

Serviciile Web trebuie s fie definite ntr-o manier consistent, astfel nct s
poat fi uor descoperite i puse n legtur cu alte servicii i aplicaii.
WSDL (Web Service Description Language) desemneaz o specificaie standardizat
de Consoriul Web i este cel mai cunoscut limbaj folosit pentru a descrie un
serviciu Web. Prin aceast descriere se nelege specificarea locaiei i descrierea
operaiilor (metodelor) permise, aceasta fiind ntructva similar modului n care
se face descrierea unei componente (interfee) COM.
Istoric
Specificaia WSDL iniial a luat natere n anul 2000, reprezentnd o fuziune a
dou limbaje de descriere a serviciilor: NASSL (Network Application Service
DESCRIEREA SERVICIILOR WEB
63
Specification Language) propus de IBM i SDL (Service Description Language) provenind

din partea Microsoft.
Versiunea actualizat WSDL 1.1 a fost publicat un an mai trziu i trimis
Consoriului Web spre standardizare. De fapt, formatul WSDL 1.1 a fost larg
mbriat de industrie, fiind practic folosit i n prezent.
WSDL 1.2 nu a depit stadiul de specificaie n lucru, fiind compus din trei
documentaii (partea de baz, mecanismul de specificare a mesajelor i modul de
ataare), ultima actualizare fiind realizat n 2003.
Actualmente, Consoriul Web lucreaz la WSDL versiunea 2.0.
Caracterizare
Conceptual, un document WSDL reprezint un contract ntre o cerere i un
rspuns, similar modului cum o interfa Java reprezint un contract ntre
codul-client i un obiect, instan a unei clase Java. Diferena esenial este c
WSDL poate fi considerat o platform i, de asemenea, un limbaj de marcare,
care este folosit n principal pentru descrierea serviciilor Web accesate via SOAP.
n figura 2, putem observa cum WSDL, prin intermediul unor descrieri
standard, face posibil comunicarea la nivelul de integrare furnizat de serviciile
Web a se consulta i capitolele 6 i 7.
Figura 2. Maniera de integrare a serviciilor Web via WSDL

(documentele WSDL ofer descrierea interfeei de interaciune cu o aplicaie
la nivel de integrare software)
Cea mai potrivit cale de a nelege cum este descris un serviciu Web cu
ajutorul WSDL este de avea o privire de ansamblu asupra modelului su
conceptual i de a studia construciile care formeaz aceast descriere.
64
SERVICII WEB
2.1. Modelul conceptual al WSDL

Dup cum am vzut, descrierea unui serviciu Web poate fi structurat n dou
pri principale. n partea abstract are loc descrierea serviciului Web n termeni
de mesaje trimise i recepionate sub controlul unui sistem de tipuri (n mod curent,
graie unei scheme XML). Modelul schimbului de mesaje definete succesiunea
i cardinalitatea mesajelor. O operaie (operation) asociaz modelul schimbului de
mesaje cu unul sau mai multe mesaje. O interfa (interface) grupeaz aceste
operaii ntr-un mod independent de transport i de metoda de serializare.
n partea concret a descrierii, bindings specific modul de transport i formatul
de serializare pentru interfee. Elementul endpoint face legtura cu o adres, iar
service grupeaz acele endpoints care implementeaz o interfa comun (SEI
Service Endpoint Interface).
Interfaa serviciului
(definiie abstract)
Implementarea serviciului
(definiie concret)
Mesaje (messages)
Operaii (operation)
Interfa (interface)
Legare (binding)
Serviciu (service)
Punct terminal (endpoint)
Figura 3. Modelul conceptual WSDL
Componentele WSDL
Pentru a descrie un serviciu Web, WSDL furnizeaz un set de componente i
proprieti asociate acestora.
Avem mai jos forma general a unui document WSDL:
<definitions targetNamespace="xs:anyURI">
<documentation>?
[<import> | <include>]*
<types>?
[<interface> | <binding> | <service>]*
</definitions>
Am folosit urmtoarele convenii: meta-caracterul ? desemneaz o construcie opional (elementul <documentation> poate, aadar, lipsi), caracterele
[ ] specific o grupare de alternative, numele de elemente fiind delimitate
de | (n cazul nostru, poate aprea fie marcatorul <import>, fie <include>).
Simbolul * specific zero, una, sau mai multe apariii (elementele <interface>,
<binding> ori <service> pot aprea de oricte ori dorim).
65
n cele ce urmeaz vom analiza fiecare element n parte, studiind iniial

componentele prii abstracte i apoi pe ale celei concrete.
Elementul-rdcin al documentului WSDL este definitions, putnd fi vzut ca un
container care conine toate informaiile i atributele asociate unui serviciu Web.
Figura urmtoare arat schema general a elementului <definitions> aa cum este
ea redat de editorul oXygen pe baza schemei XML oficiale a limbajului WSDL 1.1.
Atributul targetNamespace al elementului definitions este obligatoriu, de tipul
anyURI. Spaiul de nume poate defini n mod direct sau indirect semantica
documentului WSDL. Marcatorul definitions poate avea i alte atribute opionale
crora s le corespund diferite spaii de nume folosite n documentul WSDL.
n versiunea 2.0 a limbajului, sub-elementul portType este denumit interface.
S considerm un exemplu concret de utilizare a elementului definition pentru
specificarea unui serviciu de validare a documentelor XML (implementarea
efectiv va fi prezentat n cadrul capitolului 6):
<definitions>

<interface name="XMLValidator">
...
</interface>

<message name="ValidateSoapIn">
...
</message>

<message name="ValidateSoapOut">
...
</message>

<service name="XMLValidator">
...
</service>

<binding name="XMLValidatorSoap">
...
</binding>
<binding name="XMLValidatorSoap12">
...
</binding>
</definitions>
66
SERVICII WEB
Figura 4. Schema elementului definitions
67
Elementul interface include un set de operaii abstracte. Opional, o interfa

poate extinde una sau mai multe interfee. Un exemplu concret de utilizare a
elementului interface este urmtorul:
<definitions>

<operation name="CheckIfExists">
...
</operation>

<operation name="Validate">
...
</operation>
</interface>
</definitions>
Elementul operation const dintr-un grup de mesaje de intrare/ieire legate

ntre ele. Execuia unei operaii implic transmiterea sau schimbul unor astfel de
mesaje ntre serviciul consumator i cel furnizor. Elementul operation al interfeei
are ca atribut obligatoriu name, desemnnd numele operaiei expuse.
Reprezentarea acestor mesaje se face cu ajutorul construciei messages care se
gsete ntotdeauna ca element-copil direct al marcatorului definition. Numele
mesajului este apoi refereniat n operaiile de input/output ale elementelor copil
(vezi exemplul de mai jos).
<definitions>
...
</message>
<input name="msg" message="ValidateSoapIn" />
</operation>
</interface>
</definitions>
Un element message poate conine unul sau mai muli parametri de intrare/
ieire care aparin operaiei. Fiecare element part definete un asemenea parametru. El furnizeaz o pereche nume-valoare mpreun cu un tip de data asociat.
Exemplul urmtor ilustreaz un bloc message avnd un singur marcator part.
<definitions>
<part name="filename" type="xs:string">
68
SERVICII WEB
document.xml
</part>
</message>
</definitions>
La nivelul prii de implementare, un document WSDL poate stabili legturi

concrete cu protocoale cum ar fi SOAP sau HTTP.
ntr-un document WSDL, elementul service const din unul sau mai multe
elemente endpoint, la nivelul crora serviciul Web poate fi accesat. Aceste puncte
terminale includ informaii legate de localizare i protocolul permis.
Alte informaii specifice protocolului se regsesc la nivelul elementului binding.
S considerm mai jos un exemplu de utilizare a elementului service (spaiul de
nume tns este unul temporar):
<definitions>
<service name="XMLValidator">
<endpoint name="XMLValidatorSoap"
binding="tns:XMLValidatorSoap">

</endpoint>
</service>
</definitions>
Atributul name al elementului service este obligatoriu.

Elementul binding stabilete protocolul i d informaii despre formatul
mesajelor operaiilor. Elementul operation din cadrul unui bloc binding seamn cu
omologul su din seciunea interface.
Figura urmtoare ofer forma general a elementului binding.
Figura 5. Elementul binding
69
Pornind de la aceast schem, un exemplu de utilizare a elementului binding

este:
<definitions>
<service>
<binding name="XMLValidatorSoap">
<input>...</input>
<output>...</output>
</operation>
</binding>
</service>
</definitions>
Elementul feature asociat elementului binding definete funcionalitile asociate

schimbului de mesaje (fiabilitate, securitate, corelaie i dirijare). Elementul
property este folosit pentru a controla marcatorul feature. El const dintr-un set de
valori posibile specificate printr-o referin la o schem de descriere. Aceste
valori pot fi partajate ntre elementele feature.
Vom discuta mai departe alte construcii suplimentare pe care le ntlnim n
specificaiile WSDL.
Elementul include ajut la modularizarea descrierii serviciului Web. El permite
ca pri din definiia unor servicii care se refer la acelai spaiu de nume s
poat fi regsite ntr-un alt document WSDL, astfel putnd fi folosite sau
partajate de descrierile serviciilor Web. Atributul location este obligatoriu i rolul
su este de a specifica locaia unor astfel de documente WSDL. Valoarea
spaiului de nume asociat documentului WSDL inclus trebuie s fie referit de
spaiul de nume al elementului definition din documentul WSDL inclus.
Conceptul din spatele elementului import este cumva similar celui privitor la
include, diferena constnd n faptul c documentul WSDL importat poate referi
un alt spaiu de nume. Atributul namespace al marcatorului import este obligatoriu,
n vreme ce atributul location are caracter opional.
Figura 6. Schema elementului import
70
SERVICII WEB
Elementul types definete tipurile de date folosite n comunicare. WSDL nu

este legat exclusiv de un anumit sistem care conine aceste tipuri, dar implicit
folosete specificaiile XML Schema. Dac serviciul utilizeaz doar tipuri simple
(precum iruri de caractere i ntregi), atunci elementul types nu este obligatoriu.
Un exemplu de utilizare a elementului types care stabilete utilizarea tipurilor
de date XML Schema este urmtorul:
<definitions>
<types>
<xsd:schema
elementFormDefault="qualified"
targetNamespace=
"http://www.infoiasi.ro/XMLValidator"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
...
</xsd:schema>
</types>
</definitions>
Un alt element pe care-l regsim n forma general a unui document WSDL

este documentation. Acesta poate fi inclus n orice document WSDL i este folosit
n special pentru a furniza o explicaie textual uor de neles (human-readable).
<definitions>
<documentation>
Acest serviciu ofer operaii de validare XML.
</documentation>
</definitions>
Tipuri de documente WSDL

Sintetiznd cele detaliate mai sus, documentele WSDL pot exprima dou tipuri
de informaii: cele referitoare la interfaa serviciului i cele privitoare la implementarea efectiv a acestuia.
Dup cum am vzut, interfaa unui serviciu este descris de un document
WSDL care conine elementele types, import, message, interface i binding. Interfaa
unui serviciu conine definiia WSDL a acestuia, folosit pentru implementarea
unuia sau a mai multor servicii. Este o definiie abstract a serviciului Web i este
utilizat pentru a descrie un anumit tip (o clas) de serviciu. Un document de
tip interfa poate referi un alt document de tip interfa, folosind elementul
import.
Un document WSDL de implementare a serviciului conine elementele import
i service. Un astfel de document specific o descriere a serviciului care implementeaz
interfaa serviciului. Mcar unul dintre elementele import va face o referin la
71
documentul WSDL de tip interfa. Un document de implementare a serviciului

poate ngloba referine la mai multe documente de tip interfa (aa cum o clas
dintr-un limbaj orientat-obiect precum C++ ori Java poate moteni un numr de
una sau mai multe clase).
Figura 7. Tipurile de documente WSDL
Elementul import dintr-un document WSDL de implementare conine dou

atribute. Primul este namespace, a crui valoare este un URI care se potrivete cu
targetNamespace din documentul de tip interfa. Al doilea atribut este location,
preciznd un URI folosit pentru a referenia documentul WSDL care conine
definiia complet a interfeei serviciului. Atributul binding al elementului port
specific o referin la un element binding particular din documentul de tip
interfa.
Documentul de interfa a serviciului este dezvoltat i publicat de un furnizor
de servicii de interfa (service interface provider). Documentul de tip implementare
este creat i publicat de un furnizor de servicii (service provider). Rolurile acestui
furnizor de servicii de interfa i a furnizorului de servicii sunt separate din
punct de vedere logic, dar pot desemna i aceeai entitate emitoare.
72
SERVICII WEB
2.2. Diferenele dintre specificaiile WSDL 1.1 i WSDL 2.0

De la WSDL 1.2 s-a trecut la WSDL 2.0 i ntlnim n principal urmtoarele
diferene fa de WSDL 1.1:
Adugarea de semantici limbajului de descriere. De asemenea, s-a introdus
atributul obligatoriu targetNamespace pentru elementul definitions.
Schimbarea modului de construire a mesajului: se folosete sistemul de tipuri
de date din XML Schema via elementul types.
Elementul portTypes este redenumit interfaces. Suportul pentru motenirea
interfeei este obinut prin folosirea atributului extends n cadrul elementului
interface.
Elementul port a fost redenumit endpoint.
2.3. Exemple de documente WSDL

n cea mai mare parte, dezvoltatorii de servicii Web nu genereaz manual
descrieri WSDL pentru serviciile lor. Se utilizeaz anumite instrumente care
furnizeaz documente WSDL n mod automat.
De exemplu, platforma Microsoft .NET poate genera automat o descriere
WSDL pentru un serviciu Web. S considerm c avem un serviciu Web (vezi
capitolul 6 pentru detalii) de salutare a utilizatorului. Pentru a accesa descrierea
WSDL generat trebuie s adugm sufixul ?WSDL la URI-ul fiierului .asmx.
Se va obine o descriere WSDL a serviciului implementat n cadrul fiierului
.asmx (n exemplul nostru, considerm serviciul denumit salutari.asmx). Facem
observaia c pentru generarea automat a documentului WSDL de mai jos s-a
utilizat .NET Framework versiunea 1.1, iar versiunea WSDL folosit este 1.1.
<?xml version="1.0" encoding="utf-8" ?>
<definitions
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:hs="urn:Hello"
xmlns:soapenc=
"http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="urn:Hello"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema elementFormDefault="qualified"
targetNamespace="urn:Hello">
<s:element name="sayHello">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="name" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="sayHelloResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"

name="sayHelloResult"
type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="string" nillable="true"

type="s:string" />
</s:schema>
</types>
<message name="sayHelloSoapIn">
<part name="parameters" element="hs:sayHello" />
</message>
<message name="sayHelloSoapOut">
<part name="parameters"
element="hs:sayHelloResponse" />
</message>
<portType name="SalutariSoap">
<operation name="sayHello">
<documentation xml:lang="ro">
Metoda de salut sayHello().
</documentation>
<input message="hs:sayHelloSoapIn" />
<output message="hs:sayHelloSoapOut" />

</operation>
</portType>
<binding name="SalutariSoap" type="hs:SalutariSoap">
<soap:binding
transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
<soap:operation soapAction="urn:Hello/sayHello"
style="document" />
<input>
73
74
SERVICII WEB
<soap:body use="literal" />

</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<service name="Hello">
<documentation>
Un serviciu Web care v salut.
</documentation>
<port name="HelloSoap" binding="hs:HelloSoap">
<soap:address
location="http://localhost/salutari.asmx" />
</port>
</service>
</definitions>
n exemplul de mai sus se pot identifica elemente ca <definition>, <message>,

<portType> (din versiunea WSDL 1.1), <binding> etc.
Reprezentarea grafic a structurilor XML anterioare este dat de figura 8.
Figura 8. Reprezentarea grafic a arborelui de elemente corespunztor unui document WSDL
75
Dup cum se poate observa, elementul definitions specific mai multe spaii de
nume care vor fi utilizate n acest document.
<?xml version="1.0" encoding="utf-8" ?>
<definitions
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:hs="urn:Hello"
xmlns:soapenc=
xmlns:tm=
"http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="urn:Hello"
Folosirea spaiilor de nume este important pentru diferenierea elementelor

i permite documentului s fac referine multiple la specificaii externe, incluznd
specificaii WSDL, SOAP i XML Schema. Atributul targetNamespace este un
atribut XML Schema care permite documentului WSDL s fac referire la el
nsui. Trebuie observat faptul c aceast valoare trebuie specificat n mod unic
(diferit de alte spaii de nume definite).
Se remarc, de asemenea, faptul c elementul definitions declar i un spaiu de
nume implicit: xmlns="http://schemas.xmlsoap.org/wsdl/". Elementelor
care nu au specificat un spaiu de nume (de exemplu, message sau portType) le
corespunde acest spaiu de nume WSDL implicit.
n documentul WSDL sunt definite dou elemente message.
<message name="sayHelloSoapIn">
element="hs:sayHello" />
</message>
<message name="sayHelloSoapOut">
element="hs:sayHelloResponse" />
</message>
Primul reprezint mesajul-cerere, sayHelloSoapIn, iar al doilea desemneaz

mesajul de rspuns, sayHelloSoapOut. Fiecare din aceste mesaje conine un singur
element part. Pentru cerere, part specific parametrii funciei (metodei), iar
pentru rspuns desemneaz valoarea ntoars de aceasta. n exemplul de mai sus,
se poate observa c exist un singur parametru de intrare pentru care
type="s:string". La fel, avem un singur parametru de ieire tot de tip string.
76
SERVICII WEB
Dac exist situaii n care metoda prezint mai multe argumente sau returneaz mai multe valori, atunci se specific mai multe elemente part corespunztoare.
Marcatorul portType definete o singur operaie, numit sayHello, avnd un
singur mesaj de intrare (sayHelloSoapIn) i un unic mesaj de ieire (sayHelloSoapOut).
<portType name="SalutariSoap">
Metoda de salut sayHello().
</documentation>
<input message="hs:sayHelloSoapIn" />
<output message="hs:sayHelloSoapOut" />

</operation>
</portType>
Valoarea atributului message trebuie s fie un nume de element XML calificat

(de forma prefix:nume unde prefix reprezint prefixul spaiului de nume
corespunztor elementului). De exemplu, elementul input include un atribut
message="hs:sayHelloSoapIn" prefixul hs se refer la targetNamespace definit
mai devreme pentru elementul definitions.
2.4. Tipuri de operaii i mesaje

WSDL suport patru tipuri de operaii principale:
One-way serviciul primete un mesaj. Astfel operaia are un singur element
input.
Request-response (cerere-rspuns) serviciul primete un mesaj i trimite un
rspuns. Operaia are un element de input, urmat de un element de output.
Pentru a specifica eventuale erori se poate utiliza elementul opional fault.
Solicit-response (solicitare rspuns) serviciul trimite un mesaj i primete un
rspuns. Operaia are un element de output urmat de un element de input. n
acelai mod se poate utiliza elementul opional fault.
Notification (ntiinare) serviciul trimite un mesaj. Operaia are un singur
element de output.
Aceste operaii sunt prezentate n figura urmtoare. Modelul cerere-rspuns
este cel mai utilizat pentru serviciile SOAP.
77
Figura 9. Tipurile de operaii suportate de WSDL:

a) one-way, b) request-response, c) solicit-response, d) notification
Elementul binding furnizeaz detalii despre modul n care mesajele privitoare

la o operaie vor fi transmise prin reea (de exemplu, prin HTTP POST sau
SOAP). Elementul binding are atributele name i type:
<binding name="SalutariSoap" type="hs:SalutariSoap">
Atributul type face referin la portType definit anterior n document. n cazul

nostru, elementul binding se refer la hs:SalutariSoap. Altfel spus, elementul binding
afirm ceva de genul Voi furniza detalii despre modul cum datele operaiei
sayHello vor fi transportate n Internet.
Un document WSDL include construcii SOAP. Aceasta permite specificarea
de detalii SOAP, cum ar fi un antet SOAP, SOAP encoding style, SOAPAction vezi
capitolul urmtor.
Elementul soap:binding indic faptul c legtura cu mecanismul de transport se
va face prin SOAP. Marcatorul soap:operation desemneaz conectarea unei anumite
operaii la o anumit implementare SOAP. Atributul soapAction declar faptul c
atributul de antet SOAPAction (din cadrul unui mesaj HTTP) este utilizat pentru
78
SERVICII WEB
identificarea serviciului. Elementul soap:body permite specificarea diferitelor detalii

despre mesajele de intrare/ieire.
Marcatorul service desemneaz locaia serviciului. Deoarece este un serviciu
SOAP, n exemplul de mai sus s-a folosit elementul soap:address i s-a utilizat
adresa http://localhost/salutari.asmx.
2.5. Platforme i instrumente de lucru cu documentele WSDL

Vom trece n revist o serie de instrumente de lucru cu WSDL, lsnd la
latitudinea cititorului s decid care este cel mai uor de utilizat i mai util pentru
fiecare situaie n parte. Nu vom mai reveni la platforma .NET i suportul su
pentru generarea documentelor WSDL (discutate mai sus), ns remarcm faptul
c este unul dintre instrumentele cele mai utilizate la ora actual.
Fiind dat un fiier WSDL, se poate crea n mod manual un client SOAP
pentru a invoca serviciul. O alternativ mai bun ar fi o invocare automat a
serviciului prin folosirea unui instrument WSDL de invocare. Figura de mai jos
ilustreaz acest mecanism:
Figura 10. Invocarea automat a unui serviciu Web via un instrument specializat
n continuare vom enumera cele mai cunoscute instrumente cu ajutorul

crora se pot face invocri, validri, generri de documente WSDL: WSIF (Web
Services Invocation Framework), Stylus Studios Web Service Call Composer, XML Spy,
WTP (nsemnnd de fapt platforma Eclipse extins) i SOAEditor.
Unul din cele mai cunoscute instrumente de invocare este WSIF, proiect iniiat
de ctre IBM i donat ulterior iniiativei Apache XML http://xml.apache.org/.
79
WSIF este o interfa de programare a aplicaiilor (API Application Programming

Interface) folosit pentru invocarea serviciilor descrise cu ajutorul WSDL. Utiliznd
WSIF, putem realiza o interaciune cu serviciile Web la un nivel abstract,
neinnd cont de formatul mesajelor sau de protocolul de transport utilizat.
Poate v ntrebai: la ce este util un astfel de instrument? S ne imaginm un
sistem software al unei corporaii, sistem format din mai multe entiti software,
dezvoltate ntr-o perioad de zeci de ani. Trebuie creat o aplicaie care s poat
utiliza toate aceste entiti. WSIF rezolv problema folosind descrierile WSDL i
permind accesul la funcionalitile acestor entiti ntr-o manier independent
de protocol i de locaie. Astfel, indiferent c recurgem la tehnologii ca SOAP
(Simple Object Access Protocol), EJB (Enterprise JavaBeans) sau JMS (Java Messaging
Services), totul se concentreaz asupra unui API dependent de WSDL care permite
accesarea tuturor funcionalitilor. n consecin, integrarea tuturor componentelor se poate realiza la nivel declarativ, prin intermediul documentelor WSDL.
Stylus Studios Web Service Call Composer (pe scurt, Stylus) reprezint un sistem
care simplific dezvoltarea serviciilor Web Java, oferind suport pentru gsirea,
invocarea i testarea oricrui serviciu Web bazat pe Java, dezvoltat ntr-un cadru
de lucru (framework) Java, cum ar fi Apache Axis. Vom da mai jos un exemplu al
modului n care, cu ajutorul aplicaiei Stylus, putem localiza i invoca metodele
unui serviciu Web. Aa cum se poate observa i n figura de mai jos, crem un
proiect de tip Web Service Call.
Figura 11. Crearea unui apel de serviciu Web (Web Service Call)
prin utilizarea instrumentului Stylus
80
SERVICII WEB
Pentru a invoca un serviciu Web, trebuie s putem face o referire la adresa

documentului WSDL propriu. Deoarece e posibil ca nu ntotdeauna s cunoatem
aceast adres, Stylus are inclus un browser UDDI care permite cutarea n
regitrii UDDI (vezi capitolul 5). Pentru a realiza o interogare n regitrii UDDI
(de exemplu, IBM, Microsoft, SAP ori XMethods), se alege unul dintre acetia,
se introduce o interogare (de pild: google) i se pornete cutarea.
Figura 12. Obinerea rezultatelor privitoare la documentele WSDL gsite
Aa cum se observ i n figura 12, Stylus va afia o list cu rezultate. Pentru

exemplificare, vom alege din lista de rezultate documentul WSDL cu URL-ul
http://api.google.com/GoogleSearch.wsdl. n acest moment, avem la dispoziie documentul WSDL dorit i putem vedea ce metode pune la dispoziie serviciul Web
(n acest caz, cel oferit de motorul de cutare Google).
Aa cum se observ mai jos, Stylus afieaz operaiile oferite de serviciul Web,
signatura metodelor, lista parametrilor, precum i un mesaj SOAP necesar pentru
invocarea operaiei selectate. Interfaa Stylus ofer posibilitatea de a modifica
valoarea parametrilor, mesajul SOAP fiind automat actualizat cu noile date introduse.
81
Figura 13. Detalii privitoare la o metod oferit de serviciul Web dorit a fi invocat
Din acest moment suntem gata s realizm invocarea serviciului Web (folosim
butonul Send Request) a se vedea figura 14.
Figura 14. Invocarea serviciului Web oferit de Google
Stylus permite apoi inspectarea, n cadrul ferestrei Preview, a rezultatului ntors

de serverul care gzduiete serviciul Web.
Figura 15. Obinerea rspunsului ntors de serviciul Web invocat
Mai multe detalii despre aceast aplicaie comercial putei gsi la adresa
http://www.stylusstudio.com/.
82
SERVICII WEB
Un alt instrument este XMLSpy care, pe lng alte faciliti oferite, poate fi
folosit pentru invocarea, editarea, vizualizarea i validarea documentelor WSDL.
S considerm un serviciu Web de generare a numerelor prime. Pentru a-l putea
invoca avem nevoie de documentul WSDL asociat, pe care l putem gsi la
adresa http://www50.brinkster.com/vbfacileinpt/np.asmx?wsdl.
XMLSpy permite invocarea rapid a serviciului Web numit Prime Numbers,
implementat n Visual Basic .NET, folosind acest document WSDL.
Figura 16. Crearea unei cereri SOAP de invocare a unui serviciu Web
Se creeaz o cerere SOAP care primete ca parametru URL-ul de mai sus:
Figura 17. Introducerea adresei documentului WSDL folosit

pentru invocarea serviciului Web dorit
Acest serviciu Web ne ofer o singur metod GetPrimeNumbers. Mesajul

SOAP creat de instrumentul XMLSpy este ilustrat n figura 18.
Figura 18. Generarea unei cereri ctre un serviciu Web
83
Trimitem cererea SOAP i rspunsul obinut va fi:
Figura 19. Obinerea rspunsului oferit de serviciul Web invocat
Facem observaia c XMLSpy poate fi gsit i n cadrul mediului Eclipse

(platform universal de dezvoltare software implementat n Java, scopul su
fiind integrarea diferitelor instrumente utile, ntr-o manier indiferent de limbajul
sau platforma folosit). Aceast integrare permite utilizatorilor sistemului Eclipse
s lucreze cu tehnologiile standard XML, utiliznd numeroasele faciliti oferite
n acest caz de XMLSpy.
O alt abordare este cea oferit de <oXygen /> XML Editor, care pune la
dispoziie un instrument de consultare i invocare via SOAP a serviciilor Web.
n captura din figura 20 ilustrm acest mecanism. Se poate observa structura
fiierului WSDL returnat de Google, avnd acces la numele operaiilor implementate. De asemenea, oXygen poate fi folosit n conjuncie cu Eclipse.
Alte exemple notabile sunt Wsdlpull (instrument de inspectare i invocare a
serviciilor Web) i WSDL Verify (program de verificare a corectitudinii documentelor WSDL).
n final, putem concluziona c folosirea documentelor WSDL aduce cteva
avantaje majore:
WSDL face mai facil scrierea i meninerea serviciilor prin furnizarea unei
abordri structurate, necesar definirii interfeei serviciului Web;
specificaia WSDL permite o modalitate mai eficient de a utiliza un serviciu
Web, prin faptul c reduce mrimea codului (i astfel i a potenialelor erori)
pe care aplicaia-client trebuie s-l implementeze;
WSDL permite ca modificrile ulterioare ale interfeei/implementrii serviciului s se realizeze mai uor. Descoperirea dinamic a descrierilor WSDL
conduce la faptul c monitorizarea acestor schimbri va fi automat realizat
n cazul clienilor, recurgnd la WSDL pentru invocarea serviciilor Web
dorite.
84
SERVICII WEB
Figura 20. Pregtirea invocrii unui serviciu Web prin intermediul instrumentului WSDL
SOAP Analyser oferit de oXygen
Referine
Booth, D., Liu, C. (eds.), Web Services Description Language (WSDL) Version 2.0 Part 0:
Primer, W3C Candidate Recommendation, Boston, 2006: http://www.w3.org/TR/
wsdl20-primer
Buraga, S., Tehnologii XML, Polirom, Iai, 2006
Chinnici, R. et al. (eds.), Web Services Description Language (WSDL) Version 2.0 Part 1: Core
Language, W3C Candidate Recommendation, Boston, 2006: http://www.w3.org/
TR/wsdl20
Chinnici, R. et al. (eds.), Web Services Description Language (WSDL) Version 2.0 Part 2:
Adjuncts, W3C Candidate Recommendation, 2006: http://www.w3.org/TR/
wsdl20-adjuncts
Christensen, E. et al., Web Services Description Language (WSDL) 1.1, W3C Note, Boston,
2001: http://www.w3.org/TR/wsdl
Jorgensen, D., Developing .NET Web Services with XML, Syngress Publishing, 2002
Haas, H., Brown, A. (eds.), Web Services Glossary, W3C Working Draft, Boston, 2003:
http://www.w3.org/TR/ws-gloss/
* * *, Altova XMLSpy: http://www.altova.com/
* * *, Apache XML: http://xml.apache.org/
* * *, IBM Developers Site: http://www.ibm.com/developer/
* * *, oXygen XML Editor: http://www.oxygenxml.com/
* * *, Portal dedicat serviciilor Web: http://www.webservices.org/
* * *, Stylus Studio: http://www.stylusstudio.com/
* * *, Wsdlpull: http://freshmeat.net/projects/wsdlpull/
* * *, WSDL Verify: http://apps.gotdotnet.com/xws/wsdlverifier/wsdlverify.asmx
* * *, XML.com: http://xml.com/
85
Capitolul 4
Protocolul SOAP
Totul ar trebui s fie ct mai simplu cu putin,
ns nu mai simplu de att.
(Albert Einstein)
1. Evoluia protocoalelor bazate pe XML

Tehnologia din spatele serviciilor Web este construit pe baza protocoalelor
XML. Acestea guverneaz modul cum are loc comunicarea ntre programele
rulnd la nivel de server i de client i cum sunt reprezentate datele transmise
(parametrii de intrare i rezultatul ntors).
Din punct de vedere istoric, protocoalele de comunicaie bazate pe XML se
mpart n dou generaii: prima se bazeaz doar pe sintaxa XML 1.0, iar a dou
generaie folosete XML Schema i spaiile de nume XML. SOAP se ncadreaz
n aceast a doua generaie.
1.1. Prezentare succint a protocoalelor din prima generaie

S-au fcut numeroase eforturi pentru a crea protocoale bazate pe XML. Dou
dintre ele s-au impus n mod deosebit: WDDX (Web Distributed Data Exchange) i
XML-RPC.
WDDX a fost creat n 1998 de Allaire Corporation (preluat de Macromedia,
devenit n acest moment parte a companiei Adobe). WDDX oferea un mecanism independent de limbaj i platform pentru schimbul de date ntre aplicaii.
Dei WDDX suporta tipuri de date precum iruri de caractere, numere, valori
booleene, tablouri i structuri, nu putea fi folosit pentru reprezentarea oricror
tipuri de date ce pot fi exprimate n XML.
WDDX nu era legat n mod strict de o modalitate de transport, astfel c
aplicaiile puteau interschimba pachete WDDX folosind diverse protocoale
precum HTTP sau SMTP. n trecut, WDDX s-a bucurat de un anume succes,
existnd implementri n majoritatea limbajelor de programare.
88
SERVICII WEB
XML-RPC este un protocol bazat pe paradigma RPC (Remote Procedure Call),

descris n primul capitol al acestui volum. XML-RPC a fost introdus n 1998 de
compania Userland. Tipurile de date suportate sunt similare cu cele din WDDX.
Ca protocol de transport se folosete HTTP.
Un mesaj XML-RPC reprezint de fapt o cerere HTTP prin metoda POST.
Corpul cererii are forma unui document XML. Procedura se execut pe server,
iar rezultatul este ntors, de asemenea, sub form de XML.
Parametrii de intrare ai procedurii invocate pe server pot fi numere, iruri de
caractere etc., sau pot fi structuri ori liste de structuri.
Un exemplu de cerere XML-RPC este urmtorul, n care se dorete invocarea
funciei furnizeazaNumeSortiment(int), care va oferi numele unui sortiment de
portocale pe baza unui index (n acest caz, indexul are valoarea 2):
POST /RPC2 HTTP/1.0
User-Agent: Test/3.2 (WinXP)
Host: tsxmlrpc.ex.ro
Content-Type: text/xml
Content-Length: 181
<?xml version="1.0"?>
<methodCall>
<methodName>furnizeazaNumeSortiment</methodName>
<params>
<param>
<value><int>2</int></value>
</param>
</params>
</methodCall>
Observm c n antetul cererii URI-ul nu este specificat. De exemplu, el ar

putea fi vid (doar un singur /), n cazul n care serverul manipuleaz doar
apeluri XML-RPC.
Oricum, dac serverul opereaz cereri HTTP de diferite tipuri, atunci pe baza
valorii URI mesajele se dirijeaz spre codul responsabil cu cererile XML-RPC.
n exemplul de mai sus, URI-ul este /RPC2, aceasta indicnd serverului dirijarea
cererilor spre aplicaia RPC2, care va trimite rspunsul. Este obligatoriu ca n
antet s fie specificate cmpurile User-Agent i Host.
Valoarea cmpului Content-Type este text/xml, deoarece transmitem un document XML, iar Content-Length reprezint dimensiunea care trebuie corect specificat.
Corpul mesajului este marcat n XML i conine, n acest exemplu, o
singur structur <methodCall>. Elementul <methodCall> trebuie s includ un
PROTOCOLUL SOAP
89
sub-element <methodName>, care indic (sub forma unui ir de caractere) numele

metodei apelate.
Dac procedura invocat la distan necesit parametri, atunci <methodCall>
trebuie s conin i elementul-copil <params>. Acesta va include un anumit
numr de elemente <param>, fiecare avnd o valoare de un anumit tip. n
exemplul anterior, tipul parametrului este int i este furnizat chiar de marcatorul
<int>.
Un exemplu de rspuns pentru cererea de mai sus va avea forma:
HTTP/1.1 200 OK
Connection: close
Content-Length: 158
Date: Mon, 20 Feb 2006 19:33:07 GMT
Server:Test/3.2-WinXP
<methodResponse>
<params>
<param>
<value>
<string>Portocale japoneze</string>
</value>
</param>
</params>
</methodResponse>
Dac nu apar erori, se ntoarce codul de stare 200 OK. Valoarea cmpului de
antet Content-Type este text/xml, deoarece rspunsul este i el un document XML.
Cmpul Content-Length trebuie s fie prezent i s aib o valoare corect.
Corpul mesajului este o structur XML <methodResponse>, care conine un
singur parametru <params> cu un unic element-copil <param>. Acesta, la rndul
lui, include o singur valoare <value>.
Elementul <methodResponse> putea conine, de asemenea, marcatorul <fault>
avnd sub-elementul <value>, ce reprezint un <struct> compus din dou
elemente: primul este <faultCode>, de tip <int>, iar cellalt este numit <faultString>
i este de tip <string>. Elementul <fault> indic apariia unei excepii XML-RPC,
serverul ntorcnd codul acesteia i un mesaj explicativ.
De notat c <methodResponse> poate conine fie <fault>, fie <params>, dar nu
pe ambele simultan.
Pentru cererea anterioar putem avea i urmtoarea variant de rspuns,
indicnd o excepie referitoare la furnizarea unui numr prea mare de parametri
de intrare:
90
SERVICII WEB
HTTP/1.1 200 OK
Connection: close
Content-Length: 426
Date: Mon, 20 Feb 2006 19:33:09 GMT
Server: Test/3.2-WinXP
<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>
Datorit simplitii sale, XML a fost acceptat pe scar larg. Astfel, XML-RPC
poate fi folosit n cadrul programelor Perl, Java, Python, C, C++, PHP i multe alte
limbaje. Implementrile sunt disponibile pentru majoritatea sistemelor de operare.
Un exemplu de aplicaie Web scris n PHP i utiliznd XML-RPC este oferit n
cadrul lucrrii lui Sabin Buraga (coord.), Aplicaii Web la cheie, Polirom, Iai, 2003.
1.2. Dezavantajele protocoalelor din prima generaie

Enumerm n cele ce urmeaz principalele neajunsuri ale primei generaii de
protocoale de transport bazate pe XML :
Lipsa de extensibilitate. Creatorii protocolului trebuie s ajung la o nelegere
nainte ca orice modificri s fie implementate i versiunea protocolului trebuie
s fie revzut, astfel nct s se permit diferitelor instrumente s fac distincia
ntre versiunile vechi i cele noi ale protocolului. De exemplu, atunci cnd n
XML-RPC i WDDX s-a adugat suport pentru datele binare, specificaiile
ambelor protocoale au fost reactualizate i acelai lucru s-a ntmplat cu toate
implementrile existente pentru diferite limbaje i platforme de programare. O
PROTOCOLUL SOAP
91
astfel de necesitate constituie un serios handicap, care a fost depit de protocoalele din a doua generaie prin utilizarea spaiilor de nume XML.
A dou mare problem este legat de tipurile de date. Aceste protocoale
foloseau un singur DTD (Document Type Definition) pentru a descrie reprezentarea
serializat a datelor. n general se utilizau doar cteva tipuri de date simple XML.
Aceast abordare a permis multor instrumente s ofere suport acestor protocoale.
Dificultatea care a aprut ulterior a fost aceea c datele din mesaje erau exprimate
sintactic i nu semantic. Protocoalele din a doua generaie folosesc structurile i
bogatele tipuri de date din XML Schema.
2. SOAP scurt istorie

ncepnd cu anul 1997, corporaia Microsoft a iniiat numeroase cercetri legate
de XML. Scopul era crearea de aplicaii care s comunice pe baza RPC i HTTP.
Companiile DevelopMentor i Userland i-au adus aportul la aceste studii. La
nceputul anului 1998, s-a dezvoltat conceptul de protocol de comunicaii bazate
pe XML, numit SOAP.
n cadrul Microsoft, grupul DCOM (Distributed Common Object Model) nu agrea
aceasta nou direcie i susinea c Microsoft ar trebui s foloseasc poziia
dominant pe care i-o oferea DCOM. Alt grupare din Microsoft era de acord
cu tranziia la SOAP, ns se considera c era nevoie de ceva mai mult dect
XML simplu (ar fi fost de dorit suportul oferit de specificaiile referitoare la
spaiile de nume i schemele XML). Datorit acestor tergiversri, Userland a
fcut public n vara anului 1998 protocolul XML-RPC.
n 1999, Microsoft a creat propria versiune de schem XML (numit XML
Data Reduced) i a adugat faciliti pentru suportarea spaiilor de nume. Astfel,
protocolul SOAP ncepea s capete contur. Era totui un mecanism de transport
XML bazat pe RPC. n aceeai perioad, o echip care lucra la serverul BizTalk
a creat un model care se focaliza mai puin pe RPC i mai mult pe ideea de
transfer de mesaje (messaging).
Pentru a rezolva aceste diferene au fost necesare cteva luni. n septembrie
1999, apare versiunea public SOAP 0.9, dat spre aprobare la IETF (Internet
Engineering Task Force). Dup cteva schimbri, n decembrie 1999 e disponibil
varianta SOAP 1.0.
Pe 8 mai 2000, SOAP versiunea 1.1 a fost prezentat ca document al
Consoriului Web, la care IBM era co-autor al protocolului. Aceast specificaie
se caracteriza printr-o mai mare extensibilitate i a eliminat ngrijorrile conform
crora implicarea Microsoft ar conduce dezvoltatorii la necesitatea utilizrii unor
tehnologii proprietare.
92
SERVICII WEB
n curnd, dup apariia specificaiei SOAP 1.1, IBM a lansat pe pia

implementarea Java SOAP, pe care a cedat-o mai apoi proiectului Apache XML
(http://xml.apache.org/), n scopul unei dezvoltri open source. Ulterior, mai multe
corporaii au nceput s lucreze la implementri ale serviciilor Web folosind SOAP.
Pe 9 iulie 2001, grupul W3C a publicat o nou schi (working draft) pentru
SOAP 1.2, iar la data de 7 iunie 2003, noua versiune SOAP 1.2 a devenit
recomandare standardizat. ncepnd cu varianta 1.2, termenul SOAP nu se
mai consider a fi un acronim.
Ca majoritatea tehnologiilor noi, SOAP schimb regulile dup care sunt
dezvoltate aplicaiile. Din experiena cu alte tehnologii, s-a observat c acelea
care se caracterizeaz prin simplitate sunt cele mai promovate i au ansa s
dureze. Aa cum se va vedea din exemplele viitoare, ntr-o anumit msur,
protocolul SOAP se dovedete a fi simplu de neles i de utilizat.
3. SOAP o vedere de ansamblu

Serviciile Web sunt o instan a modelului arhitecturilor orientate spre servicii
(SOA Service Oriented Architecture), care folosesc SOAP ca mecanism de transport
a mesajelor ntre servicii descrise cu ajutorul unor interfee WSDL. n esen,
avem de-a face cu o arhitectur simpl (vezi figura 1) n care mesajele SOAP
sunt propagate cu ajutorul unui protocol de transport ntre serviciul Web i
posibilii si clieni.
Figura 1. Stiva logic a serviciilor Web
PROTOCOLUL SOAP
93
SOAP reprezint un protocol care permite att schimbul de informaii

structurate ntr-un mediu distribuit i descentralizat, ct i accesarea de servicii,
privite la nivel orientat-obiect, ntr-o manier independent de platform.
Scopul principal al SOAP este facilitarea inter-operabilitii ntre platforme i
limbaje de programare. Pentru realizarea schimbului de informaii ntre sisteme
eterogene, prile care comunic trebuie s cad de acord asupra unei reprezentri
comune. Aa cum se poate observa din exemplul urmtor, un numr de telefon
poate avea mai multe reprezentri echivalente din punct de vedere logic
(semantic).
<nrTelefon>0232 201090</nrTelefon>
<nrTelefon>
<prefix>0232</prefix>
<numar>201090</numar>
</nrTelefon>
<nrTelefon prefix="0232" numar="201090" />
Apare ntrebarea: care este codificarea corect? Rspunsul: este corect cea pe
care aplicaia o ateapt. Cu alte cuvinte, nu este suficient s afirmm c serverul
i clientul folosesc XML pentru a realiza schimbul de informaii. Trebuie s
definim tipul datelor interschimbate, maniera de modelare a datelor n XML,
mecanismul de transmitere a informaiei, folosind la nivel mai sczut
protocoalele Internet existente.
Fr aceste convenii, programele nu pot cunoate modul de decodificare a
datelor pe care le primesc, chiar dac sunt reprezentate cu ajutorul XML. SOAP
este cel care furnizeaz aceste convenii.
Arhitectura general SOAP (despre care vom discuta n detaliu n cadrul
subcapitolelor urmtoare) este surprins n figura 2.
Un mesaj SOAP const dintr-un document XML al crui element-rdcin
are denumirea de plic (envelope). n interiorul mesajului ntlnim dou elemente-copil cunoscute ca antet (header) i corp (body), similar mesajelor transmise prin
pot. Informaiile privind modul de interaciune cu aplicaiile sunt plasate n
interiorul corpului, iar n cadrul antetului se gsesc informaii despre destinatar,
despre entitatea care va avea posibilitatea modificrii mesajului respectiv etc.
n acest capitol, vom prezenta o serie de exemple de mesaje SOAP sub form
de documente XML. Specificaiile SOAP se refer la un mesaj SOAP ca fiind
specificat formal printr-un XML Infoset (vezi capitolul 2), descriere abstract a
coninutului su. Cititorii interesai de astfel de aspecte (de exemplu, asocierea
SOAP cu alte protocoale, caz n care mesajele pot avea reprezentri diferite) le
pot gsi n rapoartele tehnice furnizate de Consoriul Web.
94
SERVICII WEB
Figura 2. Arhitectura SOAP
4. Forma general a unui mesaj SOAP.

Procesarea datelor de ctre serverele SOAP
Mesajele SOAP sunt documente XML care reprezint structura atomic pentru
comunicarea n medii distribuite. Elementul-rdcin al unui mesaj SOAP este
marcatorul Envelope. Deoarece elementul Envelope este n mod unic identificat de
propriul su spaiu de nume, instrumentele de procesare vor putea determina cu
uurin dac un document XML reprezint sau nu un mesaj SOAP.
Putem s imaginm un mesaj SOAP ca pe un plic (SOAP Envelope) care
conine n interior un antet (header) opional i un corp (body) obligatoriu a se
consulta figura 3.
Antetul conine blocuri de informaii relevante pentru modul cum va fi
procesat mesajul. Acesta include date privitoare la locaia emitentului, locaia
destinatarului, anumite informaii de autentificare i autorizare. Corpul stocheaz
mesajul care va fi trimis i procesat. Orice aspect ce poate fi exprimat cu ajutorul
sintaxei XML poate fi memorat n corpul mesajului.
PROTOCOLUL SOAP
95
Figura 3. Structura unui mesaj SOAP
Dup cum se poate observa, exist aici ca i n cazul potei electronice

o separare ntre partea destinat aplicaiilor propriu-zise i partea de transport.
Informaiile destinate aplicaiilor le gsim la nivelul corpului mesajului, pe
cnd elementele legate de transportul mesajului sunt incluse doar n partea de
antet.
Ne putem imagina c o aplicaie SOAP este format din noduri (entiti de
calcul intermediare) care schimb mesaje ntre ele. Mesajele SOAP pot trece
printr-un numr oarecare de noduri intermediare pn ajung la destinatarul
final.
Specificaiile SOAP presupun existena unor noduri intermediare care descriu
comportamentul unui nod n anumite circumstane. Un mesaj, care trece din
nod n nod pentru a ajunge n final la destinatar, poate fi procesat de aceste
noduri intermediare (vezi figura 4). Mai mult, un astfel de nod poate realiza
modificri n cadrul unui mesaj, astfel nct acesta s poat fi procesat de un nod
diferit de cel final.
96
SERVICII WEB
Figura 4. Nodurile SOAP i fluxul mesajelor vehiculate
Aa cum se observ n figura 4, nodurile intermediare primesc mesajul i l

pot altera sau nu. Nodul final se numete i ultimate receiver, adic este nodul
terminal pe care se afl serviciul Web care va folosi acel mesaj.
ntregul model de procesare este implementat de ctre serverele SOAP. Un
server SOAP desemneaz un element al mecanismului care face medierea ntre
traficul SOAP i componentele unei aplicaii. Pentru a putea dezvolta servicii
Web, trebuie s nelegem modul n care un server SOAP implementeaz modelul
SOAP.
Pornind de la premisa c este imposibil s facem o trecere n revist a tuturor
platformelor SOAP existente, vom prezenta arhitectura general a unui server
SOAP. De asemenea, vom enumera principalele caracteristici de care se bucur
cele mai populare implementri actuale a se vedea i capitolul 6 pentru
exemple de aplicaii (servere i clieni) utiliznd SOAP.
O imagine general a unui server SOAP poate fi urmrit n figura 5.
Considerm scenariul n care un mesaj SOAP a ajuns la un server SOAP.
Aa cum se poate observa, elementele stocate n antetul mesajului SOAP (de
exemplu, informaii caracteristice pentru alte servicii Web cum ar fi securitatea,
tranzaciile etc.) sunt procesate de anumii lucrtori (handlers) care au fost
nregistrai pentru serviciul Web n cauz. Astfel de entiti (n fapt, funcii de
tratare a antetelor) sunt considerate n termenii SOAP noduri intermediare.
Rutinele de tratare a antetelor nu fac implicit parte din serverele SOAP, dar
sunt n general utilizate pentru mbuntirea capacitilor serverului. Aceasta
nseamn c serverele SOAP pot fi la rndul lor perfecionate ulterior, pentru a
fi compatibile cu noile tehnologii/servicii Web care apar.
Dac n urma procesrii antetului nu s-a obinut nici o eroare, partea de mesaj
care e destinat aplicaiei (care se gsete n corpul SOAP) ajunge la nivelul de
dispecer (dispatch), care transmite implementrii serviciului datele propriu-zise de
intrare. Dup efectuarea procesrii n interiorul serviciului, are loc trimiterea
rspunsului ctre dispatcher, care-l va propaga ctre entitatea ce a formulat
cererea. Aa cum se poate remarca din figura 5, mesajul de rspuns poate trece
PROTOCOLUL SOAP
97
prin mai multe etape de transformri. Anumii handler-i (noduri intermediare) pot
modifica antetul mesajului. Altfel spus, dac revenim la analogia mesaj SOAP
plic, e uor s ne imaginm cum acesta ajunge s fie adus de un pota la
destinaie, dar nainte de aceasta a trecut prin mai muli intermediari (societi
de transport, oficii potale etc.) care l-ar fi putut modifica. Aceste modificri
sunt realizate doar la exteriorul plicului (de exemplu, diverse tampilri), coninutul lui rmnnd intact pn ajunge la destinatar.
Figura 5. Arhitectura general a unui server SOAP
Eventual, mesajul poate ajunge la un nivel de reea n care este transformat

(marshalled) pentru a suporta un anumit protocol de nivel sczut (de exemplu,
SMTP ori HTTP), ns va fi trimis ntr-un mod corespunztor nodurilor SOAP
pentru a putea fi procesat.
98
SERVICII WEB
5. Modelul SOAP mesaje i codificri

Pornind de la premisa c toate cele discutate pn acum v-au strnit curiozitatea
i v-au familiarizat cu noiunile importante ale protocolului, vom ncerca s
prezentm n detaliu elementele care contribuie la crearea modelului SOAP.
Specificaia SOAP este divizat n trei componente:
prima const ntr-o descriere a utilizrii protocolului SOAP, a structurii
mesajelor i a modelului conform cruia se realizeaz schimbul de mesaje
SOAP;
partea a doua (Messaging Framework) furnizeaz un model n care se specific
regulile de procesare a unui mesaj SOAP, un cadru de lucru extensibil care
permite dezvoltatorilor s utilizeze extensii n cadrul sau n afara mesajului
SOAP, reguli pentru construcia mesajelor SOAP i legturi ntre SOAP i
diferite protocoale (cum ar fi HTTP);
partea a treia (Adjuncts) prezint, printre altele, regulile pentru realizarea unui
apel SOAP RPC i regulile de codificare a mesajelor SOAP.
n seciunile urmtoare, vom prezenta modelul de baz i structura documentelor XML, schemele de codificare, conveniile RPC utilizate i legtura
SOAP cu protocoalele de transport.
5.1. Mesajele SOAP

Dac pn n acest moment ne-am fcut o idee general privitoare la structura
per ansamblu a unui mesaj SOAP, n aceast seciune vom ncepe studierea
concret a unor exemple.
Reamintim c un mesaj SOAP trebuie s includ cel puin un bloc de date n
corpul mesajului i c antetul este opional. De altfel, nu exist o limit superioar
a numrului de blocuri ce pot aprea n antet sau n corp.
Fie urmtorul exemplu de mesaj SOAP, vehiculnd date referitoare la achiziiile i vnzrile unor sortimente de portocale:
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope
xmlns:env="http://www.w3.org/2002/06/soap-envelope">
<env:Header>
<tz:tranzactie-id
xmlns:tz="http://tranzactie.portocale.info"
env:encodingStyle=
PROTOCOLUL SOAP
99
"http://tranzactie.portocale.info/enc"
env:role=
"http://www.w3.org/2002/06/soapenvelope/role/ultimateReceiver"
env:mustUnderstand="true">
tranz10-01
</tz:tranzactie-id>
</env:Header>
<env:Body xmlns:p="http://www.portocale.info/">
<p:portocale>

<p:achizitii env:encodingStyle=
"http://www.w3.org/2002/06/soap-encoding">
<p:tip>Portocale greceti fr coaj</p:tip>
<p:cod>P10-01-GR</p:cod>
<p:cantit p:um="kg">3374</p:cantit>
</p:achizitii>

<p:vanzari>
<p:tip>Portocale japoneze albastre</p:tip>
<p:cod>P10-03-JP</p:cod>
</p:vanzari>
</p:portocale>
</env:Body>
</env:Envelope>
Dac urmrim structura acestui mesaj, observm c respect modelul prezentat n figura 2. Mesajul din exemplul nostru conine un singur bloc-antet, iar
n corp ntlnim dou elemente (care vor fi utilizate de destinatarul final). Att
elementul Header, ct i Body sunt copiii marcatorului Envelope care, de fapt, joac
rolul unui container de date.
5.2. Elementul Envelope

Elementul Envelope este elementul n interiorul cruia se gsete mesajul SOAP.
Acest element are asociat spaiul de nume de la adresa http://www.w3.org/2002/
06/soap-envelope.
n exemplul anterior, identificarea acestui spaiu de nume se face prin prefixul
env.
<env:Envelope

100
SERVICII WEB
<env:Header>
...
</env:Header>

<env:Body xmlns:p="http://www.portocale.info/">
...
</env:Body>
</env:Envelope>
Elementul Envelope poate avea maxim dou elemente-copil: Header i Body. De

asemenea, Envelope trebuie s conin i declaraiile spaiilor de nume care sunt
folosite n interiorul mesajului.
5.3. Elementul Header

Dac acest element apare, atunci el trebuie s fie primul element-copil al
marcatorului SOAP Envelope. Elementul Header poate conine un set de intrri,
fiecare element ncapsulat de Header purtnd numele de bloc antet.
Scopul unui bloc antet este de a comunica informaia relevant n procesarea
mesajului SOAP. Un exemplu ar putea fi un bloc antet care conine elemente de
autentificare sau informaii despre ruta (drumul) mesajului.
Elementul Header are asociat spaiul de nume specificat de adresa http://www.w3.org/
2002/06/soap-envelope.
<env:Envelope
<env:Header>
<tz:tranzactie-id
xmlns:tz="http://tranzactie.portocale.info"
env:encodingStyle=
"http://tranzactie.portocale.info/enc"
env:role=
"http://www.w3.org/2002/06/soapenvelope/role/ultimateReceiver"
tranz10-01
</tz:tranzactie-id>
</env:Header>
...
</env:Envelope>
Fiecare bloc antet trebuie s aib asociat un spaiu de nume calificat (n acord
cu regulile din SOAP Schema). Modul de codificare a datelor se realizeaz prin
intermediul atributului encodingStyle, iar nodul care trebuie s-l proceseze se specific
PROTOCOLUL SOAP
101
prin atributul role. De asemenea, poate conine i atributul mustUnderstand, cu

ajutorul cruia se poate solicita ca un nod SOAP s-l neleag sau nu.
n specificaiile SOAP este clar definit faptul c atributele role i mustUnderstand
pot aprea doar n declaraiile blocurilor antet. De altfel, emitorul unui mesaj
SOAP trebuie s plaseze aceste atribute cu mare grij. Dac ele sunt amplasate
greit, atunci receptorul poate s le ignore. Deoarece aceste atribute sunt
fundamentale pentru procesarea SOAP, le vom detalia n cele ce urmeaz.
Atributul role
Atributul role controleaz nodul SOAP (l vom numi nod-int) care va putea
procesa unul sau mai multe blocuri antet. Atributul role conine un URI care
identific rolul pe care l va juca nodul-int. Atunci cnd un nod primete un
mesaj incluznd blocuri antet, el trebuie s verifice aceste blocuri pentru a
determina dac exist unul pe care-l poate prelucra.
Dei unui atribut role i se poate asocia orice URI, specificaia SOAP a
prevzut trei situaii standard:
http://www.w3.org/2002/06/soap-envelope/role/none n acest caz, nici un nod
SOAP nu ar trebui s ncerce s proceseze respectivul bloc antet, dei alte
blocuri antet pot conine referine la el i la coninutul su;
http://www.w3.org/2002/06/soap-envelope/role/next n aceast circumstan,
fiecare nod trebuie s recunoasc faptul c respectivul bloc antet trebuie
trimis intact urmtorului nod SOAP (din cadrul rutei de transport a mesajului);
http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver n acest caz, blocurile antet ce conin atributul role cu acest URI asociat (sau cele care nu au
atributul role) vor fi procesate doar de ctre destinatarul final.
n exemplul dat mai sus, atributul role are ca valoare URI-ul http://www.w3.org/
2002/06/soap-envelope/role/ultimateReceiver, ceea ce nseamn c destinatarul ultim
este cel care va putea procesa acest antet. Acest ultim nod (pe care se gsete
mcar un serviciu Web), trebuie s fie capabil s proceseze coninutul mesajului
(inclus n elementul Body).
Atributul mustUnderstand
Dac atributul mustUnderstand are valoarea true, atunci nodul care primete mesajul
trebuie s-l poat procesa sau s emit un mesaj de eroare corespunztor n caz
contrar. Blocurile antet care conin mustUnderstand="true" sunt cunoscute
sub numele de blocuri antet obligatorii. Anteturile care nu au specificat atributul
mustUnderstand sunt totui examinate de nodurile-int.
102
SERVICII WEB
n exemplul anterior atributul mustUnderstand are valoarea true, aceasta nsemnnd

c destinatarul final este obligat s proceseze antetul. Altfel, nu poate s
prelucreze corpul mesajului.
n specificaiile SOAP se precizeaz c un emitor SOAP nu trebuie s
genereze un mesaj care s aib atributul mustUnderstand cu valoarea 1 sau 0, ci
true, respectiv, false. Totui, nodurile SOAP care primesc mesajul trebuie s
accepte i mesajele pentru care atributul mustUnderstand are valoarea 0 sau 1.
Atributul encodingStyle
Atributul encodingStyle este folosit pentru a declara modul prin care coninutul
unui bloc antet a fost creat. Aceast informaie permite nodurilor care interacioneaz cu acel mesaj s poat decodifica informaiile pe care le conine.
SOAP permite mai multe scheme de codificare, dar furnizeaz i o schem
proprie.
Deoarece acest atribut este utilizat i n corpul mesajului, vom discuta mai
multe despre el n cadrul seciunii 5.4.
Atributul relay
n SOAP 1.2, pentru blocurile antet este definit i atributul opional relay, cu
valori de tip boolean. Acest atribut specific dac un bloc antet poate fi transmis
mai departe, n cazul n care nodul intermediar care trebuia s-l proceseze nu a
realizat acest lucru. Exist precizat regula conform creia un bloc antet care a
fost deja prelucrat trebuie ters.
Sunt situaii n care proiectantul unui aplicaii ar dori s introduc noi faciliti
n aplicaie cu ajutorul unor blocuri antet. Un astfel de bloc antet va putea fi
procesat de nodurile intermediare care l neleg i va fi ignorat de celelalte. n
mod evident, facilitatea nou aprut nu a fost implementat de toate nodurile
SOAP. Astfel, pentru a evita situaiile n care un nod SOAP nu recunoate acel
bloc antet i genereaz o eroare, se va preciza env:mustUnderstand="false" .
Suplimentar, pentru a mpiedica aplicarea regulii implicite a mecanismului de
procesare, blocul antet va avea asociat i atributul env:relay= "true" (blocul
nu va fi eliminat).
Exemplul urmtor prezint utilizarea atributului relay:
<?xml version="1.0" ?>
<env:Envelope
<env:Header>
<a:firstQuestion
xmlns:a="http://www.intrebare.ro"
env:role="http://www.intrebare.ro/Log"
PROTOCOLUL SOAP
103
...
</a:firstQuestion>
<b:secondQuestion
xmlns:b="http://www.intrebare.ro"
env:role="http://www.w3.org/2003/05/
soap-envelope/role/next"
env:relay="true">
...
</b:secondQuestion>
<c:thirdQuestion
xmlns:c="http://www.intrebare.ro">
...
</c:thirdQuestion>
</env:Header>
<env:Body>...</env:Body>
</env:Envelope>
Observm n exemplul dat c blocul antet b:secondQuestion este int pentru

urmtorul (next) nod din calea de mesaje i are prevzut i atributul relay="true".
Un nod SOAP care primete un asemenea mesaj poate procesa acest bloc antet
n cazul n care l poate nelege, dar realiznd aceasta conform regulilor existente,
el va trebui s tearg acest bloc antet nainte de a retransmite mesajul. Oricum,
dac nodul SOAP ignor acest bloc antet (i poate efectua acest lucru, deoarece
blocul nu trebuie obligatoriu s fie procesat), atunci el va trebui s-l retrimit.
Procesarea blocului antet a:firstQuestion este obligatorie. n acest caz, blocul
trebuie ters nainte ca mesajul s fie retransmis. Exist i cazul de excepie cnd
nodul, procesnd i alte blocuri antet, gsete reguli care impun ca acel bloc s
nu fie eliminat.
Blocul antet c:thirdQuestion nu are prevzut atributul relay, aceast situaie fiind
echivalent cu relay="false". Conform regulilor, acest bloc antet nu este
trimis mai departe dac nu este procesat.
Blocul antet Representation

Blocul antet Representation permite mesajelor SOAP s transporte reprezentri ale
resurselor Web.
Utilizarea unui astfel de bloc se face n cazul n care receptorul are o
capacitate limitat de a obine reprezentri prin alte mijloace, de exemplu din
cauza restriciilor de accesare sau pentru c efortul de calcul ar fi prea mare
(situaie ntlnit, de pild, pentru anumite dispozitive mobile). Acest bloc este,
de asemenea, folositor atunci cnd sunt necesare mai multe referine la aceeai
resurs, dar duplicarea resurselor nu este de dorit.
104
SERVICII WEB
n acelai mesaj SOAP pot exista mai multe apariii ale blocului Representation.
S urmrim urmtorul exemplu:.
<soap:Envelope
xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
xmlns:rep='http://www.w3.org/2004/08/representation'
xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
<soap:Header>
<rep:Representation resource=
'http://www.infoiasi.ro/~adria/foto.jpg'>
<rep:Data xmlmime:contentType=
'image/jpg'>/aWKKapGGyQ=</rep:Data>
</rep:Representation>
</soap:Header>
<soap:Body>
<a:Persoana
xmlns:a='http://www.infoiasi.ro/~adria/mystuff'>
<a:nume>Alboaie Lenua</a:nume>
<a:foto
uri='http://www.infoiasi.ro/~adria/me.jpg' />
</a:Persoana>
</soap:Body>
</soap:Envelope>
Elementul Representation poate avea atributele resource i reinsert, coninnd

obligatoriu marcatorul Data. Valoarea atributului resource identific resursa Web a
crei reprezentare este transportat de elementul Representation. Atributul reinsert
este de tip boolean. Cnd are valoarea true nseamn c nodul intermediar care
proceseaz mesajul trebuie s reinsereze blocul antet. Aceasta nseamn c, n
conjuncie cu atributul relay cu valoarea true, blocul antet Representation trebuie
retrimis. Dac acest atribut nu exist sau valoarea lui este false, atunci se aplic
regulile obinuite de procesare SOAP.
Valoarea elementului Data este o codificare n baza 64 (base64) a reprezentrii
unei resurse Web transportat de elementul Representation.
5.4. Corpul mesajului SOAP. Elementul Body

Elementul Body este un simplu container pentru datele XML destinate aplicaiei.
Dac pentru Header trebuie respectate o serie de reguli, pentru Body nu exist o
form standard a structurii sau o modalitate strict de interpretare. Singura
constrngere este ca destinatarul final (ultimateRecipient) s poat procesa coninutul mesajului.
PROTOCOLUL SOAP
105
Dac privim cu atenie elementele Header i Body observm c, dei sunt

definite ca elemente independente, ele sunt totui interconectate. Relaia dintre
un bloc Body i unul Header este urmtoarea: o intrare Body este din punct de
vedere semantic echivalent cu una Header care nu are specificat un atribut role
i pentru care atributul mustUnderstand prezint valoarea true.
Deja am furnizat exemple de coninuturi stocate de marcatorul Body, astfel
nct putem s ne referim acum la semnalarea excepiilor de comunicare.
Coduri de eroare SOAP

n afar de rolul su de a conine datele destinate prelucrrii de ctre o aplicaie,
Body este folosit i pentru trimiterea (ctre client, uzual) de excepii care pot
aprea n comunicarea de date. Astfel, este utilizat elementul Fault pentru
transportul informaiilor (structurate sau nestructurate) legate de problemele
care pot aprea de exemplu, n momentul procesrii unui mesaj. Acest
mecanism de management al erorilor este prevzut de specificaiile SOAP, de
aceea instrumentele SOAP trebuie s respecte acest standard pentru tratarea
erorilor.
Elementul Fault are acelai spaiu de nume ca Envelope i conine obligatoriu
dou elemente-copil: Code i Reason. De asemenea, poate include opional i
elementele Node, Role i Detail.
Un exemplu de utilizare a elementului Fault l avem n fragmentul de cod de
mai jos. Acest mesaj de eroare este un rspuns la mesajul din exemplul privitor
la tranzaciile de sortimente de portocale (a se revedea seciunea 5.1). Pentru a
nelege ce a cauzat eroarea trebuie s cunoatem semnificaia fiecrui element
prezent n mesaj.
<?xml version="1.0" ?>
<env:Envelope
xmlns:env="http://www.w3.org/2002/06/soap-envelope"
xmlns:p="http://www.portocale.info/">
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Receiver</env:Value>
<env:Subcode>
<env:Value>p:cod_incorect</env:Value>
</env:Subcode>
</env:Code>
<env:Reason lang="en-UK">
The specified product does not exist.
</env:Reason>
106
SERVICII WEB
<env:Detail>
<err:DetaliiEroare xmlns:err=
"http://www.portocale.info/fault">
<err:codAchizitInvalid>
</err:codAchizitInvalid>
</err:DetaliiEroare>
</env:Detail>
</env:Fault>
</env:Body>
</env:Envelope>
Urmrind codul exemplului, remarcm faptul c primul element al lui Fault

este Code, incluznd dou sub-elemente: primul este obligatoriu i se numete
Value, iar al doilea e opional i are denumirea de Subcode.
Elementul Value poate conine orice cod de eroare care se gsete n spaiul
de nume specificat de http://www.w3.org/2002/06/soap-envelope.
n cazul nostru, coninutul marcatorului Value este env:Receiver (vezi exemplul
urmtor) i ne indic faptul c a existat un nod la captul rutei de mesaje (adic
destinatarul final) care a generat eroarea. Astfel, putem ti c aceast eroare nu
a fost generat de un nod intermediar care a procesat antetul mesajului:
<env:Code>
<env:Value>env:Receiver</env:Value>
</env:Code>
Elementul Subcode include elementul Value, care ofer informaii despre erorile
specifice aplicaiei respective (se folosete spaiul de nume definit de dezvoltatorul
acelei aplicaii).
<env:Subcode>
<env:Value>p:cod_incorect</env:Value>
</env:Subcode>
Tabelul urmtor enumr codurile de eroare definite de specificaia SOAP.

Cod de eroare
Descriere
Version Mismatch
Apare cnd se sesizeaz o diferen ntre versiunile

SOAP folosite.
Apare dac blocul antet coninnd atributul
mustUnderstand=true nu a putut fi procesat de
receptor.
MustUnderstand
PROTOCOLUL SOAP
107
Cod de eroare
Descriere
DataEncodingUnknown
Apare atunci cnd coninutul fiecrui bloc antet

sau bloc din corpul mesajului este codificat cu ajutorul unei scheme despre care nodul SOAP
raporteaz c nu o poate nelege.
Apare atunci cnd emitorul trimite un mesaj care
nu are un format corect (de exemplu, un mesaj
care nu conine suficiente date astfel nct destinatarul s-l poat procesa).
Apare atunci cnd entitatea ce recepioneaz mesajul nu-l poate procesa din cauza unor erori ale
aplicaiei. Presupunndu-se c eroarea nu este persistent, mesajul se poate retransmite.
Clasa de erori Server precizeaz c mesajul nu poate
fi prelucrat, nu din motive legate strict de coninutul mesajului, ci mai degrab din cauza unor probleme de procesare. De exemplu, serviciul ar putea
include o conexiune la un ter server care nu rspunde. Mesajul ar putea fi totui procesat cu succes
ntr-un alt moment de timp.
Sender
Receiver
Server
Dei nu-l gsim n exemplul nostru, elementul Subcode determin ca mecanismul de tratare a erorilor n SOAP s fie extensibil. Astfel, Code conine un
sub-element obligatoriu Value i unul opional Subcode, care poate la rndul lui s
includ alte marcaje Subcode.
Elementul Reason asociat lui Code este utilizat pentru a furniza o explicaie n
limbaj natural. n exemplul nostru, avem un mesaj emis n limba englez: The
specified product does not exist (Produsul specificat nu exist). Instrumentele
SOAP folosesc adesea coninutul elementului Reason atunci cnd semnaleaz
erori, astfel nct activitatea de depanare s decurg mai uor.
Elementul opional Node furnizeaz informaia despre nodul din calea de
mesaje care a generat eroarea. Coninutul marcatorului Node va fi URI-ul acelui nod.
n exemplul de mai sus nu exist specificat Node, deoarece entitatea care a generat
eroarea a fost ultimul destinatar i, evident, emitorul cunoate URI-ul su.
Elementul Node este completat de marcatorul opional Role, care furnizeaz
informaii despre ceea ce realiza nodul atunci cnd a euat. Coninutul elementului Role este de obicei un URI identificnd operaia (de obicei, un serviciu
Web) cauzatoare a erorii. Partea responsabil cu rezolvarea erorilor poate
determina ce poriune a aplicaiei a funcionat greit. Putem observa, deci, c
elementele Node i Role sunt utile pentru detectarea cu uurin a erorilor care
pot aprea.
108
SERVICII WEB
S urmrim n exemplul urmtor elementul Detail n forma specific a unei

aplicaii.
<env:Detail>
<err:DetaliiEroare
xmlns:err="http://www.portocale.info/fault">
<err:codAchizitInvalid>
</err:codAchizitInvalid>
</err:DetaliiEroare>
</env:Detail>
Prezena marcatorului Detail furnizeaz informaii despre erorile survenite

atunci cnd destinatarul final a ncercat procesarea corpului mesajului. Este
evident c atunci cnd elementul Detail exist elementele Node i Role nu vor
mai fi specificate. Acelai lucru este valabil i invers.
Coninutul elementului Detail este dependent de specificul fiecrei aplicaii n
parte.
5.5. Maniera de codificare a mesajelor SOAP Encoding

Dei scopul acestei cri nu este de a intra n detalii legate de modelul de date
utilizat de protocolul SOAP sau de alte scheme de serializare, vom prezenta n
seciunile urmtoare cteva concepte care s ajute cititorul s aprofundeze
specificaiile oficiale legate de codificri.
Termeni folosii n procesul de codificare

Pentru o mai bun nelegere a procesului de codificare n maniera SOAP a
datelor transportate, este important clarificarea urmtorilor termeni.
Termenul de valoare (value) este folosit pentru a descrie o anumit dat
codificat cu ajutorul unui element XML. O dat reprezint un ir de caractere.
Valorile dintr-un mesaj SOAP aparin ntotdeauna unui anumit tip de date
(similar variabilelor dintr-un limbaj de programare ca Java ori C).
SOAP face distincie ntre valorile simple (simple value) i valorile compuse
(compound value).
Tipurile simple value nu au elemente componente. Pentru a nelege ce sunt i
cum arat aceste valori simple, s urmrim un paralelism ntre tipurile int, float i
string, aa cum sunt reprezentate ntr-un limbaj de programare (e.g., Java), i
modul de reprezentare al lor n SOAP:
PROTOCOLUL SOAP
109
int cantit = 33;

<cantit xsi:type="xsd:int">33</cantit>
float pi = 3.14159265;
<pi xsi:type="xsd:float">3.14159265</pi>
java.lang.String sortim = "verde";
<sortim xsi:type="xsd:string">verde</sortim>
Se poate remarca faptul c tipurile de date SOAP sunt de fapt cele specificate
de recomandarea XML Schema a Consoriului Web.
Pentru cazul compound value, o valoare e constituit din mai multe elemente
componente ntre care exist o relaie. Elementele componente care formeaz o
astfel de valoare compus pot fi accesate prin diverse metode precum: indicarea
poziiei n secvena de valori (s ne imaginm cum accesm un element pe baza
indexului, atunci cnd folosim un tablou), utiliznd o cheie (ca n cazul tablourilor
asociative hash tables) sau recurgnd la numele elementului respectiv (similar
structurilor din C). Un astfel de mecanism este cunoscut sub numele de accesor
(accessor).
Un exemplu n care se folosesc valori compuse (vom face din nou o paralel
cu anumite tipuri de date din Java) este urmtorul:
int[3] Stoc = {10, 74, 33}; // tablou de numere
<Stoc xsi:type="SOAP-ENC:Array"
SOAP-ENC:arrayType="xsd:int[3]">
<val>10</val>
<val>74</val>
<val>33</val>
</Stoc>
class Produs // o clas cu doi membri-dat
{
public int cantit = 33;
public java.lang.String sortim = "Portocale";
}
Produs produs = new Produs();
<Produs>
<cantit xsi:type="xsd:int">33</cantit>
<sortim xsi:type="xsd:string">Portocale</sortim>
</Produs>
n acest exemplu, sunt folosii accesori ordinali pentru obinerea valorilor din
variabila de tip tablou Stoc.
110
SERVICII WEB
Ct privete obiectul Java produs, pentru a obine elementele lui componente

vom folosi accesori cu nume: cantit i sortim. Vom reveni ulterior la discuia
asupra tipurilor compuse (inclusiv tablouri i structuri).
n SOAP, ca n majoritatea limbajelor de programare, valorile au asociat un
anumit tip de dat. Aa cum se observ i din exemplu, mai nti declarm
instane ale tipurilor i mai apoi le atam o anumit valoare.
n esen, un accesor reprezint un element care conine sau permite accesul
la o valoare. n exemplul urmtor, prenume este un accesor, iar Ory este o valoare:
<prenume>Ory</prenume>
n codul XML de mai jos avem specificat un tip compus reprezentnd o

combinaie de doi accesori (nume i prenume) care sunt copiii unui singur accesor
(identitate).
<identitate>
<nume>Blue</nume>
</identitate>
Prin intermediul atributelor id i href, SOAP definete accesori de tip single-referenced sau multi-referenced. Un accesor simplu-refereniat (single-referenced) nu
posed o identitate, exceptnd cazul n care este element-copil al altui element.
n exemplul urmtor, <adresa> reprezint un accesor de tip single-referenced:
<persoana>
<identitate nume="Blue Ory">
<adresa>
<strada>Portocalelor</strada>
<localit>Iai</localit>
<tara>Romnia</tara>
</adresa>
</identitate>
</persoana>
Conform specificaiilor SOAP, elementelor li se permite s referenieze valorile

coninute n alte elemente. n acest caz, elementul are asociat un atribut (id) care
identific elementul n cadrul cruia se afl data refereniat.
Aceast posibilitate de a referenia valorile altor elemente este important din
mai multe motive. n primul rnd, exist ansa ca dimensiunea mesajului s se
micoreze. S ne imaginm c avem de trimis un mesaj care conine toi membrii
familiei Blue. Documentul XML n cauz ar putea avea o structur precum
urmtoarea:
PROTOCOLUL SOAP
111
<membru>
<nume>Blue</nume>
</membru>
<membru>
<prenume>Grappy</prenume>
<nume>Blue</nume>
</membru>
<membru>
<prenume>Kiwy</prenume>
<nume>Blue</nume>
</membru>
...
Dup cum se poate observa, are loc o duplicare nedorit a datelor.

Referinele ne permit minimizarea repetiiilor, deoarece muli accesori pot
referi un acelai element. Cnd are loc acest lucru, valoarea este de tip
multi-referin (multi-referenced).
Folosind aceast facilitate, noul document XML va avea forma:
<nume-fam id="nume-fam">Blue</nume-fam>
<membru>
<nume href="#nume-fam" />
</membru>
<membru>
<prenume>Grappy</prenume>
</membru>
<membru>
<prenume>Kiwy</prenume>
</membru>
...
Chiar dac n exemplul de fa nu s-a salvat foarte mult spaiu, s ne gndim

la utilitatea acestui mecanism atunci cnd lucrm, de exemplu, cu o multitudine
de elemente compuse.
Variabilele multi-referin sunt utile i atunci cnd se serializeaz un graf sau
o colecie de obiecte, multe dintre acestea avnd referin ctre acelai obiect. n
acest caz, este important s meninem legturile astfel nct s putem reconstrui
obiectul la deserializare.
Aceast abordare poate fi folosit, de asemenea, pentru a permite unui
accesor s referenieze informaii externe resurselor, care nu fac parte din
112
SERVICII WEB
elementul Envelope (date binare, de exemplu). n exemplul urmtor sunt referite

informaii coninute n interiorul unui document XML extern:
<identitate nume='Blue Grappy'>
<adresa
href='http://www.portocale.info/inf.xml#BlueGrappy'
/>
</identitate>
Tipuri de date
Dup cum probabil deja cititorii avizai au remarcat, tipurile de date suportate de
codificarea SOAP sunt definite n specificaiile XML Schema: Datatypes (a se
revedea capitolul 2).
Pot fi folosite tipurile elementare ca int, float, string, enumerri, iruri de octei
etc., plus tipurile derivate din acestea.
Figura 6. Fragment din reprezentarea grafic a schemei privitoare

la codificare (SOAP Encoding)
Vom face mai jos o trecere rapid n revist a acestor tipuri, lsnd la
latitudinea cititorului aprofundarea amnuntelor.
String
Tipul de date string este definit de recomandarea XML Schema. De remarcat c
acest tip string nu este identic cu tipul string ntlnit n alte limbaje de programare.
PROTOCOLUL SOAP
113
n mod particular, interzice apariia unei serii de caractere pe care acele limbaje
le permit (sunt caracterele rezervate din XML, precum <, > ori &). Un
string poate fi codificat ca single-referenced sau multiple-referenced.
n exemplul de mai jos, Portocale cu blan reprezint o valoare elementar.
<string>Portocale cu blan</string>
Enumerare
Specificaia XML Schema: Datatypes definete un mecanism numit enumerare
(enumeration). Modelul SOAP l adopt n mod direct. Limbajele de programare
definesc tipul enumerare ntr-un mod diferit. n cazul SOAP, enumeration luat
drept concept indic un set distinct de nume. O enumerare particular
reprezint o list de valori distincte, apropiate, bazate pe acelai tip. De exemplu,
(1, 3, 5) este o enumerare posibil bazat pe tipul integer. Sunt suportate
enumerrile pentru toate tipurile simple, exceptnd tipul boolean.
Fie urmtoarea schem reprezentarea grafic a acesteia este dat n figura 7:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="lotPortocale" type="xs:int" />
<xs:element name="greutate" type="xs:float" />
<xs:element name="culoare">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Oranj" />
<xs:enumeration value="Galben" />
<xs:enumeration value="Albastru" />
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:schema>
Figura 7. Reprezentarea grafic a schemei XML specificnd o enumerare de elemente
114
SERVICII WEB
O posibil instan care se conformeaz schemei XML anterioare poate avea

forma:
<lotPortocale>12</lotPortocale>
<greutate>3374.01</greutate>
<culoare>Albastru</culoare>
ir de octei
Dei n multe limbaje de programare irurile de caractere (string) sunt privite ca
fiind iruri de octei, n SOAP lucrurile stau diferit. Un string este reprezentat cu
ajutorului tipului de dat string. Astfel, dac avei la dispoziie o colecie de octei
care nu reprezint un string (de exemplu, coninutul binar al unei imagini ori al
unui fiier executabil), atunci aceti octei trebuie transformai cu algoritmul de
codificare base64 descris n specificaia XML Schema.
Un exemplu de codificare base64 a unui ir de octei este urmtorul:
<imagine xsi:type="SOAP-ENC:base64">
hsgajTYUTUgsjaguuwq1jgds33ds
</imagine>
Un ir de octei poate fi codificat ca o valoare de tip single-referenced sau

multi-referenced. Regulile de codificare pentru iruri de octei sunt similare cu cele
pentru string.
n particular, un element ir de octei poate avea un atribut de tip id.
Elementele accesor suplimentare pot avea asociat atributul href.
Folosirea tipurilor compuse
SOAP definete tipuri corespunztoare a dou modele ntlnite adesea n
limbajele de programare.
Primul este structura. Un struct este o valoare compus n care numele
accesorului permite diferenierea valorilor membrilor i nici un accesor nu are
acelai nume cu un altul (se asigur unicitatea numelor).
Al doilea procedeu recurge la un tablou; un array permite memorarea unei
valori compuse n care indexul (numrul) poziiei difereniaz valorile membrilor
si.
Un exemplu n care se folosesc structuri este urmtorul, considernd fragmentul de schem XML:
<xs:element xmlns:xs='http://www.w3.org/2001/XMLSchema'
name="Carte">
<xs:complexType>
<xs:sequence>
<xs:element name="autor" type="xs:string" />
PROTOCOLUL SOAP
115
<xs:element name="titlu" type="xs:string" />

<xs:element name="pag" type="xs:integer" />
</xs:sequence>
</xs:complexType>
</xs:element>
Reprezentarea grafic este ilustrat de figura 8.
Figura 8. Reprezentarea grafic a schemei XML specificnd o structur
O structur ce se conformeaz schemei anterioare poate fi urmtoarea:

<Carte xmlns="urn:infoiasi.ro">
<autor>Sabin Buraga</autor>
<titlu>Proiectarea siturilor Web</titlu>
<pag>346</pag>
</Carte>
n cazul tablourilor exemplificm cu ajutorul schemei de mai jos, care folosete

n mod explicit maniera de codificare SOAP:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:enc="http://www.w3.org/2001/06/soap-encoding">
<xs:import
namespace="http://www.w3.org/2001/06/soap-encoding"
/>
<xs:element name="numereleFavorite"
type="enc:Array" />
</xs:schema>
Un exemplu de tablou conform schemei de mai sus este:

<numereleFavorite
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:enc="http://www.w3.org/2001/06/soap-encoding"
enc:itemType="xs:int" enc:arraySize="2">
<number>29</number>
<number>10</number>
</numereleFavorite>
116
SERVICII WEB
5.6. Reguli de serializare

Elementele XML ntr-un mesaj SOAP sunt fie independente, fie imbricate. Din
nsi natura XML, majoritatea elementelor sunt imbricate ca sub-elemente ale
altora. Marcajele independente nu sunt sub-elemente ale nici unui element, iar n
urma serializrii ele se gsesc pe primul nivel al arborelui DOM asociat.
Toate valorile ntr-un mesaj SOAP sunt codificate i incluse n cadrul unui
element. Aceasta nu nseamn c orice element XML conine o valoare. De
exemplu, tipurile de date compuse precum structurile sau tablourile includ
sub-elemente coninnd valori.
Modelul de date SOAP

Atributul encodingStyle apare att n blocurile antet, ct i n cadrul elementului
Body al unui mesaj SOAP. Acest atribut impune ca mesajul s aib o anumit
form care se supune regulilor unei scheme XML ce este cunoscut att de
emitor, ct i de receptor.
Din anumite motive, poate exista i riscul ca emitorul i receptorul s nu
aib acces la aceeai schem. Pentru evitarea problemelor de acest gen, specificaiile SOAP prevd existena unei scheme i a unor reguli de codificare
proprii. Acestea sunt cunoscute sub denumirea de SOAP Encoding i spaiul de
nume corespunztor se precizeaz prin construcia:
env:encodingStyle=
"http://www.w3.org/2003/05/soap-encoding"
Regulile pentru codificarea datelor aplicaiei n mesaje SOAP se regsesc n

recomandarea SOAP sub denumirea de model de date (SOAP Data Model). n
aceast parte a specificaiei se arat cum sunt reduse structurile de date la un graf
etichetat.
Mecanismul general este prezentat n figura 9.
Exist dou aspecte ale codificrii. Primul const n transformarea structurilor
de date ntr-o form convenabil de exprimare n XML, cu ajutorul regulilor
specificate n modelul de date SOAP. Un alt aspect presupune verificarea datelor
existente n documentul XML, astfel nct s respecte regulile din schema SOAP.
n mod obinuit, instrumentele SOAP vor suporta serializarea i deserializarea
grafurilor de obiecte folosind acest model, cu minim de efort din partea
programatorului.
PROTOCOLUL SOAP
117
Figura 9. Mecanismul de codificare oferit de SOAP
Utilizarea altor codificri SOAP

Multe dintre aplicaiile existente au fost create astfel nct s poat folosi XML.
Dac se dorete utilizarea protocolului SOAP n cadrul acestor aplicaii, ar trebui
s se recurg la schemele de modelare deja existente.
Aceasta se poate realiza prin intermediul atributului encodingStyle. Deci, n loc
s se codifice corpul sau antetul unui mesaj folosindu-se SOAP Data Model, se
vor putea utiliza regulile din schemele de validare specifice fiecrei aplicaii.
Evident, trebuie s ne asigurm c entitatea care dorete serviciile pe care le
oferim nelege modul nostru de codificare.
Un asemenea stil de codificare adaug un plus de for protocolului SOAP.
Cu excepia faptului c acest mod de codificare favorizeaz reutilizarea schemelor
deja existente i, mai mult, se are de-a face cu schimburi de mesaje i nu cu
apeluri de proceduri la distan (RPC), se ncurajeaz proiectarea de servicii Web
care permit o granularitate mult mai mare a interaciunilor. n esen, se face
trecerea de la modelul RPC care ncurajeaz un model de tip fine-grain (un
client trimite o serie de date, apoi primete alte date i comunicarea continu
118
SERVICII WEB
pn cnd clientul este satisfcut) la un model coarser-grained (clientul transmite

toate datele necesare, astfel nct receptorul, dup ce realizeaz operaiile
preconizate, va trimite dup un anumit timp rspunsul complet).
Pentru a nelege mai bine aceast trecere de la fine-grained la coarser-grained, s
ne imaginm diferena dintre o discuie la telefon i trimiterea unui fax. n
primul caz, purtm un dialog, n care partenerii joac un anumit rol, schimbnd
pe o anumit perioad de timp tot felul de informaii. n al doilea caz ns,
cineva care dorete s rezolve o problem trimite un fax prin intermediul cruia
transmite toate informaiile de care cealalt parte are nevoie.
Am fcut mai sus precizarea c, folosind propriile noastre scheme de
codificare, trebuie s scriem i propriul cod cu ajutorul cruia s se poat realiza
managementul mesajelor codificate n acest mod. Dac un anumit nod folosete
SOAP RPC (unde codificarea este dat de modelul de date SOAP) i dorim s
comunicm cu acel nod, atunci trebuie s efectum o adaptare a instrumentelor
noastre n acest sens.
Figura 10. Procesarea datelor folosind mai multe scheme
Dup cum se remarc n figura 10, handler-ul aflat pe serverul SOAP este cel
care ofer posibilitatea de nelegere a mesajelor care sunt codificate cu o alt
schem, diferit de cea implicit, pus la dispoziie de protocolul SOAP.
PROTOCOLUL SOAP
119
6. Maniera de transport al mesajelor SOAP

Aa cum precizam la nceputul capitolului de fa, n cadrul stivei tehnologiilor
care stau la baza serviciilor Web, SOAP se regsete la un nivel superior
nivelurilor de reea i transport ale Internetului. Pentru aplicaiile folosind
SOAP, nu conteaz ce protocol de transport este utilizat la realizarea schimbului
de mesaje. Acest aspect confer protocolului SOAP o flexibilitate sporit.
n cadrul specificaiile SOAP ntlnim expresia SOAP Binding, care precizeaz
modul prin care mesajele SOAP pot fi transmise de la un nod la altul, folosind
la baz un anumit protocol (HTTP, SMTP etc.).
Un mesaj SOAP e definit respectnd regulile XML Infoset. Pentru transportul
unui astfel de document, se recurge la un protocol care s permit forma serializat
a documentului i care s faciliteze transportul ntre nodurile din ruta (calea) de
mesaje fr pierdere de informaii se asigur fiabilitatea transmisiei de date.
n majoritatea situaiilor se pot utiliza facilitile native ale protocolului de
baz sau, dup caz, se pot introduce anumite blocuri antet care s ofere
funcionalitile de care este nevoie.
6.1. Relaia dintre SOAP i HTTP

Legtura SOAP-HTTP ofer avantajul de a folosi caracteristicile protocolului
SOAP mpreun cu bogatele trsturi oferite de HTTP. Transportnd mesajele
SOAP via HTTP nu nseamn c protocolul SOAP suprascrie semantica existent
a HTTP-ului, ci, mai degrab, faptul c semantica SOAP se integreaz n mod
natural n cea a protocolului HTTP.
SOAP, n mod firesc, urmeaz modelul HTTP cerere/rspuns, cererea SOAP
ncapsulndu-i parametrii n cererea HTTP, iar furnizarea rspunsului SOAP se
realizeaz printr-un rspuns HTTP.
Figura 11. ncapsularea mesajelor SOAP n cadrul mesajelor HTTP
120
SERVICII WEB
De observat c intermediarii SOAP nu sunt aceeai cu intermediarii HTTP.

Astfel, un intermediar HTTP adresat cu un cmp din antetul unui mesaj HTTP
nu poate controla i prelucra elementul de coninut al mesajului SOAP transportat
n cererea HTTP.
Exist dou modaliti de schimb al mesajelor SOAP folosind HTTP, denumite i abloane de interschimb al mesajelor MEP (Message Exchange Pattern):
utiliznd metoda POST pentru transportul mesajelor SOAP n corpul cererii
HTTP, respectiv n mesajul de rspuns (acesta este modelul de schimb al
mesajelor SOAP de tip cerere-rspuns SOAP Request-Response Message Exchange
Pattern);
utiliznd metoda GET pentru a ntoarce mesajul SOAP n corpul mesajului
de rspuns HTTP (acesta este modelul de schimb al mesajelor SOAP de tip
rspuns SOAP Response Message Exchange Pattern).
Ar putea aprea ntrebarea: care metod ar trebui folosit la un moment dat?
Conform modelului arhitectural al spaiului Web, metoda GET poate fi folosit
atunci cnd scopul schimbului de mesaje este de obinere a unei informaii, iar
resursa cu care s-a interacionat a rmas neschimbat. Astfel de interaciuni sunt
cunoscute n specificaiile HTTP ca fiind sigure (safe) i idempotente. Metoda
POST poate fi folosit n toate cazurile.
Relaia SOAP HTTP GET

Utilizarea metodei GET semnific faptul c rspunsul la cererea GET a unui
nod SOAP este un mesaj SOAP ncorporat n rspunsul HTTP.
S urmrim exemplul urmtor n care avem o cerere GET (dup cum se
observ, parametrii de intrare transmii serviciului Web sunt inclui n URL, ca
ir de interogare query string prefixat de ?):
GET /Informatii?tip=3307 HTTP/1.1
Accept: application/soap+xml
Facem observaia c n acest caz corpul mesajului e vid (empty body).

Cmpul de antet Accept este folosit pentru a indica formatul preferat corespunztor cererii realizate. n cazul nostru, este tipul MIME application/soap+xml,
datele fiind procesate de aplicaia client n loc de tipul text/html folosit pentru
redarea coninutul n cadrul navigatorului (deci datele n loc s fie destinate
consumului uman vor fi utilizate pentru o anumit procesare de ctre o
aplicaie la nivelul mainii-client).
PROTOCOLUL SOAP
121
Rspunsul cererii GET de mai sus va putea fi urmtorul:

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: NNNN
<?xml version='1.0' ?>
<env:Envelope
<env:Header>
...
</env:Header>
<env:Body>

</env:Body>
</env:Envelope>
Relaia SOAP HTTP POST

Dup cum am precizat anterior, POST este disponibil pentru toate aplicaiile,
indiferent dac se scufund date XML n mesajele SOAP sau se utilizeaz
stilul SOAP RPC.
Vom considera mai jos un exemplu n care o cerere SOAP, numit GetOrangePrice,
este trimis serverului. Cererea are un parametru cu numele OrangeType, iar rspunsul
va ntoarce un parametru Price. Spaiul de nume propriu aplicaiei (n fapt, al
serviciului Web) ce va fi invocate pe server este http://www.portocale.info/. Dup cum
se poate deduce, dorim s obinem preul unui anumit sortiment de portocale.
Cererea SOAP va avea structura:
POST /Inf HTTP/1.1
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle=
<soap:Body xmlns:p="http://www.portocale.info/">
<p:GetOrangePrice>
<p:OrangeType>Portocale greceti
fr coaj</p:OrangeType>
</p:GetOrangePrice>
</soap:Body>
</soap:Envelope>
122
SERVICII WEB
Rspunsul SOAP, ncapsulat ntr-un mesaj HTTP, este de forma:

HTTP/1.1 200 OK
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle=
<soap:Body xmlns:p="http://www.portocale.info/">
<p:GetOrangePriceResponse>
<p:Price>33</p:Price>
</p:GetOrangePriceResponse>
</soap:Body>
</soap:Envelope>
n cazul n care apare o eroare la procesarea cererii, se va returna un mesaj

SOAP Fault de genul:
HTTP/1.1 500 Internal Server Error
<env:Envelope
<env:Body>
<env:Fault>
...
</env:Fault>
</env:Body>
</env:Envelope>
6.2. Relaia dintre SOAP i transportul de mesaje

de pot electronic (e-mail)
Mesajele SOAP pot fi trimise ca parte text a corpului unui mesaj de e-mail sau
drept fiier ataat (attachment) acestui mesaj.
Facem nc de la nceput observaia c exemplele oferite mai jos nu reprezint
o manier standard, ci doar o modalitate de transport al mesajelor SOAP.
S urmrim urmtoarea cerere SOAP transportat cu ajutorul protocolului
SMTP (Simple Mail Transfer Protocol):
PROTOCOLUL SOAP
123
From: admin@axiologic.ro
To: admin@portocale.info
Subject: Contract
Date: Fri, 29 Dec 2006 18:33:00 EST
Message-Id: <M56721-9MGHGJS5757@axiologic.ro>
Content-Type: application/soap+xml
<env:Envelope
<env:Header>
<p:contract
xmlns:p="http://www.portocale.info/contracts"
env:role=
"http://www.w3.org/2003/05/soap-envelope/role/next"
<p:reference>
uuid:A292310-S238787-S398298
</reference>
<p:dateAndTime>
2006-12-29T18:33:00.000-05:00
</p:dateAndTime>
</p:contract>
...
</env:Header>
<env:Body>
...
</env:Body>
</env:Envelope>
Vom presupune c nodul care recepioneaz un astfel de mesaj are abilitatea

de a procesa mesajele SOAP. n plus, i nodul care a emis cererea trebuie s aib
capacitatea de a putea prelucra, de exemplu, un rspuns SOAP, n cazul apariiei
unei erori.
Rspunsul pentru cererea anterioar ar putea fi de forma:
From: admin@portocale.info
To: admin@axiologic.ro
Subject: ContractAx
Date: Fri, 29 Dec 2006 18:45:07 EST
Message-Id: <CPAX6786382A@portocale.info>
In-replyto: <M56721-9MGHGJS5757@axiologic.ro>
Content-Type: application/soap+xml
<env:Envelope
124
SERVICII WEB
<env:Header>
<p:contract
xmlns:p="http://www.portocale.info/contracts"
env:role=
"http://www.w3.org/2003/05/soap-envelope/role/next"
<p:reference>
uuid:A292310-S238787-S398298
</p:reference>
<p:dateAndTime>
2006-12-29T18:45:07.000-05:00
</p:dateAndTime>
</p:contract>
...
</env:Header>
<env:Body>
...
</env:Body>
</env:Envelope>
n acest exemplu, Message-ID-ul corespunztor mesajului original este

transportat n In-replyto, care interconecteaz mesajele de e-mail la nivelul
SMTP. Nu se furnizeaz ns o corelaie specific SOAP ntre cerere i
rspunsul aferent. n exemplificarea de fa, aceasta se bazeaz pe existena
blocului antet contract. n general, aceste corelaii sunt dependente de fiecare
aplicaie n parte.
Mai multe discuii legate de legtura SOAP-Email putei gsi la adresa
http://www.w3.org/TR/soap12-email.
7. Apelul de proceduri la distan via SOAP RPC

Datorit faptului c specificaiile SOAP furnizeaz suport pentru RPC, muli
programatori au constatat uurina cu care se pot dezvolta servicii Web bazate
pe SOAP RPC. Chiar dac SOAP RPC nu este paradigma cea mai dominant
pentru SOAP, este uor de obinut rezultate folosind-o, deoarece majoritatea
instrumentelor suport bine-cunoscutul model RPC.
Avem n figura de mai jos arhitectura general SOAP-RPC:
PROTOCOLUL SOAP
125
Figura 12. Mecanismul de transmisie i invocare SOAP RPC
Conform specificaiilor SOAP, atunci cnd dorim s realizm o cerere folosind

SOAP RPC trebuie s cunoatem urmtoarele:
adresa nodului SOAP int;
numele metodei (procedurii) dorite a fi invocate;
argumentele (i valorile acestora) care vor fi transmise metodei mpreun cu
orice parametri de ieire sau valori de retur;
modalitatea clar de separare a argumentelor folosite pentru identificarea
resursei Web de cele utilizate de ctre nodul-int care face apelul metodei.
Opional, putem avea date care pot fi transportate n blocurile antet ale
mesajului SOAP.
Unul din principalele scopuri ale protocolului SOAP este cel de a ncapsula
i interschimba apelurile RPC folosind extensibilitatea i flexibilitatea limbajului
XML.
SOAP RPC implic dou modaliti de interschimb al mesajelor: SOAP
Response MEP i SOAP Request-Response MEP, despre care am discutat n cadrul
seciunii 6.1 a prezentului capitol.
126
SERVICII WEB
S urmrim n cele de mai jos un exemplu de utilizare a SOAP-RPC. Figura

13 prezint o interaciune simpl ntre un serviciu Web care ofer posibilitatea
de deschidere a unui cont bancar i un client (n cazul nostru, compania
Axiologic Research) care intenioneaz s foloseasc acest serviciu. Serviciul
Web pune la dispoziie o operaie (metod) numit deschideCont(), fiind expus
via un server SOAP. Maniera de acces la acest serviciu Web se realizeaz prin
SOAP RPC (protocolul SOAP nu furnizeaz nici o modalitate de descriere a
interfeelor, dar aa cum s-a vzut n capitolul 3 acest aspect e suplinit de
limbajul WSDL).
// Implementarea clientului
// Implementarea serviciului
Banca b = new Banca();
class Banca {
String cont = b.deschideCont
public String deschideCont
(tip, denumire, sitWeb);
(tip, denumire, sitWeb) {

// operaii pt. crearea
// unui cont bancar
return nrCont;
}}
Figura 13. Interaciunea cu un serviciu Web folosind SOAP RPC
Clientul interacioneaz cu serviciul printr-o clas ciot (numit stub sau proxy)
purtnd numele de Banca, generat uzual n mod automat de ctre un instrument
(putei scrie i manual propriul dumneavoastr stub). Cu ajutorul acestei clase se
faciliteaz mpachetarea i despachetarea datelor aplicaiei n/din mesaje SOAP
RPC.
Liniile de mai jos semnific o cerere SOAP RPC de la un client ctre un
serviciu Web:
<env:Envelope
<env:Body>
<b:deschideCont env:encodingStyle=
PROTOCOLUL SOAP
127
xmlns:b="http://banca.ex.ro/cont"
xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance">
<b:tip xsi:type="xs:string">Firma</b:tip>
<b:denumire xsi:type="xs:string">
Axiologic Research S.R.L.
</b:denumire>
<b:sitWeb xsi:type="xs:string">
http://www.axiologic.ro
</b:sitWeb>
</b:deschideCont>
</env:Body>
</env:Envelope>
Dup cum se poate remarca, nu este nimic surprinztor ntr-un mesaj SOAP
RPC. Respectnd specificaiile, coninutul este inclus ntr-un element Body.
Facem observaia c n exemplul nostru nu avem blocuri antet, care nu ne sunt
utile n acest caz, dar SOAP RPC nu exclude astfel de elemente.
Revenind la exemplu, vedem c numele elementului deschideCont e identic cu
numele metodei care va fi apelat de serviciul Web. Coninutul marcatorului
b:deschideCont va corespunde parametrilor metodei deschideCont() prezentat n
figura de mai sus. Suplimentar, se va mai aduga atributul xsi:type necesar
destinatarilor mesajului pentru a converti coninutul fiecrui parametru conform
tipurilor de date corespunztoare limbajului de programare ce implementeaz
serviciul Web n cauz.
Rspunsul la cerere respect un set mai complex de reguli i convenii:
<env:Envelope
<env:Body>
<b:deschideContResponse
env:encodingStyle=
xmlns:rpc="http://www.w3.org/2002/06/soap-rpc"
xmlns:b="http://banca.ex.ro/cont"
xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance">
<rpc:result>b:nrCont</rpc:result>
<b:nrCont xsi:type="xsd:int">
56291527
</b:nrCont>
128
SERVICII WEB
</b:deschideContResponse>
</env:Body>
</env:Envelope>
Sesizm dou aspecte legate de acest rspuns care trebuie discutate.

n primul rnd, numele elementului de rspuns este acelai cu cel din mesajul
de cerere, numai c i s-a ataat sufixul Response (n momentul de fa, toate
instrumentele folosesc aceast convenie).
Al doilea aspect const n faptul c rspunsul este capabil s se muleze pe
semantica apelului de procedur pentru multe dintre limbajele de programare
actuale. Acest aspect se datoreaz suportului pentru parametri de tip in, out, in/out.
Un parametru de in este un parametru de intrare pentru procedura apelat. Un
parametru out este parametrul care va conine date la terminarea apelului de
procedur. Un parametru de tip in/out are caracteristicile ambilor parametri in i
out. Diferena const n faptul c un parametru de tip out este similar cu o valoare
de retur, dar datele coninute de el pot fi ignorate de ctre apelantul procedurii.
Datorit importanei pe care o valoare de retur o are n numeroase limbaje
de programare, ea este separat de parametrii in/out, astfel nct n mesajul
nostru se folosete elementul rpc:result pentru identificarea elementului ce include
rspunsul dorit. n cazul acesta e vorba de b:nrCont, elementul care conine
valoarea de retur. Alte elemente care nu sunt refereniate sunt tratate ca simpli
parametri in/out.
Comportamentul este diferit de versiunile anterioare de SOAP, unde valoarea
de retur trebuia s fie primul element-copil al rspunsului.
Specificaia SOAP 1.2 a fost modificat astfel nct s se rezolve eventuale
probleme care puteau aprea (de exemplu, ce se ntmpl n cazul n care nu se
ntoarce nici o valoare de rspuns).
Este posibil ca i n comunicarea SOAP RPC s apar probleme (excepii).
Pentru detectarea i eventual rezolvarea lor, se recurge la avantajul mecanismului
furnizat de Fault. n plus, au fost adugate i alte coduri de eroare, al cror spaiu
de nume este specificat de adresa http://www.w3.org/2002/06/soap-rpc (a se vedea
tabelul de mai jos).
Codificarea SOAP privitoare la
semnalarea erorii
O eroare aprut la receptor (de exemTrebuie generat o eroare cu valoarea
plu: out of memory)
env:Receiver
Receptorul nu nelege codificarea (cazul Trebuie generat o eroare n care Value are
n care emitorul folosete alt codificare valoarea env:DataEncodingUnknown
dect receptorul)
Eroare
PROTOCOLUL SOAP
129
Codificarea SOAP privitoare la

semnalarea erorii
Serviciul care a fost invocat nu conine
Trebuie generat o eroare n care elementul
nici o metod care s se potriveasc
Code conine elementul Value cu valoarea
cererii RPC
env:Sender, iar elementul SubCode va avea
Value setat pe rpc:ProcedureNotPresent
Receptorul nu poate procesa argumentele O eroare n care elementul Code conine
trimise (numr incorect de parametri ori Value avnd valoarea env:Sender i elementul
nu se potrivesc tipurile de date)
SubCode include Value cu rpc:BadArguments
Eroare
n exemplul de mai jos avem un caz n care a aprut o eroare SOAP RPC.
Aceast situaie este rezultatul unei cereri construite incorect (nu s-a transmis un
parametru). Serviciul Web trimite un mesaj de rspuns n care se poate depista
cauza apariiei erorii. Se observ c ne regsim n ultimul caz expus n tabelul de
mai sus, n care mesajul de rspuns specific faptul c a aprut o eroare generat
de emitor (<env:Value>env:Sender </env:Value>) i care s-a datorat
trimiterii unui numr nepotrivit de parametri (<env:Value>rpc:BadArguments
</env:Value>).
<env:Envelope
xmlns:env="http://www.w3.org/2002/06/soap-envelope"
xmlns:rpc="http://www.w3.org/2002/06/soap-rpc">
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>rpc:BadArguments</env:Value>
</env:Subcode>
</env:Code>
<env:Reason xml:lang="ro">
Lipsete parametrul "tip".
</env:Reason>
</env:Fault>
</env:Body>
</env:Envelope>
Remarcm, de asemenea, c n mesaj este utilizat i elementul Reason ce

include explicaii n limbaj natural despre eroarea aprut.
130
SERVICII WEB
8. Versiuni SOAP
O observaie interesant despre SOAP este aceea c elementul Envelope nu
expune o versiune explicit a protocolului, aa cum fac alte protocoale un
exemplu este HTTP (e.g., HTTP/1.0 versus HTTP/1.1), iar un altul este WDDX
(<wddxPacket version="1.0">...</wddxPacket>).
Proiectanii protocolului SOAP au ales cu bun tiin aceast variant,
deoarece s-a observat c suportul oferit de numrul versiunii este destul de fragil.
Astfel, s-a apelat la utilizarea spaiilor de nume XML: versiunea protocolului
este indicat de URI-ul spaiului de nume corespunztor elementului Envelope.
Motoarele de cutare/regsire a serviciilor Web vor cunoate cum s trateze
diferite mesaje SOAP cu care ar putea intra n contact conform urmtoarelor
reguli:
dac mesajul are o versiune similar cu aceea utilizat de aplicaie, atunci
mesajul se va putea procesa;
dac mesajul are o versiune mai veche dect orice versiune pe care aplicaia
tie s o proceseze, atunci pot avea loc dou aciuni: se genereaz o eroare de
tipul Version Mismatch i/sau se trimit clientului informaii legate de versiunile
pe care le poate accepta;
dac mesajul are o versiune mai nou dect toate versiunile pe care programul
n cauz tie s le prelucreze, atunci se poate alege procesarea mesajului (ceea
ce nu este ntotdeauna o soluie bun) sau se poate ncerca s se trimit
clientului informaii privitoare la versiunile pe care le suport.
Pe ansamblu, mecanismul versiunilor bazate pe URI-uri ofer o mare flexibilitate i adaug o mai mare putere de conciliere ntre aplicaii n cazul apariiei
mesajelor cu versiuni diferite.
9. Intermediarii SOAP
SOAP se caracterizeaz prin extensibilitate. Apare o extensibilitate pe vertical
care este conferit de anteturile SOAP. Mai exact, extensibilitatea vertical se
refer la capacitatea de a introduce noi informaii n cadrul mesajelor SOAP.
Exist i o extensibilitate orizontal care se refer la posibilitatea ca diferite
pri dintr-un mesaj s poat fi procesate de noduri diferite. Aceast extensibilitate
orizontal este furnizat de ctre intermediarii SOAP.
PROTOCOLUL SOAP
131
Necesitatea existenei intermediarilor

Intermediarii SOAP sunt aplicaii care pot procesa pri ale unui mesaj SOAP pe
drumul pe care acesta l parcurge de la emitor la destinaia lui final. Intermediarii pot accepta i pot retrimite mesajele SOAP. Exist trei motive principale
care fac necesar prezena intermediarilor SOAP: traversarea de domenii de
ncredere (crossing trust domains), asigurarea scalabilitii i furnizarea unor servicii
suplimentare de-a lungul cii (rutei) de transport al mesajelor.
Modul de traversare a mesajului SOAP prin domenii sigure este de fapt o
problem care se regsete n cadrul sistemelor distribuite. S considerm relaia
dintre o organizaie i Internet. n cadrul organizaiei, calculatoarele formnd o
reea local constituie un domeniu sigur, ns Internetul este vzut ca un
domeniu nesigur. ntre aceste domenii exist ziduri de protecie (firewall-uri) i
pori (gateway-uri) avnd rolul de a permite sau nu accesul n domeniul sigur al
organizaiei.
Un alt motiv al prezenei intermediarilor se datoreaz necesitii de asigurare
a scalabilitii sistemelor distribuite. O imagine simplificat a sistemelor distribuite
e format din dou tipuri de noduri (gazde): unele care formuleaz cereri
(clienii) i altele care furnizeaz rspunsul la aceste cereri (serverele). Folosind
acest model, se poate crea un sistem distribuit scalabil, cu oricte servere la un
moment dat. Pe acest principiu funcioneaz i spaiul Web.
S lum exemplul unui mesaj de e-mail. Avem dou companii A i B.
Corporaia A trimite un mesaj de e-mail la B, ns serverul de e-mail al acesteia
este suprancrcat. n aceste condiii, folosind prioritatea mesajelor i comparnd
cam ct este de ncrcat serverul, mesajul poate s treac printr-o serie de noduri
intermediare nainte de a ajunge la compania B. Eventual, mesajul va fi stocat
temporar pe una dintre mainile intermediare.
Este clar c ntr-un astfel de sistem se cere o dirijare a mesajelor care s nu
se bazeze doar pe parametrii mesajului (emitorul, receptorul, prioritatea), ci
trebuie s depind i de aspecte ca disponibilitatea i ncrcarea nodurilor,
congestia datelor etc. Nodurile intermediare sunt cele care ascund fa de
emitor i receptor toate aceste entiti prin care navigheaz un mesaj.
Un ultim argument n favoarea existenei nodurilor intermediare se refer la
capacitatea acestora de a furniza servicii suplimentare. Unele dintre aceste
servicii pot fi foarte importante pentru aplicaia final. S analizm cteva
exemple:
schimbul de mesaje ntr-un mediu nesigur (e.g., Internet). Pentru a fi siguri c
mesajul nu va fi alterat, mai nti putem trimite mesajul unui intermediar
132
SERVICII WEB
care-l cripteaz. La recepie, un alt nod intermediar verific semntura digital

ataat i dac totul este n regul va decripta mesajul;
asocierea unor faciliti legate de drumul pe care un mesaj l va parcurge.
Folosind aceste faciliti, mesajul va fi dirijat s treac exact prin anumii
intermediari, pentru a ajunge la destinaie n timpul i forma potrivit. Astfel
de informaii sunt indispensabile pentru realizarea unor activiti precum
asigurarea calitii serviciilor (QoS Quality of Service), identificarea congestiilor
de date etc.
Tipuri de intermediari
SOAP ofer soluii flexibile la trei din cele mai importante probleme legate de
nodurile intermediare, rspunznd la urmtoarele ntrebri:
Cum se pot transmite intermediarilor informaiile necesare?
Cum se poate identifica entitatea care proceseaz datele i ce anume proceseaz?
Ce se ntmpl cu informaia prelucrat de intermediari?
Exist dou tipuri de intermediari:
care doar retransmit mesajul primit (forwarding intermediaries);
care modific i apoi retransmit mesajul (active intermediaries).
Intermediarii din prima categorie pot realiza urmtoarele operaii:
terg toate blocurile antet procesate;
elimin toate blocurile antet care nu mai pot fi retrimise i care au fost
ignorate atunci cnd un nod-int a procesat mesajul;
pstreaz toate blocurile antet care pot fi retransmise i care nu au fost
procesate de nodurile-int.
Intermediarii activi ndeplinesc diferite aciuni care pot modifica traseul
mesajului SOAP (uneori n moduri care nu sunt descrise n blocurile antet ale
mesajului). Ca exemple de astfel de aciuni putem meniona apelul unor servicii
de securitate, invocarea unor servicii care manipuleaz coninutul mesajului etc.
Aciunile pe care un astfel de intermediar le efectueaz trebuie s poat fi
detectate de nodurile care vor primi mesajul.
Facem observaia c informaia destinat nodurilor intermediare (care se
gsete n antet) nu are n general nici o legtur cu informaia coninut n
corpul mesajului.
PROTOCOLUL SOAP
133
10. O privire asupra SOAP 1.1. O comparaie cu SOAP 1.2

n acest moment, o multitudine de servicii Web nc folosesc SOAP versiunea
1.1. Vom discuta n continuare ce diferene i asemnri exist ntre cele dou
versiuni.
SOAP 1.1 se bazeaz pe XML 1.0 (documente XML text), iar SOAP 1.2 se
fundamenteaz pe XML Infoset, o viziune mai abstract, arborescent, a tipurilor
de construcii XML. De asemenea, reprezentrile interne bazate pe XML Infoset
pot conduce la optimizri n ceea ce privete performana.
De asemenea, n SOAP 1.2 au fost schimbate spaiile de nume XML pentru
Envelope i pentru schema de codificare. SOAP 1.2 nu permite existena a nici
unui element dup partea de corp a mesajului, pe cnd definiia schemei pentru
SOAP 1.1 permitea o astfel de posibilitate vezi tabelul de mai jos.
SOAP 1.1
<Envelope>
<Header>
Zero sau mai multe blocuri
antet
</Header>
<Body>
Corpul mesajului
</Body>
Alte elemente
</Envelope>
SOAP 1.2
<Envelope>
<Header>
Zero sau mai multe blocuri
antet
</Header>
<Body>
Corpul mesajului
</Body>
</Envelope>
Organizaia de standardizare a inter-operabilitii serviciilor Web WS-I (Web

Services Interoperability) a dezaprobat existena vreunui element suplimentar dup
Body, motivul fiind problemele de incompatibilitate ce ar putea surveni.
n SOAP 1.2 se definete un element antet Misunderstood, n interiorul cruia
se gsesc informaii suplimentare despre erorile care au aprut.
n exemplul urmtor, receptorul raporteaz c nu poate nelege dou anteturi
obligatorii o:oranges i p:peaches.
<e:Envelope>
<e:Header>
<f:Misunderstood qname="o:oranges" />
<f:Misunderstood qname="p:peaches" />
</e:Header>
<e:Body>
<e:Fault>
134
SERVICII WEB
<e:Code>
<e:Value>e:MustUnderstand</e:Value>
</e:Code>
</e:Fault>
</e:Body>
</e:Envelope>
n SOAP 1.1 se ntoarce codul de eroare, dar nici un alt detaliu. De asemenea,
n SOAP 1.2 atributul mustUnderstand ia valorile logice true sau false, n timp ce n
SOAP 1.1 valorile permise erau 0 sau 1.
Versiunea 1.2 a nlocuit atributul actor cu atributul role, n esen semantica lor
fiind asemntoare.
n SOAP 1.2, actorului Next din SOAP 1.1 i s-au ataat nc dou opiuni:
None pentru blocurile antet care nu vor fi niciodat procesate n mod direct;
Ultimate Receiver pentru blocurile antet care vor fi procesate de nodul
destinatar final.
Noua manier de semnalare a erorilor n SOAP 1.2

n ceea ce privete semnalarea erorilor, specificaia SOAP 1.2 definete noul cod
de eroare DataEncodingUnknown, care trebuie generat atunci cnd un mesaj primit
folosete o valoare nerecunoscut, corespunztoare atributului encodingStyle. Codul
de eroare Client din SOAP 1.1 este redenumit Sender n SOAP 1.2, iar codul de
eroare Server din SOAP 1.1 se regsete sub numele Receiver n noua versiune.
Sunt, de asemenea, adugate noi coduri de eroare pentru RPC (a se revedea
subcapitolul 7).
SOAP 1.2 aduce o manier diferit de structurare a elementelor privitoare la
erori vezi tabelul alturat.
SOAP 1.1
Fault
faultcode
faultstring
faultactor
detail
SOAP 1.2
Fault
Code
Subcode
Value
Reason
Node
Role
Detail
Dac SOAP 1.1 permite o extensie a codurilor de eroare folosind notaia cu

. (dot notation), versiunea 1.2 nlocuiete aceast notaie cu o reprezentare XML.
PROTOCOLUL SOAP
SOAP 1.1
<e:Fault>
<faultcode>
e:Server.Memory
</faultcode>
<faultstring>
Out of memory.
</faultstring>
</e:Fault>
135
SOAP 1.2
<e:Fault>
<e:Code>
<e:Value>
e:Receiver
</e:Value>
<e:Subcode>
<e:Value>
Memory
</e:Value>
</e:Subcode>
</e:Code>
<e:Reason>
Out of memory.
</e:Reason>
</e:Fault>
Modelul de procesare
SOAP 1.2 clarific modelul de procesare din SOAP 1.1. Astfel, un nod SOAP
trebuie s proceseze un mesaj respectnd urmtoarele reguli, n aceast ordine:
determinarea rolului pe care l are de jucat. Modalitatea de procesare
depinde de valorile atributului role;
identificarea antetelor obligatorii corespunztoare nodului-int. Astfel, dac
antetul este marcat cu atributul mustUnderstand="true" i atributul role are
o valoare care se potrivete cu nodul-int, atunci acesta e obligat s proceseze
acel bloc antet;
generarea erorii MustUnderstand, dac unul sau mai multe anteturi nu sunt
nelese; aceasta se ntmpl n cazul n care nodul nu conine software-ul
potrivit pentru procesarea antetului;
procesarea antetelor, iar dac nodul este destinatarul final prelucrarea, de
asemenea, a corpului mesajului.
dac exist un nod intermediar, acesta va terge partea din antet care i era
destinat i va retrimite mesajul.
Mecanismul versiunilor
n SOAP 1.2 s-au adugat noi semantici pentru a putea lucra cu mesaje SOAP
de versiuni diferite.
Un nod SOAP 1.2 care primete un mesaj SOAP 1.1 va rspunde cu un
mesaj SOAP 1.1 care conine eroarea SOAP 1.1 Version Mismatch.
136
SERVICII WEB
Un nod SOAP 1.2 care primete un mesaj SOAP de o versiune oarecare

(inclusiv mesaje din versiunile superioare) va rspunde cu un mesaj (tot de tip
SOAP 1.2) coninnd eroarea SOAP 1.2 Version Mismatch i un antet Upgrade cu
lista versiunilor pachetelor pe care le suport.
Un exemplueste urmtorul:
<u:Upgrade
xmlns:u="http://www.w3.org/2001/12/soap-envelope">
<envelope qname="ns1:Envelope" xmlns:ns1=
"http://schemas.xmlsoap.org/soap/envelope/" />
<envelope qname="ns2:Envelope" xmlns:ns2=
"http://www.w3.org/2001/12/soap-envelope" />
</u:Upgrade>
Maniera de codificare a datelor

Versiunea 1.2 furnizeaz o manier similar de codificare cu SOAP 1.1, ns mult
simplificat. Vom prezenta n cele ce urmeaz diferenele cele mai importante.
n SOAP 1.2 atributul encodingStyle poate fi folosit ca element-copil doar al
elementelor Body i Head i al elementului Detail. n SOAP 1.1, acest atribut este
permis pentru orice element din mesaj.
n ceea ce privete valorile de tip multi-referenced, pentru SOAP 1.2 acestea pot
fi codificate diferit fa de versiunea 1.1.
Vom furniza un exemplu:
SOAP 1.1
<e:Carti>
<e:Carte>
<titlu>Proiectarea
siturilor Web</titlu>
<autor
href="#SabinBuraga"
/>
</e:Carte>
<e:Carte>
<titlu>Tehnologii
XML</titlu>
<autor
href="#SabinBuraga"
/>
</e:Carte>
</e:Carti>
<autor id="SabinBuraga">
<nume>Sabin Buraga</nume>
</autor>
SOAP 1.2
<e:Carti>
<e:Carte>
<titlu>Proiectarea
siturilor Web</titlu>
<autor
id="SabinBuraga">
<nume>
Sabin Buraga
</nume>
</autor>
</e:Carte>
<e:Carte>
<titlu>Tehnologii
XML</titlu>
<autor
ref="SabinBuraga"
/>
</e:Carte>
</e:Carti>
PROTOCOLUL SOAP
137
Elementele din schema de codificare SOAP difer ntre SOAP 1.1 i SOAP
1.2, dup cum se poate remarca din tabelul de mai jos:
SOAP 1.1
Atribut
Tip
Exemplu
SOAP 1.2
href
ref
uri-reference
IDREF
#SabinBuraga
http://www.sit.ro/csb.gif
SabinBuraga
n ceea ce privete tablourile, n SOAP 1.2 nu mai ntlnim matricele rare

(sparce array). Fa de SOAP 1.1, atributul arrayType a fost nlocuit cu itemType i
cu atributul arraySize. S urmrim tabelul:
SOAP 1.1
<numere enc:arrayType=
"xs:int[2]">
<numar>29</numar>
<numar>10</numar>
</numere>
SOAP 1.2
<numere
enc:itemType="xs:int"
enc:arraySize="2">
<numar>29</numar>
<numar>10</numar>
</numere>
Specificaia SOAP 1.1 include atributul root care poate fi utilizat pentru a
marca rdcina schemei/grafului de codificare. n SOAP 1.2 acest atribut este
eliminat.
n SOAP 1.2 omiterea unui accesor este echivalent cu NIL. Semantica
accesorului NIL este ns dependent de aplicaie.
Mecanismul RPC
SOAP 1.1 ofer un model de implementare care const n existena unui nod
destinatar SOAP dat sub forma unui URI, iar n cererea SOAP se regsete
logica aplicaiei. O astfel de abordare implic ascunderea sub umbrela unui
URI a tuturor resurselor care pot fi oferite de un nod, mpiedicndu-se astfel
accesarea individual a fiecrei resurse dorite.
S revenim la exemplul nostru cu portocale i s considerm c firma cu
situl www.portocale.info ofer servicii precum: aflarea preului unui anumit sortiment de portocale, obinerea datelor privind ofertele promoionale etc. Dac
aceste servicii ar fi plasate sub acelai URI, ele ar fi efectiv ascunse. O astfel
de abordare reduce Web-ul la un nivel de transport i neag caracterul robust
i scalabil al arhitecturii spaiului WWW (n stilul REST amintit n primul
capitol).
138
SERVICII WEB
SOAP 1.2 recomand ca resursele s fie identificate de URI-uri separate.

Acest aspect permite ca resursele SOAP s poat fi accesate nu numai via HTTP
POST, ci i prin metoda GET.
SOAP 1.2 accept utilizarea fie a tablourilor, fie a structurilor pentru reprezentarea rspunsurilor sau apelurilor RPC, n contrast cu SOAP 1.1, care permitea
doar folosirea de structuri. Serializarea bazat pe tablouri este util n condiiile
n care numrul de argumente nu este cunoscut dinainte.
n urmtorul exemplu avem apelul unei funcii de adunare de numere, care
are un numr variabil de argumente:
<e:Envelope xmlns:e='...'>
<e:Body>
<a:adunaNumere xmlns:a='...' e:encodingStyle='...'>
<n>29</n>
<n>15</n>
...
<n>33</n>
</a:adunaNumere>
</e:Body>
</e:Envelope>
De asemenea, n SOAP 1.2 corpul mesajelor SOAP care folosesc codificarea

SOAP pentru RPC trebuie s conin un singur element-copil, acesta reprezentnd apelul sau rspunsul RPC sub form de structur sau tablou.
n urmtoarele linii, elementul Body este valid n raport cu codificarea SOAP,
dar nu este valid cnd este folosit n conjuncie cu conveniile RPC.
<e:Body>
<n ref='unNumar' />
<n ref='unNumar' />
</a:adunaNumere>
<n id='unNumar'>33</n>
</e:Body>
</e:Envelope>
n cele de mai jos, elementul Body va fi valid att n raport cu codificarea

SOAP, ct i atunci cnd apare n legtur cu conveniile RPC.
<e:Body>
<n id='unNumar'>33</n>
<n ref='unNumar' />
PROTOCOLUL SOAP
139
</a:adunaNumere>
</e:Body>
</e:Envelope>
Versiunea 1.2 introduce i noi coduri de eroare specifice RPC: ProcedureNotPresent

i BadArguments.
Referitor la valorile RPC ntoarse, SOAP 1.2 adaug noi convenii pentru
reprezentarea acestora:
SOAP 1.1
<e:Body>
<b:deschideContResponse>
<b:nrCont>
56291527
</b:nrCont>
</e:Body>
SOAP 1.2
<e:Body>
<b:deschideContResponse>
<rpc:result>
b:nrCont
</rpc:result>
<b:nrCont>
56291527
</b:nrCont>
</e:Body>
Legtura cu HTTP
Vom prezenta n rndurile urmtoare diferenele ntre legtura HTTP cu SOAP
1.1, respectiv cu SOAP 1.2. Tipul text/xml folosit n SOAP 1.1 a fost nlocuit n
versiunea 1.2 cu application/soap+xml.
n SOAP 1.1 s-a pus problema folosirii doar a metodei POST pentru
transportul mesajelor SOAP via HTTP. Versiunea 1.2 ofer suport i pentru
utilizarea metodei GET. Metoda GET asigur c aciunile de cerere sau de
rspuns realizate de un nod SOAP sunt sigure i idempotente, fr efecte
secundare (side effects).
SOAP 1.1 meniona c n antetul HTTP apare atributul SOAPAction, care
poate fi folosit pentru a preciza scopul mesajului pe baza unui URI. Pentru
SOAP 1.2, coninutul acestui atribut poate fi specificat cu ajutorul parametrului
opional action, ce poate fi ataat tipului MIME application/soap+xml. Valoarea
parametrului action va fi desemnat printr-un URI absolut, nu neaprat rezolvabil,
putnd fi folosit de diverse entiti (e.g., firewall-uri) pentru filtrare.
Suplimentar, SOAP 1.2 ofer o descriere mai detaliat a codurilor de stare
HTTP, de exemplu 2xx sau 4xx, pentru raportarea posibilelor situaii ce pot
surveni.
140
SERVICII WEB
Securitatea n SOAP
SOAP 1.2 a adus clarificri versiunii 1.1 din multe puncte de vedere, ns la nivel
de securitate ofer destul de puine nouti.
Din acest motiv programatorii trebuie s urmeze anumii pai adiionali i s
utilizeze diverse tehnici de criptare pentru protejarea mesajelor SOAP a se
parcurge i cele prezentate n capitolul 7.
De asemenea, dezvoltatorii de instrumente SOAP trebuie s prevad situaiile
n care nodurile SOAP pot primi mesaje cu diferite date eronate. Este recomandat
ca nodurile SOAP s aib capacitatea s evalueze care este nivelul de ncredere
n emitorul unui mesaj i n coninutul aferent.
Referine
Apparao, V. et al. (eds.), XML Protocol (XMLP) Requirements, W3C Working Group,
Boston, 2003: http://www.w3.org/TR/xmlp-reqs
Berners-Lee, T., Fielding, R., Masinter, L. (eds.), Uniform Resource Identifiers (URI): Generic
Syntax, IETF RFC 2396: http://www.ietf.org/rfc/rfc2396.txt
Biron, P., Malhotra, A. (eds.), XML Schema Part 2: Datatypes (Second Edition), W3C
Box, D. et al., Simple Object Access Protocol (SOAP) 1.1, W3C Note, Boston, 2000:
http://www.w3.org/TR/SOAP/
Box, D., A Brief History of SOAP, XML.com: http://xml.com/lpt/a/2001/04/04/
soap.html
Buraga, S., Tehnologii XML, Polirom, Iai, 2006
Cabrera, L., Kurt, C., Web Services Architecture and Its Specifications, Microsoft Press, 2005
Dumbill, E., Johnston, J., St. Laurent, S., Programming Web Services with XML-RPC,
OReilly, 2001
Fallside, D., Walmsley, P. (eds.), XML Schema Part 0: Primer (Second Edition), W3C
Fielding, R. et al., Hypertext Transfer Protocol HTTP/1.1, IETF RFC 2616: http://www.ietf.org/
rfc/rfc2616.txt
Freed, N., Borenstein, N., Multipurpose Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies, IETF RFC 2045: http://www.ietf.org/rfc/rfc2045.txt
Gudgin, M. et al. (eds.), SOAP Version 1.2 Part 1: Messaging Framework, W3C Recommendation, Boston, 2003: http://www.w3.org/TR/soap12-part1/
Gudgin, M. et al. (eds.), SOAP Version 1.2 Part 2: Adjuncts, W3C Recommendation,
Boston, 2003: http://www.w3.org/TR/soap12-part2/
Gudgin, M. et al. (eds.), Web Services Addressing 1.0 SOAP Binding, W3C Candidate
Recommendation, Boston, 2005: http://www.w3.org/TR/ws-addr-soap
PROTOCOLUL SOAP
141
Haas, H. et al. (eds.), SOAP Version 1.2 Specification Assertions and Test Collection, W3C
Recommendation, Boston, 2003: http://www.w3.org/TR/soap12-testcollection
Karmarkar, A., Gudgin, M., Lafon, Y. (eds.), Resource Representation SOAP Header Block,
W3C Recommendation, Boston, 2005: http://www.w3.org/TR/soap12-rep/
Mitra, N. (ed.), SOAP Version 1.2 Part 0: Primer, W3C Recommendation, Boston, 2003:
http://www.w3.org/TR/soap12-part0/
Nielsen, H., Ruellan, H., SOAP 1.2 Attachment Feature, W3C Working Group Note,
Boston, 2004: http://www.w3.org/TR/soap12-af/
Vedamuthu, A. (ed.), Web Services Description Language (WSDL) Version 2.0 SOAP 1.1 Binding,
W3C Working Draft, Boston, 2006: http://www.w3.org/TR/wsdl20-soap11-binding
* * *, SOAP Builders: http://www.soapbuilders.org/
* * *, XML-RPC: http://www.xmlrpc.com/
Capitolul 5
Descoperirea serviciilor
Raionamentul meu nu trebuie interpretat
ca afirmaie, ci drept ntrebare.
(Niels Bohr)
Descoperirea serviciilor este una dintre cele mai importante probleme dezbtute pe larg n cadrul comunitii serviciilor Web. Aceasta, de fapt, poate fi
formulat cu ajutorul unei ntrebri simple: cum poate afla un client despre
existena i modul de utilizare a unui serviciu?
Procesul de descoperire a serviciilor Web poate fi unul centralizat sau
distribuit. Exist mai multe abordri de soluionare a acestei probleme, care
constituie subiectul capitolului de fa.
1. Descoperirea serviciilor Web prin UDDI

Cele mai multe aplicaii destinate comerului electronic i care recurg la servicii
Web urmeaz ci divergente pentru conectarea cumprtorilor, furnizorilor de
produse, pieelor i ofertanilor de servicii. Fr largi investiii n infrastructura
tehnologic, companiile de toate mrimile i tipurile pot tranzaciona afaceri
bazate pe Internet doar cu parteneri globali deja cunoscui i care furnizeaz
aplicaii i servicii Web compatibile.
Specificaiile UDDI (Universal Description, Discovery, and Integration) au ca scop
definirea unui set de servicii care s permit descrierea i descoperirea:
afacerilor, organizaiilor i a altor furnizori de servicii Web;
serviciilor Web pe care diverse entiti le pun la dispoziie;
interfeelor cu ajutorul crora pot fi accesate aceste servicii.
UDDI reprezint nivelul superior n stiva format din tehnologii ca TCP/IP,
HTTP, XML, XML Schema i SOAP, cu care cititorul este deja familiarizat.
144
SERVICII WEB
1.1. Scurt istoric

Atunci cnd a aprut UDDI, cea mai mare atenie s-a fixat asupra UBR (UDDI
Business Registry) o implementare public a standardului UDDI, care este de
fapt un catalog principal folosit pentru publicarea serviciilor de tip e-commerce.
Dei UBR rmne un aspect important n ceea ce privete UDDI, el reprezint
doar o component a acestuia.
Tabelul urmtor sintetizeaz nivelurile specificaiilor UDDI (standardele
disponibile de-a lungul anilor):
Versiunea
UDDI
Anul
lansrii
1.0
2000
2.0
2001
3.0
2004
Obiectiv
Crearea cadrului pentru cataloage (regitri) destinate serviciilor de tip e-business.
Alinierea specificaiilor la standardele Web existente i
furnizarea unei taxonomii flexibile a serviciilor.
O principal caracteristic este cea de adugare a suportului pentru securitate.
Actualmente este n vigoare UDDI 3.0, bazat pe mai vechiul standard UDDI
2.0 propus de OASIS (Organization of the Advancement of Structured Information
Standards).
UDDI poate fi considerat drept un meta-serviciu folosit pentru localizarea
serviciilor Web, permind n acelai timp interogri robuste, n raport cu
cantitatea imens de meta-date privitoare la serviciile Web oferite de diveri
implementatori.
1.2. Concepte de baz ale UDDI

Modelul de date UDDI
n figura 1 se pot remarca principalele entiti stocate n regitrii UDDI,
suplimentar fiind ilustrate i relaiile dintre ele.
Tipurile de date folosite (care constituie nucleul modelului UDDI) sunt
definite cu ajutorul unor scheme XML. A fost ales formatul XML, deoarece este
independent de platform i permite exprimarea ntr-un mod natural a relaiilor
ierarhice.
Schemele XML utilizate de UDDI specific diverse tipuri de date fundamentale necesare utilizatorilor i aplicaiilor n vederea folosirii unui serviciu
Web.
DESCOPERIREA SERVICIILOR
145
Figura 1. Tipurile de date UDDI i relaiile stabilite ntre acestea
Tipurile de informaii de baz sunt urmtoarele:

businessService descrie o colecie de servicii Web nrudite, oferite de o
organizaie desemnat de businessEntity;
businessEntity semnific informaia privitoare la organizaia care public un
serviciu;
bindingTemplate specific detalii tehnice despre serviciu, incluznd o referin
la interfaa de programare (API-ul) serviciului;
tModel descrie un model tehnic (technical model) reprezentnd un concept
reutilizabil, cum ar fi tipul unui serviciu Web, un protocol folosit de serviciile
Web, diverse alte atribute sau meta-date (e.g., semnturi digitale, relaii cu alte
servicii etc.).
146
SERVICII WEB
Figura 2. Tipurile de informaii de baz UDDI
O structur de tip businessEntity conine una sau mai multe structuri distincte
de tip businessService. Similar, o structur de tip businessService poate include una
sau mai multe structuri bindingTemplate.
n versiunile recente exist nc dou tipuri de date care faciliteaz afilierea
regitrilor:
publisherAssertion semnific relaiile dintre entitile stocate ntr-un registru;
subscription menine anumite cereri pentru a se detecta schimbrile care pot
avea loc n ceea ce privete un set de entiti.
Toate aceste tipuri de date sunt stocate persistent de regitrii UDDI. Pentru
un anumit catalog UDDI, structurii de date fundamentale i se asociaz un
identificator unic, n acord cu o anumit schem standard. Acest identificator se
numete cheie (UDDI key).
Mai remarcm i faptul c o anumit structur businessEntity (identificat de o
cheie unic) va conine ntotdeauna o anumit instan a unei structuri de tip
businessService (specificat de propria sa cheie).
De oricte ori este necesar, prin intermediul acestor chei pot fi folosite
referine la o anumit entitate.
147
Informaiile de tip businessEntity

Fiecare intrare de tip businessEntity stocheaz date descriptive privitoare la o
afacere sau organizaie i, prin intermediul entitilor businessService pe care le
conine, pune la dispoziie informaii despre serviciile oferite.
O entitate businessService descrie un serviciu, dintr-un anumit punct de vedere.
Similar, fiecare bindingTemplate inclus ntr-o structur businessService furnizeaz o
descriere tehnic a serviciului Web care aparine serviciului logic declarat de
businessService.
Structura businessEntity conine urmtoarele elemente:
uddi:discoveryURLs, care reprezint o list de URL-uri care indic spre documente coninnd mecanisme de descoperire; avem mai jos un exemplu:
<discoveryURLs>
<discoveryURL useType="businessEntity">
http://ws.portocale.info?businessKey
=uddi:portocale.info:registry:Sales:74
</discoveryURL>
</discoveryURLs>
uddi:name, care este un element obligatoriu, semnificnd numele procesului

global de afacere oferit (de exemplu, managementul ordinelor de plat);
uddi:description, ce ofer o descriere, fiind un element opional;
uddi:contacts, ce include informaii de contact privitoare la entitatea care a
publicat serviciul; un exemplu este urmtorul:
<contacts>
<contact useType="Sales">
<personName>Blue Ory</personName>
<email>blue.ory@portocale.info</email>
</contact>
</contacts>
uddi:businessServices, care reprezint o list de servicii furnizate de businessEntity;

uddi:identifierBag pe lng businessKey, care identific n mod unic o structur
businessEntity ntr-un registru, acest element opional permite ca structurile
businessEntity s poat fi regsite n acord cu un sistem de identificare public;
uddi:categoryBag conine o list de categorii de afaceri de exemplu, dup
industrie, dup regiunea geografic etc. , fiecare descriind un anumit aspect
conform unei taxonomii alese (e.g., schema de clasificare NAICS North
American Industry Classification System);
dsig:Signature, reprezentnd o semntur digital XML ataat unei entiti
businessEntity.
148
SERVICII WEB
Notm faptul c elementele name, description i contacts ofer informaii textuale

privitoare businessEntity, eventual n mai multe limbi.
Orice instan a elementului businessEntity este identificat n mod unic de
atributul businessKey. Atunci cnd o structur de tip businessEntity este publicat
ntr-un registru UDDI, atributul businessKey trebuie omis n cazul n care cel care
public informaiile dorete ca registrul s genereze automat o cheie. Atunci
cnd o entitate de tip businessEntity este obinut dintr-un registru UDDI,
atributul businessKey trebuie s existe obligatoriu.
Informaiile de tip businessService

Elementul businessService este o structur reprezentnd un serviciu specificat logic
i conine informaii descriptive n termeni de afaceri. Informaii tehnice despre
businessService se gsesc n structurile de tip bindingTemplates (vezi infra).
Structura businessService ncapsuleaz urmtoarele elemente:
uddi:name, care semnific numele serviciului din cadrul procesului de afacere
oferit (e.g., recepionarea unui ordin de plat);
uddi:description, care specific o descriere a serviciului;
uddi:bindingTemplates este o list de descrieri tehnice a serviciilor Web
furnizate de businessService;
uddi:categoryBag, ce conine o lista de clasificri ale afacerilor, fiecare descriind
un aspect al elementului businessService;
dsig:Signature reprezentnd o semntur digital asociat entitii businessService.
Elementului businessService i sunt ataate i atributele:
serviceKey, ce identific n mod unic o entitate businessService;
businessKey reprezentnd o cheie referitoare la o intrare businessEntity.
Cnd o informaie de tip businessKey este inclus ntr-un registru UDDI,
atributul serviceKey poate fi omis dac organizaia care o public dorete ca
registrul s genereze o cheie. Atunci cnd businessEntity este obinut de la un
registru, atributul serviceKey trebuie s fie prezent.
Atributul businessKey identific n mod unic o informaie businessEntity care
furnizeaz o structura businessService. Fiecare entitate businessService este inclus
ntr-o singur structur businessEntity.
Un exemplu de intrare de tip businessService este urmtorul (cheile sunt furnizate
sub form de identificatori unici universali de tip UUID; pentru UDDI versiunea
3, aceti identificatori nu trebuie neaprat s fie numerici):
149
<businessEntity ...>
...
<businessServices>
<businessService
businessKey="uuid:..." serviceKey="uuid:...">
<name>Preia un ordin de plat</name>
<description xml:lang="ro">
Serviciu pentru recepionarea
ordinelor de plat.
</description>
<bindingTemplates>
...
</bindingTemplates>
<categoryBag>
...
</categoryBag>
</businessService>
</businessServices>
</businessEntity>
Informaiile de tip bindingTemplate

Entitile bindingTemplate furnizeaz descrierile tehnice pentru serviciile Web. Un
element bindingTemplate corespunde unei instane a serviciului oferit la o anumit
adres, n general furniznd URI-ul acesteia. De asemenea, acest element face
referiri la datele de tip tModel (pe care le vom descrie mai jos), precum i la
parametri i setri specifice aplicaiei.
Structura bindingTemplate conine urmtoarele elemente:
uddi:description, care ofer informaii textuale despre bindingTemplate;
uddi:accessPoint, care este un ir de caractere ce permite accesul la serviciul Web
descris. n mod obinuit, este un URI, dar poate fi i o adres de e-mail sau
chiar un numr de telefon;
uddi:hostingRedirector, ce reprezint un element folosit doar pentru pstrarea
compatibilitii cu versiunea UDDI 2.0. Funcionalitatea sa este acoperit de
uddi:accessPoint;
uddi:tModelInstanceDetails, care semnific o list de unul sau mai multe elemente
tModelInstanceInfo. Colecia de atribute tModelKey existente n elementele tModelInstanceInfo formeaz aa-numita amprent tehnic a serviciului Web, care
poate fi folosit pentru identificarea serviciilor compatibile.
uddi:categoryBag, ca mai sus, reprezint o colecie de categorii asociate serviciului;
dsign:Signature, ce semnific o semntur digital.
150
SERVICII WEB
Similar sunt specificate i atributele bindingKey i serviceKey, avnd aceleai

semnificaii ca n cazul anterior.
Un exemplu este urmtorul:
<businessService ...>
<bindingTemplates>
<bindingTemplate
serviceKey="uuid:..." bindingKey="uuid:...">
<accessPoint URLType="http">
http://ws.portocale.info:3333/Sales
</accessPoint>
<tModelInstanceDetails>
...
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
</businessService>
1.3. Structura tModel

Unul dintre scopurile UDDI este acela de a facilita gsirea cu uurin a
serviciilor Web. Un alt obiectiv este cel de a oferi descrieri complete ale acestor
servicii, astfel nct oamenii i programele s poat interaciona uor cu servicii
despre care nu tiau mai nimic n prealabil. Aceste scopuri sunt de fapt trsturile
eseniale ale structurilor tModel. Entitile de baz UDDI sunt tocmai instanele
tModel.
La nivel general, scopul elementelor tModel este de a furniza un sistem de
referin abstract. Exist dou motive principale pentru utilizarea structurilor
tModel: determinarea compatibilitii ntre serviciile Web i folosirea lor drept
referine la un spaiu de nume fixat.
Utilizare
Din punct de vedere al utilizrii, o instan a unei structuri tModel poate fi
referit de mai multe structuri businessEntity. De asemenea, n diferite apeluri ale
interfeei de programare pot aprea referiri la tModel.
Utilizarea cea mai obinuit a elementelor tModel este n reprezentarea
specificaiilor tehnice i a conceptelor. De exemplu, un tModel poate fi folosit
pentru a reprezenta o specificaie care definete un protocol de transport wireless,
formatul interschimburilor de date i secvena de reguli ce trebuie urmate n
procesul de schimb al mesajelor.
151
O aplicaie care comunic cu o alta va prefera, desigur, s adere la specificaii

(convenii) prestabilite. n acest caz, proiectanii acestor specificaii pot stabili o
identitate tehnic unic ntr-un registru UDDI, publicnd informaii despre
acestea n cadrul unui tModel.
n timp ce principalul motiv pentru nregistrarea unui tModel ntr-un registru
UDDI este definirea unei identiti, specificaia real sau setul de documente
care descriu conceptul tModel-ului nu vor face parte din registru, ns vor putea
fi referite (cu ajutorul structurii overviewDoc). Evident, cei care public astfel de
documente, specificnd conceptul pe care un tModel l reprezint, trebuie s
ofere descrieri folosind formate i limbaje bine-cunoscute.
Din moment ce un tModel a fost publicat, alte organizaii pot considera c un
anumit serviciu Web pe care l furnizeaz respect specificaiile acestuia i i
afirm disponibilitatea prin simpla incluziune a unei referine la acel tModel
(folosindu-se tModelKey din structura bindingTemplate) un mod similar este cel n
care cineva poate cita un document Web, fcnd o referire la acesta printr-o
legtur hipertext desemnat de un URI.
Aceast abordare faciliteaz gsirea serviciilor Web compatibile cu o anumit
specificaie. Odat ce o valoare valid pentru tModelKey este cunoscut, este uor
de descoperit c o anumit entitate particular de tip businessEntity are asociat un
serviciu Web refereniind un tModel. n acest mod, un tModelKey devine aa-numita
amprent tehnic (technical fingerprint), unic pentru o anumit specificaie.
Elementele tModel pot fi incluse n cadrul marcatorilor identifierBag, categoryBag,
address i publisherAssertion care sunt folosii pentru specificarea identitii organizaionale i a diferitelor categorii. Utilizat n acest context, un tModel desemneaz
un sistem de valori folositor pentru identificarea sau clasificarea entitilor
UDDI, avnd astfel un rol n constituirea unor taxonomii referitoare la serviciile
Web.
Pentru a reprezenta faptul c o anumit afacere descris de elementul
businessEntity are un anumit identificator ID asociat, keyedReference este plasat
ntr-un identifierBag. Acest keyedReference va avea atributul keyValue cu valoarea
identificatorului ID dat i refer un tModel semnificnd sistemul identificat de
ID. mpreun, keyValue i referina la tModel specific o valoare particular
ntr-un anumit sistem de valori.
Structura unui element de tip tModel

Un element tModel este compus din urmtoarele sub-elemente:
uddi:name care asociaz un nume unic, obligatoriu (n general este un URI);
uddi:description, reprezentnd o descriere textual opional;
152
SERVICII WEB
uddi:overviewDoc, care face referire la informaii privitoare la tModel; include un

element overviewURL ce reprezint adresa la care se gsete documentul
descriind tModel-ul. Atributul useType al marcatorului overviewURL poate avea
mai multe valori. Dac valoarea lui este text, atunci nseamn c overviewURL
conine informaii textuale. O alt valoare des ntlnit pentru useType este
wsdlInterface, ceea ce semnific faptul c overviewURL refer un document
WSDL care poate fi reutilizat de diferite implementri;
uddi:identifierBag, ce conine o list de identificatori logici, cu rol de meta-date;
uddi:categoryBag, care furnizeaz o list de clasificri descriind anumite aspecte
ale tModel-ului.
Structura tModel are asociate i atributele:
tModelKey, care identific n mod unic un tModel;
deleted este un cmp care specific dac tModel-ul a fost ters logic (valorile
sale pot fi true sau false).
Un exemplu de informaii coninute de un tModel este urmtorul, descriind
comportamentul unui serviciu Web:
<tModel tModelKey="uuid:...">
<name>Vnzri online de portocale</name>
<description xml:lang="ro">...</description>
<overviewDoc>
http://ws.portocale.info:3333/Sales?WSDL
</overviewDoc>
<identifierBag>...</identifierBag>
<categoryBag>...</categoryBag>
</tModel>
1.4. Informaii privitoare la publicarea serviciului

Structura publisherAssertion
Multe afaceri i organizaii nu sunt efectiv reprezentate de o singur entitate de
tip businessEntity. Atunci cnd o organizaie este desemnat de mai multe structuri
businessEntity, s-ar dori ca acestea s fie interconectate prin relaii vizibile. Aceasta
se poate realiza cu ajutorul elementului publisherAssertion.
Pentru a elimina posibilitatea ca o entitate care a publicat un serviciu s
revendice o relaie care nu e reciproc, ambii parteneri trebuie s fac publice
aceleai afirmaii pentru ca relaia lor s devin vizibil (se asigur astfel
reciprocitatea).
153
Structurii publisherAssertion i corespund urmtoarele elemente:

uddi:fromKey identific instana surs de tip BusinessEntity care stabilete
acordul (relaia);
uddi:toKey specific instana destinaie de tip BusinessEntity participant la
acord;
uddi:keyedReference descrie relaia dintre cele dou pri;
dsig:Signature desemneaz o semntur digital XML. Atunci cnd o structur
publisherAssertion este semnat, fiecare semntur digital trebuie s fie furnizat
de propriul element dsig:Signature.
Structura operationalInfo
La publicarea unui serviciu, n registrul UDDI sunt stocate i o serie de informaii
operaionale, incluznd data i timpul la care structura de date a fost creat sau
modificat, identificatorul nodului UDDI i identitatea celui care a publicat
datele.
Aceste informaii operaionale vor fi memorate ntr-un element operationalInfo,
pentru structurile de date de tip businessEntity, businessServices, bindingTemplate i
tModel.
Sub-elementele care pot fi folosite n cadrul operationalInfo sunt created, modified,
modifiedIncludingChildren, nodeID, authorizedName. Entitatea UDDI care are asociat
o structur operationalInfo se identific prin atributul obligatoriu entityKey.
1.5. Taxonomia entitilor UDDI

UDDI furnizeaz o structur semantic a informaiilor referitoare la serviciile
Web dintr-un registru. UDDI permite utilizatorilor s defineasc taxonomii
multiple. Astfel, utilizatorii nu sunt legai de un singur sistem taxonomic, ci pot
folosi un numr nelimitat de clasificri dorite.
Specificaiile UDDI includ anumite definiii privitoare la relaiile ierarhice
dintre o instan a unei implementri UDDI i alte entiti de care aceasta este
legat.
Serverele UDDI sunt mprite n urmtoarele tipuri:
nod (node) este un server UDDI care suport minimul de funcionaliti
definite n specificaie. Poate executa una sau mai multe operaii asupra
datelor UDDI la care are acces. Este membrul unui singur registru UDDI;
registru/catalog (registry) este format din unul sau mai multe noduri. Un
registru execut setul complet de funcionaliti definit n specificaiile UDDI.
154
SERVICII WEB
regitri afiliai (affiliated registries) sunt regitrii UDDI care implementeaz

reguli de partajare a informaiilor. Aceti regitri afiliai partajeaz un spaiu
de nume comun pentru cheile UDDI care identific n mod unic nregistrrile
de date.
n versiunea 3.0, una dintre modificrile eseniale este cea privitoare la
conceptul de regitri afiliai. S urmrim mai jos cteva aspecte referitoare la
tipurile de regitri UDDI:
Tipul
registrului
De tip
enterprise sau
privat
(corporate/
private)
Descriere
Un registru intern, al unei ntreprinderi, aflat n
spatele unui firewall izolat de Internet. Accesul la
facilitile administrative i la datele din regitri este
restricionat. Datele nu sunt partajate cu ali regitri.
Exemplu de
aplicaie
Catalog UDDI la
nivel de corporaie (Enterprise
Web Service
Registry)
Un registru dezvoltat n cadrul unui mediu controlat

Reea de pari cu acces limitat la clieni autorizai. Funciile de
De tip afiliat
teneri comerciali
administrare pot fi realizate i de alt partener de ncre(affiliated)
(Trading Partener
dere. Datele pot fi partajate cu ali regitri ntr-o
Network)
manier controlat.
Din perspectiva unui utilizator final, un registru
public este un serviciu obinuit. Dei funciile admiCatalog de tip
nistrative pot fi securizate, accesul la datele din regiUDDI Business
Public
tri este public. Datele pot fi partajate sau transferate
Registry (UBR)
ntre diferii regitri, iar coninutul propriu-zis poate fi
sau nu moderat.
Altfel spus, afilierea permite sistemului UDDI s suporte o varietate de

topologii de reele sau de infrastructuri. Structura unui registru UDDI permite
reflectarea realitii existente n interaciunile reale dintre entitile business.
Managementul versiunilor multiple ale datelor stocate de regitrii UDDI
constituie o real provocare pentru o astfel de infrastructur distribuit. Specificaiile UDDI ofer un cadru care s faciliteze meninerea i asocierea de chei
UDDI nregistrrilor din regitri, dar nu pun n discuie existena vreunui suport
de definire de scenarii business. Regulile de afaceri i scenariile aferente se las n
responsabilitatea dezvoltatorului software care ns, poate folosi infrastructura
de baz oferit de UDDI.
155
Figura 3. Tipurile de regitri i interaciunile ntre acetia (RP = registru privat, RPA =
registru privat afiliat, UBR = UDDI Business Registry)
n figura de mai sus sunt descrise o serie de moduri de interaciune ntre

regitri. Prin mecanisme de tip publicare/abonare (publish/subscribe) i replicare
(replication) ntre nodurile unui registru, informaiile de pe serverele UDDI pot fi
n totalitate publice (cazul UBR), semi-private sau total private i izolate (situaia
unei corporaii folosind servicii Web interne, la nivel de intranet propriu).
1.6. Interfee de programare pentru UDDI

n cadrul specificaiilor UDDI sunt definite dou categorii de interfee de
programare principale: Publisher API i Inquire API.
Publisher API
Interfaa Publisher API permite publicarea i actualizarea de informaii coninute
n regitrii UDDI. Funciile puse la dispoziie sunt descrise de tabelul urmtor.
156
SERVICII WEB
Metoda
add_publisherAssertions
delete_binding
delete_business
delete_publisherAssertions
delete_service
delete_tModel
discard_authToken
get_assertionStatusReport
get_authToken
get_publisherAssertions
get_registeredInfo
save_binding
save_business
save_service
save_tModel
set_publisherAssertions
Descriere
Adaug una sau mai multe relaii specificate de
publisherAssertion
terge una/mai multe instane ale elementului
bindingTemplate din regitri
terge una/mai multe nregistrri de afaceri
Elimin unul/mai multe elemente publisherAssertion
terge unul/mai multe elemente businessService
terge logic una/mai multe structuri tModel
Informeaz un nod c informaiile de autentificare
vor fi nlturate
Raporteaz starea declaraiilor care implic orice
nregistrare de afacere a crui management este
realizat de un anumit publisher
Obine un jeton de autentificare
Furnizeaz toate relaiile de tip publisherAssertion
realizate de un publisher
Obine o list a tuturor structurilor businessEntity i
tModel
Salveaz/actualizeaz un element bindingTemplate
Salveaz/actualizeaz o structur businessEntity
Adaug/actualizeaz unul ori mai multe elemente
businessService
Salveaz sau actualizeaz unul/mai multe elemente de
tip tModel
nlocuiete toate declaraiile de tip publisherAssertion
ale unui publisher
Inquiry API
Interfaa de programare Inquiry API permite operaii pentru cutarea i parcurgerea regitrilor cu scopul de a obine informaii despre o anumit afacere sau un
serviciu dorit. Tabelul de mai jos sintetizeaz lista funcionalitilor oferite.
Metoda
find_binding
find_business
find_relatedBusinesses
find_service
Descriere
Localizeaz o informaie de legare (binding) a unui serviciu la
un protocol (tip, port etc.) n cadrul unui sau mai multor
elemente businessService
Localizeaz informaii despre una/mai multe afaceri
Localizeaz informaii despre nregistrrile businessEntity
asociate unei anumite entiti de afaceri
Localizeaz anumite servicii n cadrul unor entiti de afaceri
Metoda
find_tModel
get_bindingDetail
get_businessDetail
get_businessDetailExt
get_serviceDetail
get_tModelDetail
157
Descriere
Localizeaz una/mai multe structuri tModel
Obine informaii detaliate pentru realizarea de cereri
privitoare la bindingTemplate
Obine informaii despre businessEntity pentru una sau mai
multe afaceri/organizaii
Furnizeaz informaii detaliate despre businessEntity
Obine detalii complete despre un set de entiti businessService
Furnizeaz detalii referitoare la un tModel
Publisher API i Inquiry API reprezint nucleul instrumentelor care realizeaz

managementul datelor din cadrul regitrilor UDDI.
De notat faptul c marile companii pun la dispoziie cataloage de tip UBR ce
pot fi accesate via API-urile prezentate mai sus. Cteva exemple notabile sunt
urmtoarele:
accesarea interfeei de interogare a registrului UBR de la IBM: http://uddi.ibm.com/
ubr/inquiryapi
accesarea interfeei de publicare n registrul UBR oferit de IBM: https://uddi.ibm.com/
ubr/publishapi
accesarea interfeei de interogare a registrului UBR pus la dispoziie de
Microsoft: http://uddi.microsoft.com/inquire
accesarea interfeei de publicare pentru registrul de tip UBR de la Microsoft:
https://uddi.microsoft.com/publish
Sunt disponibile i o serie de instrumente grafice de acces la UDDI prin
interfeele prezentate mai sus. Menionm doar Registry Browser din cadrul
pachetului de dezvoltare a serviciilor Web oferit de Sun Java WSDP (Web
Services Developer Pack). Tot n cadrul acestui pachet sunt disponibile o serie de
exemple de programe Java pentru lucrul cu regitrii UDDI publici.
Alte interfee de programare

O interfa de programare suplimentar este Security API, oferind dou funcii:
discard_authToken informeaz nodul c token-ul (jetonul) de autentificare
obinut anterior nu mai este solicitat i c trebuie considerat invalid dac este
utilizat dup ce acest mesaj este primit (astfel, se controleaz maniera de
valabilitate a procesului de autentificare);
get_authToken solicit de la un nod UDDI un jeton de autentificare sub
forma unui element authInfo. Un astfel de element poate fi solicitat atunci
158
SERVICII WEB
cnd se folosesc funcii din alte interfee de programare precum Inquiry,

Publication, Custody and Ownership Transfer sau Subscription.
Interfaa de programare numit Custody and Ownership Transfer API permite ca
orice nod al unui registru s transfere custodia unei structuri businessEntity sau
tModel de la un nod la altul. De asemenea, se ofer suport i pentru preluarea de
la o entitate la alta a dreptului de proprietate asupra acestor structuri.
Fr a intra n detalii tehnice pe care le putei gsi n specificaiile UDDI
s urmrim un scenariu general. S consideram c avem la dispoziie un registru
UDDI format din nodurile A, B i C. Registrul permite fiecrui nod s-i
defineasc propriile reguli pentru nregistrare, autentificare i autorizare. Dac o
persoan P dorete s se autentifice, va trebui s obin regulile de politic a
accesului ale celor trei noduri. S considerm cazul n care P alege nodul A.
Dac reuete s se autentifice cu succes i s publice o entitate business (fie
ea desemnat de E1), atunci P devine proprietar (owner) al lui E1. Se consider c
nodul A este custode (custodian) pentru E1. De asemenea, P poate efectua aceleai
operaii la nodul B, fiind n msur s publice o entitate de afaceri E 2. Nu se
poate face nici o presupunere c un registru UDDI (sau nodurile sale) este
contient c P reprezint aceeai persoan. P este responsabil pentru meninerea identitii i autentificrii corecte pentru fiecare nod din cadrul registrului.
Interfaa Subscription API d posibilitatea clienilor autentificai s primeasc
informaii privitoare la schimbrile regitrilor UDDI de care acetia sunt interesai. Aceast interfa este opional i poate fi implementat n maniera dorit
la nivelul fiecrui nod.
1.7. UDDI i SOAP

Vom enumera n cele ce urmeaz conveniile utilizrii SOAP i UDDI, prezentnd ce elemente ale protocolului SOAP 1.1 sunt suportate sau nu de UDDI:
UDDI necesit prezena cmpului SOAPAction din antetul HTTP. SOAPAction
poate conine o valoare sau poate fi vid:
POST ... HTTP/1.1
Content-Type: text/xml; charset="utf-8"
SOAPAction: ""
<?xml version="1.0" encoding="UTF-8" ?>

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
159
<Body>
<get_bindingDetail xmlns="urn:uddi-org:api_v3">
...
</Envelope>
UDDI nu ofer suport pentru conceptul de actor SOAP (pentru SOAP 1.2,
regsit sub numele de rol role). Nodurile UDDI vor respinge orice cerere
care vine cu un atribut actor n elementul Header. Se va ntoarce o eroare
SOAP fr nici un element Detail, iar codul erorii este de tip Client (sau Sender
n cazul SOAP 1.2).
UDDI nu are prevzut suport pentru facilitatea SOAP Encoding. n mesajele
trimise unui nod UDDI, nu trebuie s existe nici o informaie privitoare la
stilul de codificare pentru nici un element din cadrul spaiului de nume
urn:uddi-org. n caz contrar, nodul va rspunde cu un cod de eroare de tip
Client, iar faultstring va indica motivul apariiei problemei.
Regitrii UDDI pot ignora coninutul anteturilor SOAP.
UDDI suport urmtoarele coduri de eroare SOAP 1.1: VersionMismatch,
MustUnderstand, Client i Server.
1.8. UDDI i WSDL

UDDI este o arhitectur care permite stocarea informaiilor privitoare la diferite
servicii Web, ns nu se ocup cu descrierea acestora. Pentru a putea utiliza un
serviciu Web regsit prin intermediul UDDI, avem nevoie de o descriere WSDL
a acestuia. n cele ce urmeaz, ne vom referi la WSDL 1.1, modificrile n cele
ce privete versiunea 2.0 fiind minore.
Specificaiile existente descriu cteva tipuri de structuri tModel, care trebuie s
fie furnizate de regitrii UDDI, astfel nct s putem avea suport pentru a
modela informaii de tip portType i binding din WSDL la nivel UDDI. De
asemenea, trebuie furnizat un model care s fie consistent atunci cnd se
lucreaz att cu versiunea 3.0, ct i cu UDDI 2.0. Mai mult, surprinderea
informaiilor dintr-o WSDL trebuie s se realizeze fr o duplicare excesiv.
Sunt introduse ase aa-numite sisteme categoriale (category systems):
1. WSDL Entity Type Category System este folosit pentru a identifica entitile
UDDI care corespund celor WSDL. Este n mod obinuit folosit n cazul
structurilor tModel i businessService. Cum WSDL permite ca portType i un
binding s aib acelai nume, singurul mod de a diferenia cele dou elemente
tModel corespunztoare informaiilor portType i, respectiv, binding este de
a recurge la keyedReference.
160
SERVICII WEB
2. XML Namespace Category System este utilizat la reprezentarea oricrui spaiu

de nume XML (nu doar pentru spaii de nume privitoare la WSDL). Aceast
facilitate permite realizarea de interogri precise, folosindu-se numele complet
al elementelor XML (spaiu de nume + numele local de element).
3. XML Local Name Category System poate fi util atunci cnd se folosete numele
local al unui element XML, pentru cazul n care numele corespunznd unei
structuri UDDI nu poate fi acelai cu cel al unui element XML local (fr a
fi prefixat de spaiul de nume).
4. WSDL portType Reference Category System este folosit pentru a reprezenta
legtura dintre un binding i un portType. I se permite unei entiti UDDI s se
refere la o alt entitate prin stocarea cheii sale ca valoare a atributului
keyValue al lui keyReference (privitor la acest sistem de clasificare).
5. Protocol Category System permite ca structuri tModel referitoare la protocoale
definite de utilizator s fie ncorporate n abordarea descris n specificaii.
6. Transport Category System permite ca structuri tModel de transport specificate
de utilizator s poate fi folosite n acest context.
De asemenea, se mai poate recurge i la urmtoarele tipuri de structuri tModel:
SOAP Protocol tModel pentru a reprezenta utilizarea SOAP i WSDL;
HTTP Protocol tModel pentru a modela legtura ntre WSDL i HTTP;
WSDL Address tModel pentru cazul n care se folosesc documente WSDL.
Vom da o serie de detalii referitoare la legtura dintre WSDL i UDDI 2.0
(diferenele fa de versiunea 3 nu sunt semnificative).
Un element portType specific WSDL este reprezentat n cadrul UDDI de un
tModel. Acest tModel este clasificat folosind WSDL Entity Type Category System.
Numele structurii tModel asociate lui portType va fi identic cu cel al lui portType.
Acest aspect eludeaz cumva specificaiile UDDI care prevd c numele unui
tModel ar trebui s fie un URI.
Cnd s-a luat aceast decizie s-au propus urmtoarele alternative:
s se foloseasc numele lui portType varianta aleas;
s se recurg la o combinaie dintre portType i spaiul de nume. Aceast
opiune ar fi fcut mai dificil cutarea fie dup spaiul de nume, fie conform
unui portType;
s se utilizeze un URI i numele local al elementelor XML, iar spaiul de
nume s fie plasat n sub-elementul categoryBag din tModel. Aceast variant
face i mai dificil cutarea numelui unui portType, iar numele tModel-ului nu
conine nici o informaie reprezentativ.
161
Spaiul de nume al elementului portType este dat de keyedReference din marcatorul

categoryBag al structurii tModel privitoare la portType. Acest keyedReference determin
legtura cu sistemul de clasificare XML Namespace menionat mai sus.
Elementul binding este reprezentat tot ca un tModel, dar de tip WSDL
binding tModel, pentru a-l distinge de alte categorii de structuri tModel. Se
folosete acelai sistem de clasificare ca i n cazul anterior, dar cu o valoare
diferit pentru keyValue. Numele tModel-ului este acelai cu cel cuprins de
binding.
Elementul service al documentului WSDL este reprezentat de businessService.
Dac service desemneaz interfaa unui serviciu Web prezent deja n cadrul
registrului UDDI, atunci structura businesService aferent este adugat informaiilor existente. n caz contrar, poate fi creat o nou intrare businessService.
Elementul port este reprezentat de bindingTemplate. Coninutul relaiei dintre
un serviciu WSDL i porturile sale este oglindit aici de relaia dintre businessService
i bindingTemplates.
Discuia de mai sus se concretizeaz n figura urmtoare.
Figura 4. Relaia dintre elementele WSDL i cele UDDI
Publicarea i gsirea descrierilor WSDL

O descriere WSDL complet a unui serviciu este o combinaie ntre documentul
de tip interfa a serviciului i documentul de tip implementare.
Cum interfaa serviciului reprezint o definiie reutilizabil a acestuia, ea este
publicat ntr-un registru UDDI ca un tModel. Implementarea serviciului descrie
o instan a acestuia. Fiecare instan este definit folosind elementul WSDL
162
SERVICII WEB
service. Pentru a publica o structur businessService este utilizat un element service

dintr-un document de tip implementare.
Figura 5 ofer o serie de detalii privind asocierea elementelor WSDL ca
elemente UDDI.
Figura 5. Corespondena dintre elementele WSDL

i intrrile UDDI
Structura tModel corespunztoare interfeei serviciului Web este publicat de

furnizorul acelei interfee de serviciu. O parte dintre elementele din tModel sunt
construite pe baza informaiilor din descrierea WSDL aferent. n tabelul urmtor
se definesc paii crerii unui tModel care pentru a fi valid ar trebui numit folosind
targetNamespace i ar trebui s conin date pentru umplerea elementelor
overviewURL i categoryBag.
tModel
UDDI
1
name
description
Interfaa
WSDL a
serviciului
Atributul
targetNamespace
pentru definirea
elementului
Elementul
documentation
3 overviewURL URI-ul interfeei

serviciului i
specificarea
elementului binding
4
categoryBag
Descriere
Numele pentru tModel este obinut
folosindu-se valoarea atributului
targetNamespace din documentul
WSDL. Este necesar un nume consistent, pentru ca un tModel s fie localizat folosindu-se doar informaii din
documentul de tip implementare a
serviciului.
Elementul description din tModel este
restrns la 256 de caractere. Dac elementul documentation nu exist, atunci
trebuie utilizat numele atributului din
elementul definitions.
Localizarea documentului de tip interfa a serviciului poate fi folosit ca
valoare pentru overviewURL. Dac
exist mai mult de un singur element
binding, atunci valoarea acestuia este
codificat n URL.
Elementul categoryBag trebuie s
conin cel puin un sub-element
keyedReference. Atributul keyName va
avea valoarea uddi-org:types, iar
keyValue va avea valoarea wsdlSpec.
163
Obligatoriu
Da
Nu
Da
Da
Documentul de mai jos reprezint interfaa unui serviciu Web. Valorile ce vor
fi inserate ntr-un tModel apar cu caractere ngroate:
<definitions name="TranzactiiPortService-interface"
targetNamespace=
"http://www.portocale.info/
TranzactiiPortService-interface"
xmlns:tns=
"http://www.portocale.info/TranzactiiPortService-interface"
Definiia unei interfee standard WSDL pentru
un serviciu de tranzacii de portocale.
</documentation>
164
SERVICII WEB
<message name="TipPortocaleRequest">
<part name="tip" type="xsd:string"/>
</message>
<message name="TipPortocaleResponse">
<part name="tipIntors" type="xsd:string"/>
</message>
<portType name="TipPortocaleTranzactiiPortService">
<operation name="furnizeazaTipPortocale">
<input message="tns:TipPortocaleRequest"/>
<output message="tns:TipPortocaleResponse"/>
</operation>
</portType>
<binding name="TipPortocaleBinding"
type="tns:TipPortocaleTranzactiiPortService">
<soap:binding style="rpc" transport=
"http://schemas.xmlsoap.org/soap/http"/>
<operation name="furnizeazaTipPortocale">
<soap:operation soapAction=
"http://www.portocale.info/furnizeazaTip"/>
<input>
<soap:body use="encoded"
namespace="urn:tip-portocale-tranzactii-port"
encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded"
namespace="urn:tip-portocale-tranzactii-port"
encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
</definitions>
Valoarea atributului targetNamespace va fi folosit ca nume pentru tModel,

coninutul elementului documentation va reprezenta descrierea structurii tModel, iar
atributul name al elementului binding va fi utilizat s descrie overviewURL.
Documentul UDDI privitor la tModel are forma urmtoare:
<tModel tModelKey="">
<name>http://www.portocale.info/
TranzactiiPortService interface</name>
165
Definiia unei interfee standard WSDL pentru
un serviciu de tranzacii de portocale.
</description>
<overviewDoc>
Documentul WSDL descriind interfaa serviciului
</description>
<overviewURL>
http://www.portocale.info/TranzactiiPortServiceinterface.wsdl#TipPortocaleBinding
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey="uuid:..."
keyName="uddi-org:types" keyValue="wsdlSpec"/>
keyName="Serviciu tranzact." keyValue="..."/>
</categoryBag>
</tModel>
Elementul overviewURL are valoarea http://www.portocale.info/TranzactiiPortService-interface.wsdl, care reprezint adresa documentului WSDL de tip interfa a
serviciului Web. El conine, de asemenea, o referin direct la elementul binding
cu name="TipPortocaleBinding" n documentul de tip interfa a serviciului.
Cum exist doar un singur element binding n documentul WSDL, aceast
referin la binding nu este obligatorie.
Implementarea serviciului Web este publicat n regitrii UDDI ca o structur
businessService, avnd unul sau mai multe marcaje bindingTemplates. Aceast publicare este realizat de furnizorul acelui serviciu.
Pentru fiecare element service specificat n documentul de implementare a
serviciului va fi creat cte o structur businessService.
Lista de sub-elemente ale businessService care pot fi specificate pe baza
coninutului documentului WSDL de implementare a serviciului cuprinde:
name are valoarea dat de atributul elementului service din documentul
WSDL;
description folosete primele 256 de caractere ale elementului documentation,
dac exist.
Pentru fiecare port din cadrul elementului service se creeaz un nou element
bindingTemplate, conform detaliilor din tabelul urmtor.
166
SERVICII WEB
binding
Template
description
accessPoint
tModel
InstanceInfo
overviewURL
Descriere
Dac elementul port conine un sub-element documentation, descrierea conine primele 256 de caractere ale
elementului documentation
Pentru o legare (binding) SOAP sau HTTP, accessPoint
are valoarea atributului location al elementului extension
asociat elementului port. Dac elementul conine un
URL, atributul URLType va desemna protocolul din
cadrul URL-ului. Dac nu se folosete nici un URL,
atributul URLType ar trebui folosit pentru a se cunoate
tipul protocolului.
Va exista cte un element tModelInstanceInfo pentru fiecare tModel pe care-l refereniaz. Astfel, va aprea cel
puin un tModelInstanceInfo incluznd o referin direct
la tModel-ul ce reprezint documentul de interfa a
serviciului.
Poate conine o referin direct la documentul de
implementare a serviciului, folosit doar pentru a
furniza o documentaie uor de neles (human-readable).
Toate celelalte informaii din acest document ar trebui
s fie accesibile printr-o entitate de date UDDI (UDDI
data entity). Suntem asigurai c documentul publicat
este acelai cu cel obinut n urma operaiei de cutare.
Dac acest document cuprinde mai mult dect un element port, atunci acesta ar trebui s conin o referin
direct la atributul name al lui port. Nu este suficient s se
foloseasc doar o referin la elementul binding din
tModel, deoarece pot exista mai multe marcaje port
referind acelai binding.
Obligatoriu
Nu
Da
Da
Nu
Exemplul de mai jos reprezint un document WSDL de implementare a unui

serviciu. Valorile indicate cu caractere ngroate sunt obligatorii pentru crearea
intrrilor businessService i bindingTemplates.
<definitions name="TranzactiiPortService"
targetNamespace=
"http://www.portocale.info/TranzactiiPortService"
xmlns:interface=
"http://www.portocale.info/
167
<import namespace="http://www.portocale.info/
location=
"http://www.portocale.info/wsdl/
TranzactiiPortService-interface.wsdl"/>
<service name="TranzactiiPortService">
<documentation>...</documentation>
<port name="TipPortocaleServicePort"
binding="interface:TipPortocaleBinding">
<documentation>
TipPortocaleTranzactiiPortService
</documentation>
<soap:address location=
"http://www.portocale.info/TranzactiiPortService"/>
</port>
</service>
</definitions>
Atributul name al elementului service va fi folosit ca nume pentru businessService.

Elementul documentation din interiorul elementului service este utilizat pentru a
descrie structura businessService.
Atributul name al elementului port este anexat lui overviewURL, care conine o
referin la documentul de implementare a serviciului. Atributul location al lui
service este folosit pentru umplerea marcatorului accessPoint din structura
bindingTemplate.
Definiia unei intrri businessDefinition create pe baza documentului WSDL de
mai sus este furnizat de exemplul urmtor. Elementul categoryBag ar trebui s
conin unul sau mai muli marcatori keyedReference, folosii n clasificarea
scopurilor afacerilor utilizate pentru serviciul de fa.
<businessService businessKey="..." serviceKey="...">
<name>TranzactiiPortService</name>
<description xml:lang="en">
...
</description>
<bindingTemplates>
<bindingTemplate bindingKey="..." serviceKey="...">
<description>
...
</description>
<accesssPoint URLType="http">
168
SERVICII WEB
http://www.portocale.info/TipTranzactiiPort
</accessPoint>
<tModelInstanceInfo tModelKey="...">
<instanceDetails>
<overviewURL>
http://www.portocale.info/services/
TranzactiiPortService.wsdl
</overviewURL>
</instanceDetails>
</tModelInstanceInfo>
</bindingTemplate>
</bindingTemplates>
<categoryBag>
keyName="..." keyValue="..." />
</categoryBag>
</businessService>
Atributul tModelKey are drept valoare un UUID pentru tModel-ul privitor la

documentul de interfa a serviciului. Acest tModel poate fi localizat folosindu-se
atributul namespace din cadrul elementului import. Marcatorul overviewURL reprezint locaia documentului care implementeaz serviciul. El nu conine o referin
la elementul port, deoarece este unic pentru acest document.
Gsirea descrierilor WSDL privitoare la interfaa serviciilor se realizeaz dup
cum urmeaz. Dup cum deja cunoatem, toate documentele WSDL referitoare
la interfaa serviciilor Web sunt publicate n regitrii UDDI sub form de tModel.
Fiecare structur tModel e clasificat ntr-o anumit manier via categoryBag.
Operaia find_tModel oferit de API-ul UDDI poate fi folosit pentru a gsi un
tModel clasificat. Localizarea tuturor descrierilor WSDL privitoare la interfaa
unui serviciu se realizeaz conform construciei urmtoare:
<find_tModel generic="2.0" xmlns="urn:uddi-org:api">
<categoryBag>
keyName="uddi-org:types"
keyValue="wsdlSpec" />
</categoryBag>
</find_tModel>
Operaia find_tModel va ntoarce o list de chei tModel. Folosindu-se metoda

get_tModelDetail, este obinut o descriere particular a interfeei unui serviciu.
Metoda get_tModelDetail va returna un element tModel precum cel prezentat n
cadrul capitolului de fa.
169
Urmtorul pas este s se recurg la elementul overviewURL pentru a se obine

coninutul documentului WSDL de interfa a serviciului.
n plus, n cadrul categoryBag se mai pot aduga elemente keyedReference
suplimentare pentru a se limita mulimea de structuri tModel ntoarse ca rspuns
la aceast cerere. Metoda find_tModel de mai sus poate fi folosit pentru a localiza
toate serviciile de tip TranzactiiPort care folosesc WSDL.
<find_tModel generic="2.0" xmlns="urn:uddi-org:api">
<categoryBag>
keyName="uddi-org:types"
keyValue="wsdlSpec" />

keyName="TranzactiiPort"
keyValue="..." />
</categoryBag>
</find_tModel>
Gsirea descrierilor WSDL privitoare la implementarea serviciilor Web se

efectueaz conform etapelor descrise n continuare. O implementare a unui
serviciu este publicat n regitrii UDDI ca o intrare businessService. Acest
businessService va conine unul sau mai multe elemente bindingTemplates.
Suplimentar, structurile businessService au asociate categorii de clasificare, atfel
nct s poat fi identificate ca descrieri bazate pe WSDL a serviciilor.
O soluie pentru regsirea descrierii unui serviciu este dat de operaia
find_service.
O anumit entitate businessEntity se poate folosi de mesajul urmtor pentru
localizarea unei structuri de tip businessService, incluznd implementarea unui
serviciu TranzactiiPort. n plus, pot fi adugate i alte elemente keyedReferences
n cadrul categoryBag, cu rol de filtrare a rspunsului.
<find_service businessKey="..." generic="2.0"
xmlns="urn:uddi-org:api">
<categoryBag>
keyName="TranzactiiPort"
keyValue="..." />
</categoryBag>
</find_service>
Metoda find_service poate fi de ajutor i pentru a localiza date de tip businessService,

desemnnd implementri specifice ale interfeei unui serviciu. Mesajul descris
mai jos conine un exemplu n care se caut toate elementele businessService din
170
SERVICII WEB
cadrul marcajului businessEntity. Acest din urm element refer implementarea

interfeei unui serviciu particular (de exemplu, privitor la tranzaciile bancare).
Cum interfaa unui serviciu este reprezentat de un tModel, se va folosi un
tModelBag pentru a meniona cheia tModel corespunztoare interfeei WSDL a
serviciului considerat.
<find_service businessKey="..." generic="2.0"
<tModelBag>

<tModelKey>...</tModelKey>
</tModelBag>
</find_service>
Metoda find_service va returna o list de intrri. Descrierea businessService poate

fi obinut folosind metoda get_serviceDetail. Aceasta va ntoarce o structur
businessService precum cea prezentat mai sus. Dup ce s-a obinut un businessService,
pentru invocarea serviciului Web gsit se va selecta un anumit element bindingTemplate
inclus n businessService. Elementul accessPoint din cadrul marcatorului bindingTemplate
semnific tocmai punctul terminal al serviciului.
De asemenea, poate fi folosit elementul overviewURL, n vederea obinerii
coninutului documentului WSDL referitor la implementarea serviciului, care la
rndul su poate oferi i alte detalii de interes.
Furnizm n continuare maniera de gsire a unei structuri bindingTemplate. Dac
marcatorul businessService are mai mult de un element bindingTemplate, este dificil s
se determine care marcaj bindingTemplate trebuie efectiv folosit. Pentru a localiza
elementul bindingTemplate ce ar trebui utilizat, vom recurge la operaia find_binding.
Exemplul de mai jos recurge la find_binding pentru a obine elementul
bindingTemplate, refereniind un anumit tModel. Acest tModel poate fi asociat unui
element binding particular din cadrul descrierii WSDL a interfeei serviciului.
<find_binding serviceKey="..." generic="1.0"
<tModelBag>

<tModelKey>...</tModelKey>
</tModelBag>
</find_binding>
Se va obine unul sau mai multe elemente bindingTemplate. Dup accesarea

marcajului bindingTemplate, punctul de destinaie pentru serviciul Web este oferit
171
de elementul accessPoint. Dac elementul bindingTemplate a fost creat pe baza unui

document WSDL existent (privitor la implementarea serviciului), atunci overviewURL
poate oferi o referin la acest document. Acest document WSDL poate fi
accesat pentru a obine i alte informaii utile privitoare la serviciul Web,
informaii care nu au putut fi regsite n regitrii UDDI.
Iat un exemplu de structur bindingTemplate ntoars n urma interogrii
descrise anterior:
<bindingTemplate bindingKey=""serviceKey="">
<accesssPoint URLType="http">
http://www.portocale.info/TipTranzactiiPort
</accessPoint>

<tModelInstanceInfo tModelKey="...">
<instanceDetails>
<overviewURL>
http://www.portocale.info/TranzactiiPortService.wsdl
</overviewURL>
</instanceDetails>
</tModelInstanceInfo>
</bindingTemplate>
1.9. Crearea propriului registru UDDI folosind jUDDI

Dup cum am vzut mai sus, UDDI definete un protocol de descoperire a
serviciilor Web (permind clienilor s regseasc serviciile Web dorite), punnd
la dispoziie i un format standard de descriere a serviciilor (care ofer clienilor
detaliile privitoare la funcionalitile serviciilor Web gsite).
Exist dou tipuri de regitri UDDI: regitrii publici i cei privai. n aceast
seciune vom detalia n principal maniera de manipulare a regitrilor privai ce
pot fi utili n cadrul unui mediu de tip enterprise. De asemenea, vom oferi o serie
de amnunte privitoare la un cadru de lucru folosit pentru a reprezenta structuri
ale regitrilor UDDI i pentru a implementa regitri UDDI privai. Este vorba
de framework-ul jUDDI, disponibil n regim open source.
Descriere succint a instrumentului jUDDI

Instrumentul jUDDI este implementat n Java i ofer compatibilitatea cu UDDI
versiunea 2.0 pentru managementul regitrilor UDDI.
Pentru a putea crea propriul registru UDDI, trebuie instalate urmtoarele aplicaii:
172
SERVICII WEB
Java 2 SDK n exemplificrile urmtoare am folosit Java 2 SDK SE,

versiunea 1.5.0_06;
J2EE Build and Runtime Environment s-a utilizat Java 2 Enterprise Edition (J2EE)
1.4 oferit de Sun;
Un server Web i/sau un container de servlet-uri n acest caz s-a recurs la
Apache Tomcat, versiunea 5.5.12;
Un cadru de lucru pentru procesarea mesajelor SOAP s-a folosit Apache
Axis (compatibil cu jUDDI).
Un mecanism de stocare a datelor s-a utilizat serverul de baze de date
MySQL versiunea 5.0 (se poate recurge, de asemenea, i la alte soluii,
eventual comerciale: DB2, Sybase etc.);
Un instrument de management al regitrilor UDDI n cazul nostru, am
adoptat jUDDI.
Aplicaia jUDDI folosete Apache Axis pentru manipularea mesajelor SOAP.
Axis definete un cadru de transport transparent, care permite folosirea diferitelor
protocoale. Pentru transferul mesajelor via HTTP, orice servlet derivat din clasa
org.apache.axis.transport.http.AxisServlet este un bun candidat.
n jUDDI exist disponibile trei servlet-uri ce extind clasa AxisServlet:
org.apache.juddi.transport.axis.AdminServlet pentru administrare;
org.apache.juddi.transport.axis.PublishServlet pentru publicarea n regitri;
org.apache.juddi.transport.axis.InquiryServlet pentru realizarea interogrilor.
Aceste trei clase sunt nregistrate de jUDDI ca servlet-uri cu ajutorul unei aplicaii-server i sunt folosite doar pentru a determina tipul cererilor care sunt efectuate.
Procesarea de fapt este realizat de ctre clasa org.apache.juddi.transport.axis.AxisHandler.
Instrumentul jUDDI ncapsuleaz structurile de date fundamentale UDDI
(businessEntity, businessService, bindingTemplate i tModel) n clase. Acestea se gsesc
n pachetul org.apache.juddi.datatype sub urmtoarele denumiri:
org.apache.juddi.datatype.business.BusinessEntity;
org.apache.juddi.datatype.service.BusinessService;
org.apache.juddi.datatype.binding.BindingTemplate;
org.apache.juddi.datatype.tmodel.TModel.
Pentru a putea procesa cererile clienilor, nu avem de fcut dect s recurgem

la instanele acestor clase, mpreun cu alte tipuri de date furnizate de mediul
jUDDI.
173
Manipularea cererilor via jUDDI

jUDDI despacheteaz un mesaj de cerere cu ajutorul unui obiect numit AxisHandler.
Clasa AxisHandler folosete serviciile clasei RegistryEngine pentru a efectua procesarea efectiv a cererii primite. Modul de departajare a tipurilor de cereri (inquiry,
publish i admin) se realizeaz prin intermediul unui URI n cadrul AxisServlet.
Framework-ul clasific fiecare cerere n raport cu valoarea proprietii gsit n
obiectul de cerere MessageContext pentru cheia transport.http.servlet.
De exemplu, o cerere de publicare de date n regitrii UDDI e desemnat de
un URI de genul http://localhost:8080/juddi/publish asociat servlet-ului responsabil
cu aceasta: PublishServlet. Dup ce a primit o cerere, un obiect al clasei RegistryEngine
convertete cererea UDDI bazat pe XML n obiecte Java (deserializare, unmarshalling).
Se invoc obiectele Java i ulterior se convertete rspunsul (obiectele Java)
ntr-un rspuns n format XML (serializare, marshalling).
Similar, un URI de forma http://localhost:8080/juddi/inquiry corespunde unui
servlet de tip InquiryServlet.
Modul de autentificare
Framework-ul jUDDI recurge la org.apache.juddi.auth.AuthenticationFactory pentru a
crea o instan Authenticator, cu scopul de a putea autentifica un client dat.
AuthenticatorFactory este o implementare a modelului Factory i se folosete pentru
a realiza o implementare pentru interfaa org.apache.juddi.auth.Authenticator. Dac se
folosete o valoare nul, atunci AuthenticationFactory creeaz o implementare
implicit pentru Authenticator org.apache.juddi.auth.DefaultAuthenticator. Clasa DefaultAuthenticator nu aplic nici o restricie de acces, deci se permit toate cererile.
n general, sistemele construite pe baza jUDDI trebuie s ofere o implementare pentru interfaa Authenticator, care s realizeze procesul de autentificare
dorit. Clasa care implementeaz Authentication este nregistrat printr-o intrare a
fiierului de configurare juddi.properties.
Crearea regitrilor
Aplicaia jUDDI se instaleaz ca o aplicaie Web (fiier .ear sau .war) i, n
contextul dat de adresa http://gazd:port/juddi, se poate exploata oriunde exist
un server Web sau un motor de procesare a servlet-urilor (servlet engine).
Vom descrie n continuare paii care trebuie parcuri pentru instalare. Precizm faptul c, pentru ca instalarea s reueasc pe maina dumneavoastr
conform reetelor furnizate mai jos, trebuie s recurgei exact la versiunile de
aplicaii precizate. n cazul utilizrii altor versiuni, vor fi necesare eventual
configurri diferite.
174
SERVICII WEB
Preluai de pe Web serverul Apache Tomcat (versiunea 5.5). Dup ce l-ai

instalat, testai funcionarea lui la adresa http://localhost:8080.
Transferai apoi de pe situl Apache framework-ul jUDDI. Pentru exemplificrile
noastre am utilizat juddi.war, versiunea 0.7.0.
Prin intermediul Tomcat Web Application Manager, ncrcai juddi.war (a se vedea
figura urmtoare).
Figura 6. Interfaa Web a programului de management al serverului Tomcat
n caz de succes, vei obine un rezultat precum cel din captura-ecran de mai
jos.
Figura 7. Inserarea cu succes a framework-ului jUDDI
175
Pentru a stabili fiierul de jurnalizare corespunztor aplicaiei jUDDI, vom

edita log4j.properties (localizat, pentru Windows, n directorul c:\Tomcat5.5\webapps\
juddi \conf \), astfel nct s includ i linia:
log4j.appender.juddilog.File=C:/Tomcat5.5/logs/juddi.log
De asemenea, trebuie modificat i fiierul c:\Tomcat5.5\webapps\juddi\WEB-INF\

web.xml pentru a conine i urmtoarele:
<env-entry-name>
log4j.propsFile
</env-entry-name>
<env-entry-value>
C:\Tomcat5.5\webapps\juddi\conf\log4j.properties
</env-entry-value>
<env-entry-name>
juddi.propsFile
</env-entry-name>
<env-entry-value>
C:\Tomcat5.5\webapps\juddi\conf\juddi.properties
</env-entry-value>
Urmtorul pas este s instalai serverul MySQL (am lucrat cu versiunea

5.0.18). Transferai apoi instrumentul MySQL Control Center, care este un client
folosit pentru a crea i a interoga baza de date.
n acest moment, trebuie s crem baza de date folosit de jUDDI; va fi
numit juddi. Autentificarea la server se va realiza prin utilizatorul root cu
parola adria. ncrcai fiierul c:\Tomcat5.5\webapps\juddi\ddl\juddi_mysql.ddl
ntr-o fereastr SQL i executai comenzile SQL pe care le conine (a se urmri
figura de mai jos).
Pasul urmtor este executarea urmtoarei comenzi, care stabilete numele
entitii care va publica date n regitrii privai UDDI:
INSERT INTO PUBLISHER
(PUBLISHER_ID,PUBLISHER_NAME,ADMIN)
VALUES ('juddi', 'Juddi user', 'false');
176
SERVICII WEB
Figura 8. Execuia fiierului de comenzi SQL n vederea crerii tabelelor

ce urmeaz a fi folosite de jUDDI
Figura 9. Inserarea datelor privitoare la entitatea ce va publica date n regitrii privai
177
Mai trebuie s obinei de pe Internet driver-ul MySQL JDBC, astfel nct s

se poat accesa serverul MySQL. Preluai mysql-connector-java-3.0.17-stable-bin.jar i
copiai-l n directorul c:\Tomcat5.5\common\lib\.
Configurarea i folosirea aplicaiei jUDDI

Creai un fiier cu numele juddi.xml n cadrul directorului c:\Tomcat5.5\conf\Catalina\
localhost\. Drept coninut, introducei urmtoarele linii:
<Context path="/juddi" docBase="juddi" debug="5"
reloadable="true" crossContext="true">
<Resource name="jdbc/juddiDB" auth="Container"
type="javax.sql.DataSource"
initialSize="30" maxActive="100"
maxIdle="30" maxWait="10000"
username="root" password="adria"
driverClassName="com.mysql.jdbc.Driver"
removeAbandoned="true"
removeAbandonedTimeout="60"
logAbandoned="true"
url="jdbc:mysql://localhost:3306/juddi" />
</Context>
Astfel, am stabilit o serie de parametri referitori la conexiunea cu serverul de

baze de date via driver-ul mai sus menionat.
n cazul n care lucrai cu Tomcat versiunea 4.1.24, acest fiier are forma:
<Context path="/juddi" docBase="juddi" debug="5"
reloadable="true" crossContext="true">
<Logger
className="org.apache.catalina.logger.FileLogger"
prefix="localhost_juddiDB_log" suffix=".txt"
timestamp="true" />
<Resource name="jdbc/juddiDB"
auth="Container"
type="javax.sql.DataSource" />
<ResourceParams name="jdbc/juddiDB">
<parameter>
<name>factory</name>
<value>
org.apache.commons.dbcp.BasicDataSourceFactory
</value>
</parameter>
<parameter>
<name>maxActive</name>
<value>100</value>
178
SERVICII WEB
</parameter>
<parameter>
<name>maxIdle</name>
<value>30</value>
</parameter>
<parameter>
<name>maxWait</name>
<value>10000</value>
</parameter>
<parameter>
<name>username</name>
<value>root</value>
</parameter>
<parameter>
<name>password</name>
<value>adria</value>
</parameter>
<parameter>
<name>driverClassName</name>
<value>org.gjt.mm.mysql.Driver</value>
</parameter>
<parameter>
<name>url</name>
<value>
jdbc:mysql://localhost:3306/jUDDI?autoReconnect=true
</value>
</parameter>
</ResourceParams>
</Context>
Suntei n acest moment pregtii s rulai jUDDI.

Pentru a verifica modul de execuie a instrumentului jUDDI, pornii serverul
Web i introducei adresa http://localhost:8080/juddi/happyjuddi.jsp. Dac obinei
informaii similare celor din figura de mai jos, atunci din acest moment registrul
dumneavoastr UDDI este pregtit s recepioneze cereri.
Pachetul de instalare jUDDI include o serie de alte exemple utile pe care le
putei folosi pentru a trimite cereri registrului.
Folosind succesiunea de pai detaliat anterior, putei utiliza jUDDI pentru
crearea altor regitri privai UDDI, care s poat deservi cereri de publicare,
autentificare i interogare.
Nu ne rmne dect s v urm succes n exploatarea registrului UDDI propriu!
179
Figura 10. Mesajele de stare obinute n urma rulrii aplicaiei de diagnosticare jUDDI
2. WSIL (Web Service Inspection Language)

Iniiativa WSIL (Web Service Inspection Language) regsit i sub numele
WS-Inspection definete modul n care se poate descoperi o descriere XML a
unui serviciu Web aflat pe un server Web. Astfel, serviciile Web pot fi regsite
180
SERVICII WEB
facil. Via WSIL, un furnizor de servicii poate s-i fac disponibile serviciile
pentru a putea fi descoperite i utilizate de ctre consumatori.
Acest aspect este similar cu misiunea UDDI, dar WSIL se dorete a fi o etap
superioar UDDI n evoluia procesului de regsire a serviciilor Web.
Figura urmtoare ilustreaz noile relaii ce pot fi stabilite ntre consumatori,
furnizori i regitrii centralizai UDDI. Prima diferen se materializeaz n
faptul c o cerere de cutare a unui serviciu Web nu se realizeaz direct asupra
regitrilor centralizai UDDI. n schimb, cutarea este efectuat de ctre consumatori direct la furnizorul de servicii.
Conform acestui model, regitrii UDDI centralizai i nemoderai vor deveni
descentralizai i moderai. De observat, de asemenea, c nimeni nu mpiedic
furnizorii de servicii s-i nregistreze serviciile n cadrul regitrilor UDDI i s
redirecteze gsirea serviciului spre regitrii UDDI.
Figura 11. Furnizorii de servicii i fac serviciile cunoscute via WSIL
181
Trebuie s observm c WSIL nu reprezint un limbaj de descriere a serviciilor

Web, aceast responsabilitate avnd-o n continuare WSDL. Limbajul WSIL este
folosit doar pentru a face publice serviciile Web.
Elementele limbajului WSIL aparin spaiului de nume desemnat de adresa
http://schemas.xmlsoap.org/ws/2001/10/inspection/.
Documentul WSIL minimal const dintr-un element-rdcin service, care
conine un element description. Elementul service are rol de prezentare a serviciilor.
Documentele WSIL nu sunt folosite doar pentru descrierea serviciilor Web via
WSDL, astfel nct s poat fi utilizate i alte maniere de definire a serviciilor.
Specificaiile WSIL definesc o serie de convenii care s permit consumatorilor s localizeze documentele WSIL pe orice sit Web (vezi i figura 11).
Aceste convenii presupun existena unui nume prestabilit al documentului
WSIL i o manier de legtur la un document WSIL. Numele prestabilit este
inspection.wsil. Un document cu un astfel de nume ar trebui plasat n punctele de
intrare cele mai vizitate ale unui sit Web. De exemplu, dac un astfel de punct
este http://www.magazin-portocale.info/, atunci documentul WSIL ar trebui localizat
prin http://www.magazin-portocale.info/inspection.wsdl.
ns foarte puini furnizori ce recurg la WSIL vor oferi documentul WSIL la
acest nivel. Putem s ne gndim c aceste documente WSIL pot fi regsite destul
de uor cu ajutorul unor motoare de cutare precum Google sau Yahoo!.
Avnd scopul de a permite furnizorilor s-i organizeze serviciile ntr-o
manier ierarhic, documentele WSIL pot fi interconectate. Aceasta se realizeaz
prin prezena elementului link. Un document WSIL poate avea un numr orict
de mare de legturi, generndu-se astfel o ntreag reea de documente WSIL.
Drept exemplificare, vom oferi un fragment din documentul WSIL pus la
dispoziie de situl XMethods, document localizat la adresa http://www.xmethods.net/
inspection.wsil. Arborele asociat din figura 12 a fost generat cu ajutorul instrumentului oXygen XML Editor.
n ciuda prezenei regitrilor UDDI, se remarc existena unui gol (gap)
interpus ntre furnizorii de servicii i consumatori. Specificaia WSIL propus de
IBM i Microsoft ncearc s acopere acest gol, n timp ce UDDI se perfecioneaz i va deveni o soluie convenabil mai ales n contextul enterprise.
182
SERVICII WEB
Figura 12. Detalii privind un serviciu Web pus la dispoziie de XMethods

i descris prin WSIL
Referine
Booth, D. et al. (eds.), Web Services Architecture, W3C Working Draft, Boston, 2003:
http://www.w3.org/TR/ws-arch/
Cabrera, L.F., Kurt, C., Web Services Architecture and Its Specifications, Microsoft Press,
2005
Clement, L. et al. (eds.), UDDI Version 3.0, OASIS Open, 2004: http://uddi.org/pubs/
uddi_v3.htm
Tanas, ., Olaru, C., Dezvoltarea aplicaiilor Web folosind Java, Polirom, Iai, 2005
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*,
*,
*,
*,
*,
*,
*,
*,
*,
*,
*,
*,
*,
*,
IBMs UDDI Business Registry: http://www.uddi.ibm.com/

Instrumentul jUDDI: http://ws.apache.org/juddi/
Java Coffee-Break: http://www.javacoffeebreak.com/
Microsofts UDDI Business Registry: http://uddi.microsoft.com/
Serverul Apache: http://httpd.apache.org/
Situl dedicat dezvoltatorilor MySQL: http://dev.mysql.com/
Situl dedicat serverului Tomcat: http://jakarta.apache.org/tomcat/
Situl dedicat serviciilor Web: http://www.webservices.org/
Situl Sun privitor la Java: http://java.sun.com/
Situl XML SOAP: http://www.xmlsoap.org/
Source Forge: http://www.sourceforge.net/
UDDI (Universal Description, Discovery, and Integration): http://www.uddi.org/
WS-I (Web Services-Interoperability Organization): http://www.ws-i.org/
XMethods: http://www.xmethods.net/
183
Capitolul 6
Dezvoltarea i utilizarea serviciilor Web

Dac teoria mea nu corespunde faptelor, cu att
mai ru pentru fapte.
(Georg Wilhelm Friedrich Hegel)
1. Dezvoltarea i invocarea de servicii Web

folosind instrumente open source
1.1. Introducere
n majoritatea cazurilor, serviciile Web funcioneaz conform paradigmei client/
server: serverul ruleaz permanent, unul sau mai muli clieni trimit spre acesta
cereri SOAP printr-un protocol de transport (cel mai uzual, HTTP), iar serverul
ntoarce un rspuns.
n cazul serviciilor Web, standardele sunt eseniale pentru asigurarea inter-operabilitii. Aa cum s-a vzut n capitolele anterioare, codificarea coninutului
mesajelor vehiculate (cererea i rspunsul) prin SOAP adopt formatul XML, iar
descrierea serviciului Web se bazeaz pe limbajul WSDL. Eventual, pot fi ataate
opional date codificate n stilul base64, folosind propunerea SwA (SOAP with
Attachments), ori metoda standardizat, recomandat de Consoriul Web MTOM
(Message Transmission Optimization Mechanism). Mecanismul de ataare respect
bine-cunoscutele prevederi MIME (Multipurpose Internet Mail Extensions), larg
folosite n cazul mesajelor de pot electronic.
Trebuie s remarcm nc o dat c nu exist nici o restricie n alegerea
limbajului de programare n care se vor implementa serviciul Web i posibilii lui
clieni (programe desktop, aplicaii Web, alte servicii Web etc.). Indiferent ce
limbaj, instrument, platform sunt folosite, n esen dezvoltarea i utilizarea
serviciilor Web prezint aceleai caracteristici i adopt abloane de proiectare
similare.
Unele instrumente SOAP implementeaz propriul server Web, folosind HTTP
(de exemplu, SOAP::Lite sau Microsoft Visual Web Developer). Altele, precum
186
SERVICII WEB
extensia Soap pentru PHP sau biblioteca gSOAP, presupun instalarea n cadrul
unui server Web particular, astfel nct daemon-ul HTTP va manevra mesajele
SOAP spre o component proxy, care realizeaz invocarea serviciului Web n
manier transparent pentru programator. O serie de instrumente SOAP suport
un mecanism de transport configurabil care pemite selecia, la nivel de aplicaie,
a protocolului de transport. Modulul SOAP::Lite, de pild, ofer suport pentru
HTTP, FTP, SMTP sau Jabber.
Instrumentele SOAP furnizeaz o component proxy, menit a procesa i
interpreta mesajul SOAP n vederea invocrii codului aplicaiei. Aceast
component trebuie s aib n responsabilitate recunoaterea stilului de codificare, translatarea datelor din format nativ de exemplu obiecte Java sau
.NET n XML (i invers), procesarea antetului din mesajul SOAP cu atributul
mustUnderstand="true" etc. Atunci cnd o component proxy manevreaz un
mesaj SOAP, va trebui s efectueze urmtoarele:
deserializarea mesajului, dac este necesar, din format XML ntr-o form
adecvat pentru a-l putea analiza;
invocarea codului (a metodelor);
serializarea rspunsului primit n XML i manevrarea lui n scopul trimiterii
acestuia la emitor.
n ciuda diferenelor de implementare, instrumentele pentru dezvoltarea de
servicii Web prin SOAP urmeaz acelai model.
n cadrul acestui subcapitol ne propunem s detaliem modul de implementare
i de invocare a unor servicii Web pe baza uneltelor open source existente pentru
PHP i Perl. Pentru nceput, vom construi un server i un client SOAP simplu
n PHP, utiliznd extensia Soap disponibil n versiunea 5 a acestui server de
aplicaii i, ca alternativ, biblioteca NuSOAP care poate fi folosit i n PHP 4.
n partea a doua a acestui subcapitol ne propunem s scriem un serviciu Web
oferind o interfa comod pentru operaiile uzuale realizate asupra resurselor
unui sistem de fiiere aflat de distan. Pentru aceasta, vom recurge la modulul
SOAP::Lite, unul dintre cele mai cunoscute instrumente de dezvoltare n limbajul
Perl a serviciilor Web i a clienilor afereni acestora.
1.2. Furnizarea stocurilor de portocale via

un serviciu Web scris n PHP 5
Misiunea pe care o avem de realizat este uor de ndeplinit. Trebuie s implementm un server SOAP care va oferi accesul la un serviciu Web, incluznd o
singur metod furnizeazaCantit(). Aceasta va avea ca parametru de intrare un
DEZVOLTAREA I UTILIZAREA SERVICIILOR WEB
187
ir de caractere desemnnd un sortiment de portocale i va returna cantitatea

existent, dac acel sortiment exist. Nu vom furniza o descriere WSDL asociat
serviciului, invocarea putndu-se realiza explicit, dup cum vom vedea mai jos.
Codul-surs al acestui serviciu simplu este dat n continuare:
<?php
try {
// nu oferim nici o descriere WSDL,
// stabilim URI-ul serviciului
$server = new SoapServer(null,
array('uri' => 'urn:portocale.info'));
// adugm metodele implementate
$server->addFunction('furnizeazaCantit');
// ateptm cereri SOAP
$server->handle();
} catch (SOAPFault $exception) {
echo 'A aprut o excepie: ' . $exception;
}
// funcie care furnizeaz cantitatea
// dintr-un sortiment de portocale
function furnizeazaCantit ($numeSortiment) {
// de obicei, aici vom efectua o interogare SQL
// ori una XQuery
switch ($numeSortiment) {
case 'japoneze': return 33;
case 'albastre': return 74;
default
: return 'inexistent';
}
}
?>
Primul argument al constructorului desemneaz adresa (URL-ul) documentului

WSDL ce descrie serviciul, n acest caz fiind null. Spaiul de nume prin care e
identificat serviciul dezvoltat este dat n situaia de fa de un URN urn:portocale.info.
Fiecare funcie implementat va fi adugat cu addFunction(). De asemenea, unui
serviciu i se poate asocia o clas prin intermediul metodei setClass(). Cererile
SOAP vor fi rezolvate via handle(), care va avea n responsabilitate i (de)serializarea datelor.
Deoarece extensia Soap este inclus n distribuia standard PHP 5, pentru
rularea programului de mai sus nu va trebui instalat nimic suplimentar. n
exemplificrile de fa am recurs la PHP versiunea 5.0.4 sub diverse versiuni ale
serverului Apache 2.0.
188
SERVICII WEB
1.3. Un client PHP pentru serviciul Web

privitor la portocale
Recurgnd tot la extensia Soap, vom concepe un client care va invoca metoda
expus de serviciul Web pentru o serie de sortimente de portocale. Liniile de cod
PHP sunt urmtoarele:
try {
$client = new SoapClient(null,
array('location' => 'http://localhost/sxml/
oranges-server.php',
'uri'
=> 'urn:portocale.info'));
// realizm o suit de invocri ale metodei dorite
foreach (array('albastre', 'japoneze', 'celeste')
as $sortiment) {
$rez = $client->__call('furnizeazaCantit',
array($sortiment));
echo "<p>Stocul de portocale $sortiment
este <strong>$rez</strong>.</p>";
}
echo 'A aprut o excepie: ' .
$exception->faultstring;
}
Deoarece nu avem la dispoziie descrierea WSDL a serviciului, vom folosi

__call() pentru invocarea metodei furnizeazaCantit(). Excepiile ce pot surveni
sunt capturate graie construciei try catch incluse n PHP 5. Obiectul SOAPFault
ncapsuleaz informaiile privitoare la un fault SOAP; n cazul de fa am utilizat
proprietatea faultstring pentru a afia mesajul de excepie. Euarea unui apel
SOAP poate fi verificat i cu is_soap_fault(). Mesajele vehiculate vor respecta n
mod implicit versiunea 1.1 a protocolului SOAP. Extensia Soap ofer posibilitatea
de a recurge ns i la SOAP 1.2.
n urma iteraiilor realizate, vom obine un rezultat precum cel din figura 1.
Tipul rspunsului primit este unul eterogen (fie ntreg, fie string), n funcie
de existena sortimentului de portocale pentru care realizm invocarea
metodei.
189
Figura 1. Invocarea serviciului Web implementat n PHP 5
1.4. Un serviciu de manipulare a fiierelor implementat

n Perl cu SOAP::Lite
Ne propunem n continuare s implementm un server SOAP, disponibil la
portul 3333 via protocolul HTTP, care va ncapsula funcionalitile unui serviciu
Web, oferind diverse operaii asupra fiierelor existente pe server. Drept exemplificare, vom scrie urmtoarele metode:
List, care furnizeaz lista fiierelor existente la nivel de server; nu necesit
parametri de intrare i ntoarce o structur de forma <file name="..." />
pentru fiecare fiier gsit (vezi infra);
CheckIfExists, ce verific existena unui fiier la nivel de server, avnd ca
parametru de intrare un ir de caractere desemnnd un nume de fiier; va
ntoarce valoarea 1 dac fiierul exist i 0 dac e inaccesibil (nu poate fi
regsit ori nu exist suficiente drepturi de acces asupra lui);
Rename, care redenumete un fiier, necesitnd doi parametri (numele vechi i
cel nou) de tip ir de caractere; va ntoarce un ir de caractere: success n caz
de succes i error n caz contrar.
Codul-surs al programului Perl este urmtorul:
#!/usr/bin/perl -w
use strict;
use SOAP::Transport::HTTP +debug => [qw(all)];
# nu dorim s fim ntrerupi de semnale
# precum 'Broken pipe' ori la acionarea
190
SERVICII WEB
# combinaiei de taste CTRL+C

$SIG{PIPE} = $SIG{INT} = 'IGNORE';
# iniializm serverul, folosind un daemon HTTP
my $server = SOAP::Transport::HTTP::Daemon->new (
LocalAddr => 'localhost',
# adresa local
LocalPort => 3333,
# portul utilizat
Reuse
=> 1);
# reutilizm portul
# funcionalitatea serverului este furnizat
# de clasa 'XMLFiles'
$server->dispatch_to ('XMLFiles');
print 'Serverul SOAP ruleaz la ' . $server->url;
# ne blocm, ateptnd cereri din partea clienilor
$server->handle;
# clasa implementnd funcionalit. serviciului Web
BEGIN {
package XMLFiles;
use SOAP::Lite;
use base qw(SOAP::Server::Parameters);
sub List {
# metoda de generare a listei

# fiierelor existente pe server
my $self = shift;
my $envelope = pop;
my $files = '';
# returnm rspunsul drept frag. de doc. XML
foreach my $file (glob('*')) {
$files .= "<file name=\"$file\" />";
}
return SOAP::Data->type('xml' => $files);
sub CheckIfExists { # metoda de verificare

# a existenei unui fiier
my $self = shift;
my $envelope = pop;
# prelum param. de intrare via o expresie XPath
# (nu tim cum ar putea fi ncapsulat)
my $filename = $envelope->dataof('//filename');
# trimitem un 'fault'
# dac nu exist parametrul de intrare
die SOAP::Fault->faultcode('Server.CheckIfExists')
->faultstring(
'Input parameter is missing')
unless $filename;
191
# furnizm fiierul n cauz, dac exist

return (-e $filename->value) ? 1 : 0;
sub Rename { # metoda de redenumire a unui fiier

my $self = shift;
my $envelope = pop;
# prelum parametrii de intrare
my $filename = $envelope->dataof('//filename');
my $newname = $envelope->dataof('//newname');
# eventual, semnalm inexistena lor
die SOAP::Fault->faultcode('Server.Rename')
->faultstring(
'Input filename parameter is missing')
unless $filename;
die SOAP::Fault->faultcode('Server.Rename')
->faultstring(
'Input newname parameter is missing')
unless $newname;
# returnm rspunsul
return SOAP::Data->name('result' =>
(rename ($filename->value, $newname->value) ?
'success' : 'error'));
}
# eventual, alte metode...
}
Serverul va rula la infinit, ocupnd portul 3333 al mainii locale (vezi figura 2).
Va pune la dispoziie via SOAP 1.1 peste HTTP cele trei metode descrise mai
sus. Pentru fiecare metod n parte, prelum parametrii necesari. n cazul n care
acetia nu sunt furnizai de client, se va ntoarce un mesaj de tip fault SOAP,
semnalndu-se o situaie de excepie. Am dorit ca rspunsul oferit s fie de mai
multe tipuri de date (ntreg, ir de caractere sau o list de fiiere marcat n
XML), pentru a se putea observa diferenele de codificare.
Modulul SOAP::Perl apare n majoritatea distribuiilor Perl actuale. Versiunile
utilizate pentru testarea i rularea exemplelor din aceast carte au fost 0.65 i
0.68. n cazul n care modulul este indisponibil, poate fi preluat din CPAN
(Comprehensive Perl Archive Network) accesibil la http://search.cpan.org/ i instalat
conform urmtorilor pai:
(infoiasi)$
(infoiasi)$
(infoiasi)$
(infoiasi)$
perl Makefile.PL
make
make test
make install
192
SERVICII WEB
Figura 2. Rularea serverului SOAP ntr-o fereastr a unei console KDE
Pentru a putea realiza transferuri SOAP cu fiiere ataate (SOAP with

Attachments) va trebui s recurgem la modulul SOAP::MIME, care mbuntete
o serie de aspecte ale SOAP::Lite. Mai trebuie remarcat faptul c modulul
SOAP::Lite nu ofer suport pentru generarea automat de descrieri WSDL
corespunztoare serviciilor Web implementate.
Pentru alte detalii privitoare la folosirea sesiunilor n cadrul serviciilor Web,
a invocrii unor servicii externe i a utilizrii unor metode de autentificare n
cadrul serviciilor Web dezvoltate, cititorii interesai pot consulta documentaiile
i exemplele incluse n arhiva de instalare a modulului SOAP::Lite.
1.5. Scrierea n Perl a clientului SOAP

n acest moment putem scrie un client Perl simplu care s invoce metodele
serviciului Web implementat. Vom realiza o interaciune de baz cu utilizatorul,
la nivelul liniei de comand (prompt-ul interpretorului de comenzi, de obicei bash
n Linux). Codul-surs al programului-client e furnizat mai jos:
#!/usr/bin/perl -w
# folosim modulul SOAP::Lite cu opiunea de depanare
use SOAP::Lite +debug => [qw(all)];
if (scalar(@ARGV) < 1) {
print "Client de accesare a metodelor oferite de un
serviciu Web\npentru accesarea sistemului de fiiere de pe
server.\n";
print "Sintaxa: $0 <fiier_existent_pe_server>\n";
exit(1);
}
193
# ne conectm la server
my $soap = SOAP::Lite
->uri('http://127.0.0.1:3333/XMLFiles/')
# adresa spaiului de nume
->proxy(
'http://127.0.0.1:3333/XMLFiles/xml-files.pl');
# locaia serviciului
# mpachetm explicit parametrii,
# folosind nume calificate
# pentru parametrii metodei invocate
my @params = (SOAP::Data->name('filename', $ARGV[0]));
# verificm dac fiierul exist pe server
$response = $soap->call('CheckIfExists' => @params);
# verificm dac a aprut o eroare (SOAP fault)
if ($response->fault) {
die 'A aprut o eroare: ' .
$response->faultstring;
}
# dac rezultatul primit e nul, fiierul nu exist
if (!$response->result) {
die 'Fiier inaccesibil (nu exist pe server?)';
}
# invocm metoda de redenumire a fiierului
# adugnd i numele cel nou al acestuia
push (@params, SOAP::Data->name('newname',
$ARGV[0] . '.renamed'));
# afim rezultatul execuiei metodei
print 'Redenumire realizat cu ' .
$soap->call('Rename' => @params)->result;
Programul va verifica existena unui fiier al crui nume este furnizat de

utilizator n linia de comand, va ncerca s-l redenumeasc (numele vechi va fi
sufixat cu .renamed), apoi va afia lista fiierelor existente pe server (putem
verifica astfel dac redenumirea s-a efectuat).
n urma execuiei acestui script, vom putea obine un rezultat asemntor cu
urmtorul (presupunem c pe server exist fiierul denumit portocale.txt):
(infoiasi)$ perl xml-files-client.pl portocale.txt
Fisierul exista.
Redenumire realizata cu succes.
Fisierele existente pe server:
194
SERVICII WEB
portocale.txt.renamed
xml-files.pl
xml-files.pl~
Prima cerere efectuat de programul-client este ncapsulat ntr-un mesaj

HTTP de forma de mai jos, n care se pot observa cmpurile-antet HTTP, tipul
coninutului (fiier XML) i corpul mesajului SOAP (reprezint invocarea metodei
CheckIfExists cu parametrul corespunztor furnizat tot sub forma de marcaje
XML):
POST http://127.0.0.1:3333/XMLFiles/xml-files.pl HTTP/1.1
Accept: text/xml
Accept: multipart/*
Accept: application/soap
Content-Length: 517
Content-Type: text/xml; charset=utf-8
SOAPAction:
"http://127.0.0.1:3333/XMLFiles/#CheckIfExists"
<soap:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:soapenc=
soap:encodingStyle=
xmlns:soap=
"http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<namesp1:CheckIfExists
xmlns:namesp1="http://127.0.0.1:3333/XMLFiles/">
<filename xsi:type="xsd:string">
portocale.txt
</filename>
</namesp1:CheckIfExists>
</soap:Body>
</soap:Envelope>
Rspunsul oferit de server este:

HTTP/1.1 200 OK
Date: Fri, 04 Aug 2006 18:25:51 GMT
Server: libwww-perl-daemon/1.36
Content-Length: 523
Client-Date: Fri, 04 Aug 2006 18:25:51 GMT
195
Client-Peer: 127.0.0.1:3333
Client-Response-Num: 1
SOAPServer: SOAP::Lite/Perl/0.65_5
<soap:Envelope
xmlns:soapenc=
soap:encodingStyle=
xmlns:soap=
<soap:Body>
<namesp9:CheckIfExistsResponse
<s-gensym27 xsi:type="xsd:int">1</s-gensym27>
</namesp9:CheckIfExistsResponse>
</soap:Body>
</soap:Envelope>
Se poate remarca faptul c valoarea rspunsului furnizat (ntregul 1) este

ncapsulat n marcatorii XML din cadrul corpului plicului SOAP ce mpacheteaz
informaiile vehiculate ntre serviciu i clienii si.
Lucrurile decurg similar pentru a doua cerere corespunztoare invocrii
metodei Rename i rspunsul aferent.
Pentru a treia cerere, de invocare a metodei List, nu exist argumente de
intrare, n cadrul corpului plicului SOAP aprnd doar:
<namesp3:List xsi:nil="true"
xmlns:namesp3="http://127.0.0.1:3333/XMLFiles/" />
Rezultatul metodei reprezint o structur XML de genul:

<namesp4:ListResponse
<file name="portocale.txt.renamed" />
<file name="xml-files.pl" />
</namesp4:ListResponse>
Spaiile de nume de forma namespN sunt generate n mod automat de ctre

SOAP::Lite pentru a indica apartenena fiecrui element XML din cadrul mesajului SOAP vehiculat.
196
SERVICII WEB
n cazul n care clientul nu furnizeaz numele parametrului corect (de

exemplu, n loc de filename se trimite file pentru metoda CheckIfExists), se va
obine un mesaj de tip fault SOAP emis de serviciu (codul entitii emitente, irul
explicativ i adresa entitii care a cauzat excepia):
...
<soap:Body>
<soap:Fault>
<faultcode>
soap:Server.CheckIfExists
</faultcode>
<faultstring>
Input parameter is missing
</faultstring>
<faultactor>
http://127.0.0.1:3333/
</faultactor>
</soap:Fault>
</soap:Body>
...
1.6. Invocarea serviciului de ctre un client PHP

Am dori ca serviciul s poat fi invocat de o aplicaie Web, astfel nct
interaciunea cu utilizatorul s poat fi realizat prin intermediul unui browser
Web. Aceasta o vom realiza scriind un client PHP, inter-operabilitatea avnd loc
fr probleme, din moment ce mesajele sunt vehiculate via XML, indiferent de
platform. Programul PHP recurge la biblioteca NuSOAP (versiunea 0.6.5) i are
urmtorul cod-surs:
<?php
require_once('lib/nusoap.php'); # utilizm NuSOAP
// instanierea unui client SOAP
// pe baza descrierii serviciului Web
$client = new soapclient(
'http://endirra.ro:3333/xml-files.pl');
// prelum posibilele erori
$err = $client->getError();
if ($err) {
// semnalm eroarea
echo '<h3>Eroare de iniializare</h3><pre>'
. $err . '</pre>';
}
// stabilim parametrii de intrare ai metodei invocate
197
$param = array('filename' => 'xml-files.pl');

# exist cu siguran
# de ncercat cu un fiier inexistent:
# $param = array('filename' => 'inexistent.xml');
// stabilim spaiul de nume folosit
$namespace = 'http://127.0.0.1:3333/XMLFiles/';
// realizm apelul
$result = $client->call('CheckIfExists',
array('parameters' => $param), $namespace, '', true);
// verificm dac exist vreun fault
if ($client->fault) {
echo '<h3>Fault</h3><pre>';
print_r($result);
echo '</pre>';
} else { // verificm dac sunt erori
if ($err) {
echo '<h3>Eroare</h3><pre>' . $err . '</pre>';
} else {
// afim rezultatul
echo '<h3>Rezultat</h3>';
echo '<p>Fiierul ' . ($result ?
'exist' : 'e inaccesibil') . '.</p>';
}
}
// cererea, rspunsul i informaiile de depanare
echo '<h3>Cerere</h3><pre>' .
htmlspecialchars($client->request, ENT_QUOTES) .
'</pre>';
echo '<h3>Rspuns</h3><pre>' .
htmlspecialchars($client->response, ENT_QUOTES) .
'</pre>';
echo '<h3>Depanare</h3><pre>' .
htmlspecialchars($client->debug_str, ENT_QUOTES) .
'</pre>';
?>
Dup cum se poate remarca, se instaniaz un obiect $client al clasei soapclient()

pus la dispoziie de biblioteca mai sus menionat. Constructorul necesit
adresa Web a serviciului dorit a fi invocat. Posibilele erori survenite pot fi
captate cu metoda getError(), iar fault-urile SOAP via proprietatea fault.
n acest caz am invocat doar metoda de verificare a existenei unui fiier,
recurgnd la metoda call(). Convenia este ca parametrii transmii s fie ncapsulai
ntr-un tablou (array).
198
SERVICII WEB
Un posibil rezultat este ilustrat de figura 3, n care se remarc i afiarea

cererii, a rspunsului i a informaiilor privitoare la depanare, direct n programul
de navigare Web. Programul-client PHP i serverul SOAP scris n Perl au fost
testate pe platformele Linux i Windows. Navigatorul Mozilla Firefox care
realizeaz invocarea script-ului PHP ruleaz n Windows.
Figura 3. Rezultatele execuiei programelor PHP ce invoc metodele CheckIfExists

i List ale serviciului Web implementat n Perl
(au fost folosite navigatoarele Mozilla Firefox i Opera)
n cazul invocrii metodei List, care ntoarce drept rezultat un fragment de

document XML, vom procesa datele obinute prin intermediul extensiei Simple
199
XML (disponibil n PHP versiunea 5). Liniile de cod prezentnd interes n acest
context sunt urmtoarele:
// realizm apelul
$result = $client->call('List', undefined,
$namespace, '', true);
if ($err) {
echo '<h3>Eroare</h3><pre>' . $err . '</pre>';
} else {
// afim lista de fiiere
echo '<h3>Fiierele existente pe server</h3><ul>';
// procesm rspunsul SOAP via Simple XML
$xml = simplexml_load_string ($client->responseData);
foreach ($xml->xpath("//file") as $file) {
// afim fiecare nume de fiier
echo '<li>' . $file['name'] . '</li>';
}
echo '</ul>';
}
Rezultatul obinut este ilustrat tot de figura 3.
2. Inter-operabilitatea ntre diverse tehnologii,

instrumente i limbaje de programare a serviciilor Web
2.1. Dezvoltarea de servicii Web n .NET Framework
n cadrul platformei .NET, un serviciu Web este considerat ca fiind un tip
specific de assembly (form atomic a unui modul de cod), tratat ntr-o manier
special de ctre mediu. Serviciile Web sunt coninute de fiiere cu extensia
.asmx. Serverul Web Microsoft IIS (Internet Information Services) recunoate fiierele
.asmx ca fiind servicii Web i n mod automat export funciile assembly-ului
refereniat.
Procesul de dezvoltare i exploatare a unui serviciu Web n .NET este
(relativ) simplu: se scrie codul-surs, se salveaz ntr-un fiier .asmx, se export
respectivul fiier ntr-un director virtual al serverului IIS i se invoc respectivul
serviciu via un client.
200
SERVICII WEB
Un serviciu Web simplu implementat n C#

S ncepem cu un serviciu Web extrem de simplu. Conform tradiiei, primul
program scris trebuie s fie unul care afieaz Salut, lume! (Hello, world!).
Vom scrie un serviciu care s furnizeze mesajul Bun X, unde X reprezint un
ir de caractere introdus de utilizator (printr-un anumit client, desigur). Putem
recurge la orice editor de texte favorit pentru a crea fiierul de cod C# cu
numele salutari.asmx.
Liniile programului nostru sunt urmtoarele:
<%@ WebService Language="C#" Class="Hello" %>
using System.Web.Services;
[WebService(Namespace="urn:Hello")]
public class Hello {
[WebMethod]
public string sayHello (string nume)
return "Buna " + nume;
}
}
Linia <%@ WebService Language=C# Class=Hello %> este o directiv care

indic mediului .NET s exporte un serviciu Web, scris n limbajul C# i
implementat de clasa cu numele Hello.
Linia using (n acest caz, using System.Web.Services) realizeaz includerea assembly-urilor
necesare (n cazul nostru, a claselor privitoare la serviciile Web).
Linia [WebService(Namespace=urn:Hello)] este opional, dar ne permite s
specificm diferite atribute ataate serviciului Web dezvoltat. n acest caz, am
stabilit un spaiu de nume explicit (altfel .NET l-ar fi ales pe cel implicit,
desemnat de http://tempuri.org/).
[WebMethod] definete faptul c metoda clasei Hello face parte din cadrul
serviciului Web, fiind disponibil posibililor clieni. De asemenea, pot fi
specificate anumite proprietai legate de operaiile pe care le realizeaz
serviciul.
Dup ce am creat un astfel de fiier, atunci cnd el este solicitat de un client
via o cerere SOAP transportat prin HTTP, modulul .NET runtime va compila
codul serviciului (dac nu a fcut-o deja), pentru a se putea invoca una dintre
metodele dorite ale serviciului.
n fapt, .NET permite realizarea mai multor tipuri de cereri:
cereri privitoare la interfaa serviciului (ceea ce ofer acesta), generndu-se
automat o descriere WSDL a acestuia;
201
cereri care se intereseaz n mod explicit de o metod furnizat de serviciul

n cauz;
cereri de invocare a unei operaii (metode) furnizate de serviciul Web (via
SOAP 1.1 sau SOAP 2.0).
Fiierul salutari.asmx va fi mutat n directorul public al serverului Web
(pentru IIS, n mod implicit este c:\inetpub\wwwroot\), iar invocarea se va
realiza via URI-ul http://localhost/salutari.asmx (am presupus c IIS ruleaz pe
maina local la portul 80). Un rezultat posibil e cel ilustrat de captura-ecran
urmtoare:
Figura 4. Interfaa Web de interaciune cu serviciul Web via

programul de navigare
Dnd clic pe sayHello, vom putea parcurge o descriere detaliat privitoare la

maniera de invocarea a metodei sayHello folosind cereri SOAP 1.1, SOAP 1.2 sau
POST (vezi figura 5).
202
SERVICII WEB
Figura 5. Furnizarea informaiilor privitoare la forma cererii SOAP de invocare

a metodei serviciului Web
Pentru a testa funcionalitatea serviciul Web creat, introducem un nume n

formularul Web disponibil n cadrul paginii i apsm butonul Invoke.
203
Figura 6. Invocarea metodei sayHello
n urma rulrii codului, vom obine un rezultat precum cel din figura de mai
jos (rspunsul ntors este un document XML, aa cum era i de ateptat):
Figura 7. Rezultatul obinut dup execuia metodei invocate
n cele ce urmeaz, vom implementa un client simplu care s invoce serviciul

Web de mai sus din cadrul unui program C# interactiv. Fragmentul de cod care
se ocup cu invocarea propriu-zis este urmtorul:
using
using
using
using
using
System;
System.Diagnostics;
System.Xml.Serialization;
System.Web.Services;
System.Web.Services.Protocols;
namespace Salutari {
[System.Web.Services.WebServiceBindingAttribute(
Name="HelloSoap", Namespace="urn:Hello")]
public class ClientSalut :
System.Web.Services.Protocols.SoapHttpClientProtocol
{
public ClientSalut () { // constructor
// stabilim adresa serviciului Web
204
SERVICII WEB
this.Url="http://localhost/salutari.asmx";
[System.Web.Services.Protocols.
SoapDocumentMethodAttribute("urn:Hello/sayHello",
RequestNamespace="urn:Hello",
ResponseNamespace="urn:Hello",
Use=System.Web.Services.Description.
SoapBindingUse.Literal,
ParameterStyle=
System.Web.Services.Protocols.
SoapParameterStyle.Wrapped)]
public string sayHello (string nume) {
// rezultatul obinut (tablou de obiecte)
// n urma invocrii metodei serviciului Web
object[] rezult =
this.Invoke ("sayHello", new object[]{nume});
// ntoarcem primul element
return ((string)(rezult [0]));
}
}
}
Construcia [System.Web.Services.WebServiceBindingAttribute] stabilete la compilare ca assembly-ul rezultat s fie folosit pentru a invoca un serviciu Web. Cnd
acest assembly este compilat, .NET pune la dispoziie un mecanism intern
facilitnd funcionarea cererilor SOAP.
Linia System.Web.Services.Protocols.SoapHttpClientProtocol specific protocolul care
se dorete a fi utilizat (n acest caz, SOAP peste HTTP).
n cadrul clasei s-a mai creat un proxy pentru operaia sayHello i s-au
specificat diferite atribute privitoare la serviciul Web invocat. Detalii sunt
disponibile n cadrul documentaiilor ce nsoesc .NET Framework.
Programul-client recurge la Windows Forms i la rulare, n cazul unei compilri
cu succes, va afia o fereastr n care se solicit utilizatorului s introduc un
nume. n urma apsrii butonului Invoke, vom obine un rezultat precum cel din
figura 8.
Cnd a fost apsat butonul Invoke, s-a produs un eveniment tratat ntr-o
metod implementat de client. n cadrul acestei metode se apeleaz sayHello din
clasa proxy care invoc respectiva operaie de pe server, returnndu-se rezultatul
de mai sus.
205
Figura 8. Rezultatul invocrii serviciului Web

dintr-un client interactiv
Invocarea de servicii Web dezvoltate n C# de ctre clieni concepui

n alte limbaje de programare
Ne propunem n continuare s demonstrm inter-operabilitatea ntre serviciile
Web create sub Windows folosind mediul .NET Framework i diveri clieni
implementai n C#, Perl i PHP, rulnd n Linux i/sau Windows.
Pentru nceput vom dezvolta n C# un serviciu Web folosit pentru validarea,
conform unei scheme XML, a documentelor XML existente pe server.
Editarea codului-surs i exploatarea serviciului se vor realiza prin intermediul
aplicaiei, disponibile gratuit, WebMatrix. Exist dou variante, una pentru
versiunea 1.1 i cealalt pentru 2.0. WebMatrix include i un miniserver Web,
permind verificarea funcionalitii serviciilor dezvoltate. De asemenea, se
poate utiliza Microsoft Visual Web Developer Express mediu de dezvoltare disponibil, de asemenea, gratuit (vezi figura 9).
Serviciul va expune dou metode:
CheckIfExists verific existena documentului XML dorit a fi validat;
Validate realizeaz validarea propriu-zis.
206
SERVICII WEB
Figura 9. Crearea unui serviciu Web via ablonul

oferit de Microsoft Visual Web Developer Express
Aceste metode sunt implementate n cadrul clasei purtnd numele

XMLValidator. Aceast soluie de implementare a fost realizat pentru .NET
Framework 1.1; n versiunea 2.0, n loc de XMLValidatingReader (considerat demodat) se va recurge la XMLReader. Lsm cititorul s realizeze aceasta ca exerciiu.
<%@ WebService language="C#" class="XMLValidator" %>
using System;
using System.Xml;
using System.Xml.Serialization;
using System.Xml.Schema;
using System.IO;
// clasa care implementeaz serviciul Web
[WebService(Namespace=
"http://www.infoiasi.ro/XMLValidator")]
public class XMLValidator {

static private int validationMessages;
static private string result;
// folosim explicit 'SOAP RPC encoding',
// pentru fiecare metod
[SoapRpcMethod]
// metoda Web care verific exist. unui fiier XML
[WebMethod]
public bool CheckIfExists (string filename) {
return File.Exists (filename);
}
// metoda Web de validare a unui fiier XML
[SoapRpcMethod]
[WebMethod]
public string Validate (string filename) {
// cititorul i validatorul de documente XML
XmlTextReader tr = null;
XmlValidatingReader vr = null;
// iniial, nici o eroare
validationMessages = 0;
result = "";
// ncercm s procesam documentul XML
try {
// instaniem cititorul de coninut XML
tr = new XmlTextReader (filename);
// instaniem validatorul XML
vr = new XmlValidatingReader (tr);
// tipul implicit de validare
// folosete XML Schema
vr.ValidationType = ValidationType.Schema;
// setm o metod de semnalare a evenimentelor
// generate de validatorul XML
vr.ValidationEventHandler +=
new ValidationEventHandler (ValidationHandler);
while ( vr.Read () )
; // nu facem nimic, doar citim documentul XML
} // final de "try"
catch ( Exception e ) {
// returnm mesajul de excepie
return result + e.Message;
}
finally {
if ( tr != null )
tr.Close ();
if ( vr != null )
vr.Close ();
}
207
208
SERVICII WEB
// ntoarcem succes sau numrul de erori

return (validationMessages == 0 ?
"valid" : "invalid (" +
validationMessages + ")");
}
// metod de tratare a erorilor de validare
private static void ValidationHandler (
object sender, ValidationEventArgs args) {
result += args.Severity +
"(" + args.Message + "). ";
validationMessages++;
}
Maniera de editare i compilare a codului C# este ilustrat n figura de mai jos.
Figura 10. Construirea i depanarea codului serviciului Web n cadrul mediului de dezvoltare
Microsoft Visual Web Developer Express
209
Mediul .NET pune la dispoziie i o modalitate de generare a descrierii

serviciului Web implementat, adic de accesare a reprezentrii WSDL asociate.
Astfel, putem inspecta comod cu ajutorul unui instrument precum WSDL
SOAP Analyser, integrat n deja cunoscutul editor oXygen, menionat anterior n
cadrul crii de fa informaiile privitoare la metodele i signaturile acestora (a
se vedea figura 11).
Figura 11. Obinerea informaiilor privitoare la metodele expuse

de un serviciu Web
Rularea serviciului Web implementat n .NET poate fi realizat att n cadrul

unui server Web precum IIS, ct i n serverul Web oferit de mediul de dezvoltare.
210
SERVICII WEB
Alte exemple privind dezvoltarea de servicii Web sub platforma .NET sunt
disponibile i n volumul lui Sabin Buraga (coord.), Situri Web la cheie. Soluii
profesionale de implementare, Polirom, Iai, 2004.
2.2. Un client C# pentru serviciul creat

O implementare C# minimal a unui client disponibil n linie de comand,
avnd rolul de invocare a serviciului Web descris mai sus, este urmtoarea:
using System;
class XMLValidatorClient {
public static void Main(string[] args) {
if (args.Length == 0) {
Console.WriteLine("Sintaxa:
xml-validator-client <document.xml>");
return;
}
try {
Console.Write("Documentul '{0}' este... ",
args[0]);
// crem o instan a clasei corespunztoare
// serviciului Web
XMLValidator validator = new XMLValidator();
// invocm metoda de verificare a existenei

// fiierului la nivel de server
if (validator.CheckIfExists(args[0])) {
// exist, deci putem realiza validarea
string valid = validator.Validate(args[0]);
// afim ceea ce a ntors metoda invocat
Console.WriteLine(valid + ".");
}
else
Console.WriteLine(
"inaccesibil (nu exist pe server?).");
} // final de 'try'
catch (Exception e) {
// a aprut o excepie
Console.WriteLine("\nExceptie: " + e.Message);
return;
}
Numele fiierului XML dorit a fi validat este preluat de la linia de comand,

fiind regsit n irul de caractere args[0].
211
Pentru ca programul s funcioneze, va trebui generat o clas intermediar

(proxy), avnd rol de facilitare a dialogului dintre maina local i serverul pe care
va fi rulat serviciul Web. Aceasta se realizeaz prin comanda urmtoare, avnd
ca rezultat generarea unui fiier cu numele XMLValidator.cs, pe baza descrierii
WSDL a serviciul dezvoltat:
"c:\Program Files\Microsoft.NET\SDK\v1.1\Bin\wsdl.exe"
http://localhost:8080/xml-validator.asmx?WSDL
Calea spre programul wsdl.exe (pus la dispoziie de .NET Framework) poate

diferi, trebuind s fie ajustat n funcie de situaia concret. Pentru versiunea
.NET 2.0, se nlocuiete v1.1 cu v2.0. n cazul nostru, am presupus c
serviciul Web va putea fi invocat pe maina localhost, la portul 8080).
Clientul C# ce valideaz documentul via serviciul Web de mai sus va trebui
compilat printr-o linie de genul:
c:\Windows\Microsoft.NET\Framework\v1.1.4322\csc /t:exe /r
:System.Web.dll,System.XML.dll,System.Web.Services.dll
XMLValidator.cs xml-validator-client.cs
Interaciunea dintre un client i un server Web, via clasa proxy generat, este
prezentat n figura 12.
Figura 12. Interaciunea dintre un client, clasa proxy i serviciul Web
212
SERVICII WEB
Un posibil rezultat este ilustrat de captura-ecran urmtoare, n care se observ

i descrierea WSDL generat automat de .NET Framework pentru serviciul Web
dezvoltat.
Figura 13. Rspunsul afiat de clientul care a invocat serviciul Web
2.3. Accesarea dintr-un script Perl a serviciului Web

implementat n .NET
De asemenea, putem realiza un client conceput n limbajul Perl, apelnd la
modulul SOAP::Lite. Codul acestuia e similar celui descris mai sus, cu excepia
faptului c valoarea parametrului proxy a constructorului este o adres de genul
http://winxp.infoiasi.ro:8080/xml-validator.asmx, iar numele metodelor invocate sunt
cele ale serviciului .NET implementat.
213
Liniile care prezint interes n contextul de fa sunt:

# ne conectm la server
my $soap = SOAP::Lite
->uri('http://127.0.0.1/XMLValidator/')
# URI-ul spaiului de nume
->proxy(
'http://127.0.0.1:8080/xml-validator2.asmx')
# locaia serviciului
->on_action(sub { join('', @_) });
my @params = (SOAP::Data->name('filename', $ARGV[0]));
print "Documentul $ARGV[0] este... ";
# verificm dac fiierul XML exist pe server
if ($soap->call("CheckIfExists" => @params)->result) {
# ...i invocm metoda de validare
my $valid =
$soap->call("Validate" => @params)->result;
print $valid . ".\n";
}
else {
print "inaccesibil (nu exist pe server?).\n";
}
2.4. Invocarea din PHP a serviciului Web

Similar, clientul PHP se bazeaz pe biblioteca NuSOAP i folosete descrierea
WSDL a serviciului. Instanierea clientului SOAP n acest caz are forma:
// instanierea clientului SOAP
// pe baza descrierii serviciului Web
'http://localhost:8080/xml-validator.asmx?WSDL',
true);
Dac apelm CheckIfExists cu un nume de fiier inexistent, vom obine mesaje

similare celor din figura 14.
214
SERVICII WEB
Figura 14. Rezultatul obinut la invocarea serviciului Web

implementat n C# via un client PHP
Folosind extensia SOAP inclus n PHP 5, vom putea scrie urmtorul

cod-surs:
$doc = $_REQUEST['xml'];
try {
$client = new SoapClient(
'http://127.0.0.1:8080/xml-validator2.asmx?WSDL',
array('trace' => 1));
// $rez = $client->CheckIfExists ($doc);
$rez = $client->__call('CheckIfExists',
array($doc));
215
echo 'Cererea efectuat:<br /><pre class="cod">' .

htmlspecialchars($client->__getLastRequest(),
ENT_QUOTES) . '</pre>';
echo 'Rspunsul obinut:<br /><pre class="cod">' .
htmlspecialchars($client->__getLastResponse(),
ENT_QUOTES) . '</pre>';
if ($rez == true) {
$rez = $client->Validate ($doc);
echo "<p>Documentul $doc este $rez.</p>";
} else {
echo "<p>Documentul $doc e inaccesibil
(nu exist pe server?)</p>";
}
echo 'A aprut o excepie: ' .
$exception->faultstring;
}
Numele documentului dorit a fi validat poate fi furnizat prin GET n irul de

interogare. n invocarea serviciului Web ne folosim de fiierul WSDL asociat
acestuia. Astfel, o metod poate fi apelat direct, ca metod a obiectului $client,
instan a clasei SoapClient. Dup cum am vzut anterior, o apelare de nivel
sczut se poate efectua via metoda __call(). n exemplul de fa am afiat i
cererea i rspunsul SOAP, aa cum se remarc n figura urmtoare.
216
SERVICII WEB
Figura 15. Rezultatul obinut la invocarea serviciului Web

via un client ce recurge la extensia Soap din PHP 5
2.5. Invocarea de servicii Web externe

Dac pn n momentul de fa am scris diveri clieni care invocau metode ale
unor servicii Web proprii, e timpul s descriem modalitatea de a obine rezultate
din partea unor servicii Web externe, dezvoltate de tere organizaii. Nu vom mai
217
avea acces la codul-surs al implementrii, ci doar la interfaa serviciului oferit

de documentul WSDL ce-l descrie.
Figura 16. Consultarea metodei getAllServiceNames()

a serviciului de interogare disponibil pe situl XMethods
218
SERVICII WEB
Accesarea serviciului de interogare oferit de XMethods

Unul dintre siturile care pun la dispoziie diverse servicii Web publice este
XMethods www.xmethods.net. Pentru a accesa lista serviciilor Web oferite, vom
invoca prin SOAP una dintre metodele serviciului Web de interogare oferit de
organizaia XMethods. Consultnd documentul WSDL de la adresa http://
www.xmethods.net/interfaces/query.wsdl, observm c putem folosi metoda
getAllServicesName(), care furnizeaz numele i identificatorii universali unici ai
tuturor serviciilor Web nregistrate. Recurgnd la instrumentul WSDL SOAP
Analyser deja amintit n cadrul lucrrii de fa, obinem informaiile din figura 16.
Clientul care apeleaz aceast metod este scris n limbajul Perl i are
urmtorul cod-surs (firesc, utilizm modulul SOAP::Lite):
use SOAP::Lite;
@params = ( ); # nu exist parametri de intrare
# apelm metoda serviciului Web
$response = SOAP::Lite
->proxy("http://www.xmethods.net/interfaces/query")
->uri("http://www.xmethods.net/interfaces/query")
->call('getAllServiceNames' => @params);
# semnalm erorile SOAP, dac exist
die "Fault: " . $response->faultcode .
" " . $response->faultdetail . " " .
$response->faultstring
if $response->faultcode;
# afim o parte dintre serviciile Web ntoarse
foreach $r ($response->dataof ('//name')) {
if ($r->value =~ /^Co/) { # numele ncepe cu 'Co'
print $r->value . "\n";
}
}
Cererea va avea urmtoarea form:
POST http://www.xmethods.net/interfaces/query HTTP/1.1
Accept: text/xml
Accept: multipart/*
Accept: application/soap
Content-Length: 453
SOAPAction: "http://www.xmethods.net/interfaces/
query#getAllServiceNames"
219

<soap:Envelope
xmlns:soapenc=
soap:encodingStyle=
xmlns:soap=
<soap:Body>
<getAllServiceNames
xmlns="http://www.xmethods.net/interfaces/query"
xsi:nil="true" />
</soap:Body>
</soap:Envelope>
Serverul va ntoarce un mesaj precum urmtorul (observai codificarea SOAP

a rspunsului):
HTTP/1.1 200 OK
Connection: close
Date: Sat, 12 Aug 2006 09:41:16 GMT
Server: Apache/1.3.26 (Unix) Enhydra-Director/3
PHP/4.0.6 DAV/1.0.3 AuthNuSphere/1.0.0
Content-Length: 43538
Content-Type: text/xml; charset=UTF-8
Servlet-Engine: Enhydra Application Server/3.1.1b1
(JSP 1.1; Servlet 2.2; Java 1.4.2_03;
Linux 2.4.7-10smp i386;
java.vendor=Sun Microsystems Inc.)
<?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/envelope/'
xmlns:soapenc=
'http://schemas.xmlsoap.org/soap/encoding/'
xmlns:n4=
'http://www.xmethods.net/interfaces/query.xsd'>
<soap:Body soap:encodingStyle=
'http://schemas.xmlsoap.org/soap/encoding/'
xmlns:soap=
'http://schemas.xmlsoap.org/soap/envelope/'>
<n:getAllServiceNamesResponse
xmlns:n='http://www.xmethods.net/interfaces/query'>
<Result soapenc:arrayType='n4:IDNamePair[476]'>
220
SERVICII WEB
<i>
<id>uuid:F73777F6-1113-7D28-BE46-2A5E2B8C0313</id>
<name>Weather by City</name>
</i>

</Result>
</n:getAllServiceNamesResponse>
</soap:Body>
</soap:Envelope>
Se returneaz un document XML coninnd codificarea unui tablou de

perechi (id, name) pentru fiecare serviciu disponibil. Deoarece sunt foarte multe
intrri, programul nostru nu va afia dect numele serviciilor care ncep cu
caracterele Co. Rezultatul rulrii este ilustrat n continuare:
(infoiasi)$ perl servicii-xmethods.pl
Country Information WebService
Conversions
CountCheat Countdown Service
Congress Member Directory
Code39 Bar Code
ColdFusion Tip-of-the-Day
CountryWebservice
Pentru a obine informaii referitoare la un anumit serviciu, vom putea

recurge la metoda getServiceDetail(), care are ca parametru de intrare identificatorul serviciului respectiv i care furnizeaz un rspuns avnd structura din
figura 17.
Implementarea programului care apeleaz getServiceDetail() folosind Perl sau
oricare alt limbaj de programare (lucrurile decurg similar cu cele menionate mai
sus) o lsm ca exerciiu pentru cititor.
221
Figura 17. Structura arborelui corespunztor documentului XML privitor la informaiile

despre un serviciu Web oferit de XMethods
Invocarea serviciilor puse la dispoziie de Google

Motorul de cutare Google pune la dispoziie o serie de servicii Web care pot fi
utilizate n cadrul aplicaiilor noastre via SOAP. Vom exemplifica mai jos cum
se poate folosi un serviciu de cutare i unul de verificare gramatical (spell
checking) dintr-o aplicaie scris n Visual Basic .NET (adaptare dup tutorialele
disponibile pe Web).
Primul pas este cel de creare a unui cont la Google i obinerea unei chei cu
ajutorul creia se pot realiza maxim o mie de interogri pe zi detalii la http://
www.google.com/apis/.
Urmtoarea etap presupune crearea unui proiect de tip Windows Application
n cadrul mediului de dezvoltare Visual Studio .NET. Vom aduga o referin la
222
SERVICII WEB
serviciul oferit de Google, astfel nct s avem acces la acesta (vezi figura 18, n
care se pot remarca i metodele ce pot fi folosite).
Figura 18. Adugarea unei referine Web spre serviciul Google

(se folosete un document WSDL indicat de un URI)
Dup introducerea URI-ului http://api.google.com/

GoogleSearch.wsdl, apsai butonul Add Reference, care
determin adugarea acestei referine Web la proiectul nostru. n fereastra Solution Explorer, referina va
fi redenumit drept Google; a se urmri figura alturat.
Vom crea o interfa care va solicita de la utilizator un text folosit ca expresie de cutare, serviciul
Google returnnd numrul de rezultate (pagini Web)
gsite. De asemenea, utilizatorul va putea introduce un ir de caractere scris n
limba englez, iar Google via metoda doSpellingSuggestion() va furniza termenul
corect n urma realizrii operaiei de spell checking.
Invocarea primei metode adic doGoogleSearch() va avea loc la apsarea
butonului etichetat Numr pag. gsite, conform codului de mai jos:
223
Private Sub btn_Search_Click (

ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles NrPag.Click
' Cheia de liceniere obinut de la Google
Dim MyLicenseKey As String
' Instanierea serviciului de cutare
Dim MyService As Google.GoogleSearchService = New _
Google.GoogleSearchService()
' Rezultatul obinut n urma invocrii
Dim MyResult As Google.GoogleSearchResult
MyLicenseKey = "mT2Mpq9QFHLchbCY2F6WYAvEY39I7mDO"
' Invocm metoda
MyResult = MyService.doGoogleSearch(MyLicenseKey, _
ExpresiaCautata.Text, 0, 1, False, "", _
False, "", "", "")
' Obinem nr. de rezultate
NrRez.Text = "Numarul de rezultate gsite este:" & _
CStr(MyResult.estimatedTotalResultsCount)
End Sub
Liniile responsabile cu apelarea celei de-a doua metode la apsarea butonului

Spell checking sunt urmtoarele:
Private Sub btn_SpellChecking_Click (
ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles Spelling.Click
Dim MyLicenseKey As String
Dim MyService As Google.GoogleSearchService = New _
Google.GoogleSearchService()
Dim MyResult As String
MyLicenseKey = "mT2Mpq9QFHLchbCY2F6WYAvEY39I7mDO"
MyResult = MyService.doSpellingSuggestion
(MyLicenseKey, TextulDeVerificat.Text)
TextCorect.Text = "Google afirm c e corect: " & _
MyResult
End Sub
Un rezultat posibil e ilustrat de figura 19, n care se pot observa att

rezultatele obinute printr-o interogare manual a motorului Google, ct i cele
ntoarse de serviciul Web pus la dispoziie.
224
SERVICII WEB
Figura 19. Rezultatele obinute via serviciul Web oferit de Google
Observm, aadar, cu ct uurin se pot ncorpora serviciile Web oferite de

Google (precum cel de cutare sau cel privitor la informaii topografice via
Google Maps), n aplicaiile noastre. Utilitatea acestora poate fi foarte mare n
crearea de aplicaii informative sau de divertisment, care pot utiliza diverse
resurse disponibile pe Web. De asemenea, serviciul de spell checking se poate
integra n cadrul altor programe sau aplicaii Web. Alte utilizri sunt cele
privitoare la implementarea unor modaliti de cutare pe Web din linia de
comand sau widget-uri grafice, ori realizarea de statistici privind informaiile
despre un anumit subiect de-a lungul timpului.
2.6. Folosirea instrumentului gSOAP pentru C/C++

Suita de unelte gSOAP are drept scop simplificarea dezvoltrii de servicii Web
prin SOAP i de implementare de clieni pentru invocarea acestora n limbajele
C i C++. Se pune la dispoziie un compilator cu rolul de generare a codului-surs
C/C++, pe baza unui fiier antet. De asemenea, avem la dispoziie i o bibliotec
de clase, plus diverse rutine menite s codifice tipurile de date native C++ n
XML. Suplimentar, gSOAP furnizeaz i un mecanism de garbage collection. Modelul
de dezvoltare a serviciilor Web adoptat de gSOAP este cel clasic, bazat pe
paradigma RPC.
225
Argumentul c gSOAP este un instrument matur este dat de faptul c IBM

folosete gSOAP pentru dezvoltarea de servicii Web destinate dispozitivelor
mobile (probabil, datorit necesitii de utilizare minim a memoriei i a unei
viteze mari de procesare), iar proiectul european GridLab l-a adoptat pentru
construirea de servicii destinate sistemelor de tip grid (detalii i n capitolul 7). n
acest moment, gSOAP este dezvoltat n cadrul Source Forge, pornindu-se de la
versiunea iniial oferit de Universitatea din Florida.
Documentaiile necesare i o suit de exemple sunt disponibile n cadrul
distribuiei open source a pachetului gSOAP.
Vom detalia, ca exemplificare, maniera de dezvoltare a unui serviciu Web
care, primind un numr, va verifica dac acesta este prim. Vom crea trei fiiere:
nrprim.h, fiier antet cu informaii privind funciile RPC ce urmeaz a fi
invocate;
nrprimserver.c, reprezentnd codul serverului;
nrprimclient.c, reprezentnd programul client.
Ca i n situaiile de mai sus, vom asocia un spaiu de nume XML serviciului
Web dezvoltat. n fiierul antet se va face corespondena ntre spaiul de nume
stabilit i prototipurile fiecreia dintre funciile serviciului Web implementat.
Codul acestui fiier antet este urmtorul:
//numele serviciului:
nrprim
//stilul de vehiculare a mesajelor: rpc
//spaiul de nume: http://localhost/nrprim.wsdl
//URI-ul serviciului: http://localhost/nrprimserver.cgi
/* funcia oferit de serviciul Web */
int ns__nrprim (double numar, double *rezultat);
n cazul gSOAP, se folosete convenia urmtoare: toi parametrii funciilor

sunt considerai parametri de intrare, cu excepia ultimului (care va conine
rezultatul). De asemenea, valoarea ntoars este ntotdeauna int, putnd fi folosit
pentru diagnosticarea eventualelor erori survenite.
Furnizm mai jos codul C al serverului:
#include "soapH.h"
#include "nrprim.nsmap"
int main(int argc, char **argv) {
int m, s;
/* descriptori de socket */
struct soap soap; /* include mesajele SOAP */
soap_init(&soap); /* iniializm... */
226
SERVICII WEB
if (argc < 2)
/* oferim servicii ca un CGI */
soap_serve(&soap);
else {
/* atam serverul la un port
specificat n linia de comand (argv[1]) */
m = soap_bind(&soap, NULL, atoi(argv[1]), 100);
if (m < 0) {
/* afim eroarea survenit */
soap_print_fault(&soap, stderr);
exit(-1);
}
fprintf(stderr, "Conexiune reuit.\n");
while (1) {
// acceptm cereri din partea clienilor
s = soap_accept(&soap);
if (s < 0) { /* a intervenit o eroare */
soap_print_fault(&soap, stderr);
exit(-1);
}
fprintf(stderr, "S-a conectat un client.\n");
soap_serve(&soap); /* deservim clientul... */
soap_end(&soap);
/* am terminat */
}
}
return 0;
/* funcia invocat la apariia cererii

din partea unui client */
int ns__nrprim (struct soap *soap,
double numar, double *rezultat) {
int contor = 2;
int temp = (int) numar;
while (contor < temp) { /* verif. dac e prim */
if (temp % contor != 0)
contor++;
else {
*rezultat = 0;
break;
}
}
if (contor == temp)
*rezultat = 1;
return SOAP_OK;
}
227
Mai trebuie s descriem codul-surs al clientului:

#include "soapH.h"
#include "nrprim.nsmap"
/* URI-ul serviciului */
const char server[] =
"http://127.0.0.1/cgi-bin/nrprimserver.cgi";
int main(int argc, char **argv) {
struct soap soap;
double numar;
/* numrul solicitat */
double rezultat; /* rezultatul primit */
if (argc < 2) {
fprintf(stderr, "Introducei un numr.\n");
exit(0);
}
soap_init(&soap); /* iniializare... */
numar = atoi(argv[1]);
/* invocm funcia via SOAP */
soap_call_ns__nrprim (&soap, server, "",
numar, &rezultat);
/* verificm dac au aprut erori */
if (soap.error) {
soap_print_fault (&soap, stderr);
exit(1);
}
else {
if (rezultat == 0)
printf("Ai dat un numr care nu este prim\n");
else
printf("Ai dat un numr prim\n");
}
/* finalizm dialogul cu serverul */
soap_destroy(&soap);
soap_end(&soap);
soap_done(&soap);
return 0;
}
Pentru a facilita compilarea diferitelor servicii Web, distribuia gSOAP pune la

dispoziie un fiier Makefile pe care putei s-l ajustai dup dorin. n fiierul
Makefile folosit de noi, se apeleaz compilatorul gSOAP RPC, numit soapcpp2, n
maniera urmtoare (opiunea c este folosit pentru a se obine diversele
fiiere-surs necesare):
(infoiasi)$ ./soapcpp2 -c nrprim.h
228
SERVICII WEB
Similar manierei de dezvoltare a aplicaiilor RPC clasice, vor rezulta o serie

de fiiere: soapStub.h, soapH.h, soapC.c, soapClient.c, soapServer.c etc.
n acest moment, codul va fi compilat i legat folosindu-se stdsoap2.c (respectiv,
stdsoap2.cpp pentru C++ n loc de C). Eventual, executabilul rezultat va putea fi
apoi instalat ca un script CGI.
S urmrim n figura de mai jos testarea funcionrii serviciului:
Figura 20. Rularea programului-client dezvoltat cu gSOAP
2.7. Implementarea serviciilor Web n Java

Instrumentul Apache Axis2
Apache Axis i are originea n Apache SOAP, prima soluie, bazat pe SOAP 1.1,
oferit de fundaia Apache pentru conceperea de servicii Web. Limbajele de
programare care pot fi folosite sunt C++ i Java.
Cel mai recent efort, numit Axis2, reproiecteaz arhitectura Axis/Java i
Axis/C++, procesarea realizndu-se n stilul stateless (aceasta permite codului s
fie rulat n paralel, de fire de execuie separate). De asemenea, se ofer i un
model informaional (information model) persistent, sistemul putnd fi repornit
fr pierderi de date. Arhitectura intern a Apache Axis2 este una modular,
229
constnd din diverse componente, precum modulul de procesare XML (bazat pe

Apache Xerces), procesorul de mesaje SOAP, modulul de exploatare a serviciilor
(deployment), generatorul de documente WSDL, interfaa de programare a clienilor
SOAP i modulul de transport al datelor.
Suplimentar, Apache Axis2 permite includerea de servicii Web din zbor,
astfel nct servicii Web noi s poat fi rulate fr ntreruperea execuiei
sistemului. De asemenea, se pot realiza actualizri (modificri) ale unui serviciu
deja existent, fr a opri sistemul (desigur, eventualele schimbri produse pot
conduce la pierderea de informaii).
Pentru a putea scrie o aplicaie n Java folosind Axis2 avei nevoie de
urmtoarele componente software:
Apache Geronimo exemplele furnizate mai jos au fost rulate pe acest server,
pe baza cruia este construit i IBM WebSphere Community Edition. Desigur,
putei recurge i la un alt server. Pentru a prelua Geronimo, vizitai adresa
http://geronimo.apache.org/downloads.html.
Apache Axis2 (ori o alt implementare SOAP). Instrumentele puse la dispoziie
reduc timpul de dezvoltare a codului. Putei obine Apache Axis2 de la adresa
http://ws.apache.org/axis2/download.cgi (remarcm faptul c distribuia .war este
folosit pentru dezvoltarea de servicii Web, iar cea binar v ajut la crearea
clienilor);
Java 2 Standard Edition ncepnd cu versiunea 1.4.
Pornind de la premisa c uneori instalarea diferitelor instrumente cost mai
mult timp dect dezvoltarea propriu-zis a aplicaiei (dei nu este cazul aici),
vom prezenta n continuare paii necesari realizrii unui serviciu Web n Java,
folosind componentele software enumerate mai sus.
Dup ce ai transferat Geronimo, trebuie doar s dezarhivai serverul n oricare
director dorii (pentru prevenirea eventualelor probleme, evitai instalarea n
cazul Windows n directoarele Program Files sau Documents and Settings). Pentru
exemplele urmtoare, presupunem serverul Geronimo stocat n directorul
c:\geronimo.
Putei apoi porni serverul, fie din linia de comand, fie rulnd fiierul
startup.bat. n primul caz, introducei de la prompt-ul sistemului liniile:
cd \geronimo\bin
java -jar server.jar
Testai rularea serverului, introducnd adresa http://localhost:8080 n browser-ul

preferat. n caz de succes, vei obine informaiile din figura de mai jos.
230
SERVICII WEB
Figura 21. Testarea rulrii serverului Geronimo
Urmtoarea etap este instalarea instrumentului Apache Axis2. Folosii consola

de administrare Geronimo (numele de utilizator i parola n mod implicit sunt
system, respectiv manager) i selectai opiunea Deploy New. Testai desfurarea
cu succes a operaiunii, prin vizitarea adresei http://localhost:8080/axis2/.
Din acest moment putem crea propriul nostru serviciu Web. Indiferent ce
tehnologii folosii, exist dou abordari de dezvoltare: fie pornind de la documentul WSDL ce descrie interfaa serviciului (contract first approach), fie scriind
codul-surs al implementrii (code first approach). Prima metod presupune buna
cunoatere a specificaiilor WSDL (a se revedea capitolul 3).
Mai simplu este s concepem o clas Java i apoi s o transformm n serviciu
Web. n abordarea Axis2, dup scrierea codului clasei mai urmeaz s precizm
aa-numitul descriptor al serviciului, memorat n fiierul services.xml, i s crem
o arhiv de exploatare a aplicaiei.
Ne propunem s realizm un serviciu simplu de salutare a utilizatorului:
import org.apache.axis2.context.ServiceContext;
import org.apache.axis2.context.OperationContext;
public class HelloJavaSoap {
public String echoJavaSoap(String param) {
return "Echooo... " + param;
}
}
231
Am scris o clas Java cu o singur metod public. Aceast metod primete

un parametru de tip string i ntoarce valoarea parametrului prefixat de un text.
Urmeaz s crem documentul services.xml care indic mediului cum s
configureze i s expun posibililor clieni serviciul Web n cauz:
<service name="HelloJavaSoap">
<description>
Primul serviciu Web folosind Axis2
</description>
<parameter name="ServiceClass" locked="false">
HelloJavaSoap
</parameter>
<operation name="echoJavaSoap">
<messageReceiver class=
"org.apache.axis2.rpc.receivers.RPCMessageReceiver"
/>
</operation>
</service>
Pentru a stabili corespondena ntre serviciu i clasa Java care l implementeaz, am adugat un atribut cu numele ServiceClass, a crui valoare reprezint
calea spre locaia unde se afl memorat implementarea. Elementul operation
specific faptul c metoda oferit de serviciul Web este echoJavaSoap, mesajele
fiind recepionate via clasa pus la dispoziie de Apache Axis2. Dup cum se
poate observa, se recurge la un transfer n stilul RPC.
Urmtorul pas este s crem o arhiv cu extensia .aar (Axis2 Archive) care
include codul compilat (fiierul .class) i documentul services.xml. Structura intern
a acestei arhive de fapt, un .zip cu extensie diferit are forma:
META-INF\
Services.xml
HelloJavaSoap.class
Mai urmeaz s ncrcm serviciul prin interfaa de administrare disponibil

la http://localhost:8080/axis2/axis2-admin/, selectnd opiunea Upload Service (urmrii figura 22).
232
SERVICII WEB
Figura 22. ncrcarea serviciului Web n vederea invocrii ulterioare
Dup aceasta, dai clic pe legtura Available Services pentru a obine mesajele
din captura-ecran urmtoare:
Figura 23. Lista serviciilor disponibile (aici, serviciul Web HelloJavaSoap)
233
n cadrul distribuiei Axis2, sunt disponibile o serie de exemple pe care le

recomandm spre studiu. Ne oprim asupra unui program, numit DynamicInvoker,
care reprezint un client Java pentru invocarea serviciilor Web (cel anterior,
serviciile Web externe prezentate n seciunea 2.5 etc.) pe baza documentului
WSDL asociat.
Pentru rularea acestui program, trebuie s stabilim valoarea corespunztoare
pentru variabila de mediu CLASSPATH, astfel nct s cuprind locaia unui
procesor XML (e.g., Apache Xerces) i toate fiierele .jar din directorul lib. Dup
compilarea codului, l rulm astfel:
java samples.client.DynamicInvoker http://localhost:8080/
axis2/services/HelloJavaSoap?wsdl echoJavaSoap "avem
portocale albastre!"
Vom obine urmtorul rspuns (am omis anumite mesaje de avertisment

privitoare la lipsa suportului pentru jurnalizare log4j):
Reading WSDL document from 'http://localhost:8080/
axis2/services/HelloJavaSoap?wsdl'
Preparing Axis dynamic invocation
Executing operation echoJavaSoap with parameters:
>echoJavaSoap>param0=avem portocale albastre!
>echoJavaSoapResponse>return=Echooo... avem portocale
albastre!
Done!
Din cele prezentate mai sus, putem considera c mediul Axis2 ofer un
mecanism flexibil i rapid de dezvoltare a serviciilor Web. Ca alternative,
menionm JWSDP (Java Web Services Developer Pack) pus la dispoziie de compania
Sun i noua versiune J2SE 1.6, care include suport nativ pentru crearea i
invocarea de servicii Web.
Importarea serviciilor Web n Java

Pe baza documentului WSDL ce descrie serviciul implementat n C# (a se
revedea seciunea 2.1), vom putea realiza aa-numita importare a interfeei lui n
limbajul Java. Aceast aciune poate fi realizat uor, graie instrumentului
wsimport pus la dispoziie de Java 2 Standard Edition versiunea 1.6 (la momentul
scrierii acestei cri, am folosit varianta J2SE 1.6 beta 2). Rulndu-l cu urmtorii
parametri dai n linia de comand, vom obine n cadrul directorului xml
codul-surs Java al pachetului ro.infoiasi.xmlvalidator ce desemneaz interfaa
serviciului:
234
SERVICII WEB
c:\jdk1.6.0\bin>wsimport http://localhost:8080/
xml-validator.asmx?WSDL -s .\xml -verbose
ro\infoiasi\xmlvalidator\CheckIfExists.java
ro\infoiasi\xmlvalidator\CheckIfExistsResponse.java
ro\infoiasi\xmlvalidator\ObjectFactory.java
ro\infoiasi\xmlvalidator\Validate.java
ro\infoiasi\xmlvalidator\ValidateResponse.java
ro\infoiasi\xmlvalidator\XMLValidator.java
ro\infoiasi\xmlvalidator\XMLValidatorSoap.java
ro\infoiasi\xmlvalidator\package-info.java
Fiierul XMLValidatorSoap.java conine definiiile metodelor accesate via

SOAP expuse de serviciul Web i are urmtorul cod generat automat (din care,
de altfel, se poate deduce i maniera de dezvoltare a serviciilor Web n J2SE 1.6):
package ro.infoiasi.xmlvalidator;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.xml.ws.RequestWrapper;
import javax.xml.ws.ResponseWrapper;
// Numele i spaiul de nume al serviciului Web
@WebService(name = "XMLValidatorSoap",
targetNamespace =
"http://www.infoiasi.ro/XMLValidator")
public interface XMLValidatorSoap {
// metoda care verific existena fiierului
@WebMethod(operationName = "CheckIfExists",
action =
"http://www.infoiasi.ro/XMLValidator/CheckIfExists")
@WebResult(name = "CheckIfExistsResult",
targetNamespace =
// desemneaz clasa responsabil cu ncapsularea
// cererii SOAP
@RequestWrapper(localName = "CheckIfExists",
targetNamespace =
"http://www.infoiasi.ro/XMLValidator",
className =
"ro.infoiasi.xmlvalidator.CheckIfExists")
// desemneaz clasa responsabil cu ncapsularea
// rspunsului SOAP
@ResponseWrapper(localName = "CheckIfExistsResponse",
targetNamespace =
className =
"ro.infoiasi.xmlvalidator.CheckIfExistsResponse")
235
public boolean checkIfExists(

// meta-date pentru parametrul de intrare
@WebParam(name = "filename",
targetNamespace =
String filename);
/* similar i pentru a doua metod */
Adnotrile asociate serviciului Web sunt generate conform documentului

WSDL i sunt disponibile n fiierul XMLValidator.java:
@WebServiceClient(name = "XMLValidator",
targetNamespace =
wsdlLocation =
"http://localhost:8080/xml-validator.asmx?WSDL")
public class XMLValidator extends Service {
private final static URL XMLVALIDATOR_WSDL_LOCATION;
static {
URL url = null; // adresa documentului WSDL
try {
url = new URL(
"http://localhost:8080/xml-validator.asmx?WSDL");
}
catch (MalformedURLException e) {
e.printStackTrace();
}
XMLVALIDATOR_WSDL_LOCATION = url;
}
public XMLValidator(URL wsdlLocation,
QName serviceName) {
super(wsdlLocation, serviceName);
}
public XMLValidator() {
super(XMLVALIDATOR_WSDL_LOCATION,
new QName("http://www.infoiasi.ro/XMLValidator",
"XMLValidator"));
}
// se definete punctul terminal al serviciului
// (ntoarce un obiect XMLValidatorSoap,
// a crui clas a fost dat mai sus)
@WebEndpoint(name = "XMLValidatorSoap")
public XMLValidatorSoap getXMLValidatorSoap() {
return (XMLValidatorSoap)super.getPort(new
QName("http://www.infoiasi.ro/XMLValidator",
"XMLValidatorSoap"), XMLValidatorSoap.class);
}
}
236
SERVICII WEB
Se remarc existena pachetului javax.xml.ws disponibil ncepnd cu J2SE 1.6

i J2EE 1.5, care ofer suportul necesar dezvoltrii facile i invocrii de servicii
Web att prin SOAP, ct i recurgnd la paradigma REST. Acest pachet formeaz
JAX-WS, interfaa de programare de baz a serviciilor Web.
Conform JAX-WS, un serviciu Web n rulare reprezint o instan (obiect) a
unei clase Java, adnotat prin javax.jws.WebService. Interfaa expus ctre posibilii
clieni este o interfa Java privitoare la punctul terminal al serviciului (SEI
Service Endpoint Interface), care nu trebuie neaprat specificat de programator,
deoarece ea poate fi suplinit de clasa care implementeaz serviciul. Dup
scrierea codului i realizarea compilrii, va putea fi creat un fiier .war care va fi
exploatat n cadrul unui server de aplicaii precum Tomcat. n timpul invocrii,
serverul de aplicaii va genera automat clasele responsabile cu schimbul de
mesaje cu posibilii clieni.
Similar manierei folosite la .NET, cel mai simplu serviciu Web (de salutare a
utilizatorului) are codul urmtor:
package salut;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService()
public class Salut { // clas implementnd serviciul
private String mesaj = new String("Salut, ");
// o singur metod
@WebMethod()
public String sayHello (String nume) {
return mesaj + nume;
}
Corespunztor, clientul Java care invoc metoda de mai sus este compus din
urmtoarele linii:
import javax.xml.ws.WebServiceRef;
import salut.ServiciuSalut;
import salut.Salut;
public class ClientSalut {
@WebServiceRef(wsdlLocation=
"http://localhost:8080/salutari/salutari?wsdl")
static ServiciuSalut serviciu;
237
public static void main(String[] args) {

try {
ClientSalut client = new ClientSalut();
client.invoca(args);
}
catch(Exception e) {
}
}
// ncearc s invoce serviciul
public void invoca(String[] args) {
try {
System.out.println("Vom invoca " + serviciu);
Salut port = serviciu.getHelloPort();
String nume;
// prelum numele din linia de comand
nume = (args.length > 0) ?
args[0] : "Portocal Escu";
String raspuns = port.sayHello(nume);
System.out.println(raspuns);
}
catch(Exception e) {
}
}
2.8. Suportul oferit de mediul Delphi pentru crearea

i utilizarea serviciilor Web
Dezvoltarea serviciului
La finalul acestui subcapitol vom prezenta maniera de implementare n Delphi
(Object Pascal) a unui serviciu Web simplu. Codul-surs a fost testat sub Delphi
6 Enterprise Edition, care ofer suport pentru SOAP 1.1.
Pentru crearea serviciului Web, avem la dispoziie un asistent (wizard) pe
care-l putem apela prin intermediul operaiei Other a opiunii New din cadrul
meniului File. Selectnd tab-ul WebServices, vom da clic pe Soap Server Application.
A se urmri figura de mai jos.
238
SERVICII WEB
Figura 24. Apelarea asistentului de creare

a unui serviciu Web
Va aprea o fereastr n care trebuie s alegem tipul de aplicaie ce va fi

generat (vezi figura 25). Vom opta pentru realizarea unui executabil CGI care
va putea fi uor exploatat ulterior n cadrul serverului Apache. Drept alternative,
ni se ofer posibilitatea s implementm serviciul ca modul Apache ori ca o
bibliotec dinamic executat n cadrul unui server precum IIS.
Figura 25. Alegerea tipului de aplicaie Web

care va ncapsula serviciul dezvoltat
239
Mediul Delphi va genera un unit, pe

care-l vom salva sub denumirea
SWebMod.pas, care va ngloba trei componente:
HTTPSoapDispatcher1 dispecerul
SOAP peste HTTP, responsabil cu
preluarea cererilor i trimiterea rspunsului;
HTTPSoapPascalInvoker1 clasa responsabil cu (de)serializarea mesajelor
SOAP n obiecte Pascal;
WSDLHTMLPublish1 clasa care genereaz descrierea WSDL a serviciului.
Acest modul Web are structura ilustrat de figura alturat, iar codul lui surs
este furnizat n continuare:
unit SWebMod;
interface
uses
SysUtils, Classes, HTTPApp, WSDLPub, SOAPPasInv,
SOAPHTTPPasInv, SoapHTTPDisp, WebBrokerSOAP;
type
{ clasa responsabil cu publicarea serviciului }
TSalutWebModule = class(TWebModule)
{ dispecerul SOAP peste HTTP }
HTTPSoapDispatcher1: THTTPSoapDispatcher;
{ clasa responsabil cu (de)serializarea
mesajelor SOAP n obiecte Pascal }
HTTPSoapPascalInvoker1: THTTPSoapPascalInvoker;
{ clasa care genereaz doc. WSDL al serviciului }
WSDLHTMLPublish1: TWSDLHTMLPublish;
end;
var
SalutWebModule: TSalutWebModule;
implementation
{$R *.DFM}
end.
240
SERVICII WEB
Mai urmeaz s scriem o clas care va implementa efectiv serviciul Web dorit.
Vom crea astfel unit-ul salut.pas, al crui cod este urmtorul:
unit salut;
interface
uses InvokeRegistry;
type
{ o interfa invocabil }
ISalut = interface(IInvokable)
['{D7532EC7-EA7F-4610-ADE5-B3634BB0F343}']
function Salut: String; stdcall;
function NumaraZile: Byte; stdcall;
end;
{ o clas implementnd interfaa }
TSalut = class (TInvokableClass, ISalut)
public
{ metodele expuse de serviciul Web }
function Salut: String; stdcall;
end;
implementation
uses SysUtils, DateUtils;
{ implementarea metodelor serviciului Web }
function TSalut.Salut: String; stdcall;
begin
Result := 'Salut din Delphi, prin SOAP!';
end;
function TSalut.NumaraZile: Byte; stdcall;
begin
Result := DaysBetween (Now,
EncodeDate(2006, 12, 31));
end;
initialization
{ nregistrarea interfeei i clasei }
InvRegistry.RegisterInterface(TypeInfo(ISalut));
InvRegistry.RegisterInvokableClass(TSalut);
end.
Dup cum se observ, specificm pentru nceput o interfa invocabil, avnd

dou metode ce vor fi expuse de ctre serviciul Web de fa. Acestei interfee i
se asociaz un identificator universal unic, n maniera componentelor COM. De
asemenea, oferim i o implementare via o clas invocabil. Sunt definite dou
241
funcii, una care ntoarce un mesaj (ir de caractere) de salut, cealalt oferind
numrul de zile (un ntreg de tip Byte) rmase din momentul execuiei pn la
finalul anului 2006.
Cele dou unit-uri le includem n proiectul cu numele SalutWS.dpr i generm
fiierul executabil. Pentru a putea fi efectiv utilizat, acesta din urm trebuie
plasat n directorul htdocs al serverului Apache pentru Windows (n cazul nostru,
folosim distribuia Apache2Triad). Mai trebuie s configurm serverul s trateze
fiierele executabile (cele cu extensia .exe) ca programe CGI. Pentru aceasta vom
edita fiierul httpd.conf (localizat n directorul conf al serverului), insernd n
seciunea <IfModule mod_cgi.c>...</IfModule> liniile de mai jos:
AddHandler cgi-script .exe
AddType application/x-httpd-cgi .exe
Putem testa funcionalitatea serviciului folosind adresa http://localhost/SalutWS.exe/

wsdl/ISalut ntr-un browser Web. Va trebuie s obinem fiierul WSDL generat
automat de program (avizm cititorul c formatul WSDL nu respect standardele
n vigoare, ci o versiune mai veche a specificaiei, actualmente considerat
demodat).
Un client Delphi pentru serviciul implementat

n continuare, vom detalia maniera de exploatare a serviciului printr-un client Delphi. Vom
crea un form pe care vom plasa un buton de
execuie, la apsarea cruia s se invoce metoda
NumaraZile a serviciului de mai sus. De asemenea, din tab-ul WebServices al barei de componente (Component Palette), vom alege componenta
HTTPRIO, responsabil cu transferurile de
date aflate la distan via HTTP. n fereastra
Object Inspector, va trebui s editm valorile
urmtoarelor proprieti asociate componentei
amintite (a se urmri cele din figura alturat):
WSDLLocation reprezint locaia fiierului
WSDL asociat serviciului (putem introduce
URL-ul http://localhost/SalutWS.exe/wsdl/
ISalut);
Service desemneaz numele serviciului
(mediul genereaz o list de opiuni pe
242
SERVICII WEB
baza locaiei WSDL de mai sus, astfel nct vom selecta pentru situaia de fa
unica intrare ISalutservice);
Port reprezint punctul terminal al serviciului (ca i mai sus, din lista
generat, alegem ISalutPort).
Pentru a putea utiliza efectiv serviciul Web via HTTPRIO, va trebui s
recurgem la un alt asistent, denumit Web Services Importer (vezi figura 24),
responsabil cu generarea unui unit de accesare a metodelor puse la dispoziie de
serviciu. Asistentul va solicita adresa Web ori numele de fiier local al documentului WSDL corespunztor serviciului importat. La apsarea butonului
Generate va fi creat un unit, pe care-l denumim SalutImport.pas. Codul-surs al
acestuia este urmtorul:
unit SalutImport;
interface
uses Types, XSBuiltIns;
type
{ interfaa invocabil }
ISalut = interface(IInvokable)
['{AE775C10-3E55-41C4-8494-2A57E658F959}']
function Salut: WideString; stdcall;
end;
implementation
uses InvokeRegistry;
initialization
{ nregistrarea interfeei }
InvRegistry.RegisterInterface(TypeInfo(ISalut),
'urn:salut-ISalut', '');
end.
Mai urmeaz s scriem liniile care realizeaz efectiv invocarea, folosindu-ne

de interfaa ISalut:
unit SalutClient;
interface
uses
Windows, Messages, SysUtils, Variants, Classes,
Graphics, Controls, Forms,
Dialogs, Rio, SoapHTTPClient, StdCtrls;
type
{ fereastra de dialog }
TFormClient = class(TForm)
243
buton: TButton;
HTTPRIO: THTTPRIO;
procedure butonClick(Sender: TObject);
end;
var
FormClient: TFormClient;
implementation
{$R *.dfm}
uses SalutImport;
{ procedura de tratare a apsrii butonului }
procedure TFormClient.butonClick(Sender: TObject);
var Salut: ISalut;
begin
try
Salut := (HTTPRIO as ISalut);
{ afim rezultatul primit de la metoda
serviciului Web invocat }
MessageDlg('Au mai rmas ' +
IntToStr(Salut.NumaraZile) + ' de zile.',
mtInformation, [mbOk], 0);
except
on E: Exception do { tratm erorile }
MessageDlg('A aprut o eroare:' + E.Message,
mtError, [mbAbort], 0);
end;
end;
end.
Dup compilare, vom putea testa programul aa cum se poate remarca din
captura-ecran de mai jos:
Figura 25. Interfaa-utilizator a clientului de invocare a serviciului Web
244
SERVICII WEB
Invocarea din PHP a serviciului implementat n Delphi

La finalul acestei seciuni vom concepe un program PHP care va recurge la
extensia Soap pentru apelarea metodelor serviciului de mai sus. Ca i n exemplele
anterioare, codul-surs este simplu:
$client = new SoapClient(null,
array('location' =>
'http://localhost/SalutWS.exe/soap/ISalut',
'uri' => 'urn:salut-ISalut'));
$rez = $client->__call('Salut', array());
echo "<p>Am primit mesajul:
<strong>$rez</strong></p>";
$zile = $client->__call('NumaraZile', array());
echo "<p>Au mai rmas $zile de zile pn la
finalul anului.</p>";
Dup cum se remarc, serviciul Web este disponibil la adresa http://localhost/

SalutWS.exe/soap/ISalut, spaiul de nume fiind automat generat de mediul Delphi.
Un posibil rezultat poate fi urmrit n figura 26.
Figura 26. Rezultatul obinut dup execuia metodelor serviciului Web
245
3. Invocarea serviciilor Web n contextul AJAX

3.1. Punerea problemei
Avnd la dispoziie serviciul Web privitor la operaii cu fiiere (prezentat anterior
n cadrul acestui capitol), am dori s verificm n mod asincron existena unui
fiier, pe baza numelui furnizat de utilizator via un formular electronic. Graie
AJAX (Asynchronous JavaScript And XML), aceasta se poate realiza fr a rencrca
ntreaga pagin Web. Pe baza unor date preluate de pe servere aflate la distan,
se poate reactualiza n manier dinamic arborele DOM (Document Object Model)
asociat documentului XHTML redat de programul de navigare.
Dup o succint prezentare a suitei de tehnologii AJAX, vom furniza detaliile
de implementare a unui script PHP care va reprezenta puntea de legtur ntre
documentul Web ncrcat n browser i serviciul Web scris n Perl.
3.2. Caracteristici importante ale suitei de tehnologii AJAX

Componente
Termenul AJAX desemneaz o suit de tehnologii deschise, ncorpornd urmtoarele:
diverse limbaje standardizate de prezentare a datelor, precum XHTML i CSS
(Cascading Style Sheets);
redarea i interaciunea via standardul DOM;
interschimbul i manipularea de date prin XML i/sau XSLT (Extensible
Stylesheet Language Transformations);
transferul asincron de date via obiectul XMLHttpRequest;
procesarea prin limbajul ECMAScript/JavaScript.
Dac aplicaiile Web convenionale erau construite avnd ca punct central
serverul, navigarea fiind bazat pe ncrcarea de pagini Web (cu coninuturi
statice sau generate dinamic) solicitate serverului, n cazul AJAX aplicaia rezid
chiar n cadrul paginii, procesarea avnd loc la nivelul clientului, iar o parte din
date sunt stocate tot de ctre acesta. Astfel, avantajele majore aduse de AJAX
sunt cele legate de eliminarea rencrcrii paginilor, de facilitarea interaciunii cu
utilizatorul, de micorarea timpilor mori etc. Din punctul de vedere AJAX,
ntreaga aplicaie se regsete la nivelul browser-ului, ceea ce poate avea
repercursiuni nedorite privind sincronizarea serverului cu clientul. De cele mai
246
SERVICII WEB
multe ori este practic imposibil s se cunoasc starea (comportamentul) programelor de pe server. Alte dezavantaje vizeaz dependena de tehnologia
JavaScript (implementat n mod diferit de fiecare browser n parte), dificultatea
testrii i depanrii aplicaiilor, necesitatea folosirii navigatoarelor de ultim
generaie, accesul oricui la codul-surs (ceea ce poate cauza probleme de
securitate) i imposibilitatea, n unele situaii, de a realiza bookmark-uri ori de a
folosi mecanismul de istoric al navigrii (history).
Succesul suitei de tehnologii AJAX provine din promovarea sa de ctre
aplicaii Web populare precum Amazon, Basecamp, Flickr, Gmail, Google Maps,
Google Suggest, Netflix, Rollyo, Writely, Yahoo! i Zimbra.
Obiectul XMLHttpRequest
Componenta de baz este obiectul XMLHttpRequest pus la dispoziie practic de
ctre orice browser Web actual (a aprut n premier ca obiect ActiveX inclus n
Internet Explorer 5, iar apoi a fost adoptat i de Mozilla 1.0 i Safari 1.2). Acest
obiect permite realizarea de cereri HTTP (e.g., GET i POST) dintr-un program
rulnd la nivel de client (program de navigare) spre o aplicaie de pe server,
ntr-un mod asincron.
n mod uzual, datele vehiculate ntre programele client i server sunt marcate
n XML, dar pot fi adoptate i alte abordri: reprezentri HTML, JSON (JavaScript
Object Notation), CSV (Comma Separated Values) ori diverse metode de serializare.
Atunci cnd se utilizeaz HTML ca mijloc de reprezentare a datelor, AJAX se
mai numete i AHAH (Aynchronous HTML and HTTP). JSON reprezint un subset
al limbajului JavaScript (n fapt, al versiunii standardizate, cunoscut sub numele
de ECMAScript), avantajul fiind c datele reprezentate n JSON sunt simple
iruri de caractere ce pot fi convertite uor n (tablouri de) obiecte JavaScript.
Astfel dispare necesitatea procesrii coninutului XML obinut de la server.
Principalele metode care vor fi folosite efectiv n contextul AJAX sunt
urmtoarele:
open() iniiaz (deschide) o conexiune HTTP cu serverul, trimind o cerere
(uzual, GET sau POST) ctre acesta; aplicaia de pe server cu care va avea loc
schimbul de date va fi desemnat de un URI, dup cum vom vedea mai jos;
send() transmite date, n manier asincron, ctre aplicaia rulnd pe server;
abort() abandoneaz transferul curent;
setRequestHeader() specific diverse cmpuri ale antetului HTTP; de exemplu,
se poate stabili o anumit valoare particular pentru cmpul Content-Type,
aspect util atunci cnd dorim s manipulm alte tipuri de coninuturi, de
exemplu JSON ori CSV.
247
Proprietile de baz ale obiectului sunt:

readyState conine codul de stare a transferului (e.g., valoarea 4 specific
faptul c transferul datelor s-a efectuat complet) a se consulta i tabelul
de mai jos;
Valoarea
readyState
Stare
UNINITIATED
1
2
3
4
Descriere
Obiectul XML a fost creat, dar procesul de ncrcare nu a fost nc pornit.

ncrcarea este n progres, dar analiza XML nu a
LOADING
nceput.
ncrcarea s-a terminat, ns arborele DOM nu a
LOADED
fost creat.
Arborele DOM a fost generat, dar numai o parte
INTERACTIVE
dintre elemente au fost analizate.
Documentul XML a fost complet ncrcat i anaCOMPLETED
lizat.
status reprezint codul de stare HTTP ntors de serverul Web; de exemplu,

200 (Ok), 404 (Not Found), 500 (Server Internal Error);
statusText desemneaz irul de caractere ce explic n limbaj natural codul de
stare obinut;
onreadystatechange specific funcia ce va fi invocat la modificrile privind
schimbarea strii de transfer a datelor (datele sunt transmise n manier
asincron i deci programul de la nivel de client trebuie s poat fi notificat
asupra schimbrii evenimentelor care pot surveni pe parcursul transferului).
Utilizri
Caracteristica important oferit de AJAX este cea de a schimba doar anumite
pri ale paginii Web.
Una din tehnicile AJAX populare este i cea a indicrii vizuale a faptului c
un fragment dintr-un document a fost modificat. Astfel, pe baza unei nuane de
culoare, care dispare n timp, utilizatorului i se poate semnala c un paragraf
dintr-un text are coninutul schimbat (actualizat). Uzual, se folosete galbenul;
de aceea, acest ablon de proiectare se mai numete i YFT (Yellow Fade Technique),
generalizarea sa ntitulndu-se FAT (Fade Anything Technique).
O alt utilizare este cea a remprosptrii automate (eventual, periodice) a
unei zone dintr-o pagin. De exemplu, atunci cnd a aprut o nou tire
recepionat via un emitor Atom/RSS (Really Simple Syndication) ori s-a modificat
248
SERVICII WEB
o informaie de interes pentru utilizator (curs valutar, temperatur, scor la un

meci, voturi acordate unei piese muzicale etc.).
Tot prin intermediul AJAX, putem realiza un cmp interactiv cu autocompletarea datelor (auto-completion), n funcie de cele introduse deja de ctre
utilizator. Astfel se emuleaz bine-cunoscutul control combo-box, oferindu-se o
list de sugestii n funcie de caracterele tastate. Situl Google Suggest folosete
intensiv aceast tehnic. n acest context, putem meniona c AJAX ne poate
sluji i pentru validarea diverselor informaii obinute de la utilizator.
Alt facilitate uor de implementat via AJAX este cea de a oferi posibilitatea
efecturii de operaii drag-and-drop asupra unor zone prestabilite ale paginii Web.
n conjuncie cu o bibliotec JavaScript precum DOM-Drag, se poate astfel
implementa la nivel de aplicaie Web un comportament similar unei
interaciuni convenionale de tip MDI (Multiple Document Interface).
Diverse alte ntrebuinri ale AJAX sunt dedicate realizrii de efecte vizuale
(unele dintre ele, sofisticate), similare interaciunii cu utilizatorul n Mac OS X
sau Windows Vista.
Instrumente de dezvoltare
Actualmente sunt disponibile diverse cadre de lucru dedicate dezvoltrii aplicaiilor AJAX. La nivelul clientului pot fi folosite diferite biblioteci (e.g., Dojo,
Prototype, Rico ori Script.aculo.us), unele dintre ele oferind i suport pentru manipularea facil a arborilor DOM. Pe partea de server se poate recurge la tehnologii
precum CGI, servere de aplicaii (de exemplu, programe PHP sau servlet-uri) ori
framework-uri dedicate vezi mai jos.
Trebuie menionat faptul c o serie de companii deja au nceput s pun la
dispoziie interfee de programare AJAX specializate, pentru ca dezvoltatorii s
integreze facil coninuturi provenite de pe diverse situri n cadrul paginilor
proprii. Un exemplu notabil este Google AJAX Search API, prin care se poate
avea acces la serviciul Web de cutare direct la nivel de client, n stilul AJAX.
249
Figura 27. O aplicaie Web demonstrativ construit cu biblioteca Dojo

folosind diverse tehnici AJAX
3.3. Invocarea asincron a unui serviciu Web via AJAX

Folosirea efectiv a obiectului XMLHttpRequest i a unui intermediar scris n PHP
Vom considera scenariul: un utilizator dorete s verifice existena unui fiier
aflat pe un server, pentru aceasta trebuind s completeze un formular care i va
solicita numele fiierului n cauz. Prin intermediul AJAX, vom apela un program
PHP ce va reprezenta un client pentru serviciul Web privitor la operaii cu
fiiere, detaliat n subcapitolul 1.
250
SERVICII WEB
La apariia evenimentului de pierdere a focus-ului asupra cmpului de introducere a numelui de fiier, prin intermediul unui program JavaScript se va realiza
un transfer asincron ctre programul PHP rulnd pe server, aplicaie care va
ntoarce rspunsul privind existena numelui de fiier. n acest caz, utilizatorul va
primi imediat feedback pozitiv, suplimentar avnd posibilitatea redenumirii fiierului respectiv.
Formularul Web de interaciune cu utilizatorul are urmtoarea structur:
<form action="redenumire.php" method="get">
Numele fiierului : <input type="text" name="nume"
title="Introducei un nume de fiier"
onblur=
"javascript:verificaExist (this.value, '')" />
<span class="ascuns" id="fisierExistent">
Fiierul exist.
<input type="checkbox" value="da"
name="redenumire" checked="checked"
title="Bifai dac dorii redenumirea
fiierului" />Redenumim?
</span>
<br /><input type="submit" value="Execut" />
</form>
n cadrul unui element <span> vom insera construciile XHTML ce vor

conine mesajul afiat utilizatorului n cazul n care fiierul exist, putndu-se
bifa opiunea de redenumire a acelui fiier. Iniial, acest element va fi ascuns i
va fi afiat prin modificarea proprietii de stil display oferit de CSS.
Clasele de proprieti CSS sunt specificate n antetul documentului XHTML
n maniera de mai jos:
input[type="text"]:focus {
background:
#EEE;
border-color: #000;
}
.exista { /* pentru semnalarea exist. fiierului */
display:
block;
background:
#CCF;
border-width: 1px;
border-style: dotted;
padding:
0.2em;
width:
233px;
}
.ascuns { /* pentru ascunderea mesajului */
display:
none;
}
251
La apariia evenimentului onblur va fi apelat funcia JavaScript verificaExist()

care va avea ca responsabilitate efectuarea transferului asincron ctre un program
PHP rulnd pe server ce va apela metoda de verificare a existenei fiierului,
metod implementat de serviciul Web conceput n limbajul Perl. Att cererea,
ct i rezultatul obinut vor fi marcate n XML.
Codul-surs al funciei verificaExist() este urmtorul:
function verificaExist (nume, raspuns) {
// avem un rspuns?
if (raspuns != '') {
// prelum via metodele DOM
// elementul cu id='fisierExistent'
// pentru a afia mesajul dorit
mesaj = document.getElementById ('fisierExistent');
// schimbm stilul de afiare (n caz de succes
// vor fi aplicate proprietile CSS din
// clasa 'exista', altfel textul va fi ascuns)
mesaj.className =
(raspuns == 1) ? 'exista' : 'ascuns';
}
else {
// nu e nici un rspuns setat, vom verifica
// trimind o cerere asincron ctre server
incarcaXML ('/verifica_exist.php?nume=' + nume);
}
}
Cererea asincron ctre programul PHP va fi realizat de funcia incarcaXML()

avnd codul dat n continuare:
var cerere; // cererea ctre serverul Web
// ncarc un document XML desemnat de 'url'
function incarcaXML (url) {
// verificm existena obiectului XMLHttpRequest
if (window.XMLHttpRequest) {
// exist suport nativ (Mozilla Firefox)
cerere = new XMLHttpRequest ();
// se stabilete funcia de tratare
// a strii ncrcrii
cerere.onreadystatechange = trateazaCererea;
// prelum documentul prin metoda GET
cerere.open ("GET", url, true);
cerere.send (null);
}
else if (window.ActiveXObject) {
cerere = new ActiveXObject ("Microsoft.XMLHTTP");
// se poate folosi obiectul ActiveX din MSIE
252
SERVICII WEB
if (cerere) {
// prelum documentul prin metoda GET
cerere.open ("GET", url, true);
cerere.send ();
}
Se verific disponibilitatea obiectului XMLHttpRequest n cadrul navigatorului

Web, iar maniera de transfer se va realiza prin metoda GET a protocolului
HTTP. Tratarea evenimentelor de transmisie asincron a datelor are loc n
funcia trateazaCererea() a crei implementare este furnizat mai jos:
function trateazaCererea () {
// verificm dac ncrcarea s-a terminat cu succes
if (cerere.readyState == 4) {
// verificm dac am obinut codul de stare '200 Ok'
if (cerere.status == 200) {
// procesm datele recepionate (prelum via DOM
// elementul-rdcin al documumentului XML)
raspuns = cerere.responseXML.documentElement;
metoda = raspuns.getElementsByTagName(
'metoda')[0].firstChild.data;
rezultat = raspuns.getElementsByTagName(
'rezultat')[0].firstChild.data;
// evalum metoda
eval ( metoda + '(\'\', rezultat)');
}
// se pot trata i alte coduri (404, 500 etc.)
else {
alert ("A aprut o problem la transferul XML:\n"
+ cerere.statusText);
}
}
}
Datele XML care vor fi recepionate reprezint un nume de metod n

acest caz, verificaExist() i rezultatul ntors de aceasta. Aceste date vor fi
prelucrate doar n caz de succes (codul de stare HTTP va fi 200).
Programul PHP ce verific existena fiierului pe baza numelui recepionat de
la utilizator via AJAX are urmtorul cod-surs:
<?php
require_once('lib/nusoap.php');
// trimitem tipul coninutului
253
header ('Content-type: text/xml');

// funcie care verific dac exist un fiier
function verifica ($nume) {
// instaniem un client SOAP
'http://endirra.ro:3333/xml-files.pl');
// prelum posibilele erori
$eroare = $client->getError();
if ($eroare)
return 0;
// stabilim parametrii de intrare ai metodei invocate
$param = array('filename' => $nume);
// stabilim spaiul de nume folosit
$spatiu_nume = 'http://127.0.0.1:3333/XMLFiles/';
// realizm apelul
$rezult = $client->call('CheckIfExists',
array('parameters' => $param),
$spatiu_nume, '', true);
// verificm dac exist vreun fault
if ($client->fault)
return 0;
// eroare la executie?
$eroare = $client->getError();
if ($eroare)
return 0;
// ntoarcem rezultatul oferit de metoda invocat
return $rezult;
}
// generm coninutul XML
echo '<?xml version="1.0" ?>';
?>
<raspuns>
<metoda>verificaExist</metoda>
<rezultat>
<?php echo verifica ($_REQUEST['nume']); ?>
</rezultat>
</raspuns>
Trebuie invocat metoda CheckIfExists implementat de serviciul Web creat n

Perl.
Programul PHP recurgnd la funcionalitile oferite de biblioteca NuSOAP
devine n acest moment client al serviciului, funcionnd ca un intermediar ntre
script-ul JavaScript rulnd n browser i serviciul Web executat pe un server aflat
la distan. Cele trei categorii principale de entiti de calcul implicate n aceast
aciune sunt ilustrate de figura 28.
254
SERVICII WEB
Figura 28. Relaiile ntre programul JavaScript, script-ul PHP

i serviciul Web implementat n Perl
Tipul coninutului generat va fi XML, ateptat pe partea de client de ctre

programul JavaScript.
Figura urmtoare reprezint o captur-ecran oferind mesajul obinut de
utilizator n cazul n care introduce un nume de fiier existent, cu posibilitatea
redenumirii acestuia.
255
Figura 29. Mesajul obinut n urma introducerii unui nume de fiier existent
Apelnd script-ul PHP n mod explicit introducnd n browser o adres de

genul http://endirra.ro/verifica_exist.php?filename=inexistent , obinem documentul
XML ilustrat de figura 30. Acest document ncapsuleaz de fapt rspunsul
prelucrat n cadrul programul JavaScript descris anterior.
Figura 30. Documentul XML furnizat de programul PHP

de verificare a existenei unui fiier
Din cele descrise mai sus, se poate observa faptul c script-ul PHP funcioneaz
ca un intermediar (proxy), realiznd inter-operabilitatea ntre programul JavaScript
rulat n cadrul browser-ului i serviciul Web Perl invocat pe un server diferit de
cel n care se execut codul PHP. Am ales modelul descris aici, deoarece serviciul
Web poate s nu fie disponibil pe aceeai main pe care ruleaz codul PHP
invocat prin obiectul XMLHttpRequest.
La apsarea butonului de tip submit va fi apelat script-ul redenumire.php, care va
trebui s invoce metoda de redenumire a fiierului, metod implementat de
serviciul Web. Scrierea acestui program rmne ca tem de acas pentru cititorul
interesat.
3.4. Utilizarea bibliotecii Prototype

O soluie alternativ la precedenta este aceea n care recurgem la biblioteca
Prototype, care pune la dispoziie o suit de clase i extensii DOM (Document Object
Model) pentru facilitarea unei interaciuni Web flexibile pe partea client, n
256
SERVICII WEB
JavaScript. Una dintre funcionalitile pe care o vom utiliza se refer tocmai

la implementarea unui mecanism robust, independent de navigator, de transfer
asincron de date n stilul AJAX. Astfel, pagina Web care solicit utilizatorului
un nume de fiier pentru a verifica existena sa pe server are urmtorul
cod-surs:
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
lang="ro" xml:lang="ro">
<head>
<title>AJAX + SOAP</title>
<style type="text/css">
.exista { /* pt. semnalarea existenei fiierului */
display:
block;
background:
#CCF;
border-width: 1px;
border-style: dotted;
padding:
0.2em;
width:
233px;
}
.ascuns { /* pt. ascunderea mesajului */
display: none;
}
</style>

<script type="text/javascript"
src="prototype.js"></script>
<script type="text/javascript">
// lista de tratare a evenimentelor
// de ncrcare asincron
var globalHandlers = {
// la crearea conexiunii cu serverul
onCreate: function () {
// afim un mesaj temporar
Element.show ('asteptare');
},
// la apariia unei erori
onFailure: function() {
alert ('Eroare de transmitere.');
},
// la apariia unei excepii
onException: function() {
alert ('A aprut o excepie.');
}
};
// funcie care verific existena

// numelui de fiier via AJAX
function verificaExist () {
// nregistrm funciile de tratare a evenimentelor
Ajax.Responders.register (globalHandlers);
// instaniem obiectul AJAX
var obAjax = new Ajax.Request (
'/ajax/verifica_exist.php', // URI-ul invocat
{
method: 'get',
// parametrii transmii spre server
parameters: 'nume=' + $F('nume'),
// metoda apelat la terminarea transferului
onComplete: afiseaza
});
}
// funcie responsabil cu afiarea rezultatului
function afiseaza(rasp) {
// ascundem mesajul temporar
Element.hide ('asteptare');
// prelum valoarea rezultatului
// printr-o expresie regulat,
// deoarece rspunsul e un ir de caractere
var pattern =
new RegExp("\<rezultat\>1\<\/rezultat\>");
// modificm clasa CSS corespunztoare
// elementului <span> iniial ascuns
$('fisierExistent').className =
(pattern.test(rasp.responseText)) ?
'exista' : 'ascuns';
}
</script>
</head>
<body>
<form action="redenumire.php" method="get">
Numele fiierului : <input type="text" id="nume"
title="Introducei un nume de fiier"
onblur="javascript:verificaExist ()" />
<span id="asteptare"
style="display:none;color:#990;font-style:italic">
Ateptai, v rugm...</span>
<span class="ascuns" id="fisierExistent">
Fiierul exist.
<input type="checkbox" value="da"
name="redenumire" checked="checked"
title="Bifai dac dorii redenumirea
257
258
SERVICII WEB
fiierului" />Redenumim?
</span>
<br />
<input type="submit" value="Execut" />
</form>
</body>
</html>
Evenimentele privitoare la desfurarea transferului de date ntre client i

server pot fi tratate de funcii definite de utilizator. n cazul de fa, la crearea
unui conexiuni cu serverul, vom afia un mesaj temporar ce semnaleaz utilizatorului faptul c trebuie s atepte primirea rspunsului (a se vedea figura 31).
Figura 31. Semnalarea unui mesaj de ateptare

a realizrii unui transfer asincron via AJAX
Maniera de afiare/ascundere a unui element <span id="asteptare">

este realizat de metodele show(), respectiv hide() ale clasei Element definite de
biblioteca Prototype. n caz de eroare (onFailure) sau de excepie (onException), vom
semnala aceast situaie utilizatorului via funcia JavaScript standard alert(). Ca i
n exemplul anterior, verificarea existenei fiierului se realizeaz n cadrul funciei
verificaExist(). n aceast situaie, vom instania un obiect Ajax.Request ce reprezint cererea efectuat de program ctre server, dup ce n prealabil am nregistrat
funciile de tratare a evenimentelor de transfer via Ajax.Responders.register().
Argumentele constructorului Ajax.Request() sunt, n mod firesc, adresa script-ului
PHP ce va fi invocat pe server (acelai program ca mai sus), metoda HTTP
folosit, parametrii de intrare (n cazul nostru, numele fiierului) i funcia ce va
fi apelat la finalizarea transferului asincron. Valoarea numelui de fiier este
preluat din formular prin intermediul construciei $F() specificate de Prototype.
n acest mod, putem accesa comod cmpuri din formularele Web.
Dup obinerea rezultatului va fi executat funcia afiseaza(), care are drept
argument un obiect coninnd rspunsul primit din partea serverului, n cazul
nostru, un document XML. Proprietatea responseText reprezint irul de caractere
recepionat din partea script-ului PHP, adic documentul XML ilustrat n figura 30.
Printr-o expresie regulat simpl, prelum valoarea elementului <rezultat> ,
pentru a schimba clasa CSS corespunztoare marcatorului <span> responsabil
cu semnalarea existenei fiierului i inserrii butonului de bifare a redenumirii
259
acestuia. Construcia $() este o scurttur pentru metoda getElementById() specificat de recomandarea DOM, fiind folosit pentru a selecta un anumit element
din cadrul documentului XHTML; a se revedea i capitolul 2.
O captur-ecran a dialogului ntre client i server este pus la dispoziie de
figura 32, n care se poate remarca i interfaa extensiei Firebug pentru navigatorul
Firefox, folosit n situaia de fa pentru a lista apelurile AJAX realizate i
posibilele erori survenite. Aceast extensie poate fi utilizat cu succes pentru
depanarea oricror programe JavaScript.
Figura 32. Trasarea apelurilor AJAX via extensia Firebug

pentru navigatorul Firefox
3.5. Invocarea direct, din JavaScript, a unui serviciu Web

n continuare, ne propunem s invocm direct un serviciu Web via metoda
POST. Singura restricie este ca URI-ul folosit de obiectul XMLHttpRequest
pentru trimiterea mesajului SOAP de cerere s aib acelai domeniu cu cel al
260
SERVICII WEB
serviciului (cu alte cuvinte, serviciul Web nu poate fi localizat dect pe maina pe
care rezid i programul JavaScript ce recurge la AJAX).
Ca exemplificare, presupunem c dorim s aflm stocul unui sortiment de
portocale, recurgnd la metoda furnizeazaSortiment() implementat de serviciul
Web prezentat n cadrul seciunii 1.2. Programul JavaScript folosit la invocarea
serviciului Web are codul-surs de mai jos (se poate observa c structura
general a codului e similar celei prezentate mai sus, cu deosebirea c n acest
caz vom iniia o cerere POST spre server, adresa indicat fiind cea a serviciului
Web):
// adresa de apel al serviciului Web
const URISERV =
'http://localhost/sxml/oranges-server.php';
// adresa de baz a serviciului Web
const URIBSRV = 'http://localhost/sxml/';
// spaiul de nume al serviciului Web
const URISPN = 'urn:portocale.info';
// generm mesajul SOAP de cerere
// care va fi trimis spre server
function genMesaj (numeDoc) {
// construim 'de mn' mesajul SOAP de cerere
var mesaj = "<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/envelope/\">\n"
+ "<soap:Body>\n"
+ "<furnizeazaCantit " + "xmlns=\"" +
URISPN + "\">\n"
+ "<sortiment>" + numeDoc + "</sortiment>\n"
+ "</furnizeazaCantit>\n"
+ "</soap:Body>\n"
+ "</soap:Envelope>\n";
return mesaj;
}
// invocm metoda de validare
function invoca (numeDoc) {
var mesaj = genMesaj (numeDoc);
try {
if (window.XMLHttpRequest) { // doar pentru Firefox
cerere = new XMLHttpRequest ();
}
// stabilete funcia de tratare a strii ncrcrii
261
// trimitem cererea SOAP prin metoda POST

cerere.open ("POST", URISERV, true);
// stabilim tipul coninutului
cerere.setRequestHeader("Content-Type", "text/xml");
// stabilim valoarea cmpului SOAPAction
cerere.setRequestHeader("SOAPAction",
URIBSRV + 'furnizeazaCantit');
cerere.send (mesaj);
document.getElementById("txtCerere").value = mesaj;
}
catch (except) {
alert ('A intervenit o excepie: ' + except);
}
}
// funcie care trateaz starea conexiunii cu serverul

function trateazaCererea () {
// transferul s-a efectuat complet
if (cerere.readyState == 4) {
var raspuns = cerere.responseXML;
// a aprut o eroare?
if (cerere.status != 200) {
alert("A aprut o eroare...\n" +
cerere.statusText +
cerere.getAllResponseHeaders());
return;
}
// furnizm rspunsul primit de la server
document.getElementById("txtRaspuns").value =
raspuns.getElementsByTagName(
'Body')[0].firstChild.firstChild.firstChild.data;
return;
}
}
Mesajul ce va fi transmis ctre server este confecionat manual, construind n

acest mod plicul SOAP. n caz de eroare la ntoarcere rspunsului, afim i
anteturile HTTP primite de la server via getAllResponseHeaders(). Valoarea stocului de
portocale reprezint n fapt elementul strnepot al elementului Body al rspunsului
SOAP (folosim proprietatea firstChild pus la dispoziie de modelul DOM).
Formularul XHTML care preia de la utilizator numele unui sortiment de
portocale i afieaz rspunsul primit, inclusiv structura cererii SOAP efectuate,
are urmtorul cod:
<form>
Numele sortimentului :
<input type="text" name="nume"
262
SERVICII WEB
title="Introduceti un sortiment de portocale"

onblur="javascript:invoca (this.value)" />
<br />

<textarea rows="10" cols="60"
id="txtCerere"></textarea>
<p>Stocul din sortimentul dorit este
<input type="text" id="txtRaspuns"></input>.</p>
</form>
Un posibil rezultat este disponibil n figura de mai jos.
Figura 33. Rezultatul primit de la o metod

a unui serviciu Web invocat direct via XMLHttpRequest
263
3.6. Transferuri asincrone prin Atlas ASP.NET

La finalul acestui subcapitol vom prezenta succint cadrul de lucru Atlas ASP.NET,
conceput special de Microsoft pentru realizarea de aplicaii AJAX n contextul
ASP.NET versiunea 2.0, dar putnd fi folosit i n conjuncie cu alte tehnologii de programare a aplicaiilor Web, de exemplu PHP a se vizita adresa
http://www.shankun.com/Atlas_Php_2.aspx. De asemenea, partea JavaScript facilitnd transferurile asincrone e compatibil cu mai multe navigatoare, fr a
trebui s recurgem n mod necesar la Internet Explorer.
Pentru a utiliza Atlas, cunotinele pe care trebuie s le dein programatorul
n ceea ce privete tehnologia ASP.NET vor putea fi minimale.
Pentru redarea datelor la nivelul clientului, se ofer un set de controale de
interfa, n stilul ASP.NET, ale cror proprieti pot fi stabilite fie declarativ
(prin construcii XML), fie prin intermediul codului JavaScript. Aceste controale
vor rula n fapt pe server, mediul avnd n responsabilitate generarea de marcaje
(plus programe JavaScript), n funcie de browser-ul folosit. Funcionalitatea este
ncapsulat de un assembly numit Microsoft.Web.Atlas.dll.
O parte dintre controalele deja existente n ASP.NET sunt extinse pentru a
oferi faciliti suplimentare, n stilul AJAX. De asemenea, cmpurile de tip text
pot avea ataat un mecanism de autocompletare a datelor (vezi exemplul de mai
jos), iar coninutul unor zone din cadrul documentului Web pot fi remprosptate
periodic (via UpdatePanel). Diverse elemente dintr-o pagin pot interaciona prin
intermediul tehnicilor drag-and-drop, putnd fi astfel mutate/ascunse dinamic. Mai
mult dect att, tere componente pot mbogi paleta controalelor existente;
astfel, n Atlas pot fi incluse funcionaliti noi.
Accesul la datele de pe server se realizeaz prin apeluri asincrone de metode
ale unor servicii Web locale (codul acestora trebuie s rezide pe aceeai main
pe care exist situl), conform modelului de securitate impus de JavaScript.
Aceste servicii Web vor fi construite conform modalitilor oferite de ASP.NET.
Mediul are rolul de a realiza transferul efectiv al datelor codificate conform
conveniei JSON ntre controalele interactive i server.
Invocarea serviciilor externe se poate realiza prin aa-numita punte (bridge),
cod inclus n fiiere cu extensia .asbx, ce va facilita dialogul cu servicii rulnd pe
alte calculatoare. Un astfel de exemplu de fapt l-am implementat mai sus, n
seciunea 3.3, dar printr-un intermediar scris n limbajul PHP.
Alte detalii privitoare la arhitectura i modul de programare sunt disponibile
n documentaiile i exemplele oferite pe situl Atlas.
Drept exemplificare (o adaptare dup una dintre soluiile din tutorialele
oficiale), ne propunem s punem utilizatorului la dispoziie o facilitate de
264
SERVICII WEB
sugerare a numelor unor sortimente de portocale, pe baza caracterelor deja

testate de acesta. E vorba, aadar, de asocierea unui mecanism de autocompletare
de date pentru un cmp textual al unui formular Web. Datele privitoare la
sortimentele de portocale vor fi furnizate de un serviciu Web, care le va prelua
dintr-un fiier text (desigur, scenarii mai complexe vor putea recurge la interogri
SQL ori la preluarea informaiilor din surse multiple).
Atlas impune ca serviciul Web utilizat s aib o unic metod ce va fi invocat
pe server, n manier asincron, la apariia unui eveniment (apsarea unui buton,
introducerea unor caractere, la momente periodice de timp, la micarea cursorului
mouse-ului etc.). Aadar, vom dezvolta un serviciu Web stocat de fiierul
Portocale.asmx. Pentru aceasta, vom folosi ablonul Atlas Web Site pentru Visual
Web Developer Express (funcioneaz i n Visual Studio .NET), pus la dispoziie
n momentul instalrii distribuiei Atlas preluate de pe Web. Ulterior, vom ataa
(bind) acest serviciu unui control autoComplete dintr-o pagin ASP.NET.
Codul-surs este urmtorul a se observa existena unei singure metode,
denumit furnizeazaSortimente.
<%@ WebService Language="C#"
Class="Portocale.Portocale" %>
using System;
using System.IO;
using System.Collections;
namespace Portocale {
[WebService(Namespace = "urn:portocale.info")]
[WebServiceBinding(ConformsTo =
WsiProfiles.BasicProfile1_1)]
public class Portocale :
System.Web.Services.WebService {
// lista sortimentelor ncrcate dintr-un fiier
private static string[] sortimente = null;
// furnizeaz o list de sortimente ale cror nume
// sunt prefixate de un sir dat
[WebMethod]
public String[] furnizeazaSortimente
(string prefixText, int count) {
// 'prefixText' i 'count' sunt denumiri
// standard ai parametrilor de intrare trimii
// de controlul 'autoComplete'
string prefix = prefixText;
int lungMax = count;
// nc nu exist, ncrcm din fiier
265
if (sortimente == null) {
String[] temp = File.ReadAllLines(
Server.MapPath("~/sortim_portocale.txt"));
// sortm elementele pentru a putea realiza
// cutarea binar
Array.Sort(temp,
new CaseInsensitiveComparer());
sortimente = temp;
}
// realizm cutarea i extragem maximum 'contor'
// sortimente care se potrivesc prefixului
// preluat de la client
int index = Array.BinarySearch(sortimente,
prefix, new CaseInsensitiveComparer());
if (index < 0) {
index = ~index;
}
int potriviri;
for (potriviri = 0; potriviri < lungMax &&
index + potriviri < sortimente.Length;
potriviri++) {
// verificm dac ncepe cu prefixul dat
if (!sortimente[index +
potriviri].StartsWith(prefix,
StringComparison.CurrentCultureIgnoreCase)) {
break;
}
}
// copiem rezultatul obinut
String[] rezultat = new string[potriviri];
if (potriviri > 0) {
Array.Copy(sortimente, index, rezultat,
0, potriviri);
}
// transmitem spre client tabloul de iruri
return rezultat;
Desigur, putem invoca n mod explicit metoda definit mai sus. Primul
parametru de intrare reprezint prefixul, care trebuie s se potriveasc fiecruia
dintre elementele listei de sortimente, iar al doilea specific numrul maxim de
sortimente ce vor fi ntoarse. Datele vor fi sortate, iar cutarea va fi realizat prin
metoda cutrii binare, indiferent dac literele sunt minuscule sau majuscule.
266
SERVICII WEB
Un posibil rezultat, cu prefixText = a i count = 10, este documentul XML

dat n continuare:
<?xml version="1.0" encoding="utf-8"?>
<ArrayOfString
xmlns="urn:portocale.info">
<string>Acre</string>
<string>Albastre</string>
<string>Albe</string>
<string>Argintii</string>
<string>Aspre</string>
<string>Aurii</string>
</ArrayOfString>
Va trebui s scriem o pagin ASP.NET care s ofere un formular Web unde

utilizatorul s fie ndemnat s furnizeze un nume de sortiment de portocale. La
introducerea mcar a unui caracter, pe baza prefixului deja inserat n cmpul
formularului, va trebui iniiat un transfer asincron care s invoce metoda
furnizeazaSortimente(). Rezultatul acesteia va fi afiat ca list de sugestii ntr-un
<div>, utilizatorul putnd selecta unul dintre sortimentele aprute.
Codul XHTML al formularului este urmtorul:
<form id="formular" action="" runat="server">
<div>Introducei un sortiment:
<input id="sortiment" type="text" /></div>

<div id="listaSortimente"></div>
</form>
Iniial, marcatorul <div> cu id=listaSortimente va fi ascuns, fiind completat

de ctre Atlas la obinerea listei de sortimente ntoarse de serviciul Web.
Elementului <input id="sortiment" type="text" /> va trebui s-i atam comportamentul de autocompletare, stabilind de asemenea i metoda serviciului Web
ce va avea n responsabilitate returnarea listei de sugestii.
Vom adopta metoda declarativ, la finalul paginii insernd liniile de mai jos:
<script type="text/xml-script">
<page xmlns:script=
"http://schemas.microsoft.com/xml-script/2005">
<components>
<textBox id="sortiment">
<behaviors>
267

<autoComplete
completionList="listaSortimente"
serviceURL="Portocale.asmx"
serviceMethod="furnizeazaSortimente"
minimumPrefixLength="1"
completionSetCount="15"
completionInterval="500" />
</behaviors>
</textBox>
</components>
</page>
</script>
Se poate deduce uor faptul c pentru controlul de tip text cu id="sortiment"

se asociaz un marcator XHTML ce va conine rezultatul metodei serviciului
Web invocat, unde lungimea prefixului trebuie s fie minimum 1 (aceast valoare
o va avea parametrul prefixText de mai sus), mulimea elementelor sugerate va fi
de maxim 15 (parametrul count va avea asociat aceast valoare) i intervalul de
completare va fi de 500 de milisecunde.
Maniera efectiv de transfer asincron al datelor ntre client i server este
realizat n mod transparent de ctre Atlas. n captura-ecran de mai jos pot fi
urmrite informaiile despre sortimentele sugerate la introducerea literei A de
ctre utilizator, plus apelurile AJAX dintre pagin i serviciul Web. Putei remarca
faptul c datele vehiculate sunt codificate n stilul JSON (n cazul nostru,
parametrii de intrare sunt perechi nume-valoare incluse ntr-o list, iar rezultatul
obinut reprezint un tablou de iruri de caractere).
Din moment ce vom selecta unul dintre sortimente, acesta va fi automat
introdus ca text n cadrul cmpului formularului Web.
Dorim s adugm i un buton etichetat Alege, la apsarea cruia s fie
invocat tot n manier asincron un alt serviciu Web, care s realizeze o
anumit aciune (n acest caz, va ntoarce un ir de caractere ce va fi redat fr
a se realiza rencrcarea ntregului document). Astfel, putem remprospta
diverse zone ale paginii, fie n mod explicit, fie periodic sau n funcie de ali
factori.
268
SERVICII WEB
Figura 34. Folosirea unui control de tip autoComplete n Atlas ASP.NET
Pentru aceasta, va trebui s mai concepem un serviciu Web CantitPortocale.asmx

al crui cod C# simplu e dat n continuare (omitem construciile neeseniale):
// afieaz sortimentul preluat de la client
[WebMethod]
public String listeazaSortiment (string query) {
// prelum parametrul
string sortiment = Server.HtmlEncode(query);
// dac nu exist sau e vid,
// ntoarcem un mesaj de avertizare
if (!String.IsNullOrEmpty(sortiment)) {
return String.Format("Ai ales sortimentul {0}!",
sortiment);
}
269
else {
return "Parametrul de intrare primit e vid...";
}
Este disponibil o singur metod care preia valoarea unui control ASP.NET
via obiectul Server i ntoarce un ir de caractere. Desigur, mai util pentru
utilizator ar fi fost s obin stocul de portocale din respectivul sortiment; acesta
este ns un exerciiu uor de implementat de ctre cititor.
La formularul descris mai sus, vom aduga urmtoarele:

<input id="alege" type="button" value="Alege"
onclick="javascript:Invoca()" />
<div id="rezultat"></div>
Dup cum se remarc, la apsarea butonului va fi invocat metoda

listeazaSortiment(), de data aceasta via JavaScript. Rezultatul va fi coninut de un
element <div>. Funcia Invoca() are liniile de mai jos:
function Invoca() {
// prelum sortimentul
var sortim = document.getElementById("sortiment");
// invocm metoda
Portocale.CantitPortocale.listeazaSortiment
(sortim.value, TrateazaTransfer);
}
function TrateazaTransfer (rezultat) {
// inserm rezultatul n <div>
document.getElementById("rezultat").innerHTML =
rezultat;
}
Cu getElementById() oferit de DOM prelum numele sortimentului i invocm

metoda serviciului Web se folosete forma SpatiuDeNume.ServiciuWeb.Metoda().
Primul argument este tocmai parametrul de intrare al metodei, iar al doilea
desemneaz funcia JavaScript ce va fi apelat la terminarea transferului. Nu
facem dect s inserm n marcatorul <div> rezultatul obinut de la server.
Ca mediul Atlas s poat realiza managementul transferului de date, n antetul
paginii trebuie s introducem o referin la serviciul Web invocat:

<atlas:ScriptManager runat="server" id="Atlas">
<services>
270
SERVICII WEB
<atlas:servicereference
path="~/CantitPortocale.asmx"
type="text/javascript" />
</services>
</atlas:ScriptManager>
La rulare, vom obine un rezultat precum cel din figura 35.
Figura 35. Actualizarea coninutului fr rencrcarea ntregului document
Alte abordri AJAX pentru .NET sunt AJAX.NET, MagicAjax.NET, JSON.NET

i xap4net.
Cele descrise mai sus pot fi realizate i n Java, prin intermediul framework-ului
DWR (Direct Web Remoting) sau via jMaki, SWATO ori Taconite. De asemenea,
Google pune la dispoziie GWT (Google Web Toolkit), scopul acestui instrument
fiind cel de a oferi suport pentru scrierea n Java de aplicaii orientate spre
AJAX. Pentru PHP, se poate recurge la pachetul HTML::AJAX, disponibil n
colecia PEAR, iar programatorii Perl pot utiliza extensiile Mason pentru AJAX.
Alte cadre de lucru ofer suport pentru AJAX n mai multe limbaje de
programare, de menionat fiind CPAINT (Cross-Platform Asynchronous Interface
Toolkit), JSON-RPC i Sajax. Nu trebuie uitat nici Ruby on Rails, unul dintre
271
framework-urile de dezvoltare a aplicaiilor Web pe partea de server foarte

cunoscute n acest moment, cu suport pentru AJAX.
n funcie de preferine, de cerinele problemei, de avantaje i/sau de
platform, dezvoltatorul poate adopta una dintre soluiile disponibile.
Referine
Alboaie, L, Buraga, S., Dialoguri despre SOAP, NET Report, februarie 2003:
http://www.infoiasi.ro/~busaco/publications/articles/SOAP.pdf
Asleson, R., Schutta, N., Foundations of AJAX, Apress, 2006
books/xml/
Buraga, S., Tehnologii Web, Matrix Rom, Bucureti, 2001: http://www.infoiasi.ro/
~busaco/books/web.html
Buraga, S., Ciobanu, G., Atelier de programare n reele de calculatoare, Polirom, Iai, 2001:
http://www.infoiasi.ro/~lrc/
Buraga, S. et al., Programare Web n bash i Perl, Polirom, Iai, 2002: http://www.infoiasi.ro/
~cgi/
Buraga, S. (coord.), Situri Web la cheie. Soluii profesionale de implementare, Polirom, Iai,
2004: http://www.infoiasi.ro/~busaco/books/webapps/
Buraga, S. (coord.), Tendine actuale n proiectarea i dezvoltarea aplicaiilor Web, Matrix Rom,
Bucureti, 2006: http://www.infoiasi.ro/~busaco/books/nw05/
Dospinescu, O., Dezvoltarea aplicaiilor n Visual Basic .NET, Polirom, Iai, 2004
Eernisse, M., A Simpler Ajax Path, OnLamp.com, 2005: http://www.onlamp.com/
pub/a/onlamp/2005/05/19/xmlhttprequest.html
Kulchenko, P., Ray, R., Programming Web Services with Perl, OReilly, 2002
Mueller, J., Mining Google Web Services: Building Applications with the Google API, Sybex, 2004
Pereira, S., Developer Notes for prototype.js: http://www.sergiopereira.com/articles/
prototype.js.html
Perry, B., AJAX Hacks, OReilly, 2006
Powell, T., Schneider, F., JavaScript 2.0: The Complete Reference (Second Edition), McGraw-Hill/
Osborne, 2004
Swart, B., Delphi 6 Web Services: SOAP, The Delphi Magazine, Issue 72, August 2001:
http://www.thedelphimagazine.com/Samples/1273/article.html
Tanas, ., Olaru, C., Dezvoltarea aplicaiilor Web folosind Java, Polirom, 2005
Wood, K., Delphi Developers Guide to XML, Wordware Publishing, 2001
Zakas, N., McPeak, J., Fawcett, J., Professional AJAX, Wrox Press, 2006
Zametti, F. et al., Survey of AJAX/JavaScript Libraries, OSAF.com, 2005: http://
wiki.osafoundation.org/bin/view/Projects/AjaxLibraries
* * *, AHAH (Asynchronous HTML and HTTP): http://microformats.org/wiki/rest/
ahah
272
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
SERVICII WEB
*, Ajaxian: http://www.ajaxian.com/
*, AJAX Components for Java: http://blueprints.dev.java.net/ajaxcomponents.html
*, Apache2Triad: http://apache2triad.sourceforge.net/
*, Apache Axis2: http://ws.apache.org/axis2/
*, Apache Geronimo: http://geronimo.apache.org/
*, Apache XML Activity: http://xml.apache.org/
*, Atlas ASP.NET: http://atlas.asp.net/
*, Biblioteca NuSOAP: http://dietrich.ganx4.com/nusoap/
*, CPAN (Comprehensive Perl Archive Network): http://cpan.perl.com/
*, Developer: http://www.developer.com/
*, Dojo: http://dojotoolkit.org/
*, DOM-Drag: http://www.youngpup.net/2001/domdrag/
*, DWR (Direct Web Remoting): http://getahead.ltd.uk/dwr/
*, ECMA (European Computer Manufacturers Association): http://www.ecma-international.org/
*, Extensia de depanare Firebug: http://www.joehewitt.com/software/firebug/
*, Google API: http://www.google.com/apis/
*, Google AJAX Search API: http://code.google.com/apis/ajaxsearch/
*, GWT (Google Web Toolkit): http://code.google.com/webtoolkit/
*, Instrumentul gSOAP: http://gsoap2.sourceforge.net/
*, Mason: http://masonhq.com/
*, Microsoft Visual Studio Express: http://msdn.microsoft.com/vstudio/express/
*, Modulul SOAP::Lite: http://www.soaplite.com/
*, Modulul SOAP::MIME: http://sourceforge.net/projects/soapmime
*, MSDN (Microsoft Developer Network): http://msdn.microsoft.com/
*, OReilly OnLAMP: http://www.onlamp.com/
*, PEAR (PHP Extensions and Add-ons Repository): http://pear.php.net/
*, Portal dedicat serviciilor Web: http://www.webservices.org/
*, Proiectul jMaki: https://ajax.dev.java.net/
*, Sajax: http://www.modernmethod.com/sajax/
*, Situl bibliotecii Prototype: http://prototype.conio.net/
*, Situl oficial PHP: http://www.php.net/
*, World Wide Web Consortium, Boston, 2006: http://www.w3.org/
*, XML.com: http://www.xml.com/
Capitolul 7
Retrospectiv i perspective
Realitatea trebuie neleas numai prin spargerea
ei n pri ct mai mici.
(Ren Descartes)
1. Procesul de dezvoltare a serviciilor Web

Recapitulnd cele prezentate n capitolele anterioare, procesul de dezvoltare a
serviciilor Web implic trei categorii de activiti (a se urmri i figura 1):
oferirea de servicii, ceea ce presupune dezvoltarea propriu-zis a serviciilor puse
la dispoziie ntr-un mediu de tip enterprise, plus expunerea unei documentaii
(descrieri) privitoare la interfaa serviciilor; implementarea poate fi realizat
pe baza limbajelor de programare, cadrelor de lucru i platformelor actuale,
iar descrierile sunt specificate via WSDL i alte metode adiionale;
organizarea (catalogarea) serviciilor Web conform unor criterii viznd tipul de
afacere modelat, localizarea ofertantului, industria considerat etc; n acest
sens, una dintre iniiativele majore este reprezentat de UDDI; prin intermediul UDDI, un ofertant de servicii poate fi uor contactat de ctre posibilii
solicitani (clieni);
solicitarea de servicii fie direct, atunci cnd interfaa acestora este deja cunoscut,
fie indirect via UDDI; solicitantul i va proiecta aplicaia dorit i va invoca
funcionalitile serviciilor conform documentului WSDL asociat fiecrui
serviciu n parte ori apelnd la o interfa de programare (API) specific.
Schimbul de date ntre serviciu i client se va realiza n mod uzual prin
intermediul SOAP, folosindu-se un protocol de transport oferit de Internet
(cel mai frecvent, se recurge la HTTP). O alternativ la SOAP este dat de
modelul REST, n care mesajele interschimbate, marcate de asemenea n
XML, sunt transferate direct prin HTTP, fr a fi ncapsulate n plicuri.
274
SERVICII WEB
Figura 1. Activitile desfurate n dezvoltarea serviciilor Web
Acest proces are loc n cadrul unui mediu orientat spre servicii, respectndu-se
principiile arhitecturale SOA (Service-Oriented Architecture) pe care le-am prezentat
n cadrul primului capitol al acestei lucrri.
O aplicaie Web proiectat pe baza SOA poate fi compus din diverse straturi
funcionale, conform celor ilustrate de figura 2.
Figura 2. Structura aplicaiilor software axate pe SOA
RETROSPECTIV I PERSPECTIVE
275
2. Alte iniiative viznd serviciile Web

2.1. Privire de ansamblu
n ceea ce privete dezvoltarea de aplicaii SOA n general i de servicii Web n
particular, tehnologiile SOAP, WSDL i UDDI nu sunt singulare, actualmente
fiind disponibile o serie de specificaii i iniiative adiionale privitoare la:
1.
2.
3.
4.
5.
6.
modul de adresare: WS-Addressing;

inspecie i descoperire: WS-Inspection, WS-Discovery;
mesagerie: WS-ReliableMessaging, WS Attachments, WS-Routing etc.;
securitate i autorizare: WS-Security, WS-Trust, WS-Policy i altele;
procesarea tranzaciilor: WS-Coordination, WS-Transaction;
relaia cu interfaa-utilizator: WSRP (Web Services for Remote Portlets), WSIA
(Web Services for Interactive Applications);
7. asigurarea inter-operabilitii i fluxului de activiti (workflow): BPEL (Business
Process Execution Language) i WS-Choreography.
Figura 3. Nivelurile de specificaii adiionale privitoare la serviciile Web
276
SERVICII WEB
Trebuie, de asemenea, menionat existena unei suite de specificaii complementare, concurente, care se intituleaz ebXML i care a fost n vog n perioada
2002-2005. Aceste specificaii au fost date ulterior spre standardizare organizaiei
OASIS, semnatara multor documente privitoare la diverse aspecte legate de
SOA i serviciile Web.
Vom descrie n continuare o parte dintre direciile de evoluie a serviciilor
Web, cititorii interesai putnd aprofunda aceste aspecte prin consultarea resurselor bibliografice disponibile.
2.2. Adresarea serviciilor prin WS-Addressing

Iniiativa WS-Addressing specific modul de utilizare a unor mecanisme independente de protocolul de transport folosit destinate adresrii serviciilor i
mesajelor. Specificaia, propus de IBM, definete elementele XML menite a
identifica punctele terminale ale serviciilor Web i maniera de asigurare a
securitii comunicaiilor dintre aceste puncte terminale. Sistemele de mesagerie
(messaging systems) pot realiza transportul mesajelor n cadrul unor reele de
comunicaii uzual, folosite n mediul enterprise care pot include noduri de
procesare a datelor, precum firewall-uri sau pori (gateways), indiferent de protocoalele disponibile la nivel sczut.
Din perspectiva WS-Addressing, modelul de descriere a serviciilor Web (i.e.,
WSDL) este extins prin introducerea conceptului de referin la punctele
terminale (endpoint reference). Astfel, maniera n care se specific adresa unui
serviciu Web este mai fin, deoarece nu implic doar un URI (de exemplu, pot
fi specificate meta-date suplimentare i adresele mai multor documente WSDL).
Mesajele vehiculate pot fi identificate i corelate prin anteturile MessageID i
RelatesTo, ceea ce deschide perspective interesante privind tranzaciile i fluxurile
de date. Sunt introduse i atribute precum To, From, ReplyTo i FaultTo, care pot
fi folosite de ctre agenii implicai n comunicare pentru a procesa un mesaj i
rspunsurile aferente la acesta.
2.3. Descoperirea serviciilor

n capitolul 5 am discutat deja despre maniera de descoperire a serviciilor fie n
manier centralizat via UDDI, fie descentralizat prin WS-Inspection.
n cadrul acestei seciuni, vom prezenta succint modul de descoperire
dinamic, specificat de WS-Discovery (propunere a corporaiei Microsoft). n loc
de a se stoca informaiile privitoare la servicii ntr-un catalog central, modelul
WS-Discovery adopt strategia folosit i de sistemele wireless: un serviciu Web i
277
poate anuna via mesaje multicast prezena, atunci cnd este ataat infrastructurii Internet. Un procedeu similar are loc atunci cnd serviciul prsete
reeaua. Reeaua este una constituit ad hoc, compus din entiti interesate de
serviciul respectiv (i.e., clieni care intenioneaz s invoce anumite operaii).
Limitarea traficului de mesaje poate avea loc prin constituirea unui aa-numit
proxy de descoperire (discovery proxy) care este implementat tot ca un serviciu
Web.
n afar de mesajele de tip Hello (anun al prezenei unui serviciu) i Bye
(plecarea serviciului), sunt specificate i urmtoarele dou operaii:
Probe ncearc s detecteze un anumit serviciu ori mulime de servicii prin
transmiterea unui mesaj (multicast) ctre un grup de calculatoare, rspunsul
fiind expediat direct solicitantului. Dac reeaua posed un proxy de descoperire, atunci metoda Probe va fi executat direct de ctre acesta;
Resolve intenioneaz s rezolve un serviciu, cutarea efectundu-se dup
numele acestuia, trimindu-se un mesaj n ntreaga reea. Serviciul care se
potrivete cu numele dat, va rspunde solicitantului. Acest proces este similar
celui folosit de protocolul ARP (Address Resolution Protocol).
Un exemplu de mesaj SOAP care ncapsuleaz o cerere Probe este furnizat
mai jos (pentru localizare se folosete protocolul LDAP Lightweight Directory
Access Protocol):
<env:Envelope>
<env:Header>
<wsa:Action>
http://schemas.xmlsoap.org/ws/2004/10/discovery/Probe
</wsa:Action>
<wsa:To>
urn:schemas-xmlsoap-org:ws:2004:10:discovery
</wsa:To>
</env:Header>
<env:Body>
<wsd:Probe>

<wsd:Types>sfa:Binder</wsd:Types>

<wsd:Scope MatchBy=
"http://schemas.xmlsoap.org/ws/2004/10/discovery/ldap">
ldap:///ou=info,o=uaic,c=ro
</wsd:Scope>
</wsd:Probe>
</env:Body>
</env:Envelope>
278
SERVICII WEB
Pe baza acestei iniiative i a altora nrudite (precum WS-Eventing), poate fi

constituit o infrastructur de descoperire dinamic sofisticat, oferind suport
pentru managementul serviciilor Web. Suplimentar, n conjuncie cu UPnP
(Universal Plug and Play), serviciile Web pot rula pe diverse tipuri de dispozitive,
fiind regsite n mod dinamic. De altfel, exist deja disponibil un ghid privitor
la implementarea serviciilor Web pe calculatoare cu resurse limitate, precizndu-se
un profil minimal denumit WS-DP (Device Profile for Web Services).
2.4. Coordonarea serviciilor Web

Deoarece serviciile Web pot fi incluse ntr-o arhitectur distribuit complex, se
pune problema colaborrii ntre diversele entiti software implicate pentru a
rezolva o anumit problem specific (de exemplu, oferirea unei soluii de
petrecere a vacanei de ctre un sit de tip e-travel).
Orice colaborare presupune acceptarea unui contract (agreement). Pentru
sistemele bazate pe transfer de mesaje cazul serviciilor Web , un contract, n
forma cea mai simpl, presupune respectarea unui format comun de date (e.g.,
specificat printr-o schem XML), a unui stil de transmitere a mesajelor (unidirecional, cerere/rspuns, notificare etc.) i a unei modaliti de descoperire a
participanilor la realizarea problemei. Aceasta implic o activitate de coordonare.
Cu ct interaciunile dintre servicii sunt mai sofisticate, cu att procesul de
coordonare devine mai dificil. Modul de coordonare poate fi unul centralizat,
implicnd existena unui coordonator explicit cu rol de ef, sau nu.
Iniiativa WS-ReliableMessaging
Unul dintre aspecte importante este cel referitor la realizarea de comunicaii
fiabile. Necesitatea existenei unui mecanism de asigurare a fiabilitii transferului
de date provine i din urmtoarele presupuneri greite pe care le au dezvoltatorii
de aplicaii privind un sistem distribuit (formulate de Peter Deutsch la nceputul
anilor 90 ai secolului trecut):
1.
2.
3.
4.
5.
6.
7.
8.
reeaua este fiabil (reliable);

latena datelor este nul;
limea de band e infinit;
reeaua este sigur (secure);
topologia rmne neschimbat;
exist un singur administrator;
costul transportului de date este zero;
reeaua este omogen.
279
n contextul serviciilor Web (exemple tipice de componente ale unui sistem

distribuit), se poate folosi specificaia WS-ReliableMessaging, redactat de ctre
IBM. Scopul acestui document este cel de a stabili un protocol care s permit
livrarea n siguran a mesajelor, chiar i n prezena unor erori (failures) ale
componentelor software, ale platformei utilizate ori ale reelei.
Pe baza unor informaii suplimentare ataate n antetul mesajelor SOAP,
datele pot fi grupate n secvene. Secvena de mesaje este stabilit de ctre
expeditor, iar ordinea trebuie s fie respectat atunci cnd secvena ajunge la
destinatar (nodul ultimateReceiver). Partenerii dialogului trebuie s accepte contractul privitor la secvena de mesaje vehiculate. Iniierea unei secvene are loc
prin operaia CreateSequence, iar partenerul dialogului i va arta disponibilitatea
printr-un rspuns CreateSequenceResponse. Aceast abordare nu necesit prezena
unui coordonator explicit. Fiabilitatea este asigurat prin confirmarea fiecrui
mesaj n parte via elementele Sequence, SequenceFault, SequenceAcknowledgement i
AckRequested.
Liniile de mai jos reprezint confirmarea mesajelor de la 1 la 7 i de la 9 la
10 dintr-o secven (mesajul 8 nu a fost confirmat nc):
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:rm=
"http://schemas.xmlsoap.org/ws/2005/02/rm">
<env:Header>
...
<rm:SequenceAcknowledgment>
<rm:Identifier>
...
</rm:Identifier>
<rm:AcknowledgmentRange Upper="7" Lower="1" />
<rm:AcknowledgmentRange Upper="10" Lower="9" />
</rm:SequenceAcknowledgment>
</env:Header>
<env:Body>
...
</env:Body>
</env:Envelope>
Protocolul este neutru n ceea ce privete infrastructura de transport folosit

efectiv. Transferul datelor trebuie s respecte diverse precondiii (una fiind, de
exemplu, ordinea mesajelor vehiculate). La nivelul HTTP, o iniiativ este HTTPR
(Reliable HTTP).
280
SERVICII WEB
Coordonarea explicit a serviciilor Web

O tranzacie reprezint un mecanism care asigur c toi participanii din cadrul
unei aplicaii vor obine acelai rezultat, conform unui contract (agreement) mutual
agreat. n mod tradiional, o tranzacie care are proprietile de mai jos (ntlnite
sub denumirea de ACID Atomicity, Consistency, Isolation, Durability) se numete
atomic:
atomicitate tranzacia se ncheie cu succes dac toate aciunile pe care
aplicaia trebuie s se realizeze n cadrul tranzaciei au putut avea loc; n caz
contrar, tranzacia eueaz i nici una dintre aciuni nu va fi executat
(insuccesul unei singure operaii va cauza invalidarea execuiei tuturor aciunilor din cadrul tranzaciei);
consisten tranzaciile vor produce ntotdeauna rezultate consistente i vor
pstra transformrile de stare ale aplicaiei la terminare;
izolare strile intermediare ce apar n timpul desfurrii unei tranzacii vor
fi invizibile pentru alte tranzacii; tranzaciile apar ca fiind executate secvenial,
chiar dac sunt realizate n manier concurent; aceasta se poate realiza prin
ncuierea (locking) resurselor pe durata desfurrii tranzaciei, astfel nct
nici o alt tranzacie s nu aib posibilitatea folosirii lor, evitndu-se posibilele
conflicte de acces;
durabilitate dup ce o tranzacie se finalizeaz cu succes, schimbrile
survenite pot fi gestionate pn la apariia unei erori catastrofale.
Un exemplu de tranzacie este cel referitor la oferta unui serviciu de turism,
care implic existena unui agent (travel agent) avnd rolul de a rezerva bilete la
avion (sau tren, autocar etc.), de a nchiria diverse mijloace de transport la
destinaie, de a rezerva o camer la un hotel i, eventual, de a pune la dispoziie
i alte servicii (e.g., angajarea unui ghid ori programarea unui tur de vizitare a
localitii respective). Euarea uneia dintre activitile ce compun tranzacia (de
exemplu, imposibilitatea gsirii unei soluii de cazare) conduce la abandonarea
ntregului serviciu.
n contextul serviciilor Web, compunerea unuia sau mai multor servicii
conduce la constituirea aplicaiilor tranzacionale ale cror componente sunt slab
conectate i distribuite pe sisteme eterogene i independente. Astfel, unele
proprieti ale tranzaciilor atomice pot fi aplicate, n diverse situaii, mai puin
strict.
Intervine necesitatea existenei unui mecanism flexibil de coordonare, care s
permit colaborri, fluxuri de lucru (workflow), procesare n timp real etc. n
281
unele situaii, aceast coordonare trebuie realizat explicit, interaciunea avnd

loc uzual ntre doi participani (desigur, putem generaliza la un numr oarecare
de pri componente). Coordonarea se poate desfura spontan aa cum se
ntmpl la un schimb sincronizat de mesaje de tip cerere/rspuns (invocarea
unui serviciu i obinerea rezultatului) sau printr-un coordonator. Pentru
aceast a doua situaie, a fost propus specificaia WS-Coordination, avnd drept
iniiatoare companiile BEA, IBM i Microsoft. Se precizeaz un cadru de lucru
extensibil care s ofere protocoale pentru coordonarea aciunilor desfurate de
aplicaiile distribuite.
Specificaia introduce conceptul de context de coordonare (Coordination Context),
care apare ntr-un bloc antet SOAP i care identific unic o activitate ce trebuie
desfurat n comun. Pentru a iniia o activitate executat de mai multe servicii,
un serviciu Web va expedia un context de coordonare la serviciile vizate.
Contextul va conine informaiile necesare pentru ca o entitate s decid dac
dorete s ia parte la activitatea preconizat sau s refuze propunerea. Aceste
informaii depind de specificul activitii. Mulimea tipurilor de coordonare este
deschis, noile tipuri putnd fi definite de o anumit implementare, att timp ct
toi participanii le cunosc i consimt s le foloseasc. Comportamentul unui
anumit serviciu este expus prin intermediul unui proces de nregistrare (registration)
transmis coordonatorului. Pe baza nregistrrii, pentru a rezolva o problem dat
poate fi invocat un ntreg grup de servicii.
De asemenea, serviciul coordonator are astfel posibilitatea s orchestreze
serviciile Web (vezi seciunea 2.9) i/sau s realizeze tranzacii.
Interaciunile de tip B2B (Business-to-Business) se pot desfura conform
urmtoarelor protocoale definite de WS-Coordination:
tranzacie atomic (atomic transaction) corespunde tranzaciilor cu proprietile
ACID menionate mai sus i e specificat de WS-AtomicTransaction (vezi infra);
intra-enterprise n cadrul aceleai organizaii (domeniu), tranzaciile au loc
atomic de-a lungul variatelor aplicaiilor interne;
inter-enterprise reprezint activitatea de baz desfurat n context B2B,
necesitnd un grad mare de inter-operabilitate cu sistemele tranzacionale
existente;
activitate de afaceri (business activity) necesit o flexibilitate sporit a componentelor sistemului fa de cerinele stricte ale tranzaciilor atomice (ACID).
Interaciunile pot avea loc timp ndelungat, iar serviciile sunt de cele mai
multe ori slab conectate. Restriciile privind atomicitatea i izolarea sunt
relaxate. Acest model are legtur i cu maniera de realizare a proceselor de
afaceri.
282
SERVICII WEB
Realizarea tranzaciilor atomice

Pentru specificarea tranzaciilor atomice n contextul serviciilor Web, exist
disponibil iniiativa WS-AtomicTransaction.
Iniierea unei procesri de date (vzut ca o unitate atomic) are loc prin
protocolul numit Completion. Un serviciu Web nregistrat pentru Completion are
abilitatea de a ntiina coordonatorul atunci cnd iniiaz o tranzacie. De
asemenea, acest protocol definete forma mesajelor ce pot fi folosite pentru a
comunica rezultatul final al tranzaciei iniiatorului acesteia.
Specificaia WS-AtomicTransaction pune, de asemenea, la dispoziie i protocolul
numit Two-Phase Commit. Toi participanii nregistrai trebuie s ia n comun
decizia de a duce pn la capt (commit) o tranzacie ori de a o abandona.
Suplimentar, protocolul asigur faptul c toi participanii vor fi anunai asupra
rezultatului final. Sunt definite dou variante ale protocolului: una volatil i
cealalt durabil. Protocolul volatil poate fi folosit de participani care dein
resurse volatile (e.g., cache), pe cnd cel durabil este destinat participanilor avnd
resurse considerate durabile (precum baze de date ori fiiere).
Inter-operabilitatea este asigurat graie folosirii protocolului SOAP. Politicile
de efectuare a tranzaciilor pot fi specificate prin intermediul WS-Policy, iar
aspectele legate de securitate sunt lsate n seama propunerilor WS-Security i
WS-Trust, pe care le vom prezenta mai jos.
n conjuncie cu WS-BusinessActivity, pot fi implementate tranzacii care se
desfoar timp ndelungat (de exemplu, procesri complexe).
Managementul cozilor de mesaje

Deseori, mai ales n contextul transmiterii asincrone de mesaje, apare necesitatea
utilizrii cozilor (queues) de tranzacii durabile. Comunicarea ntre entitile
participante are loc via cozi de mesaje (MQ Message Queue). Aplicaia care
expediaz datele le plaseaz n maniera unei tranzacii atomice (via
WS-AtomicTransaction) ntr-o coad. Mesajul se consider stocat cu succes n
cadrul cozii doar dac nu apare nici o excepie de procesare (adic tranzacia nu
a euat).
Subsistemul de management al cozilor va avea misiunea de livrare a mesajului
emis de expeditor ctre destinatarul final. Acest proces poate fi desfurat la un
moment de timp diferit de cel al includerii mesajului n coad. De asemenea,
locaia cozii de mesaje nu trebuie s coincid cu cea a expeditorului ori a
destinatarului.
283
Aplicaia care preia mesajul din cadrul cozii va realiza acest lucru printr-o
tranzacie atomic, astfel nct datele vor fi livrate cu succes (i eliminate din
coad) doar n cazul n care nu apar excepii de procesare la nivelul destinatarului.
2.5. Accesarea resurselor serviciilor Web

n unele situaii, schimbul de mesaje ntre un serviciu i clienii si presupune un
dialog mai complex dect o simpl pereche cerere-rspuns. De exemplu, pot
aprea cazuri n care este nevoie de specificarea transferului unor interogri de
baze de date, fluxuri de informaii multimedia, liste de enumerare a unor valori etc.
Deoarece HTTP este un protocol lipsit de stri (stateless), nu se poate cunoate
dac diverse cereri succesive provin de la acelai client. Apare necesitatea de a
prezerva anumite date de-a lungul mai multor accesri nrudite ale unui serviciu
Web. Acest aspect se realizeaz prin intermediul sesiunilor, exact ca i n cazul
aplicaiilor Web convenionale.
Pentru enumerarea datelor via mesaje succesive, se va stabili o sesiune prin
operaia Enumerate, precizat de specificaia WS-Enumeration. De asemenea, acest
document definete i modul de accesare a secvenelor de date. Sesiunea este
declarat la nivel abstract prin intermediul unui context de enumerare (enumeration
context), care reprezint un cursor logic ce parcurge o secven de informaii
oferite de o anumit surs de date (sistem de baze de date relaionale, server de
baze de date native XML etc.). Aceste date, reprezentate via XML Infoset, vor fi
livrate printr-o succesiune de mesaje SOAP.
Cea mai simpl operaie este Pull, care permite ca o surs de date, ntr-un
anumit context de enumerare, s produc o secven de elemente XML (reprezentate intern prin Infoset) ncapsulate n corpul unui mesaj SOAP. Fiecare
operaie Pull ce va urma va ntoarce urmtoarele N elemente din cadrul secvenei.
Conform WS-Enumeration, se pun la dispoziie i operaiile:
Renew utilizat s extind validitatea unui context de enumerare (remprospteaz o sesiune);
GetStatus ofer informaii privitoare la un context de enumerare;
Release elibereaz resursele deinute n cadrul unei sesiuni i elimin un
context de enumerare.
n caz de eroare (enumerarea s-a terminat neprevzut), sursa de date va
transmite un mesaj de tip EnumerationEnd.
n conjuncie cu specificaia prezentat mai sus, poate fi folosit WS-Transfer,
care are n responsabilitate definirea operaiilor de baz privitoare la managementul entitilor de date vehiculate via servicii Web.
284
SERVICII WEB
WS-Transfer definete resursa ca fiind orice entitate adresabil de o referin a

unui punct terminal, entitate ce ofer o reprezentare XML a datelor. De
asemenea, se introduce conceptul de fabric (factory): un serviciu Web care poate
construi o resurs avnd la dispoziie reprezentarea ei XML.
Sunt specificate operaii privitoare la crearea, actualizarea, obinerea i tergerea resurselor (operaii de tip CRUD Create, Retrieve, Update, Delete). Crearea
unei resurse este realizat de o fabric, aceasta constituind resursa dorit i
stabilind reprezentarea sa iniial.
Ilustrm n continuare modalitatea de creare a unei resurse privitoare la
achiziia unui sortiment de portocale:
<env:Envelope>
<env:Header>

<wsa:Action>
http://schemas.xmlsoap.org/ws/2004/09/transfer/Create
</wsa:Action>
...
</env:Header>
<env:Body>
<p:portocale p:xmlns="urn:portocale.info">
<p:achizitii>
<p:tip>Portocale greceti fr coaj</p:tip>
</p:achizitii>
</p:portocale>
</env:Body>
</env:Envelope>
Dac transferul de date se desfoar n mod asincron, posibilele evenimente,

ce pot surveni pot fi tratate prin intermediul mecanismului oferit de WS-Eventing.
Un serviciu Web (numit subscriber) i precizeaz lista evenimentelor asupra
crora este interesat (i va fi notificat), evenimente generate de alt serviciu Web
(denumit event source). Sunt precizate i operaiile ce pot fi efectuate asupra
evenimentelor sau grupurilor de evenimente. De asemenea, pot exista i entiti
de tip broker de evenimente cu rolul de a agrega ori redistribui notificri de
evenimente.
La finalul acestei seciuni, trebuie s amintim i iniiativa WS-Management, care
ofer diverse faciliti referitoare la managementul serviciilor Web (inclusiv al
resurselor transferate sau al evenimentelor de comunicare) pe baza protocolului
SOAP.
285
2.6. Accesarea meta-datelor asociate serviciilor

Pentru a facilita dezvoltarea i exploatarea serviciilor Web, fiecrui astfel de
serviciu i se pot asocia, prin intermediul meta-datelor, diverse descrieri adiionale.
Meta-datele sunt specificate ntr-un format uor de procesat de ctre calculator,
oferind suport pentru automatizarea activitilor de implementare sau de regsire
a serviciilor. De asemenea, meta-datele pot fi de folos pentru creterea gradului
de inter-operabilitate a serviciilor.
Meta-datele descriu maniera schimbului de mesaje, funcionalitile i cerinele
(requirements) asociate unui serviciu. Aceste cerine formeaz aa-numita politic
(policy) de acces. Formatele de date i abloanele de interschimb de mesaje sunt
specificate n cadrul documentelor WSDL, dup cum am vzut n capitolul 2.
Politicile de acces sunt subiectul specificaiei WS-Policy.
ntreg setul de meta-date formeaz aa-numitul contract asociat serviciului,
contract exprimat prin construcii (elemente) XML Schema, WSDL i WS-Policy
(a se vedea i figura 4).
Figura 4. Categoriile de meta-date care formeaz contractul asociat unui serviciu Web
Documentele WSDL nu sunt capabile s ofere posibilelor entiti de calcul

sau dezvoltatorilor de aplicaii informaii privitoare la diverse caracteristici
operaionale, de securitate sau referitoare la exploatarea serviciilor Web. De
exemplu, ar fi util de cunoscut dac accesarea serviciului se realizeaz pe baza
unui sistem de autentificare obligatorie, ori dac serviciul e disponibil doar ntre
anumite intervale de timp. Toate aceste meta-date pot fi exprimate via WS-Policy
pe baza unui set extensibil de aseriuni. Dac WSDL se axeaz pe unele descrieri
funcionale asociate serviciilor Web, construciile WS-Policy permit ataarea de
286
SERVICII WEB
descrieri non-funcionale sau privitoare la asigurarea calitii serviciilor. Alte

aspecte, precum cele referitoare la semantica serviciilor Web, vor putea fi
modelate de ctre alte prevederi (e.g., OWL-S). De asemenea, setul de politici
exprimate de WS-Policy nu vizeaz doar punctele terminale, aa cum se ntmpl
n cazul WSDL.
Oferim drept exemplificare urmtorul fragment de document XML care
precizeaz c un serviciu Web nu va fi disponibil ntre orele 10 i 11 n ziua de
duminic a fiecrei sptmni (politica efectiv se exprim printr-un vocabular
XML definit de noi, aparinnd spaiului de nume s):
<wsp:Policy>
<wsp:All>
<s:PlanificareRevizie>
<s:Oprire s:ziua="Duminica"
s:start="1000" s:final="1100" />
</s:PlanificareRevizie>
</wsp:All>
</wsp:Policy>
Diversele politici de acces pot fi ataate serviciilor prin intermediul WS-PA

(WS-PolicyAttachment). Maniera de interschimb de meta-date este precizat de
specificaia WS-MEX (WS-MetadataExchange), meta-datele putnd fi specificate
n diverse aa-numite dialecte (XML Schema, WSDL, WS-Policy etc.). Un exemplu
de cerere de furnizare a meta-datelor privitoare la politicile de acces este
urmtorul:
<wsx:GetMetadata>
<wsx:Dialect>
http://schemas.xmlsoap.org/ws/2002/12/policy
</wsx:Dialect>
</wsx:GetMetadata>
2.7. Securitatea serviciilor Web

Aspecte generale privind securitatea
Securitatea joac un rol esenial n dezvoltarea serviciilor Web. n mod general,
aspectele privind securitatea datelor iau n consideraie confidenialitatea, autentificarea, autorizarea, integritatea, nerepudierea, intimitatea (privacy) i disponibilitatea.
Confidenialitatea se refer la imposibilitatea unei tere entiti s aib acces la
datele vehiculate ntre doi receptori. O soluie ar fi aceea a constituirii unei
conexiuni private ntre cele dou puncte terminale ale canalului de comunicaie,
287
datele circulnd printr-un tunel oferit de o reea privat virtual (VPN Virtual
Private Network). A doua soluie este oferit de criptarea datelor prin intermediul
unei suite de tehnici, implementate de biblioteci specializate i/sau oferite de
mediile de dezvoltare existente.
n unele situaii, precum cele din domeniul e-business, accesul la serviciul Web
nu trebuie s fie public, acordat oricui. Autentificarea presupune un mecanism
care permite utilizatorilor s acceseze un serviciu dup verificarea identitii
utilizatorului (n general, pe baza unui nume de cont i a unei parole furnizate
de acel utilizator). De cele mai multe ori, serverul Web ofer suport pentru
autentificri de baz sau bazate pe algoritmi de tip digest, precum MD5. n cazul
serviciilor Web, exist ns iniiative speciale, precum SAML (Security Assertion
Markup Language) vezi infra.
Autorizarea este asociat autentificrii i specific aciunile (rolurile) pe care un
utilizator poate s le realizeze. Un utilizator autentificat poate s nu fie n mod
implicit i autorizat s aib acces la o anumit resurs a sistemului. Sistemele de
autorizare permit administratorului s defineasc politici pentru controlul accesului la servicii. n mod tradiional, se folosesc drepturi de acces (permisiuni) i
liste de control al accesului (ACL Access Control List), utilizatorii fiind clasificai
pe grupuri sau roluri. Prin intermediul controlului accesului bazat pe roluri
(RBAC Role-Based Access Control), sistemul de management al securitii poate
fi mai uor mulat pe structura organizaiei. n ceea ce privete utilizatorul, n
mod uzual se folosete o tehnic de tip SSO (Single Sign-On), bazat pe existena
unui singur procedeu de autentificare comun pentru accesul la mai multe
resurse (situri, servicii etc.).
Tehnicile de tip digest pot asigura i integritatea informaiilor, fiind posibil
detectarea oricrei ncercri maliioase de modificare a datelor transmise. De
asemenea, tot pentru realizarea integritii, pot fi folosite semnturi digitale (a nu
se confunda ns cu semnturile electronice care se refer la totalitatea mijloacelor
prin care o informaie poate purta semntura proprietarului ei). Semnturile
digitale pot fi stocate n format XML i vehiculate, desigur, via mesaje SOAP
prin intermediul specificaiei XML Signature.
Nerepudierea asigur faptul c expeditorul mesajului nu poate afirma c nu l-a
trimis. Pentru aceasta se folosesc certificate digitale, care stocheaz datele privind
identitatea unei entiti deintoare a unui secret (o parol, o serie a unei cri de
credit, a certificatului digital n sine etc.). Certificate digitale sunt disponibile
ntr-un format precum X.500. Un certificat digital este emis de o autoritate de
certificare (CA Certification Authority), iar verificarea certificatelor se realizeaz
de ctre o autoritate de nregistrare a acestora (RA Registration Authority). Cataloagele de certificate, mpreun cu autoritile de certificare (CA) i nregistrare
288
SERVICII WEB
(RA) formeaz aa-numita infrastructur cu chei publice (PKI Public Key Infrastructure).
Oferirea de servicii PKI n contextul spaiului Web se poate realiza via XKMS
(XML Key Management Specification).
Disponibilitatea impune ca o anumit resurs s poat fi accesat la momentul
oportun. Un serviciu Web indisponibil clienilor si pur i simplu nu exist, ceea
ce are repercusiuni negative mai ales n contextul afacerilor electronice. Printre
cauzele care pot eroda disponibilitatea se enumer atacurile de refuz al serviciilor
DoS (Denial Of Service) sau DDoS (Distributed DoS). Atacurile distribuite sunt
deosebit de periculoase pentru asigurarea disponibilitii serviciilor Web publice.
Intimitatea este deseori confundat cu confidenialitatea. Confidenialitatea
presupune imposibilitatea ca datele aflate n tranzit s fie accesate de persoane
ru-voitoare, pe cnd intimitatea vizeaz drepturile ce trebuie respectate privind
caracterul (subiectul) datelor vehiculate. Multe dintre vulnerabilitile raportate
n domeniul comerului electronic sunt de fapt bree n sistemul de asigurare a
intimitii utilizatorilor. Pentru datele transportate pe Internet sunt adoptate n
mod unanim diverse tehnici de criptare, dar la nivel de server ar putea s fie
stocate necorespunztor (de exemplu, n clar) n cadrul unui sistem de stocare
vulnerabil. Un atacator va avea astfel acces la seria crii de credit a unui client,
pe baza unei conexiuni directe cu serverul de baze de date sau a unui tehnici de
tip XSS (Cross-Site Scripting). Alte probleme viznd pierderea intimitii sunt
cauzate de configurarea necorespunztoare a sistemelor detalii i n cartea lui
Sabin Buraga, Proiectarea siturilor Web (ediia a doua), Polirom, Iai, 2005.
Niveluri de securitate
Vom face mai jos o scurt trecere n revist a cerinelor de securitate pe care
trebuie s le ndeplineasc serviciile Web.
Construirea unor servicii Web sigure (din punctul de vedere al securitii)
trebuie s ia n considerare aspecte ca:
realizarea unui model (Web Services model) care are la baz o analiz detaliat a
factorilor care amenin comunicarea i punctele terminale (endpoints) ale
serviciilor Web;
existena unui cadru de lucru (framework) facilitnd securizarea resurselor, uor
integrabil ntr-o arhitectur orientat spre servicii;
asigurarea unui mecanism de autentificare i autorizare a prilor care comunic n cadrul sistemului constituit.
Majoritatea scenariilor de securitate sunt legate de securitate la nivel de reea/
transport, securitate la nivel de date i integritate la nivel de mesaj.
289
La nivel de reea, mijlocul de protecie general mpotriva incidentelor de

securitate se concretizeaz n aa-numitul zid de protecie (firewall). Deoarece
serviciile Web folosesc n mod nativ protocolul HTTP, mesajele vehiculate vor
putea traversa Internetul fr aportul filtrelor impuse de firewall-uri (acesta este,
de fapt, i unul dintre avantajele serviciilor Web fa de tehnologiile CORBA sau
DCOM). Totui, firewall-urile vor fi de folos pentru stvilirea altor tipuri de
atacuri, de nivel inferior (e.g., inundri cu pachete). De asemenea, la nivel de
reea poate fi folosit protocolul IPSec (IP Secure).
n ceea ce privete nivelul de transport, se recurge la SSL (Secure Sockets Layer)
i la versiunea mai recent, standardizat, TLS (Transport Layer Security). Aceste
protocoale sunt folosite pentru autentificarea i confidenialitatea mesajelor
HTTP. Autentificarea se realizeaz via certificate digitale, iar confidenialitatea
prin criptare. Datele HTTP securizate via SSL/TLS fac obiectul specificaiei
HTTPS, portul folosit fiind 443, n loc de cel implicit 80.
La nivel de aplicaie, n primul rnd se poate utiliza S/MIME (Secure
MIME), soluie pentru asigurarea confidenialitii, integritii i nerepudierii
n cazul mesajelor de pot electronic. Dac se adopt o metod de transfer
SOAP peste SMTP, atunci S/MIME poate fi atractiv i n cazul serviciilor
Web.
Pentru HTTP sau alte protocoale (e.g., Jabber), un prim deziderat este s se
ofere o securitate persistent a mesajelor SOAP transportate. Tehnologiile
amintite mai sus vizeaz o securitate exterioar. Includerea de informaii privind
securitatea n cadrul unui mesaj SOAP este subiectul specificaiei WS-Security,
actualmente standard OASIS. WS-Security definete metode speciale de inserare
a datelor criptate sau a semnturilor digitale n anteturile SOAP. n plus, se ofer
suport pentru includerea de jetoane (tokens) de securitate arbitrare. Alte detalii
vor fi furnizate mai trziu n cadrul acestui capitol.
Securitatea n contextul XML

Confidenialitatea este asigurat via XML Encryption, specificaie a Consoriului
Web, care ofer mijloacele pentru criptarea unor poriuni din documentele XML
i stocarea datelor criptate n format XML. XML Encryption poate fi benefic n
contextul serviciilor Web, datorit abilitii criptrii doar a unor fragmente XML.
Mesajele SOAP pot include informaii care trebuie s rmn publice (privitoare
la dirijare, de exemplu), dar pot conine i pri criptate. Standardul XML
Encryption nu introduce noi algoritmi de criptare, putnd fi folosii cei deja
consacrai, ci doar specific anumite meta-date referitoare la acetia i la modul
de utilizare ntr-un context dat.
290
SERVICII WEB
Un exemplu de criptare a informaiilor privitoare la cartea de credit a unui

utilizator este urmtorul (numele clientului e public, dar celelalte informaii
private sunt criptate n acest caz, se folosesc i semnturi digitale):
<?xml version='1.0'?>
<plata xmlns='http://portocale.info/Plati'>
<nume>Portocal Escu</nume>
<EncryptedData Id='EData'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<EncryptionMethod Algorithm=
'http://www.w3.org/2001/04/xmlenc#aes128-cbc'/>
<ds:KeyInfo xmlns:ds=
'http://www.w3.org/2000/09/xmldsig#'>
<ds:RetrievalMethod URI='#EKey' Type=
"http://www.w3.org/2001/04/xmlenc#EncryptedKey">
<ds:KeyName>SymmetricKey</ds:KeyName>
</ds:RetrivalMethod>
</ds:KeyInfo>
<CipherData>
<CipherValue>pj3io2sa25fF</CipherValue>
</CipherData>
</EncryptedData>
</plata>
Pentru rezolvarea integritii, avem la dispoziie XML Signature, specificaie

comun a Consoriului Web i a IETF (Internet Engineering Task Force). Ca mai sus,
se ofer att posibilitatea semnrii digitale a unor poriuni dintr-un document
XML, ct i exprimarea n XML a informaiilor referitoare la semnturile
digitale. Modul de integrare a elementelor XML Signature n cadrul mesajelor
SOAP este detaliat de specificaia WS-Security.
Problemele de autentificare i autorizare n contextul serviciilor Web se
ncearc a fi rezolvate de o suit de tehnologii. Diverse declaraii privitoare la
anumite aspecte legate de securitate pot fi exprimate cu ajutorul SAML (Security
Assertions Markup Language), standardizat de OASIS. Limbajul SAML poate fi de
folos i pentru stocarea unor informaii privitoare la utilizatorul final (e.g.,
precizarea unei limite inferioare a unui depozit bancar n cazul unui serviciu de
creditare). SAML este utilizat mai ales pentru a specifica informaii referitoare la
autentificare sau autorizare care s-au ntmplat n trecut, permind ca aceste
informaii s fie plasate ntr-un mesaj SOAP (de exemplu, persoana P a fost
autorizat conform unor politici de acces A la momentul M). Dac destinatarul
acelui mesaj are ncredere n aseriunea (assertion) semnalat prin SAML, poate
permite utilizatorului s aib acces la serviciul Web dorit.
291
Figura 5. Procesul de criptare/descriptare a mesajelor SOAP
Drept exemplificare, furnizm urmtorul fragment de document, care precizeaz c autentificarea utilizatorului blue.ory s-a realizat cu succes, pe baza
metodei de autentificare oferit de sistemul Kerberos:
<saml:AuthenticationStatement
AuthenticationInstant="2006-09-01T10:33:33Z"
AuthenticationMethod="Kerberos">
<saml:Subject>
<saml:NameIdentifier
NameQualifier="verisign.com/ams">
blue.ory
</saml:NameIdentifier>
</saml:Subject>
</saml:AuthenticationStatement>
292
SERVICII WEB
Suplimentar, pentru a exprima regulile de control al accesului n termenii

XML, putem recurge la XACML (Extensible Access Control Markup Language).
Decizia de autorizare modelat printr-o aseriune SAML poate fi bazat pe
regulile stipulate via XACML. Regulile pot desemna politici de acces la resurse
(citire, scriere, execuie etc.) bazate pe diverse caracteristici ale entitii n cauz
(e.g., lista clienilor poate fi parcurs doar de membrii departamentului de
vnzri) sau ale protocolului (invocarea serviciului Web se poate realiza numai
via HTTPS). De asemenea, XACML poate fi folosit i la managementul
drepturilor digitale DRM (Digital Rights Management).
Specificaia XKMS (XML Key Management Specification) ofer suportul pentru
gestiunea cheilor publice via XML. Astfel, n mod natural, serviciile PKI
recunoscute a fi dificil de implementat pot fi puse la dispoziie mai facil, graie
serviciilor Web. Recomandarea XKMS presupune existena a dou servicii Web:
X-KRSS (XML Key Registration Service Specification) trebuie s ofere suport
pentru managementul ciclului de via al acreditrilor (credentials) asociate
cheilor publice;
X-KISS (XML Key Information Service Specification) expune metode de interogare
pentru obinerea i validarea cheilor publice.
Protocolul XKMS este n strns legtur cu SOAP, fiind de tip cerere-rspuns. De asemenea, se ofer faciliti pentru procesri asincrone i formularea
de cereri compuse. Via XKMS, complexitatea vireaz de la client la intrastructur,
codul de implementat fiind mult mai simplu.
Securizarea serviciilor Web. Tehnologii i standarde

Tehnologiile prezentate mai sus nu se focalizeaz n principal asupra securitii
serviciilor Web, ci iau n consideraie i securitatea datelor XML.
Pentru securizarea mesajelor SOAP a fost redactat un set de specificaii
purtnd numele WS-Security, efort comun al corporaiilor IBM i Microsoft,
actualmente standardizat de OASIS. Aspectele de securitate nu mai vizeaz n
mod obligatoriu protocolul folosit (e.g., HTTP cu TLS), ci se situeaz la nivelul
mesajelor, n termeni de asigurare a integritii, confidenialitii i autentificrii.
WS-Security include i alte specificaii, precum WS-Trust (pentru asigurarea
ncrederii), WS-SecurityPolicy (privitoare la politici de acces sigur) i WS-Privacy
(pentru asigurarea intimitii). La un nivel superior, se afl WS-SecureConversation
(avnd n vedere sigurana conversaiilor ntre serviciile Web), WS-Federation
(viznd gruparea serviciilor ntr-o federaie partajnd aceleai politici de securitate) i WS-Authorization (oferind suport pentru metode de autorizare sofisticate).
293
Figura 6. Diversele aspecte privind securitatea serviciilor Web sunt specificate pe niveluri
WS-Trust definete modul de stabilire a relaiilor de ncredere ntr-un sistem.

Aceste relaii pot avea loc direct sau prin intermediari (brokeri). Intermedierea
relaiilor de ncredere se realizeaz printr-un proxy de ncredere (trust proxy). De
asemenea, se permit mecanisme pentru delegare (delegation) i impersonalizare
(impersonation).
Prevederile WS-SecurityPolicy pot fi utilizate pentru formularea unor politici de
securitate pe baza limbajului WS-Policy.
WS-Privacy folosete WS-SecurityPolicy, WS-Security i WS-Trust pentru a realiza
schimburi de mesaje conform unor reguli de asigurare a intimitii.
Specificaia WS-SecureConversation permite ca un solicitant i un ofertant de
servicii Web s stabileasc un context de autentificare mutual prin mesaje
SOAP.
WS-Federation duce securitatea la nivel de federaie de servicii Web, unde
federaie presupune inter-operabilitatea diverselor strategii i specificaii de
securitate folosite de o suit de servicii Web, care formeaz un domeniu de
ncredere. WS-Federation poate fi folosit i n contextul EASI (Enterprise Application
Security Integration).
WS-Authorization poate fi considerat complementar XACML, descriind maniera
de specificare i de management al politicilor de acces la serviciile Web.
Din punct de vedere tehnic, WS-Security presupune existena ntr-un mesaj
SOAP a unui bloc antet Security care trebuie s aib prevzut atributul mustUnderstand
cu valoarea true:
<Envelope>
<Header>
...
<Security role="http://www.portocale.info/Plati"
mustUnderstand="true">
294
SERVICII WEB
...
</Security>
...
</Header>
...
</Envelope>
Dac un nod SOAP este incapabil s proceseze blocul privitor la securitatea

mesajului, atunci mesajul va fi distrus. Deoarece un mesaj poate include mai
multe blocuri Security, vom indica prin atributul role crui serviciu Web i sunt
adresate informaiile de securitate din fiecare bloc n parte. Coninutul propriu-zis
al elementului Security va consta din jetoane (tokens) de securitate, precum
UsernameToken (referitor la autentificare prin SAML ori alte tehnici) i
BinarySecurityToken (privitor la diverse date criptate, exprimate cu XML Signature,
XML Encryption sau altfel).
De asemenea, se precizeaz i diverse scenarii de manipulare a erorilor
survenite via elementul Fault oferit de SOAP.
Actualmente, unul dintre cele mai versatile instrumente care suport WS-Security
este extensia WSE (Web Services Enhancements) versiunea 3.0 pentru .NET Framework.
De exemplu, criptarea unui mesaj SOAP prin folosirea unui certificat digital n
format X.509 (care trebuie s se gseasc pe fiecare calculator al clientului ce
solicit o informaie confidenial de la serviciul Web) poate fi realizat astfel:
X509SecurityToken certificat = FurnizeazaCertificat();
// adugm jetonul privitor la certificat
serviciu.RequestSoapContext.Security.Tokens.Add
(certificat);
// inserm un element EncryptedData
serviciu.RequestSoapContext.Security.Elements.Add(
new EncryptedData(certificat));
Menionm c WSE nu ofer doar faciliti n ceea ce privete securitatea

serviciilor Web, ci i pentru adresare (WS-Addressing) i ataare de alte informaii
la mesajele SOAP (WS-Attachments). Sunt puse la dispoziie i diverse instrumente
utile ce pot fi integrate fr probleme n Visual Studio .NET. De asemenea, WSE
faciliteaz exploatarea serviciilor Web create n .NET i prin intermediul unor
protocoale diferite de HTTP.
295
2.8. Asigurarea inter-operabilitii

Inter-operabilitatea vizeaz existena unei suite de tehnici i instrumente care
permit aplicaiilor software (n cazul nostru, serviciile Web i clienii afereni) s
comunice indiferent de tehnologiile i platformele folosite. Mai mult dect att,
aplicaiile pot partaja datele indiferent de manierele de reprezentare, de acces i
de tehnologia folosit la momentul rulrii pentru managementul acestor date. De
asemenea, inter-operabilitatea presupune posibilitatea formrii unei platforme
virtuale de calcul, pe baza sistemelor de operare, mediilor de rulare (runtime) i
componentelor software trecute, prezente i viitoare.
Tehnologiile actuale menite a oferi sprijin pentru realizarea inter-operabilitii
sunt WSIT (Web Services Interoperability Technology), JWSDP (Java Web Services
Developer Pack), WSE (Web Services Enhancements) i WCF (Windows Communication
Foundation). La momentul scrierii acestui material, JWSDP se afl la versiunea 2.
Dup cum am menionat n seciunea anterioar, WSE reprezint o extensie
oferit de Microsoft pentru dezvoltarea de servicii Web securizate i interoperabile pe platforma .NET, actualmente fiind disponibil versiunea 3.0. WSE
are la baz specificaii standardizate, precum WS-Security, WS-Addressing, WS-Policy
i WS-I. WCF cunoscut anterior i sub numele Indigo desemneaz una dintre
componentele fundamentale ale noului sistem Windows Vista, menit a oferi o
infrastructur pentru comunicarea prin mesaje ntre diverse componente.
O iniiativ important de standardizare referitoare la inter-operabilitatea
serviciilor Web este WS-I (Web Service Interoperability), detalii fiind disponibile la
http://www.ws-i.org.
Principalele avantaje ale inter-operabilitii sunt cele privind asigurarea independenei de platform, evoluia bazat pe standarde deschise i utilizarea
familiei XML. Printre slbiciuni se numr problemele de performan, dificultatea gestionrii per ansamblu a strii sistemului, problemele cauzate de
incompatibilitatea datelor (data mismatch) din cauza interpretrilor diferite ale
standardelor implementate de diveri ofertani. De asemenea, nu ntotdeauna
poate fi folosit modelul cerere/rspuns, mai ales n cazul unor aplicaii care
trebuie s fie executate n timp-real sau care necesit transferuri de fluxuri de
informaii (streaming).
Aspectele importante pe care trebuie s le avem n vedere cnd concepem
servicii Web care s asigure o inter-operabilitate solid se refer la:
tipurile de date i schemele XML proiectate i folosite n cadrul documentelor
WSDL (se recomand ca, nainte de implementarea propriu-zis a serviciului,
s se realizeze o analiz i proiectare corespunztoare a schemelor XML
296
SERVICII WEB
privitoare la mesajele vehiculate ntre serviciile Web i posibilii lor clieni; de

asemenea, o atenie deosebit trebuie acordat documentului WSDL de
descriere a serviciului, deoarece este unicul mijloc prin care un dezvoltator
extern are acces la funcionalitile serviciului n cauz);
alinierea la standardele n vigoare (mai ales la WS-I, prezentat mai jos);
controlul versiunilor (versioning);
compatibilitatea cu variantele anterioare ale instrumentelor folosite (de exemplu,
JWSDP 1.x/2.x versus WSE 2.0/3.0 sau WCF).
Etapa de proiectare vizeaz alegerea tipurilor de date, scrierea schemelor
XML i stabilirea modului de tratare a erorilor. Primul pas este cel de definire a
schemei XML, construciile folosite fiind ct mai simple posibil (a se evita
aspectele avansate privitoare la reprezentarea datelor via XML Schema). Tot aici,
trebuie s avem n vedere profilele de inter-operabilitate WS-I. Nu trebuie s
presupunem c tipurile de date vor fi verificate de clieni, c versiunea SOAP
folosit de diversele implementri este i va rmne aceeai, c transferurile de
date vor fi realizate doar n manier sincron. De asemenea, este posibil ca
instrumentele utilizate s nu fie compatibile ntre ele.
n faza de dezvoltare trebuie avute n vedere aspecte privind comunicaiile
asincrone, partajarea datelor/sesiunilor, mecanismul de mesagerie folosit i
securitatea.
La momentul exploatrii n practic, principalele probleme sunt cele legate de
performan i scalabilitate.
Inter-operabilitatea poate fi asigurat i prin interpunerea unei componente
de tip wrapper, care transform mesajele clientului n formatul neles de ctre
serviciu i invers. Acest wrapper poate fi situat la nivel de server, la nivel de client
sau ntr-un strat intermediar. Exist situaii n care se folosesc dou componente
wrapper, una pe maina clientului, cealalt pe server. Soluiile care permit realizarea
acestui pod (bridging) de conectare a dou aplicaii incompatibile folosesc fie
tehnologiile Java, fie .NET (via .NET Remoting).
Alternativ, inter-operabilitatea poate fi obinut graie sistemelor messaging,
folosind puni de interconectare, adaptori, mesaje SOAP ori sisteme de mesagerie
clasic SMTP/POP/IMAP. n acest caz, comunicaiile pot fi i asincrone.
Pentru aplicaii compuse (composite applications), Sun propune o arhitectur
denumit magistrala de servicii enterprise ESB (Enterprise Service Bus), constituit
din componente pentru managementul i orchestrarea sofisticat a tuturor
activitilor din cadrul unei organizaii, asigurndu-se inclusiv inter-operabilitatea.
n viziunea Sun, ESB reprezint o etap evolutiv superioar SOA, oferindu-se
suport pentru existena componentelor hibride, a unui management centralizat
297
i a unor entiti middleware orientate spre mesaje. De asemenea, prin ESB se

nlesnete asigurarea scalabilitii.
Figura 7. Componentele ESB
n ce privete aplicaiile compozite, ele sunt constituite din servicii reutilizabile,

putnd fi create uor, frecvent i la cerere, conform cerinelor afacerilor ntreprinse. Aspectele statice, mai riguroase, ale aplicaiei sunt separate de cele
dinamice, n evoluie, conforme cu preferinele utilizatorilor. Dac Java poate fi
limbajul folosit la implementarea aplicaiilor, compunerea serviciilor poate fi
realizat prin BPEL4WS; a se urmri cele discutate n seciunea de mai jos.
Aliniate arhitecturii ESB, sunt disponibile att produse comerciale oferite
de BEA, Cape Clear, IBM, Oracle ori Sun , ct i aplicaii open source de
exemplu, Celtix (IONA), FUSE (LogicBlase), Open ESB (Sun), Synapse (Apache)
i ServiceMix (Apache).
Direciile de viitor vizeaz ori, de fapt, viseaz? unificarea platformelor
J2EE (Java 2 Enterprise Edition) i .NET. Astfel, pot fi adoptate extensii J2EE care
s permit aplicaiilor .NET s ruleze pe un anumit server de aplicaii Java. De
asemenea, poate fi constituit un strat de translatare la momentul compilrii a
codului din limbajul intermediar MSIL n secvene de bytecode Java i vice-versa.
n acest mod, sistemul de operare poate gzdui o unic main virtual capabil
s neleag ambele tehnologii (instruciuni de nivel sczut, sistem de tipuri de
date, componente etc.). Aplicaiile .NET pot consuma resurse Java, n mod
298
SERVICII WEB
direct, i invers. Aceste maniere de inter-operabilitate sunt deja suportate de

aplicaii precum JBoss, Tomcat, WebLogic i WebSphere. De asemenea, Visual
MainWin pentru J2EE reprezint un plug-in Visual Studio care permite dezvoltatorilor s scrie programe C# sau VB.NET (inclusiv servicii Web) care sunt
convertite automat dup compilare n bytecode Java.
Pe o idee oarecum similar se bazeaz i noua versiune Perl 6, via maina
virtual Parrot, aflat n plin dezvoltare.
n ceea ce privete Java, noile versiuni J2SE 1.6 i J2EE 1.5 pun un accent
pronunat asupra asigurrii inter-operabilitii. Un exemplu este i GlassFish,
disponibil gratuit pentru utilizare, parte a proiectului Tango, al crui scop este
oferirea unei suite de tehnologii Web viitoare care s permit inter-operabilitatea
dintre aplicaiile Java i cele WCF, pe baza strategiilor WSIT (Web Services
Interoperability Technology) stipulate de corporaia Sun.
Profilul WS-I de baz

Pentru a nivela posibilele diferene ntre implementrile oferite de diversele
medii de dezvoltare a serviciilor Web, organizaia WS-I a redactat un prim profil
denumit profilul de baz (WS-I Basic Profile) la care trebuie s se alinieze toate
implementrile actuale. n prezent este n vigoare versiunea 1.1 a acestui profil.
Una dintre prevederile majore ale profilului este aceea a interzicerii codificrii n
stilul RPC a mesajelor SOAP.
Pentru a indica faptul c o implementare este conform cu profilul de baz,
de cele mai multe ori se recurge la specificatori (meta-date) precum cei dai mai
jos (aici, pentru .NET):
[WebService]
[WebServiceBinding(
ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Serviciu : System.Web.Services.WebService
{
// implementare
}
n viitor, WS-I ar putea standardiza i alte profile privitoare la diversele

aspecte ale inter-operabilitii serviciilor Web.
2.9. Serviciile Web n contextul proceselor de afaceri

Este de necontestat faptul c serviciile Web i arhitectura orientat spre servicii au
devenit paradigma obinuit pentru proiectarea i implementarea colaborrilor la
nivel de afaceri n cadrul i dincolo de graniele unei organizaii. Funcionalitile
299
sunt oferite prin intermediul interfeelor standardizate ale serviciilor Web.

Serviciile puse la dispoziie de diferite organizaii, eventual regsite graie UDDI,
pot fi interconectate n vederea realizrii de operaii (relativ mai) complexe.
Astfel, grupuri de servicii considerate atomice constituie aa-numitele servicii
compozite (composite Web services).
Colaborrile inter- sau intra-organizaionale necesit n multe cazuri interaciuni de durat, conduse de modele explicite de procese de afaceri. Modelarea
proceselor de afaceri se regsete i sub termenii de model al fluxului de
activiti (workflow), orchestrare sau coregrafie.
Exist deja o suit de limbaje XML de modelare a proceselor de afaceri,
distingndu-se WSCI (Web Service Choreography Interface), BPML (Business Process
Modeling Language) i BPEL4WS (Business Process Execution Language for Web Services).
Aceste abordri iau n consideraie att manierele de comunicare ntre diversele
entiti software implicate, ct i workflow-urile desfurate ntr-un sistem.
Vom discuta n continuare cteva dintre aspectele definitorii ale BPEL4WS.
Acest limbaj are ca strmoi WSFL (Web Services Flow Language) oferit de IBM i
propunerea XLANG iniiat de Microsoft. Dac primul modela un flux de
activiti ca un graf orientat specificat de construcii XML, al doilea avea un
punct de vedere apropiat de scrierea n pseudo-cod a algoritmilor.
Un proces reprezint orice colecie de activiti care conduc la realizarea unui
anumit obiectiv (de exemplu, procesarea unei comenzi ori cereri de plat,
angajarea unui nou programator ntr-o companie sau trimiterea unei propuneri
de invenie spre aprobare).
n viziunea BPEL4WS, procesele pot fi abstracte sau executabile. Cele
abstracte desemneaz un protocol specificnd tipul mesajelor interschimbate de
diverse entiti, fr a se oferi detalii privitoare la comportamentul acestora.
Procesele executabile definesc:
o ordine de execuie a activitilor constituiente;

partenerii implicai;
mesajele vehiculate ntre parteneri;
mecanismele de rezolvare a excepiilor/erorilor.
La rndul ei, o activitate parte component a unui proces poate fi simpl

(primitive) sau structurat (structured). Tipurile de activiti simple sunt urmtoarele:
invoke invocarea unei operaii oferite de un serviciu Web i descrise de un
document WSDL;
receive ateptarea unui mesaj provenind de la o surs extern;
reply trimiterea unui mesaj-replic unei surse externe;
300
SERVICII WEB
wait oprirea activitii un anumit timp;

assign copierea datelor dintr-o variabil n alta;
throw indicarea erorilor survenite ntr-o execuie;
terminate terminarea unei instane de serviciu;
empty desemneaz activitatea vid.
Figura 8. Reprezentarea grafic a unui workflow desfurat n cazul iniierii unei comenzi din
partea unui cumprtor online ce dorete s achiziioneze un sortiment de portocale
Operaiile complexe pot fi modelate prin activiti structurate. Astfel, pot fi

specificate structuri foarte similare celor puse la dispoziie de limbajele de
programare:
301
sequence definete o ordine de execuie, secvenial;

switch desemneaz o alternativ (conditional routing);
while permite bucle de execuii;
pick stabilete condiii de alegere bazate pe evenimente (e.g., onAlarm,
onMessage etc.);
flow permite execuia n paralel (parallel routing);
scope grupeaz activiti ce vor fi tratate de acelai handler de excepii.
Varianta 2.0, mai recent, a limbajului introduce noi tipuri de activiti

(if-then-else, forEach, repeatUntil, validate etc.) i transformri ale valorilor variabilelor
prin XSLT. De asemenea, este aliniat la prevederile n vigoare privind inter-operabilitatea.
Procesul de verificare a stocului de portocale poate fi modelat astfel (este
vorba de o comunicare sincronizat):
<process name="verifStocPorto">
<sequence>

<invoke partner="stocuri"
inputVariable="portocale"
outPutVariable="cantit">
</invoke>
<flow>

<sequence>...</sequence>

<receive partner="stocuri"
variable="cantit"></receive>
</flow>
</sequence>
</process>
Desigur, activitile structurate pot fi imbricate. n cazul activitilor care fac

parte din aceeai activitate de tip flow, ordinea de execuie poate fi controlat via
links legturi ce permit definirea dependenelor ntre dou activiti (activitatea
destinaie poate ncepe doar atunci cnd activitatea surs s-a ncheiat). Astfel se
formeaz un digraf aciclic de activiti, cu condiii de tranziie de la o activitate
la alta (transition conditions) i condiii de unificare (join conditions).
Vom exemplifica dou dintre abloanele de realizare a workflow-urilor: alegerea
exclusiv (exclusive choice) i confluena simpl (simple merge).
302
SERVICII WEB
Alegerea exclusiv presupune, pe baza lurii unei decizii, alegerea unei singure
soluii dintr-o alternativ. De exemplu, managerul unui magazin virtual va fi
notificat dac stocul de portocale este pe sfrite (cantitatea disponibil este mai
mic de 33 de kilograme), altfel nu. Schematic, aceasta poate fi exprimat prin
liniile:
<switch>
<case condition="#cantitMinima">

</case>
<case condition="...">
...
</case>
</switch>
Confluena simpl precizeaz un punct din procesul workflow n care se

reunesc dou sau mai multe ramuri de activiti alternative, fr a necesita
sincronizare (se presupune ns c ramurile alternative nu se execut niciodat n
paralel). De exemplu, dup ce plata a fost efectuat sau creditul a fost aprobat,
produsul comandat poate fi expediat clientului.
Actualmente sunt disponibile diverse sisteme de management al fluxurilor de
activiti WFMS (WorkFlow Management System) , majoritatea oferind suport
pentru BPEL4WS ori alte propuneri complementare. Ca exemple notabile
menionm instrumentele oferite de BEA, Microsoft, Oracle i Sun, care funcioneaz pe platforme precum .NET, J2EE sau JBI (Java Business Integration).
Ca alternativ la ESB (care ofer suport i pentru workflow-uri), corporaia
Microsoft are n vedere constituirea a ceea ce numete Windows Workflow
Foundation, integrat cu tehnologiile Microsoft, dar a crei arhitectur se bazeaz
pe modelul unui procesor (engine) BPEL. La nivel de utilizator final, workflow-urile
pot fi definite grafic direct n Office, iar dezvoltatorii vor avea la dispoziie
diverse aplicaii precum Visual Studio Team System. Actualmente, fluxurile de
activiti sunt folosite n cadrul serverului BizTalk i a noii fundaii de servicii de
comunicare WCF (Windows Communication Foundation).
2.10. Servicii Web pentru grid

Orchestrarea i coordonarea sunt eseniale i n cadrul sistemelor de tip grid, n
care serviciile Web joac un rol important. Conceptul de grid desemneaz o
entitate oferind servicii de calcul sau acces la date i fiind compus dintr-o serie
de computere privite ca o gazd Internet unic. Dac iniial au reprezentat o
propunere de infrastructur de calcul distribuit pe scar larg destinat proiectelor
tiinifice i industriale, tehnologiile grid au oferit ulterior suport pentru cutarea
303
i regsirea informaiilor, indiferent de localizarea lor fizic. ntr-un sistem grid,

serviciile pot fi dinamice i volatile, constituite ad-hoc, disponibile pe scar larg
i pe termen ndelungat.
O implementare de referin a arhitecturii i protocoalelor grid este Globus,
actualmente ajuns la versiunea 4. Instrumentele de dezvoltare formeaz Globus
Toolkit, disponibile n general pentru sistemele UNIX/Linux. Interfeele de
programare formeaz aa-numitul CoG (Commodity Grid) toolkit, fiind disponibile
pentru limbaje precum Java, Perl ori Python, cu suport i pentru CORBA, .NET i
servicii Web. Standardizarea tehnologiilor grid este supervizat de Global Grid Forum.
n prezent, atenia este focalizat asupra constituirii unei arhitecturi orientate
spre servicii grid, recurgndu-se la tehnologiile Web actuale. Astfel, n cadrul
modelul arhitectural OGSA (Open Grid Service Architecture) serviciile Web sunt
extinse pentru a putea specifica funcionaliti de baz i specializate pentru
sisteme de tip grid. Arhitectura OGSA este compus din infrastructura OGSI, o
suit de interfee i de modele.
OGSI (Open Grid Services Infrastructure) se afl la convergena dintre grid i
serviciile Web, definind mecanismele de baz pentru managementul instanelor
de servicii grid (transferul de mesaje, meninerea ciclului de via etc.). OGSI
extinde WSDL pentru a oferi servicii dependente de stare (stateful) utile pentru
gestionarea strii globale a sistemului , motenirea interfeelor serviciilor,
notificarea asincron a schimbrilor de stare, specificarea referinelor la instane
de servicii i altele. De asemenea, sunt definite mecanismele prin care clienii pot
avea acces la serviciile grid-ului.
Figura 9. Meninerea strii fiecrei instane de serviciu Web existent ntr-un grid
304
SERVICII WEB
Interfeele (OGSA Platform Interfaces) reprezint diverse servicii (interfee +

comportamente asociate) care nu sunt definite n cadrul OGSI. Se vizeaz astfel
un nivel superior de servicii, precum accesul i integrarea datelor, nregistrarea i
managementul resurselor, asigurarea securitii, jurnalizarea distribuit, orchestrarea serviciilor etc.
Modelele (OGSA Platform Models) sunt o combinaie de interfee i scheme de
date utile la reprezentarea entitilor e.g., un server de stocare care sunt
incluse ntr-un sistem grid.
Maniera de ataare a serviciilor la infrastructura de transport Internet,
specificarea gazdelor, serviciile specifice unui domeniu de activitate nu fac
subiectul specificaiilor OGSA, putnd fi definite fie de anumite profile, fie de
tere organizaii.
n plus, OGSA definete WS-Agreement, prin intermediul creia se specific
modul n care serviciile grid sunt gestionate conform scopurilor unor organizaii
sau cerinelor aplicaiilor ce trebuie rulate pe grid, pe baza unor contracte
(agreements) prestabilite sau realizate dinamic.
n legtur cu OGSA, trebuie semnalat i iniiativa WSRF (Web Services
Resource Framework), o familie de specificaii viznd accesarea resurselor prin
servicii Web, n manier stateful.
O alt direcie este DAIS (Data Access and Integration Services) prin care sunt
descrise mecanismele de acces la date la nivel nalt, ascunzndu-se detaliile
privitoare la integrarea datelor stocate n surse multiple, avnd reprezentri diferite.
Implementrile OGSA se axeaz asupra tehnologiilor Java i .NET. Unul
dintre proiectele interesante de dezvoltare este WSRF.NET, bazat pe specificaiile
WSRF i implementat n C# sub .NET Framework.
Accesul la resursele unui grid poate fi facilitat de existena unui portal,
deseori oferind o interfa Web. n acest context, menionm iniiativele WSRP
(Web Services for Remote Portlets) i WSIA (Web Services for Interactive Applications).
3. SOA n contextul noului Web

Din cele prezentate mai sus, putem deduce c n cadrul SOA pot exista mai
multe roluri pe care un dezvoltator Web poate s le joace. n primul rnd, cel de
implementator de servicii, activitate care presupune crearea i publicarea implementrilor serviciilor rezultate. O a doua ipostaz o reprezint consumatorul de
servicii, a crui misiune circumscris celei a dezvoltatorului de servicii este
de a concepe aplicaii-client menite a invoca suite de servicii. Un rol nou l deine
dezvoltatorul de compuneri de servicii care proiecteaz, genereaz i public o
305
clas de servicii compuse din alte servicii. Cel de-al patrulea tip vizeaz asamblarea
serviciilor nrudite n vederea exploatrii (deployment) efective i a managementului
operaiilor.
Modelul de creare a aplicaiilor i sistemelor utiliznd SOA este descris de o
specificaie intitulat SCA (Service Component Architecture), propus la finalul anului
2005 de o serie de companii. Conform SCA, se ofer o modalitate neutr din
punctul de vedere al platformei i limbajului de programare pentru reprezentarea serviciilor care pot fi rulate pe o varietate de medii. Aceste servicii pot
fi compuse, implementate de o palet larg de framework-uri i containere (e.g.,
EJB Enterprise Java Beans). La nivel de implementare, proiectul Apache Tuscany
ofer suport pentru SCA, n limbajele C++ i Java. De asemenea, poate fi
menionat i Eclipse STP (SOA Tools Project).
Dac SOA permite adoptarea unei abordri sistematice de compunere dinamic a serviciilor conform cerinelor industriei, noua direcie de evoluie a
spaiului WWW denumit Data Web sau Web 2.0 exprim dorina de existen
a unui mecanism flexibil de integrare ad-hoc a resurselor, fr constrngeri. Modul
de utilizare a Web-ului actual se bazeaz pe modele de interaciune bogat
(aspect posibil via tehnologii ca RSS, Atom i AJAX) i pe crearea de reele
sociale slab-conectate (a se vedea fenomenul blogging, corelat cu existena taxonomiilor create de grupuri de persoane folksonomies i a aplicaiilor colaborative
de tip wiki). Web-ul este vzut ca o platform i nu numai ca depozit de date, n care
comuniti de utilizatori genereaz coninut util (pe baza inteligenei colective).
n acest context, apare tipul de aplicaie Web hibrid (aa-numitul mash-up)
care reprezint un sit Web ori o aplicaie Web ce combin n mod agil coninuturi
provenite din mai multe surse, n vederea oferirii unei interaciuni complexe.
Sursele sunt n mod uzual RSS feed-uri asociate blog-urilor sau wiki-urilor i
servicii Web exploatate prin SOAP ori prin REST. Pentru a facilita aceast
integrare, numeroi ofertani de servicii Web ncepnd cu Google i Amazon
i continund cu eBay, Yahoo! i multe alte companii au pus la dispoziie
API-uri specializate.
Mai mult dect att, exist iniiative pentru asocierea de descrieri semantice
serviciilor Web, n contextul direciei de evoluie spre Web-ul semantic detalii n
lucrrile lui Sabin Buraga, Tehnologii XML, Polirom, Iai, 2006 i Sabin Buraga,
Semantic Web, Matrix Rom, Bucureti, 2004.
Printre problemele actuale care trebuie rezolvate numr cele legate de
neconcordane semantice ntre servicii la nivel de:
coninut de exemplu, un serviciu Web care furnizeaz localizarea unei
resurse multimedia (e.g., un film) ntoarce adresa numeric (IP) a serverului de
stocare, dei solicitantul dorete URI-ul acelei resurse;
306
SERVICII WEB
atribut se solicit tipul MIME video/mpeg, dar serviciul furnizeaz tipul

generic Video;
uniti de msur serviciul solicit ca dat de intrare dimensiunea unui fiier
audio n octei, dar i se trimite un numr reprezentnd dimensiunea n MB;
mesaj clientul solicitant poate furniza rezoluia unei imagini ca pereche
lime-nlime, ns serviciul Web dorete numrul total de pixeli alocai.
Pentru descrierea semantic i invocarea corespunztoare a serviciilor Web,
eforturile sunt concentrate asupra adoptrii unor specificaii de nivel nalt,
capabile s descrie proprieti i funcionaliti ntr-o form procesabil de
calculator. Astfel, s-a propus un cadru de lucru destinat serviciilor Web descrise
semantic SWSF (Semantic Web Services Framework), care nglobeaz o suit de
propuneri precum OWL-S i SWSO (Semantic Web Services Ontology). O alt
iniiativ demn de interes este WSMO (Web Service Modeling Ontology).
Conceptual, un serviciu va fi privit ca un proces, cruia prin proprieti
i vor fi asociate datele de intrare/ieire i, eventual, diveri parametri de control.
Un alt concept important este cel de profil, incluznd meta-date necesare
descoperirii, seleciei i potrivirii semantice (matchmaking) de servicii. Modelul de
procesare vede un serviciu ca fiind atomic ori compus, aspect util n ceea ce
privete compunerea, execuia i monitorizarea serviciilor Web. Ultima component de interes privete infrastructura (grounding), desemnnd cum poate fi
executat serviciul i extinznd WSDL. Implementarea efectiv nu are importan
n acest context.
La finalul acestei seciuni, furnizm maniera de descriere semantic a unei
instane de serviciu Web de furnizare a cantitii disponibile dintr-un sortiment
de portocale (omitem declaraiile spaiilor de nume i a modului de specificare
abstract a unor resurse):

<s:Service ID="FurnizorPortocale">

<s:presents
resource="#profil_Furnizor"/>

<s:describedBy resource="#proces_Furnizor"/>

<s:supports resource="#desc_Furnizor"/>
</s:Service>

<p:Profile ID="profil_Furnizor">
<s:presentedBy resource="#FurnizorPortocale"/>

307
<p:has_process resource="#proces_Furnizor" />


<p:serviceName>FurnizeazaPortocale</p:serviceName>

<p:hasInput resource="#intrare" />

<p:hasOutput resource="#rezultat" />
</p:Profile>

<a:AtomicProcess ID="proces_Furnizor">
<s:describes resource="#FurnizorPortocale" />

<a:hasInput>
<a:Input ID="intrare">

<a:parameterType>xsd:string</a:parameterType>

<a:semanticType resource="Sortiment" />
</a:Input>
</a:hasInput>

<a:hasOutput>
<a:Output ID="rezultat">

<a:parameterType>xsd:integer</a:parameterType>

<a:semanticType resource="Cantitate" />
</a:Output>
</a:hasOutput>
</a:AtomicProcess>
Dup cum se poate remarca, principalele avantaje aduse de aceste specificaii

conceptuale sunt cele privind automatizarea descoperirii, selectrii, invocrii,
compunerii i monitorizrii execuiei serviciilor Web.
Referine
Abbas, A., Grid Computing: A Practical Guide to Technology and Applications, Charles River
Media, 2004
Acostchioaie, D., Securitatea sistemelor Linux, Polirom, Iai, 2003
Albin, S., The Art of Software Architecture: Design Methods and Techniques, Wiley & Sons,
2003
308
SERVICII WEB

books/xml/
Buraga, S., Proiectarea siturilor Web (ediia a doua), Polirom, Iai, 2005: http://www.infoiasi.ro/
~design/
Buraga, S., Semantic Web, Matrix Rom, Bucureti, 2004: http://www.infoiasi.ro/~sweb/
Cabrera, L.F., Kurt, C., Web Services Architecture and Its Specifications, Microsoft Press, 2005
Coyle, F., XML, Web Services, and the Data Revolution, Addison-Wesley, 2002
Dierks, T., Allen., C., The TLS Protocol Version 1.0, RFC 2246, Internet Engineering Task
Force (IETF), 1999: http://www.ietf.org/rfc/rfc2246.txt
Eastlake, D., Reagle, J. (eds.), XML Encryption Syntax and Processing, W3C Recommendation, Boston, 2002: http://www.w3.org/TR/xmlenc-core/
Eastlake, D., Reagle, J., Solo, D. (eds.), XML-Signature Syntax and Processing, W3C
Recommendation, Boston, 2002: http://www.w3.org/TR/xmldsig-core/
Erl, T., Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall PTR,
2005
Fisher, M. et al., Java EE and .NET Interoperability, Prentice Hall, 2006
Hallam-Baker, P., Mysore, S. (eds.), XML Key Management Specification (XKMS 2.0), W3C
Recommendation, Boston, 2005: http://www.w3.org/TR/xkms2/
Hartman, B. et al., Mastering Web Services Security, Wiley Publishing, 2003
Hundhausen, R., Working with Microsoft Visual Studio 2005 Team System, Microsoft Press,
2006
Joseph, K., Fellenstein, C., Grid Computing, Prentice Hall, 2003
Kavantzas, N. et al. (eds.), Web Services Choreography Description Language (WS-CDL)Version
1.0, W3C Candidate Recommendation, Boston, 2005: http://www.w3.org/TR/
ws-cdl-10/
Mahmoud, Q., Service-Oriented Architecture (SOA) and Web Services: The Road to Enterprise
Application Integration (EAI), Sun, 2005: http://java.sun.com/developer/technical/
WebServices/soa/
McLaren, C. (ed.), Security and Privacy Considerations for the OASIS Security Assertion Markup
Language (SAML), OASIS Standard, 2002: http://www.oasis-open.org/committees/
security/docs/
ONeill, M. et al., Web Services Security, McGraw-Hill/Osborne, 2003
Von Laszewski, G., Wagstrom, P., Gestalt of the Grid, n Hariri, S., Parashar, M.
(eds.), Tools and Environments for Parallel and Distributed Computing, Wiley Publishing,
2004
* * *, Apache Tuscany: http://incubator.apache.org/tuscany/
* * *, Business Process Execution Language for Web Services: http://www.oasis-open.org/
committees/tc-home.php/wg_abbrev=wspel
* * *, Eclipse SOA Tools Project: http://www.eclipse.org/stp/
* * *, Global Grid Forum: http://www.globalgridforum.org/
309
* * *, Globus: http://www.globus.org/
* * *, IBMs DeveloperWorks Web Services: http://www-136.ibm.com/developerworks/
webservices
* * *, Iniiativa Electronic Business XML: http://www.ebxml.org/
* * *, Iniiativa WS-I: http://www.ws-i.org/
* * *, Microsoft WSE (Web Services Enhancements): http://msdn.microsoft.com/webservices/
building/wse/
* * *, OWL-S: http://www.daml.org/services/owl-s/1.1/overview/
* * *, Proiectul GlassFish: http://java.sun.com/javaee/GlassFish
* * *, Proiectul WSRF.NET: http://www.cs.virginia.edu/~gsw2c/WSRFdotNet/
* * *, Security in a Web Services World: A Proposed Architecture and Roadmap, IBM &
Microsoft, 2002: http://www-106.ibm.com/developerworks/library/ws-secmap/
* * *, Situl dedicat serviciilor Web: http://www.webservices.org/
* * *, Soluiile de securitate XML oferite de Verisign: http://www.verisign.com/xml/
* * *, SWSF (Semantic Web Services Framework): http://www.daml.org/services/swsf/
1.0/overview/
* * *, Web Services Activity: http://www.w3.org/2002/ws/
* * *, Web Services Addressing: http://www.w3.org/Submission/ws-addressing/
* * *, Web Services AtomicTransactions: http://www.ibm.com/developerworks/webservices/
library/ws-atomtran
* * *, Web Services Business Activity: http://www.ibm.com/developerworks/webservices/
library/ws-busact
* * *, Web Services Coordination: http://www.ibm.com/developerworks/webservices/
library/ws-coor
* * *, Web Services Dynamic Discovery: http://msdn.microsoft.com/library/en-us/dnglobspec/
html/ws-discovery.pdf
* * *, Web Service Enumeration: http://msdn.microsoft.com/library/en-us/dnglobspec/
html/ws-enumeration.pdf
* * *, Web Services Eventing: http://xml.coverpages.org/WS-Eventing200408.pdf
* * *, Web Services Interoperability Technology: http://wsit.dev.java.net/
* * *, Web Services Metadata Exchange: ftp://www6.software.ibm.com/software/developer/
library/WS-MetadataExchange.pdf
* * *, Web Service Modeling Ontology: http://www.wsmo.org/
* * *, Web Services Policy Assertions Language: http://www-106.ibm.com/developerworks/
library/ws-polas
* * *, Web Services Policy Attachment: http://www-106.ibm.com/developerworks/webservices/
library/ws-polatt
* * *, Web Services Resource Framework: http://www.globus.org/wsrf/
* * *, Web Services Security: SOAP Message Security: http://www.oasis-open.org/committees/
tc_home.php?wg_abbrev=wss
* * *, Web Service Transfer: http://msdn.microsoft.com/library/en-us/dnglobspec/html/
ws-transfer.pdf
* * *, WFMC (WorkFlow Management Coalition): http://www.wfmc.org/
Acronime
A2A Application to Application
ACID Atomicity, Consistency, Isolation, Durability
ACL Access Control List
AHAH Asynchronous HTML and HTTP
AJAX Asynchronous JavaScript and XML
ALE AJAX Linking and Embedding
ANSI American National Standards Institute
AMI Application Messaging Interface
API Application Programming Interface
ASAP Asynchronous Service Access Protocol
ASCII American Standard Code for Information Interchange
ASF Apache Software Foundation
ASP Active Server Pages/Application Service Provider
AT Atomic Transaction
AWS Amazon Web Services
B2B Business to Business
B2Bi Business to Business Integration
BASH Bourne Again SHell
BSD Berkeley Software/Standard Distribution
BPEL Business Process Execution Language
BPEL4WS Business Process Execution Language for Web Services
BPM Business Process Management
BTP Business Transaction Protocol
CA Certification Authority
CC Creative Commons
CC/PP Composite Capability/Preference Profiles
CGI Common Gateway Interface
CLR Common Language Run-time
CMS Content Management System
CoG Commodity Grid
COM Common Object Model
CORBA Common Object Request Broker Architecture
312
ACRONIME
CPAN Comprehensive Perl Archive Network

CRUD Create, Retrieve, Update, Delete
C/S Client/Server
CSS Cascading Style Sheets
CVS Control Versioning System
DAIS Data Access and Integration Services
DAO Data Access Object
DBMS DataBase Management System
DCOM Distributed COM
DDoS Distributed Denial of Service
DHTML Dynamic HTML
DIME Direct Internet Message Encapsulation
DOM Document Object Model
DoS Denial of Service
DRM Distributed Resource Management, Digital Rights Management
DSML Directory Services Markup Language
DSSO Desktop Single Sign-On
DTD Document Type Definition
DWR Direct Web Remoting
E4X ECMAScript for XML
EAI Enterprise Application Integration
EASI Enterprise Application Security Integration
ebXML Electronic Business XML
ECMA European Computer Manufacturers Association
EIS Enterprise Information System
EJB Enterprise JavaBean
ESB Enterprise Service Bus
FAT File Allocation Table, Fade Anything Technique
FTP File Transfer Protocol
GCC GNU Compiler Collection
GGF Global Grid Forum
GNU Gnu is Not Unix
GPL GNU General Public License
GSH Grid Service Handler
GUID Globally Unique IDentifier
GWT Google Web Toolkit
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
i8n Internationalization
IDE Integrated Development Environment
IDL Interface Definition Language
IDN International Domain Names
IE Internet Explorer
ACRONIME
IETF Internet Engineering Task Force

IIS Internet Information Services
IL Intermediate Language
IRI Internationalized Resource Identifier
IP Internet Protocol
IPSec Internet Protocol Security
IPv6 Internet Protocol version 6
ISO International Standards Organization
J2EE Java 2 Platform, Enterprise Edition
J2SE Java 2 Platform, Micro Edition
J2SE Java 2 Platform, Standard Edition
JAAS Java Authentication and Authorization Service
JAX Java APIs for XML
JAXB Java Architecture for XML Binding
JAXP Java API for XML Processing
JAX-RPC Java API for XML-based RPC
JAX-WS Java APIs for XML Web Services
JBI Java Business Integration
JCP Java Community Process
JDBC Java DataBase Connectivity
JDK Java Development Kit
JIT Just-In-Time
JMS Java Message Service
JRE Java Run-time Environment
JS JavaScript
JSF JavaServer Faces
JSON JavaScript Object Notation
JSP JavaServer Pages
JSR Java Specification Repository/Request
JSRS JavaScript Remote Scripting
JVM Java Virtual Machine
JWSDP Web Services Developer Pack
LAMP Linux-Apache-MySQL-Perl/PHP/Python
MDI Multiple Document Interface
MEP Message Exchange Pattern
MIME Multipurpose Internet Mail Extensions
MQ Message Queue
MSDN MicroSoft Developer Network
MTOM - Message Transmission Optimization Mechanism
MVC Model-View-Controller
MXML Maximum Experience Markup Language
NAICS North American Industry Classification System
OASIS Organization of the Advancement of Structured Information Standards
313
314
ACRONIME
ODBC Open DataBase Connectivity

OMG Object Management Group
OOP Object Oriented Programming/Paradigm
ORM Object-Relational Mapping
OS Operating System
OWL Web Ontology Language
P2P Peer-to-Peer
PDF Portable Document Format
PEAR PHP Extensions and Add-ons Repository
PERL Practical Extraction and Report Language
PHP PHP: Hypertext Preprocessor
POD Process-On-Demand
POJO Plain Old Java Object
POX Plain Old XML
PSVI Post-Schema Validation Infoset
RA Registration Authority
RAI RSS Abstraction Interface
RBAC Role-Based Access Control
RDF Resource Description Format
RDFS RDF Schema
REST REpresentational State Transfer
RoR Ruby on Rails
QoS Quality of Service
RAD Rapid Application Development
RFC Request For Comments
RIA Rich Internet Application
RMI Remote Method Invocation
RPC Remote Procedure Call
RSS Rich/RDF Site Summary, Really Simple Syndication
SAAJ SOAP with Attachments API for Java
SAML Security Assertion Markup Language
SAX Simple API for XML
SCA Service Component Architecture
SDI Single Document Interface
SDK Software Development Kit
SDL Service Development Language
SDO Service Data Objects
SEI Service Endpoint Interface
SIG Special Interest Group
SLA Service Level Agreement
SMTP Simple Mail Transfer Protocol
SOA Service-Oriented Architecture
SOAD Service-Oriented Analysis and Design
ACRONIME
SOAP Simple Object Access Protocol

SOM Service-Oriented Model
SOMA Service-Oriented Modelling and Architecture
SPI Service Provider Interface
SQL Structured Query Language
SRMP SOAP Reliable Messaging Protocol
SSI Server-Side Includes
SSL Secure Sockets Layer
SSO Single Sign-On
SW Semantic Web
SwA SOAP with Attachments
SWS Semantic Web Service
SWSF Semantic Web Services Framework
TCP Transmission Control Protocol
TLS Transport Layer Security
TR Technical Report
UA User Agent (Web)
UBL Universal Business Language
UBR UDDI Business Registry
UDDI Universal Description, Discovery, and Integration
UDP User Datagram Protocol
UI User Interface
UML Unified Modeling Language
UPnP Universal Plug and Play
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Uniform Resource Name
UTF Unicode Transformation Format
UUID Universal Unique IDentifier
VB Visual Basic
VM Virtual Machine
VPN Virtual Private Network
W3C World Wide Web Consortium
WAP Wireless Application Protocol
WCF Windows Communications Foundation
WDDX Web Distributed Data Exchange
WML Wireless Markup Language
WS Web Service
WSA Web Service Architecture/Addressing
WSC Web Service Choreography
WSCI Web Service Choreography Interface
WSDL Web Services Description Language
WSDM Web Service Distributed Management
315
316
ACRONIME
WS-DP Device Profile for Web Services

WSE Web Services Enhancements
WSF Web Services Framework
WSFL Web Services Flow Language
WS-I Web Services Interoperability
WSIA Web Services for Interactive Applications
WSIL Web Service Inspection Language
WSIT Web Services Interoperability Technology
WSMO Web Service Modeling Ontology
WSO Web Services Orchestration
WS-PA WS-Policy Attachment
WSRF Web Services Resource Framework
WSRP Web Services for Remote Portals
WSS Web Service Security
WSTK Web Services Toolkit
WSXL Web Services Experience Language
WWW World Wide Web
XAML Extensible Application Markup Language
XACML Extensible Access Control Markup Language
XHTML Extensible HyperText Markup Language
X-KISS XML Key Information Service Specification
XKMS XML Key Management Specification
X-KRSS XML Key Registration Service Specification
XML Extensible Markup Language
XMLNS XML NameSpace
XMLP Extensible Markup Language Protocol
XP Extreme Programming
XSD XML Schema Definition/Datatypes
XSL Extensible Stylesheet Language
XSLT XSL Transformation
XSS Cross-Site Scripting
Bibliografie general
Abbas, A., Grid Computing: A Practical Guide to Technology and Applications, Charles River
Media, 2004
Anghel, T., Programarea n PHP. Ghid practic, Polirom, Iai, 2005
Asleson, R., Schutta, N., Foundations of AJAX, Apress, 2006
books/xml/
Buraga, S.,Proiectarea siturilor Web (ediia a doua), Polirom, Iai, 2005: http://www.infoiasi.ro/
~design/
Buraga, S., Semantic Web, Matrix Rom, Bucureti, 2004: http://www.infoiasi.ro/~sweb/
Buraga, S. (coord.), Situri Web la cheie. Soluii profesionale de implementare, Polirom, Iai,
2004: http://www.infoiasi.ro/~busaco/books/webapps/
Cabrera, L.F., Kurt, C., Web Services Architecture and Its Specifications, Microsoft Press,
2005
Daconta, M., Obrst, L., Smith, K., The Semantic Web: A Guide to the Future of XML, Web
Services, and Knowledge Management, John Wiley & Sons, 2003
Daum, B., Merten, U., System Architecture with XML, Elsevier Science, 2003
Erl, T., Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall PTR,
2005
Geroimenko, V., Dictionary of XML Technologies and the Semantic Web, Springer-Verlag,
2004
Hartman, B. et al., Mastering Web Services Security, Wiley Publishing, 2003
Harold, E., XML 1.1 Bible (3rd Edition), Wiley Publishing, 2004
Kulchenko, P., Ray, R., Programming Web Services with Perl, OReilly, 2002
Linthicum, D., Enterprise Application Integration, Addison-Wesley, 1999
Myerson, J., The Complete Book of Middleware, Auerbach Publications, 2002
Mueller, J., Mining Google Web Services: Building Applications with the Google API, Sybex, 2004
Newcomer, E., Lomow, G., Understanding SOA with Web Services, Addison-Wesley, 2004
ONeill, M. et al., Web Services Security, McGraw-Hill/Osborne, 2003
Perry, B., AJAX Hacks, OReilly, 2006
318
BIBLIOGRAFIE GENERAL
Powell, T., Schneider, F., JavaScript 2.0: The Complete Reference (Second Edition), McGraw-Hill/
Osborne, 2004
Robinson, S. et al., Professional C# (Third Edition), Wiley Publishing, 2004
Shiflett, C., HTTP Developers Handbook, Sams Press, 2003
Si Shi, N., Murthy, V.K., Architectural Issues of Web-Enabled Electronic Business, Idea Group
Publishing, 2003
Sklar, D., Trachtenberg, A., PHP Cookbook, OReilly, 2002
Tanas, ., Olaru, C., Andrei, ., Java de la 0 la expert, Polirom, Iai, 2003
Tidwell, D., Snell, J., Kulchenko, P., Programming Web Services with SOAP, OReilly, 2001
Topley, K., Java Web Services in Nutshell, OReilly, 2003
Waltz,E., Knowledge Management in the Intelligence Enterprise, Artech House, 2003
Zakas, N., McPeak, J., Fawcett, J., Professional AJAX, Wrox Press, 2006
Zeldman, J., Designing with Web Standards, New Riders Press, 2003
* * *, Apache XML: http://www.apache.com/
* * *, API-urile puse la dispoziie de Google: http://www.google.com/apis/
* * *, Apple Developer Connection: http://developer.apple.com/
* * *, ASP.NET: http://www.asp.net/
* * *, Caf con Lche: http://www.cafeconleche.org/
* * *, Code Project: http://www.codeproject.com/
* * *, Developers.net: http://www.developers.net/
* * *, Dezvoltarea de aplicaii SOAP pentru Pocket PC: http://www.pocketsoap.com/
* * *, ebXML: http://www.ebxml.org/
* * *, Fundaia Mozilla: http://www.mozilla.org/
* * *, IBM Developers Site: http://www.ibm.com/developer/
* * *, Iniiativa WS-I: http://www.ws-i.org/
* * *, Instrumente XML disponibile la Apache: http://xml.apache.org/
* * *, Interop Month: http://www.interopmonth.com/
* * *, Java Coffee-Break: http://www.javacoffeebreak.com/
* * *, Java & Web Services: http://java.sun.com/webservices/
* * *, JCP (Java Community Process): http://jcp.org/
* * *, Lista specificaiilor privitoare la limbajele bazate pe XML: http://xml.coverpages.org/
* * *, Microsoft Developers Network: http://msdn.microsoft.com/
* * *, Mozilla Developer Center: http://developer.mozilla.org/
* * *, OReilly OnLAMP: http://www.onlamp.com/
* * *, OReilly OnDotNET: http://www.ondotnet.com/
* * *, OReilly OnJava: http://www.onjava.com/
* * *, Organizaia OASIS (Organization for the Advancement of Structured Information Standards):
http://www.oasis-open.org/
* * *, OSI (Open Source Initiative): http://www.opensource.org/
* * *, Planet Source Code: http://www.planet-source-code.com/
* * *, Perfect XML: http://www.perfectxml.com/
* * *, Perl: http://www.perl.com/
BIBLIOGRAFIE GENERAL
319
* * *, Perl XML: http://www.perlxml.com/

* * *, PHP Builder: http://www.phpbuilder.com/
* * *, PHP Classes: http://www.classes.net/
* * *, PHP Developer: http://www.phpdeveloper.org/
* * *, Portal dedicat serviciilor Web: http://www.webservices.org/
* * *, Rapoartele tehnice ale Consoriului Web: http://www.w3.org/TR/
* * *, Resurse privind programare pe partea de server: http://www.devshed.com/Server_Side/
* * *, Situl .NET 247: http://www.dotnet247.com/
* * *, Situl dedicat dezvoltatorilor Java: http://developer.java.sun.com/
* * *, Situl dezvoltatorilor .NET: http://www.gotdotnet.com/
* * *, Situl lui Paul Prescod: http://www.prescod.net/
* * *, Situl privitor la abloanele de proiectare a aplicaiilor AJAX: http://www.ajaxpatterns.org/
* * *, Situl proiectului Mono: http://www.mono-project.com/
* * *, SOA Web Services Journal: http://webservices.sys-con.com/
* * *, SOAP Software: http://www.soapware.org/
* * *, Source Forge: http://www.sourceforge.net/
* * *, Sun XML Developer Connection: http://www.sun.com/software/xml/developers/
* * *, The Open Sourcery: http://theopensourcery.com/
* * *, WebReference: http://www.webreference.com/
* * *, Wikipedia: http://www.wikipedia.org/
* * *, XFront: http://www.xfront.com/
* * *, XMethods: http://www.xmethods.net/
* * *, XML 101: http://www.xml101.com/
* * *, XML.com: http://xml.com/
* * *, XML.org: http://www.xml.org/
* * *, XML Software: http://www.xmlsoftware.com/
* * *, XML Standards Library: http://xmlstds.xemantics.com/
Sabin Buraga
Proiectarea siturilor Web.

Design i funcionalitate
(cartea include CD) (ediia a II-a)
Lucrarea realizeaz mai mult dect o introducere n
domeniul Web, ilustrnd potenialul acestuia de a
dezvolta aplicaii puternice din domenii cum ar fi informarea i documentarea, realitatea virtual, e-business.
Cititorul va putea nelege i exploata posibilitile oferite
de noile tehnologii n ceea ce privete gsirea de informaii,
demararea de afaceri online i proiectarea eficient a
siturilor Web.
Principalele nouti aduse de ediia a II-a: Strategii de

optimizare a siturilor (SEO Search Engine Optimization) Utilizabilitatea, ergonomia i
accesibilitatea siturilor Web Securitatea n spaiul Web Forumuri, blog-uri, situri wiki i
portaluri E-branding, e-government, e-learning Prin XML, spre Web-ul semantic
Coninutul CD-ului: Studii de caz i exemple Documentaii (tutoriale, manuale, specificaii) n
limbile romn i englez Curs de tehnologii Web 14 prezentri i demonstraii (n limba
romn) Aplicaii open source pentru comuniti virtuale i comer electronic
www.polirom.ro
Coperta: Radu Rileanu
Tehnoredactor: Gabriela Gheu
Bun de tipar: octombrie 2006. Aprut: 2006
Editura Polirom, B-dul Carol I nr. 4 P.O. Box 266
700506, Iai, Tel. & Fax (0232) 21.41.00 ; (0232) 21.41.11;
(0232) 21.74.40 (difuzare); E-mail: office@polirom.ro
Bucureti, B-dul I.C. Brtianu nr. 6, et. 7, ap. 33,
O.P. 37 P.O. Box 1-728, 030174
Tel.: (021) 313.89.78; E-mail: office.bucuresti@polirom.ro
Tiparul executat la S.C. LUMINA TIPO s.r.l.
str. Luigi Galvani nr. 20 bis, sect. 2, Bucureti
Tel./Fax: 211.32.60, 212.29.27, E-mail: office@luminatipo.com

Serviciibunbun 140818040019 Phpapp02 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Serviciibunbun 140818040019 Phpapp02 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

LENU}A ALBOAIE, SABIN BURAGA

Seria Web este coordonat de dr. Sabin Buraga

Bruna Zani, Augusto Palmonari (a cura di), Manuale di psicologia di comunit

2006 by Editura POLIROM

Capitolul 4. Protocolul SOAP ................................................................................................ 87

La finalul acestei prefee trebuie s menionm contribuiile autorilor, dup cum

Prezentare general a serviciilor Web

1.1. Protocolul HTTP pe scurt

Un posibil rspuns obinut din partea serverului Web ar putea fi urmtorul

PREZENTARE GENERAL A SERVICIILOR WEB

Adresarea resurselor via URI

a unui identificator uniform de resurse este schema://autoritate/cale?interogare. O

Maniera de codificare a coninutului

PREZENTARE GENERAL A SERVICIILOR WEB

PREZENTARE GENERAL A SERVICIILOR WEB

Lista tuturor codurilor de stare este disponibil n specificaiile HTTP.

Permite controlul cache-ului, de cele mai multe ori la nivelul

Atribut general folosit pentru a specifica anumite proprieti

2. Arhitectura orientat spre servicii Web

n extranet (extindere a facilitilor intranetului prin mijlocirea comunicaiilor

2.2. Programarea aplicaiilor Web

PREZENTARE GENERAL A SERVICIILOR WEB

2.3. Servicii Web. Punerea problemei

RPC ( Remote Procedure Call)

(de obicei, fr aportul programatorului) apelurile locale de procedur ntr-o

PREZENTARE GENERAL A SERVICIILOR WEB

Necesitatea unei arhitecturi orientate spre servicii. Caracterizare

Figura 1. Spaiul Web ca tehnologie middleware

PREZENTARE GENERAL A SERVICIILOR WEB

un stil arhitectural de obinere a unor valori mutuale de ctre comunitile de

serviciile trebuie s partajeze un contract formal;

Astfel, arhitectura SOA trebuie s suporte ntre aplicaii paradigme de

i/sau de afaceri (B2B Business to Business). Suplimentar, prin intermediul

2.4. Conceptul de serviciu Web bazat pe XML

PREZENTARE GENERAL A SERVICIILOR WEB

ntr-un document HTML se mai numete i Web/HTML scrapping i se dovedete

realizarea de procesri (calcule) diverse;

accesarea, n manier public, se realizeaz printr-o adres; serviciile Web pot fi

Figura 2. Interaciunea ntre un serviciu Web i un client,

PREZENTARE GENERAL A SERVICIILOR WEB

XML pentru servicii Web: SOAP, WSDL i UDDI

Figura 3. Nivelurile de standardizare a serviciilor Web

Principalele protocoale de comunicare utilizate n prezent sunt XML-RPC i

PREZENTARE GENERAL A SERVICIILOR WEB

De asemenea, SOAP poate specifica i o cale de la expeditor la destinatar, via

prisma tipurilor de afaceri electronice pe care acestea le pot modela. Conceptual,

PREZENTARE GENERAL A SERVICIILOR WEB

Funcionalitile de cutare sunt implementate via servicii Web, astfel nct

i furnizeazaUtilizator(), adaugaUtilizator(), eliminaUtilizator(), listeazaUtilizatori() i

2.5. Modalitile de implementare i exploatare

PREZENTARE GENERAL A SERVICIILOR WEB

Figura 4. Arhitectura stratificat a unui cadru de lucru

De asemenea, trebuie s se pun la dispoziie mijloace pentru catalogarea,

Actualmente exist o sumedenie de tehnologii, produse i ofertani de servicii

PREZENTARE GENERAL A SERVICIILOR WEB

2. XML (Extensible Markup Language)

2.1. Caracterizare i trsturi eseniale

Aadar, XML este o metod de descriere universal a informaiei, astfel nct

2.2. Pri componente ale unui document XML

Exemplul de mai sus nu ne precizeaz anumite reguli de compunere a

CDATA (character data), cu rolul de inhibare a prelucrrii construciilor XML.

Instruciunile de procesare reprezint un tip special de marcaj care conine

2.3. Membrii constitueni ai familiei XML