SPECIALIZAREA TEHNICA DE CALCUL t4l20lx


CUPRINS

1. INTRODUCERE…………………………………………………………….1
1.1 Contextul……………………………………………………………………..1
1.2 Conturarea domeniului……………………………………………………...2
1.3 Tema propriuzisa…………………………………………………………….2
2. STUDIU BIBLIOGRAFIC…………………………………………………..5
3. FUNDAMENTAREA TEORETICA………………………………………..6
3.1 Arhitectura SOA (Service Oriented Architecture)…………………………6
3.2 Aplicatii cu baze de date……………………………………………………...9
3.3 Entitati si Atribute……………………………………………………..…….11
3.4 Proiectarea arhitecturii aplicatiei…………………………………………...15
4. SPECIFICATIILE SI ARHITECTURA SISTEMULUI………………….18
41. Schema bloc a sistemului…………………………………………………….21
4.2 Functiile sistemului…………………………………………………………..22
5. PROIECTAREA IN DETALIU…………………………………………….23
5.1 Structura programului………………………………………………………23
5.2 Interfata utilizator……………………………………………………………30
5.3 Strunctura de baze de date…………………………………………………..31
5.4 Servicii web……………………………………………………………………34
6. TEHNOLIGIA FOLOSITA…………………………………………………36
6.1 Despre XML………………………………………………………………….36
6.2 Despre SQL Server 2000…………………………………………………….39
7. CONCLUZII…………………………………………………………………40
7.1 Aprecieri…………………………………………………………………...…40
7.2 Posibilitatea de dezvoltare…………………………………………………..41
ANEXE
Anexa1. Codul sursa pentru servicii web…………………………………..42

1. INTRODUCERE

1.1 Contextul

Traim intr-o societate care evolueaza foarte repede, oamenii devin din ce in ce mai ocupati si timpul devine tot mai pretios. Odata cu dezvoltarea tot mai rapida a internetului multe firme printre care si bancile au inceput sa ofere servicii prin intermediul acestuia. Se pot face cumparaturi , se poate verifica starea contului deschis la o banca si multe altele. Internetul a devenit o unealta absolut necesara in viata oricaruia dintre noi si in special in activitatea de zi cu zi a firmelor.
Aparitia metodei de plata prin debitarea automata a contului (in engleza Direct Debit) oferita de banci a revolutionat modul in care se efectueaza plata facturilor. Direct debit este cea mai usoara modalitate pentru un client de a-si achita facturile iar pentru firma de a incasa plata acestor facturi.
Din punctul de vedere al clientului avantajele sunt evidente : nu este nevoie sa se mai stea la cozile interminabile de la ghisee, siguranta ca facturile vor fi platite iar data limita nu va fi depasita, avantajul diverselor reduceri care sunt oferite, multe organizatii ofera posibilitatea alegerii datei la care va fi efectuata plata, garantia din parte bacilor ca banii vor fi returnati in cazul unei erori si dreptul de a renunta oricand.
Avantajele nu se opresc insa numai la clienti, si firmele se bucura de avantajul acestei metode care le garanteaza incasarea sigura si rapida a facturilor direct in contul firmei economisind timp si reducand costul colectarii acestor facturi.
Pentru a putea platii prin direct debit un client trebuie sa fie titularul unui cont curent la una din bancile care au contract cu firma furnizoare de servicii. Titularul de cont mandateaza banca sa efectueze plata facturilor in numele sau. In mandat, acesta poate face unele restrictii de termen si/sau sume. Banca va efectua din proprie initiativa plata (direct debit) in limita disponibilului din cont, fara a mai fi necesar acceptul titularului de cont.
Clientii bancii care au deschis un cont curent, completeaza un formular de imputernicire standard "Mandat de autorizare". Pe de alta parte, trebuie instiintat beneficiarul platii despre optiunea de plata din cont, pentru ca acesta sa transmita factura lunara a abonatului la banca.

1.2 Conturarea domeniului exact al temei

Aplicatia se va concentra pe comunicarea dintre firma furnizoare de servicii si banca cu care aceasta are o intelegere cu privire la plata automata a facturilor. Se vor viza aspectele comunicarii la nivel fizic si la nivel de protocol.
De asemenea se vor studia si implementa structura celor doua parti componente ale sistemului (banca si firma). Accentul va cadea insa pe organizarea si functionarea sistemului din punctul de vedere al firmei. Se vor viza aici gestiunea clientilor, a serviciilor oferite si transmiterea cererilor de plata catre banca.

1.3 Tema propriu zisa

Tema propriu-zisa consta in implementarea unei aplicatii destinata firmelor care ofera clientilor posibilitatea platii automate a facturilor lunare. Pentru aceasta se presupune o firma fictiva numita Netcom de servicii internet, telefonie fixa si cablu TV.
De la inceput se remarca doua componente majore ale sistemului si anume banca si firma. Se va urmari comunicarea dintre cele doua parti scopul fiind obtinerea unui mediu de comunicatie eficient si rapid.
Din punctul de vedere al firmei reies urmatoarele notiuni : client , serviciu , contract .Prin notiunea de clienta1i din punctul de vedere al bancii sau a firmei reprezinta persoana fizica sau juridica care in urma incheierii unui contract se angajeaza sa plateasca lunar un abonament in schimbul serviciilor oferite.
Astfel apare si notiunea de serviciua1i care inseamna un efort uman sau tehnic care satisface o nevoie sau o dorinta furnizand utilizatorului un beneficiu adeseori nematerial.
Contractul reprezinta documentul oficial prin care prin care cele doua parti reglementeaza obligatiile fiecareia dintre ele. Firma se angajeaza sa ofere clientului serviciile pe care acesta solicita iar clientul se angajeaza sa plateasca aceste servicii in conformitate cu clauzele contractuale.
Din punctul de vedere al bancii reies de asemenea cateva notiuni cum ar fi client , cont , sold , plata. Pentru banca clientul este o persoana fizica sau juridica care are deschis un cont curent. Contul curenta2i reprezinta un instrument bancar, cu ajutorul caruia clientul bancii poate administra mai usor si mai eficient banii. Poate servi deopotriva la pastrarea banilor si la efectuarea de plati, incasari sau transferuri bancare. In functie de nevoi, se poate poti deschide un cont curent in Lei, USD, Euro, GBP sau in alte valute.
Notiunea de plata inseamna transferul sumei necesare platii unuia sau a mai multor servicii din contul curent al clientului in contul firmei furnizoare de servicii. In urma acestei operatiuni banca va trimite firmei o confirmare prin care aceasta poate actualiza evidenta proprie a facturilor.
Din notiunile de mai sus reies operatiile care vor avea loc intre cele doua parti componente ale sistemului si anume transmiterea si primirea cererilor de plata respectiv transmiterea si receptionarea confirmarilor de plata.

Figura 1. Comunicare intre firma si banca

Este evidenta necesitatea comunicarii eficiente intre cele doua componente ale sistemului care se vor afla fizic pe diferite sisteme de calcul si platforme de operare. Rezulta astfel nevoie de implementare a unui canal de comunicatie flexibil care sa nu depinda de sistemul de operare utilizat. Desigur vor fi reglementate anumite protocoale in privinta comunicarii si asupra structurii si continutului mesajelor interschimbate.
Privind mai problema mai in detaliu reiese ca majoritatea firmelor si a bancilor pastreaza informatiile pe suporturi de memorie diferite si in locatii diferite. Acest fapt este dat de nevoia de siguranta si securitate al acestora. Aplicatia client care va folosi bazele de date trebuie sa fie capabila sa le acceseze chiar daca nu ruleaza pe acelasi sistem de calcul. Aceasta se va face prin intermediul internetului sau a retelelor locale.
Pe baza acestor specificatii se obtine o noua schema a sistemului care va cuprinde si accesul da bazele de date ale firmelor si bancilor.
Figura 2. Schema sistemului

O alta problema este faptul ca structurile celor doua baze de date va fi diferite, datele si informatiile fiind reprezentate in maniere si formate distincte. Aceasta se datoreaza conceptelor diferite asupra entitatilor care duc la structura acestor baze de date.
In concluzie este nevoie de o modalitate de a asigura unicitatea identificatorilor.

2. STUDIU BIBLIOGRAFIC

1. Alexandru,Gheorghe,Catana, Marketinng in Power Point, Editura U.T.Pres,2004

2. https://www.bancpost.ro Plata facturilor telefonice ale Romtelecom, MobiFon, Orange, Cosmorom si Telemobil

3. M.Endrei,J. Ang, A.Arsanjani, S.Chua, Patterns: Services Oriented Architecture and Web Services,IBM Recordbooks, Aprilie 2004

4. D, Ehnebukse, C. Ferris, T. Glover, C. Kurt, WS-I Overview,Web Services-Interoperability Organization, 15 ianuarie 2003

5. Web Services Descriptin Language (WSDL) 1.1.2001, https://www.w3org/TR/wsdl

6. Simple Object Access Protocol (SOAP) 1.1.2000, https://www.w3org/TR/2000/NOTE-SOAP-20000508

7. Dragomir, Gabriel, Dezvoltarea aplicatiilor cu baze de date, Note de curs

8. Extensible Markup Language (XML), 2003, https://www.w3org/XML

3. FUNDAMENTARE TEORETICA

In continuare vom prezenta conceptele care stau la baza arhitecturii sistemului si a functionalitatilor oferite de acesta.

3.1 Arhitectura SOA (Service Oriented Architecture)

Pentru definirea arhitecturii unor aplicatii web este intotdeauna o prioritate pastrarea legaturii cu standardele din sfera acestora, standarde in continua evolutie. In ziua de astazi arhitecturile SOAa3i consolideaza interoperabilitatea sistemelor eterogene si schimba modul de organizare a sistemelor. Luand in considerare problema interoperabilitatii si a cerintelor in continua modificare, este furnizata o platforma pentru construirea serviciilor cu urmatoarele caracteristici a4i :
• Cuplarea libera
• Transparenta locatiei
• Independenta de protocol
Avand la baza o asemenea arhitectura, utilizatorului nu trebuie sa-i pese despre un anumit serviciu cu care acesta comunica deoarece infrastructura va face alegerea potrivita pentru el. Infrastructura ascunde cat mai multe din detaliile tehnice in special cele legate de implementarea diferitelor tehnologii, care nu ar trebui sa afecteze utilizatorii. Arhitecturile SOA prezinta o abordare pentru construirea sistemelor distribuite care furnizeaza aplicatiilor functionalitati sub forma de servicii. Este caracterizat prin functionalitatea si calitatea serviciului.
Cea mai buna modalitate de a implementa servicii este utilizarea componentelor care la randul lor sunt construite prin intermediul tehnologiei orientate obiect. Realitatea a demonstrat ca dintr- o aplicatie bazata pe o componenta buna nu reiese neaparat o arhitectura SOA functionala. Service layer este un fel de margine a aplicatiei care demonstreaza faptul ca un serviciu este o foarte buna modalitate de a expune vederea externa a sistemului, cu reutilizarea si recompunerea interna folosind designul traditional al componentelor. Combinatia tuturor serviciilor interne si externe ale unei organizatii formeaza arhitectura orientata spre servicii.
Fluenta proceselor unei arhitecturi SOA poate fi privita din punctul de vedere al rolurilor, operatiunilor si a obiectelor. Rolurile intr-o arhitectura SOA:

Figura 3. Arhitectura SOA

• Utilizatorul serviciului: o aplicatie, un modul software sau chiar un alt serviciu. Initiaza o interogare a serviciului din registru,o ataseaza unui serviciu transport, si executa functia serviciului. Utilizatorul executa serviciul in conformitate cu interfata contract.
• Furnizorul de servcii: o entitate adresabila prin intermediul retelei care accepta si executa cererile venite de la utilizator. Isi publica serviciile si interfata contract in registru astfel incit utilizatorul le poate descoperi si accesa.
• Registrul serviciilor: contine un rechizitoriu al serviciilor disponibile si permite vizualizarea interfetelor catre utilizator.

Fiecare entitate din arhitectura SOA poate juca unul sau mai multe din cele trei roluri de: furnizor servicii, consumator si registru. Operatiunile arhitecturii fiind:
• Publicare: pentru a fi accesibil, descrierea unui serviciu trebuie publicata in asa fel incit sa poata fi descoperit si invocat de catre consumatorul de servicii.
• Cautare: un serviciu este localizat prin interogarea registrului de servicii in cautarea unui serviciu care indeplineste criteriile cerute
• Atasare si invocare: dupa obtinerea descrierii serviciului, consumatorul serviciului continua cu invocarea serviciului in functie de informatiile din descriere.

Obiecte din arhitectura SOA sunt :
• Serviciul: disponibil printr-o interfata care permite sa fie invocat de catre consumatorul de servicii
• Descrierea serviciului: specifica modul prin care consumatorul va interactiona cu furnizorul de servicii. Indica formatul cererii si a raspunsului primit din partea serviciului
Cea mai populara implementare a arhitecturii SOA sunt serviciile web din ziua de azi. Specificatiile acestora sunt independente de limbajul de programare, sistemul de operare si hardware in scopul promovarii, cuplarii libere dintre utilizatorul serviciului si furnizor.
Web Service Description Language (WSDL) a5i este un format pentru descrierea interfetei serviciilor web. Este calea de descriere a serviciilor si a felului in care acestea vor fi atasate unei adrese de retea. WSDL este compus din trei parti:
• Definitii
• Operatii
• Legaturile serviciului

Definitiile sunt exprimate in XML si include atat definitiile tipului de date cat si definitiile mesajelor. Aceste definitii sunt de obicei bazate pe un vocabular XML prestabilit. Operatiile WSDL descriu actiuni pentru mesajele suportate de un serviciu web. Sunt grupate in tipuri port. Tipurile port definesc un set de operatii suportat de serviciul web. Legaturile serviciului conecteaza tipul port unui port, iar un port asociaza o adresa de retea cu un tip port. O colectie de porturi defineste un serviciu. Aceste legaturi sunt de cele mai multe ori create folosind Simple Object Acces Protocol (SOAP).a6i
SOAP furnizeaza „plicul” pentru trimiterea de mesaje ale serviciilor web pe internet si contine doua parti:
• Un antet optional furnizand informatii pentru autentificare, criptare date sau felul in care receptorul unui mesaj SOAP va procesa mesajul.
• Corpul care continand mesajul, care poate fi definit utilizand specificatia WSDL

3.2 Aplicatii cu baze de date

O aplicatie este in principiu o colectie software consolidata cu scopul de a rezolva un set dat de probleme. Rezolvarea problemelor prin punerea in practica a software-ului se numeste software engineering. Tot asa cum in alte proiecte ingineresti cum ar fi constructia unei cladiri sau a unui aparat de zbor este depus un efort considerabil inaintea punerii primei caramizi in constructia cladirii sau inainte de conceperea primei piese a aparatului de zbor. In timpul fazei initiale (numita faza de proiectare) o serie de elemente vor intra in contact unele cu altele pentru a da forma proiectului de aplicatie. Unele din elemente sunt ne-negociabile sau resurse limitate cum ar fi timpul, banii, sau mana de lucru. Altele, cum ar fi tehnologiile disponibile, cunostintele, sau indemanarea sunt resurse dinamice si variaza pe parcursul ciclului de viata al sistemului "business".a7i
Notiunea de baza de date este strans legata de notiunea de date, care refera „fapte culese din lumea reala” . Baza de date se refera la un volum mare de date, care sunt stocate pe suport fizic; ea reprezinta, in cazul sistemului computerizat, echivalentul arhivei din viata reala. Mai poate fi inteleasa ca o colectie de fisiere de date intr-un sistem de calcul.
Pentru o baza de date cel mai important lucru este manipularea datelor continute in acea baza de date. Aceasta „manipulare” refera operatiile care se pot efectua asupra datelor: operatii de adaugare a unor date noi, operatii de regasire, de modificare, de stergere a datelor existente.

Programarea bazelor de date constituie, de fapt, procesul de stocare -; folosind o modalitate standard -; a unei varietati de informatii, astfel incat sa fie posibila o accesare si o intretinere facila a datelor. Informatiile stocate intr-o baza de date, spre deosebire de un document creat cu un procesor de texte, respecta de obicei un format standard.
Pentru aplicatia ceruta, utilizarea unei aplicatii cu baze de date in detrimentul altor metode de rezolvare a problemei date, cum ar fi calculul tabelar sau o aplicatie standard, fara baze de date, rezolva o serie de probleme si neajunsuri. Din acest punct de vedere, unele avantaje ale proiectarii aplicatiei cu baze de date au constituit un factor important de decizie atunci cand am ales modalitatea de rezolvare a problemei date, cum ar fi:
- posibilitatea stocarii unui volum relativ mare de informatii, precum si accesul ulterior la aceste informatii;
- remanenta informatiei, care in cazul unei aplicatii standard, fara baze de date, era incerta. Astfel, utilizatorul aplicatiei va avea posibilitatea sa verifice la un moment dat situatia clientilor sau a serviciilor pentru luna precedenta sau chiar pentru anul trecut,
- simplificarea procesului de calcul, care in cazul calculului tabelar ar fi avut o complexitate ridicata, fara a avea un control real asupra fluxului de informatie gestionat;
- transparenta totala a implementarii, utilizatorul aplicatiei nu trebuie sa cunoasca modalitatile efective de implementare, modul de stocare a datelor, verificarile de corectitudine a informatiilor introduse. Utilizatorul nu trebuie sa cunoasca ce se intampla cu o informatie introdusa in sistem, dar in acelasi timp acesta trebuie sa aiba acces la informatia respectiva;
- fiind vorba de sume de bani, securitatea metodelor de calcul trebuie sa fie ridicata, trebuie sa fie eliminata pe cat posibil posibilitatea introducerii de erori in rezultatul final, iar o aplicatie care utilizeaza baze de date reuseste sa atinga acest obiectiv.
Concluzionand, baza de date va trebui sa contina toate informatiile necesare unei cat mai bune desfasurarii a activitatii firmei.
Automatizarea procesului de calcul prin intermediul aplicatiei trebuie sa fie de asemenea transparent

3.3 Entitati si Atribute

Pentru a ajunge la realizarea structurii bazei de date, am utilizat specificatiile de definitie(prezentate in subcapitolul 1.3). Pe baza acestor specificatii extragem entitatile si atributele care constituie puncte de plecare la proiectarea bazei de date. Vom prezenta in paralel evolutia proiectarii atat pentru firma cat si pentru banca.
NOTIUNE CALITATE(entitate sau atribut) client Entitate adresa Atribut numar de telefon Atribut
Persoana Fizica Entitate nume Atribut prenume Atribut cod numeric personal Atribut persona juridica Entitate nume Atribut cod unic de identificare Atribut serviciu Entitate denumire Atribut valoare Atribut serviciu contractat Entitate data contract Atribut an Atribut luna Atribut valoare Atribut data achitat Atribut

Tabel 1. Lista cu entitati si atribute Firma
NOTIUNE CALITATE(entitate sau atribut) client Entitate adresa Atribut numar de telefon Atribut persoana fizica Entitate nume Atribut prenume Atribut cod numeric personal Atribut persona juridica Entitate nume Atribut cod unic de identificare Atribut cont Entitate sold Atribut miscare cont Entitate document Atribut data document Atribut ora document Atribut debit Atribut credit Atribut

Tabel 2. Lista cu entitati si atribute Banca
In tabelul 3 prezentam entitatile cu tipul acestora precum si cu legaturile dintre ele.

ENTITATE TIP ENTITATE ENTITATI CU CARE ARE LEGATURA client entitate de baza serviciu contractat serviciu contractat entitate de legatura serviciu client serviciu entitate de baza serviciu contractat

Tabel 3. Entitatile si legaturile dintre ele pentru Firma

ENTITATE TIP ENTITATE ENTITATI CU CARE ARE LEGATURA client entitate de baza serviciu contractat cont entitate de legatura miscare cont client miscare cont entitate de baza serviciu contractat

Tabel 4. Entitatile si legaturile dintre ele pentru Banca

Aceste legaturi le-am stabilit pe baza textului care constituie specificatiile de definitie si sunt piesele de baza la proiectarea structurii bazei de date. Pentru inceput, entitatile si atributele acestora sunt elementele de baza pentru alcatuirea diagramei entitate-relatie.
Modelarea ER a fost inventata la mijlocul anilor '70 de Peter Chen si ramane in continuare principala abordare pentru modelarea datelor.a7i Prin aceasta reprezentare schematica sub forma unei diagrame se reprezinta entitatile, atributele si relatiile dintre entitati precum si tipul acestor relatii.
Continuand analiza specificatiilor de definitie, extragem relatiile dintre entitati, care pot sa fie dintre urmatoarele tipuri:
- 1:N (one to many) - la o instanta a unei entitati ii corespunde una sau mai multe din cea de-a doua entitate
- 1:1 (one to one) - la o instanta a unei entitati ii corespunde o instanta a celei de-a doua entitatati
- N:N (many to many) - la o instanta a unei entitati ii corespunde una sau mai multe din cea de-a doua entitate si reciproc, acesteia din urma ii corespund una sau mai multe instante ale primei entitati. In acest caz trebuie introdusa o entitate de legatura pentru implementarea relatiei.

Astfel, relatiile pentru cazul de fata vor fi:

TEXT SPECIFICATIE ENTITATE 1 ENTITATE 2 TIP RELATIE un client trebuie sa detina unul sau mai multe servicii contractate client serviciu contractat 1:N un serviciu poate fi pentru unul sau mai multe servicii contractate serviciu serviciu contractat 1:N un serviciu contractat trebuie sa fie detinut de un client si numai unul serviciu contractat client 1 1 un serviciu contractat trebuie sa reprezinte un serviciu si numai unul serviciu contractat serviciu 1 1

Tabel 5. Relatiile dintre entitati Firma

TEXT SPECIFICATIE ENTITATE 1 ENTITATE 2 TIP RELATIE un client trebuie sa fie proprietar al unuia sau mai multe conturi client cont 1:N un cont trebuie sa fie posedat de un client si numai unul cont client 1:1
Miscare cont trebuie sa modifice un cont si numai unul miscare cont client 1:1 un cont poate fi modificat de unul sau mai multe miscare cont cont miscare cont 1:N
Tabel 6. Relatiile dintre entitati Firma
3.4 Proiectarea arhitecturii aplicatiei
Pentru dezvoltarea aplicatiilor cu baze de date, in functie de necesitatile de utilizare ale aplicatiei, se pot utiliza 3 tipuri de arhitectura, pe care le vom prezenta in continuare. a. Arhitectura Desktop
Arhitectura desktop este caracterizata de coexistenta aplicatiei si a bazei de date pe aceeasi masina fizica(pe acelasi calculator)

Figura 4. Arhitectura Desktop

Acest tip de arhitectura se utilizeaza in cazul aplicatiilor de complexitate redusa, cand baza de date este utilizata de o singura aplicatie si eventual de un singur utilizator. Accesul la baza de date se face fie direct de catre aplicatie(de exemplu in cazul unei aplicatii realizate in Visual Fox) sau prin intermediul unui motor de baze de date.

b. Arhitectura Client-Server
In cazul arhitecturii client-server, baza de date si aplicatia nu se gasesc neaparat pe acelasi calculator. Aplicatia ruleaza pe un sistem de calcul numit client, iar baza de date se gaseste pe un alt sistem de calcul, numit server, si este gestionata de un server de baze de date(de exemplu SQL Server, MySQL, etc.) Comunicarea dintre client si server se face prin intermediul unui canal de comunicatie, care este de obicei o retea locala LAN(Local Area Network) sau o retea WAN(Wide Area Network).
Acest tip de arhitectura permite accesul la baza de date de la distanta prin conectarea directa a clientului la serverul de baze de date, de exemplu printr-o conexiune de tip peer-to-peer.

Figura . Arhitectura Client-Server

c. Arhitectura Multistrat
Arhitectura multistrat este cea mai moderna dintre cele 3, si este caracterizata prin existenta a cel putin 3 sisteme de calcul, in mod generic. Aplicatia ruleaza pe sistemul client, pe care eventual ruleaza si un browser de web, prin intermediul caruia aplicatia poate sa emita cereri serverului de aplicatii, care poate fi de asemenea si un server de web. Serverul de aplicatii contine regulile de business ale aplicatiei, si este controlat de un administrator care cunoaste foarte bine intregul sistem si se ocupa cu eventualele actualizari ale sistemului. Un al treilea sistem este serverul de baze de date, unde se gaseste si baza de date. Serverul de aplicatii functioneaza ca un intermediar(gestionar) intre client si serverul de baze de date.
In aplicatiile prin intermediul internetului, de multe ori pe calculatorul client nu ruleaza o aplicatie specializata, ci doar serverul de web, iar utilizatorul are acces la baza de date prin accesarea unei pagini de internet.

Fig . Arhitectura Multistrat

Dintre cele trei arhitecturi prezentate, vom utiliza pentru dezvoltarea aplicatiei arhitectura multistrat datorita faptului ca cele doua parti care interactioneaza se pot afla la distanta datele lor fiind memorate pe servere diferite.
Pentru comunicare vom utiliza serviciile web iar ca si protocol de comunicatie va fi folosit limbajul XML (Extensible Markup Language).

4. SPECIFICATIILE SI ARHITECTURA SISTEMULUI

Dezvoltarea unui sistem este o activitate laborioasa ce cuprinde o multitudine de sub-activitati("tasks") desfasurate intr-o maniera metodica. Aceste sub-activitati pot fi grupate in etape importante. Fiecare etapa are definite clar elementele livrate (adica ce produse finale sunt obtinute la incheierea etapei) etapelor ulterioare.
In cadrul fiecarei etape (stadiu) sub-activitatile tind sa fie de scurta durata si pot fi estimate cu usurinta. Fiecare sub-activitate este divizata in mai multe sub-sub-activitati. O anumita sub-sub-activitate se poate repeta de un numar de ori din diferite motive.
Vom discuta despre dezvoltarea pe baza modelului CASE(Computer-Aided Szstems Engineering).
Prezentam in mare etapele importante de dezvoltare, conform acestui model, fara a insista cu detalii asupra metodelor si sub-activitatilor corespunzatoare fiecarei etape :
- etapa de strategie -; obiectivul este de a produce un set de modele de business, un set de recomandari si un plan agreat pentru dezvoltarea sistemelor de informatii ce vor servi nevoilor curente si viitoare ale organizatiei, tinand cont de constrangerile financiare si tehnice ale organizatiei.a7i Este analizata problema care trebuie rezolvata, pe baza specificatiilor de definitie. Aceste specificatii sunt obtinute in urma discutiilor avute cu beneficiarul aplicatiei, studierea unor documentatii legate de domeniul de activitate respectiv, in acest caz este vorba de studierea legislatiei asociatiilor de proprietari si discutiile avute cu administratorul de imobil;
- etapa de analiza -; Preia si verifica lucrurile obtinute in etapa strategie si le expandeaza in detaliu suficient pentru a asigura acuratetea de business, fezabilitatea si un fundament sanatos pentru proiectare, in cadrul domeniului organizatiei si avand in minte sisteme existente;a7i
- etapa de proiectare -; pe baza etapei de analiza, se realizeaza proiectarea aplicatiei, in urma careia rezulta directive concrete pentru etapa de implementarea7i, de exemplu se realizeaza proiectarea schemei bazei de date, stabilirea functiilor de business necesare in sistem, etc.;
- etapa de implementare -; realizarea efectiva a aplicatiei, scrierea codului, realizarea bazei de date, compilarea aplicatiei sub forma unui program executabil;
- etapa de testare -; produsul software este testat in conditii normale de utilizare si se rezolva eventualele probleme;
- etapa de documentare -; se scrie documentatia aplicatiei(sub forma tiparita si/sau online), se face instruirea viitorilor utilizatori ai aplicatiei.

Figura 4. Ciclul de viata al unui sistem informatica7i

Rezultatul stadiilor strategie si analiza trebuie sa fie complet independente de orice tehnica de implementare specifica, pentru a da proiectantului oportunitatea maxima de a folosi tehnologia potrivita si pentru a proiecta in coexistenta cu sisteme curente. Metoda CASE trebuie sa fie doar scheletul, ea trebuie completata cu ideile proprii si inovatia contribuie la calitatea produsului final.
Business-urile sunt in continua miscare. In linii mari se schimba nu CE este facut ci CINE si CUM face. Modelele folosite pentru a defini cerintele business-ului trebuie sa permita modificari rezonabile in structura organizatiei. Modelele trebuie sa fie de asemenea independente de toate solutiile cunoscute.
Sistemul trebuie sa continue sa functioneze eficient cand, de exemplu, sunt adoptate proceduri noi de fabricatie, vanzare, administrare.
Cerintele ar trebui modelate si definite intr-o maniera generica. Cerintele functionale ar trebui sa defineasca ce este facut, nu cum sau de catre cine. Structura datelor trebuie sa permita modificari: in structura organizatiei, pentru exceptii si pentru limite curente si observabile.a7i

4.1. Schema bloc a sistemului

Figura 5. Schema bloc a sistemului
Aplicatia client comunica cu servicile web folosind ca si canal de comunicare internetul. Apelul serviciilor se face prin intermediul apelului cu ajutorul protocolului orientat spre servicii SOAP. Modul in care sunt obtinute datele este prezentat in figura urmatoare:Figura 6.Structura serviciilor web

4.2. Functiile sistemului
Pentru reprezentarea functiilor sistemului am ales ierahia de functii care este cea mai utila si mai sugestiva tehnica de modelare a functiilor. Vom prezenta pe rand ierarhia de functii pentru firma si cea pentru banca.

5. PROIECTAREA DE DETALIU

5.1. Structura programului
In continuare vom prezenta structura proiectului implementat in Visual FoxPro 9 netcom care este copilat intr-un fisier .dll si care mai apoi este publicat ca si serviciu web prin intermediul serverului IIS. Astfel se realizeaza o legatura dinamica la sursa de date si anume la serverul firmei si al bancii.
Din punct de vedere al codului, proiectul este impartit in trei fisiere .prg :

- DataAccesLayer.prg
- GetNetcomData.prg
- GetBancaData.prg
DataAccesLayer.prg implementeaza dupa cum spune si numele stratul care infasoara accesul la bazele de date. Structura claselor si implementarea lor este inspirata din exemplul numit Northwind din pachetul VisualFoxPro 9.
Clasa MyabstractCursorAdapter mosteneste clasa CursorAdapter din pachetul de clase furnizat de VisualFoxPro redefinind unele metode si intializand proprietatile necesare problemei.
Clasa SQLNetcom intializeaza proprietatea cConnectionString cu valoarea “Driver=ASQL ServerS;Server=(local);Uid=Ovi;Pwd=;Database=firma”.Aceasta proprietate face legatura catre baza de date SQL.
Asemeni clasei SQLNetcom , clasa SQLBanca relizeaza legatura catre baza de date a bancii prin intemediul propritatii cConnectionString care de aceasta data primeste valoarea “Driver=ASQL ServerS;Server=(local);Uid=Ovi;Pwd=;Database=banca”

Clasele ClientDataSource, ServiciiDataSource, ServiciiContractateDataSource, ListaPlatiNetcomDataSource, ListaPlatiDataSource reprezinta sursele de date ale tabelelor din cele doua baze de date adica Clienti, Servicii, ServiciiContractate, ListaPlatiNetcom respectiv ListaPlati. Casete clase furnizeaza metode de accesla date prin apelul de procedurii SQL stocate. De exemplu metoda CautaServiciiNeplatite() arata astfel:

*-------------------------------------------------- FUNCTION CautaServiciiNeplatite() As Boolean
*---------------------------------------------------
This.SelectCmd = "Execute cautaserviciineplatite"
RETURN This.CreateCursorFromBackend()
ENDFUNC

Datele obtinute in urma interogarii sunt salvate intr-un cursor.

GetNetcomData.prg reprezinta implementarea claselor care vor fi publicate ca si servicii web .Aceste servicii web sunt apelate de aplicatia interfata prin intermediul lor realizandu-se comunicare intre banca si firma.
Clasa Netcom este cea care va fi expusa ca si serviciu web iar toate metodele sale vor putea fi apelate de catre aplicatie. Un exmplu de metoda este CautaDetaliiServiciiContractate() :

*--------------------------------------------------------------- Function CautaDetaliiServiciiContractate() As String
*--------------------------------------------------------------- LOCAL oServiciuContractat
LOCAL lcXML as String, loExc as Exception
TRY oServiciuContractat = CREATEOBJECT("ServiciiContractate") lcXML = oServiciuContractat.CautaDetaliiServiciiContractate()
CATCH TO loExc
This.ReturnError(loExc)
ENDTRY
RETURN lcXML

ENDFUNC

Metoda creaza o instanta a clasei ServiciiContractate iar apoi apeland metoda CautaDetaliiServiciiContractate() a acestei clase salveaza in variabila de tip string datele obtinute din interogare in format XML. Acesta variabila este returnata ca rezultat al functiei.

Pentru a evidentia functionalitatea claselor Client, Serviciu, ServiciuContractat,
ListaPlatiNetcom am sa iau ca exemplu una dintre ele si am sa explic structura sa. Metoda CautaDetaliiserviciiContractate care ulterior va deveni serviciul web cu acelasi nume afectueaza parctic o citire in baza de date a firmei returnand informatiile obtinute sub forma unui document XML.

************************************************************
DEFINE CLASS ServiciiContractate AS NetcomResourceManager
************************************************************
*-- reprezinta numele clasei care face legatura la sursa de date. cPrimaryDSClassName = "ServiciiContractateDataSource"
*------------------------------------------------ FUNCTION CautaDetaliiServiciiContractate() as String
*------------------------------------------------ LOCAL loServiciuContractat
LOCAL loExc As Exception
LOCAL llRetVal As Boolean
LOCAL lcXML As String lcXML = ""
TRY
IF This.CreateXMLAdapter()
*-- primeste o referita de la ServiciuContractatDataSource loServiciuContractat = This.CreateDataSource()

*-- Deschide un cursor deconectat in zona de lucru curenta llRetVal = looServiciuContractat.CautaDetaliiServiciiContractate()

IF llRetVal AND USED(loServiciuContractat.Alias)
*-- adauga cursorul la XMLAdapter ca si un XMLTable
This.oXMLAdapter.AddTableSchema(loServiciuContractat.Alias)
*-- creaza XML din XMLTables incarcate
This.oXMLAdapter.ToXML("lcXML")
ENDIF
ENDIF
CATCH
THROW
ENDTRY loServiciuContractat = Null
RETURN lcXML *-- returneaza datel in format XML catre client
ENDFUNC

GetBancaData.prg este asemanator cu GetNetcomData singura diferenta fiind sursa de date care se afla pe un alt server.

Metodele clasei ListaPlatiNetcom:
- CitesteListaConfirmari() se citeste tabela auxiliara a bazei de date a bacii si verifica daca s-a efectuat plata serviciilor
- ScrieListaConfirmari() dupa ce plata serviciilor se efetueaza se actualizeaza tabela auxiliara prin completarea atributului data_achitat din tabela auxiliara
- ScrieCereriPlati() scrie in tabela auxiliara cererile de plata primite de la firma
5.2. Interfata cu utilizatorul
Interfata aplicatiei consta intr-o singura fereastra de tip form impatrtita in trei pagini (in engleza pageframe) reprezentand cele trei functionlitati ale sale. In figura 9 este prezentata o mostra referitoare la organizarea ferestrei.
Figura 9. Structura ferestrei

Prima pagina intitulata sugestiv Clienti ofera utilizatorului posibilitatea de gestionare a aspectelor referitoare la clienti. Printre acestea se numara : introducerea unui nou client in baza de date, modificarea diferitelor atribute ale clientului (nume , prenume adresa, cod numeric personal , cod unic de identificare), stergerea unui client din baza de date, cantractarea unui nou serviciu sau renuntarea la unul deja contractat. Este implemenatat de asemenea si un motor de cautare a unui client dupa nume , cod numeric personal sau cod unic de identificare.
In cea de-a doua pagina sunt oferite facilitati pentru vizualizarea ofertei de servicii disponibile, detalii cu privire la serviciile contractate. Se pot de asemenea sterge sau introduce noi servicii in lista serviciilor disponibile. Tot de aici se poate vizualiza lista platilor efectuate de banca atat cele recente cat si cele mai vechi. Odata vizualizata aceasta lista utilizatorul poate actualiza baza de date cu noile confirmari de plata.
In cea de-a treia pagina intitulata Plati Servicii avem implementata functionalitatea principala a aplicatiei si anume posibilitatea de trmitere catre banca a cererilor de plata pentru serviciile contracate de clienti.
In fiecare din cele trei pagini functionalitatile sunt date prin intermediul apelarii serviciilor web disponibile. Concret aceasta interfata este o simpla aplicatie client care se bazeaz pe servcii web.
Formularul este implementat in Visual FoxPro 9 si compilat intr-o aplicatie executabila de tip desktop.Mentionez ca am urmarit sa realizez interfata utilizator intr-un mod cat mai simplu si intuitiv, folosind elemente de interfata standard de Windows, astfel incat utilizatorul sa fie deja familiarizat cu o mare parte din aceste elemente.

5.3 Structuri de baze de date

Aplicatia va avea doua baze de date aflate pe doua severe diferite. Prima dintre ele este baza de date a firmei iar cea de-a doua este baza de date a bancii cu care firma are contract.
Se presupune o firma fictiva numita Netcom care frunizeaza servicii de internet, telefonie si cablu TV. Baza de date a acestei firme consta in urmatoarele sase tabele:
- clienti
- persoane_fizice
- persoane_juridice
- servicii
- servicii_contractate
- ListaPlatiNetcom

Primele cinci tabele reprezinta entitatile prezentate in subcapitolul 2.3 iar cea de-a patra este o tabela auxiliara in care sunt memorate detaliile despre serviciile neplatite (clientii care le-au contractat, valoare serviciilor etc.). De asemenea , la primirea unei confirmari de plata din partea bancii acesta se memoreza inainte in aceasta tabela inainte de a se actualiza baza de date a firmei.
De mentionat ca tabele persoane_fizice si persoane_juridice reprezinta un subtip al entitatii client. S+a ales implementarea aceste diferentiri pentru a usura identificarea clientilor de catre firma sau banca prin intermediu codului numeric personal (cnp) sau a codului unic de identificare (cui).
Observam ca fata de atributele prezente in diagrama entitate-relatie, sunt prezente si atributele de identificare de tip chei straine, care se propaga in momentul realizarii legaturilor dintre tabele. De exemplu, in tabela apartament, atributul idclient, este cheie straina propagata din tabela clienti, pentru a se face legatura dintre cele 2 tabele.

Figura 7. Structura bazei de date a firmei
Asemanator este contruita si baza de date a bancii fiind compusa tot din sase tabele , cinci reprezentand entitati iar cea de-a sasea fiind o tabela auxiliara.
- clienti
- persoane_fizice
- persoane_juridice
- conturi
- miscare_cont
- ListaPlati
Tabela ListaPlati are rol de comunicare, asemeni tabelei ListaPlatiNetcom din baza de date a firmei. Dupa ce plata facturilor este efectuata de catre banca aici sunt memorate confirmarile care ulterior prin intermediu serviciilor web sunt citite de catre aplicatia firmei care mai departe va actualiza baza sa de date.

Figura 8. Structura bazei de date a bancii

In general, am denumit atributele de identificare cu sufixul ID(de la identificator sau index).
Mentionez ca in momentul implementarii bazei de date, prin definirea unei legaturi intre 2 tabele, am stabilit reguli de fortare a integritatii referentiale, adica motorul de baze de date nu va permite stergerea unei inregistrari din baza de date daca aceasta inregistrare are legatura cu o alta inregistrare din tabela cu care se afla in relatie. Aceasta regula se defineste in sensul de la 1 la N, adica nu pot sa sterg inregistrarea de la capatul 1 daca la capatul N exista cel putin o inregistrare care are referinta la aceasta.
Stabilirea acestei reguli se face prin bifarea optiunilor „Enforce Relationship for Application” si „Enforce Relationship for INSERT and UPDATE ” la editarea unei relatii

5.4. Serviciile web

Dupa cum se vede in fgura de mai jos servicile web sun concentrate in jurul functiilor actorului . Aplicatia contine doi actori principali : firma Netcom si banca.

Pentru a putea fi apela te serviciile web di aplicatia utilizator este nevoie adaugarea unui control numit Generic Handler, acesta face legatura cu serviciile web disponibile pentru un anumit actor.
In aplicatia Netcom avem doua astfel de controale unul pentru serviciile oferite de banca si unul pentru cele oferite de firma.
6. TEHNOLOGIA FOLOSITA

6.1 Despre XML
Limbajul extensibil de marcare (XML)a8i este un limbaj de marcare definit de Grupul de lucru XML al World Wide Web Consortium (W3C). XML este asemanator cu limbajul de marcare hipertext (HTML) prin aceea ca XML este un limbaj bazat pe etichete, proiectat anume pentru transmiterea de informatii in Web. Insa XML difera de HTML prin aceea ca etichetele utilizate de XML nu sunt predefinite. In schimb, recomandarile pentru XML ale W3C specifica un set de reguli care trebuie urmate pentru a crea propriul set de etichete cu semnificatie.
Reguli XML
XML ofera posibilitatea definirii propriile etichete care pot fi utilizate in cadrul unui document XML urmand cateva reguli simple:
Un document XML poate sa contina numai un element radacina. Elementul radacina al unui document XML este un element unic care cuprinde tot continutul considerat parte a documentului insusi. Elementul radacina este primul element care apare dupa sectiunea prolog a documentului. Elementul radacina este cunoscut si sub denumirea de element document.
Toate elementele XML trebuie sa contina etichete de incheiere. Cu toate ca etichetele de incheiere sunt optionale pentru anumite elemente ale documentului HTML, toate elementele dintr-un document XML trebuie sa aiba o eticheta de incheiere.
Numele etichetelor de inceput si de incheiere ale elementelor trebuie sa fie identice. XML este sensibil la diferenta dintre literele mari si mici, astfel incat numele unei etichete de incheiere trebuie sa fie identic cu numele etichetei de incepere care o insoteste.
Elementele XML nu se pot suprapune. Daca eticheta de incepere a unui element apare in cadrul unui alt element, trebuie sa se incheie in cadrul aceluiasi element care o contine.
Toate valorile atributelor trebuie sa utilizeze ghilimele. Valorile atributelor trebuie sa fie incadrate intre ghilimele simple sau duble. In cadrul textului unui document XML nu se pot utiliza caracterele: < > & Acestea sunt caractere speciale care au o semnificatie specifica pentru analizatorii XML. Daca este necesara utilizarea acestor caractere in textul unui document XML, utilizati caractere predefinite sau referinte la entitate.
Urmand aceste reguli va asigurati ca documentul XML este corect, adica respecta sintaxa XML asa cum s-a reglementat prin recomandarile W3C. Documentele XML se considera ca fiind XML valid daca utilizeaza o schema XML pentru a impune restrictii tipurilor de date ce se pot utiliza in documentul XML.
Structura documentelor XML
Documentele XML constau din doua parti principale: un prolog si un element radacina. Documentele XML pot contine, de asemenea, comentarii.
Prologul
Prologul este prima sectiune a unui document XML. Prologul contine declaratia XML, care stabileste ca documentul este un document XML; instructiunile de prelucrare, care furnizeaza informatii pe care analizatorul XML le utilizeaza pentru a stabili cum sa trateze documentul; si declaratiile de scheme, care stabilesc schemele XML care trebuie utilizate pentru a verifica validitatea documentului. Urmatorul exemplu este un prolog dintr-un document XML:

<?xml version="1.0" encoding="UTF-8"?>
Elementul radacina
Elementul radacina este principala sectiune a unui document XML. Elementul radacina contine datele documentului impreuna cu informatiile care descriu structura de date. Urmatorul exemplu este o sectiune element radacina dintr-un document XML:

<Employees>
...
</Employees>
Informatiile din elementul radacina sunt stocate in doua tipuri de constructe XML: elemente si atribute. Toate elementele si atributele utilizate intr-un document XML sunt imbricate in cadrul elementului radacina.
Elemente
Elementele sunt principalele blocuri constitutive ale unui document XML. Sunt utilizate pentru a reprezenta atat structura documentului XML, cat si datele continute in documentul XML. Elementele contin o eticheta de incepere, continutul si eticheta de incheiere. Deoarece XML face diferentierea intre literele mari si mici, eticheta de incepere si eticheta de incheiere trebuie sa se potriveasca exact. Urmatorul exemplu este un element simplu Employee care descrie numele unui angajat. Elementul Employee este imbricat in cadrul elementului radacina denumit Employees:
<Employees>
<Employee>
<Name>Patricia Doyle</Name>
</Employee>
</Employees>
Elementele pot contine text, alte elemente, referinte la caractere sau sectiuni cu date de caractere. Elementele care nu au continut se numesc elemente vide. Etichetele de incepere si de incheiere ale unui element vid pot fi combinate intr-o singura eticheta, cum se arata in exemplul urmator:
<Name/>
Atribute
Atributele sunt constructe XML care utilizeaza o pereche valoare-nume asociata la un anumit element. Atributele includ informatii despre continutul elementului care nu se vor afisa obligatoriu, fiind in schimb utilizate pentru a descrie unele proprietati ale elementului. Valorile atributelor sunt incadrate intre ghilimele simple sau duble, separate de numele atributului printr-un semn egal si incadrate in eticheta de incepere a elementului. Urmatorul exemplu este un atribut EmployeeNumber asociat la elementul Name:
<Employees>
<Employee>
<Name EmployeeNumber="10101">Patricia Doyle</Name>
</Employee>
</Employees>
Comentarii
Documentele XML pot contine, de asemenea, si comentarii. Comentariile nu sunt prelucrate de analizatorul XML, dar se utilizeaza pentru a furniza o documentatie explicativa in sursa XML a documentului. Comentariile incep cu <!-- si se incheie cu -->. Textul dintre aceste caractere este ignorat de analizatorul XML. Urmatorul exemplu este un comentariu dintr-un document XML:
<!-- This XML document contains employee information. -->
<Employees>
<Employee>
<Name EmployeeNumber="10101">Patricia Doyle</Name>
</Employee>
</Employees>

6.2 Despre SQL Server 2000

SQL Server este un sistem de baze de date relationale client-server, avand ca suport de baza in exploatarea bazelor de date limbajul SQL. In esenta aceasta arhitectura presupune o baza de date centrala aflata pe un server, care este accesata de mai multi clienti simultan. Acesti clienti se conecteaza ca utilizatori in cadrul retelei locale sau respectiv ca utilizatori ai Internetului. Consultarea si actualizarea bazelor de date prin intermediul Internetului presupune realizarea de aplicatii care vor fi rulate in browser-ul Web si vor fi interconectate cu baza de date prin intermediul unor scripturi ASP sau prin intermediul tehnologiei XML. De asemenea accesul utilizatorilor din Internet presupune coloborarea intre severul de baze de date si serverul de Web (exemplu Microsoft Internet Information Server), cele doua componente lucrand in tandem pentru a satisface cererile utilizatorilor din Internet.
SQL Server este un sistem de baze de date relationale client-server, avand ca suport de baza in exploatarea bazelor de date limbajul SQL. In esenta aceasta arhitectura presupune o baza de date centrala aflata pe un server, care este accesata de mai multi clienti simultan.
Acesti clienti se conecteaza ca utilizatori in cadrul retelei locale sau respectiv ca utilizatori ai Internetului. Consultarea si actualizarea bazelor de date prin intermediul Internetului presupune realizarea de aplicatii care vor fi rulate in browser-ul Web si vor fi interconectate cu baza de date prin intermediul unor scripturi ASP sau prin intermediul tehnologiei XML. De asemenea accesul utilizatorilor din Internet presupune coloborarea intre severul de baze de date si serverul de Web (exemplu Microsoft Internet Information Server), cele doua componente lucrand in tandem pentru a satisface cererile utilizatorilor din Internet.
Pentru administrarea bazei de date, SQL Server va pune la dispozitie un instrument vizual de administrare SQL Server Enterprise Manager. Enterprise Manager are o interfata asemanatoare Explorer-ului din Windows. In partea stanga sunt prezentate, sub forma ierarhica, principalele clase de obiecte gestionate de interfata.
La nivelul superior al ierarhiei se afla serverul SQL (respectiv serverele) care sunt administrate prin intermediul consolei. Facand clic pe unul din Servere se pot realiza prin intermediul ferestrei deschise in dreapta o serie de operatiuni importante cum ar fi: inregistrarea unui nou server care va fi gestionat prin intermediul acestui program, backup-ul bazelor de date, configurarea clientilor, crearea login-urilor, crearea unei baze de date etc. Interesant de subliniat este ca pentru realizarea acestor operatiuni se ofera posibilitatea utilizarii "vrajitorilor"

7. Concluzii

7.1 Aprecieri
Aplicatia Netcom este destinata tuturor firmelor care au ca domeniu de activitate furnizarea de servicii. De asemenea aplicatia poate fi folosita si de catre stat pentru colectarea impozitelor si taxelor.
Deoarece serviciile web pe care aplicatia le foloseste sunt idependente de platforma face din aceasta o unealta putenica utila ea fiind capabila sa comunice cu diverse aplicatii care ruleaza pe alte sisteme de calcul.
De asemenea constructia dinamica a serviciilor web are ca avantaj faptul ca pot fi foarte usor intretinute si imbunatatite .

7.2 Posibilitati de dezvoltare

Desi aplicatia este intr-o forma utilizabila, totusi exista posibilitatea dezvoltarii sale ulterioare, prin adaugarea unor facilitati cum ar fi:
- introducerea unei baze de date intermediare in care sa se faca scrirea si citirea mesajelor interschimbate dintre cele doua parti
- implememntarea unor functii de tip statistica pentru a se putea memora toate tranzactiile efectuate
- automatizarea procesului de trimitere a cererilor de plata utilizatorul rezumandu-se doar la gestiunea clientilor si a serviciilor
- securizarea aplicatiei prin introducerea de grupuri de utlizatori cu drepturi de acces diferite
- realizarea unor functii care sa avertizeze utilizatorul cand s-au primit confirmarile de plata de la banca
- functii care sa anunte clientul prin sms sau e-mail ca serviciile au fost platite sau in caz contrar de ce anume nu au fost paltite
- functii care sa ofere clientul psibilitatea de a-si verifica starea serviciilor contractate

ANEXE
Anexa 1 Cod Sursa Servicii Web

*******DataAccesLayer.prg********

*Ierarhia Claselor -- * CursorAdapter
* MyAbstractCursorAdapter
* SQLNetcom
* ClientDataSource

**********************************************************************
DEFINE CLASS SQLNetcom as MyAbstractCursorAdapter
**********************************************************************
*-- SQL Server Data - Inherit from this class for SQL Server Northwind
*-------------------------------------------------------------------- Name = "SQLNetcom"
DataSourceType = "ODBC" cConnectionString = "Driver=ASQL ServerS;Server=(local);Uid=Ovi;Pwd=;Database=firma"

ENDDEFINE

********************************************************
DEFINE CLASS ListaPlatiNetcomDataSource as SQLNetcom
********************************************************

Alias = "Lista"
Tables = "ListaPlatiNetcom"
KeyFieldList = "cod_client"


*-------------------------------------------------- FUNCTION Destinatie() As Boolean
*---------------------------------------------------
This.SelectCmd = "Execute selecteazatot"

RETURN This.CreateCursorFromBackend()
ENDFUNC

*-------------------------------------------------- FUNCTION ScrieInDestinatie(strXML as String ) As Boolean
*---------------------------------------------------
LOCAL numecursor as Cursor
CURSORTOXML(strXML,numecursor)
This.SelectCmd = "INSERT INTO dbo.ListaPlatiNetcom SELECT * FROM numecursor"

RETURN This.CreateCursorFromBackend()
ENDFUNC

*------------------------------------------------ * PROTECTED FUNCTION ValidateCursor()
*------------------------------------------------
* LOCAL llRetVal as Boolean
* LOCAL lcMsg as String
* lcMsg = ""
* lcAlias = This.Alias
* llRetVal = .T.
*
* SELECT(lcAlias)
* SCAN
* IF EMPTY(idclient) OR ISNULL(idclient)
* lcMsg = lcMsg + "Client: " + ALLTRIM(idclient) + " - ID-ul client nu poate fi lasat gol." + CHR(13)+CHR(10)
* llRetVal = .F.
* ENDIF
* ENDSCAN
*
* IF lcMsg != ""
* *-- Validation failed. Throw the messages to the client.
* THROW lcMsg
* ENDIF
*
* RETURN llRetVal
*
* ENDFUNC


ENDDEFINE

********************************************************
DEFINE CLASS ServiciiContractateDataSource as SQLNetcom
********************************************************

Alias = "ServiciuContractat"
Tables = "servicii_contractate"
KeyFieldList = ""


*-------------------------------------------------- FUNCTION CautaDetaliiServiciiContractate() As Boolean
*---------------------------------------------------
This.SelectCmd = "Execute detaliiserviciicontractate"

RETURN This.CreateCursorFromBackend()
ENDFUNC

*-------------------------------------------------- FUNCTION CautaServiciiNeplatite() As Boolean
*---------------------------------------------------
This.SelectCmd = "Execute cautaserviciineplatite"

RETURN This.CreateCursorFromBackend()
ENDFUNC

ENDDEFINE

**********************************************************************
DEFINE CLASS SQLNetcom as MyAbstractCursorAdapter
**********************************************************************
*-- SQL Server Data - Inherit from this class for SQL Server Northwind
*-------------------------------------------------------------------- Name = "SQLNetcom"
DataSourceType = "ODBC" cConnectionString = "Driver=ASQL ServerS;Server=(local);Uid=Ovi;Pwd=;Database=firma"

ENDDEFINE

******************************************************
DEFINE CLASS MyAbstractCursorAdapter as CursorAdapter
******************************************************

PROTECTED DataSourceType , ;
Tables , ;
SendUpdates , ;
AllowDelete , ;
AllowInsert , ;
AllowUpdate , ;
WhereType , ;
KeyFieldList , ;
UpdateType , ;
BufferModeOverride, ; nConnectionHandle , ; cConnectionString , ; lThrowExceptions , ; oADOConnection , ; oADORecordset


HIDDEN lWasConnected lWasConnected = .F.

*--PUBLIC
Alias = ""
Name = "MyAbstractCursorAdapter" lAssignPrimaryKeys = .F. oException = .NULL.

*--PROTECTED
BreakOnError = .F.
DataSourceType = ""
Tables = ""
SendUpdates = .T.
AllowDelete = .T.
AllowInsert = .T.
AllowUpdate = .T.
UpdateType = 1 && Update
WhereType = 1 && DB_KEY
KeyFieldList = ""
BufferModeOverride = 5 &&Optimistic Table Buffering nConnectionHandle = -1 cConnectionString = "" lThrowExceptions = .T. oADOConnection = .NULL. oADORecordset = .NULL.

*------------------------------------------ FUNCTION Destroy()
*------------------------------------------ This.DisconnectFromBackend()
This.oADORecordset = Null
This.oADOConnection = Null
ENDFUNC

*------------------------------------------ PROTECTED FUNCTION CreateCursorFromBackend()
*------------------------------------------ LOCAL llRetVal
LOCAL loExp As Exception llRetVal = .F.

TRY
DO CASE
CASE This.ConnectToBackend() = .F.
CASE This.CursorFill() = .F.

OTHERWISE llRetVal = .T.

ENDCASE

CATCH TO loExc
This.oException = loExc
IF This.lThrowExceptions
THROW
ENDIF

FINALLY
This.DisconnectFromBackend()

ENDTRY

RETURN llRetVal
ENDFUNC

*------------------------------------------------------------------------------------- PROTECTED PROCEDURE BeforeCursorUpdate(nRows, lForce)
*------------------------------------------------------------------------------------- LOCAL llRetVal As Boolean
LOCAL loExc As Exception llRetVal = .F.
TRY
DO CASE
CASE This.ValidateCursor() = .F.
CASE This.CreateUpdateLists() = .F.
CASE This.ConnectToBackend() = .F.
CASE This.AssignPrimaryKeys() = .F.
OTHERWISE llRetVal = .T.
ENDCASE

CATCH TO loExc
This.oException = loExc
IF This.lThrowExceptions
THROW
ENDIF

ENDTRY

RETURN llRetVal
ENDPROC


*------------------------------------------------------------------------------------- PROTECTED PROCEDURE AfterCursorFill(lUseCursorSchema, lNoDataOnLoad, cSelectCmd, lResult)
*------------------------------------------------------------------------------------- IF UPPER(This.DataSourceType)="NATIVE"
*-- CursorFill by default leaves local tables open so we need to close it manually.
*-- Because of this you need to watch out; with NATIVE you need to name y