A. INTRODUCERE
Termenul World Wide Web (abreviat WWW; numit si Web sau
web, care in engleza inseamna 'retea') este un sistem de documente si informatii de tip hipertext legate ele intre ele care pot fi accesate prin reteaua mondiala de Internet. Documentele, care rezideaza in diferite locatii pe diverse calculatoare-server, pot fi regasite cu ajutorul unui URI univoc. Hipertextul este prelucrat cu un ajutorul unui program de navigare in web numit browser care descarca paginile web de pe un server web si le afiseaza pe un terminal.
WWW este numai unul dintre multele servicii si aplicatii informatice disponibile in Internet. Alte servicii sunt de exemplu: afisarea de informatii mai mult sau mai putin statice cu forma de text, imagini si sunete (asa-numitele pagini web), posta electronica e-mail, transferul de fisiere de date si informatii FTP, chat, aplicatii video si video on demand, servicii telefonie si telefonie cu imagine prin Internet de tip VoIP, posturi de radio si televiziune prin Internet, e-commerce, sondari de opinie, raspandirea stirilor prin metode RSS, toate genurile de grafica si muzica, lucru pe un calculator de la distanta prin Internet, grupuri de discutii pe diverse teme, sisteme de jocuri interactive s.a.
Totusi, WWW este cel mai important si mai raspandit serviciu.
Webul a fost inventat in 1989 la Centrul European de Cercetari Nucleare (CERN). Propunerea initiala de creare a unei colectii de documente avand legaturi intre ele a fost facuta de Tim Berners-Lee in martie 1989. Aceasta propunere a aparut in urma problemelor de comunicare pe care le intampinau echipele de cercetatori ce foloseau centrul, chiar si folosind posta electronica.
Primul prototip al acestei colectii (mai intai in format de text simplu) a aparut nu mult inainte de decembrie 1991, cand s-a facut prima lui demonstratie publica.
Studiul a fost continuat prin aparitia primei aplicatii grafice Mosaic, in februarie 1993, realizata de cercetatorul Marc Andreessen de la centrul universitar National Center for Supercomputing Applications (NCSA) din orasul Urbana-Champaign din statul federal Illinois, SUA. Apoi webul a evoluat pana la ceea ce este astazi, un serviciu integrativ si multimedial, avand ca suport fizic Internetul.
Tim Berners-Lee si echipa sa au realizat primele versiuni pentru patru componente cheie necesare serviciului web, si anume:
* protocolul de intercomunicatie HTTP;
* limbajul de descriere a hipertextului HTML;
* serverul de web;
* browserul.
La baza functionarii webului stau 3 standarde, si anume:
* Uniform Resource Identifier (URI), sistem universal de identificare a resurselor din web, folosit pentru a identifica si localiza paginile web;
* HyperText Transfer Protocol (HTTP), stiva de protocoale OSI prin care serverul web si browserul clientului (utilizatorului) comunica intre ele;
* HyperText Markup Language (HTML), standard de definire si prezentare a paginilor web.
Programul de navigare sau browserul cheama pagina folosindu-se de URI si HTTP, o interpreteaza conform formatarii paginii (hipertext) si o prezinta utilizatorului pe un monitor. Unul dintre principiile Web-ului este principiul client/server, browserul fiind aplicatia client iar serverul HTTP (serverul web) fiind aplicatia server. Pentru a putea interpreta si reda informatiile sub forma hipertextului, browserul apeleaza la standardul de limbaj HTML (HyperText Mark-up Language), definit inca de la inceptul dezvoltarii webului.
In perioada 2004-2005 webul a cunoscut un salt calitativ cu
privinta la aplicatiile de mare raspandire pe glob, care e cunoscut sub numele Web 2.0.
B.Ce inseamna Web Services si SOA?
SOA (Service Oriented Architecture - Arhitectura software bazata pe servicii) este un tip de arhitectura software care presupune distribuirea funtionalitatii aplicatiei in unitati mai mici, distincte - numite servicii - care pot fi distribuite intr-o retea si pot fi utilizate impreuna pentru a crea aplicatii destinate afacerilor. Capacitatea mare cu care pot fi reutilizate aceste servicii in aplicatii diferite este o caracteristica a arhitecturilor software bazate pe servicii. Aceste servicii comunica intre ele trimitand informatii de la un serviciu la altul.
SOA este deseori vazuta ca o evolutie a programarii distribuite si a programarii modulare.
SOA este o tehnologie pentru construirea sistemelor informatice pornind de la proceduri reutilizabile si independente de sistem. In utilizarea obisnuita a internetului, utilizatorul transmite prin browserul sau cereri catre un anumit site Web, iar acesta trimite raspunsuri sub forma de pagini HTML. Prin Serviciile Web, o aplicatie porneste o comunicatie inteligenta cu unul sau mai multi furnizori de Servicii Web, pentru a obtine datele necesare unui raspuns catre client.
SOA si serviciile Web
Originile si scopurile Web-ului sunt date de spatiu de comunicare inter-umana prin intermediul partajarii cunostintelor si de posibilitatea exploatarea puterii computationale.
Puntem astel remarca ca interactiunea om -Web se rezolva prin intermediul formularelor Web si ca interactiunea intre masini se desfasoara foarte limitat pe Web, pentru ca apar nevoile Web-ului:
- 242j98c Standardizare
- 242j98c Solutii multi-platforma, slab-conectate, Integrare Internet/Web aplicatiilor, serviciilor serviciilor si si sistemelor
- 242j98c Performanta prin asigurarea scalabilitatii -Servicii atasabile (pluggable ) & inteligente "Software as Service" - App. Service Provider
- 242j98c Securitate Securitate, disponibilitate, mentinere
Nevoia unei arhitecturi pentru dezvoltarea de aplicatii distribuite orientate spre Web.
Software-ul trebuie divizat in servicii care se pot compune, menite a se conecta si orchestra in mod spontan in cadrul proceselor afaceri/tehnice (component-based software).
Aplicatiile standard ("vechi vechi") trebuie trebuie integrate in noua noua arhitectura rezultand protectia investitiilor
Solutia Solutia: "The Web is the computer " si se cere deci se impune crearea unei arhitecturi care.
- 242j98c Sa suporte paradigme de comunicare bazata pe Web intre aplicatii
- 242j98c Sa ofere localizare transparenta a a serviciilor
- 242j98c Sa permita adaugarea , inlocuirea, eliminarea serviciilor in mod dinamic
- 242j98c Sa ascunda dezvoltatorului detaliile de sistem
Ce sunt serviciile Web?
Aplicatii
- 242j98c Utilizate de alte aplicatii (la distanta)
- 242j98c Accesate standardizat via Web
URI, HTTP, XML
Traditional, o aplicatie Web expune o interfata-utilizator
- 242j98c
Cererile erau capt(
- 242j98c Utilizatorii umani trebuie sa sa interpreteze etichetele si cimpurile de dialog
- 242j98c Utilizatorii umani trebuie sa sa interpreteze raspunsul oferit de serviciu
- 242j98c Serviciile Web fac explicite specificatiile implicite!
Caracteristici:
- 242j98c Utilizate la interactiunea intre masini
- 242j98c Dinamicitatea
- 242j98c Lipsa unei cunoasteri a-priori a interactiunii cu alte aplicatii si/sau servicii Web
- 242j98c Sunt independente de sistem, platforma si limbaj de programare
- 242j98c Puncte terminale utilizate pentru procesarea datelor , in maniera publica
- 242j98c Abilitatea de a prelucra orice tip de date
- 242j98c Dezvoltate pe baza platformelor , arhitecturilor si limbajelor curente
- 242j98c Deschise si extensibile
Un utilizator cumpara de pe un
site web, de exemplu Voyage.com si completeaza cu numarul cardului bancar si
codul de validare pentru a plati (web clasic)
Situl Voyage.com va inainta
cererea de plata (numarul cardului, codul de validare) unui site de validare al
cardurilor bancare, de exemplu Thebank.com
Situl Thebank.com va analiza
cererea, acceptand sau refuzand plata si va transmite raspunsul catre aplicatia
sitului Voyage.com. In acest exemplu, Thebank.com furnizeaza un serviciu web
care trebuie sa dea curs unor cereri de plata de pe alte situri.
In final, cumparatorului i se va transmite raspunsul (web clasic)
Mai exact stil arhitectural de dezvoltare de aplicatiei de mai sus vazute ca serviciu ce poate fi invocat de alte aplicatii
O paradigma de programare este cea orientata serviciu. Termenul Service-Oriented Architecture (SOA) este prizat in zilele noastre. In cadrul SOA, conceptul isi pierde rolul primordial in favoarea verbului. Piatra unghiulara in jurul caruia care produce lumea proiectului in acest moment este cerinta de a face ceva, intr-un anumit fel. Aceasta cerinta se manifesta prin specificarea unui contract de imperative, a unei interfete Java de exemplu sau al unui serviciu WSDL. Esentialul in acest caz devine verbul, actiunea, imperativul. Intelegerea, caderea de acord, de asemenea. In spatele acestui verb poate exista sau nu o lume particulara de substantive si concepte, creata in sensul pe care l-am detaliat la primul punct.
In arhitectura bazata pe servicii Web, se utilizeaza urmatoarele roluri:
- 242j98c 242j98c 242j98c furnizor de servicii: software pentru specificarea si descrierea serviciului
- 242j98c 242j98c 242j98c consumator de servicii (solicitant): software care apeleaza un furnizor de servicii pentru a obtine un serviciu. Poate fi aplicatia unui utilizator (de exemplu, un browser) sau un alt serviciu
- 242j98c 242j98c 242j98c registru de servicii - software care gazduieste servicii publicate, care pot fi furnizate la cererea solicitantului. Registrul implementeaza descoperirea de servicii si functii prin care solicitantul poate cere un anumit serviciu
- 242j98c 242j98c 242j98c broker de servicii - un serviciu special, care trimite cererile de servicii catre furnizorii de servicii.
 |
Tehnologii (bazate pe pe XML):
- 242j98c Descrierea unui serviciu (interfata)
WSDL ( Web Service Description Language
- 242j98c Protocol de comunicare via mesaje
SOAP
- 242j98c Descoperirea serviciilor Web
UDDI ( Universal Description, Discovery, and Integration)
Principiile de baza impuse de SOA:
- 242j98c 242j98c 242j98c serviciile trebuie sa partajeze un contract formal
- 242j98c 242j98c 242j98c serviciile trebuie sa fie slab cuplate(loosley coupled)
- 242j98c 242j98c 242j98c serviciile trebuie sa ascunda dezvlotatorului detaliile de implementare
- 242j98c 242j98c 242j98c serviciile trebuie saofere suport pentru compunerea cu alte servicii(composability)
- 242j98c 242j98c 242j98c serviciile trebuie sa poata fi reutilizate
- 242j98c 242j98c 242j98c serviciile trebuie sa se execute intr-un mod autonom
- 242j98c 242j98c 242j98c serviciile nu trebuie sa depinda de starea comunicarii(statelessness)
- 242j98c 242j98c 242j98c serviciile nu trebuie sa depinda de cantitatea de informatie specifica unei activitati ce trebuie retinuta fiind minimala
- 242j98c 242j98c 242j98c serviciile trebuie sa poata fi facil descoperite
Pe piata serviciile web au fost bine acceptate ajungand la o larga utilizare, unul dintre motive fiind cu siguranta standardele deschise spre care s-au orientat principalii furnizori. Pe de alta parte, toti acesti furnizori au propriile preferinte despre cum anume trebuie sa arate un serviciu web si cum anume trebuie acesta sa comunice. Acest lucru si faptul ca in lumea reala sun necesare diferite stiluri de comunicare, au condus la standardele zilelor noastre care accepta diferite modalitati de formatare a mesajelor serviciilor web si diferite moduri de comunicare.
Standardele relevante pentru descrierea si utilizarea serviciilor web sunt Web Services Description Language (WDSL), un limbaj standardizat asemanator schemei XML utilizat la specificarea serviciilor web, si Simple Object Access Protocol (SOAP), care este actualul protocol de comunicatie destinat serviciilor web. Un alt mecanism de apelare a serviciilor web care permite transmisia in format XML a parametrilor si intoarcerea raspunsului este XML-RPC.
COMPONENTE
Arhitectura serviciilor web se compune din tehnologii diferite care permit unui client sa obtina date de la un server, utilizand protocolul SOAP. Un serviciu web ofera o interfata de programare a aplicatiilor (API) web care permite ca doua aplicatii sa comunice folosind XML prin web sau printr-o conexiune de retea. Acest sistem a fost gandit ca un agent intermediar in cazurile de integrare inter-aplicatii. Un serviciu web poate fi dezvoltat in orice limbaj de programare, pe orice platforma, dar mai important este faptul ca poate fi accesat de orice alta aplicatie, indiferent de limbajul in care a fost dezvoltata. SOAP serveste drept entitate care utilizeaza XML pentru a colecta mesajele specifice, serviciul, interfata sau tipul de port si legatura serviciului (legatura contine informatii despre serviciu cum ar fi redirectarea gazdei si punctul de acces).
Tehnologic, cuvantul serviciu descrie o resursa utilizata de o aplicatie, nu de o persoana. Urmand aceasta definitie, un serviciu web este un sistem orientat pe server care functioneaza pe latura server si realizeaza o anumita sarcina atunci cand i se cere acest lucru de o aplicatie. Ca orice serviciu, un serviciu web necesita o interfata API prin care poate fi invocat de alta aplicatie. Asemanator sistemelor de operare in care un serviciu este inregistrat in registry-ul de sistem pentru a putea fi localizat si utilizat, un serviciu web este inregistrat intr-un registry al serviciilor web. Asa cum am mentionat deja, un serviciu web nu depinde de un limbaj sau de o platforma, ci utilizeaza XML pentru a comunica cu alte servicii sau aplicatii si, ca oricare sistem bazat pe web, nu necesita o anumita platforma pe care sa functioneze.
CUM FUNCTIONEZA
Utilizatorul trimite date intr-un formular simplu prin care solicita un servicu web ,iar aplicatia contacteaza furnizorul UDDI pentru a cauta serviciul cerut, destinat realizarii acestei conversii. Apoi, furnizorul UDDI creeaza legatura, care asociaza mesajul serviciului cerut si locatiei acestuia. Furnizorul UDDI returneaza apoi clientului un fisier WSDL pe care aplicatia il trateaza ca mesaj SOAP. Mesajul SOAP este apoi trimis serverului de aplicatie care gazduieste serviciul web destinat executarii conversiei de moneda. Acest lucru este realizat pe baza detaliilor de legatura din fisierul WSDL primit de la UDDI. Folosind instructiunile SOAP, serviciul web poate executa corect conversia in concordanta cu parametri primiti si poate oferi rezultatul entitatii care a emis cererea.
SABLOANE DE COMUNICATIE
In cazul serviciilor web se pot distinge trei moduri principale de comunicatie:
- 242j98c 242j98c 242j98c remote procedure call (apel de procedura la distanta): clientul trimite o cerere SOAP furnizorului de servicii si asteapta un raspuns SOAP (comunicatie sincrona);
- 242j98c 242j98c 242j98c messaging (mesagerie): clientul trimite o cerere SOAP si nu asteapta nici un raspuns SOAP din partea furnizorului de servicii (comunicatie unidirectionala);
- 242j98c 242j98c 242j98c asynchronous callback (apel asincron inapoi al initiatorului): un client apeleaza un serviciu prin una din cele doua metode de mai sus. Ulterior, cele doua entitati isi schimba rolul, in vederea unui apel inapoi al initiatorului. Acest sablon de comunicatie poate fi construit pe oricare din cele doua metode de comunicatie mentionate.
C.HTTP (Hypertext Transfer Protocol)
Este metoda cea mai des utilizata pentru accesarea informatiilor in Internet care sunt pastrate pe servere World Wide Web (WWW). Protocolul HTTP este un protocol de tip text, fiind protocolul 'implicit' al WWW. Adica, daca un URL nu contine partea de protocol, aceasta se considera ca fiind http. HTTP presupune ca pe calculatorul destinatie ruleaza un program care intelege protocolul. Fisierul trimis la destinatie poate fi un document HTML (abreviatie de la HyperText Markup Language), un fisier grafic, de sunet, animatie sau video, de asemenea un program executabil pe server-ul respectiv sau si un editor de text. Dupa clasificarea dupa modelul de referinta OSI, protocolul HTTP este un protocol de nivel aplicatie. Realizarea si evolutia sa este coordonata de catre World Wide Web Consortium (W3C).
Modul de functionare
HTTP ofera o tehnica de comunicare prin care pagini web se pot transmite de la un computer aflat la distanta spre propiul computer. Daca se apeleaza un link sau o adresa de web, atunci se cere calculatorului host sa afiseze o pagina web (index.html sau altele). In prima faza numele (adresa) este convertit de protocolul DNS intr-o adresa IP. Urmeaza transferul prin protocolul TCP pe portul standard 80 al serverului HTTP, ca raspuns la cererea HTTP-GET. Informatii suplimentare ca de ex. indicatii pentru browser, limba dorita s.a. se pot adauga in header-ul (antetul) pachetului HTTP. In urma cererii HTTP-GET urmeaza din partea serverului raspunsul cu datele cerute, ca de ex.: pagini in (X)HTML, cu fisiere atasate ca imagini, fisiere de stil (CSS), scripturi (Javascript), dar pot fi si pagini generate dinamic (SSI, JSP, PHP si ASP.NET). Daca dintr-un anumit motiv informatiile nu pot fi transmise, atunci serverul trimite inapoi un mesaj de eroare. Modul exact de desfasurare a acestei actiuni (cerere si raspuns) este stabilit in specificatiile HTTP.
Transferul argumentelor
Deseori utilizatorul doreste sa transmita informatii speciale la website. Aici HTTP pune la dispozitie doua posibilitati:
Versiuni
In prezent se utilizeaza doua versiuni ale protocolului, HTTP/1.0 si HTTP/1.1. La versiunea HTTP/1.0 se stabileste o noua conexiune TCP inaintea cererii, iar dupa transmiterea raspunsului conexiunea trebuie inchisa. Astfel daca un document HTML cuprinde 10 imagini, vor fi necesare 11 conexiuni TCP, pentru ca pagina sa fie afisata complet (in browser). La versiunea 1.1 se pot emite mai multe cereri si raspunsuri pe aceeasi conexiune TCP. Astfel pentru documentul HTML cu 10 imagini este necesara doar o singura conexiune TCP. Deoarece - datorita algoritmului Slow-Start - viteza conexiunii TCP este la inceput mica, dar acum el e necesar doar o singura data, se scurteaza semnificativ durata totala de incarcare a paginii. La aceasta se adauga si faptul ca versiunea 1.1 poate relua si continua transferuri intrerupte.
La HTTP se pierd informatiile cererilor vechi (deci este un protocol fara retinerea starii). Prin utilizarea de cooki-uri in header, se pot realiza insa aplicatii care pot utiliza informatii de stare (optiunile utilizatorului din sesiunea actuala, cos de cumparaturi s.a.). Chiar si o recunoastere a utilizatorului este astfel posibila. In mod normal se pot citi informatiile transmise care parcurg reteaua pe computere si rutere. Prin HTTPS transferul se poate si cripta.
Versiunea cea mai recenta se poate utiliza in chat-uri prin utilizarea MIME-tip-ului multipart/replace, care reinnoieste complet continutul ferestrei browser-ului. Noua versiune permite pe langa preluarea datelor, si transmiterea lor la server. Cu ajutorul metodei 'PUT' web-designerii pot sa-si publice paginile web pe webserver prin WebDAV, iar prin metoda 'DELETE' ei pot chiar si sterge pagini de pe server.
De asemenea, HTTP/1.1 mai ofera metoda 'TRACE' prin care se poate urmari calea spre webserver, si verifica daca datele au fost corect transferate. Astfel se poate urmari calea prin diferite proxi-uri spre webserver, echivalent cu un traceroute la nivel aplicatie.
Metode
Metodele disponibile sunt :
GET: este cea mai folosita metoda, fiind utilizata atunci cand serverului i se cere o resursa.
HEAD: se comporta exact ca metoda GET, dar serverul returneaza doar antetul resursei, ceea ce permite clientului sa inspecteze antetul resursei, fara a fi nevoit sa obtina si corpul resursei.
PUT: metoda este folosita pentru a depune documente pe server, fiind inversul metodei GET.
POST: a fost proiectata pentru a trimite date de intrare catre server.
DELETE: este opusul metodei PUT.
TRACE: este o metoda folosita de obicei pentru diagnosticare, putand da mai multe informatii despre traseul urmat de legatura HTTP, fiecare server proxy adaugandu-si semnatura in antetul Via.
OPTIONS: este folosita pentru identificarea capacitatilor serverului Web, inainte de a face o cerere.
CONNECT: este o metoda folosita in general de serverele intermediare.
HTTP este un protocol bazat pe mesaje cerere/raspuns folosit pentru a trimite cereri si a primi raspunsurile asociate. Aplicatiile web bazate pe HTTP nu depind de o conexiune continua intre client si server. Asta face ca HTTP sa fie un protocol ideal pentru serviciile web unde conexiunea client si server poate fi intrerupta si reluata oricand. Alt avantaj important al protocolului HTTP este omniprezenta lui in retele(pervasiveness). Tehnologii precum NAT(Network Address Translation) si server proxy asigura mijlocul de acces la Internet folosind HTTP din LAN-uri care altfel ar fi izolate.
D.RPC(Remote Procedure Call)
O solutie care permite o abstractizare de nivel ridicat si este de dorit pentru dezvoltarea aplicatiilor complexe este Remote Procedure Calls (RPC), care permite comunicarea la distanta, utilizand o semantica asemanatoare apelurilor procedurilor locale.
Mecanismul a aparut cu mai bine de doua decenii in lumea UNIX si a fost/este folosit in constructia de aplicatii distribuite pe sisteme eterogene avand la baza tehnologiile inteternet.
Paradigma RPC confera forta modelului client-server si constituie un element de programare mai simpla fata de abordarea clasica oferita de socket-uri.
Stub - este o secventa de cod care ruleaza la client iar serverul face ca apelul procedurii aflate la distanta sa apara ca si cand ar fi o procedura locala. De exemplu, clientul apeleaza o procedura din stub care arata ca o procedura implementata pe server. Stub-ul transmite apoi apelul catre procedura aflata la distanta.
Marshaling - este procesul de transmitere a parametrilor de la un context la altul. In RPC, parametrii functiilor sunt serializati in pachete, in vederea transmisiei in retea.
Interface Definition Language (IDL) - este un limbaj care ofera o modalitate standard de descriere a sintaxei de apel si a tipurilor de date ale procedurilor apelabile la distanta, independent de un limbaj de programare.
RPC reprezinta un salt important in comunicarea la distanta.
Tehnologiile obiectuale distribuite permit obiectelor care ruleaza pe un anumit calculator sa fie accesate de aplicatii sau obiecte aflate pe alte sisteme. La fel ca si in cazul tehnologiei RPC, care face ca apelurile procedurilor distribuite sa apara ca fiind locale, si tehnologiile obiectuale distribuite fac obiectele aflate la distanta sa para locale. Similaritati ale tehnologiilor:
242j98c 242j98c 242j98c 242j98c 242j98c . Se bazeaza pe obiecte care au identitate si care au sau pot avea stare. Usureaza programarea distribuita si realizeaza un model unitar de programare, permitand utilizarea obiectelor aflate la distanta cu aceeasi semantica folosita in cazul obiectelor locale.
242j98c 242j98c 242j98c 242j98c 242j98c . Sunt asociate unui model pe componente. Utilizarea componentelor duce la cresterea flexibilitatii aplicatiilor si la reutilizarea serviciilor.
242j98c 242j98c 242j98c 242j98c 242j98c . Sunt asociate serviciilor de la nivelul corporatiilor care ofera suport pentru tranzactii, verificarea starii obiectelor si gestiune concurenta. Aceste servicii sunt critice intr-un sistem distribuit de mari dimensiuni si greu de implementat, motiv pentru care sunt furnizate ca tehnologii obiectuale distribuite, ca aplicatii server sau componente ale sistemului de operare.
Serviciile web axate pe documente si pe RPC acopera nise diferite. Serviciile web bazate pe stilul Document/Literal aduce o mai mare flexibilitate avand mai multe puncte tari in privinta interoperabilitatii in comparatie cu celelalte stiluri de proiectare. Abordarea RPC/Encoded nu este incurajata pentru proiectarea unui serviciu web mai ales daca principala cerinta a intregului sistem este interoperabilitatea.
Cea mai importanta trasatura a XML-RPC este simplitatea, in timp ce SOAP, cu toate ca ofera mai multe utilitati, pare a fi mai putin natural in utilizare. In timp ce XML-RPC doreste sa realizeze apelurile de proceduri la distanta la un nivel simplu, pastrand un format necomplicat, protocolul SOAP propune facilitati sofisticate si ofera mai multe posibilitati de reprezentare a datelor vehiculate (serializare, deserializare).
Daca este nevoie de tipuri de date complexe definite de utilizator si de posibilitatea ca fiecare mesaj sa defineasca modul cum va fi procesat, atunci SOAP este o solutie mai buna. Dar daca tipurile de date standard si apelurile simple de metode sunt suficiente, atunci XML-RPC face aplicatiile mai rapide, mai usor de depanat si de intretinut.
Indiferent de protocolul utilizat, XML-RPC sau SOAP, avantajul major este acela ca exista posibilitatea realizarii de apeluri de proceduri la distanta folosind direct tehnologiile web, fara necesitatea construirii unor aplicatii sofisticate. In limbajul specialistilor, procedurile care pot fi apelate la distanta se numesc servicii web.
XML-RPC ofera o specificatie si un set de implementari pentru realizarea de apeluri de proceduri la distanta, in spiritul mecanismului RPC. A fost proiectat [entru a fi cat mai simplu, in acelasi timp permitand si transmiterea, procesarea si returnarea unor structuri complexe.
XML - RPC=HTTP+XML+RPC
E.LIMBAJUL XML
Popularitatea sistemului Internet a inceput sa creasca exploziv odata cu aparitia si dezvoltarea World Wide Web. Brusc o mare de informatie era disponibila folosind un browser web si o legatura la Internet. Fara continutul foarte variat insa interesul pentru World Wide Web ar fi fost mult mai redus; acest continut variat a si scos la iveala limitarile HTML.
Numarul mare de editoare HTML(Hypertext Markup Language) si usurinta in folosire a permis multor oameni cu putine cunostinte tehnice sa publice continut pe web. Proliferarea site-urilor web personale cu continut variat este o dovada in plus ca HTML este un limbaj excelent pentru definirea prezentarii datelor. Totusi HTML nu este prea folositor atunci cand vine vorba de descrierea datelor. Odata cu maturizarea webului a devenit evident faptul ca este de dorit separarea prezentarii de continut. Acest lucru a permis unor specialisti cum ar fi artistii grafici sa se concentreze pe prezentare, iar alti specialisti cum sunt programatorii sa se concentreze pe crearea si manipularea datelor de continut.
XML(Extensible Markup Language) a aparut ca un standard web pentru reprezentarea si transmiterea datelor pe Internet. XML este un metalimbaj generic, independent de platforma, de descriere a datelor. World Wide Web Consortium(W3C) a produs standarde pentru mai multe tehnologii legate de XML.
Ce este totusi XML ? O explicatie foarte simplificate este: XML este text structurat. Simplitatea XML este ceea ce il face atat de bun pentru multe scopuri. Textul este suportat de toate platformele de calcul. Deci daca se pot reprezenta datele ca text utilizatorii oricarei alte platforme de calcul pot accesa datele fara conversii specializate dintr-un format in altul.
Documentele XML sunt structurate ierarhic. Acest lucru este important. Un document XML corect scris se numeste bine format(well formed). O explicatie simplificata a termenului de document XML bine format este: un document XML care are un nod radacina, fiecare element are tag de inceput si de sfarsit, si tagurile elementelor trebuie sa fie imbricate corect.
XML DOM
W3C a standardizat o interfata(API) pentru accesul la documente XML numit XML DOM(Document Object Model). API-ul DOM reprezinta un document XML subforma unui arbore. Deoarece un document XML are o structura ierarhica se poate construi un arbore care sa reprezinte intregul document XML. La orice nod se poate ajunge pornind de la radacina si traversand nodurile fiu.
API-ul DOM asigura si alte servicii inafara de traversarea documentelor. Cateva dintre acestea sunt enumerate mai jos:
- 242j98c gasirea elementului radacina intr-un document XML
- 242j98c returnarea unei liste de elemente cu un anumit nume de
- 242j98c returnarea listei de fii a unui anumit nod
- 242j98c returnarea parintelui unui anumit nod
- 242j98c returnarea numelui tagului unui element
- 242j98c returnarea datelor asociate unui element
- 242j98c returnarea listei de atribute a unui element
- 242j98c returnarea numelui unui atribut
- 242j98c returnarea valorii unui atribut
- 242j98c adaugarea, modificarea sau stergerea unui element dintr-un document XML
- 242j98c adaugarea, modificarea sau stergerea unui atribut dintr-un document XML;
- 242j98c copierea unui nod intr-un document XML impreuna cu toti fiii lui.
XPath
DOM este potrivit pentru traversarea si modificarea unui document XML . Totusi dardizata de W3C. liste un anumit tag; rent cu un anumit tag ; umit atribut; 2.2.2.3 XSL - returnarea numelui tagului unui element
- returnarea datelor asociate unui element;
- returnarea listei de atribute a unui element;
- returnarea numelui unui atribut;
- returnarea valorii unui atribut;
- adaugarea, modificarea sau sterg
- adaugarea, modificarea sau stergerea unui atribut dintr-un document XML;
- copierea unui nod intr-un document XML impreuna cu toti fiii lui.
Asa cum se vede din lista anterioara API-ul DOM ofera o functionali
programatorilor.
este greoi cand vine vorba despre gasirea unui element sau atribut oarecare intr-un document XML. Pentru acest lucru s-a creat tehnologia XPath. XPath este alta tehnologie legata de XML care a fost stan
Xpath este un limbaj folosit pentru a scana(query) documente XML in cautarea unei de noduri care se potrivesc cu un set de criterii date. O expresie XPath poate specifica locatia si paternul de cautat. Se pot aplica operatori booleeni, functii de lucru cu stringuri, si operatori aritmetici expresiilor XPath, astfel incat pot rezulta scanari foarte complexe asupra unui document XML. XPath ofera si functii pentru evaluari numerice cum ar fi sume si rotunjiri. Cateva dintre facilitatile oferite de XPath sunt enumerate mai jos:
- gaseste toti copii nodului curent;
- gaseste toti stramosii unui nod cu
- gaseste ultimul fiu al nodului curent al nodului cu
- gaseste al n-lea fiu al nodului curent cu un anumit atribut;
- gaseste primul fiu cu <tag1> sau <tag2>;
- gaseste toate nodurile fiu care nu au un an
- returneaza suma tuturor fiilor de tip numeric;
- returneaza numarul de fii.
XSL
Conform W3C, XSL este sintagma care cuprinde 3 specificatii diferite: XPath, it la transformarea documentelor XML. in 2.2.2.4 XML SCHEMA Asa cum s-a mentionat mai inainte XML este un format bun pentrul transferul de ate in - tele e de XSL Transformations(XSLT) si XSL Formating Objects (XSL FO). XSL-FO este o gramatica bazata pe XML, aplicata unui document XML folosind stylesheet-uri care afecteaza modul de prezentare al documentului.
XSLT este un limbaj bazat pe XML folosit la transformarea documentelor XML. Un stylesheet XSLT aplicat unui document XML transforma documentul XML in alta forma. Se pot folosi stylesheet-uri XSLT pentru a transforma documente XML in alte formate ca: HTML, RTF, PDF, etc. XSLT poate fi folosit si la transformarea din XMLXML. De exemplu, daca un producator creeaza XML intr-un anumit format, dar un partener de afaceri foloseste XML in alt format, un stylesheet XSLT poate fi folosit pentru a transforma documentele dintr-un format in altul. Stylesheet-urile XSLT pot folosi expresii XPath.
XML SCHEMA
Asa cum s-a mentionat mai inainte XML este un format bun pentrul transferul de date intre grupuri de utilizatori. Totusi, daca cei care comunica folosind XML nu cad de acord asupra unui anumit format al mesajelor XML nu se vor putea intelege. Datele dintrun document XML nu ofera informatii despre structura corecta a acelui document. Documentele DTD (Document Type Definition) reprezinta o modalitate de a descrie structura documentelor XML. Un document DTD specifica elementele si atribudintr-un document XML. De asemenea indica pozitia elementelor si numarul de aparitii. DTD-urile sunt modul "traditional" prin care este descrisa structura unui document XML. Daca un document XML are un DTD asociat, un parser XML poate citi DTD-ul si poate determina daca documentul XML este conform cu DTD-ul.
Daca documentul XML este conform cu DTD-ul, atunci documentul XML este valid. Daca documentul este valid atunci cel care l-a primit stie ca datele din el sunt conforme cu structura asteptata.
O limitare a unui document DTD este ca nu da nici o indicatie despre tipurile de date asociate cu elementele si cu atributele dintr-un document XML. De exemplu, daca un document XML are un element cu tagul <IDComanda> este neclar daca acest ID esteun string, numar sau altceva.
XML SCHEMA ofera toate facilitatile asigurate prin DTD, si, in plus, permite definirea tipurilor de date pentru elemente si atribute, specificarea valorilor minime si maxime pentru tipuri numerice, specificarea lungimii maxime pentru stringuri si definirea enumerarilor.
F.WSDL (Web Services Description Language)
Limbajul de Descriere a Serviciilor Web este bazat pe XML si ofera un model de descriere a serviciilor Web. Versiunea cea mai curenta a WSDL este 2.0; versiunea 1.1 nu a fost acceptata de W3C, deoarece pentru fiecare proiect realizat trebuie sa existe o recomandare de la W3C. WSDL 1.2 a fost re-denumit WSDL 2.0 deoarece a adus modificari substantiale fata de WSDL 1.1. Spre deosebire de WSDL 1.1, care accepta ca metode de interogare doar GET si POST, WSDL 2.0 accepta toate metodele de interogare HTTP care exista. Deasemenea WSDL 2.0 ofera un suport mai bun pentru asa-numitele RESTful Web Services (servicii Web REST), mult mai simplu de implementat. Totusi suportul acestei specificatii este inca slab dezvoltat in Software Development Kit (SDK) (engl.: Trusa de dezvoltare a programelor) pentru Serviciul Web, care adesea ofera unelte doar pentru WSDL 1.1.
WSDL defineste serviciile ca o colectie de porturi, sau puncte terminale intr-o retea. Specificarea WSDL ofera un format XML pentru documentele de aceasta categorie. Definirea abstracta a porturilor si mesajelor este separata de instanta, sau de intrebuintarea lor concreta, aceasta permitand reutilizarea acestei definiri. Un port se defineste ca asocierea unei adrese de retea cu o legatura reutilizabila, iar o colectie de porturi defineste un serviciu. Mesajele reprezinta descrierile abstracte ale datelor ce urmeaza a fi interschimbate, in timp ce tipurile de porturi reprezinta colectiile abstracte ale operatiunilor suportate. Protocolul concret si formatul de date al specificatiei pentru un anumit tip de porturi constituie o legatura reutilizabila, unde mesajele si operatiunile coreleaza cu un anumit protocol din retea si cu un format de mesaje. Pe aceasta cale, WSDL descrie interfata publica pentru serviciile web.
WSDL este adesea utilizat in combinatie cu SOAP si XML Schema pentru a oferi servicii Web prin intermediul Internetului. Un program client conectandu-se la un serviciu web poate citi WSDL pentru a determina ce functii sunt permise de acest server. Orice tip de date special folosit si implementat in fisierul WSDL in forma de XML Schema. Deasemenea clientul poate utiliza SOAP pentru ca eventual sa cheme una din functiile continute de 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 functionare a serviciului ca o parte a unui proces de afacere (Business Process Execution Language).
Web Services Description Language (WSDL) este deci o gramatica XML folosita pentru a descrie un serviciu web in termeni de mesaje pe care le accepta si mesaje pe care le genereaza. Cu alte cuvinte un fisier WSDL reprezinta un contract intre un consumator de servicii web(client) si un serviciu web.
Intr-un fisier WSDL sunt oferite definitii abstracte ale tipurilor folosite in operatii si ale documentelor transmise in fiecare operatie. Apoi sunt asociate aceste definitii cu un protocol de retea si sunt grupate in mesaje care definesc un element endpoint.
WSDL poate descrie elemente endpointuri si operatiile lor fara sa specifice formatul mesajelor sau protocoalele de retea de care este legat(bound) elementul endpoint.
Un document WSDL este o lista de definitii. Intr-un document WSDL elementul radacina se numeste definitions. Acest element contine 5 fii imediati folositi pentru a defini un serviciu web. Urmatoarele 5 elemente apar in cadrul elementului definitions, intr-un fisier WSDL in ordinea specificata:
- elementul <types> defineste tipurile de date folosite pentru schimbul de mesaje;
- elementul <message> descrie mesajele folosite in comunicatie;
- elementul <portType> identifica un set de operatii si mesajele atasate fiecareia dintre acestea; este de fapt o interfata a serviciului.
- elementul <binding> specifica detaliile de protocol folosite de operatiile serviciului si descrie cum se traduce continutul abstract al acestor mesaje intr-un format concret;
- elementul <service> grupeaza un set de port-uri corelate.
Elementul <types>
Mai intai sunt definite tipurile de mesaje folosite in schimbul de mesaje. Acest lucru inseamna in principal definirea tipurilor folosind XML Shema Definition Language
Elementul <message>
In afara de definirea tipurilor de date care sunt transmise inainte si inapoi in timpul invocarii unei metode web, trebuie de asemenea definite mesajele de cerere si de raspuns. Deoarece mesajele sunt independente de protocol, se poate folosi un mesaj cu HTTP-GET, HTTP-POST, SOAP, sau orice alt protocol pe care un ofertant de servicii web il suporta. Daca se foloseste SOAP, elementul <message> corespunde incarcaturii utile a unui mesaj SOAP de cerere sau de raspuns. Acesta nu include elementele SOAP <Envelope> si <Fault>. Mesajele pot avea orice nume pentru ca WSDL nu defineste o conventie de denumire pentru mesaje.
Un element <message> contine 0 sau mai multi fii <part>.
Un mesaj de cerere contine toti parametrii in si inout. Un mesaj de raspuns contine toti parametrii out si inout. Fiecare element <part> trebuie sa aiba un nume si un tip de data care se poate potrivi cu tipurile de date care sunt folosite in implementarea serviciului.
Elementul <portType>
Un ofertant de servicii web (un nod din retea care este server web) poate expune mai multe servicii web. Un singur serviciu web poate suporta invocarea metodelor sale folosind o varietate de protocoale. Formatul datelor schimbate intre client si serviciul web poate depinde depinde de protocolul folosit pentru a invoca o metoda. De aceea trebuie sa existe o cale de a asocia operatiile cu endpointurile de unde acestea pot fi accesate. Acest tip de asociere se poate realiza folosind elementul portType.
Elementul <binding>
Dupa definirea portului logic(portType), in continuare se defineste cum poate un consumator al serviciului web sa se lege la portul pe care este disponibila operatia GetAccount. Acest lucru implica asocierea unei operatii cu un protocol si asigurarea oricarei informatii de legatura specifice protocolului. Pentru a face asta se foloseste elementul <binding>.
Elementul <service>
La sfarsitul fisierului WSDL se definesc endpointurile pentru fiecare dintre protocoalele care se pot folosi pentru a accesa un serviciu web. Pentru a defini endpointurile se foloseste elementul <service>.
G.UDDI (Universal Description, Discovery, and Integration)
Este o colectie de specificatii pentru registre distribuite de informatii despre servicii web. Aceste registre pot fi accesate prin web. Specificatiile sunt impartite in mai multe categorii. Dintre aceste categorii doua sunt mai importante pentru un dezvoltator de servicii web: "UDDI programmers API" (API pentru programatorii UDDI) si "UDDI Data Structure Specification" (Specificatia structurilor de date UDDI). Versiunile curente ale acestor specificatii pot fi gasite la https://www.uddi.org.
- 242j98c Sistem de registri bazat pe XML independent de platforma
- 242j98c Facilitarea comunicarii intre serviciile oferite de firme:White Pages,Yellow Pages, Green Pages
- 242j98c Implementeaza conceptul de service broker
- 242j98c Este interogat de mesaje SOAP ce solicita un serviciu Web
- 242j98c Ofera acces catre documentul descriptiv WSDL al serviciului Web
- 242j98c Acceptare redusa
API pentru programatorii UDDI
Aceasta specificatie defineste functiile care aisgura un model de cerere/raspuns pentru a accesa registrele UDDI. Exista 2 tipuri de API definite in aceasta specificatie:
- API-ul publisher pentru producatorii de servicii web care vor sa publice informatii despre acestea intr-un registru UDDI.
- API-ul inquiry care permite citirea informatiei dintr-un registru.
Specificatia API pentru programatorii UDDI defineste aproximativ 40 de mesaje SOAP folosite pentru a cauta si pentru a publica informatie despre serviciile web in registrele UDDI.
Specificatia structurilor de date UDDI
Aceasta specificatie descrie detaliile fiecarei structuri XML asociate cu mesajele definite de API-ul pentru programatorii UDDI.
UDDI faciliteaza tranzactiile online permitand companiilor sa se gaseasca reciproc pe web si sa interactioneze pentru comert electronic, sau sa intreprinda alte activitati ca data mining, activitati colaborative s.a.. UDDI poate fi comparat cu paginile galbele deoarece permite afacerilor sa inregistreze in registre UDDI informatii despre serviciile web pe care le ofera.
Beneficiile utilizarii UDDI
Prin inregistrarea serviciilor web oferite de companii intr-un registru UDDI se permite:
- Listarea si descrierea regulilor prin care partenerii de afaceri pot colabora;
- Marirea vizibilitatii si accesibilitatii companiei in cautarile unor potentiali cumparatori, si pe pietele din intreaga lume;
Informatiile oferite de UDDI
UDDI poate oferi raspunsuri la query-uri astfel:
- ce servicii web ofera o anumita afacere;
- care sunt endpointurile cunoscute pentru un anumit serviciu web;
- care este informatia de legatura (binding) (care sunt protocoalele suportate) pentru un anumit endpoint.
Un sistem orientat pe serviciu trebuie sa aiba un registru care se ocupa de asocierea serviciului corespunzator cererii primite si care functioneaza si ca sistem de regasire a serviciului corect ce trebuie identificat de entitatea care trimite cererea. Mecanismul care realizeaza aceasta sarcina este UDDI Provider (furnizor UDDI - Universal Description Discovery and Integration). UDDI provider gazduieste o inregistrarea standardizata care creeaza profilele serviciilor inregistrate facand posibila asocierea unei anumite cereri cu serviciul corespunzator.
Alte interogari posibile cum ar fi comparatia intre preturile serviciilor web, sau proximitatea geografica nu fac parte din specificatia UDDI. Asemenea query-uri aditionale si metadatele asociate lor sunt considerate servicii in plus(value-added) pe care producatorii de servicii web sunt liberi sa le implementeze si sa le ofere.
H.REST (Representational state transfer)
Este un stil arhitectural pentru sisteme distribuite hipermedia (este folosit ca extensie logica a termenului hipertext, in care elementele grafice, video, textul paln si hperlegaturile intervin pentru a creea un mediu general non-linear de informatii) cum e si World Wide Web.
REST se refera strict la o colectie de principii pentru arhitectura retelei care expun cum sunt definite si cum se face accesarea resurselor. Filozofia REST presupune ca rezultatul unei procesari conduce la returnarea unei reprezentari a unei resurse web. Orice accesare a a unei reprezentari plaseaza aplicatia client intr-o stare care va fi schimbata in urma unui transfer de date (accesarea unei reprezentari, pe baza traverarii unei legaturi hipertext (desemnata de un URI (inclusa in reprezentarea resursei initiale))).
Serviciile web REST incearca sa emuleze HTTP si alte protocoale similare aplicand interfetei constrangeri la un set bine cunoscut de operatii (ex.: GET, PUT, DELETE). In acest caz, accentul cade pe interactiunea cu resursele de stare, decat pe mesaje si operatii.Serviciile web de tip REST pot folosi WSDL pentru a descrie mesaje SOAP peste HTTP, care definesc operatiile. Starea comunicarii intre mesajele vehiculate intre server si client nu trebuie retinuta (stateless).
Transferul de date se realizeaza prin HTTP, reprezentarea este marcata in XML (ori in alt format), iar adresabilitatea ei se rezolva via URI, spatiul Web putand fi considerat un spatiu REST.
Reprezinta vizunea complementarea de implementare si utilizare a serviciilor web (fara SOAP).
Resursele sunt numite folosind URI, iar reprezentarile sunt interconectate prin URI, lasand loc si la intermediari intre client si resurse (proxy, cache, porti) care asigura performanta si o securitate sporita.
Serviciile web actuale se pot dezvolta in concordanta cu arhitectura REST. Componentele care invoca functionalitati vor consuma reprezentari de resurse conform clasicei arhitecturi server - client. Fiecare cerere este considerata independeta, fara a lua in considerare contextul, adica conexiuni stateless. Resursele web pot fi accesate printr-o interfata generica pusa la dispozitie de metodele protocolului HTTP:GET, POST, PUT, DELETE.
O aplicatie proiectata in stilul REST are o arhitectura diferita de una in stil RPC(sau SOAP - modelul a fost preluat de la RPC). In cazul in care orientarea este spre REST focalizarea cade pe diversitatea resurselor disponibile. Fata de SOAP, SOAP este scalabil si uzual deci si mai usor de programat. Arhitectura REST a reusit mai mult decat sa isi demonstreze scalabilitatea. Are si avantajul ca a reusit sa aduge o tenta de ofertant de neutralitatea la SOA. Concurentul sau direct SOAP e prea stufos si prea complicat pentru ceea ce se doreste a fi, are un aspect de granditate si e "umflat fortat" (bloated). REST specifica o serie de constrangeri arhitecturale intentionand sa maresca performanta, scalabilitatea si abstractizarea resurselor inauntru distributiei sistemelor hipermedia.
Prima se refera la uniformizarea interfetei, care, dupa cum zice si numele inseamna ca toate resursele prezinta aceeasi interfata in partea clientului.
A doua constrangere se refera la statelessness, in care serverele nu pastreaza nici o stare in beneficiul clientului, asa ca toate cererile trebuie sa contina informatiile relevante despre orientat-sesiune.
A treia constrangere arhitecturala se refera la caching, ceea ce poate ajuta la imbunatatirea la imbunatatirea performantei si a scalabilitatii. Caching se realizeaza prin permiterea resunsurilor cache a clientilor sau intermediarilor sa fie marcate ca fiind cacheable de catre server. Faptul ca web-ul functioneaza asa de bine este demonstrat de eficienta acestor constrangeri.
Restursele si reprezentarile lor sunt deasemeni parti cheie a protocolului REST. Chiar si numele este bazat pe faptul ca resursele si clientul fac schimb de reprezentarile resurselor ca parte integranta a interactiunii lor. Un exemplu concret este acela in care un browser trimite o cerere HTTP GET la un site web pentru o resursa data. Raspunsul este tipic o reprezentare HTML a starii resursei. Exista si alte reprezentari cum ar fi text sau XML. Resursele sunt numite cu identificatori unici pe care clientul le foloseste pentru a interactiona cu ele; pentru web acesti identificatori sunt URI-urile. Pentru ca REST acceseaza sisteme dirribuite de hypermedia, reprezentarile in mod normal contin identificatori pentru alte resurse, premitand aplicatiilor sa le foloseasca pentru a naciga de-a lungul resurselor inrudite. In termenii HTML-ului astfel de identificatori au hyperlegaturi catre resursele inrudite.
Interfere uniforme si scalabilitate: prounerile SOA referitoare la interfete sunt critice pentru definirea serviciilor: diferte servicii au diferite interfete - o caracteristica normala si dorita ale sistemelor software, fie ele distribuite sau nu. Cei care propun REST sustin constrangerile asupra uniformizarii interfetelor.
I.SOAP (Simple Object Access Protocol)
Este un protocol bazat pe XML, folosit pentru transmiterea informatiei in sisteme distribuite. Cuvantul "simplu" explica intentia creatorilor SOAP. Un mesaj SOAP s-a dorit a fi un document XML bine format, cu alte cuvinte text pur. SOAP a depasit proiectul initial si este considerat mai mult decat un protocol si anume un framework pentru schimbul mesajelor intre clienti si servicii web. Diferenta dintre un protocol si un framework poate fi observata daca ne gandim la protocolul HTTP care a revolutionat schimbul de date intre browsere si serverele web. HTTP este folosit la conectarea a milioane de oameni la web dar nu ofera o platforma pentru schimbul liber de date. SOAP rezolva acesta problema prin folosirea protocoalelor existente(ca HTTP, sau SMTP) pentru a permite mesajelor SOAP sa fie trimise ca parte a mesejelor acestor protocoale.
Majoritatea retelelor au instalate o multitudine de firewall-uri, proxy-uri, si alte elemente de securitate pentru a bloca orice comunicatie inafara de datele HTTP. Din acest motiv, mesajele SOAP sunt trimise ca parte a mesajelor HTTP, intrun proces numit transmiterea SOAP peste HTTP. Se presupune ca aplicatiile care comunica folosind SOAP trebuie sa verifice validitatea textului XML care contine mesajele SOAP. Deoarece pe drumul dintre client si serviciul web pot interveni si alte aplicatii numite intermediari, acestea pot lua decizii de prelucrare folosind informatia continuta in headerul mesajului SOAP. Folosind acest header optional, SOAP este un protocol extensibil.
Structura unui mesaj SOAP
Un mesaj SOAP este alcatuit din 2 sectiuni obligatorii <Envelope> si <Body>, la care se poate adauga o sectiune optionala <Header>.
Fiecare element din mesaj este prefixat de spatiul de nume "soap:" . Acest spatiu de nume este definit in elementul <Envelope> (plic) si se aplica tuturor elementelor continute in spatiul de nume SOAP.
Spatiile de nume au un rol important in SOAP. Acestea sunt folosite pemtru a combate problemele de ambiguitate intre 2 sau mai multe documente XML impiedicand aparitia de elemente si atribute cu nume identice dar cu semnificatii diferite. Acest lucru este realizat prin prefixarea fiecarui element si atribut cu un sir de caractere asa cum este prefixul "soap:" folosit anterior(de exemplu <soap:Body>). Spatiile de nume ele insele sunt URI-uri arbitrare(pot fi si stringuri oarecare) care trebuie specificate cand se defineste o mapare(un alt nume mai scurt) pentru un spatiu de nume.
Elementul SOAP <Envelope>
Elementul <Envelope> este nodul radacina al documentului XML care reprezinta mesajul SOAP. Contine elementele <Header> si <Body> si este obligatoriu.
Elementul SOAP <Header>
Elementul Header este primul element fiu al elementului <Envelope> si este facultativ. Toti fii imediati ai elementului header se numesc inregistrari header sau headere.
Elementul Header asigura o metoda generala de a adauga caracteristici noi unui mesaj SOAP intr-o maniera descentralizata fara o intelegere anterioara intre cei care comunica. Headerele permit extinderea informatiei despre un mesaj. Utilizarile tipice ale inregistrarilor header sunt: autentificare, managementul tranzactiilor etc.
Elementul SOAP <Body>
Daca elementul <Envelope> nu contine elementul <Header> atunci elementul <Body> trebuie sa fie primul fiu imediat al elementului <Envelope>. Daca elementul <Header> este prezent atunci elementul <Body> trebuie sa urmeze imediat dupa acesta. Toti fii imediati ai elementului Body se numesc inregistrari body , si fiecare inregistrare este un element separat in cadrul lui Body.
In contextul serviciilor web elementul body contine date specifice unui anumit apel de metoda, cum ar fi numele metodei, parametrii ei si valorile de retur de dupa apel.
Elementul SOAP <Fault>
Elementul <Fault> este folosit pentru a transporta informatii de eroare si/sau de stare intr-un mesaj SOAP. Daca elementul <Fault> este prezent acesta trebuie sa fie o inregistrare body si poate apare doar odata intr-un elementul Body.
Elementul <Fault> contine urmatorii 4 fii:
- faultcode: acest element este folosit de un consumator al serviciului web pentru a identifica eroarea. El trebuie sa fie prezent intr-un element fault. SOAP defineste un mic set de coduri de eroare(fault codes) care acopera principalele erori SOAP.
- faultstring: acest element este folosit pentru a oferi o explicatie inteligibila pentru un utilizator uman despre eroare. Trebuie sa fie prezent intr-un element fault.
- faultfactor: scopul acestui element este de a oferi informatii despre cauza erorii si indica sursa erorii folosind un URI. Aplicatiile care nu sunt destinatia finala a unui mesaj SOAP trebuie sa includa elementul faultfactor in elementul fault.
- detail: acest element este folosit pentru a stoca informatie specifica aplicatiei despre eroare . Absenta acestui element dintr-un element fault indica faptul ca eroarea nu este legata de procesarea elementului Body.
- 242j98c Format pentru trimiterea de mesaje bazat pe XML
- 242j98c Protocol de comunicare intre aplicatii (via Internet)
- 242j98c Independent de platforma sau limbaj
- 242j98c Simplu si extensibil: envelope, header, body,fault
- 242j98c Permite evitarea firewall-urilor
- 242j98c Standard W3C
Serviciile web sunt servicii bazate pe limbajul XML, trebuind sa satisfaca mai multe cerinte dintre care cele mai generale si importante:
- Interoperabilitate; un serviciu remote trebuie sa poate fi consumat(folosit) de un client de pe alta platforma software si/sau hardware.
- Compatibilitate cu Internetul; tehnologia trebuie sa functioneze bine atunci cand este folosita de clienti care acceseaza un serviciu remote prin Internet.
- Interfete Strong Type(cu tipuri de date bine definite); nu trebuie sa existe ambiguitate in legatura cu tipurile de date trimise si primite de un serviciu remote. Mai mult, tipurile de date definite de serviciul remote trebuie sa se mapeze intr-o maniera rezonabila peste tipurile de date definite de majoritatea limbajelor procedurale.
- Capacitatea de a folosi standardele Internet existente; implementarea unui serviciu remote trebuie sa foloseasca standardele Internet existente intr-o cat mai mare masura, si trebuie evitata reinventarea de solutii la probleme care au fost deja rezolvate. O solutie construita peste standardele Internet adoptate poate folosi produsele si toolset-urile existente pentru aceasta tehnologie.
- Suport pentru orice limbaj; tehnologia trebuie sa nu fie strans cuplata cu un anumit limbaj de programare
- Suport pentru orice infrastructura de componente distribuite; tehnologia nu trebuie sa fie strans cuplata cu o anumita infrastructura de componente
Asadar avem nevie de urmatoarea piramida:
Descoperire: aplicatia client care are nevoie sa acceseze functionalitatea expusa de un serviciu web remote are nevoie de o metoda prin care sa descopere locatia acestuia. Acest lucru este realizat printr-un proces numit in general descoperire.
Descriere: odata ce endpoint-ul (locatia) unui serviciu web a fost descoperit, un client are nevoie de informatie suficienta pentru a interactiona corect cu el. Descrierea unui serviciu web cuprinde metadate structurate despre interfata care va fi consumata(implementata) de o aplicatie client si documentatie scrisa despre serviciul web respectiv, incluzand exemple de folosire a acestuia.
Formatul Mesajelor: pentru a putea comunica, un client si un serviciu(server) trebuie sa foloseasca o metoda comuna de codare si formatare a mesajelor. O metoda standard de codare a datelor asigura ca acestea vor fi corect interpretate de client si de serviciu.
Codare: mesajele transmise intre client si serviciu trebuie sa fie codate intr-un format comun inteles de ambii participanti la comunicatie.
Transport: odata ce un mesaj a fost formatat si codat acesta trebuie transmis intre client si server.
Arhitectura orientata spre servicii Web trebuie sa implementeze trei operatii care definesc contractele dintre rolurile principale (furnizor, solicitant, registru):
- 242j98c publicare: inregistrarea (sau promovarea) serviciului de catre furnizorul serviciului in registrul de servicii
- 242j98c descoperire: operatie complementara operatiei de conectare (binding), deoarece serviciile publicate trebuie regasite. Solicitantul descopera serviciul in registrul servicii conform unor criterii de cautare specificate de solicitant. Criteriile de cautare pot fi, de exemplu, tipul serviciului, caracteristicile furnizorului, caracteristicile de calitate a serviciului etc
- 242j98c conectare: conecteaza furnizorul de servicii cu solicitantul de servicii intr-o relatie de tip clientserver. Aceasta relatie poate fi dinamica (de exemplu, generarea dinamica a proxy-ului solicitantului) sau statica (cand dezvoltatorul poate predefini si codifica modul de asociere a serviciului cu orice solicitant)
Arhitectura standard orientata spre servicii este definita cu ajutorul arhitecturii si tehnologiei bazate pe servicii Web. Arhitectura bazata pe servicii Web are urmatoarele caracteristici:
- 242j98c se bazeaza pe tehnologii XML
- 242j98c este independenta de protocoalele de transport
(HTTP, SMTP)
- 242j98c utilizeaza mesaje XML pentru schimburi intre aplicatii si pentru interactiunea serviciilor. Aceste mesaje permit extinderea si adaptarea la diferite cerinte ca fiabilitate, securitate etc. Schimbul se realizeaza utilizand protocolul SOAP (Service Oriented Architecture Protocol)
- 242j98c permite publicarea capacitatilor functionale, de calitate etc. ale serviciilor, utilizand limbajul de descriere WSDL (Web Services Description Language).
Nivelul cheie (middleware)intr-o arhitectura SOA. Contine:
- 242j98c Servicii de manipulare a mesajelor
ü 242j98c suport pentru diferite tipuri de mesaje
ü 242j98c livrarea mesajelor
ü 242j98c rutarea mesajelor
- 242j98c Servicii de management
ü 242j98c monitoarizarea performantelor
ü 242j98c supraveghere
- 242j98c Servicii de interfata
ü 242j98c ofera suport pentru standarde
ü 242j98c ofera solutii pentru interfetele nestandard
- 242j98c Servicii de mediere
ü 242j98c transformarea mesajelor dintr-un format in altul
- 242j98c Servicii de securitate
ü 242j98c criptare/decriptare
ü 242j98c autentificare
ü 242j98c autorizare
SOAP initial a fost perceput ca Simple Object Access Protocol, iar mai tarziu si ca Service Oriented Architecture Protocol, dar acum este doar SOAP. Acronimul original a fost abandonat cu Versiunea 1.2 a Standardului, care a devenit o Recomandare W3C pe 24 Iunie 2003, cand denumirea a fost considerata ca fiind derutanta.
Aplicatiile din ziua de astazi comunica utilizand "Apelurile de Procedura la Distanta" (RPC - Remote Procedure Calls) dintre obiecte, dar HTTP nu a fost creat pentru acest lucru. RPC reprezinta o problema de compatibilitate si securitate; firewall-urile si serverele proxy blocheaza in mod normal acest tip de trafic.
O cale mai buna de comunicatie intre aplicatii este prin HTTP, deoarece HTTP este suportat de toate browserele si serverele Internet. SOAP a fost creat sa indeplineasca acest aspect.
SOAP furnizeaza o cale de comunicatie intre aplicatii care ruleaza pe diferite sisteme de operare, cu tehnologii si limbaje de programare diferite.
UserLand, Ariba, Commerce One, Compaq,
Developmentor, HP, IBM,
Avantaje:
- 242j98c Utilizand SOAP cu HTTP este permisa comunicatia mai buna in spatele unui proxy sau firewall decat presupunea precedenta tehnologie de apel la distanta.
- 242j98c SOAP este destul de versatil pentru a permite utilizarea protocoalelor de transport diferite. Stiva standard utilizeaza HTTP ca protocol de transport, dar alte protocoale sunt de asemenea utilizabile (TCP, SNMP).
Dezavantaje:
- 242j98c Din cauza lungimii formatului XML, SOAP poate fi destul de lent in comparatie cu tehnologiile middleware, cum este CORBA. Aceasta poate sa nu fie o problema cand se trimit numai mesaje scurte.
- 242j98c Cand ne bazam pe HTTP ca protocol de transport, rolurile partilor care interactioneaza sunt stabilite. Doar o parte (clientul) poate utiliza serviciile altuia. Deci dezvoltatorii trebuie sa utilizeze polling in schimbul notificarii in aceste cazuri comune.
- 242j98c Multe implementari SOAP limiteaza cantitatea de date care poate fi trimisa.
Libraria NuSOAP - solutia pentru serviciilor web SOAP NuSOAP este o colectie de clase PHP care permite utilizatorilor trimiterea si receptionarea de mesaje SOAP folosind protocolul HTTP. NuSOAP, cunoscut si ca SOAPx4, este distribuit de Corporatia NuSphere (https://www.nusphere.com). Aceasta librarie este open source, licentiata sub GNU LGPL. NuSOAP este utilizata ca si nucleu al altor librarii precum PEAR-SOAP.
Unul dintre avantajele NuSOAP este reprezentat de faptul ca nu este o extensie a PHP, si este scris exclusiv in acest limbaj. Aceasta inseamna ca poate fi folosit de catre orice dezvoltator PHP, indiferent de restrictiile privind accesul la resursele serverului.
Interactiunea cu serviciile web este realizata prin intermediul clasei soap_client. Aceasta clasa de nivel inalt permite utilizatorilor sa specifice optiuni precum autorizarea prin HTTP, informatii despre proxy HTTP, precum si gestionarea trimiterii si primirii de mesaje SOAP.
Operatiile SOAP pot fi executate prin pasarea numelui operatii care se doreste a fi executate, functiei call(). Daca serviciul ofera un fisier WSDL atunci, clasa soap_client preia URL-ul fisierului WDSDL ca argument in constructor, si utilizeaza clasa wsdl pentru a parsa informatia din fisierul WSDL si a extrage datele.
Clasa soap_client foloseste aceste date din fisierul WSDL pentru a encoda parametrii si pentru a crea un "invelis" SOAP cand userul executa un apel al serviciului. Cand apelul este executat, clasa soap_client utilizeaza clasa soap_transport_http pentru a trimite mesajul si pentru a pentru a primi raspuns. Mesajul-raspuns este parsat de clasa soap_parser. Figura de mai jos descrie procesul consumarii unui serviciu web utilizand NuSOAP.
STRUCTURA LIBRARIEI
Insa daca serviciul web nu ofera un fisier
WSDL, procesul este diferit. URL-ul serviciului este transmis constructorului clasei
soap_client. Operatiile sunt executate tot folosind apelul functiei obiectului
soap_client, dar detaliile care erau oferite in cazul precedent de fisierul
WSDL trebuie transmise acum ca argumente. Parametrii care sunt de tip special
pot fi reprezentate folosind clasa soapval, care permite utilizatorilor sa-i
personalizeze.
Atat SOAP cat si WSDL folosesc tipurile de date descrise in specificatiile XML.
Acest lucru poate fi problematic deoarece PHP nu suporta nativ tipurile de date
definite in specificatii. De asemenea, tipurile de date in XML sunt stricte si
bine definite in timp ce PHP este un limbaj de programare mult mai permisiv,
care converteste automat tipurile de date in functie de situatie. NuSOAP
rezolva aceasta problema pe trei nivele diferite:
- 242j98c In WSDL, clasa soap_client a NuSOAP va encoda tipul valorilor corespunzator tipului specificat in documentul WSDL.
- 242j98c Clasa soapval din NuSOAP permite utilizatorilor sa defineasca explicit tipul valorii
- 242j98c Daca nici un tip nu este declarat explicit la instantierea obiectului soapval, NuSOAP va analiza valoarea atribuita acestuia folosind functiile interne ale PHP si o va clasifica ca tip de date valid XML.
Urmatorul exemplu demonstreaza procesul de baza al crearii unui client SOAP, apelul unui serviciu si transmiterea parametrilor, si receptionarea mesajului.
Pentru a permite functiei sa fie apelata la
distanta, aceasta trebuie inregistrata in obiectul server. Daca acest lucru nu
se realizeaza atunci, la apelul functiei de catre client, serverul va genera o
eroare, indicand faptul ca serviciul nu este disponibil. In absenta acestui
proces de inregistrare, orice functie PHP poate fi disponibila apelului la
distanta, ceea ce conduce la probleme grave de securitate.
In cazul in care parametrul transmis functiei nu este un sir de caractere se
genereaza o eroare in care se specifica problema. Acesta sarcina revine clasei
soap_fault, care se ocupa de tratarea erorilor si transmiterea acestora in
mesajul-raspuns. Pasul final este reprezentat de apelul metodei service, care
proceseaza cererea primita si apeleaza functia corespunzatoare. Apoi aceasta
formuleaza raspunsul si il printeaza.
La apelul metodei call() se specifica
obiectului soap_client serviciul care se doreste a fi accesat, apoi se
transmite un array cu parametrii, iar metoda returneaza raspunsul serverului.
Acest raspuns este un tip de date nativ PHP, precum un string, integer sau
array.
NuSOAP ofera un mecanism de detectie al erorilor prin intermediul metodei
getError(). Daca a aparut o eroare, aceasta metoda returneaza un string care
descrie eroarea, sau returneaza false in caz de succes. In exemplul prezentat
se va printa rezultatul in cazul in care nu a fost generata nici o eroare.
Altfel, se va printa mesajul de eroare.
Ultima parte a codului este foarte utila pentru procesul de debug al operatiilor efectuate de NuSOAP. Proprietatile request si response ale clasei soap_client contin mesajele, inclusiv headerele HTTP transmise de fiecare.
J.STILURI
Stilul RPC
Stilul RPC specifica faptul ca eticheta contine un element cu numele metodei web de invocat (element infasurator, plic). Acest element, la randul sau, contine o intrare pentru fiecare parametru si pentru valoarea returnata a acestei metode.
Stilul Document
Daca stilul este de tipul document, nu exista nici un element infasurator (plic), cum este cazul stilului RPC. In schimb, partile de mesaj apar direct sub elementul . Nu exista nicio regula de formatare SOAP pentru continutul etichetei . Acesta contine ceea ce transmitatorul si receptorul au convenit pe baza unui document XML.
A doua regula de formatare este atributul use. Acesta se refera la modul in care tipurile sunt reprezentate in XML. El indica daca partile mesajului sunt codificare utilizand anumite reguli de codificare sau daca partile definesc schema concreta a mesajului.
Cele doua optiuni sunt:
- 242j98c Encoding - daca use este codificat, atunci fiecare parte a mesajului face referinta la un tip abstract apeland la atributul tip. Majoritatea mesajelor sunt produse utilizand o codificare specificata de atributul encodingStyle. Codificarea SOAP cea mai des utilizata este un set de reguli de serializare definit in SOAP 1.1. Regulile specifica cum anume trebuie serializate obiectele, structurile si obiectele grafice. In general, aplicatia care foloseste codificarea SOAP se axeaza pe apelurile de procedura la distanta si deseori folosesc stilul de mesaje RPC.
- 242j98c Literal - daca use este literal, atunci fiecare parte face referinta la o schema de definitie concreta utilizand fie elementul, fie atributul de tip (de exemplu, datele sunt serializate conform unei scheme date). In practica, aceasta schema este exprimata de obicei folosind W3C XML Schema.
Stilul RPC/Encoded
RPC/Encoded este un format care urmeaza stilul clasic de "apel de prodedura la distanta" in care un client trimite o cerere sincrona unui server pentru a executa o operatie. Cererea SOAP contine numele metodei ce trebuie executata si parametrul care trebuie transmis. Serverul ce ruleaza serviciul web converteste aceasta cerere in obiecte corespunzatoare, executa operatia si trimite inapoi raspunsul clientului sub forma unui mesaj SOAP. Pe latura client, acest raspuns este utilizat la formarea obiectelor corespunzatoare si la returnarea informatiilor cerute clientului. In stilul RPC al serviciilor web, intreaga metoda este specificata in fisierul WSDL si in corpul SOAP, incluzand parametri trimisi si valorile returnate. Prin urmare acest stil este unul strans cuplat.
Se remarca aici stilul de legare, care este stabilit la rpc si use, cel din urma setat la valoarea encoded. Sub sectiunea pot exista oricate elemente , fiecare continand un atribut type, unic pentru stilul rpc.
Atuuri
. Definitia fisierului WSDL urmeaza stilul intuitiv, bine cunoscut, al apelului
de procedura la distanta;
. Numele operatiei apare in mesaj, asa incat receptorul poate usor expedia mesajul in implementarea sa;
. Daca utilizati grafuri si polimorfisme in serviciu, este singurul stil care poate fi utilizat pentru aceste tipuri.
Puncte slabe
. Mesajul SOAP include informatia de codificare a tipului precum xsi:type="xsd:int", xsi:type="xsd:string", xsi:type="xsd:double" ceea ce inseamna o supraincarcare;
. In general este mai greu de validat mesajul SOAP;
. Stilul RPC duce la o cuplare mai puternica intre furnizorul de serviciu si client, orice modificare in interfata influentand negocierea dintre serviciu si client;
. In functie de informatiile care trebuie tratate simultan, constrangerile de memorie pot face nefezabila mesageria RPC;
. Nu este suportat de catre standardul WSI.
Stilul RPC/Literal
Fisierul WSDL arata aproape la fel cu cel anterior, cu exceptia modificarii setarii use de la encoded la literal in sectiunea soap:body. Acest lucru inseamna ca definitia tipului de date nu este furnizata de Schema XML referentiata, ci de codificarea RPC. Oricum, exista un mare neajuns si in acest stil. Schema XML singura nu spune ce anume contine setul de informatii al corpului mesajului, ci trebuie cunoscute si regulile RPC. Prin urmare, schema care descrie un mesaj RPC/Literal nu este suficienta pentru validarea mesajului.
Atuuri
. Definitia fisierului WSDL are acelasi stil intuitiv ca si in cazul
RPC/Encoded;
. Si in acest caz numele operatiei apare in mesajul SOAP;
. Codificarea de tip este eliminata din mesaj ducand la o crestere a performantei.
Puncte slabe
. Cuplajul dintre client si serviciu ramane
tot puternic;
. Ramane tot greoaie validarea datelor transferate prin mesajul SOAP;
. Nu este suportat de catre standardul WSI.
Sa trecem la tipul Document/Literal si sa vedem daca acest stil poate diminua o parte din neajunsurile intalnite pana acum.
Stilul Document/Literal
Principala diferenta dintre stilul Document si cel RPC este acela ca parametri serviciului sunt trimisi de client spre server intr-un document XML obisnuit, in loc sa se utilizeze un set de valori si metode ca parametri. Acest lucru face ca stilul Document sa fie mai slab cuplat fata de formatul RPC.
Furnizorul de servicii web prelucreaza documentul XML obisnuit, executa operatia si trimite raspunsul inapoi clientului sub forma unui document XML obisnuit. Nu exista nicio corespondenta directa intre obiectele server (parametri, apeluri de metode) si valori in documentele XML. Aplicatia este responsabila de maparea valorilor datelor XML. Mesajul SOAP al stilului Document transporta unul sau mai multe documente XML in corpul sau SOAP. Protocolul nu are nicio constrangere in privinta modalitatii de structurare a documentului, structurarea fiind in intregime realizata la nivelul aplicatiei. In plus, serviciile web in stilul Document urmeaza paradigma de procesare asincrona.
Fisierul WSDL pentru acest stil sufera mai multe modificari comparativ cu stilul RPC. Se observa ca stilul de legatura este stabilit la document, iar use primeste valoarea literal. Sub sectiunea message poate aparea doar un singur element , care contine un atribut de element. Aceasta parte indica spre o declaratie de element schema care descrie intregul continut al corpului SOAP. Colectia este acum definita ca element, nu ca tip. Principala trasatura a stilului Document/Literal si principalul avantaj in acelasi timp este utilizarea declaratiei de element schema pentru descrierea completa a continutului corpului . Acest lucru inseamna ca se poate cunoaste ce anume contine setul de informatii al corpului mesajului doar pe baza schemei, fara a fi necesara consultarea regulilor suplimentare. Ca urmare, mesajul poate fi validat doar cu ajutorul schemei de descriere a mesajului Document/Literal, lucru imposibil in cazul RPC/Literal.
Atuuri
. Nu exista nicio informatie de codificare a tipului in mesajul SOAP;
. Mesajul poate fi validat intotdeauna cu orice validator XML. Orice parte a
corpului soap este definita in schema;
. In cazul stilului Document regulile sunt mai putin rigide, putand fi facute multe extensii si modificari in cadrul schemei XML, fara a influenta interfata;
. Serviciile bazate pe stilul Document pot pastra starea aplicatiei daca sunt apelate mai multe proceduri intr-o anumita secventa;
. Stilul Document se potriveste mai bine procesarii asincrone;
. Multe servicii bazate pe mejajele document pot alege intre tratarea DOM si SAX a documentului si, prin urmare, pot mimimiza procesarea derulata in memorie.
Puncte slabe
. Fisierul WDSL devine ceva mai complicat;
. Numele operatiei din mesajul SOAP se pierde. Fara nume, expedierea poate fi dificila, uneori imposibila;
. Asadar stilul Document/Literal inlatura majoritatea neajunsurilor stilului RPC/Literal, dar aduce o noua problema: pierde numele operatiei in cadrul mesajului SOAP. A patra optiune de formatare, Document/Encoding, nu are utilizari practice.
K.CONCLUZII PARTIALE
Serviciile web axate pe documente si pe RPC acopera nise diferite. Serviciile web bazate pe stilul Document sunt mult mai potrivite interactiunii inter-intreprindere via internet. Dezvoltarea unui serviciu web bazat pe stilul Document poate necesita un efort mai mare fata de cel necesar dezvoltarii unui serviciu in stilul RPC. Stilul Document/Literal aduce o mai mare flexibilitate avand mai multe puncte tari in privinta interoperabilitatii in comparatie cu celelalte stiluri de proiectare. Atunci cand nu trebuie sa va conectati la o interfata RPC existenta deja, beneficiile stilului Document cantaresc mai mult decat cele de interfatare cu serviciul. Abordarea RPC/Encoded nu este incurajata pentru proiectarea unui serviciu web mai ales daca principala cerinta a intregului sistem este interoperabilitatea.
Arhitectura standard orientata spre servicii este un model bazat pe componente, al carui scop este cuplarea de aplicatii software, care interactioneaza intre ele si care furnizeaza servicii. Aceasta arhitectura propune si descoperirea serviciilor pe baza descrierilor lor. Cuplarea relaxata (nerestrictionata) a serviciilor aduce avantaje privind flexibilitatea si extensibilitatea arhitecturii insasi, precum si a structurii interne si implementarii serviciilor. Aceasta caracteristica face ca arhitectura orientata spre servicii sa fie potrivita pentru mediul de afaceri care este dinamic si bazat pe cereri explicite de servicii.
Transpunerea in realitate a idealului ca oamenii de afaceri sa controleze direct logica afacerii intr-o maniera flexibila si agila, arhitectura orientata spre servicii SOA, este o abordare catre proiectarea infrastructurii de calcul cu resurse distribuite in care resursele software sunt servicii disponibile prin reteaua Internet. Producatorii serviciilor publica informatia despre ele in registre ale serviciilor (repository), acolo unde consumatorii potentiali pot sa caute.
Solutiile SOA descrise detin urmatoarele caracteristici:
Slab cuplate - Intr-un sistem cuplat slab, aplicatiile consumator nu au nevoie sa stie a priori detalii ale functionalitatii sistemului cu care se conecteaza. Functionalitatea aplicatiilor si programele care o invoca pot fi schimbate independent unele de altele in loc de a reproiecta componentele implicate.
Cuplarea relaxata a serviciilor se realizeaza prin doua constrangeri asupra arhitecturii orientate spre servicii:
- 242j98c multime de interfete simple, comune tuturor aplicatiilor software care realizeaza serviciile. Pentru universalitate, aceste interfete au o semantica generica si sunt independente de platforma hardware, de sistemul de operare, de middleware si de limbajul de programare pentru implementarea serviciului
- 242j98c mesaje descriptive, realizate pe baza unei scheme redefinite, extensibile, care limiteaza structura mesajelor si permite definirea de versiuni noi ale mesajelor.
Granulat brut - In loc sa interactioneze cu un set larg de detalii, granulate fin, cum sunt interfetele de programare ale aplicatiilor (API), utilizatorii pot interactiona cu sisteme prin granule brute, la nivel de interfata de afacere, care impacheteaza functionalitatea multor apeluri API intr-un numar mic de mesaje de afaceri.
Bazate pe standarde cum sunt HTML, XML, SOAP etc.
Astfel SOA este arhitectura in care serviciile sunt bazate pe standarde, declansate de evenimente si cuplate slab. Arhitectura SOA permite consolidarea serviciilor in servicii de afaceri granulate brut care au flexibilitatea si receptivitatea pentru a sustine prioritatile afacerii flexibile si dinamice.
L.Cuplajul slab
Serviciile web sunt o tehnologie folosita de aplicatiile bazate pe Internet cu clienti si servere slab cuplati. Acest sistem face ca serviciile web sa fie alegerea naturala pentru constructia aplicatiilor pe infrastructura care permite partajarea unor resurse de calcul care se pot afla in domenii administrative diferite.
Astfel de sisteme in care se incearca integrarea, virtualizarea si managementul resurselor si serviciilor in organizatii virtuale distribuite, heterogene si dinamice sunt cele in care cerintele sunt de:
- 242j98c relatii de partajare foarte flexibile, de la client-server pana la peer to peer
- 242j98c modalitati precise de control asupra felului in care resursele partajate sunt folosite, incluzand controlul accesului cu granularitate fina, delegare, si aplicarea politicilor locale si globale
- 242j98c partajarea unor resurse variate ca: programe, fisiere, date, calculatoare, senzori, retele, s.a
- 242j98c modalitati de utilizare diferite , de la single user pana la multiuser, si de la sisteme sensibile la performante pana la sisteme sensibile la cost, si deci ingloband elemente de calitate a serviciului (quality of service - QoS), planificare(sheduling), si contabilitate.
M.ESB (
Abordarea prezentata, pentru solutiile de implementare a arhitecturilor orientate pe servicii care rezolva aceste cerinte schimbatoare, este ESB (Enterprise Service Bus). ESB este combinatia dintre mesajele standard la nivelul midleware, containere distribuite de servicii agregate in servicii granulate brut, bazate pe standarde si pe transmiterea documentelor pe cai guvernate de reguli. ESB furnizeaza servicii cu valoare adaugata deasupra celor gasite in abordari anterioare midleware cum sunt validarea mesajelor, transformarea, alegerea caii pe baza continutului, securitate, descoperirea serviciului, balansarea incarcarii, toleranta la defecte si
jurnalizarea. Astfel ESB poate furniza fundatia peste care pot avea loc interactiuni asincrone cuplate slab. ESB retrogradeaza serverele de aplicatii in rolul de a rula servicii asincrone particulare in timp ce ESB formeaza fundatia comunicarii intre servicii. Calitatea ESB se masoara prin determinarea abilitatii de a modela si implementa procese de afaceri din lumea reala. O magistrala ESB eficienta furnizeaza mecanisme prin care utilizatorii pot manipula componente la nivelul modelului afacerii pentru a defini si rula procese de afaceri declansate de evenimente, raspuns in timp real al schimbarilor afacerii. Magistralele ESB pot fi realizate in diverse tehnologii cum sunt Java Messaging System, Microsoft, IBM etc. In arhitecturi orientate spre servicii bazate pe standarde XML. Peste implementarea unei magistrale ESB pachetele software contin unelte vizuale estinate definirii proceselor complexe de afaceri, compuse astfel
din servicii accesibile sau create prin noua platforma:
Magistrala de mesaje (ESB) - Implementeaza interfete standard pentru comunicatie, conectivitate, transformare, portabilitate, si securitate. Specificitatea este data de modelul serviciilor de afaceri granulate brut combinate cu extensibilitatea, toleranta la defect intr-o arhitectura distribuita care permite proceselor de afaceri sa fie coordonate cu integritate tranzactionala peste un mare numar de aplicatii rulate pe platforme eterogene.
ESB este unul din cele
mai importante modele ale SOA. ESB unifica conceptele intr-o
infrastructura. Conceptul de ESB a fost la inceput descris ca fiind 'o
noua arhitectura care exploateaza serviciile Web, trimitand
mesaje,realizand o rutare inteligenta precum si transformare'
spune Roy Schulte in lucrarea sa 'Predicts 2003:
ROLUL ESB IN CADRUL SOA
In ideea implementarii SOA, atat aplicatiile cat si infrastructura trebuie sa suporte principiile SOA. Existenta aplicatiilor presupune crearea interfetelor de service pentru noi functii in mod direct sau prin intermediul unor adaptoare.
Existenta infrastructurii la nivelul de baza presupune existenta clauzei capacitatii de rutare si transport a serviciilor cerute prin intermediul provider-ului corect. Rolul ESB este acela de a permite infrastructurii aceasta legatura.
Adevarata valoare a ESB este de a permite accesarea infrastructurii pentru SOA, in scopul satisfacerii nevoilor actuale ale intreprinderii - de a oferi servicii la diferite nivele, de a putea opera in diferite medii eterogene. ESB trebuie sa fie capabil sa substituie un serviciu de implementare cu altul fara a rezulta un efect negativ asupra clientului final.
ESB este descris si ca o infrastructura distribuita. In modelul integrarii proceselor de e-business un ESB poate fi clasificat ca un bus, ce este vazut ca un hub.
242j98c 242j98c 242j98c 242j98c 242j98c Cel mai important rol al unei clase in cadrul aplicatiei este cel de furnizor de servicii. Acest tip de clasa poate furniza servicii in mod direct interfetei clientilor, unei alte componente sau unei alte aplicatii (cand se creeaza un serviciu Web). In acest sens, o componenta are un scop, si anume sa faciliteze reutilizarea si intretinerea unor secvente de cod distincte din punct de vedere logic.
242j98c 242j98c 242j98c 242j98c 242j98c Cea mai buna solutie este proiectarea componentelor avand in minte arhitectura distribuita, dar ele trebuie distribuite pe calculatoare diferite numai cand este necesar.
242j98c 242j98c 242j98c 242j98c 242j98c Cand se doreste crearea unei aplicatii ce reprezinta o extensie a unei alte aplicatii deja existente, dar care nu poate fi modificata cu tehnologia de programare folosita pentru crearea ei, cand se doreste dezvoltarea unei aplicatii create de un alt dezvoltator, sau cand se urmareste dezvoltarea unor aplicatii care ruleaza pe platforme diferite. Componentele care vor fi dezvoltate pe partea server duc la centralizarea nivelului aplicatie intr-un singur loc, dar permit utilizarea lui de diferiti clienti distribuiti, construiti ca atare.
242j98c 242j98c 242j98c 242j98c 242j98c Aplicatia este utilizata atat de mult incat scalabilitatea ei, performantele sale sunt depasite.
Cea mai importanta caracteristica a aplicatiilor distribuite o reprezinta scalabilitatea. Intr-un sistem distribuit scalabil viteza de raspuns a sistemului nu creste odata cu cresterea numarului de utilizatori. Scalabilitatea hardware a sistemului distribuit influenteaza si precede scalabilitatea software a aplicatiei. Daca singura modificare necesara unei aplicatii distribuite pentru a permite conectarea mai multor utilizatori este suplimentarea resurselor hardware ale sistemului, atunci aplicatia este considerata scalabila. O modalitate eficienta de scalare a unui sistem este partajarea resurselor software ale sistemului. Partajarea resurselor foloseste o tehnica de ciclare a resurselor fara a presupune distrugerea si recrearea lor la fiecare utilizare. Acest lucru este important din doua motive:
242j98c 242j98c 242j98c 242j98c 242j98c Timpul pentru crearea si distrugerea unei resurse software poate reprezenta o parte semnificativa din timpul de viata al resursei. Utilizarea unei resurse odata create de mai multor procese, prin activarea si dezactivarea sa, reduce costul per proces al lipsei de activitate datorat crearii si distrugerii resursei.
242j98c 242j98c 242j98c 242j98c 242j98c O resursa partajata poate fi utilizata de un alt proces si nu se va afla in asteptare atunci cand procesul care a creat-o o solicita. Stabilirea starii fiecarei resurse este utila in realizarea sincronizarii tranzactiilor deoarece in aceste conditii poate fi necesar ca un proces sa astepte terminarea unui alt proces.
242j98c 242j98c 242j98c 242j98c 242j98c Pentru ca o resursa sa poata fi partajata trebuie ca ea sa fie proiectata astfel incat utilizarea acestei resurse de un anumit client sa nu afecteze utilizarea ulterioara a acelei resurse de catre un alt client.
Resursele aplicatiei care beneficiaza de avantajele partajarii pot fi, de exemplu, conexiunile la baze de date si componentele nivelului intermediar.
242j98c 242j98c 242j98c 242j98c 242j98c Partajarea conexiunilor - permite unei aplicatii sa foloseasca conexiuni deja create, de exemplu la un server de baze de date.
242j98c 242j98c 242j98c 242j98c 242j98c Partajarea componentelor - presupune utilizarea de componente deja create, componente fara stare, aflate la un nivel intermediar al aplicatiei distribuite.
242j98c 242j98c 242j98c 242j98c 242j98c Fiabilitatea sistemului: proasta functionare sau nefunctionarea unuia din calculatoarele sistemului distribuit nu trebuie sa atraga dupa sine si nefunctionarea intregii aplicatii. Elementele care definesc fiabilitatea unei aplicatii distribuite sunt:
242j98c 242j98c 242j98c 242j98c 242j98c Serviciul asteptat - serviciile aplicatiei trebuie sa corespunda asteptarilor clientilor sau utilizatorilor.
242j98c 242j98c 242j98c 242j98c 242j98c Garantarea comportamentului - trebuie sa existe o modalitate de garantare a functionarii operatiilor critice ale aplicatiei.
242j98c 242j98c 242j98c 242j98c 242j98c Gestiunea situatiilor exceptionale - nu poate sa existe o garantie absoluta a functionarii tuturor serviciilor, existand potential de esec in orice componenta sau nivel al aplicatiei, insa aplicatia trebuie sa fie capabila sa-si reia functionarea fara coruperea informatiilor.
242j98c 242j98c 242j98c 242j98c 242j98c Securitate - o aplicatie distribuita trebuie sa fie securizata fata de agentii externi. Deoarece elementele care tin de securitate afecteaza toate componentele aplicatiei, ele pot fi incluse in infrastructura acesteia.
Eficienta la executie - masoara cat de bine functioneaza o aplicatie odata ce ea a devenit operationala. Datorita diversitatii aplicatiilor distribuite si a modificarilor dinamice in ceea ce priveste infrastructura, determinarea eficientei la executie este dificil de generalizat. Principalii indicatori care determina eficienta la executie a unei aplicatii distribuite sunt: timpul de raspuns, gradul de utilizare a resurselor, gradul de coabitare cu alte aplicatii cu care partajeaza aceeasi infrastructura.
Vastitate: aceste aplicatii sunt, in general, multi-utilizator, multi-calculator, manipuleaza volume mari de date, folosesc prelucrare paralela, resurse distribuite in retea si au o algoritmica complexa.
242j98c 242j98c 242j98c 242j98c 242j98c Continuitatea operatiilor critice: aplicatia trebuie sa fie destul de robusta pentru ca operatiile critice sa poata fi realizate continuu. Trebuie sa fie extrem de flexibila pentru a asigura scalabilitatea si pentru a permite o intretinere, monitorizare si administrare eficiente.
|
