Proiectarea Si Analiza Arhitecturii Informatice Pentru O Aplicatie de Tip Bancar
Proiectarea și analiza arhitecturii informatice
pentru o
aplicație de tip bancar
Cuprins
1 Introducere
2 Banca și Sistemul Bancar
3 Arhitecturi informatice pentru aplicația bancară
3.1 SOA-Generalități
3.2 SOA în sistemul bancar
4 Ontologia Domenială
4.1 Noțiunea de ontologie
4.2 Ontologia unei aplicatii bancare
4.2.1 Specificații
4.2.2 Conceptualizare
5 Tehnologii de implementare SOA
5.1 Tehnologia J2EE
5.2 J2EE VS .NET
5.3 Windows Communication Foundation
5.3.1 Ce este WCF?
5.3.2 Arhitectura WCF si concept de baza
5.3.3 De ce WCF pentru SOA?
6 Analiza sistemului
6.1 Cerințele funcționale
6.2 Cerințele Non Funcționale ale sistemului
6.3 Arhitectura sistemului
7 Proiectarea și Implementarea
7.1 Cazuri de utilizare
7.2 Interfata cu utilizatorul
7.3 Prezentare nivelului de servicii:
7.4 Nivelul de logică de business
7.5 Prezentarea nivelului de date
8 Concluzii
9 Repere Bibliografice
Introducere
Obiectivele lucrării:
-să analizeze sistemul bancar și necesitatea implementării unei astfel de arhitecturi software, precum și partea teoretică din spatele ei;
-să prezinte o soluție a unei arhitecturii orientate pe servicii existente pe piață;
-să studieze noțiunea de ontologie, cu toate aspectele acesteia;
-să creeze o ontologie de la zero pentru aplicația ce urmează a fi implemenată, constând în definirea conceptelor, a modului de ierarhizare, a proprietățiilor si a relațiilor dintre ele.
-să prezinte tehnologiile folosite la implementare și motivele din spatele acestor
alegeri;
-să discute toate detaliile legate de implementarea și utilizarea arhitecturii.
În cazul acesta este vorba de un sistem informatic bancar ce se compune din două module: Clienți și Operații cu clienții, proiectate cu ajutorul unei arhitecturi orientate pe servicii.
Am proiectat această arhitectură informatică pe patru nivele: 1.prezentare (nivelul de portal, de personalizare la interacțiunea cu utilizatorul efectiv, care poate fi atât lucrătorul bancar din front-office, cât și clientul utilizator al serviciilor electronice); 2.nivelul de servicii(cuprinde serviciile fondate și expuse, acestea pot fi descoperite sau legate static și apoi invocate );3. logica de business (integrare de business și de aplicații, fluxuri de lucru, managementul proceselor) si 4. Nivelul de baze de date (format din baza de date a sistemului).
Serviciile create pe baza SOA (servicii informatice) au corespondență directă în serviciile bancare care sunt modelate (la nivel de diagrama și conexiuni procedurale) prin sisteme UML sau echivalente.Fiind automatizate, toate aceste operații sunt mult mai sigure, fara erori și permit o întreținere ușoară a aplicației.
Această arhitectura ar permite o segregare, un nivel de abstractizare practică cu trei componente:
1. Operațiuni – tranzacții care determină una sau mai multe înregistrari de date, de citire sau de actualizare;
2. Servicii – o grupare logică de operațiuni (de exemplu, serviciul “Cont curent” constă în operatiunile: “Actualizare informații statice client”, “Listare după client a conturilor curente”, “Creare cont curent nou”);
3. Procese de business – o serie de operațiuni care sunt executate într-o ordine secvențială în conformitate cu un set de reguli de business.
Banca și Sistemul Bancar
Ținând cont de rolul și importanța sectorului financiar-bancar s-a impus creearea unui sistem bancar modern, capabil să ofere o gama largă de produse și servicii, care să satisfacă exigențele tuturor categoriilor de intermediari financiari și a populației din economia de piață.
Banca reprezintă o instituție financiară al cărui obiect de activitate principal este atragerea de depozite și acordarea de credite. În contextul modern, cea mai importantă componentă a sistemului financiar-bancar este banca.
Băncile își desfășoară activitatea pe baza criteriului de profitabilitate, ca oricare societate comercială, urmărind în mod permanent obținerea de profit net în condiții de riscuri specifice (evoluția economică generală, restricții impuse de banca centrală, insolvabilitatea, structura financiară a băncii), de care orice bancă trebuie să țină seama în desfășurarea activității sale.
Băncile oferă un cadru deosebit de interesant, în care se poate studia adoptarea unei implemetari SOA. Băncile se confruntă cu sisteme vechi eterogene, care sunt dificil de schimbat și de integrat. Dereglementarea, scăderea marjelor de profit ,precum și creșterea rapidă a sectorului bancar online , au un impact global asupra pieței financiare. Legile restrictive bancare au dus la fragmentarea infrastructuri IT, care în prezent trebuie să fie adaptată pentru a satisface noile cerințe ale clienților. Băncile cu arhitecturi ITC vechi se confruntă cu cereri pentru creeare de sisteme informatice flexibile și de tipul eficienta-cost.
Capacitatea de a dobândi o nouă arhitectură ITC a devenit un factor cheie competitiv, ce sprijină noile drivere de business financiar în domeniul bancar (business drivers=sarcinile, informațiile și oamenii care promovează și sprijină obiectivele întreprinderii).
Aceste arhitecturi mai vechi complica integrarea aplicațiilor enterprise, deoarece elemente de bază au creat arhitecturi "închise". Arhitecturile închise restricționează accesul la configurația software-ului și hardware-ului, forțând organizațiile să se bazeze pe un singur furnizor de soluții pentru componentele sale ITC.[2]
Din punct de vedere strategic, băncile se confruntă cu patru provocări majore în ceea ce privește arhitectura:
În primul rând, acestea trebuiesc să își integreze aplicațiile. Băncile moderne au de a face din ce în ce mai mult cu o serie de produse și servicii complexe gestionate printr-un număr mare de aplicații și sisteme, care operează adesea pe platforme diferite.
Într-un cadru bancar tipic, programele IT sunt desfășurate pe mai multe perioade istorice,dar relevante ,făcând dificilă integrarea lor într-un sistem.De aceea, dezvoltarea IT în domeniul bancar modern, necesită un efort semnificativ de integrare a aplicatiiilor pentru a acoperi, conecta și include noi funcționalități în mediile IT existente . Pentru motivele de mai sus, integrarea aplicațiilor este relevantă în sistemul bancar
În al doilea rând, băncile se confruntă cu necesitatea activării valorii proceselor de reconfigurare [3] .Pentru a reduce simultan costurile și pentru a spori utilitatea clientului, băncile sunt din ce în ce mai concentrate pe capacitățile lor individuale de bază, în timp ce explorează diferite opțiuni de aprovizionare pentru cele inexistente. Prin urmare, ele segmentează lanțul de valori în unități independente funcționale. Ca și capacități de comunicare atinge niveluri ridicate de performanță și credibilitate, iar aceste unități funcționale sunt combinate în afara granițelor corporative [4].
În acest fel, lanțurile valorice sunt dezagregate și recombinate în rețele de valoare, astfel de procese sunt conectate la un mediu complex și instabil. Complexitatea mediului cere rețele de valoare , deoarece acestea servesc cel mai bine cerințelor complexe ale pieței decât lanțurile valorice. Instabilitatea mediului cere rețele de valoare, deoarece acestea se adaptează cerințelor neașteptate ale pieței sau a altor oportunități emergente.
Al treilea motiv ar fi, existența unei nevoi de a asigura conservarea valorii. Parteneriatele, fuziunile și achizițiile reconfigurează valoarea , uneori distrugând-o [5]. Atunci când sistemele vechi ale organizației sunt înlocuite subit, cunoștințe și practici încorporate în aceste sisteme sunt pierdute.
În al patrulea rând, este nevoie de mai multe forme agile de dezvoltare a sistemelor informatice.Banca funcționează după anumite reguli și forme de securitate și, în consecință, adesea este conservatoare cu privirea la crearea unui sistem informatic.Instabilitatea mediului duce la schimbări mai frecvente de sistem.
Reproiectarea continuua a sistemelor înseamnă trecerea de la dezvoltarea tradițională la abordări de dezvoltare mai agile [6].
În acest context arhitectura sistemelor informatice bancare cuprinde următoarele subsisteme:
Operații curente care se referă la următoarele module:
Conturi curente se realizează tranzacțiile de încasări și plăti princontul curent al clientului;
Depozite se realizează gestiunea depozitelor deschise de clienți,implicând operații de calculare a dobânzii, plata dobânzii la scadență, capitalizarea acesteia, generarea de extrase de cont, calcularea și reținerea comisioanelor și a impozitului pe venit;
Casa-se realizează gestiunea operațiilor cu numerar; acest modul esteintegrat cu celelalte module care generează încasări/plăți în numerar:cont curent, depozite, alte operațiuni;
Home banking -informarea clientului cu privire la contul său sauinformatii generale legate de cursul valutar, rata dobânzii etc;
Decontări electronice, efectuarea de plăți electronice, în special pentru persoanele juridice;
Carduri, gestiunea tranzacțiilor efectuate prin conturile de card; acest modul interacționează cu cel referitor la conturile curente, pentru a putea realiza alimentarea periodică a cardurilor.
Clienți este un subsistem care permite actualizarea permanentă a datelor privind clienții băncii. Permite gestiunea unică a clienților, indiferent câte produse/servicii bancare utilizează și o administrare a acestora la nivel de bancă. Acest sistem este integrat cu celelalte subsisteme, în special cu operațiuni , gestionând produse și servicii bancare personalizate: cont curent,depozite bancare, casă.
Credite este un subsistem dedicat gestiunii contractelor de credit, ce conține două aplicații informatice:
Gestiunea riscului, pentru realizarea analizei financiare a clientului, plasarea creditului într-o grupă de risc, pe baza unor criterii prestabilite,în vederea luării deciziei de creditare;
Gestinea creditelor, pentru evidența creditelor acordate, a încasărilor ratelor scadente și a dobânzilor, calcularea penalizărilor, evaluareafinanciara permanentă a clientului.
Marketing este un subsistem realizat pe baza tehnicilor multimedia aplicabile pe Internet și se utilizează pentru promovarea produselor și serviciilor bancare.
Management bancar este subsistemul specializat în determinarea și monitorizarea indicatorilor de rating bancar: lichidități, profitabilitate, grad de îndatorare; în cadrul lui se realizează și modulele de asistare a deciziei, analiza scenariilor, elemente specifice de gestiunea riscului.
Contabilitate este subsistemul care realizează funcțiile de bază ale contabilitatii: urmărirea conturilor analitice și sintetice, evidenta tranzacțiilor interne și externe ale băncii, verificarea concordantei dintre tranzacțiile bancare derulate și evidentă contabilă, constituirea situațiilor de sinteză și raportarecatre organele administrației publice (balanțe sintetice, contul de profit și pierdere, situația patrimoniului).
Personalul este subsistemul care asigură evidenta personalului băncii și calculul salariilor.
Modulele pe care le voi proiecta și implementa în cadrul aplicației corespunzătoare temei sunt : clienți și operațiunii curente.
Modulul Operații curente:
Conturi curente – Gestionează conturile în lei ale clienților și prezintă toate rulajele aferente acestora.
Modulul Clienți
Gestionează clienții băncii și reține datele referitoare la aceștia: nume, adresa, formă de proprietate, obiectul principal de activitate. Fiecare client este identificat printr-un cod unic, reprezentat de codul fiscal pentru clienții persoane juridice și codul numeric personal pentru persoanele fizice.
Arhitecturi informatice pentru aplicația bancară
SOA-Generalități
Termenul de SOA a fost inventat în 1996 de către Gartner, dar de-a lungul timpului publicațiile l-au redefinit. În ultimii ani, SOA a fost adesea folosit ca sinonim pentru tehnologiile de tip Serviciu Web, chiar dacă există diferențe mari între punerea în aplicare efectivă a unei SOA, cu o anumită tehnolt : clienți și operațiunii curente.
Modulul Operații curente:
Conturi curente – Gestionează conturile în lei ale clienților și prezintă toate rulajele aferente acestora.
Modulul Clienți
Gestionează clienții băncii și reține datele referitoare la aceștia: nume, adresa, formă de proprietate, obiectul principal de activitate. Fiecare client este identificat printr-un cod unic, reprezentat de codul fiscal pentru clienții persoane juridice și codul numeric personal pentru persoanele fizice.
Arhitecturi informatice pentru aplicația bancară
SOA-Generalități
Termenul de SOA a fost inventat în 1996 de către Gartner, dar de-a lungul timpului publicațiile l-au redefinit. În ultimii ani, SOA a fost adesea folosit ca sinonim pentru tehnologiile de tip Serviciu Web, chiar dacă există diferențe mari între punerea în aplicare efectivă a unei SOA, cu o anumită tehnologie (de exemplu, servicii de web)
și conceptele care stau la baza ce constituie paradigmă SOA.
Ca termen, "paradigmă" presupune că, SOA nu este o tehnologie, ci o abordare de a proiecta arhitectura unei aplicații.Prin folosirea conceptului de servicii orientate, este posibil să se modele procesele de business , independente de tehnologiile actuale .
Pentru a definii conceptul de SOA, vom face uz de următoarele principii :
Toate funcțiile (de exemplu, funcțiile de business) sunt definite că servicii;
Toate serviciile sunt independente și pot fi folosite fără a acorda atenție implementării;
Serviciile pot fi accesate printr-o interfață fără nici o cunoaștere a locații sale.
Din punct de vedere al business-ului strategic, SOA este construit în jurul ideii că serviciile se mapează pe funcțiile lui [7] .
Din punct de vedere informatic, termenul de arhitectură se poate referi la niveluri mai scăzute de abstractizare, cum ar fi arhitectura unui calculator sau a unui un grup de calculatoare .Dar SOA, în general, se referă la arhitectura organizațională ICT, adică unificarea unei forme coerente, folosită pentru a organiza și proiecta construcțiile, selectarea și interconectarea hardware-ului și software-ului și pentru crearea unei comunicări între bunurile unei organizații.În acest fel, SOA este un stil arhitectural, utilizat pentru construirea de sisteme distribuite combinate, care oferă la cerere, aplicații funcționale de tip servicii care urmează să fie folosite de către utilizatorul final. [8]
Unul dintre avantajele primare oferite de SOA este rolul său, anume integrarea aplicațiilor. Enterprise Application Integration (EAI) este un termen informatic folosit în business, pentru planuri, metode și instrumente care vizează modernizarea, consolidarea și coordonarea tuturor funcționalităților întreprinderii [9] .
Conceptele SOA reprezintă o schimbare în stiluri arhitecturale de la abordările de dezvoltare, având în centru compania, care necesită tehnologii specifice, la o paradigmă de dezvoltare concentrată pe interoperabilitate și standarde deschise.
În scopul de a proiecta servicii sau procese într-o SOA, este necesar să se identifice
și să înțeleagă aspectele de afaceri ale unei organizații . Astfel, perspectiva IT a SOA este strâns legată de perspectiva activității sale, existând o relație puternică între partea de business și SOA. Aceasta din urmă îmbunătățește agilitatea și flexibilitatea companiilor, făcând posibilă oferirea de produse noi și servicii. Ca urmare, procesele de business ar putea să fie adaptate pentru a valorifica întregul potențial oferit de servicii orientate spre tehnologii .
Din punct de vedere tehnic ideile din spatele SOA sunt construite cu ajutorul SOC(Service Oriented Computing= programarea orientate pe servicii) , o paradigmă informatică, în care serviciile sunt elemente fundamentale pentru aplicații în curs de dezvoltare .În acesta paradigmă produsele ITC sunt alcătuite din referințe către componentele externe pentru îndeplinirea diferitelor tipuri de servicii. SOC poate fi folosit pentru a încadra o fațadă orientată pe servicii în jurul sistemelor cu arhitecturi închise moștenite, astfel convertindu-le pe acestea pentru a fii compatibile cu arhitecturile mai deschise.
Un framework SOA poate profita de aceste grupări, pentru a permite integrarea mai flexibilă de servicii financiare, care continua să utilizeze sistemele vechi, mai ales în setările distribuite. SOA promovează interfețe bine definite, publicate, precum și interfețe descoperite care oferă reutilizarea funcțională a aplicațiilor pentru sistemele distribuite, de exemplu, în cazul în care serviciile sunt invocate într-o rețea. În acest fel, SOA este mai mult decât o metodă tradițională de dezvoltare a sistemelor informatice, deoarece ea cuprinde modelarea proceselor de business și arhitectura întreprinderii.
Cu alte cuvinte, SOA descrie cadrul general de proiectare fizică a layer-elor(nivelurilor) unui sistem informatic, funcționalitate și rolurile unor astfel de servicii ,în timp ce SOC oferă fundamentul informatic pe care se bazează sistemul.
SOA este caracterizată de următoarele trăsături fundamentale:
se bazează pe serviciile care pot fi ușor integrate;
se bazează pe standarde;
este disponibil pe mai multe platforme;
oferă servicii de sine stătătoare ;
încorporează și presupune un contract care specifică funcționalitățile oferite și, în același timp, garanteze că acestea pot fi replicabile .[10]
Fig.1. Arhitectura orientate pe servicii
Astăzi, tehnologia cea mai frecvent asociată cu punerea în aplicare de SOA sunt servicii Web. Cu tehnologiile standardizate de servicii web, cum ar fi SOAP(Simple Access Object Protocol), WSDL (Web Service Description Language) sau UDDI (Universal Description Discovery and Integration ), este posibil să se aplice conceptul de servicii orientate.
SOA în sistemul bancar
Sectorul bancar este adesea recunoscut ca un lider de tehnologie , deoarece utilizează de mult timp noile tehnologii ale informației. În cele ce urmează, vom prezenta pe scurt efectele SOA asupra băncilor.
Cel mai frecvent menționate beneficii pentru punerea în aplicare a unei SOA includ
capacitatea de a construi arhitecturi agile pentru sisteme enterprise, care sunt capabile să susțină flexibilitatea afacerii. Adaptarea și aplicarea activă de servicii orientate spre tehnologii sunt fundamentul pentru transformarea unei model de business(afacere) (de exemplu, prin realizarea de noi strategii de externalizare) [11]. În plus, tehnologiile de servicii orientate sunt considerate a fi în măsură să rezolve provocările strategice cum ar fi integrarea unei aplicației, procese de reconfigurare a valorii , conservarea volorii după fuziuni și achiziții și permit forme mai agile de dezvoltare a sistemelor informatice [12].
De obicei, băncile beneficiază în special de punerea în aplicare a un SOA, datorită reutilizarea serviciilor în mai multe procese de afaceri și capacitatea de a oferi funcționalități existente, fără a expune sistemul logic de bază. Pe de altă parte, SOA implica dezavantaje de performanță și necesită mult timp de implementare , din cauza necesității de a dezvolta servicii suplimentare.
Sistemele informatice trebuie să fie cuplate pentru a permite comunicarea în cadrul companiilor și între o organizație și partenerii externi. SOA oferă o abordare
care reduce complexitatea și costurile acestor cerințe [13].
Înainte de SOA, pentru a avea acest nivel de flexibilitate, o instituție ar putea fi obligată să implementa și să integreze – 20 de aplicații diferite, cu SOA, o întreprindere trebuie să construiască doar unul singur ,aceasta poate reconfigura 20 moduri diferite de a îndeplini cerințele aflate în schimbare ale business-ului și ale pieței.Aceasta flexibilitate(rădăcina tuturor avantajelor SOA) o voi arăta în contexul anumitor servicii bancare( plată,deschiderea de cont și integrarea mai multor canale),prin analiza unei SOA create de către IBM.
a) Simplificarea plăților
Arhitectura unei operații de plată, în mod tradițional este costisitor de întreținut, deoarece există aplicații duplicate,ce se contecteaza punct la punct.Acestă metodă este folosită pentru integrarea diverselor sisteme din aplicație, iar pentru estimarea numărului de conexiuni necesare se folosește formula:
, unde n=nr de noduri
SOA poate oferi un layer pentru a reduce numărul de puncte de integrare și pentru a scădea costurile totale prin reutilizare de servicii comune.
În multe bănci, factori, cum ar fi activitatea de fuziune, cerințele de reglementare montare, globalizare și modalitățile de plată electronică au dus la realizarea de noi aplicații pentru a răspunde noilor cerințe și nu a le reconfigura pe cele existente.
În general, acest lucru a dus la :
duplicarea de interfețe și aplicații;
realizarea de soluții complexe punct-la-punct, care sunt dificil de întreținut și actualizat;
solutii mai puțin flexibile;
o lipsa de standarde pentru integrarea aplicațiilor;
creșterea costurilor cu întreținerea și îmbunătățirea;
transmiterea în timp util a informațiilor coerente.
Fig.2 Arhitectura unei operațiuni de plată
În partea stânga exista o mulțime de sisteme de tip CB (core banking= reprezintă serviciile prestate de către un grup de filiale ale băncilor din rețea. Consumatorii de servicii bancare pot accesa fondurile lor și alte tranzacții simple, de la oricare dintre filialele member) care pot iniția sau accepta o operație de plată, iar în dreapta sunt diferite sisteme de plată sau canale de plată. Implicația este că sistemele de tip CB precum și numărul de canale de plată, pot varia de la bancă la bancă, precum și în cadrul băncii.
Acest exemplu, aparent simplu la prima vedere, prezintă șase conexiuni interne care leagă patru sisteme externe -rezultand în 24 de conexiuni de rețea unice.
De fiecare dată când un nou sistem intern este adăugată, 4 noi conexiuni trebuie să fie create. În schimb, de fiecare dată când un nou sistem extern, se adăugă, aveți posibilitatea să creați șase conexiuni noi. Cele 24 de conexiuni trebuie să suporte și să mențină 8 tipuri de tranzacții comerciale, constând în aproximativ 160 de tipuri de mesaje. Avem 160 de tipuri de mesaje și peste 24 de conexiuni de rețea, plus complicațiile, cum ar fi costurile de întreținere sau modificări cerute de canalele de plată pentru a ține pasul cu modificariile tehnologiei.
Este necesar un sistem care poate reduce numărul de conexiuni dintre toți partenerii implicate în procesul de plată. Diferitele sisteme CB pot absorbi apoi noi moduri de a efectua plăti, fără a afecta fluxul de de afaceri.
În trecut, multe bănci au încercat să integreze aplicațiile de plată prin instalarea unui
hub (un punct de conexiune comună pentru dispozitive sau noduri într-o rețea sau sub-retea) sau gateway(sistem capabil să îmbine laolaltă două rețele care utilizează protocoale diferite) pentru a face față unui anumit canal bancar de plată. Acestă
soluție, în cele din urmă, a evoluat la gateway-uri care sprijineau multiple canale de plată, ce includeau transformări de date, formatarea mesajului și logare.Aceste soluții sunt acum învechite și inflexibile, adăugând și un layer suplimentar de conexiuni instabile.
SOA oferă o modalitate de a reutiliza serviciile efectuate pentru tranzacții de plată diferite. Aceste servicii pot fi independent de sistemul CB și canalele de plată, abordare este ilustrată în Figura 3.
Fig.3 Modelul SOA propus operației de plată
Layer-ul de servicii de plată poate sprijini, de asemenea, orice număr de canale de plată sau sisteme fără a provoca nici o schimbare sistemelor CB originare sau vizate de către serviciul de plată. Acest layer de servicii absoarbe modificările făcute în sistemele bancare sau sisteme externe de plăți.
Putem vedea avantajul numeric, în acest exemplu, SOA reduce numărul total de
conexiuni de rețea de la 24 la 10, totalul tranzacțiilor de afaceri de la 192 la 48 și,
uimitor, numărul total al tipurilor de mesaje de la 3840 la 44. SOA nu numai că scade
numărul de puncte de conexiune, dar permite reutilizarea de tipuri comune de mesaje. Acest lucru crește foarte mult probabilitatea ca serviciile create să fie utilizate de toate sistemele, în cadrul băncii.
În esență sa, această abordare stabilește cadrul pentru a reduce în mod semnificativ costurile cu interfețe mai puține, mai puține tranzacții de afaceri și gestionarea tipurilor de mesaje.În plus, crearea unor tipuri de mesaje comune poate duce la reducerea eforturilor și a costurilor de întreținere.
În momentul în care noile sisteme, cum ar fi plățile mobile, pot fi integrate în cele existente se poate vorbi de oportunități pentru noi surse de venit.Cu SOA, banca poate adăuga cu ușurință noi canale de plată și aplicații celor existente fără a afecta afacerea.
În termeni de reducere a riscurilor operaționale, SOA poate spori monitorizarea, deoarece mai multe aplicații utilizează o abordare comună pentru trimiterea și primirea plăților.
b)Integrarea canalelor de comunicație
În mod tradițional, aplicațiile bancare sunt deconectate în cadrul organizației, făcând dificilă posibilitatea de a optimiza potențialul clientului existent. SOA poate oferi un layer de integrare a aplicațiilor de tip enterprise , precum și un mod de gestionare al relației cu clienții.
Pentru a optimiza loialitatea clienților, rentabilitatea și creșterea economică, băncile vor trebui să profite de potențialul fiecărei relație cu clienții și să le ofere acestora cele mai atractive gamă de produse și servicii. Una dintre cele mai mari bariere aici este inexistenta posibilității de a integra informațiile despre clienți, de obicei se fragmentează de-a lungul canalelor.
În prezent, pentru a dezvolta produse, băncile trebuie să se bazeze foarte mult pe sistemele de colectare a datelor care integrează aplicațiile în cadrul băncii. Aceste interacțiuni, presupunând că există, sunt costisitoare, inflexibile și predispuse la erori. După cum sugerează figură de m ai jos, lipsa de interfețe disponibile împiedica banciile să aibă în acces în timp real la datele solicitate.
În multe cazuri, fiecare serviciu de bază se trimite către piața existența prin același set de canale,deși prin aceste canale s-ar putea transmite aceleași produse și servicii.De exemplu, dacă un client utilizează serviciile de card de credit ale unei băncii, el sau ea
trebuie să reînceapă relația cu banca ,în cazul în care aplica pentru un credit ipotecar, iar apoi din nou pentru servicii de administrare a averii.Banca nu poate valorifica în mod curent interesele clientului,deoarece nu poate accesa toate informațiile de care are nevoie.Rezultatul poate fi o experiență nesatisfăcătoare pentru client și un proces ce consum mult timp băncii.
Fig.4 Arhitectura canalelor de comunicație
Pentru a rezolva această problemă, aplicațiile de acest gen, de exemplu un sistem bancar utilizat de acasă de tipul web-based, au nevoie de un mod coerent de a accesa aplicațiile sistemului CB din zona de servicii.
Figură de mai jos prezintă un mod mai puțin greoi de integrare a aplicațiilor de acest gen și aplicații de suport servicii utilizând un set unic de servicii SOA.
Fig.5 Modelul SOA propus pentru integrarea canalelor de comunicație
Ca și în cazul plăților, există tehnologii care pot face acest lucru. SOA integrează un layer de servicii. De exemplu, pentru că o aplicație de tip retail se obțin informații despre relația băncii cu clienții, cererea trebuie să se conecteze la toate produsele
sistemului și va necesita un flux constant de informații în timp real de la sistemul de bază care pot fi actualizate și vizualizate în toate canalele de comunicație.
Așa cum arată figura 5, informațiile ar include:
Informații despre client;
Informații despre produse;
Tarife și comisioane;
Detalii despre bilanț.
Cu SOA, o bancă poate folosi diferite categorii de servicii – client, produs,
sold , istoric și poate crea un set standard de servicii pentru a face schimb de informații. Un singur serviciu de tipul “Preluarea soldului” ,ar putea fi aplicat la orice produs relevant.
Banca are acum o vedere de ansamblu a informațiilor clientului. Și pentru că layer-ul utilizat de SOA face mai ușoară integrarea aplicațiilor, banca oferă clienților săi produse și servicii adaptate.Deoarece informația este împărțită în timp real, controlul produsului primar rămâne cu cea mai potrivită aplictie care să-l gestioneze. De fiecare dată când un serviciu sau canal, se adăugă, acesta se poate conecta și accesă toate sistemele și canalele prin layer-ul SOA. Acest lucru ajuta la îmbunătățirea flexibilității, la reducerea costurilor de muncă, reducerea riscului.
c) Operația de deschidere cont
Deschiderea unui cont bancar este o funcție de bază, care a devenit o cheltuială majoră, și o barieră semnificativă pentru dezvoltarea mediului de afaceri. În timp ce încearcă să mențină sau chiar să îmbunătățească acest serviciu (acesta este primul contact al clientului cu banca), băncile trebuie să încerce, de asemenea, reducerea cheltuialelii
Procesul de deschidere a contului a fost paralizat de factori,cum ar fi :
constrangerile sistemului moștenit și dublarea eforturilor ;
întretinere de interfețe multiple între sisteme multiple de deschidere de cont și a aplicațiilor de-a lungul liniilor de produse și canale;
întreruperi frecvente și modificările care rezultă din fuziuni și achiziții de activitate.
Întregul proces a devenit greoi pentru bănci și clienți.Procesul de pre-vanzare suferă din cauza tarifelor mici de închidere a contului, vizualizării incomplete a clientului, a lipsei concentrației operatorilor bancari și a deficitului de materiale de colaborare pentru a ușura procesul.Abordarea și îndeplinirea acestor cerințe sunt grele, din cauza lipsei posibilității de semnătura digitală, lipsei de fonduri, costurilor administrative mari și ineficiente și urmăririi conturilor inactive.
În cele mai multe cazuri, nu există un sistem CB pentru fiecare produs pentru care un client ar deschide un cont, de asemenea, există un număr de canale diferite de multe ori susținute de mai multe aplicații. Este mai ușor de înțeles problema și soluția sa actuală prin vizualizarea proceselor de bază utilizate pentru deschidere de cont,prezentate în figură de mai jos.
Fig.6.Arhitectura unei operații de deschidere de cont
Există unele lucruri critice de reținut, în acest proces. În primul rând, timpul ciclului end-to-end este îngreunat de necesitatea de a accesa mai multe sisteme, unele considerații juridice și numărul părților implicate.
În al doilea rând, numeroase activități sunt predispuse la erori, cauzând întârzieri suplimentare. Acesta este un lucru destul de complicat pentru orice zonă de business sau linie de produse, dar pentru o bancă acest proces se dublează pentru fiecare dintre serviciile oferite. Cel mai probabil, acest proces este executat în mod diferit pentru fiecare produși și, de asemenea, variază în funcție de fiecare canal.
Este mai ușor de schimbat un proces atunci când sistemele sunt la primul punct de contact, în cazul în care deschiderea de cont este solicitată prima dată și atunci când banca poate accesa informațiile necesare și sistemele în timp real. Fie că este o aplicație CRM sau o nouă aplicație de deschidere de cont, orice cerere unică ce încerca să acopere această sarcină va necesita integrarea de sisteme extinse în cadrul infrastructurii băncii.
Aceasta aplicație, cont nou (figura 7) este posibilă numai dacă se pot accesa sistemele necesare, cum ar fi formulare electronice.
Fig 7.Reprezentarea generală a unui proces revizuit de deschidere de cont folosind o aplicație SOA
În mod ideal, aplicația, cont nou, ar folosi serviciile SOA pentru a crea de fapt,
un cont în sistemul de produse. Figura 8 arata cum se poate realizea aceasta integrare.
Fig.8 Construirea sau integrarea unei aplicați de tip cont nou utilizând SOA.
Banca va construi un layer de servicii și va folosi serviciile pentru funcționalitățile contului în sistemul CB, un singur set de servicii ar fi construit. Un serviciu de regăsire de cont poate avea o funcție diferită în fiecare aplicație a CB-ului. Cu toate acestea, ar exista un singur serviciu SOA pentru gestionarea fiecărui cont. De exemplu, serviciul de on-line banking ar putea folosi serviciile SOA în mod direct. Acest tip de implementare stabilește bază pentru reutilizarea viitoare și mai important, flexibilitate IT.Veniturile obținute pe baza utilizării acestui tip de serviciu justifica costurile de construire a acestei aplicații cu infrastructura reutilizabilă.
Ontologia Domenială
Noțiunea de ontologie
Ontologia este definită drept “teoria particulară despre natura existenței” [15]. O definiție larg acceptată pentru noțiunea de ontologie ne oferă pentru prima dată de către T. Gruber și anume: „o specificare explicită a unei conceptualizări” [16]. Tot el definește termenul de conceptualizare, care se referă la obiecte, concepte și alte entități, care se presupune că există într-un anumit domeniu de interes, precum și relațiile care le ține împreună pe toate acestea. Se observă că aceasta definiție utilizează descrierea tradițională a schemei conceptuale a bazei de date, dar diferă cel puțin prin trei elemente esențiale: obiectiv, sfera de cuprindere și conținut.
De asemenea nu trebuie neglijat faptul că ontologia este un model al realității și de aceea conceptele din ontologie trebuie să reflecte aceasta. Astfel după construirea unei prime versiuni aceasta poate fi ușor testată și evaluată cu ajutorul aplicațiilor sau cu ajutorul unor experți în domeniu. Obiectivul unei ontologii constă în reprezentarea unei conceptualizări, partajabile și reutilizabile, în care sunt ignorate detaliile specifice aplicațiilor. Sfera de cuprindere a unei ontologii se referă la toate aplicațiile domeniului, nu numai la o anumită aplicație.
Cercetătorii au ajuns la concluzia că ontologiile sunt capabile să îmbunătățească comunicarea, partajarea și reutilizarea componentelor unui produs software [17]. De exemplu, întrebarea privind semnificația termenilor de cont, proces de afaceri și piața poate avea mai multe răspunsuri în funcție de departamentul de unde provine intervievatul. Ontologiile urmăresc explicarea cât mai corectă a semnificației conceptelor astfel încât comunicarea să fie cât mai bună. Interoperabilitatea, comunicarea dintre sistemele de calcul separate, a căpătat o atenție adecvată odată cu evoluția mediilor informatice eterogene și abordărilor diferite aflate în atenția dezvoltatorilor.
O primă abordare se referă la translatarea cunoașterii într-un format comun, de exemplu KIF-Knowledge Interchange Format [18], foarte important pentru intermedierea formatului utilizat la partajarea și reutilizarea cunoașterii. Cea de a doua abordare se referă la folosirea limbajului ACL (Agent Communication Language), mult mai bine fragmentat într-o ontologie. Agenții utilizează termeni care constituie parte a ontologiei folosită pentru comunicarea cu o implementare relevanta a sistemului.
Există, în funcție de evoluția complexității proiectelor de informatizare și a obiectivelor acestora, trei categorii de utilizări:
Dicționarele de cunoștințe înregistrează semnificația conceptelor dintr-un anumit domeniu, relațiile dintre concepte și constrângerile care trebuie aplicate conceptelor.
Suportul pentru proiectarea conceptuală servește la ghidarea construirii unor noi modele de aplicații pentru un anumit domeniu, de exemplu contabilitate. Proiectarea conceptuală este mult mai eficientă datorită existenței dicționarului de cunoștințe, un exemplu excelent de utilizare operațională a ontologiei că suport pentru automatizarea proiectării conceptuale.
În ontologiile operaționale, conceptele, relațiile dintre concepte și constrângerile sunt înregistrate explicit, devenind parte a aplicațiilor proiectate. Acest aspect are în vedere înregistrarea explicită a ontologiei sub formă de specificații ale cunoașterii, lucru care favorizează utilizarea mecanismelor inferențiale în sisteme informaționale dotate și cu module de sisteme inteligente.
Ontologia unei aplicatii bancare
Pentru crearea ontologiei am utilizat programul Protege, creând o ontologie de tip OWL(Web Ontology Language). În ce privește o aplicație bancară, trebuiesc astfel, bine stabilite conceptele (precum și relațiile dintrea acestea) cu care vom lucra pentru realizarea modelelor (conceptuale și efective).
Specificații
Determinarea domeniului ontologiei
Domeniul:Financiar
Aplicația:Aplicație Bancară
Scopul:definirea unor concepte(clase, proprietăți,restricții,relații) care să ilustreze un model al realității,fiind necesare pentru implementarea aplicației.
Refolosirea unei ontologii existente
Există mai multe ontologii financiare definite, cum ar fi: Interactive Financial Exchange (IFX) – care este un protocol de mesagerie financiară bazat pe XML, construit de către lideri din industrie și tehnologia financiară, conceput pentru interoperabilitatea sistemelor care doresc să facă schimb de informații financiare pe plan intern și extern), o ontologie financiară dezvoltat de Teknowledge și scrisă în KIF(Knowledge Interchange Format=este un limbaj orientat pe schimbul de cunoștințe între programele informatice dispersate),aceasta extinde ontologia SUMO(Suggested Upper Merged Ontology=este o ontologie de nivel superior concepută că o ontologie fundament pentru o varietate de sisteme de prelucrare a informațiilor de calculator) și oferă o serie de termeni de nivel superior în domeniul financiar.
În urma studierii acestora, am decis să nu le reutilizez, deoarece descriu un cadru general, ci să creez o nouă ontologie care să îmi fie folositoare pentru proiectarea și implementarea aplicației.
Găsirea termenilor importanți din ontologie
Modulele pe care le voi proiecta și implementa în cadrul aplicației corespunzătoare temei sunt :clienți și operațiunii curente.
Modulul Operații curente:
Conturi curente – Gestionează conturile în lei si rulajele aferente acestora.
Tranzacții – operează ordinele de plată ale clienților precum și încasările acestora și actualizează on-line soldurile. Sunt permise plățile în limita soldului creditor existent.
Modulul Clienți
Gestionează clienții băncii și reține datele referitoare la aceștia: nume, adresa, formă de proprietate, obiectul principal de activitate. Sunt stocate și informații referitoare la acționariat, management, relații de interdependentă comercială. Fiecare client este identificat printr-un cod unic reprezentat de codul fiscal pentru clienții persoane juridice și codul numeric personal pentru persoanele fizice.
Conceptualizare:
Identificarea Claselor și a Atributelor
Conceptele(clasele) folosite în aplicație sunt următoarele:
– Interfata Banca – definește operațiunile comune pe care o bancă le-ar efectua.
– Interfata TipTranzactie – definește tipul de tranzacție bancară pe care bancă o permite.
– Clasa ModelBanca – este o implementare a interfeței Bancă și are următoarele atribute:
Lista ClientiConturi – reprezintă clienții ce au deschis conturi la bancă;
– Clasa Cont – este reprezentarea unui cont bancar,ce reține toate tranzacțiile de logare și de interogare aferente,prezintă următoarele atribute:
Cont_Id – reprezinta codul asociat contului pentru al deosebi de altele;
Balanta – reprezinta soldul contului;
ListaTranzactii – multitudinea de tranzacții asociate contului;
– Clasa Client – este reprezentarea unui client al băncii,contul unui titular, iar un client poate avea mai multe conturi,ce prezintă următoarele atribute:
ClientTip – este folosit pentru a determina dacă clientul este persoana fizică sau juridică;
Codul Numeric Personal sau Codul Unic de Inregistrare – reprezintă codul unic pe care îl are fiecare client, fie că este persoana fizică(CNP) său persoana juridică(CUI);
Nume – este numele clientului;
Prenume – reprezinta prenumele clientului;
Denumire – se folosește în cazul în care este persoana juridică;
ListaConturi – un client poate avea un cont sau mai multe conturi;
– Clasa Tranzactie – este o clasă abstractă de tip supertype a tuturor tranzacțiilor.O tranzacție este o singură operație, ce poate fi efectuată pe un cont, fiind de două tipuri:Debit sau Credit, având următoarele atribute:
Tranzacție_Id – reprezintă codul asociat contului pentru al deosebi de altele;
Suma – este suma asociată fiecărei tranzacții;
TimpTranzactie-timpul în care se realizează o tranzacție;
– Clasa Debit – este una dintre clasele concrete de tip subtype ale clasei Tranzacții, aceasta rezultă din operația de debitare a unui cont cu suma indicată.
– Clasa Credit – este cealalalt subtip concret al clasei Tranzacții, aceasta rezultă din operația de creditare a unui cont cu suma indicată.
– Clasa ClientBanca – crează instanțe ale claselor BancaModel,Client,Cont și efectuează unele tranzacții pe conturi.
– Clasa Exceptii – sunt implementate excepțiile ce pot apărea în aplicație.
– Clasa ClientExistentExceptie – este o subclasă a clasei Excepții, ce se folosește în cazul în care un potențial client este deja client al băncii, are următorul atribut:
Codul NUmeric Personal sau Codul Unic de Înregistrare;
– Clasa ContExistentExceptie – este de asemenea o subclasă a clasei Excepții, folosită în momentul în care se dorește să se creeze un cont deja existent în baza de date a băncii, ce prezintă atributul:
Cont_Id
– Clasa InvalidClientExceptie – subclasa a clasei Excepții,ce se instanteaza în momentul în care datele instroduse de către un client nu sunt bune, cu atributul:
Codul NUmeric Personal sau Codul Unic de Înregistrare;
– Clasa InvalidContExceptie – subclasa a clasei Excepții,folosită atunci când operațiunea de creare a unui cont este invalidă, cu atributul:
Cont_Id
– Clasa InvalidSumaExceptie – reprezinta o subclasă a clasei Excepții, ce se instantiaza atunci când suma utilizată în orice tranzacție nu este corespunzătoare, are atributul:
Suma-suma cu care se realizează o tranzacție;
– Clasa InvalidTranzactieExceptie – este de asemenea o subclasă a clasei Excepții, folosită în cazul în care o tranzacție eșuează, cu următoarele atribute:
Cont-contul asociat tranzacției;
Suma-suma asociată unei tranzacții;
Tipul Tranzactiei-o tranzacție poate fi de debit sau de credit;
Fig 9.Clasificarea claselor modelului
Definirea Relațiilor
Odată ce ierarhiile și caracteristicile lor au fost identificate, trebuiesc stabilite(dacă există) relațiile dintre anumite clase:
– CreazaCont este o relație ce definește un cont pe care îl deschide un client;
– CreazaTranzactie este o relație ce prezintă tranzacția realizată de către un cont;
– CreazaClient reprezintă relația în care un client potențial devine clientul băncii;
– CreazaContBanca definește momentul în care un cont nou deschis devine contul băncii;
– TipTranzactieCredit, relația care definește dacă o tranzacție este de tip credit;
– TipTranzactieDebit, relația care definește dacă o tranzacție este de tip debit;
– ExistaNumarCont,prin care se verifică dacă contul respectiv este deja creat;
– ExistaClient,prin care se verifică dacă clientul se găsește în baza de date;
– TranzactieNepermisa,cu ajutorul acestei relații se stabilește dacă se poate realiza tranzacția.
Tabelul de mai jos reflectă relațiile bidirecționale ce pot fi elaborate prin intermediul atribuirii de nume folosind criterii uniforme(sau un criteriu uniform), prin identificarea surselor și destinațiilor relațiilor și a cardinalitatii:
Tabel 1"Relatiile dintre clase"
Figura de mai jos reflecta relatiile realizate in Proteje, ce se gasesc intre clase:
Fig 10.Relațiile între clasele aplicației
c) Instanțiere
Tabel2."Exemple de instanțe"
Figura 11 ilustrează instanțele de mai sus pe care le-am creat în programul Protégé:
Fig 11 .Exemple de Instanțe
Tehnologii de implementare SOA
Tehnologia J2EE
J2EE este o arhitectură pentru construirea implementărilor de tip server-side în limbajul de programare Java. Poate fi folosită pentru a construi site-uri web tradiționale, componente software, sau pachete de aplicații. J2EE a fost extinsă pentru a include suport pentru construirea de servicii web bazate pe XML ce pot interopera cu alte servicii web care pot sau nu au fost scrise cu standardul J2EE.
Fig12.Arhitectura J2EE
Pe scurt, figura de mai sus prezintă:
Aplicații J2EE sunt găzduite într-un container, care oferă o calitate serviciiilor aferente aplicațiilor enterprise, cum ar fi tranzacțiile, securitatea și serviciile de persistență.
Nivelul de business prelucrează datele logice și stabilește logica. În aplicațiile J2EE, logica de afaceri este construită folosind componentele EJB (Enterprise JavaBeans). Acest nivel se conectează la bazele de date folosind JDBC (Java Database Connectivity) sau SQL/J sau sisteme existente care folosesc ACJ (Connector Architecture Java). Interoperabilitatea la acest nivel se realizează prin API-urile Java pentru XML (JAX API).
Parteneri se pot conecta la aplicațiile J2EE prin intermediul tehnologiilor de servicii web (SOAP, UDDI, WSDL, ebXML). Un servlet, care este o cerere/răspuns orientat obiect Java, poate accepta cereri de servicii web de la partenerii de afaceri, folosind API-urile JAX pentru a efectua operațiuni de servicii web.
Clienții “thick”, cum ar fi applet-uri sau aplicațiile se pot conecta direct la nivelul de business prin intermediul IIOP (Internet Inter-ORB Protocol Internet) și nu prin intermediul serviciilor web, deoarece, în general, sunt scrise de aceeași organizație care este autoarea aplicației J2EE, prin urmare, nu este nevoie de folosirea unui serviciu web bazat pe XML.
Browsere-le web și dispozitivele wireless se conectează la JSP-uri (JavaServer Pages) care redau interfețele cu utilizatorul în HTML, XHTML, WML.
J2EE VS .NET
Orientare
J2EE este centrat pe Java și este o platformă neutră, în timp ce.NET este centrat pe Windows, fiind un limbaj neutru.
Strategii
J2EE este de fapt o serie de standard, pe cand.NET este o strategia de produs Microsoft bazat pe evoluția mediului de dezvoltare Visual Studio.
Implicarea industriei
Sun a adunat întreaga industrie din spatele standardului J2EE, în special furnizorii de top de software, care au adaptat interfața J2EE, cum ar fi BEA, IBM, Oracle. Pe de altă parte,.NET se bazează pe eforturile Microsoft de a pune stapanire pe cota de piata a servicilor web.
Integrarea și Compatibilitatea
In aplicatiile J2EE integrarea mostenirilor se realizeaza usor, prin utilizarea de adaptoare JCA (Java Connector Architecture).Pe cand in.NET integrarea se face prin Host Integration Server 2000, dar cu conectivitate limitată pentru sistemele selectate.
Dezvoltare rapida de aplicații
Atât NET și J2EE oferă implementare rapida a caracteristicilor unei aplicatii. J2EE oferă servicii de management de stare pentru a ajuta dezvoltatorii sa scrie cod și sa gestioneze starile. Pe de altă parte, avantajul real din spatele ASP.NET este că acesta este independent de dispozitivul client și permite interfețelor cu utilizatorul sa fie transmise catre altele alternative fără rescrierea codului. În afară de aceasta, in.NET componentele se afla intr-o coada de asteptare, exista conceptul de e-commerce si are loc o gestionare a proceselor de afaceri, capacități care în multe cazuri sunt superioare caracteristicilor comparabile găsite in J2EE.
Furnizori
J2EE oferă de la mai mulți furnizori soluții cu o mare varietate de instrumente, produse și aplicații. Acest lucru oferă funcționalitate suplimentară și variata, dar la un cost: instrumentele J2EE, de multe ori nu sunt interoperabile din cauza unor probleme de portabilitate. Motivul este că ele nu sunt de la un singur furnizor și nu sunt bine testate.Pe de altă parte, NET oferă o soluție completă de instrumente și servicii de la Microsoft, dar lipsesc anumite caracterisici găsite în soluțiile J2EE.
Limbaj de programare
J2EE se bazeaza pe limbajul de programare Java. Toate componentele cum ar fi EJB și servlet-uri care sunt implementate în cadru J2EE sunt, de asemenea, scrise în Java. JVM byte code este un limbaj neutru, dar, în practică, acest cod octet poate fi utilizat numai cu Java.
Pe de altă parte, framework-ul.NET, bazat pe CLR (common language runtime), permite dezvoltarea în orice limbaj, care este susținut de instrumente Microsoft, avantajul fiind ca o component din.NET poate fi scrisa în mai multe limbaje. Dezavantajul ar fi ca, în primul rând ai nevoie de experți în diferite limbaje de programare, pentru a dezvolta pe deplin, pentru a depana aplicație scrisa în mai multe limbaje.In al doilea rând, este nevoie de un cost semnificativ în formarea și menținerea dezvoltatorii de cunostinte.
În cazul J2EE, aspectul de standardizare pe un singur limbaj ajută la evitarea problemelor discutate mai sus. În concluzie, întreprinderile trebuie să evalueze cu atenție diferite aspecte ale deciziilor lor în alegerea unei platforme de servicii web.
Portabilitate
In cazul J2EE, JRE (Java Runtime Environment) este disponibil pe orice platformă (Win 32, Unix). In cazul.NET, CLR(Common Language Runtime) permite rularea aplicatiilor.NET pe Windows si pe unele tipuri de Unix, Linux, Solaris, Mac OS X .
Suport Servicii Web
J2EE permite colaborarea e-Business-ului și serviciilor web prin intermediul JAXP (Java API pentru XML Parsing). API-urile conveniente sunt, de asemenea, în curs de îmbunătățire pentru a ajuta dezvoltatorii să efectueze servicii web. Totodată, diverse instrumente terțiare compatibile J2EE sunt disponibile pentru a facilita implementarea rapidă a serviciilor Web.
.NET creează servicii web cu ajutorul tehnolpogiei Windows Communication Foundation, BizTalk,Microsoft Azure.
Instrumente
IDE -uri actuale de dezvoltare pentru Java includ Visual Cafe-ul WebGain, VisualAge de la IBM pentru Java, Jbuilder-ul de la Borland, etc. De asemenea, o varietate de instrumente și codul sursă al produselor sunt accesibile. Deși funcționalitatea setului de instrumente oferite de comunitatea J2EE depășește pe cele prevăzute de Microsoft, aceste instrumente nu sunt pe deplin interoperabile, deoarece nu provin de la un singur furnizor.
Pe de altă parte, Visual Studio NET de la Microsoft are caracteristici remarcabile de productivitate care includ forme Web, setul de componente GUI NET, și mult mai mult. Aspectul de integrare cu un singur furnizor și alte funcții ușor de utilizat sunt extrem de avantajoase pentru construirea de servicii Web.
Conținutul partajat
Viziunea de conținut partajat sugerează faptul că utilizatorii nu au nevoie să-și tasteze numele de utilizator și parolele de fiecare dată când utilizează serviciile Web. Atât J2EE cât și .NET susțin conținutul partajat cu argumentele pro și contra de rigoare. Susținătorii J2EE vizualizează o piață de depozite de conținuturi comune pe Web pentru a asigura specializarea în diferite domenii ale industriei pentru o mai bună satisfacere a diferitelor nevoi ale clienților, cum ar fi clienții de bănci și finanțe, informații despre istoricul medical, etc. Această abordare, în funcție de jucătorii de pe piață este adaptabila și mai sigură în ceea ce privește getionarea nevoilor maselor.
.NET, pe de altă parte, prezintă o singură abordare a depozitului conținutului partajat, bazată pe serviciile sale Hailstorm. Acest cadru oferă o experiență de serviciu Web centrată pe utilizator și un loc pentru a găsi informații de identitate. Industria este sceptica însă în privința acestei abordări în contextul menținerii securității și dominației unei singure entități asupra datelor de identitate ale individului și mediului de afaceri.
Costurile hardware
Atât .NET cât și J2EE sprijină platforma Win32, o alternativă mai puțin costisitoare la sistemele Unix și Mainframe. În general, soluția Microsoft are un preț agresiv comparativ cu J2EE, care oferă diferite niveluri de prețuri și de servicii high-end cât si soluții ieftine, low-end.
Performanța și abilitățile dezvoltatorului
J2EE este o platformă ideală pentru dezvoltatorii instruiți și informați să îmbunătățească controlul serviciilor de programare asupra serviciilor de nivel inferior, cum ar fi managementul de stat și caching. În comparație, arhitecturii .NET îi lipsesc servicii de îmbunătățire a performanței de nivel inferior, blochează introducerea erorilor în sistem și este, prin urmare, mult mai potrivit pentru dezvoltatorii care au nevoie de mai mult hand-holding.
In urma comparării celor două platforme, am ales să implementez aplicația cu ajutorul framework-ului .NET, anume tehnologia Windows Communication Foundation și cu ajutorul mediului de dezvoltare Microsoft Visual Studio. Am ales aceast framework, deoarece:
oferă instrumente care pot fi folosite și în alte programe;
oferă acces ușor la baze de date;
este compus dintr-un set unificat de biblioteci de clase;
cu ajutorul controalelor, se pot proiecta și dezvolta rapid și interactive elementele interfeței grafice;
oferă clase care efectuează majoritatea sarcinilor uzuale cu care se confrunta programele, reducând astfel timpul necesar dezvoltării aplicațiilor.
Windows Communication Foundation
Ce este WCF?
WCF este acronimul pentru Windows Communication Foundation, fiind o tehnologie Microsoft ce permite aplicațiilor să comunice între ele într-un mediu distribuit, fiind un model de programare unificat pentru construirea de aplicații orientate pe servicii, permițând dezvoltatorilor să construiască soluții sigure , fiabile , tranzacționate ce se integrează pe diferite platforme.
WCF este o platformă dezvoltată pentru implementarea serviciilor web ce folosește ultimul framework de la Microsoft .NET 3.5, implementând standardele ce stau la baza serviciilor web și asigurând interoperabilitatea între diferite platforme.
Acesta unifică o gamă largă de capabilități a sistemelor distribuite într-o arhitectură asamblabilă, care suportă transporturi multiple , modele de mesaje, codificări , topologii de rețea și modele de găzduire (hosting). Scopul WCF-ului este de a oferi un model unic de programare, care poate fi folosit pentru a crea servicii pe platformă .NET, pentru organizații .
WCF este folosit ca o umbrelă ce înglobează servicii web de tip ASMX(Active Server Methods), .NET remoting, WSE(Web Services Enhancements), Enterprise Service și System Messaging.Acesta a fost conceput oferind o abordare gestionabilă pentru calculul distribuit, pentru interoperabilitatea amplă, precum și sprijin direct pentru orientare pe servicii. WCF suportă mai multe stiluri de dezvoltare de aplicații prin furnizarea unei arhitecturi stratificate.
Fig 13.Componente Windows Communication Foundation
La baza arhitecturii WCF, canalele oferă mesaje asincrone, peste care se afla un layer de protocoale ce facilitează și securizează schimbul de date, precum și o gama largă de opțiuni de transport și de codare.
Arhitectura WCF si concept de baza
Diagrama de mai jos ilustrează principalele straturi de comunicare în cadrul arhitecturii Windows Communication Foundation (WCF):
Fig 14.Arhitectura WCF [19]
Nivelul de Contracts definește mai multe aspecte ale sistemului de mesaje.
Nivelul Service Runtime conține evenimentele, comportamentul ce are loc numai în timpul operației actuale a serviciului.
Nivelul Messaging este compus din canale (channels). Un canal este o componentă ce procesează un mesaj într-un mod anume
Adresa
Toate serviciile WCF sunt implementate la o anumită adresa și răspund cererilor atunci când adresa respectivă este accesata.
O adresă WCF este în mod normal specificata ca un URL, prima parte, fiind mecanismul de transport, iar celelalte părți din URL prezintă locația unică a serviciului. Diagrama de mai jos ilustrează cele trei părți ale adresei unui serviciu WCF:
Fig 15.Adresa unui serviciu WCF
Binding
Bindings(Legăturile) sunt utilizate pentru a specifica transportul, codarea, detaliile de protocol necesare pentru comunicarea dintre clienți și servicii și pentru a genera endpoint-uri.Prin urmare, părțile care comunică în cadrul sistemului trebuie să aibă o convenție cu privire la detalile legăturilor, iar cel mai simplu mod de a realiza acest lucru pentru clienții , ce folosesc un serviciu este să folosească aceleași detalii de bindings ale serviciului.
Contract
Un contract WCF este un set de specificații ce definește interfețele unui serviciu WCF, iar un serviciu web WCF comunica cu alte aplicații în funcție de contractele sale. Există mai multe tipuri de contracte WCF precum: Service Contract, Operation Contract, Dată Contract, Message Contract, and Fault Contract.
Fig 16.Componentele unui contract WCF
Service Contract – Reprezintă interfața serviciului WCF, practic, spune altora ceea ce serviciul poate să facă.
Operation Contract – Acesta definește metodele serviciului WCF, care sunt accesate de sistemele externe.Atributele aflate în cadrul acestui contract trebuie să fie aplicate pentru toate metodele.
Data Contract – Definește tipuri de date ale serviciului WCF.
Endpoint
Endpoint-urile sunt locuri în care mesajele sunt trimise sau primite (sau ambele) și definesc toate informațiile necesare pentru schimbul de mesaje. Un serviciu expune unul sau mai multe endpoint-uri ale aplicației.Informațiile sunt dezvăluite ca metadate pe care clienții le procesează pentru a genera clienți WCF adecvați și o stivă de comunicare.
Fig.17 Relatia Client-Service WCF
Serviciul WCF are un endpoint compus din:
Adresă – este o adresă de rețea în care se afla serviciul web.Ea descrie, într-un mod bazat pe standarde, unde trebuiesc trimise mesajele.Fiecare endpoint are în mod normal o adresă unică, dar, uneori, două sau mai multe endpoint-uri pot partaja aceeași adresă.
Binding – specifică modul de interoperabilitate al serviciului, incluzând lucruri precum protocoalele de transport (TCP, HTTP), codarea (text, binar) și cerințele de securitate (SSL, SOAP message security).
Contract – specifică ce comunica acesta și este o colecție de mesaje organizate în operațiuni care au la bază un schimb de mesaje comun, cum ar fi : one-way, duplex, or request/reply.
Fig.18 Componentele unui WCF endpoint
Hosting
Un serviciu WCF este o componentă care poate fi apelată de către alte aplicații, de aceea trebuie să fie găzduit într-un mediu, pentru a putea fii descoperit și folosit de către alții.
De ce WCF pentru SOA?
Să presupunem că o companie proiectează un serviciu pentru a obține informații de obținere de împrumut. Acest serviciu poate fi utilizat de către aplicația internă de call center, de către o aplicație web și de către o aplicație terță de tip Java J2EE, cum ar fi un sistem bancar. Pentru interacțiunile cu aplicația client- call center, performanța este importantă, pentru comunicarea cu aplicația Java, interoperabilitatea devine cel mai important obiectiv.Cerințele de securitate diferă între aplicația locală Windows și aplicația Java ce rulează pe un alt sistem de operare.
Cu aceste cerințe complexe, nu este ușor de construit serviciul dorit cu o singură tehnologie existentă. De exemplu, tehnologia ASMX are ca avantaj interoperabilitatea, dar performanțele sale nu sunt ideale, .NET remoting este o alegere bună din perspectiva de performanță, dar nu este suficient de bună pentru interoperabilitate, Enterprise Services ar putea fi utilizată pentru gestionarea duratei de viață a unui obiect și pentru definirea tranzacțiilor distribuite, dar aceasta accepta numai un set limitat de opțiuni de comunicare.
Cu WCF, este mult mai ușor să se pună în aplicare acest serviciu, deoarece abordează următoarele cerințe:
Interoperabilitate simplă cu alte platformă care suporta SOAP, cum ar fi servere de aplicații bazate pe J2EE pentru că WCF poate comunica folosind standardele serviciilor web;
Comunicare cu servicii web prin intermediul mesajelor, nu bazate pe SOAP , ci pe formate XML simple cum ar fi RSS, deoarece WCF poate fi configurat și se poate extinde;
Performanță este o preocupare majoră pentru majoritatea firmelor. WCF a fost dezvoltat de către Microsoft, cu scopul de a fi una dintre cea mai rapidă și distribuită platforma de aplicații;
Pentru a permite performanțe optime atunci când ambele părți dintr-o comunicare sunt construite cu ajutorul WCF, codificarea wire folosită în acest caz este o versiune de optimizare binară a unui set de informații XML. Această opțiune se aplică pentru comunicare cu aplicația client call center pentru că este, de asemenea, construit cu ajutorului tehnologiei WCF;
Gestionarea duratei de viață a unui obiect, definirea tranzacțiilor distribuite, și alte aspecte ale Enterprise Services sunt furnizate de către WCF. Acestea sunt disponibile pentru orice aplicație bazată pe WCF, ceea ce înseamnă că serviciul de împrumut le poate folosi împreună cu oricare dintre celelalte aplicații ce comunica cu acesta.;
Oferă fiabilitate, securitate și tranzacții, atunci când comunica cu orice platformă care acceptă specificațiile serviciilor web.
Nu utilizează un alt set de interfețe ale programelor, deoarece WCF prezintă o opțiune de punere a mesajelor într-o coadă de așteptare (Message Queuing).
Analiza sistemului
Cerințele funcționale
Scopul principal al acestei lucrări este de a proiecta și implementa o arhitectură orientate pe servicii a unei aplicații bancare. Interfața oferită de aplicație permite clienților să interogeze serviciile WCF puse la dispoziție de sistem. Principalele funcționalități oferite de aceste servicii sunt:
Crearea unui cont bancar online
Cu ajutorul acestui serviciu utilizatorul își poate crea un cont bancar online accesând clientul serviciului, reprezentat în situația de față de o aplicație web.După ce înregistrarea s-a încheiat cu succes, acesta poate folosii celelalte servicii oferite de sistem.
Realizarea de operațiuni bancare
O dată ce utilizatorul se loghează cu succes în sistem, acesta poate folosi următoarele operațiuni bancare: depunere, retragere și transfer.Serviciile de depunere și retragere primesc ca parametru de intrare numărul contului și suma care se dorește a fi tranzacționata, pe când serviciul de transfer primește ca parametru contul în care se dorește să se facă transferul și suma. Transferul se realizează între conturile care sunt deja înregistrare în baza de date.Moneda folosită pentru realizarea de operațiuni bancare este RON.
Afisarea tranzactilor realizate
Acest serviciu permite utilizatorului să vizualizeze istoricul tranzacțiilor pe care le-a făcut din momentul creări contului și până în prezent.
Folosind serviciile enumerate, aplicația implementează următoarele funcționalități :
Creare client;
Creare cont;
Login/Logout;
Depozit;
Retragere;
Transfer;
Vizualizare tranzacții;
Afisare client folosind numărul de cont;
Cerințele Non Funcționale ale sistemului
Cerințele nonfuncționale ale sistemului sunt la fel de importante pentru sistem ca cerințele funcționale.Sistemul este caracterizat de următoarele cerințe nonfuncționale:
Reutilizarea componentelor
În primul rând arhitectura proiectului trebuie să ofere posibilitatea de reutilizare conform celor mai bune practici de dezvoltare a sistemelor software.Astfel arhitectura sistemului se bazează pe servicii și pe nivele.
Utilizabilitate:
Această cerința nonfuncțională se referă la gradul de ușurință cu care un utilizator poate folosi sistemul. Utilizarea aplicației solicită utilizatorilor cunoștințe minime despre tehnologii, iar aceștia nu sunt intimidați de complexitatea platformei web.
Securitatea
Acest tip de cerințe nonfuncțională specifică nivelul și tipul mecanismelor de securitate ce trebuie satisfăcute în timpul operațiilor sistemului. Acestea includ respectarea standardelor de securitate și implementarea unor tehnici specifice. De asemena aplicația prezintă funcționalitatea de logare, ceea ce împiedică folosirea acesteia de către utilizatorii care nu sunt înregistrați.
Performanța
Această cerință nonfuncțională specifică eventualele limite inferioare și superioare de viteză, timp de răspuns și de stocare a datelor ale sistemului.
Arhitectura sistemului
O aplicație software bine proiectată este partiționată în părți logice separate, numite nivele sau straturi. Aceste nivele au o responsabilitate diferită, distinctă, specifică în arhitectura de ansamblu. Aceste straturi sunt abstracții pure și nu corespund cu o distribuție fizică. Straturile tipice într-un sistem software sunt după cum urmează:
Nivelul de Prezentare – În acest nivel se află părți care tratează interfața utilizatorului și interacțiunea cu utilizatorul.
Nivelul de servicii: cuprinde serviciile fondate și expuse, acestea pot fi descoperite sau legate static și apoi invocate.Furnizează un mecanism prin care se realizează servicii la rulare, folosind funcționalitatea data de interfață.
Nivelul Logic de Business – Acest nivel conține componente care tratează logica de programare a aplicației.
Nivelul de Date – Acest nivel este utilizat de către nivelul logic de business pentru a persista permanent starea. Constă în mod normal din una sau mai multe baze de date în care datele sunt stocate.
S-a utilizat o arhitectură pe 4 nivele și nu una pe trei nivele din mai multe motive, printre care scalabilitate crescută, putere de procesare a calculatorului mai mică pentru fiecare client, ceea ce duce la un cost mai scăzut.
Un aspect important al unei arhitecturi orientate pe servicii este acela că, în cadrul punerii în aplicare a unui serviciu, codul responsabil pentru manipularea datelor trebui să fie separat de codul responsabil pentru logică de business.Aceste patru nivele sunt prezente în următoarele componente ale sistemului proiectat:
Nivelul de prezentare sau clientul
Este reprezentat printr-o aplicație web. Aceasta foloște design pattern-ul Model-View-ViewModel ce are ca scop decuplarea perfectă a logicii de interfață. Astfel interfața este ca un skin care se mulează peste logica și este 100% schimbabilă, pentru că nu există referințe hard-coded către ea. Elementele indispensabile pentru implementarea design pattern-ului MVVM sunt databinding și comenzile.
Partea de Client este formată din celelalte două componente a MVVM-ului și anume View-ul și View-Model-ul, însă mai conține și DomainContext-ul ce este o reprezentarea dinamică în partea de client a domain service-ului, oferind acces la toate funcționalitățile serviciului.
View-ul este de obicei relizat într-o formă declarativă cum ar fi HTML sau XAML. Interfața cu utilizatorul este realizată folosind instrumente, limbaje diferite și de către persoane diferite decât este partea de business logic sau de date.View-ul constă din elemente vizuale, butoane, ferestre, grafică și controale mai complexe a interfeței grafice. Aceasta codifică comenzile rapide de tastatură și controalele se ocupă de managmentul interacțiunilor cu dispozitivele de intrare ce reprezintă responsabilitatea Controller-ului în MVC.
Nivelul de servicii – Este implementat cu ajutorul tehnologiei Windows Communication Foundation și conține toate serviciile ce pot fi accesate de către client.
Nivelul de logică de business- Implementează toate metodele serviciilor descrise în cadrul nivelului servicii
4.Nivelul de baza de date este format din baza de date a sistemului realizată în Sql Server 2008.
Fig 19.Arhitectura sistemului
Proiectarea și Implementarea
Cazuri de utilizare
Unul dintre aspectele importante în înțelegerea și definirea cerințelor unui sistem este acela al interacțiunii dintre sistem și utilizatori sau alte componente externe.
Aplicația bancară este alcătuită dintr-un singur modul, anume: sistem bancar online, prin urmare are doi utilizatori: Client Existent și Posibil Client.În figurile de mai jos se prezintă diagrama cazurilor de utilizare pentru cei doi actori ai aplicației.
Fig 20.Diagrama caz de utilizare pentru actorul ClientExistent
Fig 21. Diagrama caz de utilizare pentru actorul ClientPosibil
Interfata cu utilizatorul
Interfața cu utilizatorul a fost creată în Microsoft Visual Studio 2013, folosind limbajul de programare C#. În cadrul proiectului, utilizatorul poate accesa serviciile dezvoltate prin intermediul aplicației web, iar pentru că acest lucru să fie posibil trebuie adăugată o referință către layer-ul de servicii.Prin această referință se preiau metadatele serviciilor implementate.
Aplicația web debutează cu pagina de Logare, cu ajutorul acesteia utilizatorul se loghează în cadrul aplicației cu un Număr de Cont asignat și cu PAROLA corespunzătoare acestuia:
Fig 22.Pagina de Logare a aplicației
În cazul în care aceste nu posedă un cont în cadrul aplicației, utilizatorul poate accesa hiperlink-ul" Crează Cont Online", ce îl va direcționa către pagina de Creare Cont, în care se voi insera informații despre client:
Fig 22.Pagina de creare cont a aplicației
In cadrul acesteia sunt puse restricții pe anumite câmpuri, email, anume textul introdus trebuie să aibă formatul:[anonimizat]3
Fig 23.Restricții camp email
O altă restricție implementată este aceea de completare a tuturor câmpurilor, deoarece toate informațiile introduse trebuiesc inserate în baza de date:
Fig 24.Restricție câmpuri necesare
De asemenea o altă restricție creată este la nivelului câmpului parolă, anume datele introduse în căsuța confirmare parolă trebuie să fie identice cu cele introduse în casuța parolă:
Fig 25. Restricție câmp parolă
Ultima restricție implementată în cadrul acestui serviciu de creare cont este la nivelul câmpului depunere initial.Metoda folosită compară valoarea introdusă cu o variabilă definită ,maintaingbalance,a carei valoare este de 500 Ron.
Fig 26.Restricție câmp depozit inițial
Dacă toate aceste restricții au fost îndeplinite, informațiile introduse se inserează în tabelele din baza de date prin apăsarea butonului Creare.De asemenea pe ecran se va afișa numărul contului și un hiperlink către pagina Home a aplicației web:
Fig 27.Creare cu succes cont
Fig 28.Pagina Home a contului creat anterior
Meniul oferit de către această fereastră este:Depunere,Retragere,Transfer, Vizualizare Istoric Tranzacții și Log Off.
Depunere
Restricția creată pentru aceasta pagină este implementată la nivelul tipului de data introdusă:
Fig 29.Restricție tip dată
În cadrul acesteia utilizatorul poate depune bani în contul personal:
Fig 30.Operațiunea de depunere
După ce sumă a fost depusă cu succes în contul utilizatorului, valoarea soldului acestuia s-a modificat:
Fig 31.Modificare Valoare Sold
Retragere
O altă operațiune bancară pe care utilizatorul o poate realiza este aceea de retragere bani.Restricțiile implementate sunt la nivelul tipului de data introdus,ca și în operațiunea de depunere, și la nivelul valorii introduse:
Fig.32 Restricție operațiune retragere
Dacă restricțiile au fost îndeplinite, utilizatorul poate retrage bani din contul bancar:
Fig 33.Realizare operațiune retragere bani din cont
Transfer
Cu ajutorul acestei operațiuni bancare, utilizatorul poate transfera bani în unul dintre conturile deja înregistrate în baza de date:
Fig.34 Operațiunea transfer bancar
Istoric Tranzacții
Cu ajutorul acestei opțiuni, utilizatorul poate vizualiza toate tranzacțiile pe care le-a făcut în cadrul contului:
Fig 35.Vizualizare Istoric Tranzacții
Prezentare nivelului de servicii:
Acest nivel a fost creat cu ajutorul tehnologiei WCF, serviciul poarta numele de BankService.svc, iar această clasă moștenește interfața IBankservice cu toate metodele sale:
Fig 36.Diagrama de clase UML a serviciului
Pentru că servicul creat să poată comunica cu nivelul de logică de business, mai exact cu elementele implementate, se adaugă în cadrul clasei BankService referințe către celelalte clase dezvoltate.
De asemenea pentru ca serviciul să poată fi folosit de către o aplicație client trebuiesc configurate bindings-urile și adresele endpoint astfel:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IBankService" sendTimeout="00:05:00" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:62745/BankService.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IBankService" contract="IBankService"
name="BasicHttpBinding_IBankService" />
</client>
</system.serviceModel>
</configuration>
Pentru a vedea metodele implementate în cadrul serviciului și dacă un client le poate accesa, folosim opțiunea WCF Test Client.În cazul de față, în cadrul serviciului nostru se pot observa toate metodele:
Fig 37.WCT Test Client pentru serviciul BankService
Pentru a testa metodele, văzând cum comunică serviciul cu serverul, se introduc parametrii de intrare și se apasa butonul Invoke.Figură de mai jos prezintă schimbul de mesaje SOAP pentru Metoda Login:
Fig 38.Schimb de mesaje SOAP
Nivelul de logică de business
Înainte de a crea clasa corespunzătoare acestui nivel,am creat Proiectele:
BankEntities: în care se găsesc definițiile claselor Account,Customers și Transactions:
Fig 39.Diagrama de clase a proiectului BankEntities
BankDataAcces :în care se găsesc implementate procedurile stocate aferente tabelelor din baza de date;
BankCommon:în care am configurat accesul la baza de date.
Fig 40.Diagrama de clase UML pt proiectele BankDataAcces și BankCommon
Implementarea acestui nivel a început prin adăugarea de referințe către clasele create în proiectele prezentate mai sus.Acest lucru este necesar, deoarece în cadrul acestui nivel sunt implementate metodele folosite de serviciul BankService:
Fig 41.Diagrama de clase nivelului Business Logic
Prezentarea nivelului de date
Fiind un sistem condiționat, trebuie determinat conținutul bazei informaționale de intrare în funcție de modul de obținere a atributelor existente în baza informațională de ieșire. Scopul acesteia este acela de identificare și descriere a datelor care sunt folosite , iar rezultatele obținute reprezintă: metadate identificate, dicționarul de date, modelul conceptual – diagrama ER (entity relantionship) sau Enitiate-Asociere (EA).
Modelul folosit pentru proiectarea bazei informaționale este cel bazat pe diagrama Entitate-Asociere, care presupune gruparea atributelor de intrare într-un ansamblu de entități, inclusiv legăturile (corespondențele) dintre acestea.Baza de date aferentă acestui sistem este formată din trei entități:
Accounts- ce prezintă structura din figură de mai jos:
Fig 42. Structura tabelului Accounts
Cutomers-ce prezintă structura din figură de mai jos:
Fig 43. Structura tabelului Customers
Transactions- ce prezintă structura din figură de mai jos:
Fig 44. Structura tabelului Transactions
În cadrul acestui nivel, datele sunt înregistrare și preluate cu ajutorul procedurilor stocate:
_Accounts_Insert:Cu ajutorul acesteia se înserează un nou cont în baza de date;
_Accounts_Retrieve: Cu ajutorul acesteia se preiau informatile unui cont aflat în tabela Accounts;
_Accounts_Retrieve_All- Cu ajutorul acesteia se preiau informatile tuturor conturilor aflate în tabela Accounts;
_Accounts_Update- Cu ajutorul acestei proceduri se modifica soldul unui cont atunci când are loc o tranzacție;
_Customers_Delete- Cu ajutorul acesteia se șterge un client din baza de date
_Customers_Insert- Cu ajutorul acesteia se înserează un nou client în baza de date
_Customers_Login-Prin această procedură se verifica datele de logare aflate în tabela Customers;
_Customers_Retrieve-: Cu ajutorul acesteia se preiau informatile unui client aflat în tabela Customers;
_Customers_Retrieve_All- Cu ajutorul acesteia se preiau informatile tuturor clienților înregistrați în tabela Customers;
_Transactions_Insert-Prin această procedură se înserează o nouă tranzacție;
_Transactions_Retrieve-Ajuta la preluarea tranzacțiilor aferente unui cont
Concluzii
Pe parcurs am studiat ce implică proiectarea unei aplicații bancare ce folosește o arhitectură orientată pe servicii, care sunt componentele acesteia și care sunt cele mai bune practici pentru implementarea lor.
Această lucrare are ca scop prezentarea și utilizarea SOA,pentru integrarea sistemelor bancare și de a arăta cum acesta arhitectura structurata pe patru niveluri poate să optimizeze un sistem informatic bancar.
Analizând conceptele acestei arhitecturi,am constatat că SOA oferă o abordare a plăților bancare, care este o soluție progresivă, cu costuri mai mici de exploatare decât alternativele de azi.
Un alt avantaj oferit de SOA layer-ul de servicii, ce permite o mai mare flexibilitate pentru schimbarea și distribuția mai multor produse, O soluție SOA poate, de asemenea, permite deschiderea unui cont pentru mai multe linii de produse. Beneficiile pot include, nu numai costuri mai mici, dar și creșterea veniturilor și dezvoltarea de relații optimizate cu clienților.
SOA este într-adevăr o implementare revoluționară ,deoarece prin exploatarea capacităților acestuia pe plan intern, cât și extern, instituțiile pot construi noi conexiuni și suporta noi niveluri de colaborare și inovare. Nu este pur și simplu nici o limită asupra numărului de conexiuni și configurații ,acest lucru aducând beneficii ce pot remodela nu doar o afacere sau o industrie, ci o întreagă economie, chiar și economia globală.
Repere Bibliografice
[1] A.M.Riad, Q.F.Hassan (2008),Service-Oriented Architecture – A New Alternative to Traditional Integration Methods in B2B Applications , JCIT, Volume 3, Number 1, March 31, 2008. ISSN:1975-9320;
[2] Mazursky, A. D. (1989), Closed-Architecture Systems. The Journal of Information Systems Management;
[3] Seifert, F., and Wimmer, A. (2001), Towards networked banking: the impact of IT on the financial industry value chain, Proceedings of the European Conference on Information Systems (ECIS), Bled, Slovenia;
[4] Homann, U., Rill, M., Wimmer, A. (2004), Flexible value structures in banking, Communications of the ACM;
[5] Bruner, R. F. (1999), An analysis of value destruction and recovery in the alliance and proposed merger of Volvo and Renault. Journal of Financial Economics;
[6] Truex, D. P., Baskerville, R., and Klein H. K. (1999), Growing Systems in Emergent Organizations,Communications of the ACM;
[7] Datz, T. (2004), “Architecture – What You Need to Know About Service-Oriented architecture”, In: CIO Magazine – Framingham;
[8] http://www.xml.com/pub/a/ws/2003/09/30/soa.html;
[9] Lee, A. S., and Baskerville, R. L. (2003). Generalizing Generalizability In Information Systems Research. Information Systems Research;
[10] Meredith, L. G., and Bjorg, S. (2003), Contracts and types, Communications of the ACM;
[11] Krafzig, D., Banke, K., Slama, D.: Enterprise SOA: Service-Oriented Architecture Best Practices (The Coad Series). Upper Saddle River, NJ, USA, Prentice
Hall PTR (2004);
[12] Baskerville, R., Cavallari, M., Hjort-Madsen, K., Pries-Heje, J., Sorrentino, M.,
Virili, F.: Extensible Architectures: The Strategic Value of Service-Oriented Architecture in Banking. In: Proceedings of the Thirteenth European Conference on Information Systems (ECIS 2005), Regensburg, Germany (2005);
[13] Homann, U., Rill, M., Wimmer, A.: Flexible Value Structures In Banking.Communications of the ACM;
[14] Jay DiMare ,Richard S. Ma (2006) “Service oriented architecture.Revolutionizing today's banking systems. http://www-05.ibm.com/de/financialservices/pdf/ibv_soa_banking.pdf;
[15] Woolf, H.B., (Ed.), 1981, Webster’s New Collegiate Dictionary, Springfield, Mass;
[16] Gruber, T., (1993), A transnational approach to portable ontologies. "Knowledge Acquisition";
[17] Ushold, M., Gruninger, M., (1996), Ontologies: Principles, Methods and Applications, The Knowledge Engineering Review;
[18] Fikes, R., Cutkosky, M., Gruber, T.R., Baalen, J.V., (1991), Knowledge Sharing Technology Project Overview, Knowledge Systems Laboratory, Stanford University;
[19]Microsoft: Windows Communication Foundation Architecture, http://msdn.microsoft.com/en-us/library/ms733128(v=vs.110).aspx ;
[20] Noy N., McGuinness D., (2001) Ontology Development 101: A Guide to Creating Your First Ontology ;
[21] Mike Uschold, Michael Gruninger,(1996), Ontologies: Principles, Methods and Applications, The University of Edinburgh;
[22] Falbo, R.A. (2004). Experiences in Using a Method for Building Domain Ontologies. Proceedings of the Sixteenth International Conference on Software Engineering and Knowledge Engineering, SEKE'2004;
[23] Guarino, N., (ed.), (1998), Formal Ontology in Information Systems, Amsterdam, IOSPress;
[24] Introduction to Ontologies with Protege, https://wiki.csc.calpoly.edu/OntologyTutorial/wiki/IntroductionToOntologiesWithProtege;
[25] Matthew Horridge,(2011), A Practical Guide To Building OWL Ontologies Using Protege 4 and CO-ODE Tools,Edition 1.3, The University Of Manchester.
[26]Thomas Erl,David Chou, SOA with .NET and Windows Azure: Realizing Service-Orientation with the Microsoft Platform, Prentice Hall, 2010.
[27] Agarwal, V., Chafle, G., Dasgupta, K., Karnik, N., Kumar, A., Mittal, S., and Srivastava, B.: Synthy: A system for end to end composition of web services. J. Web Semantics,Vol.3, Issue 4, 2005.
Repere Bibliografice
[1] A.M.Riad, Q.F.Hassan (2008),Service-Oriented Architecture – A New Alternative to Traditional Integration Methods in B2B Applications , JCIT, Volume 3, Number 1, March 31, 2008. ISSN:1975-9320;
[2] Mazursky, A. D. (1989), Closed-Architecture Systems. The Journal of Information Systems Management;
[3] Seifert, F., and Wimmer, A. (2001), Towards networked banking: the impact of IT on the financial industry value chain, Proceedings of the European Conference on Information Systems (ECIS), Bled, Slovenia;
[4] Homann, U., Rill, M., Wimmer, A. (2004), Flexible value structures in banking, Communications of the ACM;
[5] Bruner, R. F. (1999), An analysis of value destruction and recovery in the alliance and proposed merger of Volvo and Renault. Journal of Financial Economics;
[6] Truex, D. P., Baskerville, R., and Klein H. K. (1999), Growing Systems in Emergent Organizations,Communications of the ACM;
[7] Datz, T. (2004), “Architecture – What You Need to Know About Service-Oriented architecture”, In: CIO Magazine – Framingham;
[8] http://www.xml.com/pub/a/ws/2003/09/30/soa.html;
[9] Lee, A. S., and Baskerville, R. L. (2003). Generalizing Generalizability In Information Systems Research. Information Systems Research;
[10] Meredith, L. G., and Bjorg, S. (2003), Contracts and types, Communications of the ACM;
[11] Krafzig, D., Banke, K., Slama, D.: Enterprise SOA: Service-Oriented Architecture Best Practices (The Coad Series). Upper Saddle River, NJ, USA, Prentice
Hall PTR (2004);
[12] Baskerville, R., Cavallari, M., Hjort-Madsen, K., Pries-Heje, J., Sorrentino, M.,
Virili, F.: Extensible Architectures: The Strategic Value of Service-Oriented Architecture in Banking. In: Proceedings of the Thirteenth European Conference on Information Systems (ECIS 2005), Regensburg, Germany (2005);
[13] Homann, U., Rill, M., Wimmer, A.: Flexible Value Structures In Banking.Communications of the ACM;
[14] Jay DiMare ,Richard S. Ma (2006) “Service oriented architecture.Revolutionizing today's banking systems. http://www-05.ibm.com/de/financialservices/pdf/ibv_soa_banking.pdf;
[15] Woolf, H.B., (Ed.), 1981, Webster’s New Collegiate Dictionary, Springfield, Mass;
[16] Gruber, T., (1993), A transnational approach to portable ontologies. "Knowledge Acquisition";
[17] Ushold, M., Gruninger, M., (1996), Ontologies: Principles, Methods and Applications, The Knowledge Engineering Review;
[18] Fikes, R., Cutkosky, M., Gruber, T.R., Baalen, J.V., (1991), Knowledge Sharing Technology Project Overview, Knowledge Systems Laboratory, Stanford University;
[19]Microsoft: Windows Communication Foundation Architecture, http://msdn.microsoft.com/en-us/library/ms733128(v=vs.110).aspx ;
[20] Noy N., McGuinness D., (2001) Ontology Development 101: A Guide to Creating Your First Ontology ;
[21] Mike Uschold, Michael Gruninger,(1996), Ontologies: Principles, Methods and Applications, The University of Edinburgh;
[22] Falbo, R.A. (2004). Experiences in Using a Method for Building Domain Ontologies. Proceedings of the Sixteenth International Conference on Software Engineering and Knowledge Engineering, SEKE'2004;
[23] Guarino, N., (ed.), (1998), Formal Ontology in Information Systems, Amsterdam, IOSPress;
[24] Introduction to Ontologies with Protege, https://wiki.csc.calpoly.edu/OntologyTutorial/wiki/IntroductionToOntologiesWithProtege;
[25] Matthew Horridge,(2011), A Practical Guide To Building OWL Ontologies Using Protege 4 and CO-ODE Tools,Edition 1.3, The University Of Manchester.
[26]Thomas Erl,David Chou, SOA with .NET and Windows Azure: Realizing Service-Orientation with the Microsoft Platform, Prentice Hall, 2010.
[27] Agarwal, V., Chafle, G., Dasgupta, K., Karnik, N., Kumar, A., Mittal, S., and Srivastava, B.: Synthy: A system for end to end composition of web services. J. Web Semantics,Vol.3, Issue 4, 2005.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Proiectarea Si Analiza Arhitecturii Informatice Pentru O Aplicatie de Tip Bancar (ID: 150201)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.