Scrigroup - Documente si articole

     

HomeDocumenteUploadResurseAlte limbi doc
AccessAdobe photoshopAlgoritmiAutocadBaze de dateCC sharp
CalculatoareCorel drawDot netExcelFox proFrontpageHardware
HtmlInternetJavaLinuxMatlabMs dosPascal
PhpPower pointRetele calculatoareSqlTutorialsWebdesignWindows
WordXml


Tehnologii pentru aplicatiile web

webdesign



+ Font mai mare | - Font mai mic



Tehnologii pentru aplicatiile web

Alegerea unei tehnologii adecvate este un factor de succes important in dezvoltarea aplicatiilor web. Pentru a putea utiliza tehnologiile, a observa modul de interactiune dintre ele intr-o arhitectura existenta si implementa aplicatii web este necesara o cunoastere a caracteristicilor acestora. In continuare vom aborda principalele tehnologii, interactiunea si modul de utilizare al acestora in anumite arhitecturi, tinand cont de recomandarile W3C (World Wide Web Consortium).



Dezvoltarea sistemelor software traditionale este procesul proiectarii unui corect "CUM" pentru un bine definit "CE". Padridge (1992)

Din momentul in care am definit cerintele pentru o aplicatie web, am ales o arhitectura si am dezvoltat un mod de proiectare (pe scurt am clarificat "ce"), putem demara faza de implementare (pe scurt "cum"). In acest context, reutilizarea are un rol important in procesul de dezvoltare. Cerintele rezultate pentru implementarea aplicatiilor web incep cu alegerea tehnologiei adecvate. Separarea continutului si a prezentarii si cerintele pentru distribuirea si integrarea altor sisteme, in functie de arhitectura selectata sau existenta, sunt cerinte esentiale pentru o utilizare adecvata a tehnologiilor.

Caracteristicile implementarii tehnologiilor pentru aplicatiile web versus sisteme software traditionale provin din utilizarea standardelor web. Aceasta afecteaza implementarea in trei moduri: cerere (client), raspuns (server) si reguli de comunicare intre cele doua (protocol).

Datorita evolutiei rapide a tehnologiilor bazate pe web este imposibila descrierea tuturor tehnologiilor. Din acest motiv ne vom limita doar la prezentarea anumitor tehnologii. In primul rand vom prezenta cele mai folosite protocoale utilizate pe web, accentul fiind pus pe cel mai important protocol pentru World Wide Web - HTTP (Hypertext Transfer Protocol).

1 Elemente fundamentale

In general, toate paradigmele de programare, aspectele de distribuire, tehnologiile de authoring, etc., pot fi utilizate drept baza pentru implementarea aplicatiilor web. Aceasta reprezinta una din problemele care au condus la dezvoltarea haotica a aplicatiilor web. Aceste dezvoltari rezulta in principal din abordarile ad-hoc sau din schimbarile rapide ale tehnologiei. Din acest motiv ne vom focaliza pe origini: marcare (markup) si hipertext (hypertext). Marcarea reprezinta materializarea incarnarii SGML-ului care a format baza HTML-ului si XML-ului, in timp ce hipertextul descrie conceptul de baza al WWW.

Marcarea

Conceptul de marcare isi are originea in domeniul editorialelor si reprezinta instructiuni tipografice pentru formatarea documentelor. Aceste instructiuni sunt specificate in interiorul unui document sub forma caracterelor aditionale. De exemplu, putem scrie *Salut* pentru a obtine iesirea Salut sau /Salut/ pentru a obtine iesirea Salut. Marcarea semantica ne permite scrierea de comentarii in cadrul textului fara a le afisa in document. ISO defineste urmatoarele clase de marcare:

1. marcare: acesta este textul introdus in document pentru a adauga informatii despre modul in care caracterele si continutul trebuie reprezentat in document;

2. marcare descriptiva: aceasta marcare descrie structura si alte atribute ale documentului, indiferent de modul de procesare al documentului pentru reprezentare (ex: comentarii);

3. instructiuni de procesare. Aceasta marcare consta in date specifice sistemului; controleaza modul in care este procesat un document.

Dezvoltarea SGML (Standard Generalized Markup Language) a fost promovata de companiile US. Cand se utilizeaza SGML, autorii utilizeaza etichete (<tag>) pentru a marca anumite parti text, care au fost anterior definite utilizand SGML (intr-un asa numit DTD - Document Type Definition). In consecinta, SGML este si punctul de pornire pentru anumite marcari specializate, indeosebi HTML si XML.

Hipertext si hipermedia

Pe baza utilizarii marcarii pentru marcarea elementelor singulare, hipertextul este vazut ca o organizare a interconexiunilor unitatilor de informatii singulare. Relatia dintre aceste unitati poate fi exprimata prin legaturi. Conceptul hipertext este fundamental pentru World Wide Web. In timp ce hipertextul desemneaza doar legaturile unitatilor de informatie in versiunea lor text, hipermedia este vazuta ca o modalitate de extindere a principiului hipertext catre obiectele multimedia arbitrare (ex: imagini sau video).

2 Comunicarea client/server pe web

Paradigma client/server care sta la baza aplicatiilor web formeaza coloana vertebrala dintre un utilizator (client sau agent utilizator) si aplicatia reala (server). Acest model de comunicare se bazeaza in principal pe arhitectura pe doua straturi. Oricum, pasii de procesare de pe un server web pot necesita integrarea altor sisteme (ex: baze de date, servere de aplicatii). Arhitecturile pe N-straturi astfel formate sunt in principal bazate pe modelul client/server. De exemplu, un browser web trimite o cerere si aceasta cerere determina un raspuns de la un server web, in timp ce protocoalele (in special HTTP) au un rol esential. Aceste protocoale controleaza modul in care un client ar trebui sa faca o cerere, ce raspuns ii poate returna serverul si cum ar trebui sa realizeze acest lucru.

SMTP - Simple Mail Transfer Protocol

SMTP (Simple Mail Transfer Protocol) (Postel, 1982), combinat cu POP3 (Post Office Protocol) sau IMAP (Internet Message Access Protocol) (Crispin, 2003) permite trimiterea si receptionarea e-mail-urilor. In plus, SMTP este din ce in ce mai mult utilizat ca un protocol de transport pentru schimbul de mesaje asincrone bazate pe SOAP.

RTSP - Real Time Streaming Protocol

RTSP reprezinta un standard publicat de IETF (Internet Engineering Task Force) si a fost proiectat pentru a suporta distribuirea de date multimedia in timp real. Spre deosebire de HTTP, RTSP permite transmiterea resurselor de resurse catre client intr-un mod oportun comparativ cu transmiterea acestuia in intregime (imediata). Acest mod de transmitere este cunoscut sub denumirea de streaming. Streaming-ul permite schimbarea manuala a "perioadei de timp" audio-vizuale prin solicitarea stream-ului la un anumit moment, astfel oferindu-ne posibilitatea de a controla rularea componentei media intr-un mod continuu. De exemplu, putem implementa functii similare celor de pe dispozitivele hi-fi, cum ar fi "pauza", "inainte" sau "inapoi" sau repozitiona rularea componentei media intr-un punct viitor sau trecut.

HTTP - HyperText Transfer Protocol

HTTP a devenit un protocol foarte important in ultimii ani. Proliferarea pe scara larga a standardelor web si posibilitatea de extindere a web-ului a permis HTTP-ului sa devina cel mai popular protocol de transport pentru continutul Web. HTTP este un protocol simplu care controleaza modul in care resursele (ex: documetele HTML sau imaginile) sunt accesate. HTTP este construit pe stiva TCP/IP, unde serviciul este in mod normal disponibil pe portul 80. Resursele sunt adresate prin utilizarea conceptului de URI (Uniform Resource Identifier). URI-urile nu sunt legate de un anumit protocol cum este HTTP; ele reprezinta un mecansim de adresare uniform, care este utilizat de asemenea in HTTP.

URI-ul aloca identificatori unici resurselor, indiferent de tipul acestora (documente HTML, imagini). Cel mai reprezentativ URI este URL (Uniform Resource Locator). URL-urile pot fi utilizate in conexiune cu DNS (Domain Name System) pentru a identifica sistemele gazda pe care se gasesc aceste resurse. Un URI (https://www.feaa.uaic.ro/despre_feaa/index.htm), descrie de obicei trei lucruri: cum este accesata o resursa (ex: https:// daca este utilizat HTTP), calculatorul destinatie (gazda) pe care este localizata resursa (ex: www.feaa.uaic.ro) si numele resursei (ex: despre_feaa/index.htm). In plus, URI-rile definesc delimitatorul interogarii ("?"), care permite HTTP-ului sa transmita parametrii (ex: https://www.feaa.uaic.ro/catedre/in2.asp?codcat=IE). Sintaxa completa a URI-urilor a fost standardizata de IETF in RFC 1630.

Delivery = transmiterea; rendered = interpretare

Mecanismul de livrare al HTTP-ului difera de metoda utilizata in sistemele distribuite orientate obiect. In timp ce valoarea unui apel de functie (de exemplu prin utilizarea RPC-ului), este transmisa odata ce functia a fost procesata in intregime, o cerere HTTP conduce la un stream de date, care este evaluat imediat imediat, chiar daca nu au fost transmise datele in intregime. Aceasta metoda are beneficiul ca paginile web pot fi interpretate imediat, astfel fiind interpretate si afisate mai rapid. Transmiterea imediata de catre un server web si procesarea imediata de catre un client web poate de asemenea poate de asemenea cauza executia unui program intr-o pagina HTML (numita client-side scripting). HTTP a fost standardizat in RFC 1945 si este disponibil in prezent in versiunea 1.1.

Urmarirea sesiunii

Aplicatiile web interactive trebuie sa fie capabile sa distinga cererile de la numerosi utilizatori simultani si sa identifice cererile care vin de la acelasi utilizator.

Termenul sesiune este utilizat pentru a defini o astfel de secventa a cererilor HTTP dintre un anumit utilizator si un server intr-o anumita perioada de timp. Deoarece HTTP este un protocol simplu, serverul web nu poate aloca automat cererile venite pentru o sesiune. Distingem doua metode principale care permit serverului web sa aloce automat o cerere venita pentru o sesiune:

- in fiecare din aceste cereri catre server, clientul insusi se identifica intr-un mod unic. Aceasta inseamna ca toate datele trimise catre server sunt alocate ulterior sesiunii respective;

- toate datele schimbate intre un client si un server sunt incluse in fiecare cerere pe care un client o trimite unui server.

In majoritatea cazurilor, este de dorit sa lasam datele logicii aplicatiei pe server, astfel incat logica aplicatiei sa nu fie atat de simpla. De obicei, este implementat un mecanism de urmarire a sesiunilor prin rescrierea URL-ului sau cookies.

Rescrierea URL-ului

Rescrierea URL-ului este un mecanism care transmite datele relevante ale sesiunii ca un parametru in URL. Datele transmise pot apoi fi utilizate pentru a reconstrui sesiunea de pe server. Din nefericire, acest mecanism are anumite lipsuri:

- daca un volum mare de date este necesar intr-o sesiune, atunci URL-ul poate deveni cu usurinta dezordonat si purtator de erori. Din momentul in care aplicatiile web tind sa devina complexe, cerintele pentru volumul de date care trebuie stocat intr-o sesiune poate de asemenea creste;

- limitarea lungimii unui URL poate determina ca acest mecanism sa devina instabil pe anumite sisteme;

- obstacolul principal este ca URL-urile codificate in paginile HTML trebuie sa fie adaptate dinamic pentru fiecare sesiune; de exemplu pentru a codifica o sesiune intr-un ID de sesiune dintr-un URL. Aceasta inseamna ca paginile sau legaturile din aplicatie trebuie sa fie generate dinamic pentru fiecare cerere. Putem folosi cookies pentru a rezolva elegant aceasta problema.

Cookies

Cookies sunt fisiere text mici folosite pentru a stoca informatia de pe server (ex: ID-ul unei sesiuni) pe sistemul clientului. Aceasta informatie este scrisa intr-un fisier text sub forma perechilor nume-valoare. Cookies sunt generate de catre serverul web si transmise clientului in antetul raspunsului HTTP. Browser-ul web al clientului stocheaza un cookie pe sistemul clientului si va utiliza intotdeauna acel cookie pentru a transmite serverului ce a generat cookie la fiecare cerere. Cookies sunt clasificate in: "sesiune" sau "permanente". In timp ce cookie-urile permanente raman stocate pe calculatorul clientului (stocate pe hard disk), cookie-urile sesiune sunt doar pastrate pana cand situl este parasit sau browser-ul este inchis. Aceasta inseamna ca serverul poate identifica cererile de la anumit client si sa le aloce unei sesiuni. Cookies pot include si data expirarii; odata ce data expira, browser-ul client nu va trimite cookie-ul catre server.

Principalul beneficiu al cookies-urilor este ca informatia care identifica o sesiune poate fi schimbata in mod transparent intre un client si un server. Ele pot fi utilizate pentru a implementa cu usurinta urmarirea sesiunilor si nu necesita un efort sporit deoarece doar ID-ul sesiunii generate de server trebuie transmis.

Principalul dezavantaj al cookies-urilor este ca anumiti utilizatori dezactiveaza functionalitatea cookie in browsere pentru a preveni schimbarea comportamentului browserului.

Scenarii de utilizare

Care din cele doua mecanisme discutate anterior este cel mai potrivit pentru aplicatiile web depinde in principal de circumstante. In mod ideal, este de dorit sa lasam informatiile despre sesiune pe partea de server si sa utilizam un ID de sesiune cat mai sigur. Aceasta metoda poate fi combinata: utilizand cookies pentru a stoca ID-ul sesiunii si rescrierea URL-ului pentru browserele care nu accepta cookies. Un exemplu de codificare pentru ID-ul unei sesiuni intr-un URL este: https://host/application/page.ext?SessionId=XYZ sau https://host/application/XYZ/page.ext, unde XYZ reprezinta o cheie unica pentru sesiune, greu de ghicit.

Tehnologiile server actuale (PHP, JSP, ASP.NET) ofera API-uri pentru utilizarea mecanismului descris anterior. Acest API ascunde complexitatea sesiunii, facilitand generarea ID-urilor de sesiune si oferind metode dedicate pentru stocarea informatiilor despre sesiune.

3 Tehnologii client-side

Ajutoare si plug-inuri

Programele de ajutor sunt aplicatii care adauga functionalitati browserelor web. In momentul in care browserul receptioneaza un tip de media inclus in lista de ajutoare sau plug-inuri, tipul respectiv este trimis unui program extern specificat in lista pentru o procesare ulterioara. Exemple de aplicatii de ajutor sunt WinZip si Acrobat Reader. Un program de ajutor trebuie instalat de catre utilizator pe calculatorul clientului. Programul de ajutor este apoi invocat la tipul corespunzator de MIME. Orice program poate deveni un ajutor. Dezavantajul ajutoarelor consta in comunicarea avansata cu browserele. Plug-inurile pot rezolva aceasta problema. Un plug-in este un program de ajutor instalat permanent in browser pentru optimizarea comunicarii.

Applet-uri Java

Applet-urile Java sunt programe scrise in Java care sunt incarcate dinamic in browser. Ele ruleaza intr-un "sandbox", astfel impiedicand accesul direct al resurselor sistem de pe client; uneori permit accesarea resurselor dupa verificarea politicii de securitate. Applet-urile sunt incarcate de un server web si executate intr-un browser intr-un mediu de lucru numit JVM (Java Virtual Machine). Applet-urile nu sunt stocate in mod persistent pe un sistem. Spre deosebire de controalele ActiveX, applet-urile sunt compilate intr-un sistem independent, ceea ce le permite sa ruleze pe toate platformele care dispun de JVM.

Controale ActiveX

Prin controalele ActiveX Microsoft a permis utilizarea componentei COM in browserele web. Controalele ActiveX sunt componente standard COM proiectate pentru a oferi un anumit set de interfete (interfete COM). Un browser web poate incarca o astfel de componenta de pe un server web, instantia via COM si apoi utiliza funtionalitatea acelei componente. Spre deosebire de applet-urile Java, controalele ActiveX sunt compilate in cod binar, care ofera o performanta deosebita. Controalele ActiveX sunt stocate intr-un director de cache special al browser-ului, prin apelarile ulterioare functionalitatea respectiva fiind deja disponibila. In plus, controalele ActiveX au aceleasi posibilitati ca plug-in sau ajutor; ele pot accesa toate zonele sistem si functiile pe care utilizatorul le detine pe sistemul respectiv (acesta este un risc de securitate). Microsoft a dezvoltat o metoda care permit distribuitorilor de controale ActiveX sa utilizeze o metoda criptografica pentru a semna aceste componente. Cand controalele ActiveX sunt incarcate in browser, certificatul distribuitorului va fi afisat; utilizatorul va decide daca este de acord sa ruleze un program in functie de increderea pe care o prezinta compania producatoare. Un alt beneficiu al controalelor ActiveX este ca componentele pot fi dezvoltate intr-un limbaj arbitrar: Java, Visual Basic si C++, atat timp cat necesitatile compilatorului pentru limbajul respectiv indeplineste cerintele specificatiilor COM.

4 Tehnologii specifice documentului

HTML - Hypertext Markup Language

HTML este o aplicatiei SGML care descrie elementele care pot fi utilizate pentru a marca continutul intr-un document hipertext si modul in care aceste elemente sunt in legatura intr-un DTD (Document Type Definition). Elementele de marcare sunt inchise intre simbolurile "<" si ">". HTML defineste un set mare de etichete pentru a indica semantici diferite. De exemplu, eticheta <H1> poate fi folosita pentru a marca titlurile de nivel 1.

Etichetele sunt folosite pentru structurarea logica a documentului. De exemplu, elementul de marcare <strong> specifica faptul ca partea din document dintre aceste perechi de etichete trebuie interpretate sub forma unei evidentieri logice, pe care browserele le afiseaza in mod normal cu aldine. Datorita posibilitatilor limitate ale proiectarii grafice, au fost introduse elementele suplimentare pentru a permite proiectantilor sa influenteze in mod direct layout-ul documentului. De exemplu, elementul de marcare <b> poate fi folosit pentru a instrui browserul sa reprezinte o parte din document cu aldine. Oricum, semantica marcarii este pierduta. Datorita multitudinii de posibilitati de a influenta layout-ul, nu este surprinzator ca majoritatea resurselor HTML neglijeaza utilizarea elementelor de marcare logice/semantice. Aceasta face mult mai dificila interpretarea informatiilor pentru masini. Situatia este mult mai critica deoarece informatia poate fi, intr-un anumit mod, usor convertita in alte formate (de exemplu pentru a o face utilizabila pe dispozitive cum sunt telefoanele mobile). Simplitatea in crearea si procesarea resurselor HTML (ele sunt simple fisiere text) este o proprietate foarte importanta pentru caracterul omniprezent al informatiei pe Web, aceasta fiind impiedicata de aspectul prezentarii. Introducerea noilor elemente de marcare a fost facilitata indeosebi de faptul ca browserele resping sau ignora elementele de marcare pe care nu le cunosc. Aceasta flexibilitate a fost utilizata in mod repetat de producatorii de browsere pentru a extinde optiunile de layout, care au condus la noi standarde, dar si la reprezentari "incompatibile".

Aceste probleme au incurajat introducerea unui numar mare de extensii. De exemplu, CSS (Cascading Style Sheets) reprezinta un mecanism simplu pentru adaugarea informatiilor de stil (cum sunt fonturile si culorile) la documentele Web. Impreuna cu introducerea XHTML-ului, un dialect XML, a devenit posibila utilizarea beneficiilor XML-ului ca un limbaj "curat" pentru descrierea documentelor HTML.

SVG - Scalable Vector Graphics

Formatul imagine SVG (W3C, 2001a) permite descrierea imaginilor bidimensionale in XML. SVG recunoaste trei tipuri de obiecte grafice: imagini vectoriale care constau in linii si curbe, imagini si text. Obiectele grafice pot fi grupate si integrate in alte obiecte.

SVG suporta interactiuni bazate pe evenimente (ex: raspunsuri la miscarea mouse-ului sau apasarea unui buton). De exemplu, un astfel de raspuns poate fi marirea unei imagini. In plus, este posibila definirea unui cursor special pentru interactivitatea cu utilizatorul. SVG suporta toate tipurile de animatii, oferind un numar mare de functii, inclusiv cele de mutare a unui obiect grafic de-a lungul unei cai pre-definite. Datorita acestor proprietati, acest format este adecvat pentru toate toate tipurile de grafice vectoriale interactive si animate. Exemple de astfel de aplicatii includ reprezentarile CAD, hartile si rutele.

SMIL - Syncronized Multimedia Integration Language

SMIL (W3C, 2001a) este acronimul pentru Syncronized Multimedia Integration Language si a fost dezvoltat de W3C pentru a reprezenta prezentarile multimedia sincronizate. SMIL permite coordonarea prezentarii diferitelor media, cum ar fi audio, video, text si imagini. De exemplu, SMIL ne permite sa definim exact cand o fraza ar trebui rostita si ce imagine sau text ar trebui sa apara in paralel. Fiecare mediu poate fi adresat direct si putem specifica locatia si perioada reprezentarii.

Perioadele de start si final pentru fiecare mediu pot fi sincronizate relativ usor cu cele ale altor medii. Trasaturile de control standard permit utilizatorului sa interactioneze cu SMIL fiind posibile oprirea, pauza, derularea inainte sau inapoi a intregii prezentari. Functiile suplimentare includ generatoarele aleatorii, rularea cu incetinitorul si perioada de timp trecuta. Pe parcursul prezentarii, utilizatorul poate selecta legaturi pentru a naviga catre alte pagini web.

SMIL include in versiunea sa prezenta functii pentru animatii, controlul prezentarii continutului, legaturi, integrarea diferitelor tipuri de media, coordonare si sincronizare, controlul timpului si efecte de tranzitie.

XML - eXtensible Markup Language

XML (eXtensible Markup Language) este un dialect extrem de simplu al SGML-ului. Obiectivul este de a permite SGML-ului generic sa fie deservit, receptionat si procesat pe web intr-un mod posibil acum cu HTML. Din acest motiv, XML a fost proiectat pentru a usura implementarea si pentru interoperabilitate cu SGML si HTML (W3C Working Draft, November 1996).

Pe baza recomandarilor W3C, XML (eXtensible Markup Language, W3C, 1998) a cunoscut un real progres datorita utilizarii si profilerarii acestuia in cadrul si in afara Web-ului. Datorita capacitatii de a defini intr-un mod extrem de simplu, formate de date flexibile si de a schimba aceste formate pe Web, XML ofera premisa pentru pentru a omogeniza mediile eterogene. Aceasta inseamna ca, pe langa descrierea uniforma a formatelor de date, vom lua in considerare semanticile acestor date, indiferent de informatie. Capacitatea de extindere provine din faptul ca, spre deosebire de HTML, XML nu "dicteaza" o marcare predefinita cu semantici implicite; ne permite definirea flexibila a sensului semanticilor si a structurii unui document XML, acesta putand astfel fi adaptat in anumite circumstante. Acesta este motivul pentru care XML, in loc de a fi o alternativa la HTML, deschide noi moduri de a descrie datele in diverse scopuri.

Documentele XML sunt caracterizate prin doua proprietati distincte: sunt bine structurate si sunt valide. Buna structurare este in mod inerent ancorata in XML, in timp ce validitatea este asigurata de DTD (Document Type Definition) si prin schema XML. Pentru a ne asigura ca un document XML este bine structurat, exista reguli generale pentru sintaxa documentelor XML, care (spre deosebire de HTML) trebuie observate intocmai. In realitate, specificatiile XML abordeaza aceste reguli sub forma "constrangerilor". Tabelul 1 foloseste anumite exemple pentru a demonstra regulile pentru o buna structurare a XML-ului.

Descriere

Gresit

Corect

Toate etichetele trebuie sa apara in pereche pe acelasi nivel de imbricare. In plus, pot apare etichete goale (<B/>

<A><B></A></B>

<A><B></B></A> sau <A><B/></A> 

Etichetele sunt sensibile la majuscule si minuscule

<A></a>

<A></A>

Toate atributele trebuie inchise intre ghilimele

<A elem = 5/>

<A elem = "5"/>

Spre deosebire de HTML, nu exista atribute fara valori

<td>

<td style = "white-space:nowrap"

Numele de etichete trebuie sa respecte regulile pentru numirea elementelor. De exemplu, elementele goale si < sau > sunt invalide

<A B> </A B>

<AB></AB>

Tabelul 1 Reguli pentru o buna structurare a XML-ului

Deoarece aceste reguli trebuie strict observate, este posibila o stabilire clara a structurii documentelor XML. Aceasta a condus la definirea DOM (Document Object Model), care poate fi utilizata pentru a transforma structura arborescenta a documentelor XML intr-un arbore orientat-obiect. Figura 1 ilustreaza o comanda sub forma unui simplu exemplu de document XML. Vom utiliza acest exemplu drept baza pentru alte exemple din sectiunile urmatoare:

<?xml version='1.0'?>

<order OrderID='10643'>

<item><book isbn='123-321' /></item>

<item><cdrom title='Vivaldi Four Seasons' /></item>

<item><book isbn='3-8265-8059-1' /></item>

<OrderDate ts='2003-06-30T00:00:00' />

<price>167.00 EUR</price>

</order>

Figura 1 Exemplu in XML al unei comenzi

Namespace-urile

Namespace-urile sunt caracteristici esentiale ale manipularii XML-ului. Namespace-urile pot fi folosite pentru a evita conflictele de nume printr-o numire uniforma a elementelor dintr-un document XML. Aceasta permite documentelor ce apartin diferitelor structuri sa fie unite.

Exista doua moduri diferite de marca un element XML prin namespace-uri: prin specificarea namespace-ului pentru un element sau prin utilizarea unui prefix. Metoda utilizarii unui prefix este utila atunci cand diferite elemente apartin aceluiasi namespace, deoarece face documentele XML mai scurte si mai usor de citit. Figura 2 utilizeaza exemplul anterior pentru a ilustra cele doua variante. URI-ul (uri:order) adreseaza un namespace ce corespunde unei comenzi.

<order xmlns="uri:order">  <o:order xmlns:o="uri:order">

<item>  <o:item>

<book xmlns="uri:order" isbn="123-456" /> <o:book / >

</item> </o:item>

</order> </o:order>

Figura 2 Utilizarea unui namespace fara si cu un prefix

XML DOM

DOM (Document Object Model) foloseste o abordare orientata-obiect asupra documentelor XML, permitand o procesare usoara si intuitiva a XML-ului. DOM este creat de un parser XML care parseaza (analizeaza) structura unui document XML si instantiaza un arbore obiect (vezi Figura 3). Fiecare element XML din acest arbore corespunde unui nod. Beneficiul acestei metode este accesarea nodurilor intr-o maniera orientata-obiect, odata ce DOM a fost creat. Dezavantajul acestei metode consta in faptul ca este costisitoare, deoarece este nevoie de un parser XML pentru a crea arborele. De exemplu, deseori vom dori sa citim parti ale unui document XML in loc de intregul document; in aceste cazuri, este recomandat sa utilizam parsere care sunt mai putin consumatoare de resurse (ex: parsere SAX - Simple API for XML). Parserele SAX utilizeza un model bazat pe evenimente, care suporta interventia tintei in procesul de parsare. Parserele SAX sunt disponibile pentru majoritatea platformelor si limbajelor de programare.

<order>

<OrderDate ts ="2003-06-30" />

<price>30.00 EUR</price>

</order>

 


Figura 3 Structura DOM pentru un fragment al exemplului in XML de comanda

Constrangeri privind validitatea XML-ului

In timp ce constrangerea privind buna structurare, definita in specificatiile XML, asigura o sintaxa clara pentru documentele XML, validitatea ne permite introducerea unei structuri in mod specific pentru un document XML. Un document XML este valid atunci cand este corect construit si cand continutul si structura acestuia sunt conforme cu regulile predefinite. Aceste reguli sunt formulate fie in DTD-uri (Document Type Definitions) sau in schemele XML. In termenii orientarii obiect, aceasta semnifica faptul ca o buna structurare ne permite maparea XML-ului la DOM, in timp ce validitatea ne permite introducerea tipurilor de date specifice aplicatiei.

DTD (Document Type Definition)

Un DTD reprezinta un set de reguli care pot fi utilizate pentru a descrie structura unui document XML. XML a imprumutat DTD-urile din SGML. Figura 4 reprezinta un DTD care valideaza exemplul XML al comenzii. Fragmentele !DOCTYPE, !ELEMENT si !ATTLIST descriu tipul de data. Modul in care elementele sunt legate ne aminteste de modul de definire a expresiilor regulate. Regula <!ELEMENT order (item+,OrderDate,price)> specifica ca un element comanda (order) consta in cel putin un articol ("+"), urmat de o data a comenzii (OrderDate) si un pret (price).

<?xml version='1.0'?>

<!DOCTYPE order [

<!ELEMENT order (item+,OrderDate,price)>

<!ATTLIST order OrderID ID #REQUIRED>

<!ELEMENT item (book,cdrom)+>

<!ELEMENT book EMPTY>

<!ATTLIST book isbn CDATA #REQUIRED>

<!ELEMENT cdrom EMPTY>

<!ATTLIST cdrom title CDATA #REQUIRED>

<!ELEMENT OrderDate EMPTY>

<!ATTLIST OrderDate ts CDATA '2003-06-30T00:00:00'>

<!ELEMENT price (#PCDATA)>

]>

Figura 4 DTD-ul pentru exemplul XML al comenzii

Datorita structurii lor simple, DTD-urile sunt relativ usor de inteles de oameni. Acesta este motivul pentru care ele sunt utile in principal cand au fost create sau intretinute manual. Datorita structurii simple, DTD-urile determina doua probleme distincte, care sunt solutionate prin schemele XML:

- faptul ca DTD-urile au imprumutat din SGML este deseori considerata o problema, deoarece solicita un parser DTD care sa citeasca gramatica. Exemplul nostru demonstreaza ca un DTD nu reprezinta un XML corect construit;

- desi unele tipuri de date pot fi utilizate pentru a defini elementele sau atributele din cadrul DTD-urilor, intinderea acestora este foarte limitata. Aceasta restrictie impiedica reutilizarea DTD-urilor.

Schemele XML

Schemele XML (W3C, 2000) sunt proiectate pentru a raspunde problemelor introduse prin DTD-uri. Principalele lor beneficii (integrarea tipurilor de date, reutilizarea si formularea XML) vin cu pretul cresterii complexitatii. Rezultatul este ca, atunci cand dezvoltam schemele, a devenit aproape inevitabila utilizarea instrumentelor. Datorita complexitatii acestora, in continuare vom discuta schema in mod concis pentru a sublinia proprietatile si conceptele lor mai importante.

O schema XML poate fi utilizata pentru a descrie tipuri de date pre-definite, cum ar fi string, byte, decimal sau date. In plus, acestea ne permit definirea fatetelor care suporta tipuri de date definite de utilizatori similar template-urilor. Sa presupunem ca toate atributele ISBN valide ale unui element XML numit book, din exemplul cu comanda, trebuie sa urmeze notatia pentru numerele ISBN. Putem utiliza o fateta pentru a descrie combinatia de numere si linii (-) din sablonul N -NNNN -NNNN -N si reutiliza aceste tipuri de date in proiectele de dezvoltare viitoare.

Exista doua concepte distincte care pot fi folosite pentru a obtine tipurile de scheme de date pentru tipurile existente: extensia si restrictia. In sensul mostenirii orientate-obiect, restrictia va corespunde specilizarii unei serii de valori ale unui supertip, in timp ce extensia va fi similara agregarii altor tipuri. Figura 5 (partea din stanga) demonstreaza cum este creat tipul LTH (mai mic decat 100) prin restrictionarea tipului pre-definit positiveInteger si setarea limitei superioare pentru seria de valori. In partea dreapta a figurii, tipul definit de utilizator orderType este extins la datedOrderType, care adauga un element, orderDate, al tipului pre-definit date la un orderType.

Figura 5 Tipuri definite de utilizator

XSL - eXtensible Stylesheet Language

XSL (W3C, 1999a) consta in trei parti:

- transformarile XSL;

- XPath si

- XSL-FO.

XSL include un standard pentru transformarea si formatarea XML-ului. XSLT este un limbaj folosit pentru a defini sabloanele si regulile pentru transformarile acestora si reprezinta inima XSL-ului. In timp ce XSL-FO este folosit pentru a defini in mod clar un stil de formatare, acesta reprezinta doar una dintre toate posibilele rezultate pentru transformare XSLT. Din acest motiv, XSL poate fi comparat cu modelul-View-Controller de proiectare a sabloanelor. Modelul corespunde documentelor XML, iar controler-ul corespunde XSLT-ului. View-urile create pot fi de un natura arbitrara (HTML, WML, cHTML, sau din nou XML. Un view predefinit din cadrul suitei XSL pot fi conceput ca un XSL-FO (Formatting Object).

XSLT - eXtensible Stylesheet Language Transformations

Standardul XSLT descrie cum continutul (datele) marcat in XML poate fi transformat. Documente care definesc un program XSLT sunt numite foi de stiluri. Limbajul XSLT definit este un dialect XML. Aceasta inseamna ca XSLT mosteneste toate proprietatile XML, inclusiv costruirea corecta si validitatea. XSLT este descris in namespace-ul (https://www.w3.org/1999/XSL/Transform) definit de W3C, care garanteaza validitatea unei foi de stil XSLT. Rezultatul unei transformari XSL nu este legat de structuri specifice sau dictate sau de restrictii. Aceasta inseamna ca rezultatul unei transformari XSL acopera intregul spectru incepand cu marcarea structurata (XML) pana la interpretarea arbitrara a sirurilor de caractere. Un procesor XSLT lucreaza dupa principiul IPO (Input, Processing, Output). XML sunt date de intrare, in timp ce foaia de stil XSLT realizeaza prelucrarea necesara pentru a genera iesirea. Figura 6 demonstreaza modul in care functioneaza un procesor XSLT.


Figura 6 Abordare schematica a modului in care functioneaza un procesor XSLT

Functionalitatea unei transformari XSLT se bazeaza pe principiul 'potrivirii sablonului'. O foaie de stil reprezinta un set de perechi de sablon-rezultat, similar regulilor de mapare a unui sistem de rescriere a sirurilor (semi-Thue) (sablon → rezultat). Un procesor cauta intrarile (sursa documentelor) sabloanelor, care sunt definite in foaia de stil (sablon), si le inlocuieste cu rezultatul care se potriveste cu sablonul din datele de iesire (documentele rezultat). Rezultatul poate fi vazut ca un sablon care reprezinta un amestec de iesiri si alte elemente ale limbajului XSL.

Comparativ cu limbajele de programare conventionale, precum C sau C #, putem aborda sabloanele ca proceduri, si template-urile drept corpul acestora. Inlocuirea sablonului rezultat initeaza un proces recursiv asupra DOM-ului din intrarea XML. Similar cu procedurile, sabloanele pot fi parametrizate si suporta contextele dintr-o intrare XML. XML Path Language (XPath) este folosit pentru a gasi sabloane. In timp ce XSLT reprezinta o colectie de modele, XPath controleaza modul in care sunt conectate la documentul de intrare XML. Elementele limbajului XSLT pot fi grupate in patru categorii distincte:

- elementele de definire (D): aceste elemente ale limbajului sunt utilizate pentru a defini o foaie de stil XSL (xsl: stylesheet), un model (xsl: template), variabile, parametri, etc

- elementele fluxului de control (C): aceste elemente de limbaj sunt utilizate pentru a manipula control fluxului dintr-un sablon XSLT. De exemplu, putem formula iteratii (xsl: foreach) sau intructiuni conditionale (xsl: if).

- elementele limbajului orientat pe iesiri (O): aceste elemente sunt folosite pentru a genera datele de iesire ale unui sablon XSLT. De exemplu, am putea genera elemente de marcare (xsl: element si xsl: atribut) sau doar text liber.

- elemente privitoare la locatie (L): Aceste elemente sunt utilizate pentru aspecte privitoare la limbi multiple, cum ar fi definitiile locale si formatele (xsl: zecimal-format).

Figura 7 defineste un stil XSLT, care poate transforma "ordinul de cumparare" din exemplul XML prezentat in figura 1. Browserele cu procesoare XSL integrate, cum sunt versiunile curente de Internet Explorer si Netscape Navigator, pot reprezenta un 'ordin de cumparare' cu foaia de stil specificata in HTML. Observam ca avem nevoie sa adaugam un procesor de instructiuni pentru exemplul XML, pentru a specifica locatia foii de stil (vezi figura 8).

<?xml version='1.0'?>

<xsl:stylesheet

xmlns:xsl=https://www.w3.org/1999/XSL/Transform

version='1.0'>

<xsl:template match='/'>

<HTML><HEAD><TITLE>Ordin de cumparare</TITLE></HEAD>

<BODY>

<xsl:apply-templates select='order'/>

</BODY>

</HTML>

</xsl:template>

<xsl:template match='order'>

<table border='1'>

<th colspan='2'>

Ordin de cumparare (<xsl:value-of select='@OrderID'/>)

</th>

<xsl:for-each select='item'>

<xsl:apply-templates select='book' />

</xsl:for-each>

</table>

</xsl:template>

<xsl:template match='book'>

<tr><td>Book</td>

<td><xsl:value-of select='@isbn'/></td></tr>

</xsl:template>

</xsl:stylesheet>

Figura 7 Utilizarea unui stil XSLT pentru exemplul "ordin de cumparare" example.

<?xml-stylesheet type='text/xsl'

href='https://www.order.com/xsl/order.xslt'?>

Figure 8 Integrarea unui stil XSLT intr-un document XML

XPath

XML Path Language (XPath) ofera functionalitatea de a parcurge un document XML. XPath ofera o multitudine de expresii care permit definirea unor cai de cautare ce pot fi folosite intr-un document XML pentru a returna setul de noduri XML. Expresiile XPath sunt evaluate de un procesor XPath, care functioneaza in acelasi mod cu directoarele dintr-un sistem de fisiere. De exemplu, copiii elementelor XML pot fi priviti ca intrari intr-un director din sistemul de fisiere. Figura 9 arata legatura dintre un document XML si interpretarea acestuia ca un sistem de directoare pentru a intelege mai bine conceptul. Pe partea stanga, figura arata cum este utilizata o expresie XPath, in timp ce partea dreapta arata modul in care o expresie locala este utilizata. Nodurile dintre acolade reprezinta rezultatele acestor expresii.

Figura 6-9 Interpretarea unui document XML ca o structura a unui sistem de directoare

Similar cu caile dintr-un sistem de fisiere, putem defini expresii XPath, descriind calea dintr-un document XML. Similar cu sistemul de fisiere, distingem o adresare relativa si una absoluta. XPath ofera o varietate larga de modele de cautare in XML. De exemplu, am putea folosi pe langa elementele XML atribute. Mai mult decat atat, XPath ne permite accesul 'axe', cum sunt, descendentii si stramosii. Aceasta inseamna ca putem sa formulam in mod arbitrar expresii complexe, care pot fi apoi folosite pentru a parcurge documentele XML pe baza DOM-ului.

XSL-FO - eXtensible Stylesheet Language Formatting Objects

XSL-FO reprezinta o definitie a obiectelor de tip media pentru diferite reprezentari. XSL-FO nu este legat exclusiv de elementele media vizuale, cum ar fi ecrane, imprimante, sau documente. De fapt, standardul permite includerea reprezentarilor audio. Proprietatile importante ale 'obiectelor de formatat' se refera la paginare, proprietatile layout-ului (de exemplu, font), sau structurarea obiectelor in functie de orientarea lor si de margini.

Acest standard reprezinta o punte de legatura intre continutul definit intr-un XML media independent si iesirea dependenta de platforma (de exemplu, un document in format PDF). Figura 6-10 utilizeaza doi pasi de prelucrare pentru a demonstra modul de functionare. In primul rand, un procesor XSLT utilizeaza o foaie de stil XSLT pentru a procesa continutul definit in XML. Rezultatul acestui pas de procesare reprezinta o instanta a unui obiect formatat definit in specificatia XSL-FO. Ulterior, printr-un "formatator" sunt utilizate resursele de formatare, cum ar fi imaginile si fonturile, pentru a fi create iesirile media specifice. Iesirile media utilizate in acest exemplu sunt un document PDF, o imprimanta, si un ecran.

Figura 6-10 Imagine schematica a interactiunii dintre XML, XSLT si XSL-FO

XSL reprezinta un instrument puternic pentru a transforma XML. Limbajul XSLT include o multime de transformari, care pot crea iesiri dedicate. Deoarece in mod inerent XSLT actualizeaza modificarile, pentru ca separa de datele/continutul de reprezentarea acestora (transformare), circumstantele utilizarii XSLT-ului sunt similare cu cele care contribuie la selectarea unei arhitecturi.

5 Tehnologii server-side

5.1 Agenti URI

Agentii URI sunt aplicatii speciale utilizate pentru a procesa cererile HTPP si transmite o resursa solicitata. Practic, un URI este utilizat pentru a identifica instanta care proceseaza cererea. Aceasta instanta - manipulatorul URI specializat - preia cererea si o trimite mai departe pentru executie. Rezultatul executiei este returnat apoi serverului Web, care, la randul sau, trimite resursa agentului utilizator.

Server-Side Includes (SSI)

Un SSI reprezinta un mecanism simplu care permite crearea imediata a paginilor HTML compuse din fragmente de text. Acest mecanism este implementat de un pre-procesor pentru paginile HTML, care in mod normal este integrat in serverele web moderne.

O pagina HTML care foloseste SSI este transmisa catre pre-procesor atunci cand un browser Web le solicita. Iesirea pre-procesor-ului este apoi livrat de catre server. Serverul identifica in general astfel de pagini printr-o extensie speciala de fisier (in mod normal, shtml).

Comenzile utilizate pentru a controla pre-procesorul sunt incluse in comentariile SGML si au urmatoare forma:

<!--#atributul comenzii=valoare atribut=valoare -->

Valoarea comenzii specifica tipul comenzii, care este parametrizat de catre o lista atribut-valoare. SSI accepta urmatoarele comenzi:

include: aceasta comanda este inlocuita de continutul unui fisier, specificata fie prin calea catre un fisier sau un URL (prin intermediul unui fisier sau atribut virtual)

exec: acesta este un program la care calea catre fisierul acestuia este specificata de atributul cmd. Este executat sale de productie si inlocuieste comanda. Anumite extensii de SSI (de exemplu, XSSI) includ comenzi suplimentare pentru iesiri text conditionate sau pentru definirea si returnarea variabilelor.

Desi SSI nu mai este folosit pe o scara larga, tehnologia a avut o contributie majora la progresul noilor abordari si asupra metodelor moderne de manipulare a URI-urilor. Cele mai moderne metode de a manipula URI-ri au inlocuit SSI-ul, cu mai multe concepte. Oricum, SSI-ul poate fi folosit indeosebi pentru pagini care sunt, in principal, statice, sau pagini care dispun de mijloace auxiliare de navigare.

CGI/FastCGI

CGI este o interfata standardizata intre serverele web si programele de aplicatii care trimit datele dintr-o cerere HTTP un program al aplicatiei. Programul aplicatiei este specificat prin formarea unui URL sub forma etichetelor de pe pagina HTML apelata. Acest program citeste parametrii din cerere, le proceseaza si creaza o iesire (de obicei un document HTML). Orice limbaj de programare disponibil pe o platforma server poate fi utilizat; de obicei sunt folosite limbaje ca Perl, C, C++ sau Python. O mare lipsa a texhnologiei CGI este scalabilitatea limitata, deoarece pentru fiecare cerere venita trebuie pornit un proces independent. Acest lucru poate determina o depasire considerabila a resurselor, in special atunci cand mai multe cereri concurente trebuie sa fie procesate. Aceasta situatie a condus la introducerea FastCGI, un standard care permite programelor de aplicatii sa deserveasca mai multe cereri in paralel.

Scripting Server-Side

In aceasta sectiune vom prezenta PHP (Hypertext Preprocessor), o solutie open-source care poate fi folosita in locul solutiei ASP (Active Server Pages) oferite de Microsoft. Alte tehnologii reprezentative sunt Cold Fusion si JavaScript Server-Side oferit de Netscape ca o parte a programului LiveWire. Toti agentii URI mentionati definesc un limbaj de scripting. Comenzile acestor limbaje de scripting sunt incluse in resursele HTML si executate pe server de catre un interpretor de scripturi, inainte de livrarea resurselor.

PHP reprezinta o tehnologie open-source si server-side, existand versiuni disponibile pentru majoritatea serverelor web si pentru toate sistemele de operare. Similar cu SSI, instructiuni speciale pentru un pre-procesor sunt adaugate in paginile HTML, care sunt prelucrate de catre acel pre-procesor inainte de a fi transmise. Scripturile sunt stocate in fisiere speciale, cu extensia de fisier .PHP. In consecinta, este vorba de implementarea unui suport pentru generarea dinamica a resurselor, pentru care costul sau de prelucrare este oarecum redus in acea resursa, si care, odata creata pe server este pastrata intr-o memorie cache si poate fi adusa din cache daca este solicitata ulterior.

In timp ce instructiunile SSI permit inserarea in continutul unui fisier, acesta nu ofera nici o modalitate de a interveni in fluxul de control al pre-procesorului. Metodele de scripting pe partea de server permit executarea de codului unui program incorporat in HTML (asa-numitele scripturi), care sunt scrise intr-un limbaj de programare interpretat.

Conform statisticilor PHP este instalat pe 20 de milioane de situri web si pe 1 milion de servere web, fiind disponibil sub licenta PHP si Free Software Foundation, fiind astfel un software liber.

Servlet-uri

Servlet-urile reprezinta o imbunatatire a tehnologiei CGI in mediul Java. Similar cu programele CGI, servlet-urile sunt invocate de catre URL-uri speciale pentru a procesa cererile si genera apoi pagini de raspuns HTML in mod direct. Servlet-urile ruleaza intr-un mediu special (asa-numitele containere servlet), care sunt in intregime integrate in serverul Web.

Un mare avantaj al servlet-urilor fata de CGI este capacitatea lor de multi-threading. Servlet-urile pot procesa mai multe cereri concomitent pe fire diferite din cadrul unui mediu de lucru. In plus, ele ofera un API vast pentru programarea aplicatiilor web si un numar mare de caracteristici integrate, in special, mecanisme de securitate Java. Mai mult decat atat, servlet-urile ofera o modalitate eleganta de urmarire a sesiunii prin utilizarea de cookie-uri si obiecte HttpSession pentru a accesa datele sesiunii.

Java Server Pages

Java Server Pages (JSP) sunt proiectate pentru a simplifica programarea paginilor HTML sofisticate din punct de vedere grafic.

Java Server Pages extinde paginile HTML conventionale cu tag-uri JSP speciale, permitand integrarea codului programelor Java pentru a crea continut dinamic. In momentul invocarii lor, mediul de lucru traduce JSP-urile in servlet-uri, si apoi creaza paginile de raspuns HTML corespunzatoare.

ASP.NET

ASP.NET reprezinta urmatoarea generatie Microsoft Active Server Pages. Noua componenta tehnologica, asamblarea, si CLR (Common Language Runtime) formeaza coloana vertebrala a unei intregi noi game de tehnologii.

De exemplu, ASP.NET permite generarea paginilor de la Server Controls pentru a separa codul de continut, simplificand proiectarea paginilor dinamice. In plus, .NET ofera suport dedicat pentru implementarea si utilizarea serviciilor web. ASP.NET ofera avantaje considerabile pentru dezvoltarea de aplicatii web moderne distribuite si aplicatii bazate pe servicii Web.

5.2 Servicii web

De la aparitia serviciilor web si introducerea SOAP-ului, au fost publicate un numar mare de imbunatatiri si protocoale. Aceste produse sunt proiectate sa acopere lacunele existente sau sa implementeze concepte care aduc imbunatatiri. In continuare vom discuta doar tehnologiile de baza ale serviciilor web si nu vom aborda protocoale suplimentare cum ar fi WS-Security, WS-Transaction sau WSCI.

SOAP - Simple Object Access Protocol

Simple Object Access Protocol (W3C 2003a) reprezinta un modalitate simpla de a face schimb de mesaje pe baza XML-ului. Astfel de abordari comparabile, sunt, de exemplu, Internet Inter-ORB Protocol (IIOP) in CORBA, Sun's Remote Method Invocation (RMI) in Java sau .NET de la Microsoft. Pentru a permite serviciilor web sa comunice fara probleme, este necesar un protocol uniform pentru mesaje, independent de platforma utilizata. SOAP este un astfel de protocol pentru mesaje bazat pe XML. De notat ca SOAP nu poate rezolva toate problemele; nu rezolva probleme ca transportul mesajelor sau corelarea semantica. Asa cum sugereaza si numele, SOAP este proiectat pentru a defini un simplu format de comunicare. De exemplu, Remote Procedure Calls (RPCs) poate fi implementat si permite formularea de mecanisme simple pentru schimbul de mesaje in sistemele distribuite. In general, SOAP transmite informatiile ca date XML. Informatiile binare, cum ar fi fisierele imagini, pot fi adaugate de catre MIME (Multipurpose Internet Mail Extensions) in mod similar cu Microsoft BizTalk Server.

Deoarece SOAP specifica doar cum ar trebui sa arate mesajele, sunt necesare protocoale de transport suplimentare pentru a trimite si receptiona aceste mesaje. Standardul nu defineste un anumit protocol de transport. De fapt, poate fi folosit orice protocol, cum ar fi HTTP, SMTP (Simple Mail Transfer Protocol) sau protocoale proprietare bazate pe TCP/IP. Dintre acestea, protocolul HTTP este cel mai frecvent folosit. De exemplu, SOAP 1.1 defineste modul in care mesajele specificate in SOAP pot fi schimbate peste HTTP. Specificatiile SOAP constau din trei parti:

- plic SOAP: specifica ce date sunt incluse intr-un mesaj (corp SOAP), ce date pot fi incluse in mod optional (antet SOAP) si modul in care acestea ar trebui sa fie prelucrate;

- reguli de codificare SOAP: aceste norme specifica, de exemplu, cum datele definite de utilizator trebuie serializate;

- reprezentarea RPC a SOAP-ului: daca SOAP este utilizat pentru a lucra cu Remote Procedure Call, atunci reprezentarea RPC este responsabila de unde si cum ar trebui mesajele sa fie codificate.

SOAP este proiectat pentru a utiliza aceste trei parti, independent una de alta. Cele mai mari beneficii ale acestei modularitați este ca fiecare parte poate fi inlocuita si adaptata la situa ii specifice.

WSDL - Web Service Description Language

Consumatorii si furnizorii unui serviciu trebuie sa ajunga la o intelegere comuna, de exemplu, o interfata comuna pentru a putea face schimb de mesaje. Web Service Description Language (WSDL) (W3C 2003b) este un limbaj proiectat pentru a defini astfel de interfete (Interface Definition Language, IDL) pentru serviciile Web. WSDL descrie modul in care un utilizator al unui serviciu Web trebuie sa-si planifice apelurile de functii. Acesta specifica ce fel de mesaje poate accepta un serviciu, ce informatii (parametri) trebuie sa fie inclusi in mesaj si cum ar trebui sa fie structurat. In plus, utilizatorul specifica cum va fi construit raspunsul la cererea lui si cum vor fi interpretate informatiile returnate. WSDL este un alt dialect XML folosit de serviciile Web (furnizorii de servicii) pentru a descrie modul in care aceste servicii vor utiliza mesajele pentru a comunica cu utilizatorii lor (consumatorii de servicii). Serviciile Web pot utiliza unul sau mai multe porturi de comunicare, care vor schimba mesaje pentru a realiza apelurile de functii si pentru a transmite documentele.

O descriere WSDL este alcatuita din elemente de baza si extensii. Elemente de baza descriu un serviciu si porturile, tipurile de porturi si mesajele pe care le utilizeaza. Extensiile permit adaugarea constructorilor XML arbitrari, cum ar fi tipurile de date definite de utilizatori. In consecinta, documentele WSDL reprezinta un acord de stabilire a metodelor si a conventiilor de apelare a unui serviciu pe care consumatorul trebuie sa le examineze atunci cand utilizeaza acel serviciu Web.

UDDI - Universal Description, Discovery, and Integration

UDDI (https://www.uddi.org) este un director de servicii Web care ajuta clientii (solicitanti de servicii) si serverele (furnizori de servicii) sa se gaseasca unul pe altul. UDDI foloseste SOAP pentru comunicare. UDDI este deseori comparat cu Paginile Aurii, deoarece UDDI permite companiilor posibilitatea de a oferi produse si servicii in functie de nume, produs, locatie, si alte criterii.

5.3 Tehnologii middleware

Servere de aplicatii

Serverele de aplicatii sunt legate de conceptul de arhitectura pe trei straturi. Ele denota o platforma software utilizata pentru a procesa tranzactiile online (OLTP). Arhitectura pe trei straturi muta logica aplicatiei de la client la serverul de aplicatii. Clientul executa in mod normal un asa-numit thin client, fara nici o logica. Cel de-al treilea strat este reprezentat de sistemele backend, cum sunt mainframe-urile sau serverele corporatiei. Figura 12 arata modul in care interactioneaza cele trei straturi.

In acest scenariu, serverul de aplicatii reprezinta un mediu pentru dezvoltarea si functionarea aplicatiilor distribuite, bazate de componente. In acest scop, acesta ofera o serie de servicii, cum ar fi tranzactiile, punerea in comun a resurselor, echilibrarea sracinilor (load balancing), numirea sau directorul de servicii. Majoritatea serverelor de aplicatii suporta specificatiile Java 2 Enterprise Edition (J2EE), Java servlets, Java Server Pages, Enterprise Java Beans, CORBA, etc. Vechile servere de aplicatii, asa-numitele monitoarele 'procesoare de tranzactii', pot fi programate in C, C + + sau COBOL.

Enterprise Java Beans

Enterprise Java Beans (EJBs) reprezinta o arhitectura bazata pe componente pentru dezvoltarea de aplicatii Java distribuite client/server deschise si independente de platforma. Arhitectura EJB a fost dezvoltata de Sun Microsystems si publicata in specificatiile unui furnizor independent. Enterprise Bean implementeaza fie logica aplicatiei (session bean), fie reprezinta datele (entity bean). Dependent de functionalitatile acestora, aplicatiile distribuite pot fi compuse dintr-un numar mare de EJB-uri. Enterprise Beans ruleaza intr-un mediu runtime special numit de container EJB. Containerul EJB este un server de aplicatii care ofera servicii de sistem integrate, cum sunt: suportul pentru tranzactii, persistenta obiectelor sau Java Naming si Directory Interface (JNDI). Figura 6-13 prezinta aceste componente de baza.

Majoritatea proprietatilor lui Enterprise Bean, cum sunt tranzactiile sau controlul caracteristicilor bazelor de date, sunt definite intr-un fisier de configurare (descriptor de implementare), atunci cand este instalat intr-un container EJB.

Sistemul de mesaje ofera posibilitatea de comunicare asincrona intre sisteme, intr-un mediu distribuit. Sistemele sursa si destinatie dintr-un astfel de mediu comunica prin schimbul de mesaje. In functie de gradul de incarcare si de disponibilitate a sistemului destinatie, un sistem sursa poate sa astepte pentru ca un mesaj sa ajunga. Sistemele de mesaje sunt grupate de doua tipuri distincte de comunicare: comunicarea cerere/raspuns intre exact doua masini (peers) din mediul de lucru si comunicarea publica/aboneaza. In comunicarea publica/aboneaza, abonatii inregistrati la un serviciu de mesaje aferent unui anumit subiect, vor primi ulterior mesaje de la toti editorii.

5.4 Concluzii

Tehnologiile care vor avea succes in ingineria web viitoare sunt greu de prezis. XML, ca tehnologie de baza, a determinat o mutatie majora in ceea ce priveste omogenizarea mediilor eterogene. XML a determinat aparitia altor standarde bazate pe XML, care au fost si vor fi din ce in ce mai mult mai folosite. De exemplu, Web Services, tehnologiile XSL au un mare potential in ceea ce priveste utilizarea scenariilor, deoarece, datorita XML-ului ele pot construi pe baza unor premise omogene.

Implementarea cerintelor aplicatiilor web necesita o abordare bine pusa la punct. Cerintele specifice de implementare a tehnologiilor isi au originea in alte etape de dezvoltare, cum ar fi, de exemplu, analiza cerintelor, proiectarea dependenta de tehnologie sau cerinte arhitecturale si de securitate. Aceasta inseamna ca implementarea aplicatiilor web va trebui sa urmeze un corect 'cum', dupa un pre-dat 'ce'.



World Wide Web Consortium (W3C), Namespaces in XML, January, 1999a, https://www.w3.org/TR/1999/REC-xml-names-19990114/Overview.html, [ultima vizita: 2007-12-05]



Politica de confidentialitate | Termeni si conditii de utilizare



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 2094
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved