Universitatea Politehnica Bucureti

Facultatea Electronic,Telecomunicaii i Tehnologia Informaiei

Tehnologii pentru dezvoltarea aplicatiilor si

serviciilor web in .net
SOAP, UDDI si WSDL

Profesor indrumator:
Stefan STANCESCU
Student: MARIN Alexandru Catalin
Master univeritar: IISC

2009-2010

1
 Cuprins

Cuprins 2
1 Introducere ................................................................................................................... 3
1.1 Introducere in Servicii Web .......................................................................................... 4
1.2 Exemple de servicii Web .............................................................................................. 5
1.3 .NET .............................................................................................................................. 6
1.3.1 Rularea serviciului standalone ......................................................................................... 6
1.3.2 Rularea serviciului pe server ........................................................................................... 7
2 XML ............................................................................................................................ 8
2.1 Introducere XML .......................................................................................................... 8
2.2 Structura XML .............................................................................................................. 9
2.2.1 Prologul documentului .................................................................................................. 10
2.2.2 Elemente XML .............................................................................................................. 10
2.2.3 Extinderea elementelor .................................................................................................. 11
2.2.4 Atributele XML ............................................................................................................. 11
2.2.5 Conflictele namespace ................................................................................................... 12
2.2.6 Caracterele speciale ....................................................................................................... 13
2.3 Validarea documentului XML .................................................................................... 13
2.4 XML DTD................................................................................................................... 14
2.5 XML Schema .............................................................................................................. 15
3 SOAP ......................................................................................................................... 16
3.1 Introducere .................................................................................................................. 16
3.2 Structura de mpachetare ............................................................................................. 17
3.3 Plic SOAP (SOAP Envelope) ..................................................................................... 18
3.4 Antet SOAP (Header) ................................................................................................. 19
3.4.1 Atributele principale pentru header-ul SOAP .............................................................. 20
3.5 Corp SOAP (Body) ..................................................................................................... 21
3.6 Codarea datelor ........................................................................................................... 22
3.7 Reguli generale ........................................................................................................... 22
4 WSDL ........................................................................................................................ 24
4.1 Introducere WSDL ...................................................................................................... 24
4.2 Structura documentului WSDL ................................................................................... 25
4.3 Elementele Port-uri WSDL ......................................................................................... 26
4.4 Elementele Operation WSDL ..................................................................................... 27
4.5 Elementele Message WSDL ....................................................................................... 28
4.6 Elementele Type WSDL ............................................................................................. 28
4.7 Elementele Binding (legtur) .................................................................................... 29
4.8 Folosirea documentului WSDL .................................................................................. 30
5 UDDI ......................................................................................................................... 31
5.1 Introducere UDDI ....................................................................................................... 31
5.2 Folosirea UDDI ........................................................................................................... 31
Bibliografia............................................................................................................................... 32

2
 1 Introducere

Lucrarea curenta incearca sa prezinte in ansamblu dezvoltarea serviciilor Web. Tehnologiile

examinate sunt .Net, COM, XML, SOAP ,WSDL si UDDI.
.Net este dezvoltat de Microsoft, a fost conceput pentru a oferii clientilor un serie de
frunctiionalitati predefinite pentru serviciile Web. Acest abordare are ca obiectiv o raspandire la scara
mai larga a dezvoltarii de aplicatii Web. Ofera usurinta si o accesabilitate sporita in cadrul dezvoltarii
de aplicatii Web.
COM acronimul de la Component Object Model, ofera posibilitatea componentelor software sa
comunice. Obiectele COM pot fii create folosind limbase obiect orientate precum C++, ofera
programatorilor mecanisme simple de implementat.
XML este un limbaj extensibil de marcare, a fost conceput si dezvoltat pentru transportul si
stocarea dalelor. Limbajul XML nu inlocuieste limbajul HTML, XMLul este orientat asupra
principalul datelor, ce sunt acestea de fapt, si cum pot fii stocate optim.
SOAP este un protocol simplu pentru schimbul de informaii. Acesta este bazat pe XML i este
format din trei pri:
parte ce descrie ceea ce este n mesaj i cum poate fi procesat
un set de reguli de codare
convenie pentru efectuarea RPC-urilor (Remote Procedure Call) precum i un mod de
rspuns.
WSDL stabilete gramatica XML folosita pentru a descrie modul de colecionare de obiective de
comunicare capabile s faca schimbul de mesaje.
Companiile pot publica WSDL, pentru serviciile pe care le furnizeaz iar alte companii pot avea
acces la aceste servicii utiliznd informaii n WSDL.
Link-uri in WSDL sunt de obicei oferite n companii cu profilul n registru UDDI.
UDDI este un descriptor universal pentru decoperire si integrare, este conceput specializat pentru a
permite ntreprinderilor s se beneficieze n noua economie digital.
A fost standardizat un registru UDDI, care este deschis pentru toat lumea. nscrierea este gratuit
i membrii pot introduce detalii despre ei nii i serviciile pe care le furnizeaz. Cutrile pot fi
efectuate dupa nume de companie, servicii specifice, sau tipurile de servicii efectuate.
Acest lucru permite companiilor, ce furnizeaz sau au nevoie de servicii web, posibilitatea de a se
descoperi reciproc, de a defini modul n care acestea interacioneaz pe Internet. Gestiunea de astfel de
informaii se face intr-un mod standardizat la scara globala.
Pentru serviciile Web nu exist o specificaie final pentru standardele folosite, ea fiind nc n
dezvoltare.

3
 1.1 Introducere in Servicii Web

Industria IT a cunoscut o dezvoltare extrem de rapid, de multe ori ducnd la modificri

radicale privind arhitectura i implementarea produselor software.

Serviciu Web sunt intr-o continua dezvoltare:

s fie transmis prin ct mai multe ci posibile prin reea.
Acest lucru este necesar companiilor ce doresc s foloseasc doar anumite protocoale de
transport pentru o mai bun securitate.
Cea mai bun solutie este folosirea protocolului HTTP (HyperText Transfer Protocol) datorit
posibilitii de a nu fi blocat de firewall.
s fie uor de extins i refolosit n aplicaii noi.
Obiectiv atins prin adoptarea programrii obiect orientate, ct i prin folosirea modularizrii.
Un serviciu poate fi vzut ca un modul, precum un obiect.
Clientul nu trebuie s stie c serverul se afl pe alt main ci doar s apeleze o metod a
serviciului ca i cnd acesta este un obiect ce aparine propriei aplicatii.
s ofere interoperabilitate, indiferent de platform, sistem de operare i limbaj de programare.
Problem se incearca a fi rezolvat prin decizia de a folosi XML (eXtended Markup
Language) pentru a transmite datele prin reea.
XML este un ansamblu foarte general, astfel a fost realizata o particularizare a acestuia,
rezultnd SOAP (Simpe Object Access Protocol). Acesta doar impune un set de reguli de
formatare a mesajului XML reprezentnd informaia transmis.
s fie uor de folosit pentru a descrie i a crea programe client.
Solutia a fost dezvoltarea unui noi particularizari XML, numita WSDL. WSDL ofera elemente
prestabilite capabile s informeze clientul asupra structurilor (obiectelor) folosite de serviciu,
asupra metodelor expuse i asupra modului de accesare a acestora (parametrii, tipul
parametrilor intrare, ieire, protocoalele de transport admise, stilul i tipul de codare, ...)
WSDL prezinta un caracter fix al limbajului, oferind posibilitatea realizarii unor utilitare ce
ofera suport de comunicare pe baza documentului WSDL ce descrie serviciul respectiv.
o cautare rapida precum si posibilitatea de a fi gsit pe internet.
Acest lucru este realizat prin folosirea regitrilor UDDI.
Ofera posibilitatea de a cuta cu uurint pe internet un serviciul dorit i s vad dac ntr-
adevr ndeplinete condiiile necesare pentru a putea fi folosit.

4
 1.2 Exemple de servicii Web

Pentru a demonstra c ntr-adevr serviciile Web reprezint o soluie viabil n lumea tehnologiei
informaionale, vom prezenta cteva servicii ce au fost deja implementate i fcute publice pentru
utilizatori din orice col al lumii:
http://www.google.com
Motorul de cutare Google ofer dezvoltatorilor posibilitatea de a accesa funcionalitatea
acestuia prin intermediul unui serviciu Web. Astfel pot fi dezvoltate programe ce beneficiaz
de capacitile motorului Google fr a necesita interaciunea utilizatorului prin clasica pagin
de Web.
http://www.amazon.com
Magazinul electronic Amazon ofer, un serviciu Web prin intermediul cruia se pot executa
cutri produse i de asemenea pli online.
http://translate.google.com/
Serviciu folosit pentru traducerea unui text dintr-o limb n alta.
http://www.xmethods.com/
XMethods este un site cu o list impresionant de servicii Web dintre cele mai variate.
http://telecom.berkeley.edu/uc/
Universitatea Berkeley din California foloeste servicii Web pentru a integra i mbunti
sistemul de comunicaii. Mai exact pentru a unifica emailul, voice-mailul i mesajele fax n
csue potale individuale ce pot fi accesate de proprietar prin intermediul telefonului celular,
PDA-ului (Personal Digital Assistant), telefon sau client mail. n acest moment proiectul este
n faza de dezvoltare.
http://www.iflyswa.com/cgi-bin/carItinerary
Foarte multe companii aeriene, de turism, de transport, de nchirieri se folosesc de servicii
Web nu numai pentru a oferi clienilor informaii de ultim or ct i pentru a integra ct mai
uor sisteme diferite. Ex: firma Dollar Rent a Car i Southwest Airlines, care au fondat un
parteneriat prin care firma de transport aerian d posibilitatea clienilor si s nchirieze o
main prin intermediul siteului propriu. Problema a aprut datorit diferenei de sisteme de
operare: compania aerian folosete UNIX pe cnd cea de inchirieri Windows. Soluia aleas
de Dollar este clar: implementarea unui serviciu Web prin intermediul cruia s se poat face
rezervri pentru mainile sale.
http://babelfish.altavista.com/
Companiile din domeniul financiar au mereu nevoie de valori la zi legate de stocuri, de
aciuni. Pentru a facilita accesul la astfel de informaii pentru agenii de burs, a implementat
un serviciu Web care returneaz valorile curente ale cotelor. Acest lucru a dus la o mai bun
organizare a informaiilor i astfel la un lucru mult mai efficient din partea angajailor firmei.

5
 1.3 .NET
Scopul principal al .Net Framework este de a oferii clientilor o serie de frunctiionalitati
predefinite pentru serviciile Web. Framework-urile sunt o clasa speciala de libraii software, cuprinde o
suma de functii generale ce pot fii specializate pe un anumit domeniu, acestea in general sunt
reutilizabile.
.NET Remoting este special optimizara pentru functionarea client-servar .Net. In acest mediu
se poate verifica ca servarul si clientul sa foloseasca gestionat de consum pentru optinerea codului
int. Chiar si in acest mediu este fosibila folosirea COM+Web service pentru a comunica prin
intermediu SOAP cu alte masini.
Rutarea .NET se poate combina cu SOAP pentru a oferii a optiune mai flexibila decat DCOM.
DCOM este acronimul de la Distributed Component Object Model, a fost dezvoltate de Microsoft
pentru a comunica intre aplicatiile software disctriubuite intr-o retea de calculatoare. DCOM

1.3.1 Rularea serviciului standalone

Platforma .NET ofera acest tip de rulare, desi in realitate aceasta nu este n ntregime
independent. Acest tip de serviciu are in componenta dou clase principale:
clasa care conine interfaa oferit de serviciu percum i implementarea
clasa ce lanseaz n execuie serviciul.
Prima clasa care conine interfaa i funcionalitatea serviciului este obinuit i trebuie s se
conformeze anumitor standarde cerute de platforma .NET.
A doua clasa este responsabil cu lansarea n execuie a serviciului, aceasta are o form standard.
In prima etapa clasa trebuie sa anunte platforma .NET c dorete s nregistreze un serviciu la o
anumit adres a sistemului i la un anumit port. Apoi ofera informaii referitoare la tipul de serviciu,
singleton sau one per request, care sunt clasele care i definesc interfaa i implementarea acestui
servicului.
Platforma .NET prezint traseul pe care l urmeaz un mesaj SOAP de la client ctre server i
napoi. Etapele sunt:
platforma .NET primete cererea de la client sub forma de mesaj SOAP i l trimite mai
departe la registrul de servicii Web.
registrul deserializeaz mesajul prin intermediul Motorului SOAP.
pe baza mesajului decodat, registrul ncarc serviciul dorit de client i apeleaz metoda cerut.
registrul primete rezultatul metodei cerute.
registrul serializeaz rezultatul metodei prin intermediul Motorului SOAP.
registrul trimite clientului rezultatul serializat n format SOAP.

6
 1.3.2 Rularea serviciului pe server

Rularea serviciul prin intermediul unui server beneficeaza de mecanisme specifice unui server
pentru repartizarea optim a cererilor, optimizarea conexiunilor, folosirea de sesiuni. In cadru .net este
posibil folosirea unor fiiere de configurare, unor fiiere de desfurare (deploy) i de dezinstalare
(undeploy) a serviciului astfel nct aceste operaii de rutin s se desfoare n mod automat. Aceste
fiiere speciale sunt specifice fiecrui server n parte, astfel c pentru a afla mai multe informatii
trebuie consultat ghidul serverului.
Rulare poate fi efectuata dou moduri:
rularea ntr-un server ce suport servicii (ex: IIS i serviciile .NET)
rularea serviciului prin intermediul unei aplicaii web instalate pe un server de aplicaii
(ex: Apache AXIS rulnd pe un server Tomcat sau Orion).
Soluile cele mai folosit pentru servere ce suport servicii este combinaia IIS cu servicii
.NET sau Apache Server cu modulul de .NET. n aceste cazuri, serverul are la dispoziie facilitile
oferite de platforma .NET, adic Motorul SOAP care nu este ncapsulat n server. Serverul este
responsabil de gestionarea serviciilor ct i rularea acestora, nlocuind rudimentara variant cu un
Registru De Servicii Web.
O varianta mai complex, necesar instalarea unui server de aplicaii (de exemplu Tomcat).
Serverului de servicii este inlocuit de o aplicatie Web care face gestionarea de servicii instalate i
ncrcarea i executarea acestora. Mesajul SOAP urmeaza urmatorul traseu:
serverul de aplicaii primete o cerere de la client;
pe baza URL-ului pe care l adreseaz, mesajul este trimis la aplicaia Web ce este nregistrat
la acea locaie. S presupunem c am primit un mesaj SOAP adresat aplicatiei Web
ServerSOAP instalat pe server atuncieste trimisa la punctul de intrare al aplicaiei, ex:
procesorul de cereri coninut de aplicaia ServerSOAP;
procesorul de cereri deserializeaz mesajul cu ajutorul Motorului SOAP (ServerSOAP)
procesorul de cereri localizeaz serviciul ce trebuie folosit, l ncarc i execut metoda cerut
de client;
procesorul de cereri primete rezultatul executrii metodei;
procesorul de cereri serializeaz rezultatul metodei folosind Motorul SOAP;
procesorul de cereri trimite serverului de aplicaii rspunsul deja serializat ;
serverul de aplicaii trimite ctre client rspunsul.

Serviciile SOAP care au ca scop implementarea funcionalitii cerute de specificaiile SOAP, sunt
oferite de ServerSOAP, astfel este scutit de a se ocupa de nivelul de transport, de acest nivel acesta
fiind responsabil serverului.

7
 2 XML

2.1 Introducere XML

XML este acronimul de la Extensible Markup Language, un limbaj extensibil de marcare. XML
a fost proiectat si dezvoltat pentru transportul si stocarea dalelor.

<?xml version="1.0"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>

Fig.2.1. Exemplu document XML

Limbajul XML nu a fost conceput pentru a inlocui limbajul HTML, acestea au avut concepte
diferite. HTML afiseaza informatiile pe care XML le transporta. Limbajul HTML a fost conceput
pentru a afisa date si informatii, principalul aspect a fost acela al modului incare datele sunt afisate.
Limbajul XML a fost conceput pentru transportul si stocarea de date, principalul aspect a fost acelea al
datelor, ce sunt acestea de fapt.
XML reprezinta un set de reguli cu ajutorul cruia pot fi descrise documente complexe i
structuri ramificare ntr-un mod natural. Acest limbaj nu conine cuvinte cheie ci doar elemente de
sintax ce definesc corectitudinea unui astfel de document.
Limbajul XML a aparut n anul 1998, devenind repede o component util a industriei IT.
Limbajul XML este o unealt central de dezvoltare n aplicaii ce se folosesc de schimburi de
informaii precum aplicaiile B2B, aplicaii distribuite client-server sau peer2peer.
Limbajul XML se afla intr-o continua dezvoltare, prin intermediul lui s-a dat un nou sens ideii
de structurare, modelare, organizare i descriere a informaiei. Au fost dezvoltate numeroase extinderi
precum: DTD, XML Schema, XPointer, XLink, XPath, XSLT, SOAP, WSDL, UDDI, SAX, DOM,
JAXM.
Pentru a putea intelege XML trebuie sa cunosti doar notiunile de baza, elementele, sintaxa i
regulile de validitate i cteva alte elemente referitoare la alte tehnologii auxiliare.
Sintaxa si regulile pe baza crora se construiete un document XML
Spaiile de nume, folosite pentru a identifica unic un element
Validarea documentelor XML cu ajutorul documentelor DTD i XML Schema
Pastrarea documentelor XML. Alegerea unei metodologii adecvate situaiei: DOM, SAX sau o
tehnic hibrid.

8
 2.2 Structura XML

Definim regulile de sintax necesare pentru a scrie un document XML valid. Structura standard
cuprinde o zon de prolog care este optional i conine instruciuni de procesare i zona de date, care
conine elementul rdcin al documentului.
Structura elementelor este aceea de arbore, in care avem definita o radacina si fii acesteia.

<root>
<child>
<subchild>.....</subchild>
</child>
</root>

Fig. 2.2. Structura document XML

<bookstore>
<book category="COOKING">
<title lang="en">Everyday Italian</title>
<author>Giada De Laurentiis</author>
<year>2005</year>
<price>30.00</price>
</book>
<book category="CHILDREN">
<title lang="en">Harry Potter</title>
<author>J K. Rowling</author>
<year>2005</year>
<price>29.99</price>
</book>
<book category="WEB">
<title lang="en">Learning XML</title>
<author>Erik T. Ray</author>
<year>2003</year>
<price>39.95</price>
</book>
</bookstore>

Fig. 2.3. Structura document XML

[1] http://www.w3schools.com/xml/xml_tree.asp

9
 2.2.1 Prologul documentului
Prologul unui document XML este opional. Prolog face referire la programare logica, un
conceput pentru analiza lexical.
Prologul este alctuit din una sau mai multe instruciuni. Instructiunile de procesare sunt
delimitate de <?, respectiv ?>. Acestea specifica versiunea de XML folosit i modul de codarea al
documentului.
n general aplicaiile XML nu folosesc instruciuni de procesare, coninnd informaiile
necesare n interiorul documentului propriu-zis.
Prologul poate conine i comentarii referitoare la coninutul documentului n cauz. Un
comentariu este coninut ntre semnele <!-- respectiv --> precum in HTML. Comentariile pot s
apar oriunde ntr-un document XML, fiind ignorate de aplicaiile XML.

<?xml version="1.0" encoding="utf-8"?>

<!--Numele fisier: test_rci.xml -->
<?xml-stylesheet type=text/css href=calefiier CSS?>

Fig. 2.4. Exemplu prolog document XML

2.2.2 Elemente XML

Elementele XML sunt delimitate de etichete de nceput cu o etichet de sfrit. Elemente sunt
definite de utilizator.
<note> <--elemente standard -->
<to>Sava</to> <--elemente definite -->
<from>Cata</from>
<heading>Reminder</heading>
<body>
Nu uita de tema de la RCI :D
</body>
</note>

Fig. 2.5. Elemente XML

De exemplu elementul rdcin al documentului exemplu are eticheta de start <note> i

eticheta de sfrit </note>. Elementul XML poate include i elementele imbricate, n cazul nostru
fiind vorba despre elementele <to>, <from>, ...
Numele unui element trebuie sa respect urmtoarele reguli:
Conine caractere alfanumerice ( 09, AZ, az )
Poate sa conina caracterele underscore _, cratima - sau dou puncte :
Trebuie sa nceap cu o liter

10
 Limbajul XML este case sensitive, adica face diferneta intre literele mari si cele mici,
elementele <to> si <To> difera.
Un element poate avea patru tipuri de coninut:
doar elemente imbricate (element-only)
doar text (text-only)
mixt
vide
Primele dou tipuri de coninut sunt mai usor de inteles i procesat. In exemplul anterior
<note> contine doar elemente imbricate iar <to> contine doar text.
Elemente vide nu contin nimic Ex: <element tip="book"></subiect>, poate fi scris <element
tip="book" />, o definire mai rapida. Acestea sunt folosite pentru a definii elementul si ulterior
declarate.

2.2.3 Extinderea elementelor

Elementele XML pot sa fie extinse

<note> <note>

<to>Sava</to> <to>Sava</to>
<from>Cata</from> <from>Cata</from>
<body> <heading>subiect</ heading >
Nu uita de tema de la RCI :D <body>

</body> Nu uita de tema de la RCI :D

</note> </body>
</note>

Fig. 2.6. Extindere elemente XML

Daca aplicatia trebuie sa afiseze doar elementele <to> <from> <boby>, la aparitia elementului
<heading> aplicatia nu se opreste, ea va afisa doar elementele necesare.

2.2.4 Atributele XML

Elemente XML pot avea, opional, unul sau mai multe atribute. Un atribut este reprezentat de
o pereche de tip nume=valoare, in exemplul din Fig.2.3 se poate observa atributul
category="COOKING.
Atribule ofera informatii ce nu fac parte din date, dar care sunt utile pentru identificare.
Atribule sunt folosite in general pentru stocarea metadatelor (date despre date).
Numele unui atribut trebuie s ndeplineasc aceleai restricii ca i numele unui element
XML. Valoarea atributului trebuie introdus sub form citat (intre ghilimele ) in toate cazurile.

11
 2.2.5 Conflictele namespace

Problemele namespace apar datorit folosirii de nume de elemente des ntlnite astfel se
produc coliziunii n documentele XML.
Astfel documentul definit principal, care are o anumit structur pentru elementul table,
include un alt document care poate defini propria form a elementului tabel.
n acest caz, dac documentul exemplu include acest nou document, aplicaia XML
responsabil cu interpretarea informaiei ar avea mari probleme n a recunoate despre ce tip de
element este vorba.
Acesta problema este des ntlnita, n limbaje precum C++ i C#, sau sub forma pachetelor n
limbajul Java. Acest mecanism presupune definirea unui nume calificat (qualified name) pentru un
element astfel: Nume calificat = identificator spaiu de nume + nume local
Spaiile de nume XML utilizeaz drept identificatori aa numiii identificatori de resursa
uniform (Uniform Resource Identifiers URI), acestia pot fi locatori (URL), nume sau ambele
xmlns="namespaceURI". De remarcat c, dac vei accesa adresa respectiv, nu vei gsi nimic, sau
chiar serverul va returna un mesaj conform cruia nu poate accesa pagina respectiv.
Este important de reinut c un spaiu de nume valid nu trebuie neaprat s indice un URL care
s i existe, ci doar s presupun faptul c alte persoane nu vor folosi un astfel de identificator. n acest
caz probabilitatea este sczut ca o alt persoan s foloseasc acest namespace.

<table xmlns="http://www.w3.org/TR/html4/"> <table

<tr> xmlns="http://www.w3schools.com/furniture">
<td>Apples</td> <name>African Coffee Table</name>
<td>Bananas</td> <width>80</width>
</tr> <length>120</length>
</table> </table>

Fig.2.7. Exemplu Exemplu rezolvare conficte de nume cu URI

Exemplu de rezolvare a problemei prin folosirea prefixelor, aceasta implica cunoasterea

continului documentului inclus.
<-- documentul 1 --> <h:table>
<table> <h:tr>
<tr> <h:td>Apples</h:td>
<td>Apples</td> <h:td>Bananas</h:td>
<td>Bananas</td> </h:tr>
</tr> </h:table>
</table>
<f:table>
<f:name>African Coffee Table</f:name>
<-- documentul 2 inclus de documentul 1 --> <f:width>80</f:width>
<table> <f:length>120</f:length>
<name>African Coffee Table</name> </f:table>
<width>80</width>
<length>120</length>
</table>

Fig.2.8. Exemplu rezolvare conficte de nume cu prefixe

http://www.w3schools.com/xml/xml_namespaces.asp

12
 2.2.6 Caracterele speciale

Caracterele precum <, & nu pot fii folosite in mod obisnuit XML, deoarece ar contrazice
regulile de validitate. Limbajul XML permite modalitati prin care putem sa folosim un caracter care nu
poate sa apar ntr-un document XML.
Folosirea unei astfel de metode asigur introducerea unor date mai complexe, dar sporete
dimensiunea documentului i gradul de dificultate pentru editarea acestora.
Metoda CDATA permite introducerea unei secvene de caractere permise de codarea
documentului, textul cuprins in CDATA nu este analizat de xml, dar nu poate sa includa ]]>.

<script>
<![CDATA[
function matchwo(a,b)
{ if (a < b && a < 0) then
{ return 1; }
else { return 0; }
}
]]>
</script>

Fig. 2.9. Date CDATA

2.3 Validarea documentului XML

XML este un limbaj flexibil, ofera utilizatorului posibilitatea de a defini elemente i structuri
proprii. Dar sunt cazuri (ndeosebi cele n care documentele trebuie procesate de o aplicaie) cnd este
necesar verificarea structurii i a informaiilor introduse.
Pentru a evita realizarea procesului de verificare direct de ctre aplicaia XML, s-a ales o soluie
mult mai elegant i modular: definirea unui limbaj pe baza cruia s se poat stabili structura unui
document XML.
Pentru ca un document XML s fie valid, el trebuie s ndeplineasc anumite reguli de sintax,
prestabilite de specificaiile XML:
Toate elemente trebuie s fie valide, ele trebuie s aib un nume valid, atribute valide i
trebuie s conin o etichet de nceput i una de sfrit.
Este case sensitiv <Message> EROARE </message>
Elementele trebuie ncapsulate corect. Astfel orice element copil trebuie nchis nainte de a
nchide elementul printe.
Exemplu structura < parinte ><copil></parinte></copil> nu este o structur XML valid.
Structura < parinte ><copil></copil></parinte> este o structur XML valid.
Documentul XML trebuie s conin un singur element rdcin.
Toate atribule trebuie sa fie intre , indiferent de tip (numar, data, text)

13
 2.4 XML DTD
Primul limbaj oficial de descriere al unui fiier XML este DTD (document type definitions).
Acesta presupune descrierea structurii unui document XML prin intermediul unei liste de elemente
permise. Aceste informaii pot fi plasate ntr-un fiier separat i referite de ctre documentul XML sau
pot fi incluse n documentul XML.

Cu ajutorul limbajului DTD se pot specifica urmtoarele lucruri referitoare la un document

XML:
Identificarea ordinii i a relaiilor dintre elemente definire
Elementele ce pot aprea n documentul XML
Identificarea atributelor pentru fiecare element

Structura unui document XML poate fi validat pe baza unui document DTD (coninutul
elementelor, atributele permise i tipurile lor de valori).
Folsirea DTD-urilor duce la aparitia unor probleme suplimentare:
Nu ofer capabiliti de reutilizare
XML care face verificarea pe baza unui document DTD trebuie s tie s interpreteze i acest
limbaj.
DTD-urile nu prezint faciliti mulumitoare pentru lucrul cu spaiile de nume, deoarece au
fost proiectate nainte de apariia spaiilor de nume
Structurarea elementelor este de multe ori prea restrictiv (n mod special ordinea n care apar
elementele i imposibilitatea definirii numrului de repetri admise de un element)
Nu definesc nici o noiune despre tipuri de date.

Din aceste motive unul din principalele protocoale de servicii Web interzic n mod explicit
folosirea DTD-urilor pentru definirea structurii documentului.

<!DOCTYPE note
[
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>

Fig.2.10.Format DTD

14
 2.5 XML Schema
XML Schema este de asemenea un limbaj de descriere a unui document XML, acesta poate face
validri ale structurii documentului XML. n comparaie cu DTD, XML Schema este un limbaj
puternic, complex, care prezint numeroase avantaje:
Suport pentru definire de structuri de date complexe (elemente i atribute)
Suport sporit pentru lucrul cu spaii de nume
Colecie standard de date simple (integer, string, date amd)
Schemele sunt exprimate cu ajutorul limbajului XML. XML are posibilitatea de a interpreta o
schem folosind aceleai metode de pastrare ca i pentru documentul XML.
XML Schema definete dou spaii de nume standard prin intermediul crora se vor putea crea
documente schem:
http://www.w3.org/2001/XMLSchema, prefixat deobicei xsd (XML Schema Definition)
definete elementele folosite pentru a construi un document schem
definete tipurile simple recunoscute de schema.
http://www.w3.org/2001/XMLSchema-instance, prefixat de obicei xsi (XML Schema
Instance) definete atribute ce sunt parte a specificaiei schemei. Aceste atribute pot fi aplicate
elementelor n documentele XML pentru a furniza informaii suplimentare unui procesor
XML.
Aceasta este lista de tipuri simple pe care XML Schema o recunoate: string, base64Binary,
hexBinary, integer, positiveInteger, negativeInteger, nonNegativeInteger, nonPositiveInteger, decimal,
boolean, time, dateTime, duration, date, Name, QName, anyURI, ID, IDREF.
Deoarece protocolul SOAP (vom vedea n capitolul urmtor) se bazeaz pe XML Schema pentru a
defini tipul atributelor obiectelor (folosind atributul xsi:type), acestea sunt i tipurile acceptate de
acesta (cu unele restricii).
Atributul xsi:type este folosit pentru a transmite aplicaiei XML informaii referitoare la tipul
datelor coninute de elementul respectiv. Prin intermediul lui aplicaia XML poate efectua verificri
suplimentare i de asemenea poate implementa o form primitiv de polimorfism.
Acestea sunt doar cteva elemente ce fac din XML Schema un limbaj puternic pentru definirea
structurii documentelor XML. Dac dorii s aflai mai multe informaii referitor la acest subiect, se
recomand parcurgerea specificaiilor oficiale W3C. Un pas nainte l reprezint parcurgerea unui
tutorial XML Schema.

<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>

Fig.2.11.Format XML Schema

15
 3 SOAP

3.1 Introducere
SOAP reprezinta acronimul pentru Simple Object Access Protocol, dupa cum ii spune numele
este un protocol simplu de accesare a obiectelor. Protocolul reprezinta un set de instructiuni folosite
pentru a putea transmite date intre doua dispozitive. SOAP reprezinta un protocol specializat pentru
schimbul de informatii in domeniul serviciilor de internet si al retelelor de calculatoare.
SOAP este rezultatul muncii de cercetare i dezvoltare a companiilor Microsoft i IBM, a
devenit un standard pentru implementarea serviciilor Web. Protocolul SOAP a fost proiectat pentru a
fii O infrastructur universal de calcul distribuit, pe baza XML. Protocol SOAP este contruit pe
baza regulilor propuse de limbajului XML. XML a fost dezvoltat pentru transportul si stocarea datelor,
reprezinta un set de reguli prin care sa putem coda documentele electronice.
Protocolul SOAP este destinat dezvoltrii de aplicaii de complexitate sporita, nu doar pentru
simple aplicaii B2B (Business-to-business) i eComerce. SOAP presupune servere capabile sa
ascunda nivelul de transport, astfel incat pentru utilizator toate resursele sa para localizate local. Se
dorete a fi un standard, folosit pentru a uura comunicarea dintre aplicaii diferite.
SOAP ofera posibilitatea unui calcul distribuit, poate fi utilizat pentru a realiza comunicarea
dintre aplicaii si procese. Aceast comunicare ofera o interfata standard astfel incat este independent
de platform, sistem de operare i limbaj de programare, oferind interoperabilitatea aplicaiilor la
distan. La ora actuala SOAP reprezinta unul dintre cele mai bune eforturi al industriei IT de a
standardiza tehnologia de infrastructur pentru calculul distribuit multiplatoform pe baza XML.
SOAP ofera o serie de mecanisme prin care doreste sa acopere o gama foarte larga de aspecte
aferente calculului distribuit.
Un mecanism de legtur a mesajelor SOAP la HTTP, acesta fiind cel mai utilizat protocol de
comunicaie.
Un mecanism de gestionare a erorilor, in cazul producerii unei erori acesta poate transmite
informaii despre natura erorii i locul producerii acesteia.
Un mecanism de definire a unitii de comunicaie, acesta ncapsuleaz orice mesaj transmis
ntr-un pachet cu structur prestabilit.
Un mecanism de extensibilitate, ofera posibiliatea de a adauga noi funcionaliti pe aceeai
structur de baz.
Un mecanism flexibil pentru reprezentarea datelor, acesta permite schimbul de date deja
formatate (text sau XML) ct i unele convenii pentru reprezentarea structurilor de date
abstracte ntr-un limbaj de programare.
Un mecanism pentru reprezentarea RPC (Remote Procedure Call), acesta implic definirea
unor structuri standard pentru un apel de procedur la distan i de asemenea pentru
comunicarea rspunsului.
Un mecanism pentru schimbul de documente documente, acesta reprezinta o alternativ la
RPC, pentru a evita granularizarea interfeelor.

16
 3.2 Structura de mpachetare

Este cea mai important parte specificat de SOAP, se refer la modul de mpachetare. Const
n doar cteva elemente XML, dar care ofer o structura i mecanismele de extensibilitate care fac
SOAP un fundament pentru calculul distribuit pe baz de XML.
Structura unui mesaj SOAP:
un element de inceput numit plic SOAP (SOAP envelope), folosit pentru identificarea
documentului XML ca fiind un mesaj SOAP
un antet SOAP (SOAP headers), prezenta acestora este opionala, contine informatii de
tip header
un corp SOAP (SOAP body) ce cuprinde datele transmise si receptionate prin
intermediul mesajului
un element EROARE (SOAP Fault), ce contine erori si infomarii despre starea
mesajului

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-
envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soa
p-encoding">

<soap:Header>
...
</soap:Header>

<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>

</soap:Envelope>

Fig 3.1. Structura SOAP

17
 3.3 Plic SOAP (SOAP Envelope)

Din punct de vedere XML un mesaj SOAP este ncapsulat ntr-un element envelope care este
coninut de spaiul de nume xmlns:soap http://www.w3.org/2001/12/soap-envelope.

Plicul conine i informaia de versionare a mesajului. Aceasta nu este inut sub form numeric,
este reprezentat de spaiul de nume de mpachetare (cel care are asociat prefixul SOAP). n cazul
mesajelor SOAP, serverul poate spune doar dac mesajul are o versiune pe care o recunoate sau nu.
Nu se poate pronuna asupra compatibilitii versiunii recunoscute cu cea prezent n mesaj.
Astfel se limpezete mult procesul de stabilire a versiunii protocolului ntre client i server (ori
serverul cunoate versiunea de mpachetare a mesajului caz n care se continu comunicarea, ori
serverul nu cunoate versiunea n cauz, i rspunde cu un mesaj de eroare).

Atribul legat de modul de codare Ex: soap:encodingStyle definete tipul de codare al mesajului.
SOAP reprezint spaiul de nume ce conine elementele unui plic SOAP (eticheta de antet i cea de
corp).

Plicul presupune declararea spaiilor de nume standard pentru protocolul SOAP precum si a
atributelor suplimentare daca acestea sunt prezente.

Pot exsita doua scheme:

xsd definete spaiul de nume pentru definiia XML Schema. n acest caz se va folosi
codificarea din schema 2001.
xsi definete spaiul de nume pentru atributele unui element din XML Schema.

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

...
Mesaj
...

</soap:Envelope>

Fig 3.2. Exemplu plic SOAP

18
 3.4 Antet SOAP (Header)

Antetul unui mesaj SOAP reprezint mecanismul primar de extindere a funcionalitii

protocolului SOAP, adauga caracteristici pentru un mesaj SOAP, neadugnd alte restricii.

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234
</m:Trans>
</soap:Header>
...
...
</soap:Envelope>

Fig 3.3. Exemplu antet SOAP

Zona antetului SOAP este un element optional, dar daca soap:Header este prezent el trebuie sa
fie primit ca prim element copil al elementului plic soap:Envelope. Elementul soap:Header trebuie sa
fie descendent direct al elemntului root soap:Envelope.

Antetul definete propriul spaiu de nume de care aparine, antetul poate include atributul
soap:mustUnderstand. Dac soap:mustUnderstand este prezent i are valoarea 1 atunci serviciul este
obligat ca, dac nu poate nelege acest antet (nu tie s l proceseze) s rspund cu un mesaj de
eroare (fault).
In antetul prezentat trebuie sesizata prezenta prefixului m:, elementului Trans, a atributului
soap:mustUnderstand ce are setata valoarea 1, si valoarea 234.

Aceste anteturi sunt specifice serviciului care le interpreteaz i pot fi folosite pentru
transmitere de informaie de autentificare, informaie despre identificatorul tranzaciei de pe server,
informaii despre identificatorul sesiunii folosite. Astfel poate sa modifice modul in care un server
trebuie sa proceseze un mesaj de tip SOAP.

19
 3.4.1 Atributele principale pentru header-ul SOAP

Atributul mustUnderstand (soap:mustUnderstand="0|1") mentioneaza daca mesajul este sau nu

obligatoriu ca serverul sa-l inteleaga, poate avea valorile 0/1. Daca acesta este setat la valoarea 1,
atunci cel care proceseaza mesajul trbuie sa recunoasca elementele. Daca nu este recunoscut, mesajul
este respins din momentul in care proceseaza antetul.

Atributul actor (soap:actor="URI"), este folosit pentru a informa elementul header asupra
nodului final . In general un mesaj circula prin mai multi intermediari, este posibil ca nu toate partile
mesajului sa fie intentionate nodului final.

Atributul encodingStyle (soap:encodingStyle="URI"), este folosit pentru a definii tipul de date

folosit in document.
Daca acest element este prezent intr-un element SOAP, el se aplica asupra elementului precum
si asupra copiilor.

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:actor="http://www.w3schools.com/appml/"
soap:mustUnderstand="1">234
</m:Trans>
</soap:Header>
...
...
</soap:Envelope>

Fig 3.x. Exemplu header complet SOAP

20
 3.5 Corp SOAP (Body)

Elementul soap:Body, cuprinde chiar informaia necesara nodului destinatie, reprezinta

informatia care st la baza mesajelor SOAP.

Elementul soap:Body trebuie sa urmeze imediat elementului antet daca acesta este prezent,
daca elementul antet nu este prezent elementul corp trebuie sa urmeze imediat elementului plic.

Toi copiii direci ai elementului Body se numesc corpuri, corpurile pot conine XML arbitrar.
n general pe baza tipului mesajului SOAP (RPC sau message) pot guverna anumite convenii asupra
structurii corpului mesajului SOAP.

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>

</soap:Envelope>

Fig 3.4. Exemplu corp mesaj SOAP, aflare pret

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body>
<m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>

</soap:Envelope>

Fig 3.5. Exemplu corp raspuns SOAP, valuare pret

21
 3.6 Codarea datelor

Mesajele SOAP conin informaii referitoare la modul n care modelul obiectelor este mapat la
limbajul SOAP XML. De asemenea prezint algoritmi de baz pentru executarea urmtoarelor trei
sarcini:

avnd informaii despre organizarea unui model de obiecte, trebuie sa construiasc o schem
XML pentru descrierea acestui model
fiind dat o list de obiecte ce respect modelul de mai sus (un graf instan al modelului de
obiecte), s se genereze cod XML necesar care s se conformeze schemei.
Aceasta reprezinta operaia de serializare.
fiind dat cod XML care se conformeaz schemei, s se creeze o structur de obiecte care s
ndeplineasc condiiile modelului de la primul punct.
Aceast operaie se numete deserializare.

Dei scopul codrii pare a fi simplu, de a mapa elementele XML, regulile efective de realizare
pot fi complicate.

3.7 Reguli generale

Codarea SOAP folosete un sistem de tipuri bazat pe XML Schema, majoritatea tipurilor
prezente n XML Schema sunt folosite de SOAP pentru a mapa informaia n cazul tipurilor simple.
Obiectele simple sunt mapate n XML ca un element ce conine doar text.
n afar de aceste tipuri simple mai exist tipurile compuse, acestea fiind alctuite din mai multe
pri. Un astfel de obiect compus este mapat n XML printr-un element ce contine elemente imbricate.
Pornind de la tipurile compuse, se disting dou categorii:
structurile, care au elementele imbricate deosebite prin numele lor
tablourile, care se disting doar prin poziia lor de ordine
Valorile simple sunt codate ca i coninutul elementelor care au un tip simplu, cu coninut text
iar valorile compuse sunt codate ca i coninutul elementelor care au un tip compus, i care sunt
alctuite din elementele copii coninute de acestea. Ele nu pot s conin elemente text. Valorile nu
sunt niciodat codate ca atribute ci doar ca i coninutul unui element.
Orice element XML creat prin serializarea unui obiect conine un atribut xsi:type prin
intermediul cruia se determin maparea ce va fi folosit. Acest atribut este folosit pentru a realiza
polimorfismul SOAP.
SOAP permite i transmiterea valorilor nule, sunt definite dou modaliti prin care se poate
realiza acest lucru:
prin omiterea elementului care are valoare nul, lipsa acestuia presupune valoarea nul
prin folosirea atributului xsi:nil
acesta trebuie setat cu valoarea true n caz c atributul este nul

22
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

<env:Header>

<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="1">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>

<n:passenger xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>ke Jgvan yvind</n:name>
</n:passenger>

</env:Header>

<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">

<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>

<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid-morning</p:departureTime>
<p:seatPreference/>
</p:return>

</p:itinerary>

<q:lodging
xmlns:q="http://travelcompany.example.org/reservation/hotels">
<q:preference>none</q:preference>
</q:lodging>

</env:Body>

</env:Envelope>

Fig 3.6. Exemplu mesaj SOAP

http://www.w3.org/TR/2007/REC-soap12-part0-20070427/

23
 4 WSDL

4.1 Introducere WSDL

WSDL este acronimul de la Web Services Description Language. WSDL reprezinta un

documnet scris in XML, care descrie un serviciu Web. In document sunt specificate locatia serviciului,
a operatiilor precum si a metodelor oferite de acest serviciu.

Protocolului SOAP prezint un nivelul ridicat de interoperabilitate, acest lucru a nceput s

devin tot mai probabil odat cu adoptarea pe scar larg a protocoalelor bazate pe XML. Odat cu
publicarea specificaiilor oficiale, aceste protocoale sunt cu un pas mai aproape de a-i atinge scopurile
initiale de stadardizare, oferind un mod de lucru distribuit.
Interoperabilitatea reprezint capacitatea aplicaiilor, aflate pe platforme diferite, pe sisteme de
operare diferite i programate n limbaje diferite, de a interschimba informaii. Interoperabilitatea este
ngreunat deobicei de probleme precum nepotrivirea codrii caracterelor de la o limb la alta,
reprezentarea diferit a unor tipuri standard. Codare binar standard este destul de greu de definit
pentru a reui s reuneasc toate caracteristicile mai multor limbaje de programare diferite. O soluie
viabil este oferita limbajului XML prin mesajele SOAP.

Dei specificaiile, implementrile corecte de biblioteci SOAP precum i ali factori

independeni de programator influeneaz caracterul de interoperabilitate, important de tiut este c i
programatorul joac un anume rol n sporirea gradului de interoperabilitate al unui serviciu Web.
WSDL ofera programatorului posibilitatea de a urma anumite procedee standard de
implementare i elemente recomandate de organizaii internaionale (precum WS-I). Pstrarea ct mai
general a implementrii, fr a folosi tipuri speciale ale motorului SOAP folosit, ct i modularizarea
i documentarea serviciului pot face din acesta o soluie viabil pentru muli poteniali clieni.
Exista programatori care vor s se foloseasc de funcionalitatea oferit de serviciul Web n
cauz. Dar sarcina lor este foarte dificil n cazul lipsei documentaiei referitoare la interfaa oferit de
serviciu i la maprile ce trebuie folosite pentru a putea transmite corect obiecte i alte informaii.

Din aceast cauz au luat natere mai multe limbaje de documentare a unui serviciu Web.
Unele dintre ele se axeaz pe organizarea i accesarea serviciilor, altele pe topografia unui serviciu
Web mai complex iar altele pur i simplu descriu ce face fiecare metod i cum ar trebui apelat.
Dintre toate aceste limbaje se remarc, datorit folosirii sale pe scar larg, limbajul WSDL (Web
Services Description Language). Submis pentru aprobare de ctre IBM, Microsoft i alii n
septembrie 2000, acest protocol are ca rol descrierea tehnic elementar a interfeei serviciului.

24
 O descriere WSDL prezint trei proprieti fundamentale ale unui serviciu Web:
ceea ce face serviciul operaiile pe care serviciul le furnizeaz.
cum este accesat serviciul detalii ale formatelor de date i protocoale folosite pentru
accesarea operaiilor.
unde este localizat serviciul detalii ale adresei de reea specifice protocolului (un URL).
Document WSDL ce descrie un serviciu este destul de impresionant, ca dimensiuni ct i ca
varietate de etichete, spaii de nume, ... . Dei este bazat tot pe limbajul XML, citirea lui poate fi destul
de greoaie datorita marimii. De aceea urmtorul subcapitol va prezenta organizarea unui astfel de
document i nsemntatea fiecrei etichete.
Avnd n vedere nivelul nalt de normalizare al unui astfel de document, odat ce ai neles
elementele componente, va fi uor de urmrit, pas cu pas, funcionalitatea oferit de un serviciu Web
descris cu ajutorul acestui limbaj.

4.2 Structura documentului WSDL

Documnetle WSDL descriu servicii Web ce pot sa foloseasca:
<types> - tipurile de date folosite de serviciul web
<message> - mesajele folosite de serviciul web
<portType> - operatiile efectuate de serviciul web
<binding> - protocoalele de comunicare folosite de serviciile web

<definitions>

<types>
definire tipurilor ...
</types>

<message>
definirea mesajelor ...
</message>

<portType>
definirea porturilor ....
</portType>

<binding>
definirea protocoalelor ...
</binding>

</definitions>

Fig 4.1. Structura generala documentelor WSDL

25
 4.3 Elementele Port-uri WSDL

Elementele <portType> sunt cele mai importante elemente WSDL, Acestea descriu interfata
serviciului. Celelalte elemente reprezinta modalitati prn care <portType> functioneaza.

Elementele <portType> descriu serviciile web, operatiile pe care aceste le por efectua, si
mesajele care sunt implicate. Suma acestor elemente poate fii comparata cu o librarie de functii,
module si clase din programarea clasica.

Un element <portType> conine un singur atribut name. Acesta definete numele prin care se
va face referire in interfaa n acest document. De aceea el trebuie s fie diferit de numele altor
elemente <portType> aflate n WSDL. Numele acestor elemente respect n general un ablon general
acceptat numeServiciuWebWS sau numeServiciuWebPortType.

Elementul <portType> conine mai multe elemente operation prin intermediul crora se
definete inferfaa portului respectiv. Un document WSDL poate conine zero sau mai multe definiii
de tip <portType>.

<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>

<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>

Fig 4.2. Exemplu portType WSDL

In exemplu prezentat, elementul <portType> defineste "glossaryTerms" ca fiind numele

acestui port si "getTerm" ca fiind numele unei operatii.
Operatia "getTerm" are un mesaj de intrare "getTermRequest" si un mesaj de iesire
"getTermResponse".
Mesajele definesc mesajele in parte precum si tipul de date asociat.

26
 4.4 Elementele Operation WSDL

Un element <operation> definete o metod petru un serviciu Web, inclusiv numele metodei i
parametrii de intrare, precum i tipul de returnare al metodei i, dac este necesar, erorile (fault) ce pot
fi generate.

<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>

Fig 4.3. Exemplu operation WSDL

In exemplu anterior "glossaryTerms" definete o singur operaie (metod) denumit getTerm.

Aceasta este de tip cerere-rspuns deoarece primul element copil este de tip input i este urmat de un
element de tip output.

Prin intermediul elementelor input/output pot fi definite patru tipuri de apel:

operaie cerere-rspuns (Request-response) primul element este de intrare, al doilea de ieire;
echivalentul unui apel de metod;
operaie cu sens unic (One-way), doar elementul de intrare;
echivalentul unei operaii care transmite date i nu necesit rspuns;
operaie de notificare (Notification), doar elementul de ieire;
echivalentul notificrii clientului de ctre server c un eveniment a avut loc;
operaie de solicitare rspuns (Solicit-response), elementul de ieire urmat de cel de intrare;
echivalentul cererii serverului de a primi un rspuns de la client.

In WSDL se foloseste cu preponderenta mesajele cu sens unic i cerere-rspuns. Mesajele de

tip notificare i solicitare rspuns cer un anumit tip de corelare, fiind necesare cunoaterea n prealabil
a anumitor elemente pentru ca serverul s poat iniia comunicarea cu clientul (adresa i portul la care
acesta poate fi gsit amd).

Cele dou elemente copil ale elementului <operation> nu definesc efectiv semntura intrrii
sau ieirii ci refer anumite mesaje care reprezint semntura de intrare i cea de ieire a metodei.

27
 4.5 Elementele Message WSDL

Un mesaj WSDL reprezint un concept foarte simplu, reprezinta o colecie de pri. Un

document WSDL poate conine zero sau mai multe elemente <message>, acestea fiind plasate ca i
copii ai elementului rdcin.
n exemplul prezentat, sunt definite dou mesaje, unul referit de intrarea operaiei
<getTermRequest>, altul referit de aceeai operaie <getTermRequest> prin intermediul elementului
de ieire.

<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>

<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>

Fig 4.4. Exemplu message WSDL

Un element <message> conine obligatoriu un atribut name. n acest caz el are valoarea
getTermRequest. Numele fiecrui element <message> trebuie s fie unic n interiorul documentului
WSDL deoarece el va fi identificatorul prin care va fi referit mesajul, pentru a evita conflicte.
Aceste mesaje conin doar o parte de tip xs:string. O parte este format din dou proprieti:
numele prii i tipul acesteia. Atributul name trebuie s fie unic ntre toate elementele copil ale
mesajului. Proprietatea de tip este definit ca un atribut type, acesta lund valori specifice XML

4.6 Elementele Type WSDL

Cu ajutorul seciunii <types> se definesc tipuri noi ce vor fi folosite de serviciul Web.

Modul de definire este cel folosit de XML.

Structura acestor tipuri este definit cu ajutorul limbajului XML Schema i poate fii introdus
cu ajutorul elementului complexe.

28
 4.7 Elementele Binding (legtur)

Elementele de tip <binding> definesc formatul mesajelor si detaliile protocoalelor pentru

fiecare port.
Serviciul are definite interfeele pe care le expune (cu ajutorul elementelor <portType>), dar
nu specific pe moment nimic despre modul n care aplicaia client poate s acceseze aceste metode.
Scopul elementului legtur <binding> este de a ataa informaii referitoare la protocolul de transport
(HTTP, FTP, SMTP, ...), stilul apelului (rpc sau document) i specific, pe rnd, pentru fiecare
operaie coninut de portul legat, cum se face codarea spaiul de nume ce trebuie folosit i modul de
codare.
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>

<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>

<binding type="glossaryTerms" name="b1">

<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<operation>
<soap:operation soapAction="http://example.com/getTerm"/>
<input><soap:body use="literal"/></input>
<output><soap:body use="literal"/></output>
</operation>
</binding>

Fig 4.5. Exemplu binding WSDL

Un element de tip <binding> conine obligatoriu un atribut name. Acesta trebuie s fie unic
n documentul WSDL.
n cazul exemplului prezentat numele elementului legtur este b1, acesta are definit
elementului soap:binding ce specific nivelul de transport folosit (n cazul nostru este vorba de HTTP,
referit prin folosirea atributului transport) i modul n care se face apelul (definit prin intermediul
atributului style, care poate avea valorile document sau rpc).

29
 Elementul legtur trebuie s precizeze informaii de acces pentru fiecare din operaiile
definite de portul legat, in acest caz fiind vorba despre o singur operaie.
Operatia definete valoarea atributului soapAction pentru a descrie intenia clientului n
apelul metodei respective. Apoi se specific formatarea mesajului de input pentru operaie i de
asemenea formatarea mesajului de output.

4.8 Folosirea documentului WSDL

Un document WSDL descrie o interfaa oferit de un serviciu Web i modul n care aplicaia
client ar trebui s acceseze serviciul. Pentru nceput el poate fi folosit de programatorul aplicaiei
client spre a nelege interfaa client i clasele de date folosite.

Document respect anumite reguli publice (specificaiile WSDL) favorizand astfel dezvoltarea
unor utilitare extrem de practice, care sunt capabile s genereze clasele de comunicare client (stub) i
server (skeleton) pe baza acestor informaii.
Stud, se refera la retele independete ce nu sunt constiente de legaturile pe care le au cu alte
retele. In comunicatiile stud tot traficul extern este efectuat pe o singura cale, reteaua fiind constienta
doar de calea definita catre o destinatie externa. Serverele skeleton se folosesc acum (Java 2) doar
pentru implementarea RMI (Remote Method Invocation), anterior erau folosite si pentru
implementarea RMC (Remote Method Xalls)

Spre exemplu Apache AXIS ofer programatorilor aplicaia WSDL2Java ce are ca rol
preluarea unui document WSDL ce descrie un serviciu Web i crearea claselor de date i a claselor de
comunicare prin intermediul crora aplicaia client va efectua apelurile la distan. Aceste clase de
comunicare public interfaa serviciului Web i ascund nivelul de transport (serializarea elementelor,
efectuarea apelului prin protocolul de transport, primirea rspunsului amd). Programatorul percepe
serviciul Web ca pe un obiect ce aparine de aplicaia sa.
Pe lng motorul SOAP sunt oferite si aplicatii de generare a claselor WSDL, aceste aplicatii
sunt in general sunt accesorii auxiliare. Dup cum am menionat, Apache AXIS dispune de un astfel
de utilitar. De asemenea aceast funcionalitate este oferita si de mediul integrat de dezvoltare Visual
Studio .NET. Puterea acestor tipuri de programe a crescut, astfel c genereaz cod optim n timp foarte
scurt, eliminnd perioada de dezvoltare a nivelului de comunicare de ctre programatori.

30
 5 UDDI

5.1 Introducere UDDI

UDDI reprezinta acronimul de la Universal Description, Discovery and Integration, reprezinta
un serviciu de directoare prin care companiile se pot inregistra si pot cauta servicii Web. Ofera
posibiliatea de publicare i promovare de servicii Web pe un site Web specializat n acest proces. n
acest caz, site-ul Web acioneaz ca un registru de servicii iar operaia de publicare este doar un act de
prezentare Web ce poate fi accesat cu un simplu browser de HTML.
UDDI foloseste standardele create de W3C(World Wide Web Consortium comunitate
internatinala fondata pentru standardizarea Web) si IETF (Internet Engineering Task Force
comunitate ce are ca scop imbunatatirea calitatii serviciilor Web) precum standardele XML, HTTP si
protocoalele DNS.
UDDI include mult mai mult informaie dect descrierea de serviciu, incluznd metadate de
afaceri. UDDI nu numai c rspunde ntrebrii unde este localizat serviciul ci abordeaz i ntrebri
de genul Cum tie solicitantul ce afacere furnizeaz serviciul.
Obiectivul UDDI este de a facilita descoperirea de servicii Web att pentru proiectare ct i n
mod dinamic, la execuie. Proiectul UDDI menine un registru de afacere public online, mpreun cu
serviciile corespondente, denumit UDDI Business Registry.

5.2 Folosirea UDDI

UDDI este mai mult dect un registru de servicii i de afaceri, definete i un set de structuri
de date i o specificaie API pentru a nregistra i a gsi afaceri, servicii, legturi i tipuri de servicii,
prin program.
Funcionalitatea UDDI poate fi accesat prin intermediul unei interfee Web oferite de
operatorii UDDI, precum site-urile http://www.ibm.com/services/uddi i http://uddi.microsoft.com.
un set de specificaii de structur a datelor, pentru ca metadatele s fie stocate n registru;
un set de specificaii ale operaiilor Create, Read, Update, Delete, pentru stocare, tergere i
interogare a datelor din registru;
drept de proprietate;
Datele pot fi plasate n una sau mai multe categorii, facilitnd operaia de cutare i interogare;
autentificare pentru operaii de schimbare a informaiei i pentru regitrii publici;
acces deschis pentru operaiile de citire i interogare.

31
Bibliografia

Servici Web:

http://www.w3schools.com/webservices/default.asp
http://www.scritube.com/stiinta/informatica/Aplicatiile-web-si-dispozitive25271.php
http://www.brics.dk/~amoeller/WWW/webservices/index.html

COM:

http://msdn.microsoft.com/en-us/library/ms694505%28v=VS.85%29.aspx

XML:

http://www.w3schools.com/xml/default.asp
http://uddi.xml.org/uddi-org
http://www.upg-ploiesti.ro/col/ldumitrascu/html/content.jsp-id=465.htm

SOAP:

http://www.w3schools.com/soap/default.asp
http://www.w3.org/TR/soap/
http://www.w3.org/TR/soap12
http://schemas.xmlsoap.org/soap/envelope/

WSDL:

http://www.w3schools.com/wsdl/default.asp

UDDI:

http://www.w3schools.com/wsdl/wsdl_uddi.asp
http://java.sun.com/j2se/1.4.2/docs/api/java/rmi/server/Skeleton.html
http://www.w3.org/Consortium/
http://www.ietf.org/

32