Integrarea Datelor în Aplcatii Web

Informatica

Integrarea Datelor în Aplcatii Web

Byadmin ianuarie 1, 2024

C u p r i n s

1. Introducere 5

2. Internet și World Wide Web 7

3. Limbajul HTML/XHTML 11

3.1. Diferențe între limbajele XHTML și HTML 12

3.2. Structura unui document XHTML 13

3.3. Transmiterea datelor la server și prelucrarea lor 14

4. Limbaje de programare Web 17

4.1. Programare Web pentru client și server 17

4.2. PHP – limbaj de programare Web pentru server 18

5. Sistemul MySQL 20

5.1. Baze de date relationale 20

5.2. Caracteristici MySQL 22

6. Integrarea datelor 25

6.1. Bazele integrării datelor 25

6.2. Web Services Description Language 29

6.3. Simple Object Access Protocol 31

6.4. Integrarea datelor folosind tehnologia XAware 35

6.4.1. Mediul de proiectare XAware 36

6.4.2. Metodologia construirii unui proiect XAware 43

7. Prezentarea aplicației 51

7.1 Descriere generală 51

7.1.1 Fișierele aplicației 51

7.2. Arhitectura aplicației 55

7.2.1. Interfața utilizator 55

7.2.2 Secțiunea de administrare 58

8. Concluzii 62

Bibliografie 63

=== Integrarea datelor în aplcatii web ===

C u p r i n s

1. Introducere

Studiile recente arată că un Customer Data Integration (CDI) bine executat și calitatea datelor pot ajuta dramatic companiile să-și îmbunătățească relația cu proprii clienți și totodată să-și reducă semnificativ costurile. În același timp, comerțul electronic a cunoscut o evoluție accentuată, de la paginile HTML statice ce ofereau doar informații de contact, oferte promoționale sau cataloage de produse, la site-urile Web complexe caracterizate de o flexibilitate mare în dezvoltare și de o adaptabilitate rapidă la cerințele specifice clientului.

Aplicația EShop își propune să realizeze serviciului web pentru site-ul unei societăți comerciale ce are ca obiect de activitate vânzarea online de produse IT. Site-ul EShop va trebui să răspundă atât cerințelor clienților cât și cerințelor administratorului.

Pentru client, aplicația va realiza următoarele obiective:

– accesul la informațiile referitoare la firmă și la alte informații utile despre modul de cumpărare;

– posibilitatea de a înregistra sugestii și opinii referitoare la site;

– accesul cat mai rapid la informațiile necesare clientului;

– căutarea produselor din baza de date;

– gestionarea coșului de cumpărături.

Pentru administrator, aplicația va oferi răspunsul la următoarele cerințe:

– autentificarea administratorilor și posibilitaea creării unui cont nou de către un administrator autentificat;

– posibilitatea modificării parolei administratorului logat;

– posibilitatea adăugarii, ștergerii sau modificării unei categorii de produse din baza de date;

– posibilitatea adăugarii, ștergerii sau modificării unui produs dintr-o categorie;

– gestionarea comenzilor;

– gestionarea sugestiilor.

Cerintele administratorului vor fi rezolvate cu ajutorul serviciului web , fiecărei operații din secțiunea administrator corespunzându-i o operație în cadrul serviciului. Acest lucru va conferi reutilizabilitatea cât si posibilitatea de a conecta mai multe site-uri, cu opțiuni de administrare similare, la același serviciu web. Rezultatul este o eficiență sporită a proiectării site-urilor asemănătoare, cât si o gestionare mult mai ușoară a acestora.

În plus, aplicația va trebui să aibă o interfață care să ofere utilizatorilor flexibilitate, consistență și o operare cât mai simplă. Deasemenea se va avea în vedere crearea unui serviciu web care va rezolva o parte din interogările bazei de date, și anume opțiuniile din meniul administratorului (autentificare, modificări categorii/produse, etc.)

Soluția software a acestor cerințe este pusă la dispoziție de serverul Web Apache, serverul de baze de date MySQL, limbajele PHP și JavaScript, pe partea de realizare a site-ului, iar pentru crearea si rularea serviciului web se va folosi serverul Tomcat și XAware Designer. Serviciul va fi accesat prin intermediul fișierului WSDL utilizând protocolul SOAP (librăriile NUSOAP pentru PHP).

Lucrarea de față este structurată în 8 capitole și prezintă, într-o primă etapă, spațiul World Wide Web și principalele sale caracteristici, urmând ca în capitolele 3, 4 și 5 să fie analizate noțiunile de bază și modalitățile de utilizare ale limbajelor HTML/XHTML și PHP, respectiv ale sistemului de gestiune a bazelor de date relaționale MySQL. În capitolul 6 se vor descrie conceptul de integrare a datelor, modul de accesare al acestora prin intermediul SOAP și WSDL cât și pașii necesari pentru crearea unui serviciu complet și deploymet-ul său.

Îmbinarea tehnologiilor software descrise mai sus face posibilă realizarea paginilor Web dinamice, cu acces la diverse tipuri de date stocate pe server în baza de date MySQL cât și prin accesarea serviciului web dezvoltat.

În capitolul 7, prin aplicația EShop se vor pune în practică cele prezentate anterior, realizându-se serviciul web pentru site-ul Web dinamic.

Aplicația prezentată nu epuizează toate aspectele caracteristice categoriei din care face parte, ci ilustrează o soluție posibilă, un punct de plecare în procesul de continuă dezvoltare al serviciilor web și implementarea acestora în cadrul unui site Web.

Lucrarea se încheie prin precizarea elementelor nesoluționate ale aplicației și prin oferirea unor posibilități alternative de utilizare a site-ului.

2. Internet și World Wide Web

O rețea de calculatoare este un ansamblu de calculatoare independente capabile să comunice între ele prin intermediul unor canale de comunicație. Așadar, o rețea poate fi privită drept o colecție de calculatoare autonome interconectate.

Internetul este o rețea care cuprinde calculatoare și rețele din întreaga lume. Toate calculatoarele conectate la Internet comunică între ele folosind un protocol de transmitere a datelor, Transmission Control Protocol/Internet Protocol (TCP/IP).

Unul dintre cele mai importante și de succes servicii ale internetului este World Wide Web-ul (pe scurt Web-ul sau spațiul WWW). Acesta reprezintă un sistem de distribuție locală sau globală a informațiilor hipermedia. Din punct de vedere tehnic, spațiul Web pune la dispoziție un sistem global și standardizat de comunicare multimedia, informațiile fiind organizate asociativ si distribuite în funcție de cererile utilizatorilor, funcționând conform modelului client/server. Acest model presupune existența unor calculatoare server, care furnizează fișiere și informații, la cerere, unor calculatoare client.

Calculatoarele server depozitează informația, o sortează si o distribuie cu ajutorul unui software specializat, care asigură anumite servicii în rețea (poștă electronică, transfer de fișiere, comerț electronic etc.).

Calculatoarele client emit cereri de servicii către calculatoarele server cu ajutorul unor programe care asigură accesul la aceste servicii.

Web-ul, cu toată dezvoltarea lui spectaculoasă, nu trebuie confundat cu Internetul, ci poate fi considerat drept cea mai dinamică și spectaculoasă componentă software a acestuia, neputând exista fără infrastructura hardware a rețelelor mondiale interconectate prin intermediul protocoalelor TCP/IP.

Web-ul poate fi privit ca fiind un spațiu informațional compus din elemente de interes, denumite resurse, desemnate de identificatori globali denumiți URI (Uniform Resource Identifiers). O adresă URI reprezintă un descriptor care identifică în Internet, în mod unic, o resursă. Adresele URI sunt de două tipuri: URL (Uniform Resource Locator) și URN (Uniform Resource Name). URL-urile, accesibile prin intermediul protocoalelor existente, sunt utilizate de browserele Web pentru localizarea resurselor din Internet. URN-urile permit identificarea resurselor în Internet dupa nume, indiferent de locul în care se află.

Identifocatorul URL are o formă standard:

[protocol://]nume_gazdă.domeniu[/cale][/fișier.extensie#ancoră][?date]

unde:

protocol reprezintă metoda (protocolul) pentru accesarea resursei;

nume_gazdă reprezintă numele computerului gazdă;

domeniu reprezintă numele domeniului de pe Internet căruia îi aparține computerul;

cale reprezintă calea către un fișier, în structura de directoare și fișiere aflate pe computerul de pe Internet ;

ancoră reprezintă un reper (marcaj) în interiorul unui fișier ;

date (componentă utilizată împreună cu protocolul http) precizează anumite date, în perechi de forma nume_data=valoare_data, separate prin caracterul &.

Un computer are un nume unic pe Internet reprezentat de sintaxa: nume_gazdă.domeniu .

Web-ul permite accesarea spațiului Internet folosind majoritatea protocoalelor de acces din rețea: mailto, ftp (File Transfer Protocol), telnet, news etc. și în plus are propriul său protocol: http (HyperText Transfer Protocol). Interacțiunea dintre clientul si serverul Web, prin intermediul protocolului HTTP, constă de cele mai multe ori dintr-o cerere ASCII a clientului și un răspuns MIME (Multipurpose Internet Mail Extensions) al serverului. Cererea implică o metodă aplicată asupra unei resurse aflate pe calculatorul server. Utilizarea standardului MIME permite transmiterea, pe lângă textul simplu (plain text), și a altor informații (audio, video, imagini etc.).

Deoarece HTTP este un protocol care utilizează codul ASCII, obținerea unor fișiere aflate pe server nu necesită în mod obligatoriu un program de navigare (browser Web). Este suficientă stabilirea unei conexiuni TCP pe portul 80 al mașinii pe care funcționează serverul Web, lucru realizabil și cu alte programe, ca de exemplu, programul Telnet (Windows). Cu toate acestea, în mod normal, pentru a obține accesul la un document Web, utilizatorul folosește un program de navigare (browser). De aceea, operațiile de stabilire a conexiunii TCP (la inițiativa browserului), de transmitere a cererii HTTP (efectuată de browser) și de comunicare a răspunsului HTTP (efectuată de serverul Web) sunt realizate în mod transparent pentru utilizator.

În cadrul WWW, informația este organizată sub formă de pagini Web. Pagina Web conține, pe lângă informații, referințe pentru alte informații din rețea. Aceste referințe se numesc hiperlegături. Mai multe pagini Web, împreună cu elementele asociate (fișiere, scripturi, baze de date), organizate pe un server, formează un site Web. Paginile web sunt scrise într-un limbaj specific: HTML (HyperText Markup Language). Tot ceea ce ține de WWW – modul de organizare a informației, modul de transport, modul de codificare a acesteia – este legat de două noțiuni fundamentale: hipertext si hipermedia.

Hipertextul (hypertext) este un mod de a organiza informația textuală, cu particularitatea că poate lega diferite părți ale acesteia după o anumită logică, și nu într-o succesiune liniară, impusă prin fraze și paragrafe.

Hipermedia (hypermedia) este o extensie a structurii hipertext, dezvoltată prin adăugarea la aceasta a unor elemente multimedia (sunete, imagini etc.).

Componentele celor doua structuri sunt nodul informațional și legătura (link), prin care se construiesc sistemele și se realizează căutarea informațiilor. Nodul este elementul de natură textuală sau multimedia, iar legăturile sunt conexiuni între noduri.

Legăturile pot fi:

interne – se stabilesc între noduri informaționale ce se găsesc în același fișier HTML;

externe – se stabilesc între noduri informaționale ce se găsesc în fișiere diferite;

executabile – se stabilesc între un fișier codificat HTML și un fișier executabil ce poate genera o pagină HTML sau un anumit conținut media.

Modalitatea de memorare a informațiilor în cadrul nodurilor variază de la sistem la sistem, dar cele mai folosite tehnici sunt cele bazate pe SGML (Standard Generalized Markup Language) sau XML (Extensible Markup Language), pentru Web pretându-se limbajul HTML și succesorul acestuia, XHTML.

Organizația responsabilă cu coordonarea standardelor referitoare la World Wide Web este W3C (World Wide Web Consortium), înființată în octombrie 1994 de către însuși creatorul Web, Tim Berners-Lee. Organizația este găzduită de trei universități: Massachusetts Institute of Technology din SUA, Institute National de Recherche en Informatique et en Automatique din Europa și Keyo University din Japonia. Printre membrii W3C se numără companii precum: IBM, Microsoft, America Online, Apple, Adobe, Macromedia, Sun Microsystems etc.

Standarde W3C:

HTML – HyperText Markup Language

XHTML – Extensible HyperText Markup Language

CSS – Cascading Style Sheets

XML – Extensible Markup Language

XLS – Extensible Stylesheet Language

DOM – Document Object Acces Protocol

WSDL – Web Services Description Language

RDF – Resource Description Framework

OWL – Web Ontology Language

SMIL – Synchronized Multimedia Integration Language

Misiunea W3C este de a conduce evoluția Web-ului. Identificatorii universali de resurse, formatele de date ușor de procesat de către mașină și specificațiile capabile de a fi interpretate de calculatoare pot fi îmbinate într-un sistem extensibil care asimilează orice concurență.

3. Limbajul HTML/XHTML

Limbajul pentru scrierea paginilor web este HTML (HyperText Markup Language). De fapt, HTML nu este un limbaj de programare propriu-zis, ci, mai degrabă, un sistem pentru descrierea modului de afișare a elementelor din pagină și de stabilire a legăturilor cu alte documente. Documentele HTML conțin text ASCII și o serie de marcaje specifice (tags). Browserele interpreteaza un document HTML și îl afișează.

Faptul că documentele HTML sunt documente text prezintă două avantaje principale:

pot fi interpretate pe orice platformă: IBM, Macintosh sau Unix;

pot fi scrise folosind programe obișnuite de editare a textului.

Un document HTML este divizat în blocuri numite elemente. Acestea pot fi încadrate în trei secțiuni principale:

secțiunea HEAD – conține informații despre documentul HTML: titlul acestuia, relațiile cu alte documente HTML, etc.;

secțiunea BODY – descrie cum va fi afișat corpul documentului de către browser;

secțiunea pentru declarații – este plasată la începutul documentului și nu este obligatorie.

Exemplu de document HTML:

<html>

<head>

<title> titlul_paginii </title>

</head>

<body>

corpul documentului

</body>

</html>

Dezvoltări succesive ale limbajului HTML au condus la apariția limbajelor DHTML (Dynamic HyperText Markup Language) și XHTML (Extensible HyperText Markup).

XHTML este noua generație de HTML, conformă cu tehnologia XML, astfel, acesta are facilități moștenite de la ambele limbaje de marcare:

similar limbajului HTML, XHTML poate fi utilizat la crearea paginilor Web (există câteva diferențe minore, dar capacitățile limbajului HTML au fost păstrate în XHTML);

similar limbajului XML, XHTML poate fi utilizat cu toate aplicațiile XML, codul fiind mai strict, dar în același timp, mai stabil și mai curat.

3.1. Diferențe între limbajele XHTML și HTML

Limbajul XHTML impune un standard riguros în ceea ce privește scrierea documentelor. Regulile utilizate pentru scrierea documentelor XHTML sunt precizate de W3C.

Fiind bazat pe XML, limbajul XHTML, spre deosebire de HTML, este case sensitive. Din acest motiv, numele elementelor XHTML trebuie scrise cu minuscule.

Instanțele elementelor XHTML sunt reprezentate întotdeauna printr-un marcaj de deschidere și un marcaj de închidere (ca în XML, spre deosebire de HTML). Textul situat între marcajul de deschidere și limbajul de închidere preia efectele acelui marcaj.

Cele mai multe elemente XHTML utilizează atribute. Ele trebuie plasate între parantezele unghiulare ale marcajelor de deschidere, după numele elementului, în perechi nume_atribut=”valoare_atribut”. În mod obligatoriu în XHTML (spre deosebire de HTML) valorile atributelor (inclusiv ale celor numerice) trebuie specificate între ghilimele.

În HTML, atributul name identifică elementele, pentru ca acestea să fie utilizate de limbajele de scripting (de exemplu JavaScript). Limbajul CSS utilizează atributul id pentru a accesa elementele HTML. Pentru identificarea elementelor în XHTML este definit atributul id (având tipul ID). Codul XHTML va lucra cu browserele actuale și cu scripturile existente dacă se vor folosi ambele atribute (name și id).

În limbajul XHTML, conținutul instanțelor elementelor script și style trebuie marcat ca secțiune CDATA, deoarece aceste elemente sunt definite în DTD ca având conținut #PCDATA (în caz contrar, caracterul < va fi interpretat ca începutul unui element XHTML). În acest scop se utilizează delimitatorii [[ și ]] sau se utilizează fișiere script și de stil externe.

Instanțele elementelor nevide pot fi imbricate, în XHTML fiecare pereche de marcaje corespunzătoare unei instanțe fiind plasată în interiorul unei alte perechi corespunzătoare unei alte instanțe.

Dacă browserul nu recunoaște un element va prelucra conținutul său (situat între marcajul de deschidere și cel de închidere).

3.2. Structura unui document XHTML

La începutul unui document XHTML trebuie declarat tipul acestuia prin utilizarea unei declarații DOCTYPE. Fiecare versiune de XHTML se conformează unei definiții formale stabilite de W3C și reprezintă în fapt un tip de document. Această definiție este denumită definiția tipului de document – DTD (Document Type Definition) și se găsește la un URI din cadrul site-ului W3C. Un DTD este un fișier text conținând reguli care stabilesc mulțimea de elemente și atribute, valorile acestora, ca și structura unui document XHTML (maniera de apariție a elementelor și atributelor, precum și relațiile dintre ele).

Orice document hipertext are un element rădăcină (root element), acesta fiind html. Marcajul de început al elementului rădăcină al unui document XHTML trebuie să conțină în mod explicit o declarație xmlns pentru spațiul de nume XHTML. Adresa URI a spațiului de nume XHTML 1.0 este http://www.w3.org/1999/xhtml.

Instrucțiunile de procesare XML (XML PI – Processingg Instructions) sunt opționale. Dacă există, ele trebuie plasate la începutul documentului XHTML (înaintea declarației DOCTYPE). O instrucțiune de procesare XML este similară, ca sintaxă, cu:

<?xml version=”1.0” encoding=”iso-8859-1”?>

Această instrucțiune de procesare comunică oricărui program care analizează docmentul versiunea de XML și setul de caractere utilizate. Prezența acestei instrucțiuni este opțională, însă ea nu trebuie să lipsească atunci când se dorește precizarea setului de caractere care va fi folosit de browser.

Un document XHTML, la fel ca și un document HTML trebuie să conțină următoarele două secțiuni:

head (secțiune numită antetul documentului);

body (secțiune numită corpul documentului).

Cele două secțiuni ale documentului trebuie încadrate între perechea de marcaje <html> și </html>. Într-un document XHTML elementele head, body și title (titlul documentului) sunt obligatorii.

Exemplu de document XHTML 1.0 Transitional:

<?xml version="1.0" encoding="iso-8859-1" ?>

<!DOCTYPE html

PUBLIC "-//W3C//DTD HTML 4.0//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-

transitional.dtd">

<head>

<title> titlul_paginii </title>

</head>

<body>

corpul documentului

</body>

</html>

Pentru a converti documente HTML în documente XHTML se poate utiliza aplicația Tidy, dezvoltată de W3C.

3.3. Transmiterea datelor la server și prelucrarea lor

Pentru transmiterea datelor la serverul Web se utilizează un program de navigare, o conexiune TCP și protocolul HTTP.

Unele dintre cele mai răspândite servere Web (numite și servere HTTP) sunt următoarele:

Apache (din categoria open source).

IIS (Internet Information Server), de la Microsoft

Netscape ;

Zeus.

CGI (Common Gateway Interface) reprezintă o modalitate de comunicație între serverul Web și resursele calculatorului gazdă (baze de date, programe etc.) prin intermediul programelor sau scripturilor CGI.

Interfețele server API (numite și SAPI, adică Server Application Programming Interface) reprezintă o altă modalitate prin care serverul Web poate să comunice cu aplicațiile. Ca exemple de interfețe API pentru servere Web menționăm: interfața SAPI Apache, ISAPI (Internet SAPI – interfață performantă destinată aplicațiilor back-end pentru IIS) de la Microsoft și NSAPI (Netscape SAPI – interfața dintre serverul Netscape și programele de aplicație) de la Netscape.

Mediul SSJS (Server-Side JavaScript) de la Netscape permite scrierea unor aplicații Web care folosesc extensiile JavaScript pentru server, aplicații controlate de serverul Netscape.

Prin script, în sens larg, înțelegem trei tipuri de programme :

programe compilate (de exemplu programme scrise în limbajele C, C++, Visual Basic etc.) ;

programe interpretate. Acestea sunt scrise în limbaje numite limbaje interpretate sau limbaje de scripting (ca exemple, menționăm limbajele Pearl și PHP, des utilizate în programarea Web pentru server) ;

programe de tip batch sau de tip shell script, scrise în limbajul shell al sistemului de operare (shell-ul este un program, numit și interpretor de comenzi, care asigură comunicația directă între utilizator și sistemul de operare; ca exemple, amintim shell-urile Bourne shell, C shell, Korn shell – UNIX – și Bash shell – Linux ).

Scripturile din prima categorie (impropriu numite astfel) sunt programe compilate, scrise într-un limbaj de programare compilat. Aceste scripturi au avantajul că ocupă un spațiu mic de memorie și se execută mai repede decât un program echivalent scris într-un limbaj de scripting. Serverul Web execută programul – numit adesea script CGI – ca urmare unei cereri venite de la client și îi transferă informațiile primite de la client (via HTTP) intermediul interfeței CGI. De asemenea, prin intermediul CGI, programul întoarce serverului Web informațiile prelucrate.

Programele din a doua categorie (scrise într-un limbaj de scripting) sunt interpretate înainte de execuție de către un program numit interpretor.

Interpretorul unui limbaj de scripting (utilizat ca server de aplicații) poate fi folosit în două moduri:

ca program CGI – interpretorul este invocat de serverul Web ca un proces separat, pentru executarea scriptului (serverul Web comunică cu interpretorul prin intermediul interfeței CGI, determinând pornirea acestuia de fiecare dată când primește o cerere pentru execuția unui script) ;

ca modul, fiind executat ca parte a procesului server – interpretorul execută scriptul imediat după ce acesta este cerut, neexistând întârzieri.

Utilizarea ca modul a interpretorului limbajului de programare se poate face în două moduri :

ca modul static compilat în programul server ;

ca modul legat dinamic sau plug-in, pe care serverul Web îl va încărca de fiecare dată când este pornit, dacă o opțiune corespunzătoare este plasată în fișierul de configurare al serverului. Această modalitate este cea mai utilizată. Are avantajul că instalarea unei noi versiuni a interpretorului limbajului de programare nu necesită recompilarea serverului Web, așa cum se întâmplă în cazul în care interpretorul este instalat ca modul static.

Dacă interpretorul limbajului de scripting rulează ca modul compilat sau legat în procesul server Web, interfața CGI nu este utilizată de server.

Programele compilate sau scripturile executate de interpretorul care rulează ca un proces separat de procesul server (ca program CGI) se găsesc localizate în directorul rădăcină al al serverului Web, de obicei în subdirectorul cgi-bin (Common Gateway Interface – binaries), pentru ca serverul Web să știe unde să le găsească atunci cănd primește o cerere de la un client pentru un astfel de program sau script.

Programele din a treia categorie (batch sau shell script) sunt scripturi CGI scrise în limbajul shell al mașinii gazde.

Exemple de limbaje script/platforme pentru realizarea aplicațiilor Web:

PHP (inițial Personal Home Page, ulterior Hypertext Preprocessor). Bazele sale au fost puse de Rasmus Lerdorf în 1994. O combinație de C, Perl și Java, PHP este unul dintre cele mai performante limbaje de scripting, fiind, în același timp, și cel mai ușor de învățat. poate fi instalat pe un număr mare de sisteme de operare. Lucrează ca program CGI sau ca modul (static sau dinamic) în procesul server, de cele mai multe ori cu serverul Web Apache.

JSP (JavaServer Pages) este o platformă de programare Web creată de Sun Microsystems (la începutul anului 1998) și face parte din specificația Java 2 Enterprise Edition compilat în așa-numitele servlet-uri binare pentru o procesare rapidă. Primele servere Web includ API-ul Java Servlet, care permite comunicația cu serverele pentru servlet-uri.

ASP (Active Server Pages) este o platformă de programare Web creată de Microsoft. Paginile Active Server includ scripturi scrise în VBScript (Visual Basic Script), JScript (versiunea Microsoft a limbajului JavaScript de la Netscape), dar și în PerlScript. Lucrează bine cu serverul IIS, dar există versiuni ASP și pentru alte servere Web.

Perl (Practical Extraction and Report Language) este un limbaj de programare complex, creat de Larry Wall. Are la bază limbajul C și o serie de utilitare UNIX. Este strămoșul PHP-ului și, de asemenea, un limbaj de referință în lumea limbajelor de scripting. Poate fi instalat, practic, pe toate sistemele de operare. Este utilizat în special pentru procesarea fișierelor și manipularea textelor. Utilizarea pe scară largă a limbajului PHP a pus în umbră, în ultimii ani, limbajul Perl.

4. Limbaje de programare Web

4.1. Programare Web pentru client și server

Activitatea de programare Web presupune utilizarea unor limbaje de programare atât pe partea de client, cât și pe partea de server. De cele mai multe ori acestea sunt limbaje interpretate, adică instrucțiunile incluse în scripturile scrise în aceste limbaje sunt translatate într-un format intern și scrise una câte una.

Deși, din punct de vedere formal, limbajele de programare Web pentru client și server sunt asemănătoare – în sensul că secvențele de cod-sursă scrise în aceste limbaje pot fi integrate în codul XHTML – ele sunt diferite din punctul de vedere al modalităților de execuție a programelor. Astfel, browserul Web interpretează un script scris într-un limbaj de programare pentru client după ce pagina care îl conține a fost descărcată pe calculatorul utilizatorului. În schimb, un script scris într-un limbaj de programare pentru server este procesat în întregime pe serverul Web, ca rezultat fiind generate diverse tipuri de conținuturi, inclusiv XHTML, transmise apoi aplicației-client.

Utilizarea programării Web pe server are următoarele avantaje:

nu apar probleme legate de compatibilitatea cu browserul, deoarece scripturile scrise într-un astfel de limbaj sunt interpretate pe server;

este permis accesul la resursele aflate pe server (resurse reprezentate în special de fișiere și de baze de date);

se reduce „încărcarea” calculatorului client, acest avantaj fiind important în cazul în care acest calculator are resurse reduse.

Exemple de limbaje de programare Web pentru server au fost date în capitolul precedent în secțiunea „3.4. Transferul datelor la server”.

Exemple de limbaje de programare Web pentru client:

Java este un limbaj de programare derivat din C++ și extins prin colecții de biblioteci. O platformă Java este este alcătuită din interfața de programare (Java Apllication Programming Interfaces – API), alcătuită din biblioteci de coduri compilate care pot fi folosite în programele utilizatorului, și interpretorul Java virtual machine (Java VM) cu ajutorul căruia pot fi rulate programele Java.

JavaScript a fost introdus pentru prima oara de catre Netscape in produsul Netscape Navigator 2.0. Spre deosebire de Java, unde codul este compilat și scris in fișiere separate numite appllet-uri, codul JavaScript este inclus ca parte integrantă a codului sursă HTML si nu necesită compilari sau preprocesari, fiind un limbaj 100% interpretat.

VBScript (Visual Basic Script) a fost dezvoltat de Microsoft ca alternativă a limbajului JavaScript și are la bază limbajul de programare Visual Basic. Este un limbaj de scripting suportat doar de Internet Explorer și permite legarea și activarea automată de obiecte în pagina Web, incluzând controale ActiveX și applet-uri Java.

VRML (Virtual Reality Modeling Language) a fost dezvoltat de Consorțiul Web3D și a fost destinat utilizării pe Internet, fiind văzut ca o extensie 3D a World Wide Web. VRML permite încorporarea de programe de tip script, făcând astfel posibilă programarea comportării obiectelor din lumea virtuală.

4.2. PHP – limbaj de programare Web pentru server

PHP este unul dintre cele mai utilizate limbaje de programare pentru server. Succesul său este datorat atât posibilităților deosebite pe care le oferă programatorilor, cât și ușurinței cu care poate fi învățat. Aceste caracteristici fac din PHP un instrument utilizat din ce în ce mai des pentru crearea unor aplicații Web dinamice complexe în domenii ca : e-commerce, e-marketing, e-mailing, e-consortium, e-learning, e-banking.

Scurt istoric

În anul 1994, Rasmus Lerdorf a creat utilitarul PHP (acronim pentru Personal Home Page), prin intermediul căruia colecta informații despre vizitatorii site-ului său Web. Mai târziu el a adăugat la PHP elemente de interfață între utilizatori și bazele de date, pe care le-a numit Form interpreters, rezultând PHP/FI. În anul 1997, Zeev Surasky și Andi Gutmans au inițiat dezvoltarea unui limbaj de programare Web bazat pe PHP/FI și pe sintaxa C, numit PHP (de data aceasta, acronim recursiv pentru PHP : Hypertext Preprocesor). În anul 1998 este oferită utilizatorilor versiunea 3.0 a limbajului, versiune ce permitea folosirea unor elemente de programare orientată pe obiect. În anul 2000 apare versiunea 4.0, în care este introdus motorul Zend (Zend Engine). Versiunea 5 a limbajului a fost lansată în 2004 și se bazează pe versiunea 2 a motorului Zend, care asigură, printre altele, un progres important în ceea ce privește implementarea POO (Programarea Orientată pe Obiect).

Avantaje ale utilizării PHP

Serverul de aplicații PHP dispune de interfețe pentru o mare parte a sistemelor de gestiune a bazelor de date utilizate în Internet (spre exemplu, MySQL, Oracle, Microsoft SQL Server, IBM DB2, Postgresql, Informix, Sybase), precum și ODBC (Open DataBase Connectivity).

Un alt avantaj al utilizării PHP este acela că include suport pentru comunicația cu servicii care utilizează diverse protocoale: HTTP, FTP, IMAP (Internet Message Acces Protocol), POP3 (Post Office Protocol Version 3), COM (Component Object Model) și LDAP (Lightweight Directory Acces Protocol).

În ceea ce privește procesarea textului, PHP implementează standardul POSIX Extins (Portable Operating System Interface: Operating system based on UNIX) și expresiile regulate Perl. De asemenea, PHP permite accesarea, procesarea și transformarea documentelor XML, implementând modelele SAX (Simple API for XML), DOM (Document Object Model) și limbajul XSLT (Extensible Stylesheet Language Transformation).

Este important de amintit suportul PHP pentru instanțierea claselor Java, generarea și prelucrarea imaginilor, crearea animațiilor Flash, a documentelor PDF și gestiunea sesiunilor (prin variabile sesiune și variabile cookie).

În plus, serverul de aplicații PHP poate fi utilizat pe majoritatea platformelor (de exemplu, UNIX/Linux, Windows, Mac OS X), împreună cu cele mai multe servere (de exemplu, Apache, IIS, iPlanet). În cele mai multe cazuri PHP este folosit ca modul inclus în procesul server HTTP, iar în cazul în care serverul Web suportă standardul CGI (Common Gateway Interface), PHP poate lucra ca procesor CGI.

Interpretarea scripturilor PHP

Interpretarea unui script PHP are loc în felul următor: când preprocesorul PHP începe să citească fișierul cu extensia php, trimite la ieșirea standard tot ce întâlnește (cod XHTML), până în momentul în care întălnește codul de început (care poate fi <?php), când trece din modul XHTML în modul PHP. Din acest moment interpretează codul PHP, care se termină cu codul de sfârșit (care poate fi ?>), la întâlnirea căruia preprocesorul trece din nou în modul XHTML. Datele de ieșire sunt generate la ieșirea standard cu ajutorul instrucțiunii echo sau al funcțiilor print() și printf(). Serverul Web interceptează ieșirea standard a preprocesorului PHP și trimite rezultatul browserului.

5. Sistemul MySQL

Sistemele de gestiune a bazelor de date (SGBD) sunt componente software utilizate într-un număr mare de sisteme de activiate pentru introducerea, organizarea, stocarea, administrarea și utilizarea datelor.

Pentru organizarea și stocarea datelor în bazele de date, SGBD-urile utilizează modele conceptuale (numite și modele structurale). Modelele conceptuale mai des utilizate sunt: ierarhic, rețea, relațional, obiectual și obiectual-relational.

Modelul coceptual cel mai folosit de SGBD-uri pentru stocarea datelor este modelul relațional. Sistemul software care permite gestionarea bazelor de date relaționale se numește sistem de gestiune a bazelor de date relaționale – SGBDR (Relational DataBase Management System – RDBDMS).

5.1. Baze de date relationale

O bază de date relațională este alcătuită, în principiu, din mai multe tabele (tables) între care există anumite relații. Un tabel conține înregistrări (records), numite și rânduri (rows). O înregistrare este alcătuită din mai multe câmpuri (fields), numite și coloane (columns) sau atribute.

În teoria relațională, într-un tabel, înregistrările nu se pot repeta, adică un tabel nu poate avea două linii identice. O linie este identificată prin valoarea atributelor care o compun. Atributul sau atributele ale căror valori sunt unice servesc pentru identificarea înregistrărilor.

O combinație de atribute care permite identificarea înregistrărilor poartă numele de cheie candidată. O cheie candidată trebuie să respecte trei conditii:

unicitate – o cheie identifică în mod unic o înregistrare în tabel;

valori nenule – atributele care compun cheia trebuie să aibă valori diferite de NULL;

compoziție minimală – atunci când cheia este compusă din mai multe atribute, dacă oricare dintre acestea este eliminat, înregistrarea din tabel nu va mai fi unică.

Dintre cheile candidate se alege o cheie primară, restul numindu-se chei alternate. Alegerea cheii primare se face în functie de lungimea cheii, numărul de atribute care o compun, ușurința în manipulare etc. O cheie a unui tabel se numește cheie externă sau cheie străină dacă este cheie primară a unui alt tabel.

Pentru ca o bază de date să fie utilizată într-un mod eficient, aceasta trebuie normalizată.

Normalizarea este procedeul prin care o bază de date relațională este adusă la o formă optimizată prin transformări succesive (etape) supuse unor anumite reguli. În fiecare etapă, bazele de date sunt aduse într-o formă standard, cunoscută sub denumirea de formă normală (FN). Există cinci forme normale: FN1, FN2, FN3 (numită și BCNF – Boyce-Codd Normal Form), FN4, FN5.

Prima formă normală elimină câmpurile compuse și pe cele repetitive. A doua formă normală elimină dependențele funcționale parțiale (trebuie ca toate câmpurile unui tabel să depindă doar de cheia sa primară – nu de atribute ale acesteia). A treia formă normală elimină dependențele funcționale tranzitive (dependențele de acest tip iau naștere când un câmp C1 depinde de un alt câmp C2, iar acesta depinde de un altul, C3, astfel încât C1 depinde de C3). A patra formă normală elimină dependențele multivaloare suplimentare (pentru un tabel este permisă numai una singură), iar a cincea formă normală elimină dependențele joncțiune.

În modelul relațional, implementarea unei baze de date implică parcurgerea obligatorie a trei etape:

proiectarea bazei de date. În acest scop este utilizat un procedeu cunoscut sub numele de modelare entitate-relație (modelare E-R). Procedeul include următoarele subetape:

identificarea coloanelor, în care se ține seama de datele pe care trebuie să le stocheze baza de date;

gruparea coloanelor în entități sau tabele, astfel încât coloanele corelate să se grupeze în același tabel; există posibilitatea ca o coloană să fie prezentă în mai multe tabele;

identificarea cheilor primare; o astfel de cheie poate fi reprezentată de o coloană, de mai multe coloane (în cazul în care cheia primară este cheie compusă) sau de o nouă coloană creată în acest scop;

identificarea cheilor externe;

normalizarea bazei de date;

specificarea tipului de date pentru fiecare coloană. Majoritatea tipurilor de baze de date relaționale acceptă următoarele tipuri de date: caracter, întreg, zecimal, dată și oră, binar.

Pentru exploatarea bazelor de date relaționale este utilizat SQL (Structured Query Language), adică limbajul de interogare structurat. SQL este cel mai utilizat limbaj standardizat pentru accesul la bazele de date, permițând stocarea, regăsirea și modificarea datelor din bazele de date relaționale. Exemple de SGBD-uri care utilizează SQL: Microsoft SQL Server, Oracle, IBM DB2, MySQL, INGRES, Sybase etc.

Limbajul SQL permite efectuarea următoarelor operații:

crearea bazelor de date și a tabelelor;

modificarea structurii tabelelor;

indexarea tabelelor;

stabilirea unor relații între tabelele componente ale unei baze de date;

actualizarea conținutului tabelelor componente ale unei baze de date;

interogarea tabelelor componente ale bazelor de date;

controlul (adăugarea sau revocarea) drepturilor de acces ale utilizatorilor asupra bazelor de date;

configurarea unor elemente legate de securitatea sistemului.

Fiecare SGBDR implementează într-o manieră specifică limbajul SQL, în sensul că majoritatea producătorilor adaugă extensii proprii la standardul SQL, fapt ce determină implementări SQL diferite de la un sistem la altul.

În funcție de proveniență și costuri, SGBDR-urile se împart în:

sisteme comerciale (proprietare);

sisteme cu sursă deschisă (open source).

Cel mai popular SGBDR cu sursă deschisă este MySQL. Acest sistem de gestiune a bazelor de date este scris în C și C++, fiind testat cu numeroase compilatoare, pe numeroase platforme și are implementat suportul pentru următoarele tipuri de date: numeric, dată și timp, șir de caractere.

5.2. Caracteristici MySQL

MySQL este un server de baze de date SQL rapid, robust, multi-fir (multi-threaded) – utilizează fire de execuție concurente – și multi-utilizator (multi-user) – poate deservi simultan mai multe conexiuni cu utilizatorii.

Există numeroase interfețe de acces la bazele de date MySQL din diverse limbaje și medii de programare: C++, Java, Perl, PHP (așa cum este aplicația phpMyAdmin, care poate fi descărcată de la adresa http://www.phpmyadmin.net), Phyton, Tcl, Eiffel etc.

Programatorul iși poate crea propriile interfețe de acces la bazele de date MySQL, deoarece unele dintre limbajele amintite anterior, de exemplu PHP, dispun de funcții puternice dedicate interacțiunii directe cu sistemul MySQL, iar altele pot interacționa cu MySQL prin intermediul interfețelor API ODBC (limbajele C, C++, PHP) și API JDBC (limbajul Java).

MySQL utilizează, ca și alte SGBDR-uri, arhitectura client-server. O mașină care dorește să proceseze interogări asupra bazelor de date MySQL trebuie să ruleze un server MySQL (acesta este, în general, mysqld) care este responsabil cu traficul de tip incoming/ougoing în bazele de date. Serverul MySQL „ascultă” posibilele cereri de conexiune ale clienților pe portul 3306 (implicit). Prin client MySQL se înțelege orice aplicație capabilă să trimită interogări serverului MySQL. Aceasta poate fi, spre exemplu, un script PHP sau Perl, clientul în linia de comandă mysql instalat o dată cu distribuția MySQL sau clientul cu interfață grafică MySQLGUI.

Modelul de securitate folosit în MySQL are la bază numele de utilizator și parola (username and password), numele gazdei (hostname) și privilegiile utilizatorului (care precizează operațiile care pot fi efectuate asupra bazelor de date, tabelelor și indexurilor), fiind similar celui utilizat în sistemele UNIX/Linux.

Sistemul MySQL suportă o varietate de moduri de conectare, incluzând socketuri TCP/IP, socketuri UNIX și canale denumite (în Windows NT/2000). De asemenea, MySQL este furnizat împreună cu mai multe instrumente pentru administrarea acestuia. Versiunile pentru platforma Windows conțin un program cu interfață grafică (GUI), pentru configurare și management, numit winmysqladmin.

MySQL este unul dintre cele mai stabile sisteme de gestiune a bazelor de date, astfel încât numeroase corporații îl utilizează ca parte a strategiei lor de dezvoltare a aplicațiilor mission-critical business. Un alt motiv pentru care MySQL poate fi folosit cu succes în acest tip de aplicații este acela că în tabelele utilizate de acest sistem, începând cu versiunea 3.23 (tabele în format myISAM), pot fi stocate până la 8 milioane de Terabytes de date.

Sistemul de gestiune a bazelor de date relaționale MySQL este specific mediilor de operare UNIX, fiind SGBDR-ul preferat al webmaster-ilor cu site-uri Linux. Cu toate acestea există versiuni și pentru alte platforme (Windows, Mac OS X Server și OS/2). Sistemul MySQL este optimizat pentru platformele UNIX și Windows.

Distribuțiile MySQL conțin numai o parte sau toate componentele următoare:

serverul mysqld (sau diverse variante; de exemplu, distribuția standard client server pentru Windows oferă următoarele servere: mysqld, mysql-opt, mysqld-nt) care îndeplinește următoarele funcții: primește cererile clienților , obține accesul la bazele de date și furnizează clienților informațiile solicitate;

programe client (mysql și mysqlc), utilizate pentru conectarea la serverul MySQL și pentru transmiterea interogărilor către acesta;

programe utilitare (mysqladmin, mysqldump, myisamchk, isamchk etc.) folosite pentru administrarea sistemului MySQL;

fișiere antet și fișiere bibliotecă;

documentație (manual);

baza de date mysql care conține, printre altele, și tabelele de acordare a privilegiilor pentru utilizatori.

Distribuțiile MySQL sunt de două tipuri:

distribuții client; aceste distribuții nu conțin nici un server, dar conțin programe client pentru realizarea conexiunii cu un server instalat pe un alt calculator;

distribuții client-server; aceste distribuții conțin atât programele server, cât și programele utilitare. Dacă se dorește realizarea unor conexiuni cu serverul, chiar de pe calculatorul pe care acesta este instalat, trebuie instalate programele client inclusiv pe acest calculator.

MySQL nu suportă încă anumite caracteristici implementate în alte sisteme de gestiune a bazelor de date relaționale, ca de exemplu, următoarele:

subselecții;

extensia SQL Oracle SELECT … INTO TABLE … ;

tranzacții;

proceduri stocate (comenzi SQL compilate și stocate în server) și triggere (proceduri apelate în momentul apariției unui eveniment);

chei externe;

vederi.

MySQL este compatibil cu standardul ANSI SQL92. În plus, MySQL include câteva extensii față de acest standard care nu se regăsesc la alte SGBDR-uri:

tipurile de coloane MEDIUMINT, SET, ENUM și câteva dintre tipurile BLOB și TEXT;

atributele AUTO_INCREMENT, BINARY, NULL, UNSIGNED, ZEROFILL;

funcția LAST_INSERT_ID();

instrucțiunea LOAD DATA INFILE;

folosirea multiplă a clauzelor ADD, ALTER, DROP sau CHANGE într-o instrucțiune ALTER TABLE;

instrucțiunea SET OPTION;

clauza LIMIT pentru instrucțiunea DELETE;

clauza DELAYED pentru instrucțiunile INSERT și REPLACE;

folosirea instrucțiunii DROP TABLE cu cuvântul-cheie IF EXISTS;

clauza LOW_PRIORITY pentru instrucțiunile INSERT, REPLACE, DELETE și UPDATE;

instrucțiunile ANALYIZE TABLE, CHECK TABLE, OPTIMIZE TABLE și REPAIR TABLE;

instrucțiunea SHOW.

6. Integrarea datelor

Pentru omul de rând, thenologia informației (IT) este un univers misterios plin cu limbaje de programare indescifrabile și de componente hardware costisitoare. Ascultând o conversație între tehnicieni IT este aproape ca și când ai asculta o conversatie într-o limbă străină. Dar în ciuda acestei bariere de limbaj aparent impenetrabile, poate fi foarte important pentru cei care iau deciziile într-o companie să ințeleagă lumea IT-ului. Unul dintre cele mai importante concepte IT este integrarea datelor (data integration).

La prima vedere, integrarea datelor pare o idee simplă. Datorită faptului că multe companii își stochează informațiile pe mai multe baze de date, aceștia au nevoie să folosească datele din mai multe surse și să le asambleze într-un mod unitar. De exemplu, să ne închipuim că o companie de electronice se pregătește să lanseze un nou model de telefon mobil. Departamentul de marketing vrea să afle informații despre clienți din baza de date a departamentului de vânzări și să le compare cu informațiile primite de la departamentul de producție pentru a creea o listă de target-uri a vânzărilor. Un sistem bun de integrare a datelor ar permite departamentului de marketing să obțină informațiile din ambele surse într-o formă unificată, omitând informațiile irelevante căutării.

Ce sunt datele?

Datele pot fi orice tip de informație. Pot fi un fișier audio sau video. Pot fi un șir de caractere dintr-un document. Pot fi rezultatul excuției unui program. Sau pot fi informațiile ce descriu un fișier. Integrarea datelor se axează pe informație, nu pe fișiere.

În realitate, integrarea datelor este o disciplină complicată. Nu există o abordare universală a integrării datelor, și multe dintre tehnicile folosite de experții IT sunt încă în stadiul de evolutie. Unele abordări ale integrării datelor pot să funcționeze mai bine decât altele pentru o organizație. Ne vom uita mai de aproape la unele din strategiile generale folosite de către experții IT pentru a integra mai multe surse de date și vom pătrunde în lumea managementului bazelor de date.

6.1. Bazele integrării datelor

Integrarea datelor se concentrează mai ales pe baze de date. O bază de date este o colecție organizată de date. Este similară cu sistemul de fișiere, care este o structură organizațională pentru ca acestea să fie găsite, accesate și manipulate cu ușurință.

Există mai multe categorii de baze de date. Unii preferă să le clasifice în funție de tipurile de date stocate în acestea. Spre exemplu, se poate clasifica o bază de date ca fiind pentru fișiere media dacă totă informația conținută sunt fișiere video sau audio.

O altă metodă de clasificare se bazează pe felul cum sunt organizate datele. Argumentul de organizare al datelor într-o bază de date se numeste schema. O tehnică oragnizatională comună este folosirea tabelelor pentru a arăta relația între diferite tipuri de date. Tabelele sunt ca și foile de calcul. Coloanele definesc categoriile de date, în timp ce rândurile reprezintă datele. O bază de date care folosește această abordare se numeste o bază de date relațională.

Pentru a accesa informația dintr-o bază de date (indiferent cum este organizată), se folosesc interogările (query). O interogare este doar o solicitare de informații. Utilizatorii și aplicațiile pot invoca o interogare unei baze de date. O bază de date răspunde acestei interogări trimițând date care corespund parametrilor cerinței. Interogările se bazează pe un limbaj special cum este Structuctured Query Language(SQL).

Baza de date răspunde interogării generând o vedere a datelor. O vedere este o formă specifică de a afișa datele. Într-un sistem de integrare a datelor, vederea returnată arată doar datele care au legatură cu interogarea inițială.

Abordări ale integrării datelor

Bazele de date sunt destul de complexe, de aceea integrarea datelor este încă o disciplină în curs de dezvoltare cu toate că este veche de mai bine de 30 de ani. Scopul integrării datelor este să adune date din diferite surse, să le combine și să le prezinte într-un anumit fel încât să pară un tot unitar.

Să spunem că am vrea să plecăm într-o excursie și vrem să vedem cum este traficul înainte să ne decidem pe ce rută să mergem. Iată cum diferitele abordări ale integrării datelor ar rezolva aceasta interogare.

Abordarea integrării manuale ne-ar lăsa să facem singuri toată munca. Mai întai, ar trebui să știm unde să căutăm datele. Ar trebui să știm locația fizică pentru raportul de trafic cât și harta. Trebuie să obținem datele direct din baza de date respectivă, iar apoi să comparăm cele două seturi de date pentru a ne da sema care este ruta cea mai bună.

Dacă folosim abordarea interfetelor de utilizator comune, va trebui să muncim mai puțin. Am folosi o interfață cum este World Wide Web pentru a face interogarea. Rezultatele interogării vor apărea ca o vedere pe interfață. Va trebui în conținuare să comparăm raportul de trafic cu harta pentru a determina cea mai buna rută, dar măcar interfața se ocupa de localizarea și obținerea datelor.

Unele abordări ale integrării se bazează pe aplicații care fac toată treba. Aplicațiile , care sunt programe specializate, ar localiza, obține și ar integra informația în locul nostru. În timpul acestui process de integrare, aplicațiile trebuie să manipuleze datele pentru ca infomația dintr-o anumită sursă să fie compatibilă cu infomația din altă sursă. Aceasta ar însemna că am face o interogare către aplicație și aceasta va prezenta o vedere combinată a hărtii și a datelor despre trafic. Problema cu această abordare este faptul că aplicațiile devin complexe și dificil de programat odată cu cresterea numărulul de surse de date și a formatelor acestora.

Mai există și metoda de stocare a datelor în comun, cunoscută și ca înmagazinarea datelor(data warehousing). Folosind această motodă, toate datele din diferite baze de date pe care intenționăm să le integrăm sunt extrase, transformate și încărcate. Aceasta înseamnă că magazia de date mai întâi ia datele din diferite surse de date. Apoi, magazia de date convertește toate datele într-un format comun asfet încât seturile de date să fie compatibile între ele. Apoi încarcă aceste noi date în propria baza de date. Când facem o interogare, magazia de date localizează cea mai nouă informație pe care o are despre trafic și hartă. Apoi le va integra pe cele două și va trimite vederea înapoi. Acest sistem are avantaje și dezavantaje .

Majoritatea sistemelor de integrare pornesc de la presupunerea că scopul este să se genereze cât mai putină muncă petru utilizatorul final, de aceea acestea tind să se concentreze pe aplicații și pe tehnici de inmagazinare a datelor.

O magazie de date este o baza de date care stocheaza infomația din alte baze de date folosinf un format comun. Nu exista o definitie comuna care să indice ce sunt magaziile de date sau cum ar trebui să fie construite acestea. Astefel, exista mai multe modalitati de a creea o magazie de date, și o magazie de date poate să arate și să se comprte foarte diferit fata de alta

În general, rezolvarea interogarilor către o magazie de date dureaza foarte putin. Aceasta se datoreaza faptului ca magazia de date a facut deja majoritatea trebuirilor de extragere, convertire și combinare a datelor. Din punctul de vedere al utilizatorului inmagazinarea datelor este o metoda eficienta de a obține date integrate.

Din celălat punct de vedere (al managerului bazei de date), este o cu totul altă poveste. Acesta trebuie să depună mult efort în creare unui sistem de inmagazinare a datelor pentru a-l face eficace. Convertirea datelor adunate din diferite surse într-un format comun poate fi destul de dificil. Sistemul necesită o abordare consistentă în descrirea și codificarea datelor.

Descrierea datelor se numeste metadata. Metadata este folositoare la numirea și definirea datelor cât și la descrierea relației dintre mai multe seturi de date. Sistemele de integrare a datelor folosesc metadatele pentru a localiza informațiile relevante interogărilor.

Magazia de date trebuie să aiba o bază de date destul de mare pentru a stoca date adunate din mai multe surse. Unele magazii de date includ un pas în plus numit data mart. Magaziile de date preiau sarcina de agregare a datelor, în timp ce data mart-ul răspunde interogărilor utilizatorilor extrăgând și combinând datele adecvate din magazie.

O problemă cu magaziile de date ar fi faptul că informațiile din acestea nu sunt întotdeuna de actualitate. Acest lucru se datorează modului în care funcționează magaziile de date – extrag periodic infomația din alte baze de date. Dacă datele din aceste baze de date se schimbă între extrageri, rezultatele interogărilor către magazia de date nu vor conține cele mai noi și exacte vederi. Dacă datele dintr-un sistem se schimbă rar nu este o așa mare problemă. Pentru alte aplicații, însă, este o problemă.

O magazie de date s-ar putea să nu extragă datele destul de des, care face ca informațiile care depind de timp să nu fie de încredere. Pentru acest tip de aplicații, este mai bine să se folosească o altă abordare a integrării datelor.

Baze de date conectate

Pentru sistemele de integrare care se bazează pe informații care se schimbă des, abordarea înmagazinării datelor nu este chiar ideală. O modalitate prin care experții IT încearcă să rezolve această problemă este crearea de sisteme care extrag datele direct din surse individuale. Din moment ce nu exista o bază de date centralizată dedicată analizării, sortării și integrării datelor, în pregătirea pentru interogările utilizatorilor, aceste responsabilităti cad în sarcina altor părti ale sistemului.

Experții IT definesc sistemele de integrare în funcție de schema. Vederea unificată rezultată din procesarea unei interogări se numeste schema globala. Structura diferitelor surse de date și modul în care relaționează între ele se numeste schema sursă. Modul în care schema sursă și schema globală interrelaționează se numeste mapare.

Există două abordări principale în rezolvarea interogărilor în sistemele de date integrate: global-as-view și local-as-view. Fiecare abordare se concentrează pe o anumită parte din intregul sistem și are avantajele și dezavantajele sale.

Abordarea global-as-view se concentrează asupra schemei globale. Atâta timp cât sursa de date rămâne consistentă, această abordare funcționeaza bine. Este destul de ușor de schimbat setările schemei globale. Aceasta însemnă ca nu este greu de analizat același set general de date în mai multe feluri. Totuși, să adaugi și să ștergi surse de date în sistem este o problemă, deoarece per total afectează datele din tot sistemul.

Tehnica local-as-view folosește abordarea opusă. Se concentrează asupra surselor de date. Cât timp schema globala ramane constanta, este usor de adaugat și de scos surse de date din sistem. Schema cauta același tip de date și de relatie în noile surse de date. La aceasta abordare, schimbarea parametrilor schmei globale este destul de dificil. Dacă se incearca analiza surselor de date într-un alt mod, trebuie redefinit întregul sistem.

Există mai multe companii care ofera soluții de sisteme pentru integrarea datelor. Cele mai cunoscute sunt Business Objects, IBM, Informatica, Microsoft, Oracle și SAS. Tabelul de mai jos ilustrează ce funcții îndeplinesc diferitele platforme de integrare a datelor oferite de acestea.

Pe lângă aceste produse există și platorme de integrare freeware cum sunt XAware, Fusion Integration Platform.

6.2. Web Services Description Language

WSDL (Web Services Description Language) sau Limbajul de Descriere a Serviciilor Web este un limbaj bazat pe XML ce oferă un model de descriere a serviciilor web. Versiunea curentă a WSDL este 2.0. Versiunea 1.1 nu a fost acceptată de W3C (World Wide Web Consotium), deoarece pentru fiecare proiect realizat trebuie să existe o recomandare de la W3C. WSDL 1.2 a fost redenumit WSDL 2.0 deoarece a adus modificări substanțiale față de WSDL 1.1. Spre deosebire de WSDL 1.1, care accepta ca metode de interogare doar GET și POST, WSDL 2.0 acceptă toate metodele de interogare HTTP care există. Deasemenea WSDL 2.0 oferă un suport mai bun pentru așa-numitele RESTful Web Services (servicii Web REST), mult mai simplu de implementat. Totuși suportul acestei specificații este încă slab dezvoltat în Software Development Kit (SDK) pentru Serviciul Web, care adesea oferă unelte doar pentru WSDL 1.1.

WSDL defineste serviciile ca o colectie de porturi, sau puncte terminale într-o rețea. Specificarea WSDL oferă un format XML pentru documentele de această categorie. Definirea abstractă a porturilor și mesajelor este separată de instanță, sau de întrebuințarea lor concretă, aceasta permițând reutilizarea acestei definiri. Un port se definește ca asocierea unei adrese de rețea cu o legătură reutilizabilă, iar o colecție de porturi definește un serviciu. Mesajele reprezintă descrierile abstracte ale datelor ce urmează a fi interschimbate, în timp ce tipurile de porturi reprezintă colecțiile abstracte ale operațiunilor suportate. Protocolul concret și formatul de date al specificației pentru un anumit tip de porturi constituie o legătură reutilizabilă, unde mesajele și operațiunile corelează cu un anumit protocol din rețea și cu un format de mesaje. Pe această cale, WSDL descrie interfața publică pentru serviciile web.

WSDL este adesea utilizat în combinație cu SOAP și XML Schema pentru a oferi servicii Web prin intermediul Internetului. Un program client conectându-se la un serviciu web poate citi WSDL pentru a determina ce funcții sunt permise de acest server. Orice tip de date special folosit și implementat în fișierul WSDL în formă de XML Schema. Deasemenea clientul poate utiliza SOAP pentru ca eventual să cheme una din funcțiile conținute 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 funcționare a serviciului ca o parte a unui proces de afacere (Business Process Execution Language).

Iata un exemplu de cum arata un fișier WSDL

<?xml version="1.0"?>

<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl"

xmlns:tns="http://example.com/stockquote.wsdl"

xmlns:xsd1="http://example.com/stockquote.xsd"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>

<schema targetNamespace="http://example.com/stockquote.xsd"

xmlns="http://www.w3.org/2000/10/XMLSchema">

<all>

</all>

</complexType>

</element>

<all>

</all>

</complexType>

</element>

</schema>

</types>

</message>

</message>

</operation>

</portType>

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<soap:operation soapAction="http://example.com/GetLastTradePrice"/>

<input>

<soap:body use="literal"/>

</input>

<soap:body use="literal"/>

</output>

</operation>

</binding>

<documentation>My first service</documentation>

<soap:address location="http://example.com/stockquote"/>

</port>

</service>

</definitions>

Limbajul poate fi descris ca și având doua nivele:

nivelul de definire al serviciului descrie proprietăti abstracte:

tipuri de date

tipuri de mesaje

opereații

servicii

nivelul de lagatura descrie proprități concrete:

protocoale

formate de date

Un documet WSDL se constituie din seturi de definitii de urmatoarele tipuri:

types – conțin elementul Schema XML și definiții de tipuri

message – consistând din una din

un număr sau părti numite introduse de elementele Schemei XML, sau

un tip cu o singură parte introdus de către tipul Schemei XML

portType – descrie un set de operații, fiecare fiind una din cele patru:

one-way: primește un mesaj de intrare,

request-response: preimește un mesaj de intrare și răspunde cu un mesaj de ieșire (ca și RPC),

solicit-response: trimite un mesaj de ieșire și apoi premește un mesaj de intrare, sau

notification: trimite un mesaj de ieșire

binding – selectează protocoalele de comunicare și formatele de date pentru fiecare operație și mesaj

service – descrie o colecție de porturi cu nume, fiecare în asociere cu o legatura și o adresa de retea .

Un mecanism de import permite modularizarea definițiilor.

6.3. Simple Object Access Protocol

SOAP, inițial definit ca și Simple Object Access Protocol, este un protocol pentru schimbul de informații structurate în cadrul implementărilor Serviciilor Web în rețelele de calculatoare. Formatul său are la baza XML-ul (eXtensible Markup Language), și de obicei și alte protocoale de la nivelul aplicație (cel mai cunoscut este Remote Procedure Call (RPC) și HTTP) pentru negocierea mesajelor și transmiterea lor. SOAP poate constitui stratul de baza al stivei protocoalelor din cadrul serviciilor web, deoarece pune la dispoziție un format de baza al mesajelor pe baza căruia se pot construi servicile web.

Un mesaj SOAP poate fi trimis către un un site unde este implementat un serviciu web (de exemplu, o baza de date cu prețuri de locuințe) conținând parametrul necesar căutării. Acest site va returna un document în format XML cu datele rezultate (preț, lacație, caracteristici, etc). Deoarece datele sunt returnate într-un format standardizat, acestea pot fi integrate direct într-un alt site.

Arhitectura SOAP se constituie din câteva nivele de specificații pentru formatul mesajului: MEP (Message Exchange Patterns) care definește legăturile de la nivelul de transport din cadrul protocolului, modele de procesare ale mesajelor, și capacitatea de extindere a protocolului. SOAP este succesorul XML-RPC, de la care a imprumutat modul de transport și invelișul, header-ul și corpul din alte surse.

Istoria SOAP

SAOP în engleza vine de la Smple Object Access Protocol dar s-a renunțat la acest acronim odata cu versiune 1.2 a standardului. Versiunea 1.2 a devenit o recomandare a W3C în 24 iunie 2003. Acest acronim este adesea confundat cu SOA (Service-Oriented Architecture), dar SOAP este destul de diferit fața de SOA.

SOAP a fost creat inițial de către Dave Winer, Don Box, Bob Atkinson și Mohsen Al-Ghosein în 1998. Specificațiile SOAP sunt în prezent menținute de Grupul de Lucru al Protocolului XML din cadrul World Wide Web Consotium.

Metode de transport

SOAP folosește ca și protocol de transport în internet un protocol la nivel de aplicație. Criticii au sustinut ca acest lucru este un abuz al acestor protocoale, deoarece acestea nu au fost create cu acest scop și deci rolul lor nu este indeplinit foarte bine.

Atât SMTP cât și HTTP sunt protocoale valide de nivel apliație folosite la transport de către SOAP, HTTP a câștigat teren deoarece funcționează bine cu infrastructura internetului din ziua de azi. Mai exact, HTTP funcționează bine cu firewall-urile de rețea. SOAP poate fi folosit și cu HTTPS (care este același protocol ca și HTTP la nivel aplicație, dar folosește un protocol criptat la baza) cu autentificare simplă sau mutuală. Aceasta este metodă susținută de WS-I pentu a furniza securitate serviciilor web după cum s-a meționat în WS-I Basic Profile 1.1. Acesta este un avantaj major asupra altor protocoale aflate în distribuție cum sunt GIOP/IIOP sau DCOM care sunt în mod normal filtrate de către firewall-uri. O altă posibilitate ar fi SOAP împreună cu AMOP, pe care unele implementări o suportă.

XML a fost ales ca și formatul standard al mesajului datorită folosirii acestuia de către marile companii cât și în dezvoltarea de tip open source. Deasemenea, tranziția la implementări bazate pe SOAP a fost usurată și de o varietate mare de unelte disponibile distribuite gratuit. Sintaxa cât de cât lungă a XML-ului poate fi atât un benficiu cât și un dezavantaj. În timp ce ușurează cititul pentru oameni, ușurează detecția erorilor, și evită problemele de interoperabilitate cum este byte-order, poate încetinii în același timp viteza de procesare. De exemplu CORBA, GIOP, ICE, și DCOM folosesc formate ale mesajelor mult mai scurte. Pe de alta parte, există componente hardware care pot accelera procesare mesajelor XML. XML-ul binar este în curs de explorare ca și mijloc de a dinamiza necesarul de debit pentru XML.

Exemplu de mesaj SOAP

Cerere SOAP

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>

<req:echo xmlns:req="http://localhost:8080/axis2/services/MyService/">

<req:category>classifieds</req:category>

</req:echo>

</soapenv:Body>

</soapenv:Envelope>

Răspuns SOAP

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">

<soapenv:Header>

<wsa:ReplyTo>

<wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>

</wsa:ReplyTo>

<wsa:From>

<wsa:Address>http://localhost:8080/axis2/services/MyService</wsa:Address>

</wsa:From>

<wsa:MessageID>ECE5B3F187F29D28BC11433905662036</wsa:MessageID>

</soapenv:Header>

<soapenv:Body>

<req:echo xmlns:req="http://localhost:8080/axis2/services/MyService/">

<req:category>classifieds</req:category>

</req:echo>

</soapenv:Body>

</soapenv:Envelope>

Avantajele și dezavantajele lui SOAP

Mulți specialisti au discutat despre avantajele și dezavantajele tehnice ale lui SOAP în comparație cu alte tehnologii și despre domeniul intenționat de folosire pentru care a fost creat.

Avantaje

Folosind SOAP peste HTTP permite comunicarea mai ușoară prin proxi-uri și firewall-uri decât execuția de la distanță a tehnologiilor antrioare

SOAP este destul de versatil pentru a permite folosirea diferitelor protocoale de transport. Stivele de baza folosesc HTTP ca și protocol de transport, dar se pot folosi și alte protocoale (ex. SMTP)

SOAP este independent de platformă.

SOAP este independent de limbaj.

Dezavantaje

Datorită formatului prolix al XML-ului, SOAP este considerabil mai lent decât tehnologiile intermediare cu care se află în concurență așa cum este CORBA. Acest lucru nu este o problemă când sunt trimise doar mesaje de dimensiuni mici. Pentru a spori performața pentru cazul special al obiectelor incastrate binar, a fost introdus Mecanismul de Otimizare al Transmisiei Obiectelor

Când se bazeaza pe HTTP ca și protocol de transport și nu folosește Adresarea- WS sau un ESB, rolurile părților care interacționează sunt fixe. Doar o singură parte (clientul) poate folosii seviciile celuilalt. Dezvoltatorii trebuie să folosescă scrutinul în loc de notificare în aceste cazuri uzuale.

Majoritatea cazurilor de folosire al HTTP-ului ca și protocol de transport se fac neținând cont de cum va fi modelată operația în HTTP. Datorită acestui lucru, nu există cale de a știi dacă metoda folosită este adecvată operației. Aceasta duce la dificultatea de a analiza protocolul operației de la nivelul aplicație, cele mai bune rezultate fiind sub-optime (dacă legătuara pe baza de POST este folosită pentru o aplicație în care HTTP-ul ar fi modelat cu o operație de tip GET). Arhitectura REST a devenit o alternativă a serviciilor web care folosește în mod adecvat metodele definite de către HTTP.

Când se folosește HTTP ca și protocol de transport un firewall creat pentru a permite doar navigare pe web nu poate pur și simplu să dea voie tuturor pachetelor care folosesc HTTP; în schimb trebuie să facă o analiza mai detailiată (și deci mult mai puțin eficientă) a pachetelor HTTP.

Deși SOAP este un standard deschis, nu toate limbajele oferă suportul necesar. Java, .NET și Flex oferă o integrare a SOAP și/sau un suport IDE excelent. Python și PHP oferă un suport mult mai slab.

6.4. Integrarea datelor folosind tehnologia XAware

Softul pentru integrarea datelor, XAware, furnizează o soluție elegantă la multe dintre cele mai complexe probleme din industrie. Prin definirea stratului de abstracție, și prin afișarea obiectelor informaționale ca și servicii, XAware furnizează ceea ce în industrie se numeste Integrare Orientată pe Servicii (SOI). SOI duce la reducerea complexității în accesarea informației, reutilizabilitate, reduceri de cost, și returnarea rapidă a investiției. XAware reduce sau chiar elimina multe din problemele cauzate de mediile de date complexe. Setul de unelte pentru integrarea datelor inclus în XAware are la bază o Arhitectură Orientată pe Servicii (SOA), și este construit pe standarede tehnice de bază cum sunt J2EE, XML, Eclipse, REST și Spring, și suportă și alte standarde ale industriei cum sunt ACORD, CSIO, EDI, HL7 și NIEM.

Interfața XAware Designer

XAware face legatura între activitatea comercială și accesul fizic al datelor prin faptul că permite clienților să creeze un nivel de servicii care este alcătuit din componente logice ale serviciilor de date și procesarea condițională. Odată create aceste servicii pot fi dirijate și refolosite pentru a rezulta noi compentete în mediul de afacere.

XAware este un plug-în pentru mediul de lucru Eclipse și este gata de lansare pentru a rezolva problemele cheie din industrie cum ar fi Servicii Finanaciare, Guvernământ și Sănătate. Nivelul de abtractizare bazat pe XML al softului XAware include câteva nivele distincte de funcționalitate și componente software. Acestea sunt ilustrate în Figura 1 în relație cu aplicații care folosesc nivelul de abstractizare XML, și sursele de date accesate. Componentele software sunt listate în Tabelul 1, și vor fi descrise mai în detaliu în următoarele paragrafe.

Tabel 1. Componentele softului XAware Designer

Figura 1. Componentele softului XAware (www.xaware.org)

6.4.1. Mediul de proiectare XAware

Mediul de proiectare XAware este un plug-în pentru Eclipse folosit la crearea, testarea și deployment-ul serviciilor web compatibile cu standardele actuale și pentru aplicații de integrare a datelor. Acest soft este prvăzut cu un mediu vizual cu facilități de tip drag-and-drop, debug, și mediu pentru deployment-ul pe server. Multe dintre aceste facilități în XAware sunt de tip wizard, care sporesc procesul de dezvoltare al aplicațiilor. Serviciile sunt construite grafic ca și vederi XML (numite BizDocuments) prin combinarea schemelor și a modelelor de date XML corespunzătoare standardelor, adaptorilor configurabili (numiti BizComponents), conectorilor și a regulilor de dezvoltare.

Componentele dezvoltate cu XAware sunt reutilizabile. De exemplu, odată creată o componentă pentru accesarea unui anumit set de date, aceasta poate fi folosită în oricâte servicii. În catalogul de componente XAware sunt descrise trăsăturile cheie ale acestor componente. Acesta găsește și componentele posibil reutilizabile pentru o anumită aplicație.

Engine-ul XAware

Engine-ul XAware este nucleul setului de unelte XAware. Aesta este un server de integrare a informației care răspunde cu vederi XML ale datelor, diminuând efortul aplicațiilor în accesarea informațiilor într-o întreprindere. Engine-ul XAware funcționează ca un server de transformare, ca motor de procesare a regulilor, și ca o baza de date XML virtuală. Engine-ul Xaware are mai multe fire de execuție, este scalabil, robust, și oferă posibilitatea de procesare a tranzacțiilor cu volum mare. Engine-ul XAware este în esență un motor de procesare ale cărui instrucțiuni sunt fișierele de metadate ale XAware. Aplicațiile client cer o anumită vedere XML. Engine-ul XAware face asocierea cererii cu un anumit set de fișiere de metadate, și procesează aceste fișiere, returnând rezultatul aplicației care a efectuat cererea.

Fișierele de metadate XAware

Vederile XML sunt definite prin mai multe caracteristici cum ar fi formatul XML, cereri către surse de date, reguli de transformare, și reguli de procesare, care sunt stocate ca și “metadate”. Metatdatele XAware sunt stocate ca și XML, în trei tipuri de fișiere numite fișiere de metadate. În Figura 2 este ilustrată relația fișierelor de metadate care compun vederile XML. În Tabelul 2 este definit fiecare tip de fișier de metadate.

Figura 2. Relația fișierelor de metadate (www.xaware.org)

Tabel 2. Tipuri de fișiere de metadate (www.xaware.org)

În XAware sunt folosiți diferiti termeni pentru aceste fișiere. Figura 3 ilustrează structura de fișiere de metadate folosind termenii specifici XAware. Tabelul 3 definește acești termeni.

Figura 3. Structura fișierelor de metadate (www.xaware.org)

Tabel 3. Termenii folosiți în XAware pentru fișierele de metadate

Pe lângă numele specifice XAware pentru fiecare fișier de matadate, se poate observa din Figura 7 că o anumită combinație de BizDocument, BizComponents, și BizDrivers pentru o anumită vedere XML are deasemenea un nume, “BizView”. Un BizView este același lucru cu o vedere XML. Este o vedere XML dată de un set de fișiere de metadate.

BizDocument

Un BizDocument XAware conține un set ierarhic de elemente reprezentând vederea XML a datelor. Pe lângă definirea formatului XML, BizDocument-ul mai poate conține instrucțiuni de procesare, instrucțiuni de transformare, și referințe către seturi de date generate dinamic numite BizCompenente. Fiecare element din BizDocument poate fi un element static XML, sau un element dinamic. Elementele statice din BizDocument sunt pur și simplu returnate nemodificate către clientul care a făcut cererea. De fapt cel mai simplu BizDocument este dat de un simplu fișier XML fără să conțină nici un fel de elemente dinamice. Elementele dinamice conțin instrucțiuni de procesare, cum sunt instrucțiunile condiționale, comenzi de manipulare ierarhica, sau referinte către BizComponente sau către alte BizDocumente pentru execuție.

Deoarece BizComponentele au o interfață bazată pe XML, ascunzând complexitatea sursei de date, toate instrucțiunile de procesare din BizDocumente operează pe structuri XML. Aceste comenzi sunt ambivalente față de sursa de date inițială, și operează la fel pe XML static, sau pe XML generat din surse relaționale, non-relaționale, sau orice altă sursă. De exemplu, această stratificare permite o joncțiune între un RDBMS și o sursă de date “mainframe”. Elementele dintr-un BizDocumet sunt procesate prin parcurgerea în adâncime. Aceasta însemnă că fiii unui element sunt procesați înaintea fraților săi.

Pe lângă aceasta, multe BizComponente crează un set de date dintr-un XML care de fapt conține alte elemente dinamice. Odata executat un astfel de BizComponent, rezultatul său este apoi procesat, posibil accesând alte surse de date și creând alte elemente dinamice, toate fiind executate la rândul lor. BizDocumentele pot fi deasemenea defintie cu o interfață care acceptă unul sau mai mulți parametrii. Fiecare parametru este o valoare scalară, cum ar fi un string sau un întreg. Totodată, un BizDocument poate să primească la intrare un document XML. Parametrizarea folosind fie un scalar sau un XML permite ajustarea procesării BizDocument-ului pentru un anumit scop. De exemplu, crearea unei vederi XML a unui client va fi cel mai probabil construit să accepte un parametru de intrare care menționează ID-ul clientului sau poate un string de căutare al clientului. Valoarea parametrului primit în momentul rulării va pune în mișcare returnarea datelor din sursa de date.

O întrebuințare uzuală a unui asemenea parametru este referirea lui în clauza “WHERE” a unei cereri SQL pentru a selecta doar datele necesare. Astfel parametrul acționează ca și un filtru furnizând aplicației doar datele cerute. Toate fișierele de metadate din XAware au capacitatea de a defini un parametru de interfață care ghidează procesarea în cadrul componentei. Totodată BizDocumetele permit referențierea valorilor dinamice din orice punct al BizDocument-ului. Referențierile folosesc o sintaxă similară cu XPath. Un exemplu des întâlnit este generarea setului de date dintr-o singură sursă, apoi referențierea unui element generat într-un parametru într-un alt BizComponent. Acesta este un proces tipic în înlănțuirea datelor, spre exemplu, unde un set de date conține o cheie într-un al doilea set de date conținut într-un alt sistem. Cheia este mai intâi regăsită folosind un BizComponent, apoi elementul generat dinamic este referențiat în parametrul celui de-al doilea set de date, permițând extragerea informațiilor necesare.

BizComponent

Un BizComponent este componentă dinamică de date a unei vederi XML. Un BizComponent poate extrage date, insera noi date, înprospăta date într-o sursă de date, sau poate trimite un set de date unei alte surse de procesare. BizComponentele pot deasemenea permite competențe de procesare fără a fi asociate cu citiri sau scrieri, de exemplu, pentru a aplica un algoritm pe un set de date. BizComponentele sunt menite să fie construite ca și componente reutilizabile reprezentând manipularea unui anumit set de date. De exmplu, BizComponentele pot fi construite pentru a extrage o listă a clienților din baza de date a unei aplicații. Odata definit, acest BizComponent poate fi apelat din multe alte BizDocumente. BizComponentele crează un strat de abstracție bazat pe XML pentru BizDocumente.

În timp ce BizComponentele au o mare varietate de interfețe către multe surse de date posibile într-o întreprindere, toate expun o interfață comună bazată pe XML către BizDocument. Astfel, BizComponent-ul ascunde complexitatea comunicarii cu alte surse de date.

BizDocument-ul poate manipula surse de date într-un mod consistent folosind o interfață comună bazată pe XML către BizComponente. Odată ce seturile de date sunt converitite în XML de către BizComponent, comenzile BizDocument-ului pot manipula și procesa XML-ul fără a ține cont de sursa reală de date. Acest lucru permite operații ca joncțiuni XML, modificări ierarhice, și operații condiționale.

Când un BizDocument apelează un BizComponent, acel BizComponent este încărcat și executat, generând rezultate XML. Apelul unui BizComponent include o referențiere a fișierului de meatadate adecvat, și orice parametrii necesari BizComponent-ului. Apelul BizComponent-ului se comportă ca și un apel de metodă sau procedură într-un limbaj de programare procedural. Rezultatul XML înlocuiește apelul BizComponent-ului în cadrul BizDocument-ului.

Un BizComponent este apelat dintr-un BizDocument sau dintr-un alt BizDocument. BizComponentele pot fi conținute asfel încât un BizComponent să apeleze unul sau mai multe BizComponente. De exemplu, se pot construi BizComponente pentru a interoga mai multe baze de date rezultând într-o vedere agregată a datelor.

BizDriver

Un BizDriver permite unui BizComponet să se conecteze la o sursă de date. Un BizDriver este de obicei necesar pentru fiecare sursă de date pe care o va accesa BizComponent-ul. Unele tipuri de BizComponente, ca HTTP și FTP, nu necesită un BizDriver pentru BizComponent. Acestea sunt în general BizComponente care execută o acțiune, cum ar fi copierea unui fișier de la distanță folosind FTP. Mai multe BizComponente pot refolosi orice BizDriver atâta timp cât se conectează la aceeași sursă de date. Ca și în cazul BizDocumentelor și a BizComponentelor, un BizDriver poate avea parametrii. Această posibilitate este cel mai des folosită pentru a transmite informații legate de conexiune, pentru a specifica informații de autentificare și de autorizare cum sunt numele de utilizator și parola sursei de date.

Interfețele de aplicație

Interfețele de aplicație permit aplicațiilor să comunice cu Engine-ul XAware prin mai multe protocoale. Vederile XML și fișierele de metadate asociate acestora (BizDocumetn, BizComponent și BizDriver) sunt create și lansate motorului XAware din spațiul de lucru. Interfețele de aplicație includ atât interfețe sincrone cât și asincrone, dând flexibilitate în accesarea unei anumite vederi pentru a îndeplinii cerințele aplicației. Interfețele de aplicație includ EJB, Servlet, Java API, SOAP, COM, ISAPI, HTTP, și JMS.

Conectorii

Conectorii sunt folosiți pentru a permite conectivitatea sincronă și asincronă între o aplicație client și Engine-ul XAware cât și pentru aplelarea unui serviciu sau a unei aplicații. Conectorii standard sunt oferiți pentru SOAP / WSDL, JMS, EJB, HTTP și HTTP. Un API Java este deasemenea furnizat pentru a accesa direct servicii web sau pentru a accesa aplicații încastrate XAware.

Adaptorii

Adaptorii sunt folosiți pentru a permite conectivitatea între Engine-ul XAware și sistemele de date. Folosind XAware Designer, utilizatorii pot configura rapid adaptori pentru utilizarea lor în cadrul serviciilor web sau în aplicații de integrare. Printr-un proces de tip “wizard”, utilizatorii pot configura adaptorii pentru a mapa semantic datele între sursă și structura vizată, și transformarea datelor aplicând direct expresii logice complexe. XAware include un set vast de adaptori și furnizează unelte pentru crearea propriilor adaptori, când este necesar. XAware poate să construiască, deasemenea, adaptori care să indeplinească orice nevoi de conectare.

Ciclul de dezvoltare pe baza vederilor XML

Folosind XAware, un constructor creează o vedere XML în ciclul de dezvoltare standard care include proiectarea, testare, și deployment-il către Engine-ul XAware pe baza vederilor XML. În urmatoarele pragrafe va fi descris acest cilcu.

Proiectarea

XAware designer este folosit pentru a proiecta vederi XML ale datelor prin crearea fișierelor de metadate XAware necesare. Procesul de proiectare cuprinde urmatorii pași:

Definirea formatului vederii XML. O schemă XML sau un exemplu poate fi importată pentru acest scop, sau poate fi creată. Acest format XML reprezintă vederea XML. Pentru o vedere de ieșire, BizDocument-ul va genera un XML cu acest format. Pentru un o vedere XML de intrare, BizDocument-ul va aștepta un XML cu acest format ca și intrare, și va procesa XML-ul într-una sau mai multe surse de date.

Definirea interfeței BizDocument-ului. Fiecare vedere poate fi parametrizată, deci ca și proiectanți, trebuie să decidem ce informație este trimisă către BizDocument pentru a determina ce informație este returnată sau procesată.

Transformarea structurii XML în BizComponente. Când scheama XML sau un exemplu este inportată în XAware Designer, acesta afișează ierarhia statică a structurii documentului. Urmatorul pas, și cel mai important, este convertirea structurii statice în structură generată dinamic sau XML procesat. XAware Designer este optimizat pentru a îndeplinii această sarcină, prin permiterea proiectantului de a selecta o secțiune de XML, apoi crearea unui BizComponent petru a citit sau a scrie acele date din/în sursa de date. Transformare în BizComponente este un proces iterativ, fiecare secțiune a ierarhiei este tratată la un moment dat, posibil mapând fiecare secțiune într-o alta sursă de date.

Permite controlul fluxului de execuție dacă este necesar. Unele vederi XML necesită controlul fluxului de execuție pentru a fi procesate în mod corect. De exmplu, rezultatele unui BizComponent pot să trebuiască evaluate pentru a stabili următorul BizComponent care va fi procesat. Deși este ultimul pas din acest proces, inserarea de logici de control în fluxul de excuție poate avea loc în orice puct al procesului de proiectare.

Testarea și depanarea

XAware Designer conține funcțiuni necesare petru testarea și depanarea unei vederi XML înainte de deployment. În orice moment al procesului de proiectare, proiectantul poate executa BizDocument-ul pentru a vedea și verifica corectitudinea rezultatlor intermediare. Când este executat un BizDocument, se afișează un diagnostic detailiat în fereastra de log și în fișierul de log. Structura de apelare a componentelor din Profilul de Execuție arată fiecare BizDocument și BizComponent care este apelat, și timpul de excuție pentru fiecare. Este prezent și un depanator, care permite stabilirea de puncte cheie și evaluarea stării fiecărui pas al procesului de excuție. Facilități ca substituirea varibilelor, formatarea cererilor către sisteme, și rezultatele comenzilor sunt disponibile pentru a fi vizualizate. Totodată, când o sursă de date permite diagnosticarea erorilor, acea informație este disponibilă proiectantului.

Deployment

Deployment-ul aplicațiilor XAware implică împachetarea tuturor fișierelor afiliate într-o arhivă, numita o arhivă XAware (XAR). Pot fi impuse metode de securizare în timpul procesului de împachetare pentru a restricționa privilegiile de execuție a BizDocumentelor și a BizComponentelor. Fișierul arhivă este apoi lansat pe server, unde vederile XAware devin disponibile imediat. Totodată, o interfață a serviciului web poate fi creată, caz în care este generat un fișier WSDL pentru a fi accesat de către aplicațiile web orientate pe servicii. XAware poate fi configurat să ruleze în trei configurații diferite: server de palicatii, server web, stand-alone.

Server de aplicații

Opțiunea standard de deployment pentru XAware conține un server de aplicații J2EE de la unul din cei mai mairi comercianți de servere, printre care IBM WebSphere, BEA Systems, WebLogic Server, JBoss, și Sun. Pentru organizații care au deja un server de aplicații, Engine-ul XAware poate fi lansat către servere de aplicații de la BEA Systems, IBM, Sun, și Oracle. O versiune de dezvoltare este deasemenea disponibilă, care include cunoscutul server de aplicații JBOSS. Din mediul serverului de aplicații, Engine-ul XAware poate fi configurat să ruleze ca servlet, EJB, sau mesaj de tip bean.

Server Web

Engine-ul Xaware poate fi configurat să ruleze împreună cu un server web, fără a fi necesar un server de aplicații J2EE. În această configurație, vederile XML pot fi afisate folosind SOAP pentru invocarea serviciilor web, sau folosind comenzi HTTP cum sunt GET sau POST. Alte tehnologii pentru interfețe de aplicație, cum este EJB, nu sunt disponibile.

Stand-alone

Funcțiunile Engine-ului XAware pot fi incluse în alte aplicații folosind configurația de tip stand-alone. Astfel, softuri care îndeplinesc rolul de server sunt împachetate într-o arhiva Java (JAR), și pot fi accesate direct de către un alt program Java prin interfața de programare a aplicației.

6.4.2. Metodologia construirii unui proiect XAware

Mediul de proiectare XAware combină folosirea wizard-urilor și a template-urilor pentru a facilita construirea fișierelor care constituie un BizView XAware care vor defini servicul web. Pentru construirea unui serviciu web folosind XAware există mai mulți pași care trebuie urmați.

Pașii majori pentru construirea unui serviciu web

Prima dată vom crea un nou proiect.

Apoi, vom creea un BizDocument.

Pasul următor este construirea BizComponet-ului. Există mai multe tipuri de BizComponent-uri, pentru aplicația de față vom folosi un BizComponent pentru SQL, cu ajutorul căruia vom face interogările în baza de date. Tot la acest pas vom creea și BizDriver-ul necesar pentru a ne conecta la baza noastră de date MySQL.

Odată ce am terminat testarea componentelor vom împacheta și vom face deployment-ul serviciului web. Package Assembly Tool este unealta care ne va ajuta să împachetăm fișierele serviciului web într-o arhivă căreia i se va face deployment-ul pe server. După această operație se mai pot face testări pentru a ne asigura că toate conexiunile funcționează și că datele vor fi returnate de la client, după cum s-a intenționat.

Pentru a accesa noul serviciu folosind SOAP, vom genera un fișier WSDL (Web Services Description Language), care ne va expune BizDocument-ul folosind SOAP pentru a invoca un Serviciu Web.

În continuare vor fi prezentați pașii descrisi mai sus în detaliu.

Crearea unui Proiect Nou

Folosiți pașii următori:

Odată pornit XAware Designer, selectați File | New | Designer Project. O noua fereastra de proiectare va fi afișată.

Introduceți numele proiectului în câmpul Project Name. Numele proiectelor nu trebuie să conțină spații.

Ne vom asigura că spațiul în care vom salva fișierele este cel dorit. Dacă dorim ca fișierel să fie salvat în spațiul de lucru stabilit la pornirea XAware vom bifa căsuța Use default din panoul Project contents. Dacă dorim să salvăm fișierele în altă locație debifăm această casuță și navigăm până la directorul unde dorim să salvăm fișierele proiectului.

Fecem click pe Finish pentru a adauga proiectul în panoul Project Navigator.

Un nou proiect este aduăgat în spațiul de lucru.

Crearea unui BizDocument Nou cu ajutorul wizard-ului

Wizard-ul pentru creare unui Nou BizDocument ne permite să construim BizDocumente în timpul procesului de construcție al aplicațiilor XAware. Acest wizard furnizează câteva opțiuni în caz că dorim să generăm un BizDocument de la zero sau dintr-o schemă.

Folosiți pașii următori:

În XAware Designer facem click dreapta pe proiectul nou creat în panoul Project Navigator apoi New | BizDocument și wizard-ul va porni.

Va aparea fereastra cu titlul BizDocument File Name.

Tastăm sau selectăm numele proiectului în care vom vom creea BizDocument-ul, în câmpul “Enter or select parent folder”

Introducem numele BizDocument-ului în campul “File name”, având grijă să păstrăm extensia .xbd.

Facem click pe Next.

Va aparea fereastra cu titlul “Select XML Schema / WSDL File”.

Selectăm opțiunea “Generate a BizDocument without an XNL schema reference”.

Facem click pe Next.

Va aparea fereastra cu titlul “Select Options”.

În caseta “Service options” bifăm căsuta “Add BizComponent call”, dacă nu este bifată, și apoi selectăm tipul BizComponent-ului pe care îl vom construi. În cazul de față selectăm SQL BizComponent. După încheierea wizard-ului de creare al BizDocument-ului va porni automat wizard-ul pentru creare BizComponent-ului și se vor urma pașii majori descrisi mai jos.

Facem click pe Finish.

Construire unui BizComponent cu ajutorul wizard-ului

După completarea pasului anterior va aparea următoarea fereastră:

Definirea BizDriver-ului

Folosim următorii pași:

Lăsăm optiune de creare unui BizDriver nou. Pentru BizComponentele viitoare similare cu acesta (care vor interoga aceeași bază da date MySQL și cu aceeași autentificare) vom selecta opțiunea de folosire a unui BizDriver existent după care se va sării peste următorii pași.

Introducem calea și numele BizDriver-ului. Dacă dorim ca acesta să fie salvat în proiectul curent lăsăm calea neschimbată și introducem doar numele BizDriver-ului.

Deoarece se va folosi o bază de date MySQL vom avea nevoie de un conector specific acestei baze de date. XAware nu furnizează acest conector dar ne permite să adăugăm orice alt tip. Conectorul necesar pentru o astfel de conexiune este o arhivă java și se numește mysql-connector-java-5.0.7-bin.jar. Mai întâi vom copia acest fișier în directorul dynamic din calea de instalare al soft-ului XAware. Facem click pe Browse for JARs după care ne va aparea următoare fereastra:

Adăugarea arhivelor JAR

Facem click pe Add după care navigăm până la directorul unde am copiat arhiva Java. Ok și se revine la fereastra inițială. Acum suntem gata să configurăm BizDriver-ul

Se completeaza câmpul cu numele de utilizator și parola cu care ne vom conecta la baza de date. Deoarece în cazul de fata folosim o bază de date MySQL, tipul protocolului va fi cel specific, având deasemenea host-ul, portul și numele bazei de date corespunzătoare. Clasa driver-ului va fi com.mysql.jdbc.Driver .

Avem posibilitatea de a testa conexiunea la baza de date.

Salvăm BizDriver-ul nou creat pentru a-l putea folsi ulterior și în cazul altor BizComponente similare.

Click Next.

Definirea parametrilor de intrare ai interfeței.

Definirea parametrilor de intrare ai interfeței

Parametrii de intrare ai interfeței sunt valori după care se fac interogările în baza de date. De obicei sunt folosiți în clauza WHERE a cererii SQL. Pentru a adăuga un parametru de intrare se va selecta New și vom avea posibilitatea de a adauga un nou parametru după nevoiele noastre selectând tipul, dacă este necesar sau nu acest parametru, și deasemena putem adăuga și o descriere pentru parametrul nou adăugat.

Click Next și vom vedea urmatoare fereatra.

Definirea cererii MySQL.

În funcție de tipul cererii (select, insert, insert/update, update sau delete) SQL necesară, la acest pas se va configura cererea. Se selectează baza de date care va fi interogată după care adaugăm coloanele după care se va face interogarea iar apoi alegem tabela din baza de date. În caseta Criteria se va putea adauga clauza WHERE în dreptul parametrului de intrare dorit, și după operatorul necesar.

Click Next.

Maparea rezultatelor

Maparea rezultatelor. Maparea va face legătura între rezultatele obținute în urma interogării și vederea XML pe care vrem să o construim. Pentru aceasta mai întâi generăm modelul elementului XML. În cazul acesta vom lăsa programul XAware să-l genereze automat. Se selectează Auto-generate. Maparea efectivă se va face deasemenea automat selectând Auto-map.

Click Finish.

Salvarea BizComponent-ului

Salvăm BizComponent-ul nou creat selectând directorul unde se va salva și introducem numele BizComponent-ului. Se va avea în vedere păstrare extensiei .xbc.

Click Ok. Următoarea fereastra care se va afița va fi cea de BizComponent Reference.

La acest pas vom face referința între parametrii de intrare ai BizComponent-ului și cei ai BizDocument-ului. De aceea vom urma pasul 8, descris mai sus, pentru a introduce aceeași parametrii introduși anterior.

Click Ok.

Împachetare fișierelor serviciului într-o arhivă

Folosiți pașii următori:

Se face click dreapta pe BizDocument-ul creat anterior apoi Package Assembly Tool.

Introducem URL-ul serverului unde este instlat Engine-ul XAware.

Click Create Package pentru a crea arhiva.

Pentru a face “deployment”-ul fișierelor împachetate în arhivă, mai întâi trebuie să ne asigurăm că Engine-ul este pornit după care se face click pe Deploy. Arhiva nou creată va aparea în panoul Project Navigator.

Generarea fișierului WSDL pentru serviciul web

Folosiți următorii pași:

Se face click dreapta pe arhiva (.xar) creată la pasul precedent din panoul Project Navigator, și selectam Make WSDL from Archive.

Putem adăuga acest serviciu unui fișier WSDL existent sau să creem un serviciu nou. În acest caz se va selecta Create service in new WSDL, urmând ca BizDocumentele viitoare să le adaugăm la acest serviciu.

Selectăm BizDocument-ul căruia i se va aduga acest serviciu.

Specificăm numele și calea în campul WSDL File Name unde se va salva fișierul WSDL.

În campul Service Name se va introduce numele serviciului web care va fi inclus în noul fișier WSDL.

URL-ul “listener”-ului îl vom lăsa neschimbat. Pentru aplicația de față s-a folosit cel implicit.

Click Make WSDL.

Selectăm Add WSDL to Archive pentru a adăuga fișierul WSDL în arhiva creată mai sus. Un mesaj de inștiințare ne va apăre infomându-ne că fișierul a fost adăugat cu succes.

Click OK .

Click Close.

Serviciul web este complet.

Pentru adăugarea unor Bizdocumente noi la acest serviciu web se vor urma pașii descriși mai sus cu mențiune că aceste noi BizDocumente se vor adăuga la aceeași arhivă și la același fișier WSDL create inițial. La creare BizComponentelor se va urma deasmenea pașii descrisi dar de această dată se va reutiliza BizDriver-ul deja construit.

7. Prezentarea aplicației

Acest capitol expune un exemplu de dezvoltare a unei aplicații de comerț electronic: un magazin virtual.

7.1 Descriere generală

Această aplicație se dorește a fi un instrument care să faciliteze unui posibil cumpărător găsirea mai ușoară a obiectului ce se dorește a fi cumpărat (echipamente pentru sporturi de iarna) prin punerea la dispoziție a unei game variate de modele, dar bine structurată, dar și a unui algoritm de căutăre avansat care-l va ajuta să localizeze obiectul dorit mult mai ușor.

Aplicația EShop este realizată în PHP, folosește serverul web Apache, iar pentru lucrul cu baza de date, în care se păstrează produsele comercializate de magazin și alte informații importante, este folosit serverul MySQL. Design-ului grafic a fost realizat in Adobe Photoshop, care a fost implementat în limbajul HTML (HyperText Markup Language), limbaj ce poate fi interpretat direct de browser (Internet Explorer, Opera, Netscape Navigator, Mozzila, Firefox, etc.).

În conceperea site-ului a fost gândită o modalitate de a obține o aplicație cât mai ușor de întreținut și cât mai ușor de conceput. De aceea s-a încercat cât de mult a fost posibil, a nu se combina codul PHP cu cel HTML. Dacă nu este realizat acest lucru, codul poate deveni din ce în ce mai dificil de întreținut.

Totodată s-a utilizat metoda fișierelor incluse. În aplicația EShop acestea conțin colecții de funcții care sunt folosite în diverse scopuri ( functii_afisare.php, functii_admin.php, functii_autentificare.php, functii_baza_de_date.php, functii_comanda.php, functii_produs.php, functii_validare.php ). Aceste fișiere vor fi incluse cu ajutorul instrucțiunii include, în diverse pagini ale site-ului, în momentul în care este nevoie de acele funcții. Există deasemenea și un fișier fisiere_aplicatie.php care conține o colecție de fișiere incluse pentru această aplicație. De fapt, acest fișier este important deoarece vom putea include în fiecare pagină creată un singur fișier, în loc să le includem pe toate necesare.

7.1.1 Fișierele aplicației

După cum se observă fișierele din aplicația EShop sunt structurate în mai multe categorii: un prim grup, constituit din fișierul de descriere al serviciului web și anume fișierul WSDL, BizDriver-ul comun fiecărui BizComponent, care face conectarea la baza de date MySQL, fișierele BizDocument reprezentând fiecare operație disponibilă acestui serviciu,fișierele BizComponent incluse fiecare în BizDocument-ul corespunzător și care efectuează fiecare operație descrisa de acesta, și un ultim grup, cel al fisierelor XAR cuprinzând arhivele XAware în care sunt împachetate separat fișierele corespunzătoare unei anumote operiații.

Funcțiile disponibile administratorului sunt conținute in fișierul functii_autentificare.php. acestea sunt implemetate cu ajutorul librăriilor NUSOAP pentru PHP. Toate aceste funcții sunt similare, ficare dintre ele returnând true sau false în funcție de rezultatul obținut în urma apelării unei operații descrise de fișierul login.wsdl. Singura diferență dintre aceste funcții SOAP este deci apelarea BizComponent-ului corespunzător fiecărei cereri utilizator. Rezultatul obținut este o interogare indirectă a bazei de date, interogarea propri-zisă fiind executaă de către BizComponete Xaware.

Un exemplu de funție SOAP care accesează o operație descrisă de fișierul login.wsdl este funcția care face autentificarea. Aceasta este exemplificată mai jos.

function login($user,$pass){

$client = new soapclient("http://localhost:8090/xaware/XADocSoapServlet");

$username = $user;

$password = $pass;

$parameters = array('username' => $username, 'password' => $password);

$err = $client->getError();

if ($err) {

// Display the error

echo "client construction error: " . $err ;

return false;

} else {

//call the login.xbd operation

$result = $client->call('login.xbd',$parameters);

$err = $client->getError();

if ($err) {

// Display the error

echo "Call error: " . $err;

return false;

} else {

return true;

}

Cele mai semnificative fișiere PHP din punct de vedere al integrării datelor în apicații web ale acestui proiect sunt functii_admin.php și functii_autentificare.php.

Astfel fișierul functii_admin.php va conține funcții care vor deservi modului administrator : afis_form_categorii() (funcție care afișează formularul de editare sau inserare a unei categorii), afis_form_produse() (funcție care afișează formularul de editare sau inserare a unui produs), formular_parola() (funcție care afișează formularul pentru schimbare a parolei), introd_categoria() (funcție SOAP care afișează formularul pentru a introduce o categorie), introd_produs() (funcție SOAP care afișează formularul pentru a introduce un produs într-o categorie specificată), modifica_categoria() (funcție SOAP care afișează formularul pentru modificarea numelui unei categorii specificate), modifica_produs() (funcție SOAP care afișează formularul pentru modificarea numelui, a detaliilor sau a prețului unui produs), sterge_categoria() (funcție SOAP care afișează formularul pentru stergerea unei categorii) și sterge_produs() (funcție SOAP care afișează formularul pentru stergerea unui produs).

Fișierul functii_admin.php va conține funcții care vor deservi tot modului administrator și care se vor referi la autentificarea administratorilor (funcțiile login() și verif_admin()) dar și la schimbarea parolei unui administrator (funcția schimba_parola()).

De asemenea fișierul functii_autentificare.php va contine funcția SOAP login(), exemplificată mai sus, care efectuează autentificarea utilizatorului in modul administrator .

Alte fișiere PHP mai putin relevante în cadrul integrării datelor, dar cu o importanță semnificativă pentru aplicația de față o constituie fișierele funcții_afișare.php, functii_produs.php și functii_validare.php.

Astfel, fișierul funcții_afișare.php va conține :

– o funcție antet(). Această funcție va fi responsabilă cu afișarea bării de sus a paginii, a bannerului din partea de sus a paginii, afișarea logo-ului firmei, a butoanelor, dar și afișarea meniurilor din stânga (unde sunt redate categoriile pentru produsele din baza de date) și din dereapta a paginii. Totodată background-ul pentru această aplicație este afișat în cadrul acestei funcții.

Ne putem da seama deci, că această funcție antet(), va avea un rol foarte important în crearea interfeței. Astfel această funcție trebuie să fie apelată în fiecare pagină a site-ului, deci întreg fișierul functii_afisare.php va trebui inclus.

– o funcție afis_produse() pentru afișarea produselor. Această funcție va afișa produsele dintr-o categorie selectată preluându-le din baza de date.

– o funcție afis_form_informatii() pentru afișarea formularului în care se cer informații legate de clientul firmei.

– o funcție afis_livrare() care afișează un rând de tabel cu costul de livrare si prețul total incluzând livrarea.

– o funcție afis_formular_card() care afișează formularul care cere clientului detalii despre cardul cu care va plăti.

– o funcție afis_cos() care afișează produsele selectate în coșul de cumpărături.

– o funcție afiseaza_tabel_login() care afișează tabelul prin care se permite logarea ca administrator.

– o funcție meniu_admin() care care afișează tabelul din meniul administratorului, cu toate opțiunile care pot fi făcute ca administrator.

Fișierul functii_produs.php conține:

– o funcție cost_livrare() care tot timpul va returna costul livrării, care in cazul nostru este setat la 20.00.

– o funcție preia_categorii() care preia categoriile din baza de date.

– o funcție get_search() care va deservi pentru cautarea produselor dintr-o anumită categorie după mai multe câmpuri.

– o funcție nume_categorie() care realizează conversia unui ID de categorie într-un nume de categorie.

– o funcție preia_produse() care interoghează baza de date în legătură cu produsele dintr-o categorie.

– o funcție calculeaza_pret() care calculează prețul total pentru toate produsele din coș.

– o funcșie calculeaza_produse() care calculează numărul de produse din coș.

Fișierul functii_validare.php conține o funcție form_completat() care verifică dacă toate variabilele dintr-un formular au valore, deci verifica dacă formularele au fost completate în întregime.

7.2. Arhitectura aplicației

În această secțiune, sunt structurate cerințele aplicației în două mari module și are loc o prezentare a serviiciilor oferite de fiecare modul in parte.

7.2.1. Interfața utilizator

Interfața utilizator este acea parte a aplicației care o poate vizualiza oricine (spre deosebire de secțiunea de administrare care poate fi accesată doar de persoane autorizate). Un procentaj foarte mare al informației afișate în interfața utilizator este informație dinamică, extrasă din baza de date aferentă.

Principalele servicii oferite de acest modul sunt următoarele:

accesul la informațiile referitoare la firmă și la alte informații utile despre modul de cumpărare

posibilitatea de a înregistra sugestii și opinii referitoare la site

catalogul de produse și servicii oferite

gestionarea coșului de cumpărături

efectuarea comenzii

Cosul de cumparaturi

Sugestii si opinii

Structura aplicației pentru cazul unui utilizator obișnuit poate fi reprezentată prin diagrama următoare:

Această diagramă prezintă legăturile principale dintre scripturi în partea pentru utilizatori a site-ului. Un client ajunge prima dată la pagina de bază care listează, pe lângă alte informații utile și toate categoriile de produse din magazinul virtual. De acolo, acesta poate trece la o anumită categorie de produse, iar de acolo la detalii despre un produs ales.

Vom oferi utilizatorului o legătură pentru adăugarea produsului selectat în coșul virtual, iar de pe pagina coșului virtual, unde poate viziona toate produsele adăugate de el în coș, utilizatorul va putea ajunge la casa magazinului on-line. Apoi se va face prelucrarea datelor despre utilizator, care necesită a fi introduse în anumite formulare, date care ajung în baza de date a aplicației. Odată ce aceste date au fost introduse corect, se va finaliza comanda, iar datele, ajunse în baza de date, vor fi vizualizate de un administrator care va onora comanda depusă de utilizator.

Urmărirea produselor selectate de un utilizator în timp ce face cumpărături

Există două metode fundamentale prin care putem urmări produsele selectate de un utilizator în timp ce face cumpărături. Una este să trecem produsele selectate de acesta în baza de date , iar cealaltă să utilizăm o variabilă sesiune.

Utilizarea unei variabile sesiune pentru a urmări selecțiile de la o pagină la alta este o soluție care va putea fi scrisă mai ușor pentru ca nu va necesita interogarea constantă a bazei de date pentru a avea aceste informații. De asemenea, prin utilizarea acestei abordări se va evita situația în care am avea în baza de date multe date inutile provenite de la utilizatori care s-au răzgândit în timp ce răsfoiau site-ul.

Deci, trebuie să proiectăm o variabilă sesiune sau un set de variabile pentru a stoca selecțiile făcute de un utilizator. Când un utilizator își încheie cumpărăturile și plătește produsele selectate, vom trece aceste informații în baza de date ca o înregistrare a tranzacției.

De asemenea, aceste date sunt utilizate și pentru a oferi utilizatorului permanent un rezumat al stării curente a coșului, pentru ca utilizatorul să poată ști oricând cât va avea de plătit.

7.2.2 Secțiunea de administrare

Secțiunea de administrare este un modul, de eficiența căruia depinde succesul oricărui magazin electronic. Actualizările produselor fiind frecvente, este necesar ca acest modul să facă față cu succes unui număr (relativ) mare de actualizări zilnice.

Structura aplicației pentru cazul unui utilizator de tip administrator poate fi reprezentată prin diagrama următoare:

Administrarea a fost dezvoltată într-un mod dinamic, la fel ca și celelalte module. Acest modul nu este destinat utilizatorilor obișnuiți, ci doar administratorilor care se ocupă de actualizarea produselor.

Secțiunea de administrare se poate accesa numai dacă administratorul se autentifică cu parola și username-ul corect al său. Acest lucru se poate face prin intermediul fișierului login.php sau mai simplu accesând link-ul Login din bara de sus a paginii. După deschiderea unei sesiuni de lucru, identificăm utilizatorul cu rol de administrator prin variabila sesiune admin_user și prin funcția verif_admin() din biblioteca de funcții functii_autentificare.php. În urma autentificării unui administrator vom fi conduși la meniul de administrare din admin.php. Acest meniu din secțiunea administratorului, va prezenta de fapt toate serviciile oferite de acest modul.

Panoul de login

Aceste servicii sunt următoarele:

modificare categorie

ștergere categorie

adăugare categorie nouă

modificare produs

ștergere produs

adăugare produs nou

verificare comenzi

stergere comenzi

stergere sugestii

schimbarea parolei administratorului curent

adaugare administrator

stergere administrator

Meniul administrator

Dacă administratorul dorește să adauge o categorie sau să adauge un nou produs, acesta va fi direcționat fie la scriptul introd_categoria_form.php, fie la scriptul introd_produs_form.php după caz. Fiecare script îi oferă administratorului un formular pe care trebuie să îl completeze. Fiecare formular este prelucrat de scriptul corespunzător (introd_categoria.php sau introd_produs.php), care verifică dacă formularul este completat și inserează datele noi în baza de date. Obsevăm că scriptul introd_produs.php apelează funcția introd_produs().pe care o găsim în biblioteca de funcții functii_admin.php.

În afară de adăugarea de categorii și de produse, administratorul poate edita și șterge aceste elemente. Când administratorul execută click pe legătura Meniul principal din meniul de administrare, el va fi condus pe pagina index.php și poate naviga pe site ca un utilizator obișnuit, utilizând aceleași scripturi.

Totuși, există diferențe în meniul pentru administrare: administratorii vor vedea opțiuni diferite datorită faptului că au înregistrată variabila sesiune admin_user. De exemplu, atunci când se vor vizualiza detaliile unui produs opțiunea Editează Item va apărea și administratorul va avea deci, posibilitatea să schimbe caracteristicile produsului sau din același script, edit_produs_form.php să și șteargă produsul respectiv.

În cazul navigării pe o categorie va apărea opțiunea Editează categoria care ne va duce la scriptul edit_categoria_form.php unde vom putea fie să modificăm numele categoriei, fie să o ștergem. Când un administrator încearcă să șteargă o categorie, aceasta nu va fi ștearsă dacă există cărți în ea ( Acest lucru se verifică printr-o interogare a bazei de date ). Prin aceasta se evită problemele pe care le pot crea unele anomalii ale ștergerilor.

Totodată va exista tot timpul la sfârșitul fiecărei pagini, dacă suntem logați ca administratori, o opțiune de revenire la meniul administratorilor unde vor fi disponibile toate serviciile posibile.

Schimbarea parolei unui administrator sau adăugarea unui administrator se face tot cu ajutorul unor formulare în urma direcționării spre scripturile corespunzătoare (schimba_parola_form.php și adauga_admin_form.php).

Opțiunile de vizualizare a comenzilor, ștergere a comenzilor, a sugestiilor sau a administratorilor utilizează interogări ale bazei de date, astfel de exemplu pentru vizualizarea comenzilor vom fi trimiși la scriptul comenzi.php unde vor fi disponibile spre vizualizare doar comenzi existente, pe care administratorul le va putea alege cu ajutorul comenzii SELECT – OPTION din limbajul HTML. Aici el va putea alege să vizualizeze detalii despre client (vom fi trimiși la scriptul detalii_client.php de unde vom putea afla detalii despre cardul clientului respectiv prin scriptul detalii_card.php) sau detalii despre comanda făcută de un anumit client (vom fi trimiși la scriptul detalii_comanda.php).

La fel și în cazul ce ștergerilor, datorită faptului că interogăm baza de date, se vor putea șterge doar comenzi, sugestii sau administratori existenți, evitând astfel eventuale greșeli. Pentru aceste operațiuni vom fi trimiși la scripturile sterge_comenzi_form.php, sterge_sugestie_form.php respectiv sterge_admin_form.php, de unde, în scripturile sterge_comenzi.php , sterge_sugestia.php respectiv sterge_admin.php, vom fi anunțați despre realizarea sau nerealizarea operațiunii.

8. Concluzii

Viteza de evoluție a Internet-ului este impresionantă. Dacă acum se apreciază că există câteva milioane de oameni care folosesc serviciile Internet în fiecare moment, numărul lor va crește exponențial în anii următori.

În orice domeniu de activitate, calitatea datelor face ca sistemele informatice să-și atingă scopul inițial, fie că acesta este reducerea costurilor sau prestarea unor servicii de o calitate superioară. Dacă avem in vedere volumul uriaș de date existent într-o bancă sau într-o companie de telecomunicații cu milioane de clienti, raportările cerute de reglementările specifice, precum si necesitatea unei viziuni integrate a datelor nu sunt posibile fără o serie de instrumente specializate. Devine imposibil, fizic, pentru o companie să gestioneze aceste date si să genereze rapoarte fiabile, astfel că instrumentele de integrare a datelor devin esențiale.

Integrarea datelor combină elementele de bază ale sistemelor de gestiune a datelor, ale sistemelor de gestiune a conținutului, depozitele de date și alte aplicații de întreprindere într-o platformă comună.

Principalele probleme care apar în procesul de integrare a datelor sunt generate de:

• Utilizarea unor surse de date multiple care folosesc variante diferite de reprezentare a datelor,

• Necesitatea de sincronizare în timp a datelor preluate din surse diferite,

• Utilizarea de date neconvenționale,

• Conexiunile ad-hoc care trebuie realizate între date de tipuri diferite sau între diferite produse software. .

Această lucrare se referă la cele mai importante concepte, standarde, tehnologii și oferă soluții pentru: dezvoltarea de aplicații integrate, integrarea datelor și a aplicațiilor, manipularea și controlul datelor. Modularitatea aplicației înlesnește o dezvoltare ulterioară, accesul la aplicație este ușor (putând fi folosită orice aplicație de gen browser), dar cel mai importat avantaj al aplicației rămâne în continuare mobilitatea, ea putând fi accesată din orice zonă a lumii singura condiție care trebuie îndeplinită fiind publicarea aplicației pe un server care deține o adresă publică. Accesul la serviciul creat se poate face deasemena de oriunde si nu necesită conectarea printr-un driver specific bazei de date.

Aplicația poate fi îmbunătățită prin adăugarea unor module noi, ca de exemplu: implementarea unei modalități de plată bine securizate (folosind protocolul SSL, de exemplu), prezentarea produselor prin intermediul unor tehnici tridimensionale sau alte elemente care ar ajuta ca aplicația sa fie mai ușor de accesat de către utilizatori. De asemenea aplicația nu este în totalitate orientată pe servicii, pentru imbunătătirea acestui aspect se pot proiecta și restul de operații necesare pentru a face arhitectura alicației de tip Service Oriented.

Bibliografie

Anghel T., Dezvoltarea aplicațiilor Web folosind XHTML, PHP și MySQL,

Editura Polirom, 2005

Buraga S., Aplicații Web la cheie, studii de caz implementate în PHP,

Editura Polirom, 2003

Buraga S., Proiectarea siturilor Web, Design și Funcționalitate,

Editura Polirom, 2005

Luke Welling, Laura Thomson, Dezvoltarea aplicațiilor Web cu PHP și MzSQL,

Editura Teora, 2005

Gugoiu T., HTML, XHTML, CSS și XML prin Exemple, Ghid practic,

Editura Teora, 2005

Simion I., Proiectarea paginilor Web,

Editura Teora, 2006

Williams H.E., Lane D., Web Database Applications with PHP & MySQL,

O’Reilly & Associates, Sebastopol 2002

Referințe Web: http://www.php.net, http://dev.mysql.com, http://www.w3.org, http/www.xaware.com, http/www.xaware.org, http/www.wikipedia.com

Copyright Notice

© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.

Acest articol: Integrarea Datelor în Aplcatii Web (ID: 149349)

Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.

Integrarea Datelor în Aplcatii Web

Copyright Notice

Compresia Datelor. Compresia In Formatele Grafice

. Generatoare de Functii. Considerente Legate de Proiectarea Antipertubativa a Cablajelor Imprima

Sistem Automat Pentru Monitorizarea Unei Parcari Urbane

Sistem de Timp Real Bazat pe Tehnologii Gsm

Reteaua Informatica Nationala

Serverul de Aplicatii Glassfish

Copyright Notice

Similar Posts