Sugarjav Battamir wsdl-soap caracteristicile de baza ale Web Services, wsdl si soap sugarjav Battamir

Sugarjav Battamir WSDL-SOAP

Caracteristicile de baza ale Web Services, WSDL si SOAP

Sugarjav Battamir

Universitatea POLITEHNICA,Bucuresti

Facultatea de Automatica si Calculatoare

Email{sugarjav.battamir}@gmail.com

Abstract

The restructuring of the traditional forms of education reverse the direction of social

movements: it is not the student that goes to the school, but rather the school that

approaches the student. Also, e-Learning offers through the Web are directed mainly

towards elves and students with non-traditional positions and demands. Within this cooperative learning procedure, all projects and project outcomes can be documented

and made publicly accessible, discussions can be summarized, and literature and link

lists, as well as collective search, learning and composition process of the background

materials become available. In today's world of extreme competition on the learning

process, information exchange is the need of the day. Web services represent the

evolution of the website and offer a direct means by which learning processes can interact.

1.Obiectivele acestui raport

Se urmareste sa aduca la cunostiinta cele mai importante aspecte in domeniul Web-Service, cu accent pe WSDL (Web Services Description Languages) si anume furnizarea abstractiilor importante si cele mai fundamentale ale serviciilor Web, interfata expusa catre alte servicii Web prin care acestea sunt conduse la bazele programelor si applicatiilor. Se va continua cu detalii despre SOAP (Simple Object Access Protocol), unde se va expune teoriile cele mai importante privind capacitatiile de comunicare pentru interfatele serviciilor Web prin intermediul internetului si a altor retele.

2.Introducere

Ca si efectul transporturilor feroviare asupra economiei nationale, serviciile Web schimba intr-un mod fundamental regulile comertului online. Acestea conecteaza programe catre alte puncte aflate intr-o alta parte a lumii, transportand eficient si ieftin cantitati mari de date, ceea ce este considerat o metoda de comunicare rapida, mai buna si mai productive in special in domeniul afaceriilor si a consumatoriilor.

Web-ul a inceput prin a asista interactiunea umana prin date textuale si grafice. Oamenii folosesc internetul aproape zilnic ca sa compare preturi, sa cumpere produse, si sa citeasca cele mai noi stiri si articole. Insa acest nivel de interactiune nu este sufficient sa suporte diferite interactiuni ale diferitelor aplicatii, si in special a transferurilor de date in cantitati foarte mari. Este in continuare nevoie de o metoda eficienta care sa permita applicatiilor sa interactioneze direct intre ele, executand automat instruction, care in de altfel puteau fi introduce manual prin intermediul browserului.

Oamenii si companiile fac afaceri prin intermediul internetului ca o metoda de publicare a legaturilor catre aplicatiile si datele lor, cam in acelasi mod prin care publicau linkurile pe paginile de internet. Aplicatiile online trebuie sa fie capabile sa localiseze, acceseze si automat sa interactioneze cu alte aplicatii online. Prin adoptarea in masa a serviciilor Web, aplicatiile in diverse locatii de pe internet pot fi direct integrate si interconectate ca si cum ar fi fost parte dintr-un singur/mare sistem de informative tehnologica.

De asemenea, conceptul de serviciu este familiar oricarei persoane care cumpara online prin intermediul unui web site. O data plasata comanda trebuiesc introduse informatii despre credit card, serviciu autorizat si realizat de obicei de un furnizor din afara. O data ce comanda este depusa, compania e-commerce coordoneaza livrarea comenzii impreuna cu furnizorul serviciului de expeditie. In cazul in care unul dintre servicii nu functioneaza, cum ar fi de exemplu cel legat de credit card, clientul se afla in imposibilitatea de a-si satisface nevoia. Astfel, aplicatiile e-commerce ilustreaza perfect nevoia unei arhitecturi orientate spre serviciu, care sa furnizeze stabilitate unor astfel de tranzactii.

In acelasi spirit, daca privim comportamentul consumatorilor de servicii mobile, acestia au modalitati diferite de a accesa sa spunem serviciile web; browser, PDA, mobil. Ca si tendinta a numarului in crestere de aparate ubiquitous , conectate intre ele, denumite si pervasive computing, a crescut eterogenitatea si capabilitatile clientilor si a numarului de metode de accesare a serviciilor informatice. Ei spera ca serviciile Web sa fie accesate de pe orice aparat, in aceeasi maniera, si totodata spera ca serviciile sa fie „constiente” de mediul curent, respectiv tipul de aparat, preferinte, locatie. In acest context arhitecturile orientate spre serviciu reprezinta o cerinta sine qua non.

3.Bazele serviciilor Web

Ce sunt serviciile web? Acestea sunt aplicatii Extensible Markup Language (XML) specific programelor, obiectelor sau bazelor de date sau functiilor complexe in domeniul afaceriilor. Folosing un document XML in forma unui mesaj, un program trimite o cerere catre serviciile Web prin intermediul retelei si optional primeste un raspuns, specificand interfata catre care acel mesaj a fost trimis, descrie reguli specific continutului mesajului si definirea mecanismelor pentru a publica si descoperi interfatele serviciilor Web.

Nu cu mult timp în urma, la conferintele internationale, marile companii de software calificau aceste Web Services ca fiind "Revolutia Internet". Este o tehnologie care de fapt nu a inventat nimic nou, ci a dat o noua valoare a ceea ce aveam deja, a reusit sa schimbe modul de a concepe si realiza aplicatiile software.

Pentru a construi o aplicatie distribuita, robusta si flexibila, trebuie îndeplinite

anumite cerinte:

• 
  integrarea resurselor software trebuie sa fie slab cuplate, distincte si separate de restul aplicatiei;
  
• 
  intercomunicarea între componente trebuie sa se realizeze cu ajutorul unor protocoale standard Internet;
  
• 
  interfata catre componentele software trebuie sa fie publicata pentru a fi accesibila (interfata si documentatia serviciului). Implementarea cerintelor anterioare este posibila doar într-o arhitectura orientata pe servicii, care contine trei componente de baza:
  
• 
  Furnizorul de Servicii: nod în Internet care printr-o interfata asigura accesul la un se rviciu
  

software care executa un anumit set de operatii;

• 
  Consumatorul de Servicii: nod în retea care se leaga la Furnizorul de Servicii, si foloseste
  

functionalitatea oferita de acesta, construind solutia de afacere ("business solution");

• 
  Broker-ul: nod în Internet unde sunt stocate informatii despre furnizorii de servicii.
  

Clientii se conecteaza pentru a obtine informatiile despre interfetele pe care le expun Furnizorii de Servicii. Comunicatia între cele trei componente se realizeaza cu ajutorul lui HTTP, între ei transferându-se mesaje SOAP (care sunt de fapt mesaje XML formatate conform standarduluiSOAP). Broker-ul foloseste protocolul UDDI (Universal Description, Discovery and Integration) pentru cautarea si actualizarea informatiilor din baza sa de date cu privire la localizarea serviciilor Web înregistrate. Dupa localizarea serviciului Web, acesta este interogat pentru a obtine informatii despre metodele sale, respectiv interfata pe care o expune, informatii organizate sub forma unui document WSDL (Web Services Description Language).

4. Tehnologiile care stau la baza serviciilor Web

În prezent, Web-ul cunoaşte un mare succes în domeniul e-learning, toată

infrastructura în învăţământ cunoscând schimbări radicale. Serviciile Web au apărut ca

o nevoie naturală de extindere a tehnologiei informaţiei şi reprezintă felul în care

programatorii îşi pot face bazele de date disponibile pe Web, deschizâdu-le accesului

mai larg şi legând aceste baze de date de servicii noi, performante.

Serviciile Web reprezintă o modalitate standardizată de distribuţie a aplicaţiilor,

care foloseşte Internetul şi tehnologii fundamentale ce stau la baza acestei reţele. De

asemenea, serviciile Web oferă posibilitatea de interconectare a numeroase aplicaţii

disponibile pe diferite platforme şi în diverse locaţii de pe glob.

Spre deosebire de reţelele extranet tipice, ce necesită interfeţe puternic integrate

între membrii comunicării, scopul serviciilor Web este acela de a oferi o singură

interfaţă comună care să permită calculatoarelor să ruleze programe, să partajeze date

si să acceseze servicii diverse.

Astfel, tehnologiile Web deschid larg poarta spre o nouă era a informaticii dominată

de aplicaţii cu un grad de inteligenţă ridicat, capabile în luarea deciziilor şi în căutarea

informaţiei pe Internet ca suport pentru hotărâri cât mai judicioase.

Bazate pe un limbaj comun – XML (eXtensible Markup Language) şi un protocol

comun de transport –HTTP (HyperText Transfer Protocol), serviciile Web acţionează

ca un intermediar între cele două entităţi ce doresc să comunice între ele. XML

constituie motorul care face posibil transferul datelor prin intermediul Internetului,

constituind totodată fundamentul serviciilor Web.

Conferinţa Naţională de Învăţământ Virtual, ediţia a IV-a, 2006 269

269

Raportat la celelalte mijloace de transfer al datelor, prezintă avantajul simplităţii,

structurării eficiente a informaţiei, precum şi al portabilităţii informaţiei pe orice

platformă sau dispozitiv. XML este de fapt “fratele” limbajului HTML (HyperText

Markup Language), între cele două limbaje existând o serie de asemănări

5. Arhitectura serviciilor Web

Serviciile Web sunt o modalitate standardizată de consorţiul WWW. Indiferent de

tipul platformei de dezvoltare (Microsoft, IBM, HP sau Oracle), serviciile Web se

încadrează în acelaşi set de standarde, reguli care să fie strict respectate de produsele

dedicate acestei arii. Astfel, un serviciu Web trebuie:

• 
  să fie uşor de extins si refolosit în aplicaţii noi. Acest lucru este realizat prin
  

adoptarea programării orientate obiect, cât si prin folosirea modularizării. Un serviciu poate fi văzut ca un modul, un obiect. Clientul nu trebuie să ştie că serverul se află pe altă maşină, ci doar să apeleze o metodă a serviciului ca si când acesta este un obiect ce aparţine propriului program.

• 
  să ofere interoperabilitate indiferent de platformă, sistem de operare si
  

limbaj de programare.

Serviciile Web au următoarele funcţii:

• 
  fac schimb de date între aplicaţii folosind formatul XML;
  
• 
  folosesc un registru (UDDI), un şablon (WSDL) si o interfaţă (SOAP) pentru a
  

permite interacţiunea între aplicaţii;

• 
  folosesc o reţea (Internet) pentru transportul datelor şi al informaţiilor între
  

aplicaţiile bazate pe Internet ( figura):

6.Cum functioneaza XML Web Service?

Clientul ia legatura cu brokerul sau chiar direct cu serviciul web pentru a obtine informatii legate de interfata Web Service. Pentru aceasta foloseste "Discovery document" care poate fi realizat în doua moduri:

• 
  Static Discovery: localizarea unui Web Service este deja cunoscuta, adica URL-ul catre acesta.
  
• 
  Dynamic Discovery: singura informative despre un Web Services este punctul din Internet unde se afla furnizorul de Web Services, URL-ul site-ului. Se genereaza automat o lista cu informatii despre Web Services expuse de catre acel furnizor, servicii accesate prin URL-uri diferite. Dupa ce a fost localizat Web Service, clientul cere o descriere a acestuia, care trebuie sa cuprinda metodele expuse, parametrii lor, precum si ce tip au valorile care se retur neaza în urma executiei. Toate aceste informatii sunt încapsulate într-un WSDL. WSDL este o gramatica XML folosita pentru a descrie un Web Service din punct de vedere al mesajelor pe care le primeste si le emite. Acest fisier activeaza ca un contract între Consumer si Provider. Este echivalent cu rolul unui TLB (Type Library) în DCOM.
  

Cu informatiile continute în WSDL, clientul stie cum sa încapsuleze cererile catre furnizorul de Web Services în pachete SOAP si cum anume sa interpreteze pachetele SOAP venite sub forma de raspuns al cererii efectuate de client.

Urmatorul pas depinde de platforma utilizata pentru implementarea clientului de Web Se rvice.Pe platforma .Net clientul impleme nteaza conexiunea cu un Web Services sub forma unui proxy.

Rolul unui proxy este acela de a împacheta cererile catre Web Services în pachete SOAP si de a despacheta raspunsurile venite de la Web Services sub forma de pachete SOAP, degrevând astfel aplicatia de logica împachetarii si despachetarii. (asemanator conceptului "proxy-stub" din DCOM).

7.WSDL

Limbajul Descrierii Serviciilor Web (Web Services Description Language WSDL) este un limbaj bazat pe XML care furnizeaza un model pentru a descrie Serviciile Web. Versiunea 1.1 nu a fost adoptata de catre World Wide Web Consortium(W3C). Versiunea 2.0, pentru care multe schite au fost lansate, este asteptat sa fie devine o recomandare pentru WSDL.

WSDL este o descriere bazata pe serviciile XML despre cum sa comunici folosind serviciile web. WSDL defineste serviciile ca o colectie de retele sau porturi. Specificatiile WSDL asigura un format XML pentru documente pentru acest scop.

Definitia abstracta de port-uri si mesaje este separata de folosirea concreta sau instanta, ce permite refolosirea acestor definitii. Un port este definit asociind o adresa de retea cu o legatura refolosibila, si o colectie de porturi definesc un serviciu. Mesajele sunt descrieri abstracte a datelor interschimbate, tipurile de porturi sunt colectii abstracte de operatii suportate. Protocolul concret si specificatiile formatelor de date puntru un tip de port particular constituie o legatura refolosibila, unde mesajele si operatiile sunt apoi legate de un protocol concret de retea si format de mesaj. In aceste fel, WSDL descrie interfata publica catre serviciul web.

WSDL este foarte des folosit in combinatie cu SOAP si XML Schema pentru a asigura service web pe Internet. Un program client conectandu-se la un serviciu web poate citi WSDL-ul pentru a determina ce functii sunt disponibile pe server. Orice tipuri speciale de date sunt incluse in fisierul WSDL in forma unei scheme XML. Clientul poate apoi sa foloseasc SOAP pentru a chema una din functiile listate in WSDL.

XLANG este o extensie a WSDL, iar descrierea unui serviciu XLANG este o descriere a unui serviciu WSDL cu un element de extensie ce descrie modul de funcționare a serviciului ca o parte a unui proces de afacere (Business Process Execution Language).

8.SOAP

SOAP este un protocol de mesaje extensibil bazat pe XML ce constituie fundamentul pentru serviciile web. SOAP ofera un mecanism simplu si consistent ce permite unei aplicatii sa trimita un mesaj XML unei alte aplicatii.

SOAP ofera suport pentru comunicatiile tip peer-to-peer. Un mesaj SOAP este o transmisie one-way de la un trasmitator SOAP la un receptor SOAP, orice aplicatie poate participa in acest schimb de mesaje fie ca transmitator fie ca receptor. Mesajele SOAP pot fi combinate sa suporte deverse tipuri de comunicatii de ex: cerere/raspuns (request/response) cerere de raspuns (solicit response) sau notificare (notification)

SOAP contine patru parti:

• 
  SOAP Envelope –furnizeaza un mecanism de identificare a continutului mesajului si de explicitare a modului in care trebuie procesat (tratat) mesajul. SOAP Envelope include un SOAP header si un SOAP body. Body poate contine orice noduri copil este nevoie. Acesta este definit in asa fel incat poate contine orice XML valid si foarte bine format ce a fost calificat si nu poate contine vreo instructiune de procesare sau Document Type Definition (DTD). Daca Envelope contine Header atunci numarul acestuia trebuie limitat la unul singur si trebuie sa apara ca fiind primul nod copil, inaintea Body-ului. La fel, header-ul poate contine XML valid si bine format pe care creatorul mesajului SOAP vrea sa insereze.
  
• 
  SOAP Transport Binding Framework – furnizeaza un mecanism extensibil ce mapeaza SOAP Envelope la protocoalele de transport de nivel inferior.. Specificatia SOAP 1.2 defineste legaturile de transport pentru HTTP si HTTP Extensions Framework. Deasemenea se pot dezvolta legaturi si pentru alte protocoale de transport ca SMTP, JMS sau MQSeries.
  
• 
  SOAP Enconding Rules- toate datele transmise printr-un mesaj SOAP sunt codate utilizand XML, dar nu exista un mecanism implicit de serializare pentru maparea tipurilor de date definite de aplicatie la elementele XML.Datele pot fi transmise literal sau ca valori codate. Utilizatorii pot definii propriul lor mecanism sau pot utiliza mecanismul de serializare definit de regulile de codare SOAP. Aceste reguli specificat in mod detaliat cum tipurile de date ale unei aplicatii basic sunt mapati si encodati intr-un format XML. Stiluri de encoding sunt complet optionale si in foarte multe dintre situatii nu sunt folositare. Anvelopele SOAP sunt create pentru a putea cara orice document XML indifferent cum poate arata corpul mesajuli sau se conformizeaza unui set specific de reguli.
  

În esenţă, acest protocol este bazat pe limbajul XML, având următoarele caracteristici funcţionale:

• 
  controlul transferului de pachete de date între furnizorul de servicii Web si
  

utilizatorul acestora, folosind protocolul HTTP (metode GET sau POST)

pentru transferul pachetelor de date între server si utilizator;

• 
  transferul parametrilor stabiliţi de utilizator si specifici funcţiilor accesibile
  

prin intermediul serviciului Web;

• 
  returnarea rezultatelor rulării funcţiilor pe serverul care furnizează serviciul
  

Web, aceste rezultate fiind în realitate seturi de date care au fost transpuse

în fişiere XML;

• 
  să fie transmis prin cât mai multe căi posibile prin reţea. Acest lucru este
  

necesar deoarece multe companii doresc să folosească doar anumite

protocoale de transport pentru o mai bună securitate. Cea mai bună soluţie

este folosirea protocolului HTTP datorită posibilităţii de a nu fi blocat de

firewall;

8.1 Specificatie

Specificatia SOAP a fost elaborata şi publicaat pe Web la sfârşitul anului 1999. SOAP este un

extinderea specificatiei XML-RPC, definită iniţial de către Dave Winer de UserLand.
Implementari ale XML-RPC anterioare SOAP continuă să fie utilizate, dar SOAP a câştigat o
mai largă acceptare datorita caracteristicilor sale suplimentare şi funcţionalitate.

Iona şi apoi IBM s-au alăturat efortului de la jumătatea anului 2000 şi a contribuit la producerea specificatieiv1.1, care a fost prezentat de către vendorii W3C 11. Aceasta specificatie a devenit fundamentul XML Protocols Working Group al W3C.

Pentru a furniza un basic, aceasta specificatie defineste:

• 
  Inceputul si sfarsitul anvelope ce imbraca documentul XML
  
• 
  Cum sa reprezinte vreun header optional pentru informatii aditionale, incluzand pointeri catre scheme aditionale associate cu document, vizand securitatea, coordonarile de tranzactii s.am.d
  
• 
  Cum sa serializeze tipurile de date, cu suportul specific pentru interactiunile RPC-style
  
• 
  Bind la HTTP pentru a se asigura ca se transporta documentul in mod correct catre destinatia sa si acesta din urma directioneaza mesajul catre un processor SOAP potrivit
  

8.2 Mesaje SOAP

Mesajele SOAP sint codificate in documente XML care este alcatuit dintr-un infasurator (SOAP envelope, obligatoriu), un header (SOAP header, optional) si un body (SOAP body, obligatoriu). Obligatoriu primul element dintr-un mesaj SOAP este envelope- ul (asemanator cu plicul unei scrisori). Ofera informatii despre informatiile codificate in SOAP payload, contine informatii despre sursa mesajului, recipientul mesajului si detalii despre mesaj in sine. De exemplu, header- ul envelope- ului poate specifica exact cum mesajul trebuie sa fie procesat. Asta inseamna ca, inainte ca aplicatia sa proceseze mesajul poate afla informatii despre mesaj, includind daca aplicatia trebuie sa proceseze mesajul sau nu.

Diferit de apeluri RPC standard, unde mesajul trebuie sa fie prelucrat total ca sa aflam daca el trebuie procesat de noi sau numai trimis mai departe, header-ul SOAP poate indica daca mesajul trebuie procesat sau trimis mai departe, fara ca payload-ul sa fie parsat. Corpul mesajului contine numele metodei accesat si parametrii metodei. Exista o asemanare intre SOAP si DCOM, care poate serializa obiecte si sa-l trimita altor aplicatii unde obiectele sint deserializate si prelucrate.

Cand par erori la procesar raspunsul la mesajul SOAP este un element de eroare situate in corpul mesajului, element ce este returnat expeditorului. Mesajul de raspuns poate cara in singur bloc de eroare in corp ( , , ,).

8.2.1 SOAP Request si Response

Request : Documentul SOAP este organizat intr-un nod radacina (envelope), header si body.Sectiunea body contine informatiile specifice metodei. Elementele documentului XML se mapeaza la spatii de nume XML. SOAP-ENV se mapeaza la spatiul de nume http://schemas.xmlsoap.org/soap/envelope , xsi se mapeaza la http://www.w3.org/1999/-XMLSchema-instance , xsd se mapeaza la http://www.w3.org/1999/-XMLSchema . Acestea sunt spatiile de nume standard pentru fiecare documente SOAP.

Numele unei intefetei se refera la spatiul de nume, nsl. Impreuna cu valoarea parametrului, si tipul acesteia este trimis la server. Elementul radacina envelope are un atribut, encodingstyle: http://schemas.xmlsoap.org/soap/encoding/. Aceasta valoarea informeaza serverul de codificarea utilizata pentru serializarea metodei, necesar pentru server ca sa deserializeze metoda cu succes.

Response: Similar cu mesajul request. Elementul body contine valoare returnate de metoda apelata. Formatul documentelor este flexibil, de exemplu stilul de codificare (encodingStyle) nu este fixat, se poate schimba daca partile comunicante se inteleg asupra unui stil comun.

8.3 SOAP intro aplicatie Peer2peer

Intr-o aplicatie peer2peer clientul si serverul SOAP trebuie sa fie aceeasi. Daca folosim SOAP intr-un mediu peer2peer este impractical ca sa folosim un web server complex ca si Apache, este mai util ca sa folosim un server mai mic scris special pentru a procesa mesaje SOAP. O alta problema apare in privinta group management-ului, trebuie implementat un presence server care sa registreze sau deregistereze nodul SOAP in reteua peer2peer.

SOAP
Nodul este responsabil pentru inregistrarea sa in presence service, fiecare nod poate cere lista utilizatorilor inregistrati la serviciu. O problema apare cand un nod pica si ramane inregistrat la presence service, si ceilalti incearca sa se conecteze la el. Asta inseamna ca avem nevoie si de un serviciu de inlaturare a nodurilor neprezente, nodurile trebuie sa poate notifica presence server ca un nod a picat.

Arhitectura prezentata precedent are imbunatatiri vizibile fata de modelul client-server, pentru ca orice nod poate interactiona cu orice alt nod, dar totusi avem notiunea de server care ramane "single point of failure".

9.Beneficiile Serviciilor Web

Beneficiile arhitecturii orientate spre servicii ar fi: costuri reduse de integrare, o mai mare refolosire a activelor, si posibilitatea ca IT-ul sa raspunda mai repede la schimbarile din mediul de afaceri.

Printre avantajele pe care le aduce serviciile Web as putea enumera:

• 
  functionalitatile de baza sunt concentrate in jurul unui serviciu ce ruleaza independent de aplicatie; odata ce acesta este dezvoltat si iesit din faza de testare si debug el reprezinta o resursa disponibila oricarui proiect -> timpul de implementare scade;
  
• 
  orice modificari care duc la imbunatatirea procesului de lucru in cadrul unui serviciu se reflecta imediat in toate aplicatiile ce il folosesc -> upgrade simultan pe toate aplicatiile -> timpul de implementare scade;
  
• 
  situatii cum ar fi cresterea resurselor alocate unei aplicatii sa genereze probleme, nu se vor mai regasi; arhitectura bazata pe servicii este o arhitectura distribuita, toate serviciile pot rula pe acelasi server iar cand situatia o cere fiecare serviciu poate rula pe un server propriu -> adaptabilitate la crestere, scalabilitate;
  
• 
  educarea echipelor de dezvoltatori prin standardizare: atata timp cat toti dezvoltatorii trebuie sa foloseasca aceleasi servicii vor fi mult mai usor de operat schimbari in cadrul echipelor; de asemenea, cu fiecare implementare a unui serviciu intr-o aplicatie, se extinde libraria de exemple ce vor fi folosite ca baza de invatare pentru membrii noi ai echipelor de dezvoltare;
  
• 
  poate sa usureze integrarea diverselor medii care sa gasesc in multe organizatii;
  
• 
  faciliteaza colaborarea si distribuirea de informatii in cadrul intregii organizatii si cu partenerii externi;
  
• 
  permite customizarea si optimizarea proceselor de business, care devin mai transparente, fara modificarea codul sursa;
  
• 
  pastreaza complexitatea unei integrari business-to-business, reducand semnificativ costurile si ridicand tehnologia la nivel de afacere.
  

10.Limitari

Una dintre preocupari o reprezinta si gasirea unei metode de a urmari atat detaliile tehnice asociate cu serviciile, cum ar fi cerintele de translatare si dependentele serviciilor, cat si considerentele functionale, cum ar fi ce procese sunt implicate. De exemplu anumiti registrii nu sunt la fel de buni pentru ambele tipuri de informatii. Solicitantii serviciilor trebuie sa poata gasi registrul in care sa aiba incredere, ceea ce inseamna ca avem de a face cu aspecte legate de incredere, reputatie, si cel mai important pentru registrii, sa inteleaga nevoile solicitantilor. Cheia pentru noile generatii de servicii o reprezinta serviciile compuse, „increderea”, „reputatia” si o intelegere globala bazata pe semantica.

Una din problemele curente in sistemele distribuite la scara larga este reutilizarea si integrarea sistemelor existente pentru a crea noi aplicatii in termeni de eficienta a costului. Aspectele non-funcionale ale serviciilor si conexiunilor ar trebui definite separate de cele functionale(ex. logicile de business) deoarece aplicatii diferite folosesc serviciile si conexiunile in context nonfunctional diferit. Separarea aspectelor functionale de cele nefunctionale creste posibilitatea de reutilizare a serviciilor si conexiunilor. De asemenea stimuleaza evolutia independenta a celor doua aspecte si imbunatateste intelegerea arhitecturilor aplicatiilor.

O alta preocupare a cercetatorilor se gaseste in sfera auto-vindecarii serviciilor. Atributele calculului autonom pot fi implementate ca si servicii Web pentru a depasi problema sistemelor eterogene de calcul. Prin aderarea la triunghiul autonom Web services, serviciile Web autonome pot fi publicate intr-un registru public a serviciilor web. Prin urmare, alte servicii Web sau sisteme wrapped carora le lipsesc comportamentul autonom incorporat, se pot lega sau pot folosi aceste servicii Web autonome, pentru a imprumuta comportamentul autonom. In consecinta serviciile Web vor putea supravietui in diferite conditii de munca, fara a depinde de interventia umana care impiedica realizarea beneficiilor asteptate.

Bibliografie

[1] Jeffrey Hasan with Mauricio Duran – Expert Service-Oriented Architecture In C# 2005, 2nd Edition, Apress,2006

[2] Lisa Bertino, Lorenzo D. Martino, Federica Paci, Anna C. Squicciarini – Security for Web Services and Service-Oriented Architectures, Springer, 2009

[3] Norbert Bieberstein; Robert G. Laird; Dr. Keith Jones; Tilak Mitra – Executing SOA: A Practical Guide for the Service-Oriented Architect, IBM Press, 2008

[4] Michael Stevens – Service-Oriented Architecture Introduction, 2002, http://www.developer.com/tech/article.php/1010451/Service-Oriented-Architecture-Introduction-Part-1.htm

[5] Matt Wright,Antony Reynolds – Oracle SOA Suite Developer's Guide, Packt Publishing, 2009