A.INTRODUCERE
Arhitectura software bazata pe servicii este din ce in ce mai larg acceptata si utilizata in contextul actual al evolutiei catre Web 2.0.
SOA (Service-Oriented Architecture) este un tip de arhitectura software care presupune o abordare modularizata asupra dezvoltarii aplicatiei, aceasta fiind divizata in unitati distincte dar interoperabile - numite servicii - care sunt puncte de acces la functionalitatile pe care aplicatia le furnizeaza. Capacitatea mare de reutilizare a acestor servicii, provenite din diferite surse, in cadrul unor aplicatii diferite este una din caracteristicile definitorii ale arhitecturilor software bazate pe servicii, SOA fiind deseori vazuta ca o evolutie a programarii distribuite si modulare.
Lucrarea de fata reprezinta un studiu general asupra arhitecturii SOA, cu accent pe detalii specifice de implementare si exploatare, evidentiind faptul ca orchestrarea unei astfel de arhitecturi este o sarcina complexa, standardele implementarii fiind volatile, situate in centrul cercetarii companiilor mari.
Pentru a sublinia beneficiile aduse de arhitectura SOA in cadrul tehnologilor web (reutilizabilitate si extensibilitate), se va prezenta o aplicatie dezvoltata sub forma unor servicii web utilizand protocolul SOAP, care modeleaza interactiunea dintre o loterie, clientii acesteia, si banca prin intermediul careia se desfasoara tranzactiile.
B.SOA in contextul actual
Serviciile Web au aparut ca urmare a necesitatii interconectarii diferitelor aplicatii ce ruleaza la nivel de intreprindere printr-o modalitate mai rapida si eficienta decat prin metodele traditionale. In prezent, din ce in ce mai multe companii apeleaza la ajustarea arhitecturilor pentru a exploata serviciile Web in scopul dezvoltarii de aplicatii flexibile, ce pot fi ajustate pe masura ce cerintele de afaceri o impun.
Conceptul de servicii Web (Web services) si-a facut aparitia la inceputul anului 2000, intr-o perioada de recesiune in care solicitarile de integrare a sistemelor folosind standarde precum Simple Object Access Protocol, Web Services Description Language (WSDL) si specificatii Universal Description, Discovery and Integration (UDDI), impreuna cu tehnologia XML.
Penetrarea
conceptului de servicii Web in zona operatiunilor IT la nivel de corporatie a
fost atenuat multa vreme din cauza pozitiilor divergente vizavi de standarde.
Cererea pietei pentru asemenea capabilitati a condus la fortarea unor acorduri
intre producatori rivali si a condus la unirea eforturilor lor pentru a pune la
dispozitia clientilor intregul set de avantaje generate de serviciile Web, in
ciuda provocarilor ridicate de arhitecturile si gradul lor de securitate.
Aproximativ doua treimi din cele mai mari implementari de servicii Web
existente la ora actuala au ca tema principala proiecte de integrare, asa dupa
cum arata un studiu al companiei Gartner.
Utilizarea strategica a serviciilor Web a devenit subiect de prima importanta pe masura raspandirii conceptului. Serviciile Web sunt definite ca un nou set de standarde si tehnologii ce permit integrarea aplicatiilor intre ele. Prin beneficiile pe care le aduc, serviciile Web sunt considerate de multi ca un panaceu pentru toate problemele legate de IT. Si, in ciuda faptului ca de-a lungul timpului au fost inregistrate numeroase cazuri de tehnologii care au fost promitatoare la inceput si pe parcurs s-au dovedit a ramane la stadiul de promisiuni neonorate, serviciile Web aduc o serie de beneficii semnificative. In primul rand, serviciile Web pot automatiza procese de comunicare ce pana in prezent s-au dovedit a fi ineficiente sau greu de stabilit.
De asemenea, serviciile Web furnizeaza beneficii in interiorul companiei prin scaderea semnificativa a costurilor de integrare. Conectarea diverselor departamente sau a noilor sedii se poate realiza rapid, cu cheltuieli reduse si intr-un mod mai flexibil folosind tehnologiile puse la dispozitie de serviciile Web.
Serviciile Web sunt un element important pentru arhitectura SOA (Service-Oriented Architecture) ce permite organizatiilor sa raspunda mai rapid modificarilor aparute in mediul de afaceri, fie ca este vorba despre modificarea aplicatiilor sau de introducerea de noi produse si servicii. Utilizarea unei arhitecturi a serviciilor Web are ca efect adaptarea mai facila la cerintele de compatibilitate impuse de diverse alte standarde. Intr-un mediu cu arhitectura distribuita, administratorul are un control si o vizibilitate mai buna, precum si posibilitatea de a masura performantele mediului.
Un limbaj de programare si platforma de dezvoltare corespunzatoare sunt necesare petru a dezvolta seturi de servicii Web. Alaturi de acestea trebuie folosite o serie de standarde de programare proiectate special pentru serviciile Web. Cele mai importante standarde sunt:
XML (Extensible Markup Language) - un standard pentru definirea numelor si proprietatilor elementelor asociate datelor tranzactionate intre solicitantul serviciului si furnizorul acestuia.
SOAP (Simple Object Access Protocol) - un set de reguli referitoare la modul in care sunt incluse solicitarile si raspunsurile pentru servicii Web in schimbul care are loc intre un utilizator si un furnizor de servicii Web.
WSDL (Web Services Description Language) - un limbaj bazat pe XML utilizat pentru descrierea serviciilor oferite de un furnizor si a protocoalelor (precum SOAP) necesar a fi utilizate pentru a putea beneficia de acestea.
UDDI (Universal Description, Discovery and Integration) - un registru care permite unui furnizor de servicii Web sa faca publice si sa descrie serviciile pe care le pune la dispozitie pentru ca potentialii utilizatori sa fie informati de disponibilitatea lor.
O serie de organizatii urmaresc elaborarea si certifica standardele mentionate mai sus, precum si alte standarde menite sa asigure interoperabilitatea extinsa a serviciilor:
- World Wide Consortium (W3C); organizatia care a dezvoltat protocolul de baza al Web-ului, HTTP, si limbajul paginilor Web, HTM, a dezvoltat, de asemenea, standardul XML. O serie de colaborari intre principalele companii din piata au condus la aparitia SOAP si WDSL, standarde ce se inscriu pe lista de recomandari a W3C.
- OASIS (Organization for the Advancement of Structured Information Systems) este o organizatie formata la initiativa unor companii cu preocupari in randul serviciilor Web, precum IBM, Microsoft si Sun Microsystems. OASIS a supervizat dezvoltarea de standarde precum UDDI, ebXML.
- Web Services Interoperability Organization (WSI) este o alta organizatie formata din peste 120 de membri, printre care IBM, Microsoft, Sun Microsystems, Oracle, ce au ca scop elaborarea de standarde ce permit serviciilor Web sa fie accesibile pe platforme diferite. Activitatea legata de interoperabilitate este cuprinsa intr-un document intitulat Basic Profile Version 1.
Principalele platforme de dezvoltare utilizate pentru elaborarea de servicii Web sunt puse la dispozitie de Microsoft, Sun Microsystems, Hewlett-Packard si IBM. Setul comun de instrumente standard folosite este destinat sa permita functionarea serviciilor Web pe diferite sisteme de operare.
C.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. 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:
Standardizare
Solutii multi-platforma, slab-conectate, Integrare Internet/Web aplicatiilor, serviciilor serviciilor si si sistemelor
Performanta prin asigurarea scalabilitatii -Servicii atasabile (pluggable ) & inteligente "Software as Service" - App. Service Provider
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 (component-based software).
Aplicatiile standard ("vechi vechi") trebuie trebuie integrate in noua noua arhitectura rezultand protectia investitiilor
Solutia se pare ca este una singura: "The Web is the computer " si se cere deci se impune crearea unei arhitecturi care sa suporte paradigme de comunicare bazata pe Web intre aplicatii, sa ofere localizare transparenta a a serviciilor, sa permita adaugarea , inlocuirea, eliminarea serviciilor in mod dinamic si sa ascunda dezvoltatorului detaliile de sistem.
Serviciile
web sunt deci aplicatii utilizate de alte aplicatii (la distanta) fiind accesate
standardizat via Web. Traditional, o aplicatie Web expune o
interfata-utilizator in care cererile erau capt(
Caracteristici acestor servicii se reduc la utilizarea lor in interactiunea intre masini, dinamicitate, lipsa unei cunoasteri a-priori a interactiunii cu alte aplicatii si/sau servicii Web. Deasemeni sunt independente de sistem, platforma si limbaj de programare si sunt puncte terminale utilizate pentru procesarea datelor , in maniera publica. Reusec cu succes sa prelucreze orice tip de date fiind dezvoltate pe baza platformelor , arhitecturilor si limbajelor curente in concluzie fiind deschise si extensibile.
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:
furnizor de servicii: software pentru specificarea si descrierea serviciului
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
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
broker de servicii - un serviciu special, care trimite cererile de servicii catre furnizorii de servicii.
D.Principiile de baza impuse de SOA:
serviciile trebuie sa partajeze un contract formal
serviciile trebuie sa fie slab cuplate(loosley coupled)
serviciile trebuie sa ascunda dezvlotatorului detaliile de implementare
serviciile trebuie saofere suport pentru compunerea cu alte servicii(composability)
serviciile trebuie sa poata fi reutilizate
serviciile trebuie sa se execute intr-un mod autonom
serviciile nu trebuie sa depinda de starea comunicarii(statelessness)
serviciile nu trebuie sa depinda de cantitatea de informatie specifica unei activitati ce trebuie retinuta fiind minimala
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:
remote procedure call (apel de procedura la distanta): clientul trimite o cerere SOAP furnizorului de servicii si asteapta un raspuns SOAP (comunicatie sincrona);
messaging (mesagerie): clientul trimite o cerere SOAP si nu asteapta nici un raspuns SOAP din partea furnizorului de servicii (comunicatie unidirectionala);
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.
Imprementarea SOA fara servicii web
Servicii web sunt esentiale pentru punerea in aplicare a SOA in cazul in care mediul se modifica la unul eterogen. Cred ca problema este de fapt ceea ce constituie un serviciu web intradevar. Urmatoarea intrebare care se ridica este este destul de bun SOAP? Daca da, vorbim despre SOAP 1.0, 1.1, sau 1.2? Daca nu, avem nevoie, de asemenea, de mai multe din specificatiile WS? Daca da, care dintre ele? WS-Reliable Messaging? WS-Atomic Transaction? WS-Addressing? WS-Topics? De asta sunt asa de grozave standardele - exista atat de multi de la care poti alege. Desigur diferiti furnizori sprijina diferite subseturi dintre toate aceste standarde care ofera atat de multa interoperabilitate. La nivel de message-payload interoperabilitatea este suficient de bine manipulate de XML si XSD, desi RelaxNG arata atat de elegant, mult mai bine pentru scheme. Intrebarea acum devine una de comunicare - cum arata un mesaj si cum sunt reprezentate diferitele modele de comunicatii. La cel mai simplu nivel avem HTTP care este interoperabil apoape pe toate platformele dar este totodata si putin absent la un nivelel mai ridicat al caracteristicilor. Acest lucru reduce problema la legaturi care se pare ca devine una din marile griji care se incearca a fi rezolvate prin creerea unui strat abstract intre logica serviciilor si infrastructura comunicarii. Acest layer de abstractizare ar trebui sa fie implementat in aceesi tenhologie ca si serviciile. Cand se vor folosi ca suport platforme care suporta lucrul cu interfete de multe ori aceasta conduce la 2 astfel de straturi: unu pentru interfata si celalalt pentru maparea tehnologiei specifice. Adaugam la aceasta faptul ca folosirea dependentei de insertie si faptul ca poti face ca comunicatia ta sa evolueze cu specificatii si platforme. Aparitia unui astfel de strat de abstractizare pentru fiecare din tehnologii gasit printre servicii poate fi anticipata.
Putem incepe asadar cu o singura platforma pentru a pastra lucrurile simple. Ramand decuplat de la ea vom reusi sa evoluam odata cu tehnologia, mentanand in acelasi timp si ce s-a lucrat pana in acel moment asupra serviciilor. Acesta este un aspect de agilitate asteptat din partea ahitecturilor SOA. Asfel serviciile web sunt de fapt doar un detaliu in implementare si nicidecum o preocupare primara a arhitecturii. Interfata de comunicare este bine definita logic si maparea pe tehnologia aleasa este ceva simplist, se complica uneori daca tehnologia nu suporta pub/sub si se doreste implementarea in layerul de mapare. Daca se foloseste WS - Addressing sau WS - Topics nu este insa relevant. Alte specificatii precum WS - Atomic Transactions sunt ceva ce nu se va folosi probabil niciodata deoarece tranzactiile care urmeaza intre servicii distruge autonomia.
Concluzia care poate fi desprinsa este ca SOA poate fi implementata si fara servicii web in ambele medii omogen si eterogen, si fiecare proiect trebuie sa sa se autoanalizeze sau macar sa incerce sa rezolve acest aspect. Asadar acest aspect al diferitelor tipuri de implementare a arhitecturii SOA ma refer la cel fara servicii web nu ar trebui sa influenteze deciziile luate in arhitectura, este doar o problema de comunicare. De asemea trebuie sa se tina seama ca nu toate interactiunile intre servicii ar trebui sa sa fie la fel, unele au nevoie de fiabilitate, altele trebuie sa se trimita un sumum de mesaje, altele prezinta necesitatea de a interopera bine cu partenerii externi. Planul si orarul pentru aceste cazuri speciale iau timp pantru a fi perfectionate si nici apartitia de specificatii WS nu va rezolva problema in vreun mod magic. SOA inseamna mult mai mult decat un concept de tehnologie si WebServices este doar unu suport al acestei tehnologii. SOA are la baza urmatorul concept 'Schimbul de servicii'. Se face deci referire la refolosire, repetabilitate su mentenanta. Serviciile web nu sunt esentiale pentru punerea in aplicare a SOA: daca opereaza intr-un mediu omogen. Tehnicile actuale care se bazeaza pe principiile analizei si proiectarii orietante obiect pot in mod clar sa expuna acest aspect al implemetarii SOA in mediu omogen fara a se folosi servicii web. Pentru a sustine acesta teorie se considera ca exemplu elocvent momentele in care se se scrie cod si se vrea ca acesta sa fie reutilizabil si fac referinta la algoritmi care se repeta si care sunt incapsulati in functii sau metode pentru a fi reutilizati, sunt doar numiti si codul lor nu este rescris de cate ori este nevoie de aplicarea algoritmului in cauza. Asadar reutilizarea, repitabilitatea si posibilitatea de a lucra asupra codului conduce spre impartirea serviciilor, care este fundamentul SOA. Se pare deci ca ideea de SOA a aparut odata cu apropierea de abordarea sistemul client - server. Ideea s-a conturat mai bine atunci cand calculul distribuit s-a dezvoltat si mai tarziu cu impartirea serviciilor s-a observat dependenta SOA. Aici am vorbit de un mediu omogen. Cand functioneaza intr-un mediu omogen in cazul in care vizibilitatea in randul sistemelor nu este o problema, (acelasi sistem de operare,aceeasi infrastructura de retea, de protocol comun de comunicare, etc), doua cereri diferite pot 'partaja serviciile lor'.
Insa serviciile web sunt esentiale pentru punerea in aplicare a SOA: in cazul in care mediul se schimba catre unul eterogen. Int-un mediu eterogen in care sunt necesare doua tipuri de stive tehnologice pentru a se asigura interoperabilitatea sau unde nu exista vizibilitatea din cadrul sistemelor datorata incapsularii in domeniul industrial.
Pentru a concluziona daca SOA este gandita intr-un mediu omogen vizibil serviciile web nu isi mai au rostul, acestea devin importante cand vine vorba de platforme tehnologice eterogene sau de mediile dintre intreprinderi.
TEHNOLOGII IMPLICATE
A.Spatiul WWW (World Wide Web)
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.
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.
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).
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.
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.
Tehnologiile obiectuale distribuite permit obiectelor care ruleaza pe un anumit calculator sa fie accesate de aplicatii sau obiecte aflate pe alte sisteme.
Similaritati ale tehnologiilor:
. 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.
. Sunt asociate unui model pe componente. Utilizarea componentelor duce la cresterea flexibilitatii aplicatiilor si la reutilizarea serviciilor.
. 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. XML - RPC=HTTP+XML+RPC
E.LIMBAJUL XML
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.
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:
gasirea elementului radacina intr-un document XML
returnarea unei liste de elemente cu un anumit nume de
returnarea listei de fii a unui anumit nod
returnarea parintelui unui anumit nod
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 stergerea unui element dintr-un document XML
adaugarea, modificarea sau stergerea unui atribut dintr-un document XML;
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.
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 unul dintre participantii la comunicatie creeaza XML intr-un anumit format si celalalt 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.
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.
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 separat (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>
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
Elementul <portType>
Trebuie sa existe o cale de a asocia operatiile cu endpointurile de unde acestea pot fi accesate.
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> La sfarsitul fisierului WSDL se definesc endpointurile pentru fiecare dintre protocoalele care se pot folosi pentru a accesa un serviciu web.
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.
Sistem de registri bazat pe XML independent de platforma
Facilitarea comunicarii intre serviciile oferite de firme:White Pages,Yellow Pages, Green Pages
Implementeaza conceptul de service broker
Este interogat de mesaje SOAP ce solicita un serviciu Web
Ofera acces catre documentul descriptiv WSDL al serviciului Web
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 inregistrarea in registre UDDI a informatilor 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 participantii pot colabora;
- Marirea vizibilitatii si accesibilitatii companiei in cautarile unor potentiali beneficiari;
Informatiile oferite de UDDI
UDDI poate oferi raspunsuri la query-uri astfel:
- ce servicii web ofera o anumita aplcatie;
- 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.
Un punct in care SOA si REST sunt de acord este loose coupling care se pare ca este dorit in general. Aceasta va permite diferitelor parti ale unui sistem distribuit evolueze la rate diferite, ambele tabere de acord ca este absolut necesar fiindca scalabilitatea sistemul creste. In general, fiecare intr-un serviciu de sistem are o interfata sau contractul nu numai pentru operatiunile sale, ci si pentru schimbul de date, ca parte a operatiunii de invocare. O definitie WSDL unui serviciu Web, de exemplu, defineste operatiunile din punct de vedere al celor care stau la baza intrarilor si iesirilor de mesaje, dar ea defineste de asemenea, schimbul de date, care insoteste aceste mesaje. Un important avantaj al interfetei uniforme de constrangere se afla in zona de scalabilitate. Dar un client pentru de a invoca un serviciu REST, trebuie sa inteleaga ca doar date specifice contractului ale serviciului: contract de interfata este uniforma pentru toate serviciile. Impactul pe scara larga a sistemelor: imaginati-va, de exemplu, Web-ul contine milioane de site-uri Web si ca fiecare are definit propria sa interfata speciala. In utilizarea browser-ul dumneavoastra Web pentru a interactiona cu un anumit site, probabil ca ar trebui sa descarci sau sa scrii un nou plug-in de browser care intelege interfata site-ului. Dar nu exista nici o indoiala asupra constrangerii interfetei uniforme poate permite scalabilitatea pentru mai multe sisteme. Se scot total din ecuatie termenii contractului de interfata din interactiunea client-serviciu.
In ceea ce privete variabilitatea datelor bineinteles, o parte din variabilitatea datelor din ecuatia de scalabilitate (servicii care astepta la diferite si ofera formate diferite de date), raman in incluse in protocolul REST, chiar daca variabilitatea interfetei este eliminata. Desi variabilitatea datelor este intr-adevar un factor in ambele sisteme SOA si REST, REST are un avantaj aici, de asemenea. Maniera de manipulare a formatelor de date in REST ajuta, de asemenea, la scalabilitate. Permitand serviciilor sa gestioneze mai multe formate de date inseamana clienti si servicii care pot folosi tipuri de date corespunzatoare pentru diferite tipuri de date, cum ar fi imagini, text, si foi de lucru. Aceste tipuri de media sunt forme specifice alee rprezentarii generale notiunii de metadate a REST-ului. Faptul ca aceste metadate insotesc de asemenea mesaje, inseamna ca, clientii pot solicita formatul de date pe care le prefera sa il primeasca. Mai mult, separarerea clara intre infrastructura de distributie si reprezentarea metadatelor manipulate in REST inseamna ca dezvoltatorii pot construi sisteme orientate spre REST, folosind o infrastructura care este mult mai usoare decat multe dintre platformele SOA.
In ceea ce priveste denumirea resurselor desi interfata si, evident, contractele de date in mod clar si semnificativ variaza intre REST si SOA, fiecare suporta notiunea de denumire a resurselor. REST trateaza ca reprezentari ca fiind cai pentru aplicatii pentru a permite navigarea sisteme distribuite hipermedia; in mod similar, aplicatiile in mod normal acceseaza serviciile SOA prin intermediul unui identificator dintr-o retea distribuita. Multe platforme SOA se concentreze prea puternic la nivel de nivel de programare dar nu suficient la nivel de distributie.
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.
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.
SOAP versus
REST
Exista dezbatere aprinsa pe fondul meritelor SOA fata de REST.
Unii sustin ca SOA/WS- * este prea complex si prea de nivel
industrial si ca ar trebui sa extirpe complexele standarde de
abordare WS-* in favoarea unei abordari simplificate REST. Intentia
este de a crea procesul de imbunatatiri si flexibilitate
pentru a schimba procesele de codare folosind un proces modeler si executie
motor - inlocuirea hard-coded. Exista, de asemenea, necesitatea de a
agrega serviciile fin granulate(intr-un serviciu Web se cere clientilor de a
face multe metode de invocare pentru a reusi sa isi atinga telul). Acest
concept este sustinut de modul de lucru orientat obiect care acompaniaza
un set de servicii pentru a forma un proces mult mai complex. Pentru a pune
URI-uri legate de un set de servicii care nu vor mai fi prezente intr-un
browser care urmeaza sa fie agregate pentru refolosire nu are prea mult sens. Chiar
daca servicii de web nu ar fi existat, unii ar accepta sa nu foloseasca
REST pentru acest scop. Este de cele mai multe ori dorit sa se foloseasca SOAP pentru
a simplifica gestionarea si securitatea tranzactiei. Unele dintre
cele mai complexe WS-* standarde sunt acum incluse in unelte, cu multe posibilitati
de dezvoltare.
** ** ** ** ** ** **********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):
publicare: inregistrarea (sau promovarea) serviciului de catre furnizorul serviciului in registrul de servicii
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
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:
se bazeaza pe tehnologii XML
este independenta de protocoalele de transport
(HTTP, SMTP)
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)
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:
Servicii de manipulare a mesajelor
suport pentru diferite tipuri de mesaje
livrarea mesajelor
rutarea mesajelor
Servicii de management
monitoarizarea performantelor
supraveghere
Servicii de interfata
ofera suport pentru standarde
ofera solutii pentru interfetele nestandard
Servicii de mediere
transformarea mesajelor dintr-un format in altul
Servicii de securitate
criptare/decriptare
autentificare
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:
Utilizand SOAP cu HTTP este permisa comunicatia mai buna in spatele unui proxy sau firewall decat presupunea precedenta tehnologie de apel la distanta.
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:
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.
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.
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:
In WSDL, clasa soap_client a NuSOAP va encoda tipul valorilor corespunzator tipului specificat in documentul WSDL.
Clasa soapval din NuSOAP permite utilizatorilor sa defineasca explicit tipul valorii
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:
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.
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 dinamic si bazat pe cereri explicite de servicii.
Transpunerea in realitate a idealului ca oamenii controleze direct logica aplicatiei 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:
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
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 aplicatie, care impacheteaza functionalitatea multor apeluri API intr-un numar mic de mesaje.
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 granulate brut care au flexibilitatea si receptivitatea pentru a sustine prioritatile aplicatiei 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:
relatii de partajare foarte flexibile, de la client-server pana la peer to peer
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
partajarea unor resurse variate ca: programe, fisiere, date, calculatoare, senzori, retele, s.a
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 din lumea reala. O magistrala ESB eficienta furnizeaza mecanisme prin care utilizatorii pot manipula componente la nivelul modelului aplicatiei pentru a defini si rula procese declansate de evenimente, raspuns in timp real al schimbarilor aplicatiei. 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 destinate definirii proceselor complexe, 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 granulate brut combinate cu extensibilitatea, toleranta la defect intr-o arhitectura distribuita care permite proceselor 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.
Iata deci propunera cu privire la implementarea SOA, propunere survenita in urma prezentarilor din 8 septembrie 2005 pentru a se pune bazele unui nou stil arhitectural puternic propus si sustinut de IBM.
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.
Cea mai buna solutie este proiectarea componentelor avand in minte arhitectura distribuita, dar ele trebuie distribuite pe calculatoare diferite numai cand este necesar.
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.
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:
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.
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.
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.
Partajarea conexiunilor - permite unei aplicatii sa foloseasca conexiuni deja create, de exemplu la un server de baze de date.
Partajarea componentelor - presupune utilizarea de componente deja create, componente fara stare, aflate la un nivel intermediar al aplicatiei distribuite.
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:
Serviciul asteptat - serviciile aplicatiei trebuie sa corespunda asteptarilor clientilor sau utilizatorilor.
Garantarea comportamentului - trebuie sa existe o modalitate de garantare a functionarii operatiilor critice ale aplicatiei.
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.
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.
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.
|
Politica de confidentialitate |
 .com |
Copyright ©
2024 - Toate drepturile rezervate. Toate documentele au caracter informativ cu scop educational. |
Personaje din literatura |
| Baltagul – caracterizarea personajelor |
| Caracterizare Alexandru Lapusneanul |
| Caracterizarea lui Gavilescu |
| Caracterizarea personajelor negative din basmul |
Tehnica si mecanica |
| Cuplaje - definitii. notatii. exemple. repere istorice. |
| Actionare macara |
| Reprezentarea si cotarea filetelor |
Geografie |
| Turismul pe terra |
| Vulcanii Și mediul |
| Padurile pe terra si industrializarea lemnului |
| Termeni si conditii |
| Contact |
| Creeaza si tu |
