Banki informatika Pázmány Péter Katolikus ITK
Kada Zsolt
2016
Banki rendszerek architektúrája
2016
Mikor vezették be a bankszámlaszám fogalmát? a, 1812
b, 1955
c, 2004
Mekkora volt a súlya az első banki rendszernek? a, 600 kg
b, 2,5 t
c, 22,7 t
Mit jelent a redundancia az informatikai környezetek tekintetében? a, Erőforrás duplikáció
b, Virtuális hardver kiépítés
c, Hálózati zavar
Milyen architektúrális elemek nevei az alábbiak: WebSphere, WebLogic, GlassFish? a, Hálózati eszközök
b, Közösségi média oldalak
c, Alkalmazás szerverek
2016
Mikor vezették be a bankszámlaszám fogalmát? a, 1812
b, 1955
c, 2004
Mekkora volt a súlya az első banki rendszernek? a, 600 kg
b, 2,5 t
c, 22,7 t
Mit jelent a redundancia az informatikai környezetek tekintetében? a, Erőforrás duplikáció
b, Virtuális hardver kiépítés
c, Hálózati zavar
Milyen architektúrális elemek nevei az alábbiak: WebSphere, WebLogic, GlassFish? a, Hálózati eszközök
b, Közösségi média oldalak
c, Alkalmazás szerverek
Banki rendszerek története 1950-es évek – az első banki rendszer • Bank of America által megrendelt • A Stanford Research Institution-on • 1950-1955-ig futó projekt • ERMA (Electronic Recording Machine, Accounting)
2016
Banki rendszerek története
2016
1950-es évek – az első banki rendszer • 1959-ben került kereskedelmi forgalomba (General Electrics, GE-100) • 1970-ig működtek, mint a BoA számlavezető és csekkezelő rendszere • 22.7 tonna • 80 kWatt fogyasztás • 8000 elektroncső (később tranzisztor alapú) • 34.000 dióda
Banki rendszerek története
2016
1960-es évek – központosított adatfeldolgozás • a fiókokból összegyűjtik a kézzel írt dokumentumokat • a központban operátorok által, manuálisan történik az adatbevitel • riportok generálása a bankvezetés számára • néhány banki tranzakció végrehajtása • ERMA első számlavezető és csekk-kezelő számítógép
Banki rendszerek története
2016
1970-es évek – fiókok technológiai fejlesztése • kialakulnak az offline fiókok • fiókon belül a terminálok online kapcsolódnak a helyi feldolgozást végző lokális számítógéphez • a központi feldolgozás offline történik • később a fiókok online összeköttetésbe kerülnek a központtal • a központban mainframe-eken történik a tranzakciók feldolgozása és az adatok tárolása
Banki rendszerek története
2016
1980-es évek – új termékek, új eszközök • termék alapú bankolás, új banki termékek jelennek meg • Hitelkártyák (credit card) • Betétkártyák (debit card)
• új termékek új eszközök bevezetését jelentették • ATM (Automated Teller Machine) • POS (Point Of Sales) • IVR (Interactive Voice Response)
Banki rendszerek története
2016
1990-es évek – elektronikus csatornák • az internet térhódításának eredményeként új (elektronikus) csatornák jönnek létre • megjelennek a banki weboldalak • megjelenik az internetbank (online banking) • központokban többnyire még mainframe-ek futnak • a fiókokban PC-ék • folyamatosan teret nyernek a többrétegű architektúrák
Banki rendszerek története
2016
2000-es évek – mobil technológiák • A mobil kommunikáció fejlődésének eredményeként az elektronikus csatornák bővülnek • sms bank • mobil bank • még mindig jelentős a mainframe alapú központi feldolgozás • de egyre gyakoribb a többrétegű architektúrák alkalmazása • terjed a szolgáltatás orientált megközelítés
Elosztott rendszerek
2016
Az 1990-es években a banki környezetekben központosított ősrendszerek futottak, melyek nagy száma miatt bonyolult, egymással sokszoros keresztkapcsolatban álló alkalmazáscsoportok, úgynevezett szigetrendszerek alakultak ki.
Ezek paraméterezését, esetleg fejlesztését egyre körülményesebb volt a piac dinamizmusához alakítani.
Ezért az osztott rendszerek tervezőinek a célja lett, hogy olyan hardvert és szoftvert tervezzenek, amely rendelkezik az osztott rendszerektől elvárt tulajdonságokkal és ugyanakkor minimalizálja az ezekkel a rendszerekkel kapcsolatos problémákat.
Elosztott rendszerek
2016
Az osztott rendszerek olyan rendszerek, amelyekben az információfeldolgozás nem egyetlen gépre korlátozódik, hanem el van osztva több számítógép között.
Jelenleg minden nagy számítógép-alapú rendszer osztott.
Elosztott rendszerek előnyei: Erőforrás megosztás Nyíltság Konkurencia Skálázhatóság, hibatűrés Elosztott rendszerek hátrányai: Bonyolultság Biztonság Kezelhetőség Megjósolhatatlanság
2016
Osztott rendszerek architektúrájának főbb típusai Az ipari és az üzleti szférában az alábbi architektúrákat széles körben használják, de az alkalmazások osztottsága általában egyetlen szervezeten belül értendő. Az így támogatott osztottság így szervezeten belüli. Kliens-szerver architektúra. Ebben a megközelítésben a rendszer nem más, mint kliensek számára biztosított szolgáltatások halmaza. Ezek a rendszerek különbözőképpen kezelik a szervereket és a klienseket.
Hálózat
Kliens
Szerver
2016
Osztott rendszerek architektúrájának főbb típusai Az ipari és az üzleti szférában az alábbi architektúrákat széles körben használják, de az alkalmazások osztottsága általában egyetlen szervezeten belül értendő. Az így támogatott osztottság így szervezeten belüli. Osztott objektumarchitektúrák. Ebben az esetben nincs különbség a szerverek és a kliensek között, és a rendszert olyan egymással kölcsönhatásban lévő objektumok halmazaként képzelhetjük el, amelyek helye lényegtelen. Nem különböztetjük meg a szolgáltatókat és a szolgáltatások felhasználóit.
o1
o2
o3
o4
S(o1)
S(o2)
S(o3)
S(o4)
Szoftverbusz o5
o6
S(o5)
S(o6)
2016
Osztott rendszerek architektúrájának főbb típusai Az ipari és az üzleti szférában használt szervezetközi megosztás számára megfelelő osztott architektúrák: peer-to-peer architektúra. A peer-to-peer feldolgozás önálló hálózati csomópontok által végzett feldolgozáson alapul. A feldolgozást a hálózat bármely csomópontja végezheti és (elvileg) nem különböztetünk meg klienseket és szervereket. Lehet centralizált és decentralizált.
n8
n4
n6
n7
n2
n3
n1
n5
2016
Osztott rendszerek architektúrájának főbb típusai Az ipari és az üzleti szférában használt szervezetközi megosztás számára megfelelő osztott architektúrák: szolgáltatás orientált architektúra. A szolgáltatás orientált rendszerek osztott szolgáltatásokon alapulnak, az adatcserére pedig XML-alapú szabványokat használnak.
2016
Osztott rendszerek architektúrája - Middleware Az osztott rendszerek különböző komponensei különböző programozási nyelveken implementálhatók és különféle processzorokon futtathatók. Az adatmodellek, az információ ábrázolásmódja és a kommunikációs protokollok mind-mind eltérhetnek. Egy osztott rendszernek ezért olyan szoftverre van szüksége, amely a különféle részeket kezelni tudja, és biztosítja a kommunikáció és adatcsere lehetőségét.
Az ilyen szoftvereket köztes termékeknek, middleware-eknek hívjuk – a rendszer osztott komponensei között középen helyezkednek el.
A köztes termékek (middleware-ek) olyan általános célú szoftverek, amelyeket általában kulcsrakész formában vásárolnak meg ahelyett, hogy az alkalmazás fejlesztői írnák meg azokat. Köztes termékek például az adatbázisokkal kommunikációt kezelő szoftverek, a tranzakciókezelők, az adatkonverterek, a kommunikációvezérlők, stb. Bankinformatikában a köztes szoftverek általában tranzakciókezelők, vagy egyéb üzleti logikát megvalósító szoftverek.
2016
A kliens-szerver architektúra I. A kliens-szerver architektúra egy olyan osztott rendszer modell, ami megmutatja, hogy az adat és a feldolgozás hogyan oszlik meg a feldolgozóegységek között. A modell fő komponensei: Szerverek halmaza, amelyek más alrendszerek számára szolgáltatásokat nyújtanak. Kliensek halmaza, amelyek hozzáférnek a szerverek által biztosított szolgáltatásokhoz. Ezek általában önálló létjogosultsággal rendelkező alrendszerek. Egy kliensprogramnak számos példánya futhat egyidejűleg. Hálózat, amely lehetővé teszi, hogy a kliensek hozzáférjenek a szolgáltatásokhoz.
Kliens
Szerver
2016
A kliens-szerver architektúra II. Azaz a kliens-szerver architektúrában az alkalmazást szerverek által biztosított szolgáltatásoknak, valamint az ezeket igénybevevő klienseknek a halmazaként modellezik. A klienseknek tudniuk kell az elérhető szerverekről, de általában nem tudnak a többi kliens létezéséről. A kliensek és szerverek különálló folyamatok. c4 c3
Szerverfolyamat
c12
Kliensfolyamat c2
S1
S4
c11
c1
c10 c5
S2
S3
c9
c6 c7
2016
A kliens-szerver architektúra III. Számos folyamat futhat egyetlen processzoron, ezért a rendszer folyamatai és processzorai közötti kapcsolat számossága nem szükségképpen 1:1. Az alábbi ábrán hat kliens- és két szerverszámítógéppel felálló rendszer fizikai felépítése látható, amelyek az előző ábrán látható kliensés szerverfolyamatok futtatására képesek. Általában, amikor kliensekről és szerverekről beszélünk, ezekre a logikai folyamatokra gondolunk, nem pedig azokra a fizikai számítógépekre, amelyeken ezek a folyamatok végbemennek. c1 CC1
c2 CC2
c3, c4 CC3
s1, s2
s3, s4
SC1
SC2
Szerverszámítógép c5, c6, c7 CC4
c8, c9 CC5
c10, c11, c12
Kliensszámítógép
CC6
c1 – c12
Kliensfolyamatok
s1 – s4
Szerverfolyamatok
2016
A kétrétegű kliens-szerver architektúra A legegyszerűbb kliens-szerver architektúra a kétrétegű kliens-szerver architektúra, ahol az alkalmazás egy szerverből (vagy több azonos szerverből) és több kliensből épül fel. A kétrétegű kliens-szerver architektúrának két formája van:
Vékony kliens modell. Egy vékonykliens modellben minden alkalmazásfeldolgozó és adatkezelő művelet a szerveren megy végbe. A kliens csupán a megjelenítő szoftver futtatásáért felelős.
Vastag kliens modell. Ebben a modellben a szerver csak az adatkezeléssel törődik, az alkalmazáslogikát és a felhasználóval történő kapcsolattartást a kliensen futó szoftver valósítja meg.
2016
A kétrétegű kliens-szerver architektúra Központosított ősrendszerek kliens-szerver felépítésű rendszerekké alakítása legegyszerűbb egy vékony klienssel rendelkező, kétrétegű architektúrát használni.
esetén
Ezen rendszerek felhasználói felületét kell átültetni PC-kre, és maga az alkalmazás szerverként üzemel, kezelve az alkalmazás feldolgozásának és az adatok kezelésének műveleteit. A vékony kliens modell abban az esetben is kialakítható, ha a kliensek egyszerű hálózati eszközök, nem pedig PC-ék, vagy munkaállomások. A hálózati eszköz futtat egy internetböngészőt, amin keresztül a felhasználói felület implementálva van.
Kliens
Szerver
Megjelenítés
Adatkezelés Adatfeldolgozás
2016
A kétrétegű kliens-szerver architektúra A vékonykliens modell fő hátrányai: mind a szervert, mind a hálózatot nagy terhelésnek teszi ki minden számításért a szerver a felelős, és ez a kliens és a szerver között jelentős hálózati forgalmat generálhat a modern PC-kben sok olyan feldolgozási tartalék van, amelyet a vékony kliens architektúra nagyrészt kihasználatlanul hagy
2016
A kétrétegű kliens-szerver architektúra Ezzel szemben a vastag kliens modell kihasználja ezt az elérhető feldolgozási tartalékot, és mind az alkalmazáslogika feldolgozásának, mind pedig a megjelenítésnek a feladatát a kliensre osztja. A szerver lényegében egy tranzakciószerver, amely az adatbázis tranzakciókat kezeli.
Kliens
Szerver
Megjelenítés Adatfeldolgozás
Adatkezelés
2016
A kétrétegű kliens-szerver architektúra Ennek az architektúrának jól ismert példái a banki ATM-rendszerek, ahol az ATM a kliens, a szerver pedig az ügyfél számlaadatbázisát futtató nagyszámítógép. A pénzkiadó automata hardvere sok, a tranzakcióval kapcsolatba hozható, ügyféllel kapcsolatos feldolgozást végez. Ugyanakkor az ATM-ek nem közvetlenül az ügyféladatbázishoz, hanem egy távoli feldolgozást felügyelő tranzakciókezelőhöz kapcsolódnak. Egy tranzakciókezelő (vagy távfeldolgozó monitor) olyan köztes termék (middleware), amely szervezi a távoli kliensek kommunikációját és szériázza a kliens tranzakcióit, hogy azokat az adatbázis fel tudja dolgozni. A szériázott tranzakciók használata azt jelenti, hogy a rendszer hiba esetén adatvesztés nélkül helyreállítható.
ATM ATM
ATM ATM
Számlaszerver Távfeldolgozó monitor
Ügyfélszámla adatbázis
2016
A kétrétegű kliens-szerver architektúra A vastag klienseken alapuló modell ugyan hatékonyabban osztja el a feldolgozást, mint a vékony klienseken alapuló modell, de a rendszermenedzsment bonyolultabb vastag kliensek használata esetén. Az alkalmazás funkcionalitása sok különböző számítógép között van szétszórva. Ha az alkalmazást meg kell változtatni, akkor az magával vonja a kliensekre való újratelepítést. Ez több száz klienssel rendelkező rendszer esetén igen nagy költséggel járhat.
A szerverről kliensre letölthető mobil kód (mint például a Java-appletek és ActiveX vezérlők) megjelenése olyan kliens-szerver modell kifejlődését tette lehetővé, amely valahol a vékony és a vastag kliens modellek között helyezkedik el. Az alkalmazást futtató szoftverek mobil kódként letölthetők a kliensre, ily módon könnyítve a szerver terhelésén. A felhasználói felület egy, a letöltött kódokat futtatni képes webböngésző segítségével épül fel.
2016
A háromrétegű kliens-szerver architektúra A háromrétegű kliens-szerver architektúrában a megjelenítés, az alkalmazásfeldolgozás és az adatkezelés különböző processzorokon futó logikailag különálló folyamatok.
Prezentáció KLIENS
SZERVER Alkalmazás feldolgozás
SZERVER Adatkezelés
2016
A háromrétegű kliens-szerver architektúra Egy háromrétegű kliens-szerver architektúra megvalósítására példa lehet egy bank portálrendszere (mint például egy bank honlapja). a portálon megjelenő adatokat tartalmazó adatbázis biztosítja az adatkezelési szolgáltatásokat egy webszerver biztosítja a portál által nyújtott szolgáltatásokat (mint például időpontfoglalás a bankfiókban vagy éppen betét- és hitel kalkulátorok) a felhasználó saját számítógépe pedig egy internetböngészővel rendelkező kliens, amelyen megjelenítésre kerül a banki portál felülete és azon keresztül az elérhető információk és szolgáltatások ez a rendszer skálázható, mivel az ügyfelek számának növekedésével a rendszer könnyen bővíthető új webszerverek hozzáadásával
2016
Többrétegű kliens-szerver architektúra Gyakran célszerű a háromrétegű kliens-szerver modell többrétegűvé bővítése, ahol a rendszerhez további rendszerek kapcsolódnak.
A többrétegű rendszerek akkor használhatók, ha az alkalmazásoknak több adatbázishoz kell hozzáférniük és azokat használniuk.
Ebben az esetben az alkalmazásszerver és az adatbázisszerverek közé egy integrációs szervert kell elhelyezni, amely összegyűjti az osztott adatokat, és úgy jeleníti meg az alkalmazás számára, mintha azok egyetlen adatbázisból valók volnának.
2016
Többrétegű kliens-szerver architektúra Többrétegű architektúrára példa lehet egy internetbanki alkalmazás. Az internetbankok napjainkban már igen gazdag funkcionalitást nyújtanak a felhasználók számára. A funkciókhoz szükséges adatok több – akár egymástól elkülönített – adatbázisokban, több adatbázisszerveren vannak tárolva. Az adatbázisok egy része általában egy számlavezető rendszerhez kapcsolódik, amely egy alkalmazásszerveren fut. A számlavezető rendszer feladata a különböző a számlavezetéssel és banki tranzakciókkal kapcsolatos műveletek kezelése. Ehhez a rendszerhez kapcsolódik általában az internetbank, mint felület, amely egy webszerveren fut. Ez a felület általában a megjelenítéssel, esetleg authentikációs folyamatokkal, valamint a felületen a felhasználó által kitölthető mezőkbe írt adatok előellenőrzésével kapcsolatos logikákat tartalmazza. Minden egyéb banki funkció esetében az adatokat átadja a számlavezető rendszernek (vagy egyéb köztes üzleti logikának).
Általános architektúra
2016
KLIENSEK Netbank
Mobilbank
Call center
Partnerek alkalmazásai
Fiókok
Adminisztráció
Monitoring
KÖZTES SZERVEREK Webszerverek
Üzleti logikák (alkalmazás szerverek)
Portál szerverek
Work-flow motorok (alkalmazás szerverek)
Elszámoló központok
Integrált service bus Pénzügyi hálózatok
ADATBÁZISOLDALI LOGIKA Számlaadat műveletek
Tranzakciósadat műveletek
Ügyféladat műveletek
Hiteladat műveletek
Kártyaadat műveletek
ADATBÁZISOK Számla adatok
Tranzakció adatok
Ügyfél adatok
Külső adatkapcsolatok
ADATTÁRHÁZAK
Hiteladatok
Kártya adatok
Történeti, részletes adatok
2016
Köszönöm a figyelmet!
