Lucrarea este total incompleta.
Toate cele 50 de pagini care le ai pina acum sa le transformi in 20 de pagini. Ti-am mai zis asta odata. Este absolut inutil sa spui ce inseamna HTTP, ce inseamna XML. Doar cite o fraza doua la fiecare.
Nu am vazut nimic legat de aplicatia ta, dar absolut nimic.
Rescrie lucrarea cit mai rapid posibil.
CUPRINS
Motivatie ?? Introducere
Arhitectura software bazata pe servicii este din ce in ce mai larg acceptata si utilizata. Soa poate rezolva probleme dintr-o gama larga fiind utilizata la nivel de www si are posibilitati de expansiune si evolutie ridicate.
Scopul aplicatiei este dat de faptul ca implementare unei arhitecturi de tip soa este dificila si standardele implementarii sunt volatile fiind in centrul cercetarii companiilor mari.
Cea mai puternica echipa si primii care s-au preocupat de acest domeniu, temerarii acestui nou stil arhitectural au fost cei de la IBM. Lucrarea propune o metoda de implemantare a unei astfel de arhitecturi.
Aplicatia isi propune implementare sub forma modularizata cu module independente dintr-o arhitectura de tip soa, evidentind astfel beneficiile aduse de arhitectura Soa in cadrul tehnologilor web (aplicatii reutilizabile si usor extensibile)
SOA 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. SOA este deseori vazuta ca o evolutie a programarii distribuite si a programarii modulare.
Aplicatia presupune o demonstratie exemplificata printr-un singur serviciu web care este modularizat pentru a putea procesa in paralel rezultatul care va fi furnizat.
// e o prostie asta cu un serviciu Web
Asfel fiecare modul va contribui la rezultatul final desi va fi independent de acesta. Aplicatia va fi modularizata pe un serviciu web care va oferi alternative pentru petrecerea vacantelor fiind supusa unor anumite conditii.
A. INTRODUCERE ?? Situatia actuala sau Contextul actual sau.
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. 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 Solutia: "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
Sa ascunda dezvoltatorului detaliile de sistem
Ce sunt serviciile Web?
Aplicatii
Utilizate de alte aplicatii (la distanta)
Accesate standardizat via Web
URI, HTTP, XML
Traditional, o aplicatie Web expune o interfata-utilizator
Cererile erau capt(
Utilizatorii umani trebuie sa sa interpreteze etichetele si cimpurile de dialog
Utilizatorii umani trebuie sa sa interpreteze raspunsul oferit de serviciu
Serviciile Web fac explicite specificatiile implicite!
Caracteristici:
Utilizate la interactiunea intre masini
Dinamicitatea
Lipsa unei cunoasteri a-priori a interactiunii cu alte aplicatii si/sau servicii Web
Sunt independente de sistem, platforma si limbaj de programare
Puncte terminale utilizate pentru procesarea datelor , in maniera publica
Abilitatea de a prelucra orice tip de date
Dezvoltate pe baza platformelor , arhitecturilor si limbajelor curente
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:
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.
 |
Tehnologii (bazate pe pe XML):
Descrierea unui serviciu (interfata)
WSDL ( Web Service Description Language
Protocol de comunicare via mesaje
SOAP
Descoperirea serviciilor Web
UDDI ( Universal Description, Discovery, and Integration)
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.
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:
Transferul datelor in combinatie cu o cerere pentru o resursa (HTTP-metoda 'GET')
Transferul datelor in combinatie cu o cerere speciala (HTTP-metoda 'POST')
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:
. 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.
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:
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.
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 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.
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 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> 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.
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.
Daca vrei sa intelegi detaliile si motivatiile din spatele REST-ului downloadeaza si uita-te pe urmatoarea adresa www.ics.uci.edu/~fielding/pubs/dissertation/top.htm .
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.
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. Mesageria aduce o alta problema in ceea ce
priveste REST in interiorul firewall. 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.
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.
Format pentru trimiterea de mesaje bazat pe XML
Protocol de comunicare intre aplicatii (via Internet)
Independent de platforma sau limbaj
Simplu si extensibil: envelope, header, body,fault
Permite evitarea firewall-urilor
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):
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.
PHP este un limbaj de programare destinat in primul rand Internetului, aducand dinamica unei pagini de web. Este unul din cele mai importante limbaje de programare web open-source si server-side. Numele PHP provine din limba engleza si este un acronim recursiv : Php: Hypertext Preprocessor. Exemple faimoase de utilizare a acestui limbaj sunt PhpBB (forum), PhpNuke(CMS), chiar si MediaWiki, software-ul din spatele Wikipedia. Folosirea PHP poate fi vazuta ca o alternativa gratuita la utilizarea unor limbaje comerciale cum sunt ASP de la Microsoft, ColdFusion de la Macromedia, sau chiar JSP de la Sun Microsystems.
Istoric
PHP a fost inceput in 1994 ca o extensie a limbajului server-side Perl, si apoi de o serie de CGI-uri compilate de catre Rasmus Lerdorf, pentru a genera un curriculum vitae si pentru a urmari numarul de vizitatori ai unui site. Apoi a evoluat in PHP/FI 2.0, dar proiectul open-source a inceput sa ia amploare dupa ce Zeev Suraski si Andi Gutmans, de la Technion au lansat o noua versiune a interpretorului PHP in vara anului 1998, aceasta versiune primind numele de PHP 3.0. Tot ei au schimbat si numele in acronimul recursiv de acum, pana atunci PHP fiind cunoscut ca Personal Home Page Tools. Apoi Suraski si Gutmans au rescris baza limbajului, producand astfel si Zend Engine in 1999. In mai 2000 a fost lansat PHP 4.0, avand la baza Zend Engine 1.0.
PHP 5
Pe 13 iulie 2004 a fost lansat PHP 5, cu Zend Engine II, ce a adus si o orientare obiect mai pronuntata si suportand mai multe caracteristici ale acestui tip de programare.
PHP 5 aduce mai multe noutati fata de versiunea 4:
Suport imbunatatit pentru OOP
Introduce extensia PDO - PHP Data Objects, care defineste o modalitate facila si consistenta de accesare a diferitelor baze de date
Imbunatatiri de performanta
Suport imbunatatit pentru MySQL si MSSQL
Suport nativ pentru SQLite
Suport SOAP integrat
Iteratori pentru date
Control de erori prin tratarea de exceptii
La sfarsitul lui 2007 doar versiunea 5.x mai era intretinuta, deoarece in data de 13 iulie 2007 (exact la 3 ani dupa lansarea PHP5), PHP Group a anuntat ca PHP4 va fi scos din uz pe 31 decembrie 2007, desi prognozeaza ca anumite upgrade-uri de securitate se vor oferi pana pe 8 august 2008. Dezvoltarea la PHP 6 incepuse deja in decembrie 2007 si urmeaza sa fie oferit odata cu scoaterea din uz a PHP4.
PHP 6 are urmatoarea agenda de imbunatatiri:
suport pentru Unicode
scoaterea definitiva a unor functii ca register_globals sau magic_quotes
retragerea definitiva a variabilelor tip $HTTP_*_VARS
Popularitate
PHP-ul este unul din cele mai folosite limbaje de programare server-side, conform unui studiu efectuat de Netcraft in aprilie 2002, aparand pe 9 din cele 37 milioane de domenii cercetate in studiu. De asemenea, exista un grafic al cresterii folosirii PHP-ului pe site-ul oficial. Popularitatea de care se bucura acest limbaj de programare se datoreaza urmatoarelor caracteristici :
Familiaritatea : sintaxa limbajului este foarte usoara combinand sintaxele unora din cele mai populare limbaje Perl sau C;
Simplitatea : sintaxa limbajului este destul de libera. Nu este nevoie de includere de biblioteci sau de directive de compilare, codul PHP inclus intr-un document executandu-se intre marcajele speciale;
Eficienta : PHP-ul se foloseste de mecanisme de alocare a resurselor, foarte necesare unui mediu multiutilizator, asa cum este web-ul;
Securitatea : PHP-ul pune la dispozitia programatorului un set flexibil si eficient de masuri de siguranta;
Flexibilitatea : fiind aparut din necesitatea dezvoltarii web-ului, PHP a fost modularizat pentru a tine pasul cu dezvoltarea diferitelor tehnologii. Nefiind legat de un anumit server web, PHP-ul a fost integrat pentru numeroasele servere web existente: Apache, IIS, Zeus, server, etc.;
Gratuitatea : este probabil cea mai importanta caracteristica a PHP-ului. Dezvoltarea PHP-ului sub licenta open-source a determinat adaptarea rapida a PHP-ului la nevoile web-ului, eficientizarea si securizarea codului.
Utilizare
PHP este simplu de utilizat, fiind un limbaj de programare structurat, ca si C-ul, Perl-ul sau incepand de la versiunea 5 chiar Java, sintaxa limbajului fiind o combinatie a celor trei. Datorita modularitatii sale poate fi folosit si pentru a dezvolta aplicatii de sine statatorare, de exemplu in combinatie cu PHP-GTK sau poate fi folosit ca Perl sau Python in linia de comanda. Probabil una din cele mai importante facilitati ale limbajului este conlucrarea cu majoritatea bazelor de date relationale, de la MySQL si pana la Oracle, trecand prin MS Sql Server, PostgreSQL, sau DB2.
PHP poate rula pe majoritatea sistemelor de operare, de la UNIX, Linux, Windows, sau Mac OS X si poate interactiona cu majoritatea servereler web. Codul dumneavoastra PHP este interpretat de serverul WEB si genereaza un cod HTML care va fi vazut de utilizator (clientului -browserului- fiindu-i transmis numai cod HTML).
Suport
PHP are un manual oficial intretinut de comunitatea din jurul proiectului. In plus, raspunsurile la multe probleme pot fi gasite printr-o simpla cautare pe internet. Exista multe resurse disponibile pentru un programator PHP incepator.
MySQL
MySQL este un sistem de
gestiune a bazelor de date relational, produs de compania suedeza
Desi este folosit foarte des impreuna cu limbajul de programare PHP, cu MySQL se pot construi aplicatii in orice limbaj major. Exista multe scheme API disponibile pentru MySQL ce permit scrierea aplicatiilor in numeroase limbaje de programare pentru accesarea bazelor de date MySQL, cum are fi: C, C++, C#, Borland Delphi, Java, Perl, PHP, Python, FreeBasic, etc., fiecare dintre acestea folosind un tip spefic API. O interfata de tip ODBC denumita MyODBC permite altor limbaje de programare ce folosesc aceasta interfata, sa interactioneze cu bazele de date MySQL cum ar fi ASP sau Visual Basic. In sprijinul acestor limbaje de programare, unele companii produc componente de tip COM/COM+ sau .NET (pentru Windows) prin intermediul carora respetivele limbaje sa poata folosi acest SGBD mult mai usor decat prin intermediul sistemului ODBC. Aceste componente pot fi gratuite (ca de exemplu MyVBQL) sau comerciale.
Licenta GNU GPL nu permite incorporarea MySQL in softuri comerciale; cei care doresc sa faca acest lucru pot achizitiona, contra cost, o licenta comerciala de la compania producatoare, MySQL AB.
MySQL este componenta integrata a platformelor LAMP sau WAMP (Linux/Windows-Apache-MySQL-PHP/Perl/Python). Popularitatea sa ca aplicatie web este strans legata de cea a PHP-ului care este adesea combinat cu MySQL si denumit Duo-ul Dinamic. In multe carti de specialitate este precizat faptul ca MySQL este mult mai usor de invatat si folosit decat multe din aplicatiile de gestiune a bazelor de date, ca exemplu comanda de iesire fiind una simpla si evidenta: "exit" sau "quit".
Pentru a administra bazele de date MySQL se poate folosi modul linie de comanda sau, prin descarcare de pe internet, o interfata grafica: MySQL Administrator si MySQL Query Browser. Un alt instrument de management al acestor baze de date este aplicatia gratuita, scrisa in PHP, phpMyAdmin.
MySQL poate fi rulat pe multe dintre platformele software existente: AIX, FreeBSD, GNU/Linux, Mac OS X, NetBSD, Solaris, SunOS, Windows 9x/NT/2000/XP/Vista.
|
