CUPRINS:

INTRODUCERE:
CAPITOLUL I. Notiuni generale privind Serviciile Web
1.1.Apariţia şi dezvoltarea serviciilor Web
1.2.Serviciile Web. Noţiuni generale
1.2.1. Metodele serviciilorWeb
1.2.2. Arhitectura soluţiei. Suita de tehnologii (XML, UDDI, WSDL, SOAP)
CAPITOLUL II Piata virtuala de E-Comerce
2.1. Avantaje si dezavantaje pentru clienti
2.2. Concurentii comertului electronic
CAPITOLUL III Tehnici de promovare. Studiu de caz la FASHION DAYS SHOPPING S.R.L.
3.1. Prezentarea generală a societăţii comerciale
3.1.1.Gama de produse
3.1.2.Structura organizatorică şi date privind personalul firmei
3.1.3.Piaţa firmei
3.1.4.Activitatea de marketing
3.1.5.Evaluarea performanţelor financiare are firmei
3.1.6.Analiza SWOT
3.2. Orientarea firmei spre client – tendinţa majoră în noua economie de promovare on line
3.2.1.Aspecte generale privind orientarea spre client a companiei
3.2.2.Mix-marketingul - Trecerea de la cei 4P la cei 3C
3.2.3.Cunoaşterea comportamentului clienţilor
3.2.4.Canalele de interacţiune cu clientul
3.2.5.Personalizarea interacţiunii cu clientul
3.2.6.Atragerea şi retenţia şi recâştigarea clienţilor
3.2.7.Optimizarea valorii fiecărui client
3.2.8.Atitudine proactivă a tuturor angajaţilor
Concluzii şi propuneri
Bibliografie

Introducere
 World Wide Web-ul, domeniul virtual în care îşi desfăşoară activitatea şi firma
studiată, a fost înfiinţat în anul 1991, transformând internetul folosit doar în domeniul
cercetării la internetul cu scop comercial, informativ, educativ, etc. S-a dezvoltat de asemenea
şi latura comercială a acestei unelte moderne, aceasta fiind atât de atractivă datorită
comodităţii şi multitudinii de informaţii, încât actualmente tinde să devină unul dintre cele
mai importante domenii de desfăşurare a comerţului. Observând această oportunitate,
actualualii asociaţi ai companiei FASHION DAYS SHOPPING S.R.L., au înfiinţat un
magazin online de tip outlet: http://www.fashiondays.ro, prin intermediul acestuia urmând să
se comercializeze haine, accesorii şi genţi de damă. Aşadar asociaţii, de altfel şi managerul
acestei firme a angajat iniţial trei salariaţi, ce făceau diferite tipuri de muncă în mod
complementar. Datorită succesului companiei s-a ajuns la concluzia că cei trei angajaţi
împreună cu managerul, nu puteau face faţă nivelului de muncă datorită multitudinii de
comenzi, soluţia fiind, evident, angajarea altor persoane. La această dată firma are în
subordine peste 379 de angajaţi, fiecare lucrând, în principiu, pe un anumit segment.
De ce afaceri în mediul online? Pentru că acest mediu nu reprezintă doar o modă, ci
este o metodă revoluţionară de a face afaceri. În mediul online, se observă modificări majore
în ceea ce priveşte informaţia. Aceasta este transmisă mult mai prompt şi corect, între oricare
dintre părţile implicate, respectiv depozite, furnizori, curieri, firma, angajaţii firmei şi mai ales
clienţi. De asemenea, un alt motiv pentru alegerea spaţiului virtual este faptul că tot mai multe
întreprinderi îşi fac simţită prezenţa şi în mediul online, iar experienţa este privită ca un
criteriu foarte important de către client.
Pe segmentul de piaţă ales de FASHION DAYS SHOPPING S.R.L., concurenţa este
aprigă, nu numai în domeniul online cât şi în magazine, fiecare încercând să obţină cel mai
bun raport calitate-pret, ajutându-se, în funcţie de posibilităţi, de tehnicile de negociere, de
depozitare, de manipulare, de informaţii, etc. Cei din incinta firmei studiate, analizează
permanent atât piaţă, cât şi concurenta, pentru a cunoaşte în ce măsură este rentabil să îşi
creeze stocuri la anumite produse sau să le afişeze în magazinul online. De asemenea,
salariaţii au în vedere un aspect foarte important, la care lucrează constant, respectiv
încântarea şi fidelizarea clienţilor, cunoscându-se efectele benefice pe termen lung al acestor
tehnici.
În acest proiect de licenţă, urmează a fi prezentate structura companiei FASHION
DAYS SHOPPING S.R.L., precum şi punctele ţări ale acesteia în comparaţie cu companiile
concurente existente în momentul de fată pe piaţă. De asemenea, în lucrarea de fata vom
evidenţia aspectele ce fac ca această companie să fie unul dintre liderii de piaţă în domeniul
vânzărilor online de vestimentaţie pe piaţa din România şi nu numai. În capitolul întâi se
regăsesc aspecte privind delimitarea conceptuală a temei alese, acestea fiind selectate din
literatură de specialitate, preponderent din cea internaţională.
Capitolul doi vă conţine detalii despre firma studiată (performanţele acesteia,
produsele comercializate, servicii, date interne, activitatea de marketing, organigrama, etc.) şi
detalii din mediul în care această activează (furnizori, clienţi, concurenţa, etc.).
În capitolul trei se vor regăsi punctele care recomandă această firmă, oportunităţile ce
o pot propulsa, dar şi aspecte ce necesită atenţie şi eventual intervenţii din partea salariaţilor
în vederea transformării acestor punctelor slabe sau ameninţări, eventual, tot în beneficii.
În capitolul patru, proiectul se axează pe orientarea către client, un domeniu de studiu
foarte important în era actuală a comerţului, având în vedere că existenţa în viitor a firmei
depinde în cea mai mare măsură de clienţii ce vor reveni sau vor aduce după sine alţi clienţi.
De asemenea, în acest ultim capitol, se vor regăsi tehnicile folosite de firma studiată, în
vederea întăririi relaţiilor cu clienţii, metode ce indică axarea firmei pe grijă acordată celui
mai important pilon din desfăşurarea activităţii comerciale, şi anume cumpărătorul.
În cele din urmă, în cadrul acestui proiect de licenţă, vor fi prezentate concluziile şi
propunerile referitoare la această lucrare, în vederea îmbunatăţirii activităţilor acestei firme,
desigur, acolo unde este cazul.

Motto:
 "Orice afacere trebuie privită din punctul de vedere al rezultatului final, adică prin
prisma CLIENTULUI. Succesul unei afaceri nu este determinat de firma, ci de CLIENT."
PETER DRUCKER

CAPITOLUL I. NOTIUNI GENERALE PRIVIND SERVICIILE WEB

1.1.Apariţia şi dezvoltarea serviciilor Web

Prin natura activităţii societăţilor comerciale denumite după noile reglemetari apărute
în Noul Cod Civil doar societăţi, devine necesară orientarea acestora în primul rând spre
menţinerea clienţilor existenţi, obiectiv realizabil prin îndeplinirea cerinţelor de satisfacere a
clienţilor şi doar ulterior, spre atragerea altora noi. Această condiţie s-a impus ca urmare a
constatărilor referitoare la nivelul mult mai ridicat al costurilor de atragere a noilor clienţi în
comparaţie cu cele ale menţinerii clienţilor existenţi. De aceea, în orice societate comercială
menţinerea fondului de clienţi devine o parte crucială a strategiei de marketing. Prin urmare,
tendinţa instituţiilor financiare este de orientare spre serviciile de relaţie (sau serviciile cu
caracter continuu - presupun o relaţie de durată cu societatea financiară prestatoare, de
exemplu contul curent) în detrimentul serviciilor singulare (sau serviciile „o singură dată” –
nu presupun în mod obligatoriu o continuitate în timp a relaţiilor clientului cu banca, de
exemplu schimbul valutar).
Ca rezultat a necesităţii consolidării relaţiei cu clienţii, devine din ce în ce mai evident,
faptul că fiecare are rolul său de jucat, iar calitatea serviciilor prestate trebuie să fie la cel mai
înalt standard pentru asigurarea continuităţii relaţiilor1.
În afacerile actuale o tendinţă majoră o constituie orientarea firmelor spre client.
Orientarea spre client înseamnă că tot ceea ce face un manager trebuie să se întemeieze pe
grijă de a-i îndeplini acestuia toate exigenţele, indiferent dacă este un client intern sau extern,
indiferent dacă este vorba de sectorul public sau de o organizaţie non profit. Acest lucru ar
trebui să însemne că în tot ceea ce se face -stabilirea priorităţilor, elaborarea deciziilor,
participarea la întâlniri sau discuţii cu conducerea - să se aibă în vedere solicitările şi
pretenţiile clienţilor2.

1
Vorzsak Almos , “Marketing serviciilor”, Editura Presa Universitara Clujeana, Cluj-Napoca, 2004, p 74
2
A. Olaru , “Managementul afacerilor”, Ed. Academica, Galati, 2003, p 24
 Industriile din sectorul privat, care aveau contact imediat cu clienţii care plăteau,
ca, de exemplu, cele din sectorul comercial, hotelier, transport, divertisment, au fost primele
care au realizat cât de important este să ai un serviciu eficient de relaţii cu clienţii. Astăzi, în
multe ţări, în majoritatea domeniilor din sectorul public există programe de deservire a
clienţilor şi personal instruit în acest scop. Organizaţiile publice au datoria de a-şi îmbunătăţi
performanţele în ceea ce priveşte serviciul
De relaţii cu clienţii. Ideea că cetăţenii sunt clienţi care trebuie atent serviţi, se regăseşte în
toate reformele sectorului public contemporane. Clientul stă la baza modernizării
managementului în Sectorul Public. În Occident, a existat o cerere mare din partea publicului
de a avea Instituţii Publice de încredere şi uşor accesibile. Furnizorii de servicii din domeniul
public sunt obligaţi să satisfacă nevoile şi aşteptările clienţilor, care – la rândul lor – pot
exercita aceeaşi influenţă ca şi angajaţii într-o societate comercială.
TCP/IP-ul a fost la inceput, acesta a avut o evoluţie spectaculoasa: a apărut în primele
reţele din anii ’70 şi până în zilele noastre a reuşit să cucerească toată planeta. Suita de
protocoale TCP/IP a evoluat, mereu s-au adus îmbunătăţiri la el fără să i se întrerupă prezenţa
în reţele şi, poate mai important, fără să i se blocheze evoluţia. Încă de la început, TCP/IP-ul a
fost şi a rămas protocol deschis, guvernat de organizaţii de standardizare independente ca
IETF sau W3C. Oricine putea să aducă îmbunătăţiri. Bineînţeles că aceste organizaţii se
ocupă de multe alte standarde fără de care internetul de azi nu ar mai fi la fel. Există unele
lucruri însă, fără de care internetul nu ar exista. TCP/IP-ul este unul din ele.3
Era nevoie ca toţi să urmeze modelul standardelor deschise. Fiindcă TCP/IP-ul a fost
al nimănui şi a avut succes tocmai prin caracterul deschis, trebuia găsit ceva asemănător (la
nivelul aplicaţiilor) care să fie tot al nimănui şi să fie bazat pe standarde. Acel ceva este
reprezentat de serviciile web. Dacă lumea IT reuşeşte să impună serviciile web bazate pe
standarde, s-a rezolvat problema, fiindcă furnizorii de produse software vor îmbrăţişa ideea de
servicii web realizând produse care ştiu să comunice astfel cu orice alt produs indiferent de
platforma pe care rulează, indiferent de cine le-a creat şi indif+erent cu ce tehnologie le-a
construit. Problema nu este atât de simplă, însă ideea este extraordinară şi realizabilă. În
ultimii ani s-au definitivat zeci de standarde în acest domeniu şi suntem în faza în care putem
spune că serviciile web vor avea succes cel puţin la fel ca bătrânul TCP/IP. Mai mult, pentru
accelerarea standardizării şi pentru oferirea unei garanţii că prin serviciile web se va asigura

3
Patriciu Victor-Valeriu, Pietroşanu-Ene Monica, Bica Ion, Cristea Costel – “Securitatea informatică în UNIX şi
INTERNET”, Ed.Tehnică, Bucureşti, 1998
interoperabilitatea mult dorită, s-a creat şi WS-I, un organism care furnizează documente
mature pentru W3C şi IETF.
Dezvoltatorii de software au fost mulţumiţi o vreme, până când nu a mai fost de ajuns
să construiască aplicaţii care să aibă drept consumator omul. Era nevoie ca aplicaţiile să
comunice între ele. Aici s-a produs ruptura. Între marile companii furnizoare de tehnologie nu
a mai fost acelaşi consens la problemele de comunicaţie între aplicaţii cum a fost odinioară la
problemele de comunicaţie între calculatoare. Au fost câteva încercări dintre care s-au detaşat
DCOM (Distributed Component Object Model) de la Microsoft, RMI (Remote Method
Invocation) de la Sun şi CORBA (Common Object Request Broker Architecture) de la OMG
(Object Management Group). Necazul e că nici una din cele trei tehnologii nu a fost adoptată
de toată lumea.
Lumea IT a ajuns la consens în ceea ce priveşte caracteristicile acelui ceva care va
rezolva comunicaţia între aplicaţii. Acel ceva trebuie să fie:
independent de maşină (PC-uri, maşini mari sau dispozitive mobile), de sistemul de
operare, de limbajul de programare, de baza de date sau de arhitectură,
modular,
să suporte comunicaţie între aplicaţii slab cuplate (cu gândul la internet),
utilizabile în orice domeniu, de la soluţii simple P2P (Peer to Peer) la sisteme EAI
(Enterprise Application Integration) şi până la sisteme B2B (Business to Business) de
anvergură.
Toate soluţiile de până acum (DCOM, RMI sau CORBA) au probleme majore cu cel
puţin două dintre cerinţele de mai sus. Trebuie să amintim aici şi o soluţie mai exotică numită
EDI (Electronic Data Interchange), care părea să rezolve problema.
Ca să putem înţelege de ce în mintea specialiştilor în IT a apărut concepţia de web-
service, prin ce ea diferă de celelalte încercări de a crea tehnologii de dezvoltare a sistemelor
informatice şi, cel mai important, de ce e atât de bună, cum spun experţii companiilor-vendori
şi analiştii sectorului IT, e necesar să ne intoarcem cu câţiva ani în trecut şi să privim cum se
dezvoltau tehnologiile creării sistemelor informatice, ce a fost creat si ce probleme au apărut.
Cum se întîmpla de obicei, în totul sunt “vinovaţi” banii. 4Când reţelele de calculatoare au
ieşit din cadrul organizaţiilor strict militare si ştiinţifice(cum ar fi ARPAnet), ele au ajuns in
mâna particularilor. În momentul în care numărul utilizatorilor a crescut a apărut ideea că
reţelele de calculatoare pot fi folosite în afaceri. Astfel, reţelele de calculatoare de uz comun,

4
Patriciu Victor-Valeriu, Pietroşanu-Ene Monica, Bica Ion, Cristea Costel – “Securitatea informatică în UNIX şi
INTERNET”, Ed.Tehnică, Bucureşti, 1998
principala şi cea mai răspândită din care astăzi se numeşte Internet, au ajuns business-
instrument. Dar ca să conduci un business cu un astfel de instrument, el trebuie să corespundă
unui set de cerinţe, cele mai importante dintre care sunt – securitatea şi viteza de transfer a
informaţiei. Problema rezolvării acestor cerinţe au început să o rezolve la nivelul cel mai de
jos – nivelul protocoalelor de transport. Diferite companii au propus diferite realizări a
protocoalelor de reţea. Protocoalele de reţea, dupa cum se ştie, conţin regulile de formare a
pachetelor si schimbul dintre ele. Aplicaţiile ce folosesc aceste reguli (diferite pentru diferite
protocoale) sunt strîns legate de aceste protocoale. Între timp relaţiile B2B (Business–to–
Business) cereau ca aplicaţiile de reţea ce foloseau protocoale diferite să poata comunica între
ele – în asa fel a aparut problema integrării aplicaţiilor.
Pe parcursul câtorva ani au fost elaborate câteva tehnologii de interacţionare între
aplicaţii care permiteau, intr-un fel sau altul, realizarea schimbului de date intre aplicaţii (cele
mai răspândite dintre care – Remote Procedure Calls (RPC), Distributed COM (DCOM),
Remote Method Invocation (RMI) si Common Object Request Broker Architecture
(CORBA)), însa fiecare dintre ele a fost destul de greu realizabilă, nu dispunea de
universalitate necesară (De exemplu: Toti utilizatorii trebuiau sa aibă acelaşi sistem de
operare) si, cel mai rau, aceste tehnologii erau greu compatibile intre ele. Aceasta situatie nu
putea sa mulţumeasca nici business-ul, nici pe specialiştii IT.
Atunci s-a apelat la web-tehnologii de bază, s-a încercat gasirea acelui puţin, ce se afla
la baza Internetului. Dar această bază e constituită din urmatoarele tehnologii:
TCP/IP – protocolul universal, acceptat de către toate dispozitivele de reţea, de la
mainframe-uri la telefoane mobile si PDA;
HTML – limbaj universal, folosit pentru redarea informaţiei cu dispozitivele
utilizatorilor;
XML – limbaj universal pentru lucrul cu orice tip de date.
În fiecare definiţie e conştient subliniată universalitatea fiecărei din tehnologii, pentru
că această universalitate este baza inţelegerii serviciilor web. Ele sunt bazate numai pe
tehnologii larg acceptate, deschise şi formal independente de vendori. Doar prin intermediul
acesta se ajunge la principalul avantaj al serviciilor web – universalitatea lor, adică
independenţa de sisteme de operare, limbaje de programare, servere de aplicaţii, etc. Astfel,
serviciile web rezolvă problema iniţială – problema integrării aplicaţiilor de natură diferită şi
construirea sistemelor informaţionale distribuite.5 Aceasta şi este diferenţa de bază dintre

5
Patriciu Victor-Valeriu, Pietroşanu-Ene Monica, Bica Ion, Cristea Costel – “Securitatea informatică în UNIX şi
INTERNET”, Ed.Tehnică, Bucureşti, 1998
serviciile web şi predecesorii săi. Cu ajutorul serviciilor web câteva, uneori total diferite,
business-procese se pot integra într-un singur business-proces.
Şi totuşi web-services nu pot fi privite ca leac de toate business-probleme. Serviciile
web, ca şi multe altele, au plusurile si minusurile lor şi, prin urmare, domeniile de aplicare.
Necunoaşterea şi neconformarea în aceste domenii în proiecte reale poate duce la urmări
destul de grave.
Plusurile web-service sunt:
Web-services permit companiei integrarea propriilor business-procese cu business-
procese ale business-partenerilor si clienţilor săi cu costuri mult mai mici, decât cu alte
tehnologii. Costurile unor asemenea soluţii este accesibilă si IMM-urilor, ceea ce va deschide
companiei noi orizonturi;
Întrucât serviciile web se organizează în regiştri publici (UDDI, ebXML), accesibili
persoanelor interesate din toată lumea, pragul ieşirii companiei pe pieţe noi se micşoreaza,
posibilitatile cresterii bazei de clienţi însa, cresc.
Serviciile web asigură compatibilitatea in relaţia cu sisteme informationale deja
existente în companie. Astfel, se păstrează investiţiile făcute anterior şi nu sunt necesare
schimbări radicale.
Construirea soluţiilor noi cu aplicarea serviciilor web se realizează mai rapid şi mai
puţin costisitor.6
Neajunsurile serviciilor web:
Standardele de integrare a aplicaţiilor, crearea politicilor IT si business ce pot
interacţiona prin intermediul serviciilor web se află încă în stadiul de continuă dezvoltare şi
elaborare. Mai multe companii lucrează în paralel asupra serviciilor web (Web Services Flow
Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS)) de la
IBM, XLANG de la Microsoft şi specificaţiile WS-Coordination şi WS-Transaction –
rezultatul colaborării IBM, Microsoft şi BEA). Evident, fără formularea strictă a lor
construirea sistemelor informatice pe baza tehnologiei web-service poate merge doar cu
succes intermitent.
Folosirea dinamică a informaţiilor din regiştrii serviciilor web, apelul serviciilor
concomitent cere rezolvarea problemelor relaţiei de încredere între diferiţi regiştri. În plus,
sunt probleme în utilizarea concomitentă a regiştrilor de formate diferite.

6
Patriciu Victor-Valeriu, Pietroşanu-Ene Monica, Bica Ion, Cristea Costel – “Securitatea informatică în UNIX şi
INTERNET”, Ed.Tehnică, Bucureşti, 1998
 Specificaţia WS-Security – produsul colaborării IBM şi Microsoft – este destul de
“tânără” şi este mereu înnoită. Se pregătesc deja specificaţiile destinate securităţii serviciilor
Web: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy
Framework, Web Services Trust, Web Services Secure Conversation, Web Services
Federation.
Analizând cele relatate mai sus, se poate observa că plusurile sunt de domeniul
strategic, pe când minusurile au caracter tehnic, datorită noutăţii tehnologiilor serviciilor Web.
Rezolvarea acestor probleme este doar problema de timp.

1.2 Serviciile Web

Definiţia dată de organizaţia W3C este: un web-service este un sistem software
identificat de URI [RFC 2396], a cărui interfeţe publice şi legăturile sunt definite şi descrise
folosind XML. Definirea să poată fi gasită şi de alte sisteme software. Aceste sisteme pot
ulterior interacţiona cu web-service în acord cu definirea sa, folosind mesaje bazate pe XML
transmise cu ajutorul protocoalelor Internet.7
Definition: A Web service is a software system identified by a URI [RFC 2396], whose
public interfaces and bindings are defined and described using XML. Its definition can be
discovered by other software systems. These systems may then interact with the Web service
in a manner prescribed by its definition, using XML based messages conveyed by Internet
protocols.
Din definiţia de mai sus, observăm că unica tehnologie ce este folosită cu stricteţe este
XML. Nu se aminteşte nici de protocolul de reţea folosit, nici de limbajul de programare, nici
de platforma pe care se realizează. Unica condiţie – folosirea mesajelor XML (mai precis
SOAP), întrucât alternativă reală pentru XML, ca limbaj ce permite lucrul cu orice tip de date,
în ziua de azi nu există.
Web Services este o tehnologie .NET folosită pentru crearea de componente
programabile. Multe aplicaţii folosesc tehnologii de componente distribuite, cum ar fi
Distributed Component Object Model (DCOM) şi Remote Procedure Call (RPC). O problemă
comună a acestor tehnologii este dependenţa de platformă. Web Services foloseşte tehnologii
de Internet standard, cum ar fi HTTP şi XML. Independenţa de platformă creează posibilitatea
şi pentru sistemele eterogene de a folosi aceste aplicaţii. Utilizatorii nu mai trebuie să ştie în

7
Patriciu Victor-Valeriu, Pietroşanu-Ene Monica, Bica Ion, Cristea Costel – “Securitatea informatică în UNIX şi
INTERNET”, Ed.Tehnică, Bucureşti, 1998
ce limbaj a fost creată o aplicaţie sau un serviciu. Nu mai trebuie să ştie decât care sunt
facilităţile pe care le oferă şi cum le pot utiliza în propriile lor aplicaţii.
Serviciile Web prezintă un uriaş potenţial de utilizare într-o mare varietate de aplicaţii
folosite în Internet, cum ar fi cele pentru serviciile meteorologice, pentru ştiri bursiere, pentru
serviciile de ştiri, pentru serviciile de urmărire a pachetelor şi pentru serviciile asociate. De
exemplu, o firmă care vinde cărţi prin Internet, cum este Amazon.com, ar putea să includă o
facilitate pentru urmărirea pachetelor folosind o componentă Web Service de la o firmă de
distribuţie prin poştă, ca UPS. O agenţie de ştiri prin Internet ar putea oferi o componentă
Web Service tuturor siturilor de Web care le publică ştirile.
Web Services foloseşte tehnologiile de Internet obişnuite, ca HTTP şi XML, pentru a
realiza comunicarea între furnizor şi consumator. În acest caz, furnizorul este cel care creează
componenta Web Service şi o distribuie prin serverul său pentru a putea fi folosită în aplicaţii
de către consumatori.
De asemenea, Web Services foloseşte un nou protocol redus numit SOAP (Simple
Object Access Protocol). A fost nevoie de un nou protocol fiindcă o mare parte din
tehnologiile de componente distribuite existente în prezent sunt legate de un sistem de
operare, obligându-ne să rescriem obiecte pentru diferiţi clienţi. Problema devine mai serioasă
când se distribuie obiecte prin Internet, din cauza problemelor de securitate: majoritatea
aplicaţiilor de Web folosite de firmele comerciale au firewall. Dacă se foloseşte SOAP, care
utilizează protocolul HTTP ca purtătoare, nu mai este necesară deschiderea de noi porturi în
firewall. Comunicarea dintre furnizorul serviciului de Web şi consumator se va face printr-un
mesaj SOAP în format XML. Ca să le permită consumatorilor să folosească un serviciu de
Web în aplicaţiile lor, programatorul serviciului respectiv trebuie să furnizeze informaţii, cum
ar fi metodele definite de serviciul Web, parametrii solicitaţi şi valorile generate de metode.
Limbajul WSDL (Web Service Description Language) este cel care realizează acest
lucru, furnizând informaţii despre serviciul de Web în format XML. WSDL este generat de
ASP.NET
Nota: Pentru a vedea contractul WSDL, scrieţi URL-ul pentru apelarea fişierului .asmx
cu sufixul ?WSDL. De exemplu, dacă veţi crea un fişier myWebService.asmx în
http://localhost/, aţi putea folosi adresa http://localhost/myWebService.asmx?WSDL pentru a
vedea contractul WSDL.
Discovery of Web Services (DISCO) este mecanismul folosit pentru localizarea unui
serviciu din Web. Când se crează în VS.NET serviciul de Web este generat şi un fişier XML
cu extensia .disco.
 Toate serviciile de Web au extensia de fişier .asmx. Scrierea unei componente Web
Service poate dura de la câteva minute la câteva zile, în funcţie de funcţionalitatea oferită.
ASP.NET se ocupă de crearea contractului WSDL şi de mesajul SOAP pentru comunicare.8

1.2.1 Metodele serviciilor Web

Componenta Web Services conţine, de regulă, una sau mai multe funcţii publice sau
private interne. WebMethod este un atribut individualizat aplicat funcţiilor publice pentru a
permite accesul la funcţia respectivă clienţilor de Web de la distanţă. După cum sugerează şi
numele, funcţiile private nu pot fi apelate de clienţii de Web de la distanţă.
Funcţiile publice dintr-un serviciu de Web care nu are atributul WebMethod nu pot fi
apelate de clienţii de Web de la distanţă.
Următorul cod defineşte o metodă numită TestMethod, care are o valoare String ca
intrare şi generează o valoare String ca ieşire.
Public Function <WebMethod()> TestMethod(strInput as String) as_String
‘aici vine codul de implementare’
End Function
Când se aplică atributul WebMethod() unei funcţii publice, pot fi introduse şi
proprietăţi pentru controlul temporizării, a stării sesiunii şi a sectoarelorde cache. Astfel,
prorietăţile care pot fi specificate când se aplică atributul WebMethod() sunt:
BufferResponse: Stabileşte dacă răspunsul este temporizat în memorie înainte de a fi
transmis clientului. Introducerea valorii True pentru această proprietate determinată
temporizarea răspunsului; intruducerea valorii False determină transmiterea răspunsului către
client în momentul generării sale. Valoarea prestabilită este False.
CacheDuratioa: Stabileşte durata (în secunde) de plasare în cache a răspunsului.
Valoarea prestabilită este 0, astfel că răspunsul nu este salvat în cache. Dacă introduceţi o
valoare mai mare de 0, răspunsul va fi salvat pe durata indicată. O solicitare ulterioară în
limita duratei stabilite va genera un răspuns din cache.
Description: Furnizează o instrucţiune descriptivă despre WebMethod pentru
utilizatorii serviciului. această instrucţiune este afişată în dreptul de atribuire WebMethod în
pagina Service Description sau Service Help.

8
Patriciu Victor-Valeriu, Pietroşanu-Ene Monica, Bica Ion, Cristea Costel – “Securitatea informatică în UNIX şi
INTERNET”, Ed.Tehnică, Bucureşti, 1998
 Figura 1.1 Valoarea proprietăţii Description afişată în pagina Service Help.

EnableSession: Stabileşte dacă este activată funcţia pentru starea sesiunii a serviciului
de Web. Introducerea valorii True determină activarea acestei funcţii; introducerea valorii
False o dezactivează. În configuraţia prestabilită, funcţia pentru starea sesiunii este
dezactivată.
MessageName: Numele folosit pentru metoda Web Service în datele transmise şi
primite de la o metodă Web Service. Este util când există două sau mai multe metode cu
aceeaşi denumire.
TransactionOptions: Indică facilităţile pentru tranzacţii ale metodei de Web.
1.2.2 Arhitectura soluţiei. Suita de tehnologii din serviciile Web (XML, SOAP,
WSDL, UDDI ş.a.)
Folosirea Web Services se extinde rapid o dată cu creşterea necesităţilor de
comunicaţie intre aplicaţii. Web Services oferind un standard de comunicare între diverse
aplicaţii software rulând pe platforme diferite. Un Web Service este un sistem software unic
identificat (URI), ale cărui interfeţe publice şi metoda de conectare sunt definite şi descrise
folosind XML. Definirea unui Web Service poate fi descoperită de către alte sisteme software.
Aceste sisteme pot apoi interacţiona cu Web Service-ul respectiv în maniera descrisă de
definire, folosind mesaje XML9.
Datorită cerinţelor crescânde ale clienţilor şi ale partenerilor de afaceri pentru
informaţie în timp real, companiile s-au văzut silite să îşi conecteze sistemele disparate.
Nevoia sistemelor IT de a comunica cu organizaţia din care fac parte a condus la evoluţia

9
Patriciu Victor-Valeriu, Pietroşanu-Ene Monica, Bica Ion, Cristea Costel – “Securitatea informatică în UNIX şi
INTERNET”, Ed.Tehnică, Bucureşti, 1998
Integrării Aplicaţiilor unei Organizaţii (EAI). Această integrare foarte complexă poate fi
realizată într-o manieră dinamică folosind Web Services.
Arhitectura soluţiei
Arhitectura de bază defineşte interacţiunea dintre agenţii software ca un schimb de
mesaje dintre consumatorii de servicii şi producătorii de servicii. Agentii software pot juca 3
roluri: cel de producător de servicii, cel de consumator de servicii, respectiv cel de agenţie de
descoperire de servicii. Prin intemediul agentiei de descoperire, serviciile sunt publicate şi pot
fi găsite de consumatori.
Consumatorii şi producatorii interacţionează folosind unul sau mai multe modele de
schimb de mesaje (Message Exchange Protocol). Componentele care respectă arhitectura de
baza sunt de obicei definite folosind aplicaţii XML, folosesc definiţii XML infoset pentru
structura şi tipul de date ale mesajelor şi folosesc HTTP pentru transport.
Facilităţile oferite de arhitectura extinsă cuprind:
Schimb asincron de mesaje
Ataşare de documente binare
Tranzacţii pe durată lungă
Autentificarea mesajelor
Integritatea mesajelor
Confidenţialitatea mesajelor
Specificarea căilor de urmat pentru mesaje
Gestionarea mesajelor - se permite organizarea mesajelor după anumite criterii.
Crearea de sesiuni de comunicaţie
Web Services pot fi implementate cu diferite formate de împachetare a datelor sau
diverse modele de procesare. Datorită ubicuităţii standardului SOAP, acesta este folosit cu
precădere în Web Services. SOAP este un protocol de schimb de informaţie într-un mediu
descentralizat şi este bazat pe protocolul XML. Deşi poate sa folosească diverse metode de
conectare, cel mai des folosită este HTTP.
Suita de tehnologii
Suita de tehnologii din serviciile web conţine patru membri de categorie grea. Primul
membru este XML iar ceilalţi sunt SOAP, WSDL şi UDDI.
XML
XML este o modalitate de descriere a informaţiei şi a fost creat pentru a avea un limbaj
universal de a descrie orice fel de date în internet. A fost primul pas către serviciile web.
Trebuia imaginat ceva simplu şi uşor de transportat prin internet. Fiindcă prin reţeaua globală
circulă tone de informaţie sub formă de HTML (web-ul nostru cel de toate zilele) a fost firesc
să vină cineva cu ideea: hai să creăm un HTML extensibil, care să fie capabil să descrie orice
informaţie. Când spunem informaţie, nu înseamnă numai pagini web sau documente cum este
acesta ci şi imagini vectoriale, tranzacţii de comerţ electronic, operaţiuni matematice,
metadate ale obiectelor etc. Aşa s-a născut XML, care a devenit în scurt timp standard adoptat
de W3C şi este omniprezent în produsele marilor furnizori IT.
În prezent prima versiune de XML este standard şi sunt definitivate specificaţiile (sep.
2002) pentru XML versiunea 1.1 (Candidate Recommendation).
Documentele care sunt destinate să devină standarde în internet trebuie să treacă prin 5
faze în cadrul W3C. Documentele pot fi blocate la orice fază:
Notă – faza de idee
Draft – faza de lucru, de dezvoltare
Candidate Recommendation – faza în care se cere deja feedback de la alte grupuri de
lucru sau din afara W3C
Proposed Recommendation – faza în care s-a atins consensul şi se propune
documentul spre aprobare
Recommendation – faza în care W3C îşi asumă responsabilitatea de a ”da liber” pentru
implementare globală. Spunem că aici documentul devine standard de internet. Asta nu
înseamnă că este obligatorie implementarea tehnologiei descrise, însă piaţa IT a demonstrat-o
că recomandările W3C sunt adoptate pe larg de furnizorii de tehnologie IT.
XSD: Spre deosebire de HTML, XML ne permite să creăm elementele noastre aşa
cum vrem noi. Descrierea acestor elemente se face în documente numite XML Shema.
Aceste documente sunt tot XML însă folosesc un limbaj specific numit XSD (XML
Schema Definition) a cărei primă versiune este descrisă de mai multe recomandări W3C.
Xpath: XPath (XML Path Language) este un limbaj de interogare (query) a
documentelor XML. Asa cum limbajul SQL este un limbaj de interogare a bazelor de date
relaţionale, XPath poate şi el să extragă informaţie din documente XML considerându-le
structuri arborescente (elemente în elemente ş.a.m.d.). Aceste structuri arborescente, care
abstractizează documentul XML, se numesc Information Set (pe scurt: Infoset).
În prezent, prima versiune de XPath este recomandare W3C.
XSLT: XSLT (Extensible Stylesheet Language Transformation) este o altă tehnologie
care se bazează pe ideea de abstractizare a documentelor XML prin Infoset-uri şi care se
bazează în mare parte pe XPath. XSLT este un mecanism de transformare a documentelor
XML, de exemplu de la o schema la alta.
 Prima versiune de XSLT este recomandare W3C.
SAX şi DOM: Procesarea (extragerea) informaţiei (datelor) din documente XML se
poate face în mai multe moduri. Una din soluţii este extragerea secvenţială a datelor
traversând structura arborescentă a documentelor XML. Această abordare se numeşte SAX
(Streaming API for XML) şi nu este prezent în nici un document al W3C însă fiindcă este o
metodă performantă de citire a datelor, soluţia este implementată de majoritatea furnizorilor
IT. O a doua soluţie este una prin care aplicaţiile pot ”naviga” înainte şi înapoi în documentele
XML.
Soluţia se numeşte DOM (Document Object Model) şi este recomandare W3C.
Putem vedea deci, că XML aprinde multe beculeţe în minţile arhitecţilor software.
Unul din aceste beculeţe este ebXML (electronic business XML), care este rezultatul unui
proiect al UN/CEFACT în colaborare cu OASIS (Organization for the Advancement of
Structured Information Standards). Proiectul dorea trecerea soluţiilor EDI spre XML, ceea ce
a şi reuşit, ba mai mult, a născut o strategie solidă în domeniul tranzacţiilor B2B însă fără
aplicabilitate în EAI sau P2P. Motivul este rigiditatea sistemului de mesagerie la care dacă
adăugăm scăpările de securitate, vom înţelege de ce marii furnizori de tehnologie IT şi-au
îndreptat atenţia spre o altă tehnologie: serviciile web (XML Web Services).
Serviciile web au fost gândite de la început utilizabile în orice domeniu, să satisfacă
orice cerinţă de mesagerie indiferent de scenariu. Arhitectural au fost gândite să fie modulare,
funcţionale în soluţii slab cuplate şi conforme cu toate specificaţiile standard.
XML pare să schimbe lumea şi o schimbă într-o direcţie bună. Este vremea
consensului. Dorinţa beneficiarilor de soluţii IT de a avea o modalitate comună de
comunicare, a determinat marii furnizori de tehnologie IT (Microsoft, IBM, Oracle, Sun,
BEA, SAP, Siebel etc.) să investească miliarde de dolari în construirea de produse şi soluţii
bazate pe servicii web. Suportul total primit de la furnizorii de platforme, de la telefoane
mobile la PC-uri, servere şi maşini mari (mainframe-uri), conduce la dezvoltarea unei
multitudini de produse ce suportă servicii web. Aceasta înseamnă că din reţeaua virtuală
globală, orice componentă (orice client, orice server, orice aplicaţie) poate trimite sau primi
mesaje de tip XML Web Services.
Un exemplu de reprezentare în XML a descrierii unui serviciu Web care returnează
HelloWorld:
<?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:s0="http://tempuri.org/"
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="http://tempuri.org/" xmlns="http://schemas.xmlsoap.org/wsdl/">
- <types>
- <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">
- <s:element name="HelloWorld">
<s:complexType />
</s:element>
- <s:element name="HelloWorldResponse">
- <s:complexType>
- <s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="HelloWorldResult"
type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
</s:schema>
</types>
- <message name="HelloWorldSoapIn">
<part name="parameters" element="s0:HelloWorld" />
</message>
- <message name="HelloWorldSoapOut">
<part name="parameters" element="s0:HelloWorldResponse" />
</message>
- <portType name="Service1Soap">
- <operation name="HelloWorld">
<input message="s0:HelloWorldSoapIn" />
<output message="s0:HelloWorldSoapOut" />
</operation>
</portType>
- <binding name="Service1Soap" type="s0:Service1Soap">
 <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
- <operation name="HelloWorld">
<soap:operation soapAction="http://tempuri.org/HelloWorld" style="document" />
- <input>
<soap:body use="literal" />
</input>
- <output>
<soap:body use="literal" />
</output>
</operation>
</binding>
- <service name="Service1">
- <port name="Service1Soap" binding="s0:Service1Soap">
<soap:address location="http://localhost/HelloWorld/Service1.asmx" />
</port>
</service>
</definitions>

Există mai multe avantaje ale serviciilor web faţă de alte tehnologii dar cele mai
importante sunt suportul total primit de la industria IT şi flexibilitatea. Pe de altă parte, cei
care sunt familiari cu specificaţiile organizaţiilor de standardizare ştiu că de multe ori se
folosesc cuvinte ca ”ar trebui” sau ”este posibil ca”. Pentru serviciile web, însă, s-a creat o
organizaţie care se luptă pentru înlocuirea acestor expresii cu unele ca ”trebuie” sau ”va
trebui”, ceea ce aduce o puternică reducere a ambiguităţilor din standarde şi duce la evitarea
”interpretărilor” proprietare ale textelor. Această organizaţie este WS-I, care are drept scop ca
implementările diferite ale suitelor de servicii web să fie interoperabile.
SOAP
Iniţial SOAP se descifra ca Simple Object Access Protocol. Dacă, în urmă cu câţiva
ani, întrebaţi pe cineva ce înseamnă SOAP primeaţi un asemenea răspuns: este pentru lucrul
DCOM şi CORBA prin Internet. Primii autori au recunoscut atunci ca ei au focusat asupra
‘accesului la obiecte’, dar cu timpul s-a dorit ca SOAP să asigure mai multe. Astfel, obiectul
specificaţiei s-a deplasat de la obiecte la schimbul cu mesajele XML. Această deplasare a
creat o mică problemă cu litera O in abrevierea SOAP. Echipa de lucru SOAP 1.2 a păstrat
numele SOAP, dar s-a decis să nu se mai descifreze această abreviere, ca să nu inducă în
eroare dezvoltatorii. Astăzi, în definiţia oficială, folosită în ultimele specificaţii SOAP 1.2,
obiectele nici nu sunt pomenite. SOAP (Simple Object Access Protocol) reprezintă un strat
important din suita de tehnologii din serviciile web şi fiindcă de la apariţia sa a avut o evoluţie
fulminantă şi fiindcă în engleză sună haios, multă lume deja ignoră că numele reprezintă
iniţiale şi îi spun simplu: SOAP (săpun).
Dacă XML este o modalitate de descriere a informaţiei prin text simplu (documente
XML), trebuia imaginat un protocol capabil să transporte aceste documente peste Internet.
Acesta este SOAP, care este o tehnologie de comunicare bazată pe un mecanism de
”împachetare” a documentelor XML în plicuri SOAP (envelope – în engleză). Ideea de
împachetare este asemănătoare cu ceea ce se întâmplă cu frame-urile care se împachetează în
pachete IP la nivel de reţea, numai că la SOAP header-ul este – firesc – un text care se adaugă
la începutul documentului XML. SOAP a fost gândit să permită conectivitatea sistemelor
peste web, independent de platforma folosită. El permite ca sisteme diferite să citească, să
înţeleagă şi să ruteze informaţia din mesaje iar pentru transport poate folosi protocoale ca
HTTP, HTTPS sau SMTP.10
Unul din motivele pentru care SOAP a devenit extrem de popular este că e
indepependent de platformă şi astfel permite conectivitate indiferent de sisteme. Folosind
standarde XML, sistemul receptor poate citi, înţelege şi ”consuma” un mesaj SOAP indiferent
de tehnologia care a emis-o. Acest lucru extinde ideea de interoperabilitate în interiorul şi
exteriorul companiilor consumatoare de tehnologie IT. Componentele SOAP Server şi SOAP
Client reprezintă interfeţele către aplicaţiile care cer respectiv oferă informaţie, transformând
comunicaţia specifică platformei în mesaje XML independente de platformă. SOAP permite
expunerea oricăror servicii în interiorul companiei, în exterior pentru eventuali parteneri sau –
de ce nu – în întregul Internet, dacă e nevoie.
În prezent, SOAP este suportat de majoritatea furnizorilor IT şi este menţinut de W3C.
Versiunea 1.2 este descrisă în trei documente care au devenit ”Candidate Recommendation” în
decembrie 2002.
SOAP este format din 3 părţi:
Învelişul SOAP care defineşte ce există în mesaj, cine trebuie să-l primească şi dacă
este opţional sau obligatoriu.

10
http://msdn2.microsoft.com/en-us/library/ms161953.aspx
 Regulile de împachetare SOAP care definesc un mecanism de serializare folosit pentru
transferul de tipuri de date definite de aplicaţii.
Reprezentarea RPC SOAP care defineşte o convenţie folosită pentru executarea de
proceduri la distanţă.
Această noua tehnologie, considerată de majoritatea specialistilor urmatoarea revoluţie
în Internet, permite atingerea unui nou nivel de performanţă în crearea, menţinerea şi
actualizarea conţinutului în Internet.
SOAP creează metodele necesare accesării unui anumit conţinut, fie că este vorba de
un mesaj email, fie de rezultatul unei cautări intr-o bază de date. Printr-o interfaţă unică,
acelaşi conţinut poate fi folosit pe mai multe medii (de exemplu, cursul valutar poate fi afişat
pe o pagină WEB, pe un PDA sau pe un telefon celular compatibil WAP). Implementările
acestui protocol sunt diverse.
SOAP decide metoda transferului mesajelor XML din punctul A în punctul B(ca în
imagine).

Figura 1.2 Schimb simplu de mesaje SOAP

Prima caracteristică esenţială a SOAP este capacitatea sa de a se extinde. Când
abrevierea SOAP mai avea o importanţă, litera ‘S’ insemna ‘Simple”. Dacă ceva a putut fi
invăţat din Web, se datorează faptului ca simplitatea este intotdeauna mai presus decât
eficienţa sau calitatea tehnică, şi când se pune accentul pe capacitatea de interacţionare,
această simplitate este absolut necesară. Simplitatea ramâne una din obiectivele de bază în
dezvoltarea SOAP, fapt ce demonstrează inexistenţa în cadrul SOAP a capacităţilor sistemelor
partajate, precum securitatea, rutarea, siguranţa şi altele. Microsoft, IBM si alti producători de
sisteme operaţionale, coopereaza activ pentru crearea unui pachet comun de extensii SOAP,
care vor adăuga mai multe dintre posibilităţi, cerute de majoritatea dezvoltatorilor. Primul
rezultat este Global XML Web Services Architecture (GXA).
A doua caracteristică importantă a SOAP este: poate fi utilizat în orice protocol de
transport precum TCP, HTTP, SMTP si chiar MSMQ. Totuşi, pentru a susţine posibilitatea de
compatibilitate, e necesar să fie determinată compatibilitatea cu protocoalele standard,
structura cărora este diferită pentru medii diferite. Specificatia SOAP asigură o metodă
flexibilă de determinare a interacţiunilor dintre protocoale şi asigură o legătura evidentă
pentru HTTP, care este astazi utilizat pe larg.
A treia caracteristică este: SOAP este compatibil cu toate modelele de programare si
nu este legat de RPC. SOAP defineşte modelul prelucrării mesajelor separate şi
unidirecţionale. Mai multe mesaje se pot întruni într-un proces de schimb de mesaje. Figura
1.2 ilustrează un mesaj simplu unidirecţional, în care emitentul nu primeşte răspuns. Dar
destinatarul îi poate trimite emitentului răspuns (Figura 1.3).

Figura 1.3 Schema schimbului de mesaje cerere/răspuns

Dezvoltatorii adesea confundă cerere/răspuns cu RPC – acestea sunt două lucruri
diferite. RPC utilizează cerere/răspuns, dar cererea/răspuns nu sunt obligatorii pentru RPC.
RPC este un model de programare, care dă dezvoltatorilor posibilitatea de a lucra cu apelul
metodelor. RPC necesită transformarea signaturii metodei în mesaje SOAP.
Înarmată cu aceste trei caracteristici importante, stratul de schimb de mesaje SOAP
determină schimbul de mesaje XML în medii heterogene, pentru care posibilitatea de a
interacţiona mult timp era o problemă.

Stratul de schimb de mesaje.

SOAP determină modelul prelucrării, care conţine regulile esenţiale de prelucrare a
mesajelor SOAP pe parcursul transportului lor de la SOAP emitent către SOAP destinatar.
Figura 1.2 ilustrează un scenariu simplu de schimb de mesaje SOAP, în care o aplicaţie
(SOAP Sender) trimite un mesaj SOAP către o altă aplicaţie (SOAP Receiver).
Dar modelul prelucrării admite şi arhitecturi mai interesante, asemănătoare cu cea
arătată în figura 1.4, care conţine o mulţime de noduri intermediare.

Figura 1.4 Schimb complex de mesaje SOAP

 Figura 1.5 Forma mesajelor SOAP
Un mesaj SOAP constă într-un plic format dintr-un antet (header) opţional, plus un
corp (body) obligatoriu. Antetul conţine blocuri de informaţii relevante pentru modul cum va
fi procesat mesajul (date despre expeditor, despre destinatar, date de autentificare şi autorizare
a transmisiei etc.). Corpul va conţine mesajul care va fi efectiv trimis şi procesat. Se poate
face analogia cu sistemul de poştă electronică folosit pe Internet, dar aici lucrurile capătă un
aspect obiectual, abstract. Dacă creăm un simplu serviciu Web care returnează textul Hello +
nume şi îl apelăm vom obţine o imagine ca acea de mai jos:

Dând clic pe legătura HelloWorld se poate vedea o descriere detaliată despre cum are
loc invocarea operaţiei implementate. Ca în captura de mai jos:
 SOAP reprezintă un protocol care se comportă ca un “lipici” între componentele
software eterogene, aflate pe maşini diferite. SOAP este definit să utilizeze XML şi HTTP.
SOAP poate fi utilizat să acceseze servicii, obiecte şi servere într-o manieră independentă de
platformă. Principalul său scop este tocmai facilitatea interoperabilităţii.
Ca concluzie se poate observa că: SOAP oferă o manieră independentă de platformă
pentru vehicularea datelor marcate în XML, printr-o manieră orientată-mesaj, peste protocolul
HTTP. SOAP reprezintă deci un summum între HTTP, XML şi RPC, putând fi privit în acest
sens ca o abordare la nivel înalt a paradigmei RPC, mai general decât RMI din Java.
EDI: Succesul EDI a fost mai ales în rândul marilor furnizori de produse de orice fel.
Aceşti furnizori învârteau tone de hârtie pentru a furniza produsele pentru distribuitori.
Trecerea la tranzacţionarea electronică aducea un pas enorm: se înlocuiau tonele de hârtie cu
sistemul ”computerizat” EDI. Totusi, multe din promisiunile EDI nu au fost îndeplinite
deoarece multe din operaţiunile manuale pe documente nu erau eliminate de aplicaţiile
instalate. De multe ori, după concedieri masive, companiile angajau din nou personal pentru a
manipula documentele care ajungeau să fie tipărite din nou şi culmea este că în final costurile
totale cu EDI nu erau semnificativ mai mici decât costurile cu basculantele de hârtie. Pe de
altă parte, lipsa de flexibilitate a eliminat EDI din soluţiile B2B şi P2P.
 DCOM şi RMI: Distributed Component Object Model şi urmaşul său COM+ a căzut
în aceeaşi capcană ca şi Remote Method Invocation pentru că ambele tehnologii foloseau o
abordare strâns cuplată. Ideea era de a conecta sistemele prin API-uri (Application
Programming Interface) cu alte cuvinte de a apela funcţii sau metode de pe alt calculator peste
protocolul RPC (Remote Procedure Call). Acest lucru necesită un efort suplimentar de la
programator fiindcă acesta trebuie să cunoască în detaliu aplicaţia pe care o apelează. Dacă la
unul din capetele comunicaţiei se face o modificare minoră, se compromite întregul sistem.
CORBA: Common Object Request Broker Architecture şi protocolul său IIOP
(Internet Inter-ORB Protocol) au reprezentat prima încercare de rezolvare a problemelor de
interoperabilitate între sisteme distribuite eterogene. CORBA a fost sprijinit de multe
companii IT, chiar şi de comunitatea open-source, însă chiar dacă iniţial părea o soluţie viabilă
a avut o rată de adopţie modestă din mai multe motive. În primul rând era extrem de
complexă şi în al doilea rând proprietarii (OMG) au decis să nu mai rămână independenţi de
limbajul de programare şi au ales EJB (Enterprise Java Beans). Astfel, fiindcă nu a mai reuşit
să se aşeze pe standarde deschise din internet sau măcar să aducă inovaţii acceptate de toţi,
CORBA a fost şi ea condamnată la implementări limitate.11
EDI, DCOM, RMI şi CORBA chiar dacă nu au reuşit să cucerească internetul sau să
obţină acordul unanim al comunităţii IT, reprezintă soluţii extraordinare. Aceste tehnologii vor
trăi încă mulţi ani de acum încolo fiindcă – dacă ne gândim numai la COM+ şi RMI – vom
mai avea nevoie de soluţii strâns cuplate. Ce este mai important e că aceste tehnologii au
reprezentat paşi importanţi către soluţiile actuale bazate pe XML (Extensible Markup
Language). Vom vorbi în continuare de XML şi încă câteva tehnologii strâns legate de acesta
(XSD, XPath, XSLT, SAX şi DOM).
WSDL
Un document WSDL (Web Services Description Language) poate fi considerat
manualul de utilizare pentru serviciile web deoarece este o descriere completă a serviciului
web în cauză. Mai poate fi privit ca un contract prin care serviciul web se angajează să
funcţioneze într-un anumit fel. De fapt este un document XML – deci independent de
platformă – care descrie metodele sau funcţiile (rutinele) utilizabile în aplicaţiile noastre,
descrie locaţia serviciului web, forma datelor pe care le primim de la funcţiile expuse şi alţi
parametri de comunicare.

11
Patriciu Victor-Valeriu, Pietroşanu-Ene Monica, Bica Ion, Cristea Costel – “Securitatea informatică în UNIX şi
INTERNET”, Ed.Tehnică, Bucureşti, 1998
 În prezent WSDL este suportat de majoritatea furnizorilor IT şi este menţinut de W3C.
Versiunea 1.2 este descrisă de mai multe documente „Draft” aflate în lucru la W3C.
UDDI
UDDI (Universal Description, Discovery and Integration) este cel mai exotic dintre cei
patru membri. Dacă putem deja să descriem datele noastre cu XML, să le transportăm cu
SOAP, să construim servicii web cu Visual Studio .NET sau – nu contează cu ce – apoi să
folosim WSDL pentru a descrie aceste servicii web, va trebui să găsim o soluţie pentru a
publica undeva serviciile web, pentru a căuta, pentru a localiza uşor servicii web care ne
interesează. Acesta este UDDI şi am văzut deja că seamănă cu un ”directory” de servicii web.
Acest depozit de servicii web poate fi intern într-o companie sau poate fi public, în internet.
Problema pare să fie simplă însă UDDI se vrea mult mai mult decât atât. De exemplu, să
presupunem că am putea construi o aplicaţie care să consume un anumit serviciu web iar dacă
acel serviciu web cade din diferite motive, aplicaţia noastră să fie capabilă să caute un alt
serviciu web (folosind UDDI) găzduit probabil pe o altă maşină sau chiar altă platformă, să-l
integreze şi să continuie să funcţioneze. Utilizatorul nici nu observă. Pare să fie SF, dar astfel
de soluţii se pot construi deja.
În prezent UDDI este suportat de majoritatea furnizorilor IT şi este în lucru la OASIS.
Pentru a uşura viaţa dezvoltatorilor care lucrează la soluţii în interiorul companiilor,
Microsoft a implementat pe lângă UDDI şi o variantă mai simplă, numită Disco, care nu este
o soluţie standard.
Până acum, serviciile web (XML Web Services) reprezintă unica suită de protocoale
care satisface cele patru cerinţe enumerate. Chiar dacă furnizorii din industria IT – cu câteva
excepţii – trec printr-o perioadă de recesiune, au făcut totuşi investiţii de miliarde de dolari în
dezvoltarea de produse care vor furniza suite de servicii web, servere, dispozitive mobile,
aplicaţii şi unelte pentru a dezvolta aceste servicii web sau aplicaţii conectate.
Microsoft împreună cu alţi furnizori de platforme şi experţi în domeniu, continuă să
investească în dezvoltarea de noi specificaţii pentru XML Web Services. În documentele
tehnice ale Microsoft, aceste noi specificaţii se numesc GXA (Global XML Web Services
Architecture). Aceste specificaţii sunt rezultatul colaborării cu alţi furnizori şi pe măsură ce au
fost elaborate, au fost supuse organizaţiilor de standardizare.