Universitatea Alexandru Ioan Cuza, Iai Facultatea de Economie i Administrarea Afacerilor Specializarea Informatic-Economic

Lucrare de licen E-banking. Disponibilitate 7/24 a serviciilor bancare ctre clieni

ndrumtor tiinific, Lect. univ. dr. Liviu-Gabriel Creu Absolvent

Iai, 2011

Cuprins Introducere ...................................................................................................................................... 3 1. De la Banking la E-Banking .................................................................................................... 4 1.1 1.2 2. Modificri survenite ca urmare a trecerii de la Banking la E-Banking ............................ 4 Perspective viitoare ce va fi dup E-Banking ................................................................ 8

Arhitectura Client-Server i aplicaiile Web .......................................................................... 11 2.1 2.2 Arhitectura Client-Server ............................................................................................... 11 Aplicaiile Web ............................................................................................................... 16

3. Prototip de aplicaie pentru extinderea funcional a aplicaiei E-Banking de la Banca Romn pentru Dezvoltare ............................................................................................................ 19 3.1 3.2 3.3 Analiza situaiei .............................................................................................................. 19 Proiectarea aplicaiei....................................................................................................... 20 Prototip implementat ...................................................................................................... 27

Concluzii ....................................................................................................................................... 32 Bibliografie.................................................................................................................................... 33

Introducere
Prezenta lucrare vrea s trateze problematica sistemelor bancare electronice prezente astzi i modificrile survenite ca urmare a acestei apariii. Aceast tem a fost aleas deoarece este un punct de discuie foarte interesant, avnd n vedere c nceputurile sistemelor bancare electronice nu sunt aa deprtate din perspectiv temporal. De asemenea, aceast discuie este una de actualitate, tratnd diverse elemente. Sistemelor bancare electronice li se acord o mare importan, deoarece prin intermediul acestora din ce n ce mai mult lume efectueaz tranzacii bancare. Sunt folosite din ce n ce mai des i se pare c vor nlocui ct de curnd n totalitate sistemele bancare tradiionale. Ca i obiective propuse pentru prezenta lucrare, se dorete introducerea cititorilor n problematic i nelegerea de ctre acetia a ceea ce nseamn E-Banking. Pentru ndeplinirea obiectivelor propuse, tema este structurat astfel nct este prezentat un mic istoric al E-Banking-ului, modificrile survenite n trecerea de la tradiional la electronic, arhitectura de baz a sistemelor E-Banking i spre final, este adus n discuie i o component adiional pentru un astfel de sistem.

1. De la Banking la E-Banking
Serviciile bancare la distan (Remote Banking), realizate pe cale electronic (E-Banking), au nceput s se dezvolte odat cu anul 1995, atunci cnd banca american Prezidential Bank din Mariland a lansat pentru clieni primele servicii bancare prin intermediul Internetului. Ca i statistici pentru a evidenia importana introducerii i utilizrii ulterioare a acestor servicii bancare electronice, putem aduce n discuie faptul c la jumtatea anului 2004, peste 17% din populaia Americii utiliza serviciile bancare electronice (e-banc). De asemenea, n prezent, serviciile bancare electronice sunt folosite n special de europeni: 48 de milioane la numr. Europenii au devansat n acest top americanii, n numr de 21 de milioane i japonezii, cu o cifr de 20 de milioane de utilizatori, n cursul ntregului an 2003. n anul 2004, circa 16.000 de instituii financiar-bancare din toat lumea ofereau servicii bancare electronice pentru clieni1. Avnd n vedere faptul c sistemul bancar s-a dezvoltat odat cu aceste servicii bancare electronice, cea mai potrivit continuare a prezentei lucrri este trecerea n revist a modificrilor suferite de serviciile bancare ca i consecin a urcrii acestei trepte evolutive, urmnd ca mai apoi s apar n cadru tendinele existente, ce va fi dup sistemele E-Banking.

1.1 Modificri survenite ca urmare a trecerii de la Banking la E-Banking

Furnizarea serviciilor financiare prin intermediul componentelor electronice Internet Banking, Mobile Banking, PC Banking (uneori numit i Home Banking) a dus la producerea de schimbri masive n aceast industrie de servicii financiar-bancare oferite pentru clieni. Aceste modificri survenite sunt cauzate de factori precum viteza de procesare a tranzaciilor, viteza de introducere a produselor i serviciilor financiare noi. Aceste produse noi sunt din ce n ce mai adoptate de ctre instituiile financiare, ns de foarte puine ori aceste adoptri au n spate cunotina i experiena n lucrul cu aceste inovaii, fcndu-se referire strict la experiena instituiei ce adopt aceste produse i servicii. De asemenea, la lipsa experienei se adaug lipsa cunoaterii riscurilor i ameninrilor ce vin odat cu utilizarea acestor inovaii tehnologice. Alte ameninri i riscuri apar odat cu utilizarea serviciilor ce provin din exteriorul instituiilor bancare, care apeleaz la teri pentru implementare2. i n aceast situaie, apare lipsa de experien la nivelul terilor, precum i lipsa unor cunotine necesare legate de managementul situaiilor de risc.

Georgescu-Golooiu, L., Servicii bancare electronice, electronic banking/e-banking, pg. 1-2 la http://www.ligiagolosoiu.ro/content/Servicii_bancare_electronice.pdf 2 Basel Committee on Banking Supervision, Risk Management Principles for Electronic Banking, 2003, pg.1 la http://www.bis.org/publ/bcbs98.pdf

La aceste riscuri i ameninri menionate se adaug i noile condiii de lucru, care trebuie s in pasul cu tehnologia i astfel, s ofere vitez n tranzacii i procesarea datelor. Odat cu aceste noi condiii, cererea pentru implementarea unei infrastructuri tehnologice care s fie flexibil, scalabil i care s permit interoperabilitatea este n cretere. Ca i cerine suplimentare pentru aceast structur tehnologic cerut de instituiile financiare, n spe bncile, se dorete unirea a trei elemente principale ce in de securitatea datelor transmise, i anume se dorete asigurarea securitii, a integritii i a disponibilitii serviciilor i informaiilor confideniale transmise n cadrul infrastructurii. O modificare survenit n interiorul proceselor bancare ar fi aceea a colectrii, stocrii i partajrii n mod frecvent a unor cantiti de date semnificative ce au legatur cu clienii, deoarece aceste operaiuni pot face ca n sistem s apar unele probleme legate de confidenialitatea datelor, aceste probleme putnd avea repercusiuni de natur legal sau reputaional asupra bncii. Rmnnd cu atenia concentrat asupra clienilor i datelor acestora, am putea aduce n discuie i unele proceduri de autentificare lungi sau complicate, care ar putea duce ntr-un final la renunarea din partea clientului n a utiliza pagina de Internet sau aplicaia mobil prin care dorea accesarea serviciului de E-Banking sau, chiar mai ru, renunarea la utilizarea serviciului electronic; mai mult, unele operaiuni laborioase de lucru cu un client, ce implic resurse de orice manier mai multe dect n mod obinuit, pot afecta serios performana general a aplicaiei de E-Banking, avnd n vedere c, odat cu dezvoltarea acestor servicii electronice, crete i numrul utilizatorilor acestora i, implicit, dificultile pe care acetia le ntlnesc uneori n utilizare, de multe ori simultan. Pe de alt parte, natura acestor servicii electronice face posibil extinderea n afara granielor rii, ns dat fiind faptul c reeaua de lucru este deschis, comerul i plile electronice expun instituiile financiare la o concuren demn de luat n seam att de la alte instituii financiarbancare, ct i de la instituii nonbancare. Pe lng toate acestea menionate pn n momentul de fa, trebuie s avem n vedere i s menionm i cteva modificri ale profilurilor de risc strategic i operaional, datorate EBanking. Pe de o parte, avnd n vedere cererea n cretere de servicii bancare electronice menionat anterior i, odat cu aceasta, acceptarea din partea clienilor a acestor servicii i a eficienei lor, bncile tradiionale au fost nevoite s adopte unele strategii legate de utilizarea diverselor canale pentru a oferi clienilor ceea ce ei vroiau. Date fiind aceste strategii alese i evolutia aceasta continu n materie de tehnologie, precum i ritmul n care crete competiia n livrarea de E-Banking, este uor s ne dm seama c banca ce planific i implementeaz strategiile de furnizare a E-Banking poate fi expus cu uurin la 5

unele riscuri majore dac aceste strategii nu au n spate aciuni bine gndite i bine repartizate n perspectiv temporal. Pe de alt parte, dac lum n considerare canalele de furnizare, nainte de Internet bncile utilizau reele proprietare pentru a face legtura ntre unitile acestora, ns, odat cu Internetul, care fiind o reea de tip public unde accesul este nelimitat pentru orice fel de ntreprindere din orice sfer de activitate, competiia a crescut n industria financiar ca i n alte industrii i se pare c aceast competiie va avea un nivel ridicat i pe viitor. Majoritatea celor ce activeaz n sistemul bancar consider E-Banking-ul ca fiind un mijloc de reducere a cheltuielilor operaionale. Dei exist acest considerent, o mare parte din clienii bncii care utilizeaz serviciile bancare electronice nc mai doresc s pstreze legtura cu banca i prin canalele tradiionale, adic nc vor s mearg personal la ghieul bncii i s fac operaiuni fa n fa cu un operator. Odat cu introducerea serviciilor bancare electronice, s-a sperat c, treptat, se va abandona infrastructura existent pentru a se reduce costurile operaionale, ns dorinele clienilor s-au interpus n faa acestei sperane, fcnd dificil acest abandon menionat anterior. Altfel spus, n viitorul apropiat, bncile vor fi nevoite s-i ofere serviciile pe mai multe canale, iar planificarea i implementarea serviciilor de E-Banking va fi n mod sigur o cheltuial n plus. Aducnd n discuie i riscul operaional, putem spune c acest risc este cel care are cel mai mult de suferit din perspectiva furnizrii serviciilor bancare electronice, lund n considerare legtura dintre aceste ultime servicii menionate i tehnologie. Pentru a se reduce nivelul de risc operaional, organizaiile bancare trebuie s aib o arhitectur tehnologic operaional, care s faciliteze integrarea operaiunilor bancare, care s asigure elementele de securitate pentru datele clienilor i care s permit managementul relaiilor cu furnizorii de servicii din afar. n plus, inndu-se cont c tehnologia care evolueaz pe zi ce trece schimb n mod radical modelul de afacere i procesele operaionale interne, bncile au nevoie s in pasul cu procedurile de control, aici incluznd controlul schimbrilor i procesele de audit. i dac tot suntem la capitolul tehnologie, este de menionat faptul c, odat cu E-Banking-ul, a venit i problema integrrii elementelor tehnologice cu procesele i operaiunile care aveau loc pn n momentul de fa. Chiar i n prezent, multe bnci au aceast problem, ncercnd s integreze sistemul de E-Banking cu sistemul informatic din cadrul instituiei i cu sistemul de parteneri i furnizori de servicii. Erorile ce pot aprea n procesarea tranzaciilor datorit unei integrri incorecte a sistemelor sau a unor elemente din sisteme pot expune bncile la unele riscuri operaionale majore. Ca o consecin a cele prezentate, multe bnci investesc cantiti mari de bani pentru a-i dezvolta infrastructura i pentru a crea procesele interne de control i supraveghere a riscurilor 6

provenite din integrarea sistemului existent cu sistemul de E-Banking, amintite mai sus. Prin intermediul acestor investiii, bncile vor s aib parte de o flexibilitate i o scalabilitate crescut, precum i o interoperabilitate ameliorat n ceea ce privete operaiile din interior, ct i cele din exterior. Ajungnd i la riscul de securitate, acesta este considerat de majoritatea bancherilor ca o principal preocupare n legtur direct cu serviciile bancare electronice. Ameninri din exteriorul bncii, cum ar fi atacurile de tip denial of services3, hacking, sniffing sau spoofing expun banca la noi riscuri de securitate. Printre cele mai mari probleme de securitate ntlnim autentificarea utilizatorilor, controlul accesului n sistem, confidenialitatea i integritatea datelor clienilor. De aceea, bancherii doresc s rezolve ct mai rapid unele probleme ce in de dezvoltarea de instrumente exacte de verificare a identitii persoanelor din sistem i de verificare a cererilor de tranzacii din sistem. De asemenea, modificri survenite n interiorul sistemului mai fac referire i la cele mai bune metode de criptare, ntre care se includ semntura electronic i legalitatea documentelor electronice. O alt modificare survenit n urma implementrii serviciilor bancare electronice ar consta n nivelul de disponibilitate a sistemului. Pentru a se asigura o reea securizat n privina activitilor bancare, modul cum se planific resursele este critic atunci cnd se vorbete de continuitatea disponibilitii serviciilor bancare. Avnd n vedere concurena existent pe pia, bncile sunt mpinse s declare c serviciile oferite sunt disponibile 7 zile din 7, 24 de ore pe zi, iar acest lucru a condus la o cretere important a ateptrilor clienilor. De aceea, pentru a putea face fa concurenei i ateptrilor clienilor, evitnd n acelai timp riscurile operaionale i pe cele legate de reputaie, riscuri care pot aprea atunci cnd se ntrerupe furnizarea de servicii bancare electronice din varii motive sau cderea sistemului, bncile trebuie s gseasc un echilibru perfect atunci cnd vine vorba de oferirea serviciilor, echilibru ntre securitate i consisten. Eecul tehnologic domin aici, principala grij fiind sistemul bncii4. Mai mult, tiut fiind faptul c din ce n mai multe bnci apeleaz la teri furnizori pentru intermedierea de servicii electronice ntre ele i clieni, este necesar o verificare regulat a capacitii furnizorilor de a asigura acea continuitate a furnizrii serviciilor care este necesar i n interior atunci cnd serviciile sunt furnizate direct de banc. De asemenea, tot n cazul n care teri intermediaz legtura dintre banc i clieni, este necesar ca la acetia s existe planuri de backup i planuri de rspuns la diversele incidente ce pot avea loc; aceste planuri trebuie s fie cel puin la acelaii nivel de eficien ca i cele ce sunt stabilite n interiorul bncii. Din aceste cauze, este de

3 4

Johnson M, A new approach to Internet Banking - Technical Report, University of Cambridge, 2008, pg. 16 Heffernan S, Modern banking, John Wiley & Sons, Ltd, 2005, pg. 110

menionat c orice banc ar trebui s aib pregtite alternative de furnizare continu a serviciilor ctre clieni n cazul producerii oricror incidente ce pot duce la nefuncionare. O alt component care sufer modificri odat cu implementarea furnizrii de servicii bancare electronice este cea a controlului i auditului intern, n sensul c abilitatea de a detecta erorile i a le corecta este un element critic din sistemul de control intern pentru orice fel de operaiune bancar. De asemenea, trebuie avute n vedere suficiente msuri de control pentru a se preveni frauda din exterior sau din interior, astfel protejndu-se datele clienilor i ale bncii, precum i activele. Mergnd n continuare pe partea aceasta de audit intern i control, trebuie precizat c o bun parte din eficiena serviciilor bancare electronice i din reducerea costurilor generate de aceste servicii stau n maniera de procesare imediat oferit de aceste servicii; aceast procesare se realizeaz automat, fr ca un factor uman s intervin. Dei beneficiile acestei procesri automate sunt numeroase i recunoscute, mai exist i o alt fa a monedei. Astfel, serviciile E-Banking modific oarecum modul de aplicare a procedurilor de control intern i de pstrare a informaiilor pentru auditare ulterioar atunci cnd vine vorba de canale de larg acces. Continund ideea, pe viitor bncilor li se va cere din ce n ce mai mult s asigure clienii c mediul automatizat n care au loc tranzaciile ofer destul control, n acelai timp fiind eficient i ndeplinindu-i rolul de protecie a informaiilor. Relund o idee anterior menionat, i anume aceea c unele bnci nu furnizeaz n mod direct serviciile bancare electronice, ci apeleaz la teri pentru a face acest lucru, bncile dau dovad de prea puin interes n ceea ce privete riscurile, indiferent de mrimea lor. Aceste a anumite subcontractri5, care au ca ultim scop externalizarea serviciilor pn n momentul n care banca nu mai rmne dect cu funcia i cu competena ei de baz, sunt benefice pentru piaa bancar, ns au adus i provocri n managementul riscurilor. De aceea trebuie repetat ideea prin care bncile trebuie s i ia toate msurile necesare i s monitorizeze relaia cu furnizorii i activitatea acestora, la care se adaug i faptul c trebuie verificai termenii din contractele de furnizare ncheiate, pentru a se nu se nclca unele legi n vigoare.

1.2 Perspective viitoare ce va fi dup E-Banking

Avnd n vedere c pn n momentul de fa s-au prezentat modificrile i riscurile survenite n interiorul bncilor n urma trecerii de la canalele tradiionale bancare la serviciile bancare accesibile pe cale electronic, este necesar trecerea n revist a perspectivelor de viitor pentru aceast pia bancar, pentru a vedea cum va evolua E-Banking-ul sau dac va fi nlocuit de un alt fel de servicii bancare pentru clieni. Se pare c aceast idee este mprit i n practic, n
Trufau, M. C., The Impact of Delivering E-Banking Services on the Traditional Banking Risks, n revista Informatic Economic, nr.4(32)/2004, pg 5, la http://revistaie.ase.ro/content/32/trufasu.pdf
5

sensul c sunt dou perspective ce par s i fac loc n sistemul bancar. Prima dintre acestea este evoluia E-Banking-ului prin canalul oferit de dispozitivele mobile, M-Banking, pn la o anumit limit unde E-Banking-ul va fi reprezentat n totalitate de ctre M-Banking. A doua perspectiv, care pornete din prisma unei companii americane, este nlocuirea tuturor serviciilor bancare electronice actuale printr-un USB drive care ncorporeaz funciuni ce vor fi detaliate ulterior. n primul rnd, pe msur ce Mobile Banking-ul ofer bncilor abilitatea de a se angaja n mod complet n conversaii cu clienii prin intermediul dispozitivelor mobile, este necesar coordonarea fluxului de afaceri ntre diferite sisteme bancare. Pentru a ndeplini aceasta, providerii de Mobile Banking trebuie s stabileasc ci directe i deschise pentru a se accesa aceste diferite surse de informaie din fluxurile de afaceri. Aceast conectivitate este crucial pentru a furniza un serviciu Mobile Banking complet. Pentru a furniza valoare autoritar ctre clieni i pentru a produce o adoptare puternic, soluiile bancare mobile de ultim generaie trebuie s dea curaj instituiilor s foloseasc canalul mobil ca o extensie a tehnologiilor existente. Aceasta va rezolva instant probleme clienilor i va ndeplini sarcinile mai repede i mai economic. Totui, astzi, multe instituii bancare i vnztori de dispozitive mobile sunt legai de funcionalitile de baz pe care le ndeplinesc aceste dispozitive. De aceea, se preconizeaz c soluiile mobile detepte de mine vor anticipa ateptrile clienilor i vor realiza ce reprezint canalul mobil o tehnologie construit pentru a crete loialitatea i satisfacia clienilor prin crearea de conversaie. Totodat, dat fiind faptul c Mobile Banking-ul tinde s ofere cele mai sigure metode de autentificare (aici este vorba despre implementrile actuale ale semnturilor digitale), se ateapt emergena dispozitivelor de identificare dedicate; aceste dispozitive vor avea rolul de a ne pstra identitatea n format digital, iar fiecare tranzacie va fi deblocat de ctre aceste dispozitive. Evoluia aceasta complet ctre Mobile Banking deja a nceput s fie vizibil, avnd n vedere c, la sfritul anului 2010, Google a introdus primul smartphone cu funcia NFC6, Nexus S, produs de cei de la Samsung. O simpl aplicaie de pe acest smartphone l transform ntr-un adevrat procesor portabil de pli. S-a menionat c acesta are funcia NFC, dar trebuie detaliat acest acronim pentru a se nelege mai bine practic ce se ntmpl cu acest smartphone. Acronimul NFC face referire la near field communications, adic o serie de tehnologii wireless care funcioneaz pe o raz mic de aciune, n general avnd nevoie de o distan de 4 cm sau mai mic. Aceste tehnologii necesit un iniiator i o int. Iniiatorul activ genereaz un cmp de frecven radio (RF) prin care interacioneaz cu inta. Cele trei principale
6

Lance W., Future of Mobile Banking: Paying with Your Cell Phone , la http://moneywatch.bnet.com/savingmoney/article/future-of-mobile-banking-paying-with-your-cell-phone/6238761/

utilizri ale NFC sunt partajarea, crearea de perechi i tranzaciile, tocmai de aceea sunt cele mai potrivite tehnologii de a fi folosite pentru tranzaciile bancare mobile. Revenind la introducerea primului smartphone, ar trebui menionat c deocamdat acesta este singurul lansat oficial, ns multe alte dispozitive sunt pe cale s fie lansate; Nokia i BlackBerry au promis ca pn la sfaritul 2011 s-i lanseze propriile smartphone-uri NFC. Deja prerile bancherilor sunt mprite n ce privete n special securitatea acestor dispozitive mobile, iar pentru a se nltura aceste griji, industria bancar lucreaz la instituirea unui numr de garanii. Printre acestea se numr i cererea unui cod de acces atunci cnd se vrea efectuarea unei pli la un punct bancar, exact ca n cazul cnd clientul folosete cardul la ATM. Trecnd la cea de-a doua perspectiv, cea oferit de o firm american, IronKey7, viitorul EBanking se ndeprteaz de la prima idee, a Mobile Banking. Astfel, aceast firm a venit n pia cu un drive USB care poate fi folosit pentru accesarea virtual a conturilor bancare fr a implica sistemele de operare sau aplicaiile care cauzeaz att de multe probleme de securitate n ziua de azi. Determinat de dorina companiilor ce vor s i protejeze conturile bancare corporative, Trusted Access for Banking este de fapt un USB drive standard ce ruleaz un mediu virtual Linux n interiorul sistemului de operare al calculatorului. De asemenea, vine cu propriul browser, pentru a accesa numai un anume serviciu bancar; acest drive ncorporeaz i un token software cu criptare RSA pentru autentificare. Desi acest dispozitiv pare a fi unul care s revoluioneze piaa bancar, pentru clientul de rnd este posibil ca costul s fie prea mare. Tocmai de aceea experii n domeniu spun c cea mai mare posibilitate de existen a acestor dispozitive s se ntlneasc la accesul bancar n corporaii i ntr-un numr mult mai mic la clienii persoane fizice. Orice perspectiv ar avea viitorul E-Banking-ului, ntotdeauna vor exista i rufctori informatici care vor ncerca fie s interfereze undele de frecven ale dispozitivelor NFC menionate anterior, fie s i creeze propriile medii virtuale cu care s atace datele i informaiile confideniale. n ultim instan, se preconizeaz dispariia n totalitate a cash-ului, deoarece oamenii, lund parte la tranzacii financiare, vor ncepe s realizeze cu adevrat care sunt problemele i riscurile asociate folosirii banilor ghea.

Dunn, J. E., Virtualized USB Key: The Future of Online Banking? , la http://www.pcworld.com/article/190015/virtualized_usb_key_the_future_of_online_banking.html

10

2. Arhitectura Client-Server i aplicaiile Web

Pn n prezent au fost trecute n revist modificrile ce au avut loc odat cu trecerea de la sistemele bancare tradiionale la cele pe cale electronic, precum i tendinele E-Banking-ului, ns nu s-a adus n discuie arhitectura pe care sunt bazate serviciile bancare electronice. Este vorba aici de arhitectura client-server, care va fi detaliat n continuare.

2.1 Arhitectura Client-Server

Arhitectura client-server este o arhitectur de baz n funcionarea internetului, ce a fost neneleas la nceput. Acest model de arhitectur este o structur de aplicaii distribuite care mparte sarcini sau fluxuri de lucru ntre 2 entiti, i anume furnizorii unei resurse sau ai unui serviciu, numii servere, i cei ce solicit aceste servicii sau resurse, denumii clieni. Adesea, clienii i serverele comunic prin intermediul unei reele de calculatoare pe elemente hardware diferite, ns ei rezid n acelai sistem. Un server este o gazd care ruleaz unul sau mai multe programe de server, cu ajutorul crora resursele sau serviciile sunt partajate cu clienii. Aceast partajare vine doar din partea serverului, deoarece clientul nu-i mprtete resursele de asemenea. ns ceea ce face clientul este s cear coninutul unui server sau o funcie a respectivului server. Deci, iniiatorul comunicrii este clientul, prin cererea pe care o face ctre server, iar serverul este destinatarul: el ateapt cereri de la clieni8. Programele client de obicei gestioneaz poriunea aplicaiei ce ine de interfaa-utilizator, valideaz datele introduse de ctre utilizator, expediaz cererile ctre programele de server i uneori execut logica de afaceri. Procesul bazat pe client este partea din fa a aplicaiei, pe care utilizatorul o vede i cu care acesta interacioneaz. De asemenea, procesul client gestioneaz resursele locale cu care utilizatorul interacioneaz, cum ar fi monitorul, tastatura, staia de lucru i perifericele. Unul dintre elementele cheie ale unei staii de lucru client este interfaa grafic a utilizatorului. Avnd n vedere multitudinea de legturi existente astzi pe internet, un server ndeplinete adesea i funcia de client, atunci cnd rezultatul cererii clientului iniial nu poate fi furnizat de server i acesta trebuie s lanseze cererea n continuare ctre un alt server, operaiunea repetndu-se pn se gsete rspunsul la cerere, care este apoi furnizat n sens invers cererii, pn la iniiatorul cererii. Unii ar crede c diferena principal dintre servere i calculatoarele personale ar fi aceea a hardware-ului, ns nu este aa. Cea mai mare diferen este aceea a software-ului: pe servere ruleaz sisteme de operare care au fost proiectate n mod special pentru a face fa tuturor

http://en.wikipedia.org/wiki/Client-server_model

11

cererilor efectuate de ctre clieni i pentru a le ndeplini cu succes. Avnd acestea menionate pn n momentul de fa, este necesar i trecerea n revist a avantajelor i dezavantajelor ce vin odat cu aceast arhitectur. n primul rnd, utilizarea arhitecturii client-server se bucur de urmtoarele avantaje: n majoritatea cazurilor, arhitectura client-server permite ca rolurile i responsabilitile unui sistem computaional s fie distribuite ntre cteva computere independente care se cunosc ntre ele numai prin intermediul unei reele. Asta creeaz un avantaj adiional pentru arhitectur: o mai mare uurin n ntreinere; toate datele sunt stocate pe servere, care au, n general, controale mult mai bune ale securitii dect orice client. Serverele pot controla accesul i resursele pentru a garanta c numai clienii cu permisiunile necesare pot accesa i schimba datele; odat ce stocarea datelor este centralizat, update-urile pentru respectivele date sunt mult mai uor de administrat dect n cazul unei arhitecturi peer-to-peer (de la egal la egal). n cazul ultimei arhitecturi, update-urile datelor trebuie distribuite i aplicate la fiecare participant al reelei, activitate ce este consumatoare de timp, deoarece poate fi vorba de mii sau chiar milioane de participani; multe tehnologii client-server aflate la maturitate sunt deja disponibile, ele fiind proiectate s asigure securitatea, o interfa user-friendly i uurin n folosire; arhitectura client-server funcioneaz cu clieni multipli diferii, care au capaciti diferite. Totui, trebuie s privim i cealalt fa a monedei pentru arhitectura client-server, i anume 2 mari dezavantaje ale acesteia: pe msur ce numrul cererilor simultane venite din partea clienilor ctre un anumit server crete, serverul devine suprancrcat. n schimb, ntr-o reea peer-to-peer, limea de band crete pe msur ce sunt adugate alte noduri; Paradigmei client-server i lipsete robusteea unei reele peer-to-peer bine pus la punct. n client-server, n cazul unei cderi critice a serverului, cererile clienilor nu mai pot fi ndeplinite. Deoarece s-au menionat trsturile generale i modul de funcionare al arhitecturii clientserver, se poate trece la prezentarea diferitelor arhitecturi ale mediilor client-server. Odat ce numrul de utilizri ale aplicaiilor web crete, este necesar o examinare a celei mai bune arhitecturi care s suporte aplicaiile web. n principiu, va fi prezentat arhitectur a pe straturi, care practic sparge o aplicaie n buci logice ce sunt numite straturi sau niveluri. Straturile pot exista pe acelai computer i pot fi conectate virtual sau logic sau pe maini diferite. 12

Cele mai simple exemple de arhitectur pe straturi sunt enumerate ca fiind pe 1 strat, pe 2 straturi i pe 3 straturi. ns, n prezenta lucrare, vor fi tratate arhitecturile pe 2, 3 i n straturi pentru a exemplifica cu succes ceea ce se dorete. Astfel, arhitectura client-server pe 2 straturi practic furnizeaz o reea de baz ntre client i server. Ca referin, putem meniona c modelul web de baz este un model pe 2 straturi. Acest model este folosit s descrie sistemele client-server unde clientul cere resurse i serverul rspunde n mod direct cererii, folosindu-se de propriile resurse9. Asta nseamn c serverul nu apeleaz la alt aplicaie pentru a-i furniza o parte din serviciu. ns, prin propria-i natur, o aplicaie pe 2 straturi nu este scalabil dup un anumit punct. Sunt mai multe motive pentru acest lucru. Unul dintre acestea este numrul de conexiuni pe care o baz de date le poate menine concomitent. Dac ne imaginm un numr de un milion de utilizatori care acceseaz n acelai timp serverul, reuim s ne dm seama ct de greu va reaciona acesta din urm la cererile utilizatorilor. Nu exist nici o cale pentru a gestiona efectiv conexiunile cnd sunt create pe calculatorul utilizatorului. De aceea, acest model de arhitectur este folosit de obicei n mediile de lucru cu un numr redus de utilizatori (mai puin de 100 utilizatori). O greeal comun n dezvoltarea client-server este de a furniza o aplicaie pentru un mediu de lucru mic, pe 2 straturi, iar mai apoi ncercarea de a aduga utilizatori la ea. Aceast abordare va duce ntr-un final la un sistem care nu mai este eficace, deoarece serverul devine copleit de cererile utilizatorilor. Pentru a urca un astfel de mediu ctre sute sau mii de utilizatori, de obicei este necesar trecerea la o arhitectur pe 3 straturi, ale crei caracteristici vor fi prezentate imediat.

Figura 2.1 Arhitectur client-server pe 2 straturi

Networking - 3 Tier Client/Server Architecture, la http://en.kioskea.net/contents/cs/cs3tier.php3

13

Arhitectura client-server pe 3 straturi aduce ca modificare fa de modelul pe 2 straturi prezentat anterior nc un server (sau un agent) ntre client i server10. Rolul acestuia este variat. Astfel, el poate s furnizeze servicii de traducere, servicii de msurare (poate aciona ca un monitor de tranzacii pentru a limita numrul de cereri simultane trimise ctre un server) sau servicii inteligente (poate mapa o cerere ctre un numr de servere diferite, iar apoi unete rezultatele pentru a furniza clientului un singur rspuns). Acest model pe 3 straturi face parte din clasa general de modele denumite pe n straturi, fiind cel mai folosit. n acest model, interfaa utilizator, logica funcional a proceselor (regulile afacerii), stocarea datelor i accesul la acestea sunt dezvoltate i ntreinute ca module independente, cel mai adesea pe platforme separate. Acest model de arhitectur client-server a fost dezvoltat de John Donovan la Cambridge, Massachusetts. Pe lng avantajele uzuale ale software-ului modular cu interfee bine definite, arhitectura pe 3 straturi este destinat s permit oricrui din cele 3 straturi s fie mbuntit sau nlocuit independent pe msur ce necesitile sau tehnologia se schimb. De exemplu, dac s-ar efectua o schimbare a sistemului de operare n stratul de prezentare nu ar afecta dect codul interfeei utilizator i nimic altceva. n general, interfaa utilizator este rulat pe un calculator personal sau pe o staie de lucru i folosete o interfa grafic utilizator standard, logica funcional a proceselor poate consta ntrunul sau mai multe module separate ce ruleaz pe un server staie de lucru sau server de aplicaii, iar un sistem de gestiune al bazelor de date aflat pe un server de baze de date conine logica de stocare a datelor. Ca un considerent final al acestui model pe 3 straturi, stratul din mijloc poate fi la rndu-i mprit n mai multe straturi. n acest caz, arhitectura total este numit arhitectur pe n straturi, ce urmeaz a fi tratat n continuarea acestui paragraf.

10

http://www.faqs.org/faqs/client-server-faq/

14

Figura 2.2 Arhitectur client-server pe 3 straturi O arhitectur pe n straturi este o arhitectur ce folosete mai multe straturi pentru a interpreta cererile i pentru a transfera date ntre diferite locuri. De fapt, judecnd din prisma a cele prezentate pn n acest punct, o arhitectur pe n straturi este i cea pe 3 straturi prezentat anterior. Deci numrul n este >=3. Fiecare strat este independent fa de celelalte, cu excepia stratului de deasupra i celui de dedesubt. Un oarecare strat trebuie s tie doar cum s prelucreze cererea de la stratul de deasupra i cum s o trimit ctre stratul de dedesubt, pentru ca mai apoi s primeasc rezultatele cererii. Aceasta arhitectur furnizeaz un model pentru dezvoltatorii ce doresc crearea unei aplicaii flexibile i reutilizabile. Principalul avantaj al folosirii acestui model de arhitectur pe straturi multiple este faptul c complexitatea asociat afacerii i procesului este redus i este foarte uor de lucrat cu ea. Un avantaj al acestei arhitecturi este c dezvoltatorii vor trebui s modifice sau s adauge un strat specific, dect s rescrie toat aplicaia de la capt, n cazul n care se decide modificarea aplicaiei.

15

Figura 2.3 Arhitectur client-server pe n straturi

2.2 Aplicaiile Web

O aplicaie web este o aplicaie accesat ntr-o reea, cum ar fi un intranet sau internetul. Acest termen face referire la un software gzduit ntr-un mediu controlat de browser (un Java applet) sau codat ntr-un limbaj suportat de browser (cum e JavaScript, combinat cu un limbaj de markup cum ar fi HTML) i care se bazeaz pe un browser web comun pentru a face aplicaia executabil. Aplicaiile web sunt populare datorit omniprezenei browser-elor web i comoditii de a folosi un astfel de browser web ca un client. Capacitatea de a actualiza i ntreine aplicaiile web fr distribuirea i instalarea de software pe un numr potenial de mii de calculatoare client este un motiv cheie pentru popularitatea lor, aa cum este i suportul inerent pentru compatibilitile inter-platforme. Pe partea de interfa, prin intermediul Java, JavaScript, DHTML i alte tehnologii, metodele specifice aplicaiilor, cum ar fi desenarea pe ecran, redarea audio i accesul la mouse sau tastatur, sunt toate posibile. Multe servicii au lucrat mpreun pentru a combina toate acestea ntr-o interfa mai familiar care preia aspectul unui sistem de operare. Tehnicile cu scop comun cum ar fi drag and drop sunt de asemenea suportate de aceste tehnologii. Dezvoltatorii de aplicaii web folosesc adesea scripting pe partea de client pentru a aduga funcionalitate, n 16

special pentru a crea o experien interactiv care nu necesit rencrcarea paginii. Recent, tehnologiile au fost dezvoltate s coordoneze scripting-ul pe parte de client cu tehnologiile pe parte de server cum ar fi PHP. Dei astzi exist multe variaii n ceea ce privete numrul de straturi din arhitecturile clientserver, cea mai comun structur este cea a aplicaiilor pe 3 straturi. Un browser web este primul strat, un motor care folosete tehnologii dinamice pentru coninut web (cum ar fi ASP, ASP.NET, JSP, JAVA, PHP etc.) reprezint stratul de mijloc, iar o baz de date reprezint ultimul strat. Pentru a nelege mai bine cum funcioneaz aceast arhitectur pe 3 straturi, cel mai bine ar fi prezentarea n continuare a straturilor 2 i 3, mai exact a tehnologiei PHP i a unei baze de date, anume MySQL. PHP este un limbaj de scripting cu scop general ce a fost proiectat iniial pentru dezvoltare web pentru a produce pagini web dinamice. Pentru acest scop, codul PHP este ncorporat n documentul-surs HTML i interpretat de un server web cu un modul de procesare PHP, care genereaz documentul pagin web. A evoluat de asemenea pn s-a ajuns la includerea unei capabiliti de interfa cu linii de comand i poate fi folosit n aplicaii grafice de sine stttoare. PHP poate fi lansat pe majoritatea serverelor web i ca un interpretor de sine stttor, pe aproape orice sistem de operare sau platform gratuit. Fiind tiut ca un mare competitor al motorului de scripting oferit de Microsoft, Active Server Pages, i a altor limbaje similare, PHP este instalat pe mai mult de 20 de milioane de site-uri web i 1 milion de servere web. PHP poate fi folosit cu multe sisteme de gestiune a bazelor de date relaionale. Acest limbaj de scripting este disponibil gratuit, iar Grupul PHP furnizeaz utilizatorilor codul-surs complet pentru a construi, customiza i extinde pentru propriul uz. n prim faz, PHP acioneaz ca un filtru, prelund intrarea dintr-un fiier ce conine text i/sau instruciuni PHP i mai apoi trimind un ir de date; n mod obinuit, rezultatul va fi HTML. PHP a atras dezvoltarea multor cadre de lucru care furnizeaz blocuri de construcie i o structur de proiectare pentru a promova RAD (rapid application development metodologie de dezvoltare software). Trecnd la cel de-al treilea i ultimul strat al modelului de arhitectur pe 3 straturi, va fi adus n discuie sistemul de gestiune a bazelor de date relaionale MySQL. Astfel, MySQL ruleaz ca un server ce furnizeaz acces pentru utilizatori multipli la un numr de baze de date. Proiectul de dezvoltare al MySQL a fcut ca codul-surs s fie disponibil sub termenii GNU General Public License, precum i sub o varietate de acorduri proprietare. MySQL a fost deinut i sponsorizat de o singur firm, compania MySQL AB, care acum este sub proprietatea corporaiei Oracle. Multe proiecte open-source ce folosesc software gratuit care necesit un sistem de gestiune a bazelor de date cu proprieti complete adesea folosesc MySQL. 17

Pentru uz comercial, sunt disponibile cteva ediii cu plat, care ofer funcionaliti adiionale. MySQL este scris n limbajele de programare C i C++ i nu este livrat cu unelte grafice pentru administrarea bazelor de date MySQL sau pentru gestionarea datelor din aceste baze de date. Din aceast cauz, utilizatorii pot folosi uneltele linie de comand incluse sau pot descrca interfeele MySQL din diferite pri care au dezvoltat software desktop i aplicaii web care gestioneaz bazele de date MySQL, construiesc structura bazelor de date i lucreaz cu nregistrrile. Pe partea de instalare, MySQL poate fi instalat manual din codul surs, dar asta poate fi obositor, aa c de obicei este instalat dintr-un pachet binar numai dac nu sunt necesare customizri speciale. Este nc n mod comun folosit n desfurrile serverelor singulare de la dimensiune mic la dimensiune medie sau ca o component n aplicaii web de tip LAMP11 (suit de soluii, cu software open-source; acest acronim pornete de la sistemul de operare, n cazul de fa Linux, serverul Apache, MySQL i limbaj de scripting PHP/Perl/Phyton) sau ca un server de baze de date de sine stttor. Mare parte din atracia MySQL i are originile n simplicitatea-i relativ i uurina n folosire, activat de un ecosistem de unelte open-source cum ar fi PhpMyAdmin.

11

http://ro.wikipedia.org/wiki/LAMP

18

3. Prototip de aplicaie pentru extinderea funcional a aplicaiei EBanking de la Banca Romn pentru Dezvoltare
Banca Romn pentru Dezvoltare este una dintre multele bnci din Romnia care au implementate servicii bancare electronice pentru clieni, cu disponibilitate 7 zile pe sptmn, 24 de ore pe zi. Banca furnizeaz servicii bancare electronice sub toate cele 3 forme ale EBanking, adic Internet Banking cu aplicaia BRD-Net pentru persoane fizice i BRD@ffice pentru persoane fizice, Home Banking cu aplicaia MultiX i Mobile Banking cu Mobilis12. Avnd n vedere ca BRD furnizeaz aceste servicii electronice pe toate cile posibile, a fost cea mai potrivit alegere pentru a proiecta o parte de aplicaie care s duc la extinderea funcional a proceselor din cadrul Internet Banking BRD.

3.1 Analiza situaiei

La o simpl logare n aplicaia BRD-Net cu id-ul i parola furnizate la nceperea utilizrii serviciului, fiecare client are posibilitatea s fac diverse tranzacii i s acceseze diverse servicii. ns, atunci cnd utilizatorul dorete s efectueze un transfer sau s seteze o plat programat pentru un anume beneficiar, el trebuie s l selecteze dintr-o list disponibil. Pn n momentul de fa, totul este normal. n schimb, n cazul n care se dorete adugarea unui nou beneficiar n baza de date, aceast operaiune se face numai prin deplasarea utilizatorului la unitatea BRD la care a fost ncheiat contractul sau prin contactarea telefonica a serviciului Vocalis furnizat de banc la numerele disponibile, apelabil din orice reea de telefonie mobil, de luni pn duminic, ntre orele 08:00-22:00. Prima opiune este valabil att pentru persoanele fizice, ct i pentru cele juridice, pe cnd a doua este disponibil numai persoanelor fizice. Dar, oricare ar fi opiunea aleas, din momentul n care se face adugarea beneficiarului i pn acesta este disponibil a fi selectat din list trece o zi. Pentru unii utilizatori aceast durat poate s reprezinte o adevrat piedic dac se dorete transferul de bani ntr-un timp mai scurt. De asemenea, dac se utilizeaz serviciul Vocalis, exist posibilitatea ca operatorul s l roage pe client s mearg la sediul bncii pentru o recunoatere fizic. Aceasta se poate ntmpla dac utilizatorul sun de pe un alt numr de telefon, iar mai apoi este sunat de ctre operatori pe numrul de telefon dat la ncheierea contractului i nu rspunde pentru confirmare. Acesta nu este un fapt public confirmat de ctre BRD, ns pentru aceste afirmaii stau mrturie relatrile diferiilor utilizatori care au vrut s adauge beneficiari i au ntmpinat uneori probleme.

12

http://www.banking.ro/e-banking.php

19

Acesta este i motivul pentru care n partea de proiectare a prototipului pentru aplicaie s-a dorit extinderea funcional prin oferirea posibilitii de introducere a beneficiarilor online, urmnd s existe 2 metode de verificare i confirmare a cererii clientului, ce vor fi detaliate ulterior n acest capitol.

3.2 Proiectarea aplicaiei

Pentru aplicaie am luat decizia de a face o copie dup aplicaia original, cu meniunea c prile funcionale din aceast aplicaie sunt cele ce au legtur cu beneficiarii clientului, i anume adugarea unui beneficiar, vizualizarea listei actualizate a beneficiarilor, precum i prile de transferuri ctre beneficiari i pli programate ctre beneficiari. Aplicaia ar trebui s cuprind procesele principale ce sunt necesare a fi efectuate n lucrul cu beneficiarii, procese ce sunt surprinse i n figura 3.1. Astfel, acestea se prezint dup cum urmeaz: completarea formularului cu datele cerute pentru beneficiarul ce se dorete a fi introdus; trimiterea datelor ctre baza de date, prin acionarea butonului de Adaug beneficiar; acceptarea sau respingerea cererii de introducere a unui nou beneficiar n baza de date.

Figura 3.1 Procesele pentru introducerea unui nou beneficiar 20

Este necesar, de asemenea, s detaliem ultimul proces, de acceptare sau respingere a cererii de introducere, deoarece acesta este unul mai complicat. Astfel, odat ce a fost trimis ctre baza de date formularul cu datele pentru noul beneficiar, va avea loc unul din urmtoarele 2 subprocese: un subproces automatizat, n care sistemul trimite, pentru verificare, un SMS pe telefonul mobil al clientului n care acesta este rugat s trimit parola de acces a aplicaiei pentru respectiva cerere, iar clientul rspunde tot prin SMS (gratuit, n urma acordului ntre banc i companiile de telefonie mobil). Dac parola este cea corect, beneficiarul este introdus n baza de date, iar n cazul n care este incorect se va cere nc o dat aceasta; la a doua trimitere a parolei greite, se renun la introducerea beneficiarului n baza de date. De asemenea, n cazul n care clientul nu are nici o idee despre ce este vorba, poate apela serviciul Vocalis pentru a se clarifica; un subproces manual, n care clientul este sunat de ctre un operator al bncii, care l ntreab dac este iniiatorul cererii; dac rspunsul este afirmativ acestuia i se va cere id-ul i parola de acces. Furnizate corect, acestea duc la introducerea n baza de date a beneficiarului. n caz contrar, vor urma discuii edificatoare cu clientul, discuii ce vor avea loc i n cazul n care clientul neag c ar fi iniiatorul cererii; Ambele subprocese menionate au i cel mai mare rol pe partea de securitate a operaiunilor efectuate n privina introducerii de beneficiari, asta deoarece este foarte improbabil ca unui client s-i fie furate att datele de acces n aplicaie, ct i telefonul mobil. Astfel, dac iniiatorul constat c este contactat pentru o cerere de care nu are habar, va comunica acest lucru bncii. Pentru prezentarea evenimentelor acestei activiti, am considerat c este necesar doar exemplificarea prin intermediul figurii 3.2.

21

2. Trimitere cerere

4. Adugare beneficiar

3.1.1 Cerere parola 1. Completare formular 3.1.2 Confirmare parola 3.2.1 Preluare date de ctre operator 3.2.3 Confirmare cerere

3.2.2 Discuie operator-client pentru confirmare cerere

Figura 3.2 Evenimentele activitii de introducere a unui nou beneficiar De asemenea, pentru introducerea unui nou beneficiar i apoi selectarea acestuia din baza de date pentru tranzacii, este necesar prezentarea scenariilor de lucru ale formularelor de introducere i de transfer din aplicaia prototip BRD-Net, lucru fcut n urmtoarele 2 tabele: Tabelul 3.1 Scenariul de lucru din formularul pentru introducerea unui nou beneficiar Scenariu Zon de lucru Clientul acceseaz aplicaia, se logheaz, Adugarea unui nou beneficiar merge la modulul Transferuri - Beneficiari, iar apoi selecteaz Adaug un beneficiar nou o Introducerea datelor despre Clientul trebuie s completeze formularul de beneficiar ce sunt cerute n adugare beneficiar cu urmtoarele date: cadrul formularului Nume beneficiar; Tip beneficiar; Numr cont; Moneda cont; Filiala Banca. o Trimiterea formularului ctre Se acioneaz butonul Adaug beneficiar, serverul de baze de date iar datele sunt trimise ctre server, unde are loc unul din cele dou subprocese menionate anterior, pentru a se verifica cererea i pentru introducerea n baza de date

22

Tabelul 3.2 Scenariul de lucru din formularul pentru selectarea unui beneficiar Scenariu Zona de lucru Clientul acceseaz aplicaia, se logheaz, Transferul ctre un anume beneficiar merge la modulul Transferuri, unde selecteaz Ctre beneficiari naionali o Selectarea datelor cerute Clientul selecteaz din baza de date urmtoarele: Transferuri predefinite; Din contul (debit); Beneficiar. o Introducerea datelor cerute Clientul acceseaz butonul de Astzi dac vrea ca data transferului s fie ziua curent sau introduce alt dat; De asemenea, introduce motivul i detaliile transferului i suma (n moneda contului) despre care este vorba; o Trimiterea cererii pentru Se acioneaz butonul Validare transfer ctre server sau pentru a nregistra transferul, caz n renunarea la aceasta care apare un formular n care i se spune clientului c transferul a fost nregistrat i i se furnizeaz o legtur pentru a se ntoarce la seciunea de transferuri; Se acioneaz butonul Anulare pentru a se anula transferul, fcnduse automat ntoarcerea la lista de beneficiari

Acest ultim scenariu este valabil att pentru transferul ctre beneficiari naionali, ct i pentru beneficiari internaionali. De asemenea, aplicaia ofer un formular pentru setarea unei pli programate ctre beneficiari naionali, singurele diferene fiind acelea c, dup accesarea aplicaiei, se va merge la modulul Pli programate i se va selecta Ctre beneficiari naionali, iar n cadrul formularului mai este necesar selectarea frecvenei plilor i data cnd trebuie s se nchid sesiunea de pli programate. Avnd n vedere c s-au detaliat pn n momentul de fa scenariile pentru formularele de introducere a unui nou beneficiar i de selectare ulterioar a acestuia pentru tranzacii, este necesar i o prezentare a obiectelor de pe fiecare formular, obiecte detaliate n tabelele 3.3 i 3.4. Aplicaia a fost realizat n limbajul PHP, aa c fiecare obiect din formulare este prezentat ca avnd un id, de aceea denumirea obiectului va face referire la id-ul corespunztor.

23

Tabelul 3.3 Obiectele de pe formularul de introducere a unui nou beneficiar Nr. Denumire Crt. 1 adaugarebeneficiartitlu 2 3 introd_numebeneficiartxt introd_nume Explicaie Textul Adugare beneficiar de dinaintea csuelor de introducere a datelor Textul Nume beneficiar Csua text unde clientul trebuie s introduc numele beneficiarului pe care vrea s l adauge n lista de beneficiari Textul Tip beneficiar List de opiuni din care clientul poate s aleag tipul beneficiarului, cu valorile National i International Textul Numr cont Csua text unde va fi introdus numrul de cont al beneficiarului, pentru ca sistemul s tie unde s vireze banii din urma transferurilor i a plilor programate Textul Moneda cont List de opiuni din care clientul poate s aleag moneda beneficiarului, cu valorile RON, EUR, USD, GBP i CHF Textul Filiala banca Csua text unde se introduce filiala bncii la care are beneficiarul ncheiat contractul Butonul cu textul Adaug beneficiar, care face trimiterea datelor din formular ctre server, pentru a fi introduse ulterior n baza de date

4 5 6 7

select_tipbeneficiartxt select_tipbeneficiar numarconttxt introd_nrcont

8 9

select_monedacont select_tipmoneda

10 11 12

filialabancatxt introd_filiala btnadauga

Figura 3.3 Formularul pentru adugarea unui nou beneficiar

24

Tabel 3.4 Obiectele de pe formularul de efectuare a unui transfer ctre beneficiari naionali/internaionali Nr. Denumire Crt. 1 transferuripredefinitetxt 2 transfer 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 n Explicaie Textul Transferuri predefinite din faa listei de opiuni List de opiuni de unde clientul poate selecta Transfer manual sau Adugare transfer predefinit dincont Textul Din contul (debit) selectcont List de opiuni ce permite clientului s aleag contul din care s se fac transferul ctre beneficiar beneficiartxt Textul Beneficiar selectform List de opiuni ce permite clientului s selecteze unul din beneficiarii naionali/internaionali definii anterior datatext Textul Data astazi Buton radio pentru a selecta data transferului ca fiind cea curent altadata Textul La o alt data introd_data Csua text unde se introduce data n formatul artat imediat formatdatatxt Textul Format data(15/12/2010) motiv Textul Motiv motivtext Csua text unde se introduce motivul pentru care se efectueaz transferul detaliitransfer Textul Detalii transfer detaliitransfertext Csua text unde se introduc detalii n legtur cu transferul ce se vrea a se efectua suma Textul Suma(n moneda contului) sumatext Csua text unde se introduce suma de bani ce se vrea a fi transferat, exprimat n moneda contului btnvalidaretransfer Buton care, la accesare, valideaz transferul ctre beneficiar i duce la apariia unui formular de confirmare btnanularetransfer Buton de anulare a transferului, cu ntoarcere la lista de beneficiari cazul n care este vorba de setarea unei pli programate ctre un beneficiar naional, la Tabelul 3.5 Obiecte suplimentare din formularul de pli programate ctre beneficiari naionali Nr. Denumire Crt. 1 frecventatxt 2 frecventa 3 4 5 dataultimtext introd_data_ultima formatdataultim Explicaie Textul Frecventa List de opiuni de unde clientul selecteaz una din valorile Zilnic, Sptmnal, Bi-lunar, Lunar Textul Data ultimului transfer Csua de text unde se introduce data cnd se va face ultimul transfer n format lun/an Textul cu formatul datei (ex: 12/2018)

obiectele din tabelul anterior se adaug urmtoarele:

25

Figura 3.4 Formularul pentru efectuarea unui transfer ctre beneficiar

Figura 3.5 Diagrama de secven pentru evenimentul de postare din formularul de introducere

26

Figura 3.6 Diagrama de secven pentru evenimentul din formularul de selectare

3.3 Prototip implementat

Arhitectura pe care s-a bazat este cea pe 3 straturi, acestea fiind, dup cum urmeaz: interfaa browser-ului primul strat; serverul HTTP Apache i PHP stratul doi de legtur ntre interfa i baza de date; serverul de baze de date ultimul strat;

Astfel, pentru dezvoltarea aplicaiei s-au folosit mai multe unelte, dup cum urmeaz: pachetul software WAMPP, aplicaia PHPDesigner, add-on-ul Web Developer de la Mozilla Firefox i Macromedia Dreamweaver. Pachetul XAMPP include serverul HTTP Apache, MySQL i phpM yAdmin cu care s-a lucrat pentru a rula aplicaia pe gazda local (localhost) a serverului web. Aplicaia Macromedia Dreamweaver a fost utilizat pentru crearea designului de baz a aplicaiei, prin gruparea diverselor elemente pe baza aezrii n pagina, mai precis n 2 pri: antetul i partea de mijloc, care include la rndu-i bara lateral din stnga i seciunea principal. Odat delimitate aceste elemente, s-a trecut la folosirea PHPDesigner pentru a apela aceste elemente i pentru a se efectua completrile necesare n funcie de modulul de aplicaie selectat. Aceste elemente au fost totui aezate haotic n pagin, deci a fost nevoie de o unealt software care s ajute la alinierea i formatarea acestora. De aceea s-a trecut la instalarea add-on-ului Web Developer, care permite n timp real modificarea stilurilor CSS pentru fiecare seciune de pagin i fiecare element. Fiecare element a avut un id propriu, asta fcnd utilizarea stilurilor CSS mai uoar. Lsnd interfaa n spate i trecnd la partea de baze de date, ne-am folosit de utilitarul MySQL oferit de pachetul XAMPP pentru realizarea a dou tabele n baza de date, unul dintre ele coninnd conturile clientului, iar cellalt beneficiarii pentru respectivul client, dup cum se 27

poate vedea i n figurile 3.7 i 3.8. Primul tabel, cel cu conturile clientului, are 4 cmpuri, dup cum urmeaz: numecont numele dat de ctre client contului; nrcont numrul de cont; valuta valuta contului; sold soldul contului la momentul actual.

Pentru cel de-am doilea tabel, cu beneficiarii, am folosit 5 cmpuri care solicit cele mai reprezentative date pentru fiecare beneficiar n parte: nume numele complet al beneficiarului; tip tipul beneficiarului: naional sau internaional; nrcont numrul de cont al beneficiarului; moneda moneda n care este contul; filiala filiala bncii unde s-a ncheiat contractul.

Figura 3.7 Conturile clientului

Figura 3.8 Beneficiarii clientului Tabelul din figura 3.8, cel cu beneficiarii clientului, este updatat prin intermediul formularului prezentat anterior, ce are n spate cod PHP. Pentru a vedea mai bine cum funcioneaz acest cod i legtura dintre formular i serverul de baze de date, am adus n casetele text 3.1 i 3.2 cte o poriune din codul formularului i, respectiv, din codul de introducere a beneficiarului.

28

Caseta text 3.1 Codul de introducere a unui nou beneficiar

{ case '': echo '<br><br><br><br> <div id="adaugabeneficiari"> <div id="adaugabeneficiartitlu"><font color="#B30000" id="adaugarebeneficiartitlu"><strong>Adaugare beneficiar</strong></font></h1></div> <table id="tabelbeneficiar" width="309" border="0" cellpadding="9" cellspacing="9"> <form name="formular" action="adaugarebeneficiari.php?actiune=validare" method="post"> <tr> <td height="22" align="right" valign="top"><font color="#333333" id="introd_numebeneficiartxt"><strong>Nume beneficiar</strong></font></td> <td colspan="2" valign="top"> <input type="text" id="introd_nume" name="nume" value="'.$_SESSION['nume'].'"></td> </tr> <tr> <td height="22" align="right" valign="top"><font color="#333333" id="select_tipbeneficiartxt"><strong>Tip beneficiar</strong></font></td> <td colspan="2" valign="top"> <select name="tip" id="select_tipbeneficiar"> <option selected value ="- Alegeti tipul -">- Alegeti tipul -</option> <option value ="National">National</option> <option value ="International">International</option> </select></td> </tr> <tr> <td height="22" align="right" valign="top"><font color="#333333" id="numarconttxt"><strong>Numar Cont</strong></font></td> <td colspan="2" valign="top"> <input type="text" id="introd_nrcont" name="nrcont" value="'.$_SESSION['nrcont'].'"></td> </tr> <a href="beneficiari.php"><input type="submit" id="btnadauga" style="color:#B30000; fontweight:bold;" value="Adauga beneficiar"></a></td>

Dup cum se poate observa din primul text care este ngroat, aciunea care se efectueaz la apsarea butonului Adaug beneficiar cu id-ul btnadauga este cea de validare, adic cea de introducere practic a beneficiarului, prezent n caseta text urmtoare:

29

Caseta text 3.2 Introducerea beneficiarului

case 'validare'; $_SESSION['nume']=$_POST['nume']; $_SESSION['tip']=$_POST['tip']; $_SESSION['nrcont']=$_POST['nrcont']; $_SESSION['moneda']=$_POST['moneda']; $_SESSION['filiala']=$_POST['filiala']; if(($_SESSION['nume']=='') || ($_SESSION['tip']=='') || ($_SESSION['nrcont'] == '') || ($_SESSION['moneda'] == '') || ($_SESSION['filiala'] == '')) { echo '</br></br></br></br></br></br></br></br></br></br></br></br><font color="#333333" id="confirmare" align="center" size=4px><strong>Datele introduse sunt incorecte sau incomplete.</strong></font></br> <font color="#333333" id="confirmare" align="center" size=3px><strong>&nbsp;&nbsp;&nbsp;Click <a href="adaugarebeneficiari.php"><font color="#b30000">aici</font></a> pentru a va intoarce la pagina anterioara.</strong></font>'; } else { echo '</br></br></br></br></br></br></br></br></br></br></br><font color="#333333" id="confirmare1" align="center" size=4px><strong>Va multumim !</strong></font></br> <font color="#333333" id="confirmare1" align="left" size=4px><strong>Datele dumneavoastra au fost inregistrate. Veti fi contactat n curand de un operator pentru confirmarea beneficiarului.</strong></font></br> <font color="#333333" id="confirmare1" align="center" size=3px><strong>Click <a href="../transferuri/transferuri.php"><font color="#b30000">aici</font></a> pentru a va intoarce la sectiunea de transferuri.</strong></font>'; $cerereSQL="INSERT INTO `beneficiari` (`nume`, `tip`, `nrcont`, `moneda`, `filiala`) VALUES ('".addentities($_SESSION['nume'])."', '".addentities($_SESSION['tip'])."', '".addentities($_SESSION['nrcont'])."', '".addentities($_SESSION['moneda'])."', '".addentities($_SESSION['filiala'])."')"; mysql_query($cerereSQL); $_SESSION['nume'] = ''; $_SESSION['tip'] = ''; $_SESSION['nrcont'] = ''; $_SESSION['moneda'] = ''; $_SESSION['filiala'] = ''; }

n cazul n care nu se introduc toate datele, la apsarea butonului de adugare beneficiar, clientului i va aprea un text de eroare i o legtur pentru a se ntoarce la pagina anterioar, iar n caz de succes, se va afia un text de confirmare i o legtur pentru ntoarcerea la seciunea de transferuri. De asemenea ne intereseaz i cererea SQL fcut ctre baza de date (ngroat n ultima parte), n care se vede clar cum instruciunea este cea de inserare n tabela beneficiari a datelor necesare, introduse anterior de ctre client. Dup aceast operaiune, cmpurile din formular devin goale, dup cum se vede n ultima secven de cod. Alte dou coduri cu importan n prezenta aplicaie sunt cel de selectare din baza de date pentru utilizare n cadrul transferurilor i cel pentru lista de beneficiari, care practic sunt cereri 30

sql, al cror rezultat se prezint sub forma de opiuni, n primul caz, sau sub form tabelar, n cel de-al doilea caz. Aceste coduri se regsesc n casetele text 3.3 i 3.4
Caseta text 3.3 Cod selectare beneficiari n cadrul transferurilor echo "</br><font color=#333333 id='beneficiartxt'>Beneficiar"; $sql="SELECT nrcont, nume, moneda FROM `beneficiari` where tip='National'"; $result=mysql_query($sql); //echo "<form id=selectform>"; echo "<select name=\"nrcont\" id=selectform>\n"; echo "<option value=selecteaza>Selectati un beneficiar</option>"; while ($row=mysql_fetch_assoc($result)) { $nrcont= $row['nrcont']; $nrcont2= $row['nrcont']; $nume=$row['nume']; $moneda=$row['moneda']; echo "<option value=$nrcont>$nume - $nrcont - $moneda\n</option>"; } echo "</select></br>"; Caseta text 3.4 Cod list beneficiari echo "<table id=listabeneficiari cellpadding=3 cellspacing=0> <tr bgcolor=#B30000 align=left> <th width=200>Nume Beneficiar</th> <th width=100>Tip Beneficiar</th> <th width=300>Numar Cont</th> <th width=100>Filiala Banca</th></tr>"; while($row = mysql_fetch_row($result)) { $nume = $row[0]; $tip = $row[1]; $nrcont = $row[2]; $moneda = $row[3]; $filiala = $row[4]; echo "<tr>"; echo "<td>$nume</td>"; echo "<td>$tip</td>"; echo "<td>$nrcont $moneda</td>"; echo "<td>$filiala</td></tr>";} echo "</table>";

n momentul de fa, singurul lucru care ar mai fi de menionat este c principala funcie a prototipului de aplicaie este de a oferi clienilor posibilitatea introducerii de beneficiari online, fr a mai fi nevoie s se deplaseze la sediul bncii sau s apeleze serviciul Vocalis. Astfel, orice client al bncii nu trebuie dect s deschid aplicaia de Internet Banking BRD-Net, s mearg la modulul de transferuri i s acceseze submodulul Beneficiari, de unde va avea posibilitatea s introduc un nou utilizator. Dup introducerea datelor, va avea loc una din cele dou msuri de securitate menionate anterior, pe cale manual sau automatizat, iar n urma confirmrii, clientul va avea posibilitatea pe viitor s aleag din lista de beneficiari i beneficiarul pe care l-a introdus online.

31

Concluzii
Serviciile bancare electronice sunt o certitudine i pe viitor se pare c vor nlocui cu totul canalele tradiionale de furnizare a serviciilor i produselor bancare, dup cum preconizeaz experii n domeniu. Dei a avut loc trecerea de la Banking la E-Banking, aceasta nu s-a fcut complet i nc mai sunt destule puncte unde trebuie lucrat. Cele mai importante sunt cele legate de riscurile operaionale i strategice, precum i de securitate, care este probabil cel mai mediatizat subiect al banking-ului pe cale electronic n momentul de fa. Serviciile acestea electronice se regsesc n momentul de fa sub mai multe forme Home Banking, Internet Banking, Mobile Banking i din ce n ce mai des. ns, n mare parte, aplicaiile E-Banking urmeaz o arhitectur client-server bazat pe 3 straturi sau pe n straturi, n care primul strat este interfaa pentru client, iar ultimul strat este acela al serverului final ce ncheie tranzaciile i serviciile, fie c este vorba de un server de aplicaii sau de un server de baze de date. Aceste straturi mpart sarcinile de lucru pentru a uura procesele interne, ns toate merg pe aceeai baz. Orice organizaie bancar este organizat, fr nici un dubiu, doar din perspectiva de face bani, iar extinderea serviciilor i ca numr, dar i ca metode de distribuire a acestora aduc cea mai mare profitabilitate. De asemenea, nu trebuie uitat, totui, elementul de baz, clientul, pentru c fr acesta nu s-ar face nimic. Tocmai de aceea bncile care au cei mai muli clieni mulumii sunt i cele cu cel mai mare profit. i tot din acelai motiv se extind i serviciile bancare electronice, pentru a putea fi folosite oriunde i oricnd de ctre clieni. Probabil cel mai important element n aceast ecuaie este timpul. Timpul care nu mai este pierdut de client prin deplasarea la sediul bncii i efectuarea tranzaciei sau cererea serviciului dorit. Din aceasta cauz, dezvoltatorii caut s modifice chiar i ultimii itemi care ar determina deplasarea clientului i pierderea de timp preios. La dispoziia acestora stau diverse suite de aplicaii, unele profesioniste, altele mai puin profesioniste. Totul st n mna decidenilor. Oricum ar fi i orice s-ar spune, E-Banking-ul are un urcu vertiginos ctre culmile bancare, ns va trebui s se opreasc la un moment dat.

32

Bibliografie

1. Heffernan S, Modern banking, John Wiley & Sons, Ltd, 2005, pg. 110 2. Johnson M, A new approach to Internet Banking - Technical Report, University of Cambridge,
2008, pg. 16

Articole: 3. Basel Committee on Banking Supervision, Risk Management Principles for Electronic Banking, 2003, pg.1 la http://www.bis.org/publ/bcbs98.pdf 4. Dunn, J. E., Virtualized USB Key: The Future of Online Banking?, la http://www.pcworld.com/article/190015/virtualized_usb_key_the_future_of_online_banki ng.html 5. Georgescu-Golooiu, L., Servicii bancare electronice, electronic banking/e-banking, pg. 1-2 la http://www.ligiagolosoiu.ro/content/Servicii_bancare_electronice.pdf 6. Lance W., Future of Mobile Banking: Paying with Your Cell Phone, la http://moneywatch.bnet.com/saving-money/article/future-of-mobile-banking-paying-withyour-cell-phone/6238761/ 7. Trufau, M. C., The Impact of Delivering E-Banking Services on the Traditional Banking Risks, n revista Informatic Economic, nr.4(32)/2004, pg. 5, la http://revistaie.ase.ro/content/32/trufasu.pdf Site-uri Web: 8. http://en.wikipedia.org/wiki/Client-server_model 9. Networking - 3 Tier Client/Server Architecture, la http://en.kioskea.net/contents/cs/cs3tier.php3 10. http://www.faqs.org/faqs/client-server-faq/ 11. http://ro.wikipedia.org/wiki/LAMP 12. http://www.banking.ro/e-banking.php

33